思想

プログラマは若いうちの仕事だ、という言い方があります。歳を重ねれば設計や管理へ移り、いつかは現場を離れる。そういうキャリアが当たり前とされてきました。そこへAIがコードを書くようになり、プログラマという職業そのものが要らなくなるという話まで出てきています。

どちらの見立ても、プログラミングを「コードを書くこと」だと捉えています。書く作業が中心なら、速く書ける若い人が有利になり、機械が書けるようになれば人は要らなくなる。筋は通っています。

けれど、実際の仕事はそこに収まりません。何をつくるべきかをお客さまと一緒に悩むところから始まり、設計し、つくり、動き出したあとも直し続ける。その全体がプログラミングです。外科医が手術で患者を治すように、プログラマはソフトウェアを通じて問題を解決します。コードは、その過程で生まれる表現のひとつにすぎません。

そう捉え直すと、この仕事は歳を重ねるほど分が悪くなるものではありません。書く速さでは若い人に敵わなくなっても、何をつくるべきかの判断は、見てきた失敗の数だけ確かになります。医者や弁護士と同じで、経験がそのまま実力になる種類の仕事です。だから、続けられる。

しかも、終わりがありません。技術は変わり続け、解くべき問題も変わり続ける。ここまで来れば極めた、と言える地点が用意されていない。飽きることがないという意味でもあり、一生かけても足りないという意味でもあります。

AIがコードを書けるようになって、この性質はむしろ強まりました。書く手間が減るほど、何をつくるかを決め、それでよいと引き受ける部分の比重が上がります。積み上げた経験が効くのは、まさにその部分です。裾野は広がり、プロの敷居はかえって高くなる。

私自身、学生の頃に仲間とつくったソフトウェアを公開し、使った人から直接反応をもらったときの興奮を、いまも覚えています。自分のアイデアが形になり、誰かの役に立つ。あの手ざわりは、経営に携わるようになっても変わりませんでした。

続けられて、続ける価値がある。だから、プログラマを一生の仕事にする。歳を重ねても、AIの時代になっても、つくることで生きていける。それが私たちの出発点です。

ソフトウェア開発の現場では、工程を分けるのが当たり前とされてきました。要件を決める人、設計する人、コードを書く人、テストする人、運用する人。人手が足りなければ、人を増やして間に合わせる。

この分け方は、ものづくりを設計と製造に分ける考え方から来ています。設計図さえできれば、あとは図面どおりに作ればいい。製造の部分は人数を投じれば速くなる。工場のやり方です。

けれどソフトウェアには、製造にあたる工程がありません。図面どおりに組み立てる作業は、とうにコンピュータの仕事です。人間が手を動かしているところは、殆どが設計です。分業できる「製造」だと思っていた部分が、そもそも存在しなかった。

設計は試行錯誤の連続です。つくってみて初めて分かることがあり、分かったら戻って考え直す。この行き来を工程の壁で分断すると、そのたびに人と人の間で受け渡しが起き、速さも精度も落ちていきます。腕のいい医者が百人集まっても、難しい手術がその人数ぶん簡単になるわけではない。人を増やしても速くならないのは、同じ理由です。

だから私たちは、分業しません。何をつくるかをお客さまと決めるところから、設計し、書き、動き出したあとの運用まで、同じ人が持ちます。開発と運用も分けません。担当が変わらないので、前に考えたことがそのまま次に効きます。

そしてもうひとつ、設計には再現性がありません。同じ問題を渡しても、人によって解き方が違います。良し悪しの差というより、そもそも同じにならない。ソフトウェア開発とは元来そういう仕事で、属人的になるのは避けようがない。

工程を分ける発想は、誰がやっても同じ結果になるという前提の上に成り立っています。その前提を取れば、人による違いは消すべき誤差になる。私たちは、前提のほうを取りません。違いは均すものではなく、作家性として扱っています。

AIがコードを書くようになって、この方向はさらに進みました。ソフトウェアをつくるのに要る人数は、これから確実に減っていきます。残るのは人数の問題ではなく、難易度の問題です。

会社は人を管理するものだ、と長く思われてきました。目標を立てて割り振り、進捗を測り、評価して処遇に反映する。そうしないと人は動かない、という前提です。

私は以前、三千人ほどの規模のシステム開発会社で管理職をしていました。そこで見たのは、ルールで縛れば縛るほど、人が自分で考えるのをやめていく光景です。決められた通りにやることが仕事になり、決められていないことは誰もやらなくなる。

そもそも、管理とマネジメントは同じものではありません。マネジメントとは、状況をなんとかして良い感じにすることです。管理は、そのための手段のひとつにすぎません。ところが日本語では管理という訳語が定着したせいで、マネジメント＝統制という意味に狭まってしまいました。

私たちがやめたのは、この狭いほうの管理です。マネジメントをやめたわけではありません。

ソフトウェア開発は、統制がいちばん効きにくい仕事です。再現性がなく、手順に落とせない。原材料もなく、すべてが人の頭から出てきます。何をつくるかも、どうつくるかも、その場の判断が要る。手順に落ちないものを、細かく指示することはできません。

もうひとつ、動機の問題があります。この種の仕事で成果を左右するのは、内から湧いてくる動機のほうです。評価や報酬で外から動機づけようとすると、評価される形に仕事を寄せる力が働き、面白いと思う方向へ進む力を打ち消してしまいます。

だから、目標管理をやめ、個人評価をやめ、上司をなくしました。短い期間でプログラマの働きを測るのが難しいからでもありますが、理由の中心は動機のほうです。外から与えなくても湧いてくるものを、消さないようにしたかった。

管理する人がいなくなると、その分をひとりひとりが担うことになります。それがセルフマネジメントです。自己管理とは違います。朝きちんと起きる、体調を保つ、締切を守る。そうやって自分を律することは、その入口にすぎません。

仕事の目的を自分で確かめ、手がつく大きさに分け、周りと相談しながら進め、終わったら振り返って次に活かす。見える範囲を、自分の担当からチームへ、お客さまへ、会社の外へと広げていく。そこまで含めてセルフマネジメントと呼んでいます。

これができて成果が出るなら、働く場所や時間を決める理由はなくなります。全国どこからでも働けて、コアタイムのない完全フレックスになっているのは、そう決めたというより、管理をやめた結果としてそうなった部分が大きい。

ただし、楽な会社という意味ではありません。指示がないということは、自分で決めるということです。自由と自立は表裏一体で、片方だけを取り出すことはできません。

セルフマネジメントは才能ではなく、身につけられる習慣だと考えています。だから、段階を追って身につける道筋を用意しています。どこでも働ける人になったうえで、それでもここにいたいと思える場をつくること。それが経営の仕事です。

会社とは目的を達成するための組織だ、というのが普通の説明です。事業があり、目標があり、それを実現するために人を集める。目的が果たされれば次の目的が置かれ、集められた人はそのために働く。

私たちの始まりは、そうではありませんでした。前の会社の中でつくった小さな組織が、会社の都合で解散させられそうになったことがあります。そのとき手放したくなかったのは、事業でも実績でもなく、一緒にやってきた仲間でした。この人たちと働き続けるにはどうすればいいか。それが独立の理由です。

会社があって人が集まったのではなく、集まった人たちが続けるために会社という形を選びました。順番が逆になっています。

もっとも、目的を持って組む集まりがないわけではありません。お客さまとは、チームを組みます。「納品のない受託開発」では、社外の業者としてではなく、お客さまの事業の一員として入り、何をつくるべきかから一緒に悩んで貢献する。ここには果たすべき目的があり、出すべき成果があります。

そのチームを担っているのが、私たち一人ひとりです。それぞれが別のお客さまと仕事をしていますが、会社に戻れば同じ職業の人間が集まっている。知見を持ち寄り、うまくいかないときは励まし合い、詰まったら助け合う。技術者のコミュニティのような場所です。

お客さまと組むチームと、それを担う人たちのコミュニティ。この二つが、共通のビジネスモデルの上で会社として成り立っている。それがソニックガーデンという場です。

チームとコミュニティは、続き方が違います。チームは目的のために組まれ、果たせば解散する。コミュニティは、目的ではなく共通の関心で集まり、どういう状態であるかで続いていきます。終わりが設定されていません。だから私たちは、急いで大きくすることを目的には置かず、長く続くほうを取ります。

コミュニティであることは、採用のしかたも変えます。ビジネスのための組織なら、能力だけを見て採ることもできるでしょう。コミュニティではそうはいきません。カルチャーを壊す人を迎え入れると、場そのものが変わってしまうからです。

だから、まず見るのは、ありたい姿に共感できるか、近い価値観を持っているか、そして一緒にいて仲良くなれるかどうかです。そういう人たちが集まってきたからこそ、いまのカルチャーができあがりました。

共通の趣味を持つ友人同士のようでもあり、腕を磨く道場のようでもある。そういう場所として保ちたいと考えています。

仕事は生活のためにするもので、楽しさは求めるものではない。そう考える人は少なくありません。楽しいかどうかは趣味の領域で、仕事は我慢して対価を得る場だ、という分け方です。

けれど、成果という点から見ると、この分け方は分が悪い。論語に、知る者は好む者に如かず、好む者は楽しむ者に如かず、という一節があります。知識のある人も好きな人には敵わず、好きな人も楽しんでいる人には敵わない。実際、大きな成果を出しているのは、その仕事を楽しんでいる人です。

遊ぶように働くというのは、遊びながら働くという意味ではありません。本人は真剣に取り組んでいるのに、外から見ると楽しんでいるように見える。そういう状態を指しています。

そもそも遊びとは、それ自体が目的になっている活動のことです。子どもは報酬のために遊びません。やること自体が面白いから続く。外から動機づけなくても動いてしまう状態、と言い換えてもいい。仕事にも、同じ状態はありえます。

では、なぜ面白くなるのか。ひとつは、上達があるからです。昨日できなかったことが、今日はできる。その手ごたえ自体が報酬になります。私たちはこれを技芸と呼んでいます。技術のように誰がやっても同じ結果にはならず、芸術のように自分の表現だけで完結もしない。腕を磨いて、誰かの役に立つものをつくる。その中間にある営みです。

もうひとつは、難易度です。易しすぎれば退屈になり、難しすぎれば不安になる。夢中になれるのは、その間の狭い帯にいるときだけです。だから仕事の任せ方は、その人がいまいる位置より少し上を狙って調整することになります。手が届きそうで届かない、というところに置く。徒弟制度で段階を追うのも、この帯から外さないためです。

そして、自分で決められること。同じ難易度でも、命じられてやるのと、自分で選んでやるのとでは、別の仕事になります。管理をやめたのは、この一点のためでもありました。

私自身、創業したばかりの頃は自分で電話をかけて営業していました。誰に言われたわけでもありません。それでも苦痛でした。難しかったからでも、選ばされたからでもなく、単純に面白いと思えなかった。そこで、苦手をできるようにするのはやめて、得意なことを徹底的に活かす方へ切り替えました。

社内には部活と呼んでいる時間があります。仕事で生まれた余白を使って、仲間と好きなものをつくる。そこから実際のサービスになったものもあります。稼ぐためのプログラミングと、遊びのためのプログラミングを分けていません。

ただ、楽しく働くことと楽に働くことは違います。夢中になるには、届きそうで届かないところへ手を伸ばし続けることになる。大変ですし、疲れもします。それでも成果が出ると、また楽しくなる。仕事は生計を立てる手段であると同時に、人生を豊かにする経験でもあると考えています。

技芸は、勉強して身につくものではありません。わかることと、できることは違います。知識を入れただけでは、できるようにならない。状況に応じた判断、設計の美しさに対する感覚、お客さまとの話から本質を見抜く力。どれも、研修で教えられるものではありません。

かといって、自己流の鍛錬だけで育つには、よほどの才能か、膨大な時間が要ります。早く上達するには、先を行く人からのフィードバックが欠かせない。自分では見えていないところを指摘してもらうと、鍛錬の質が変わります。

腕を磨くのに要ることは、突き詰めると三つです。できる人のプロセスを間近で見ること。自分の手で実践すること。その実践を見てもらい、フィードバックを受けること。

上司と部下の関係では、これが成り立ちません。上司の目的は、部下に成果を出させることです。プロセスに時間をかけることは、短期の生産性と衝突します。上司に求められるのは話を聴くことですが、技芸を伝えるのに要るのは、仕事のプロセスを見ることです。

そこで私たちは、上司ではなく親方と呼ぶことにしました。宮大工の世界を書いた『棟梁』という本から借りた言葉です。親方は、自分も仕事をしながら、弟子が育つ環境と機会を渡す。命じる人でも、教える人でもありません。隣で働き、見て、必要なときに手を入れる。

昔の徒弟制度には、理不尽さがつきものでした。長く下働きをさせる、理由を説明しない、私生活まで縛る。そこは持ち込みません。受け継いだのは、伝え方の構造のほうだけです。

段階もあります。最初は親方の手伝いから始まり、やがて案件に加わり、自分でお客さまを持つようになる。前の章で書いた、届きそうで届かない帯から外さないための段取りでもあります。道筋の詳しい中身は、開発者への道にまとめています。

そして、育つのは弟子だけではありません。人が育つ仕組みを持つと、その仕組み自体が組織を育てていきます。親方のほうも、弟子に見られることで自分の仕事を言葉にするようになる。

デジタル化とAIが進むほど、現場から易しい仕事は減っていきます。残るのは難易度の高い仕事ばかり。けれど、誰もが最初から高度な仕事をできるわけではありません。経験を積む機会がなければ、いつまでも初心者のままになってしまう。その穴を埋めるのが、徒弟制度だと考えています。

AIがコードを書けるのだから、プログラマは要らなくなる。そう言われるようになりました。

似たことは何度も起きています。パンチカードは高級言語に置き換わり、サーバーの構築はクラウドに吸収されました。そのたびに手作業の工程が消えましたが、消えたのは工程であって、つくる仕事そのものではありません。省けたぶんだけ、人は何をつくるかを考えることに時間を使えるようになりました。生成AIも、その延長にあります。

コードを書く行為は、ソフトウェア開発の一部にすぎません。何をつくるべきかを決め、どう組み立てるかを設計し、動き出したあとの責任を持ち続ける。この部分は誰かが引き受けなければならず、引き受けられるのは人です。書く手間が減るほど、決めることと引き受けることの比重は上がります。

だから、AIと人を競わせる構図には意味がありません。私たちが向き合っているのは問題のほうで、AIはこちら側に立つ道具です。対立させるより、どう組むかを考えたほうが早い。

一方で、動くものをつくること自体は、誰にでもできるようになりました。けれど、それが本当に良いのかを判断し、長く使われる状態を保つ仕事は、前より難しくなっています。裾野が広がることと、頂が低くなることは別です。敷居はむしろ、上がったのではないか。

私が新人だった頃、ソフトウェア開発は工業化を目指していました。属人性を排除し、誰がつくっても同じものになるようにする。人月という単位で人を数える。あの考え方の下では、つくる人の名前は残りません。

いまは、その逆へ向かえる時期だと考えています。手を動かす部分をAIに任せられるようになったぶん、何をどうつくるかという判断に、その人らしさが出るからです。技術でも芸術でもない、技芸と呼ぶべき領域が、そこにあります。

ただ、放っておいて戻るわけではありません。だから私たちは、仕事を技芸として捉え直す考え方を、自分たちで実践し、外へも広げていきます。つくったものに自分の名前を置ける仕事に、もう一度していく。