『新米マネージャー、最悪な未来を変える』（倉貫書房）の刊行記念として企画されたこのイベント。普段のエンジニアやビジネス系のイベントとはまったく違う空気感で、正直なところ少し緊張していました。

ミシマ社との出会い

ミシマ社の三島さんとの出会いは、2025年の2月ごろのことでした。お互いの仕事について話すうちに意気投合し、ミシマ社のDXをソニックガーデンがお手伝いし、倉貫書房の2冊目の編集・営業をミシマ社にお願いするという関係になりました。

私たちはこれを「技術の物々交換」と呼んでいます。それぞれの得意なことを持ち寄って、お互いの課題を解決し合う。そうしたつながりから、ソニックガーデンとミシマ社は業務提携にも至りました。

今回のイベントも、そうした関係の延長線上にあります。

三島さんとのトーク

イベントの前半は三島さんとのトークでした。出版社を営む三島さんと、ソフトウェアの会社を営む私。業種はまったく違いますが、「ちいさな会社でおもしろく仕事をする」というテーマでは、驚くほど共通する部分がありました。

トークはお互いの出会いの話から始まり、規模や業種は違っても「いい仕事をしたい」という思いが重なる部分について語り合いました。三島さんとの対話はとても楽しく、話が自然に広がっていく感覚がありました。

「クリエイティブ読書」というワークショップ

今回のイベントで特に手応えがあったのが、「クリエイティブ読書」と名付けたワークショップです。

やり方はシンプルです。『新米マネージャー、最悪な未来を変える』から数ページだけ抜粋した箇所を、その場で参加者に読んでもらいます。そして「あなたならどうする？」という問いをもとに、隣の人と話し合ってもらう。それだけです。

これが大変盛り上がりました。

本の中で、新米マネージャーの建太が直面する組織の問題は、多くの人にとって他人事ではなかったようです。「自分だったらこうする」「自分の職場でも同じことがあった」と、参加者同士の対話がどんどん深まっていきました。

本を作った側として話すということ

ワークショップの後、参加者から共有してもらった意見に対して、本を作った側としての意図や狙いをお話しさせてもらいました。なぜこのシーンを入れたのか、元ネタになったソニックガーデンでの習慣や哲学について。

参加者の皆さんの反応を見ていて、小説という形式だからこそ、正解を教わるのではなく自分ごととして考えられるのかもしれないと感じました。

熱心にメモをとってくださる方も多く、質問もたくさんいただきました。

うれしい時間

参加者の皆さんがワークショップにも積極的に参加してくださり、ほとんどの方がサイン会にも残ってくださいました。アンケートでも「具体的な内容で参考になった」「仕事についてのビジョンのヒントがたくさんあった」「楽しかった」といった声をいただき、とてもうれしい時間になりました。

今後も三島さんやミシマ社との良い関係を続けていきたいですし、「クリエイティブ読書」という試みも、また別の機会にやってみたいと思っています。

今回のイベントのきっかけとなった倉貫書房の2冊目『新米マネージャー、最悪な未来を変える』は、ミシマ社に編集・営業をお願いして作った本です。ご興味のある方はぜひ。

▼詳しくはこちら（公式サイト）
▼個人での購入はこちら（バリューブックス）

前回の記事では、なぜ私たちが師匠と弟子という関係を選んだのかを書いた。今回は、その中で具体的にどう育てているのか。親方たちが実践の中で得た学びと、うまくいかないことも含めて書いてみたい。

試合をしなければ育たない

技芸の育成において、私が最も大切だと考えていることがある。全体をつくる経験を早い段階から積ませることだ。

ソフトウェア開発のゴールは「コードを書くこと」ではない。お客さまの事業を成長させること、業務の問題を解決すること。それがゴールである。しかも私たちの「納品のない受託開発」では、お客さまとの対話から問題や実現したいことを引き出すことから始まり、つくって終わりではなく、成果が出せているかどうかまで気にする。

このゴールに至る全体のプロセスを体験しなければ、部分だけ鍛えても意味がわからないまま終わる。効率を突き詰めると分業に行き着くが、分業では自分の作品だとは感じられない。面白さも熟達もそこにはない。コーディングはいくらでも効率化できるし、AIで代替もされうる。しかし、全体を見て目的の達成に導く力は、全体を経験しなければ身につかない。

サッカーに例えるとわかりやすい。プロのサッカー選手は、基本的なことがすべて高いレベルでできた上で、得意な役割がある。しかし、すべてをマスターしないと試合ができないわけではない。技術的に劣る部分があっても、試合をすれば何が足りないかがわかるし、勝っても負けても試合そのものが面白い。面白いから続けられる。だから小さな頃から試合をする。練習だけしても、うまく育たないのだ。

ソフトウェア開発も同じである。ただし、本番環境に未熟な成果物を出すわけにはいかない。そこで私たちは「安全に試合ができる場」として、毎月のハッカソンを用意した。ゼロから企画し、設計し、実装し、動くものを見せる。全体をつくる経験を、安全な環境で繰り返すのだ。

それと並行して、可能な限りお客さまとの打ち合わせに弟子を同席させる。親方がやっていることの全体が見えるようにするためだ。部分練習と試合の両方を回すことで、弟子は育っていく。

遊びが先、徒弟制度は後

試合が面白いのは、プログラミングそのものが面白いからだ。この「面白い」という感覚が、育成の出発点になる。だから弟子入りの前に、まずプログラミングで遊ぶ時間を確保することにしている。

同じ時期に二人の新入社員を迎えたことがあった。一人は少し開発経験があったので、そのまま弟子入りさせた。もう一人は開発経験がほぼなかったので、最初の半年ほどはゲームをつくらせることにした。プログラミングが面白くて没頭できて、寝食を忘れて取り組めるものだと思ってもらいたかったのだ。

結果は対照的だった。遊びから入った社員は、プログラミングで遊ぶようになり、自分から弟子として頑張りたいと言うようになった。

一方、いきなり弟子入りした社員は、難しさの方が大きくなったためか、仕事中は頑張るけれど、仕事の時間が終わるとプログラミングをしなくなった。プログラミングが面白いからやるのではなく、プログラマとして仕事ができるようになることが目的になってしまったのかもしれない。結果として、その社員は別の道を選んだ。

面白いと思えるから向上心が生まれ、向上心があるから親方の教えを素直に受け入れられる。親方もフィードバックのしがいがある。面白さが先になければ、徒弟制度はうまく機能しない。

弟子入りは強制ではなく、本人の自己決定から始まる。自分で決めたことでなければ、どこかで誰かのせいにしてやめてしまう。自分で決めたからこそ、その決断を正解にするために頑張れる。

弟子入りを受け入れるには、自分自身で上達したいという気持ちが必要だ。だから、その前の段階で遊ばせて、上達したい気持ちを醸成させることにしたのだ。

親方という存在

徒弟制度における親方とは、どんな存在なのか。

まず、親方は弟子の上位互換でなければならない。親方自身がプレーヤーであり続け、弟子よりも高い技術力を持つ。弟子の仕事は親方の仕事の一部であり、いざとなれば親方が代わることができる。プレーイングマネージャーという言い方があるが、親方はむしろマネージングプレーヤーだ。本職はあくまでプレーヤーであり、プログラマであること。その上で弟子を育てる。

弟子は親方の仕事の仕方を真似るところから始める。ただし、表面だけをなぞるのではない。大切なのは、親方の行動の意図を理解することだ。なぜそう判断したのか、なぜその方法を選んだのか。何度も意図を確認し、違っていたらフィードバックをもらう。

そうしているうちに、弟子の頭の中に親方が住み着く。コードを書いているときに、親方ならこう書くだろうか、これを見せたら何と言われるだろうか、と考えるようになる。私たちはこれを「リトル親方」と呼んでいる。何をしたら良しとされるのか、親方と価値判断が揃ってくる。それが型を身につけるということだ。

だからこそ、親方には一貫性が求められる。もし親方の考え方が毎回ブレていたら、弟子は親方の顔色を伺って正解を当てにいくだけになってしまう。親方が確固たる考え方を持ち、判断にロジックを持っていれば、弟子はその考え方のOSをインストールできる。その上で、自分の考えを持てるようになる。

一方で、親方は完璧な人間である必要はない。少しドジなところがあってもいいし、弟子と一緒にランチをしながらしょうもない話をしてもいい。弟子が親方を尊敬するのは、肩書きや権限があるからではない。圧倒的な実力の差があるからだ。実力が尊敬の源泉であり、人間らしさがあってこそ、師弟の関係性は築ける。

親方と弟子は、同じ道の先にいる同志でもある。弟子からすると遥か遠くだが、親方は同じ道の先にいて、親方自身もまだその先に進もうとしている。ソフトウェア開発の道を極めようとするコミュニティだからこそ、徒弟制度は機能する。

観察こそが親方の仕事

徒弟制度を三年ほど運営してきて、親方たちの間で共有されるようになった実践知がある。その中で最も大切なのは「観察」だと感じている。

弟子のタスクの進め方、調べ方、質問の仕方、迷ったときの反応、試行錯誤の痕跡。結果だけではなく、プロセスを見る。アスリートの育成で、記録だけを見て「もっと良い記録を出せ」と言うフィードバックはありえない。フォームや練習方法を見て改善していくことで上達する。プログラミングも同じだ。

観察していると、弟子の実力やコンディションが見えてくる。そこから、頑張ればちょうどできるレベルの仕事を渡す。この難易度の調整が、親方の大切な仕事である。簡単すぎれば退屈になり、難しすぎれば自信を失う。弟子がフロー状態に入れるような課題を設定するには、日頃の観察が欠かせない。

最初のうちは量を重視する。量をこなすことで質に転化するからだ。最初からいいコードを書こうとか、いい設計にしようと考えすぎて手が動かないのでは、何も経験値は得られない。まずはたくさんコードを書くことが大事だ。

親方は次々と新しいことに挑戦させたくなるが、新しいことは質の転換を求められる。その前に量稽古が必要だ。今の仕事が当たり前にできて余裕が生まれてから、質の転換に向かう。

こうした観察を続けていると、弟子の限界も見えてくる。特に忙しい時期にそれは顕著になる。限界は伸びていくものなので、定点観測を続けることが大切だ。弟子の速度がわかれば、親方もアクセルが踏みやすくなる。

口を出しすぎないことも大切だ。口を出すと、それは親方のアウトプットになってしまう。口を出さずに見ることで、弟子のボトルネックが見える。

失敗する前にフォローしすぎると、本当の強さは身につかない。観察していれば、取り返しのつかない失敗にはならない。たった一つの正解だけを教えるよりも、試行錯誤して身につけた答えの方が、将来に役に立つ。

ただし、違和感には厳密でなければならない。弓道の「正射必中」という言葉がある。正しく射れば、結果は自ずとついてくるという考え方だ。仕事の結果だけを見ても、なぜ時間がかかっているのか、なぜ品質が悪いのかはわからない。過程を見れば一目瞭然である。些細な違和感でも流さず、その場でフィードバックする。それが親方の責任だ。

教え方にも段階がある。最初は答えを教える。次に、正解を知った上で自分で練習させる。やがて自分で考えるように促し、最終的には内省の振り返りへと変わっていく。弟子のフェーズを見極めて、教え方を変える。このフェーズの見極めも、観察があって初めてできることだ。

一人では育てられない

親方と弟子の一対一の関係だけでは、育成は完結しない。

私たちが大切にしているのは、タテ・ヨコ・ナナメの関係性で弟子を支えることだ。タテは親方と弟子の指導関係。ヨコは弟子同士の関係である。同じ親方ハウスにいる弟子たちが互いに助け合い、刺激し合う。別の拠点にいる同期の弟子が、落ち込んでいる仲間をわざわざ励ましに行ったこともあった。ナナメは、採用や育成を全社横断で担う人事で、親方には言いづらい相談を受ける存在だ。

ある親方は「班全体で弟子を育てている感じ。地域全体で子供を育てている感じ」と表現していた。親方一人に閉じない育成の構造が、弟子にとっても親方にとっても、安心できる環境をつくっている。

親方自身の振り返りも欠かせない。弟子の課題を記録するだけでなく、「自分がこうすべきだった」という反省も残す。ある親方は「弟子が最近少し雑になってきたと思ったが、自分が雑になっていたと気がついた」と語っていた。弟子は親方の鏡でもある。

そして、師弟の関係は一代で閉じない。前回書いたように、物理的な近さを卒業しても、師弟の関係そのものは続く。一人前になった弟子がやがて自分の弟子を持つ。親方と元弟子の関係は、指導する側とされる側から、対等な仲間へと変わっていく。この連なりが、コミュニティの中に文化を伝える経路をつくっている。

うまくいかないこともある

弟子が辞めることはある。大半は入社して半年以内だ。

実際に働く親方やベテランの姿、一緒に入った弟子たちの成長を目の当たりにして、「自分にはできない」と感じてしまう。長く続けてから辞めるケースは多くなく、早い段階で辞めていく。

ただし、私はこれを「失敗」だとは考えていない。合わなかっただけのことであり、別の場所で活躍している人もいる。育成において失敗はない。

早く育つ人もいれば、大器晩成の人もいる。決まった正解がない仕事だからこそ、育成にも決まった正解はない。結果だけを見て「成功か失敗か」を判定するのではなく、プロセスに価値を見出す。これは、仕事を技芸として捉えることの核心と通じている。

棟梁としての経営者

徒弟制度において、私自身の役割は「棟梁」である。親方たちの親方だ。

親方たちとはほぼ毎週の定例ミーティングがあり、育成の悩みを一緒に考える。責任と権限は親方に渡す。しかし、それがうまくいくように全力でサポートするのが棟梁の仕事だ。

前回書いたように、伝統的な徒弟制度が敬遠されるようになった原因の一つは、親方に責任も権力もすべてを渡してしまったことにある。育て方もわからないまま、孤立した親方のもとで弟子が潰れていく。それを繰り返さないための最も大切な設計が、棟梁による支援体制なのだ。

徒弟制度を導入して、最も育ったのは親方たちだった。育成という答えのない問いに向き合い続けることで、親方自身の技芸も深まっていく。弟子を育てることが、組織の文化を育てることにつながっていた。これは始める前には想像していなかった成果である。

徒弟制度で弟子は育つ。親方も育つ。そして組織も育つ。弟子がいることで生まれる不安定さが、制度や仕組みを見直す機会をつくり、組織を強くしていく。コミュニティとして文化が伝承される。では、育った先に何があるのか。技芸をどう認め、どう報いるのか。結果で測れないものを、組織としてどう扱うか。次の記事では、その問いに向き合ってみたい。

参考記事

• 人を育てる仕組みから、組織を育てる仕組みへ〜現代に再発明した徒弟制度３年の学び
• 育成に必要なのは「観察」と「自己決定」
• 遊びから始まるプログラミング 〜 ハッカソンが育む文化と成長
• エンジニアリング的思考だけで人は育たない
• 「得るより、与える」〜人生後半に希望をもたらす指針
• 上司と親方の違い、徒弟制度の再発明でプログラマ育成
• 未経験から始めるエンジニアキャリアへの道

チャットは、人間が毎回指示を出し、AIが1回答える。AIは道具である。出力をコピペしたり、ファイルを保存したり、操作するのは人間の仕事だ。

エージェントは、人間がゴールと制約を渡し、AIが自律的にタスクを分解・実行する。操作もAIがやる。AIは実行者であり、人間はマネージャーの役割になる。

チャット的な使い方に留まっている人の特徴は「1回のやりとりで完結させようとする」ことではないか。より良いプロンプトを書こうとする時点でチャット思考である。エージェント思考は「雑に渡して、途中経過を見て、方向修正する」。

では、エージェントの先に何があるのか。

マルチエージェント、Computer Use、常駐型エージェント。これらはすべてエージェントの改善であり、チャットからエージェントへの変化に匹敵するパラダイムシフトではない。延長線上の進化である。

次の非連続な変化があるとすれば、「ナビゲーター」ではないかと考えている。

段階を整理するとこうなる。チャットは道具（聞けば答える）。エージェントは部下（ゴールを渡せば実行する）。

ナビゲーターは導き手（自分のすべてを知っていて、進むべき方向を示してくれる）。

ナビゲーターが成立する条件は、入力の質が根本的に変わることだろう。今のAIは人間が言語化したものしか受け取れない。

これからは、スマートウォッチやスマートグラスを通じた身体情報・環境情報・行動履歴が常時流れ込むことで、AIが「言語化される前の文脈」を持てるようになる。

加えて、コンピュータの操作を委譲することによって知的活動の前提——過去の思考、価値観、判断履歴——もすべて持っている状態になる。

パーソナルな情報の総体をAIが保持することで、「この人にとって何が最善か」を人間より正確に判断できる可能性がある。

ペアプログラミングのナビゲーターが機能するのは、ドライバーが行き先を決めている場合だ。カーナビは目的地を決めてくれない。しかし、パーソナルな情報をすべて持ったAIは「あなたは本当はこっちに行きたいのでは？」まで踏み込める。

うまくいけば誰もが幸せになる。だが、ナビされるままで本当に幸せなのかどうかは、わからない。

自分で迷い、自分で選ぶことの中にある価値が、ナビゲーションの快適さによって失われるかもしれない。これは技術の問題ではなく、人間の幸福とは何かという問いではないかな。

長期雇用と「自立」のスタンス

Q：ソニックガーデンは長期雇用前提で動いている？

基本的にはそう。若い人に限らず、全員「辞めない前提」でやっている。

ただ「辞めないでいてね」と言って大事にしすぎる、みたいなスタンスでもない。大企業だと「力をつけさせすぎると辞めちゃうから、あんまり自立させないほうがいい」みたいな考え方もあるけど、うちは真逆で、めちゃくちゃ自立させたい。「自立した人たちの集団」でありたいというのが大前提。

経営としてやるべきは、めちゃくちゃ自立した集団を作った上で、その自立した人たちが「なおここで働きたい」と思える環境を作ること。依存させて囲い込むのでもなく、自立させて「いなくなってもいい」でもなく。自立しているけど依存していない、けど「ここがいいな」と思ってくれている——その状態を作るのが経営の難しさであり、面白さだと思っている。

AI時代にプログラマーはどうなるか

Q：AI時代にプログラマーはいらなくなるのでは？

2つの話がある。

まず人数の話。1つのソフトウェアを作るのにかかる人数は減ると思う。でも、ソフトウェア自体の総数はもっと求められるようになる。今まで大企業が300人で1個のシステムを作っていたのが、3人でできるようになるかもしれない。100分の1。けど3人は残る。一方で中小企業は今まで1人さえ雇えなくて作れなかったのが、作れるようになってくる。1人のプログラマーで10社見れるかもしれない。トータルで見たらニーズはむしろ増えるんじゃないか。

次に「誰でも作れるようになるか」という話。技術的にはそうなるかもしれない。でも「作れる」と「作りたい」は別。私も経営者だから自分で作れるけど、自分のところのシステムを全部AIでやりますかと言ったら「いやそれは作れる人に任せたい」と思う。任せたいという人がいる限り、プログラマーは必要。

これは料理と一緒。各家庭にコンロも冷蔵庫もキッチンもあるのに、みんな外食に行く。普段の日常的なことはAIで効率化できるようになるかもしれないけど、「親戚20人呼んで法事やるからお母さん家庭料理で作りますか」となったら「お店行こう」となる。だから全部なくなるかというと、そこまで悲観していない。

職種で採用しない——仲間と農業しても楽しいか

Q：本当にプログラマーという職がなくなったらどうする？

うちは社員を職種で採用していない。ジョブ型ではない。ジョブ型は業務委託で外部の方にお願いしている。

社員の場合、職種の前に「ソニックガーデンの仲間であること」が先に来る。その職がなくなったとしても、別の職をみんなでやろう、という考え方。この世からあらゆるテクノロジーの仕事がなくなって「農業しかないぞ」となったら、今いる仲間と農業をやる。それは私たちなら楽しめるんじゃないかと思っている。

逆に「職を固定で行きたい」という人には「業務委託にしませんか」と提案する。社員として雇用するなら、ソニックガーデンに入ってほしい。やることは変化していくかもしれないけど、それをみんなでやろう、と思える人たちを入れている。

採用のスタンス——歓迎はするが迎合はしない

Q：師匠と弟子の採用プロセスで、途中で離脱するケースは？

1年半とかかけてお付き合いする中で「やっぱり違うかもね」となるケースはある。でも長くやるからこそ、そこでわかってよかったねとなる。

最近もあったのが、半年くらいいろいろやってみて、ご家庭の事情もあって「今じゃないね」とお互いなった。でも「今じゃないね」であって「合わないね」ではないから、「友達でいましょう」となって、今でも友達。

うちの採用はグラデーションで進む。友達から真剣交際に行って、同棲して、籍を入れるのはその先、くらいの感覚。一方的に会社が選ぶ・選ばないでもないし、応募者が一方的に選ぶ・選ばないでもない。

葛藤としては、こんなまどろっこしいことやっているので会社がすぐ大きくならないし人も増えない。でもハードルは絶対に下げない。うちの採用の言葉として「歓迎はするが迎合はしない」というのがある。来てくれる方はみんなウェルカムだけど、条件変えますとかお給料上げますね、みたいなことはしない。「違うね」ということは「違うね」となる。

会社の規模はコントロールできない

Q：人数を増やさなくていいという考え？

「増やさないでいい」とも思っていない。仲間が増えたらいいし、困っているお客さんも多い。人が増えて売上増えたらできることも増える。だから仲間集めるための取り組みはやる。けど結果増えなかったら「残念だったね」で終わる。

会社の規模はアンコントローラブルだと思っている。「来年100人行くぞ200人だぞ」と言ってできるなら、みんなやる。できないから悩んでいる。

これは子供の身長と同じで、「来月まで10cm伸びろ」と言って伸びるもんじゃない。できることは、健やかに寝て、ご飯食べて、勉強して、運動すること。それでも遺伝でそんなに伸びないかもしれないけど、しょうがない。コントロールできることだけにフォーカスする。

KPIもないわけではなくて、売上もコストもお客さんの数も全部見えるようにはしている。ただ、それを「目標の数字」にはしていない。

結果よりプロセスを大事にする

私たちが見るべき指標はいくつかあるけど、それを目標設定にしない。前提にあるのは「結果をコミットするために仕事しているわけではない」ということ。

ベストエフォートで頑張る。その結果はついてくるだろうし、ついてこなかったらしょうがない。順番として、やることの方を大事にしている。しかも結果よりも大事にしているのは「やることのプロセス」。プロセス自体が楽しく、やりがいがあるいいものでないといけないと思っている。

「結果ありきで手段は問わない」となると最悪のケースでは不正会計みたいなことが起きる。やっている人たちも「結果さえ出せば飲み会とか行かなくていいでしょ」となったら、本当にそれ楽しいか、という話。

私たちは「仕事をやっていること自体、仲間とコミュニケーションを取ること、仕事を通じて人生を豊かにすること」を価値観として大事にしている。仕事は面白いもんだという考え方でやりたいし、面白さのために腕を磨く。仕事を通じて知り合いも増える、友達も増える、助けてくれる人も増える。経済的にも豊かになれる。リッチであることではなくて、いろんなものが手に入っている状態こそが本当に豊かだろうと。この仮説を証明したくて会社をやっている、というところはある。

Tシャツピチピチ理論——等級は後追いでつける

Q：評価や報酬差はどうしている？

4〜5年前までは評価も報酬差も完全になし、フラットでやっていた。中途採用だけだったし、一定基準を超える人しか入れていなかったから。一定以上であれば、細かく差をつけるよりフラットにしたほうが運用上いい。

ただ弟子を採用するようになって、さすがに一緒にするのはおかしいだろうとなった。ベテランはコストよりパフォーマンスが上回っている。弟子はまだ逆。足りない部分は親方が補っていて、その分のコストがかかっている。だから弟子のところには階段を作った。

等級の考え方は「キャリブレーション」と呼んでいる。「今この人にどういうことができるのか」の期待値を見て、実態に合ったロールを決め、ロールに紐づいた報酬を出す。

大事にしているのは「先に上げない」こと。よくある会社だと、ここができるようになったら「じゃあ次に上げましょう」となる。でもそれがピーターの法則を生む。上がったけどできない、みたいなことが起きる。

うちは逆で、「ここができるなら、ここの報酬でずっと行きましょう」とする。放っておいても人は成長する。仕事の機会はどんどん増やすし、どこにいても仕事の制限はない。どんどん難しいことをやっていった結果、できることが大きくなる。それを見て「この人こんなに大きくなっているのにこの等級に置いておくのはアンバランスだね」となったら、実態に合わせて等級を上げる。後追い。

これを「Tシャツピチピチ理論」と呼んでいる。子供にぴったりの服を着せて、体が大きくなってピチピチになってきたら、ワンサイズ上げる。最初からブカブカの服を着せない。

弟子の階段は、若い人ほど細かく刻んでいる。ゲームでもレベルが低いうちは上がりやすいのと同じ。多分4〜5段階はある。最先端の弟子に合わせて階段を伸ばしていく感じだけど、まだフラットなベテラン水準には到達していない。

一人残業禁止

Q：リモートワークでオーバーワークは起きない？

ベテランはほぼ在宅でご家族と一緒にいるので、実は働きすぎにくい。6時過ぎになると「ご飯なので終わります」と言ってみんないなくなる。通勤がないからすぐ家族と過ごし始めて、そこからまた仕事に戻る人はほぼいない。一人暮らしリモートだと危ないかもしれないけど、ベテランはそういう人が多い。

弟子は親方が見ている。どれくらい働いているかのダッシュボードがあるし、残業するなら親方に許可を取るルールにしている。あと「ラクロー」という仕組みを入れていて、GitHubやGoogle Docsなどのログから夜中働いていたら「あなた残業してたでしょ」とコンピューターが教えてくれる。もともとうちの社内新規事業から生まれたサービスで、変なサービス残業が発生しない仕組みにしている。

で、もう一段やりたいと思っているのが「一人残業禁止」。残業するなら必ず二人以上で。クライアントワークなのでどうしても残業が発生するタイミングはある。その時に一人でやるとただ辛い。でも二、三人で「大変だね」と言いながらZoomで繋いでやって、終わった時に「お疲れ様」と言い合えたら、それは思い出になる。

自分の過去を振り返っても、一人で残業してた記憶はほぼないけど、先輩と徹夜して深夜に部長が差し入れ持ってきてくれた、みたいなことは思い出になっている。コストは残業代が二倍になるけど、得られるメリットを考えたら大した額じゃない。

思い出に投資する

豊かさとは何かと考えた時に、BSがめちゃくちゃいい会社は「儲かっている」とは言うけど「豊か」とは言わない。個人でも資産をめちゃくちゃ持っていても、誰とも話ができない状態になったら「金持ちだけど豊かではない」。

豊かさのいくつかある要素の1つが「思い出がいっぱいあること」じゃないかと思っている。思い出がたくさんあるほうが「まあこういう人生だったな」と思えるし、もっと良いのは「思い出を共有できる相手がいる」こと。

だから今、会社で思い出をいっぱい作ろうとしている。そのためにけっこうお金をかけている。

全社員合宿を年2回やるようにした。うちは沖縄から各地に散らばっているので、交通費だけで目玉が飛び出る額になるけど、やったほうがいいと判断した。

去年は「ハケーション」もやった。ハッカソンとバケーションを合わせたやつで、5〜6人のグループで好きなリゾート地に行って、ハッカソンした翌日にバケーションで遊ぶ。全部経費。一緒に働いている人たちの思い出が増える。

BSは傷つくしPLにも影響するけど、まあいいかと思っている。

いいソフトウェアとは何か

Q：組織の中を豊かにすることと、外向きの成果の両立はどう考えている？

お客さまのことはとても大事にしている。経営理念に「一緒に悩んで、いいものつくる」と入れているぐらいだし、月額定額モデルなので成果出せなかったら翌月切られる。ちゃんとパフォーマンスは出す。

ただ、お客さまのために私たちがすり減ることはしない。「良い仕事をする」時に、お客さまとは一緒に悪巧みしている仲間みたいな関係でやっている。社内でやっている遊びや合宿を、お客さんにも拡大してやることもある。

私自身は直接クライアントワークしているわけではなくて、社員の皆さんと仕事している。私からすると社員はお客さまみたいなもの。「倉貫株式会社」が一人でやっているんだとしたら、この会社の顧客はソニックガーデンの社員の皆さん。その人たちを幸せにしたいと思っている。

経営理念に「いいソフトウェアをつくる」というのがあるけど、いいソフトウェアとは何か。機能がいいとか品質がいいとかいろいろあるけど、私が考えている本当にいいソフトウェアは「作る人と使う人が幸せであること」。

ユーザーが不便だと思っているならいいソフトウェアじゃない。でもユーザーが喜んでいても、作る人がめちゃくちゃ疲弊していたら、それもいいソフトウェアとは言えない。作る人——私たちのお客さんと私たち自身——と、使う人の両方が幸せじゃないといけない。

この定義がすべてに繋がっている。迎合しない話も、すり減ることをしない話も、全部ここから来ている。自分たちが幸せじゃないとダメなんだから。

前回の記事の末尾で、こう書いた。「まだセルフマネジメントに至っていない人をどう迎え入れるか」。創業から十年、セルフマネジメントできる人だけで組織をつくってきた私たちが、次に向き合うことになった問いである。

技芸を磨き続けるコミュニティを維持するには、新しい仲間を迎え入れなければいけない。しかし、最初からセルフマネジメントできる人だけを待っていたのでは、いつか限界が来る。未経験の若い人たちを迎え入れ、技芸を伝えていく仕組みが必要だった。

その答えとして私たちが選んだのが、「徒弟制度」だった。

技芸の育成は可能なのか

そもそも、技芸は育成できるのだろうか。

以前の記事で書いたように、技芸は勉強して身につくものではない。「わかる」と「できる」は違う。知識を得ただけではできるようにならない。練習や鍛錬を重ねて、身体で覚えていくものだ。ソフトウェア開発で言えば、状況に応じた判断、設計の美しさに対する感覚、お客さまとの対話から本質を見抜く力。こうしたものは、研修で教えられるものではなく、実践の中で磨いていくしかない。

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

鍛錬が必要だが、自己流では育ちにくい。フィードバックが必要だが、誰がそれを担うのか。では、どうすればいいのか。

この問いに対する私たちの仮説が、徒弟制度だった。

なぜ「徒弟制度」なのか

技芸の腕を磨くために必要なことは、突き詰めると三つだと考えている。

一つ目は、できる人のプロセスを間近で見ること。成果物だけを見ても、技芸は伝わらない。どう考え、どう迷い、どう判断したか。そのプロセスにこそ技芸が宿る。

二つ目は、自分で実践すること。見ただけではできるようにならない。自分の手で試行錯誤し、プロセスを体験することで、初めて身についていく。

三つ目は、実践を見てもらい、フィードバックをもらうこと。自分では気づけない癖や盲点がある。良いのか悪いのか、どこを直すべきか。技芸には審美眼が必要であり、審美眼を鍛えるには「いったん絶対の正解とする存在」が欠かせない。自分なりの判断基準を持つのは大切だが、最初からそれができる人はほとんどいない。まずは師匠の基準を内面化し、その上で自分の審美眼を磨いていく。

この三つを実現するには、教える側が弟子より高い実力を持ち、弟子の仕事のプロセスを観察してフィードバックできる関係が必要になる。一般的な会社における上司と部下の関係では、これが難しい。

上司と部下の関係では、「成果を出させること」が目的になる。プロセスに時間をかけることは、短期的な生産性と衝突する。上司に求められるのは部下の話を「聴く」ことだが、技芸の育成に必要なのは仕事のプロセスを「見る」ことだ。結果ではなく、仕事の仕方そのものに対して、実力のある先達がフィードバックする。

この関係は、上司と部下ではなく、師匠と弟子だった。師匠と弟子の関係なら、プロセスそのものが育成の場になる。成果が出るまでに時間がかかることも、当然のこととして受け入れられる。

宮大工の『棟梁』からの着想

徒弟制度という言葉を使い始めたのには、きっかけがある。宮大工の小川三夫さんが書いた『棟梁』という本を読んだことだ。小川さんは、薬師寺金堂の再建を手がけた西岡常一棟梁の最後の内弟子である。西岡棟梁のもとで学んだ後に独立し、自ら「鵤工舎（いかるがこうしゃ）」という工房を立ち上げ、若い宮大工を育ててきた。

良いプログラマが育つ環境とは何か。その問いを考えていたとき、この本に出会った。宮大工の世界では、親方が弟子に技を伝え、弟子は親方の仕事を間近で見て学ぶ。知識を教えるのではなく、仕事そのものを通じて技を伝承していく。「言葉で教えられないから弟子に入ってくるんや」という小川さんの言葉が印象的だった。

小川さんは「育てる」と「育つ」は違うと言う。自分で自分を育てる。その環境と機会を与えるのが人育てだ、と。弟子たちは共同生活をしながら、寝ても覚めてもそのことしか考えない時期を過ごす。そうやって技が身体に染み込んでいく。

プログラミングと宮大工の仕事は、一見まるで違う。しかし、技芸を身につける構造は同じだと感じた。「上司と部下」ではなく「親方と弟子」。その言葉の方が、私たちがやりたいことにしっくりきた。

実際、呼び方を変えただけで関係性が変わった。もともとは「マネージャー」と呼んでいたが、どこまで強くフィードバックしていいのか迷いがあったし、部下の側もどんな心構えでいればいいのかわからなかった。「親方と弟子」にしたことで、弟子は「まず学ぶ」つもりになったし、親方も「まず育てる」つもりで向き合えるようになった。名前が、期待と認識を揃えたのだ。

再発明した徒弟制度

ただし、従来の徒弟制度をそのまま取り入れたわけではない。従来の徒弟制度には問題があった。親方に責任も権力もすべてが渡され、育て方もわからないまま弟子が潰れていく。それが、伝統的な徒弟制度が敬遠されるようになった原因の一つである。

私たちが導入したのは、現代に合わせて再発明した徒弟制度だ。従来との違いをいくつか挙げてみたい。

「背中を見て学べ」とは言わない。教えるべきことは教える。放置はしない。ただし、最初から自分なりのやり方を求めるのではなく、まずは親方と同じやり方を身につけてもらう。一つの流派として教えられる型があるからこそ、徒弟制度が成り立つ。

親方に最も求められるのは「見る」ことだ。弟子が実践したものを見て、フィードバックする。口を出しすぎると親方のアウトプットになってしまう。口を出さずに見ることで、弟子のボトルネックが発見できる。この「見る」が、親方の核心的な仕事である。

仕事に通じない雑用はない。私たちはソフトウェアの会社だから、デジタルでできる雑用はすべて自動化されているか、必要であれば自動化すること自体が仕事になる。下働きで修行するような構造ではない。

そして、親方ひとりに責任を負わせない。親方が弟子を育てられるように、会社全体で支援する。私自身が親方たちの棟梁のように寄り添い、一緒に悩む。従来の徒弟制度の失敗を繰り返さないための、最も大切な設計だと考えている。

セルフマネジメントへの道

前回の記事で描いたのは、セルフマネジメントできる人たちが自由に働く世界だった。弟子たちの現実は違う。親方の近くに引っ越す。毎日オフィスに通う。仕事の進め方を見てもらう。自由とは言い難い環境である。

しかし、それはセルフマネジメントの思想を捨てたのではない。

セルフマネジメントできる人たちで組織をつくると、誰かが個々人をマネジメントする必要がない。しかし、セルフマネジメントがまだ足りない人もいる。足りていない部分を誰かが補ってあげることで、パフォーマンスが出る。一般的な会社では、それがマネージャーの役割だ。ソニックガーデンでは、それが親方の役割である。

マネージャーと親方の違いは、目的にある。マネージャーは管理して成果を出させることが目的だ。親方はセルフマネジメントできるように育てることが目的である。だから、親方の仕事は、自分の役割をなくすことだとも言える。弟子がセルフマネジメントできるようになれば、前回描いた自由な世界に合流する。

弟子にとっての不自由は、永遠ではない。「いつかセルフマネジメントできるようになって、自由を得る」ためのプロセスなのだ。前回の記事で描いた世界は、ゴールとして存在し続けている。

親方ハウスというプロセスを見るための場

技芸の育成にはプロセスを見ることが不可欠だと書いた。しかし、ソニックガーデンにはオフィスがない。全員がリモートワークで働いている。オンラインミーティングはできるが、その前後の様子まではわからない。

そこで、一度オフィスをなくした会社が、今度は育成のために改めてオフィスを用意した。ただし本社ではない。親方が住んでいる家の近くにオフィスを構えた。これを私たちは「親方ハウス」と呼んでいる。

なぜ親方の家の近くなのか。親方たちはもともとリモートワークで在宅勤務をしていた。親方になったからといって、公共交通機関を使った通勤が発生するのは、私たちの思想にはあわない。だから親方が会社に通うのではなく、弟子が親方のもとに引っ越す形にした。親方は自宅から徒歩圏内のところにオフィスを構える。沖縄から愛知県瀬戸市に移住してきた弟子もいる。

同じ時間と空間にいることの効果は大きい。軽い雑談がしやすい。親方と弟子の会話を、別の弟子が自然と耳にする。弟子同士が同じ場所にいることで、親方との関係だけに閉じない。一緒にランチを取ることで信頼関係が築かれる。定量的な効果を示すことは難しいが、実感として大きい。

では、弟子はいつまで親方ハウスに通うのか。セルフマネジメントができるようになれば、リモートワークに移行できる。リモートへの移行時期は画一的なルールではなく、親方が見極める。ただし、物理的な近さを卒業しても、師弟の関係そのものは続く。弟子が四十歳になっても五十歳になっても、自分の師匠は誰か、自分の弟子は誰かという関係は連綿と続いていくものだと考えている。

なぜジュニアを育てるのか

ここまで読んで、「なぜわざわざ未経験の若い人を育てるのか」と疑問に思う人もいるだろう。経済合理性だけで考えれば、未経験者を一人前に育てるには五年から六年かかる。即戦力を採用した方が、はるかに効率がいい。

実際、多くの会社はそう判断している。特にAI時代に入り、コーディングがAIで代替できるようになると、ジュニアの育成に投資する経済合理性はさらに低下する。

私たちも、創業から十年ほどは中途採用だけで会社を運営してきた。しかし、社員が辞めずに腕を磨き続ける会社なので、社内の水準がどんどん上がっていく。すると中途採用で求める基準も一緒に上がり、市場で採れる人が少なくなっていった。

振り返ってみれば、他社が時間とコストをかけて育てた人たちを、私たちが採用してきたということでもある。育成のコストを自分たちでは負担してこなかった。業界全体を見ても、実践経験を積める場は圧倒的に不足している。

であれば、今度は自分たちでしっかりお金をかけて人を育てるべきではないか。それが若い人を採用しようと考えた最初のきっかけだった。

しかし、理由はそれだけではない。

技芸の伝承がなければ、コミュニティは一代で終わる。今いるメンバーだけで回し続けることはできても、技芸を次の世代に伝えなければ、文化は途絶えてしまう。技芸を伝え、文化を育てることは、コミュニティとしての社会的な使命だと考えている。

そして、実際に育成を始めてみると、思わぬ副産物があった。若い人がいることで組織は不安定になる。不安定になるということは、制度や仕組みをしっかり考え直す機会が増えるということだ。それが組織を強くする。

そして何より、弟子を育てるという一筋縄ではいかない仕事に日々向き合うことで、親方たち自身が人間的にも技術者としても成長していく。育成は、コストではなく投資だった。

経済合理性だけでは説明しきれない。しかし、経営者として人生の後半に差しかかり、「得るより、与える」ことに意味を感じるようになった。「いいソフトウェアをつくる」という理念に基づけば、次の世代を育てることは自然な選択だった。

次の記事では、徒弟制度の中で具体的にどう育てているのか。全体と部分の育て方、親方たちが実践の中で得た学び、そしてうまくいかないケースも含めて書いてみたい。

参考記事

• 人を育てる仕組みから、組織を育てる仕組みへ〜現代に再発明した徒弟制度３年の学び
• 親方のそばで育つためのオフィス
• NHKの番組「笑う会社革命」にて「徒弟制度」が紹介された経緯と裏側
• 『棟梁 〜技を伝え、人を育てる』の感想
• 上司と親方の違い、徒弟制度の再発明でプログラマ育成

なんだか懐かしい感覚があった。この感覚は何だっけ？と思ったけど、これはペアプログラミングしてたときの感覚だ。しかも、ドライバーではなくナビゲーター（助手席）にいるときの感覚。

出来上がっていくものを見て、あれこれ言う感じ。適度に意見を交わしたりしながらも、こちらはキーボードは触らないで、出来上がっていく。

AIとペアプログラミングもとい、ペアワークしてたのか。生産性が高まるわけだ。

人間のペアとの違いがある。AIは疲れない。だからずっと続けられる。思考時間はかかるが、それは相手が人間でも同じ。AIを相手にするなら、同時に何人？ものAIとは並行でやりとりできるし、失礼には当たらない。限界は人間側にある。

そして、今まで始めるまでが億劫だったものも、相手がいるからか始めやすくなった。「始めやすい」の中身は二つある。一つは、一緒にやる人がいたらサボれないのでやれるということ。

もう一つは、いきなり成果物に向かわずに、会話から始められるということ。会話から入れるのは単に気楽だからという話だけではなくて、会話すること自体が思考の整理であり設計行為になっている。

ペアプロでもコードを書く前に「これから何をやるか」を口頭で確認するプロセスがあった。あれは雑談ではなく設計だった。AIとのチャットでも同じことが起きている。ザッソウ（雑に相談すること）で考えがまとまっていく、あの感覚。

ナビゲーターとして人間がしていることは、方向性を示す、間違いに気づく、一歩引いた視点で全体を見る。これはAIが相手でも人間が相手でも変わらない。ドライバー（コードを書く側）がAIに替わっても、ナビゲーターの仕事はそのまま残る。

AIの生産性に対して、人間はレビューだけするようになるという言説もあるが、ペアワークをしていると、ペアプログラミングで言われるメリットと同じでAIが書き込む瞬間に一緒にレビューしている状態になる。そうなると、レビューしているという感覚ではなく、共同作業をしていると感じる。

その状態が続くから、レビューだけでつまらないということはない。そして、AIが作って、自分が作った感が無いという問題も解消される。ペアワークでは、AIとの共同作業なので、これは自分で作った感覚は残る。

一方で、AIとのペアワークには「終わらない」という問題がある。ミーティングなら時間がきたら終わるし、相手を拘束するのも悪いから区切りがつく。だけどAIはずっと付き合ってくれる。

AIは「疲れない」というメリットの裏面として、際限なく続けてしまうリスクがある。強制的に仕事以外の時間を作らないと、身体を壊す。

対処として、仕事が終わったら終わる、ではなく、カレンダーに仕事以外の予定を先に入れてしまう。ジムにいく、本を読む、散歩にいく。仕事の終了を成果ではなく時間で区切る。時間割で働く。これが本当のワークライフバランスかもしれないな。

ここ数年は、「仕事は必要悪だ」「仕事は減らすべきだ」。そんな空気が当たり前になっています。でも、本当にそうでしょうか。

一方で、ビジネス系のコンテンツは人気を増しています。それなのに、「仕事がおもしろい」という声はあまり聞こえてこない。この不思議なねじれの中に、見落とされている領域があるように思います。

この記事では、「仕事はおもしろい」がなぜ語られにくいのか、その構造を整理しながら考えてみます。

お金しか残らない仕事と、体験が残る仕事

仕事をしても、残るのはお金くらいのもの。そう感じている人は少なくないのではないでしょうか。

大きな事業の中で、分業された一部分だけを担う仕事。自分が何のために手を動かしているのか見えにくく、全体の成果を実感できません。お金は入るけれど、何かが消耗していく。その仕事が悪いわけではなく、構造的に仕事のおもしろさを感じにくい状態に置かれてしまっているのです。

そういう仕事であれば、結果だけ効率よく得たいと考えるのは当然のことだと思います。コスパやタイパを求めるのもわかります。人間関係だって煩わしいだけでしょう。「仕事は減らすもの」「仕事は必要悪」という風潮は、こうした経験から来ているのだと思います。

しかし、それとは別の世界があります。

最初から最後まで自分で手がけて、プロセスそのものに充実がある仕事。終わった後に、お金だけでなく、経験や技や手応え、豊かな人間関係や思い出が自分の中に残る仕事です。そういう仕事が、この世の中にはあるのです。

「仕事が充実している」と言えない空気

こんな話を聞いたことがあります。仕事に夢中で取り組んでいる若い人が、友人との食事の場で趣味や遊びの話をしている中で、「自分は仕事でこういうことに充実している」と話したら、かわいそうな目で見られた、と。そういえば私の若い頃にもありました。

趣味で充実しているのはいいのに、仕事で充実しているのはなぜダメなのか。

ワークライフバランスという言葉は、もともと仕事と生活の両方を充実させようという考え方だったはずです。しかしいつの間にか、「仕事は悪いもの」「仕事は減らすべきもの」という意味に変質してしまっています。とはいえ、仕事をゼロにはできません。そうであれば、仕事をつらいものとして耐えるより、おもしろいものとして取り組めた方が良いと思いませんか。

「お金しか残らない仕事」しか知らなければ、そう思うのも無理はありません。でも、仕事には別の姿もあるのです。

「仕事のプロセス」を語る人がいない

ビジネス系の動画やノウハウ本は、相変わらず人気があります。みんなビジネスの話が嫌いなわけではありません。

しかし、そこで語られているのは「成果を出すためのハック」「年収を上げるノウハウ」が中心です。結果を効率よく得るための攻略法です。書籍の要約サービスが流行るのも同じ構造で、本を読むプロセスを楽しむのではなく、結果としての知識を効率よく手に入れたいから要約で済ませてしまうのでしょう。

仕事も本も、プロセスをすっ飛ばして結果だけ取りに行く。これが今の時代の基本姿勢になっています。

しかし、ゲームをしていてエンディングだけを目的に遊ぶ人はいません。旅をしていて、目的地に着くことだけを目指すのは味気ないでしょう。プロセスそのものに楽しさがあることを、本当はみんな知っているはずです。なのに、仕事になると途端にそれを忘れてしまう。

「仕事のプロセス自体がおもしろい」という声はあまり聞こえてきません。しかし本当に大事なのは、まさにそこではないでしょうか。結果ではなく、やっていること自体に喜びがある、という話です。

ぽっかり空いたポジション

世の中の言説を「結果志向か、プロセス志向か」と「仕事か、生活か」の二軸で整理すると、四つの象限が見えてきます。

「結果志向×仕事」は、稼ぐために働く世界です。結果がすべて。極端に言えば、結果さえ得られるなら仕事そのものはなくしたいとさえ思っているように見える。

「結果志向×生活」は、効率よく生きるライフハック的な暮らし。「プロセス志向×生活」は、丁寧な暮らしやスローライフで生活自体に喜びを見出している。

そして「プロセス志向×仕事」——いい仕事をする、遊ぶように働く。この象限が、ぽっかり空いているように見えます。

仕事から離れたい人が向かう先は、たいてい「丁寧な暮らし」や「スローライフ」の方向です。しかしそれは、仕事というものを「結果を追うだけの消耗戦」としか捉えていないからではないでしょうか。仕事に対する解像度を上げれば、プロセスを大事にする「いい仕事」という領域があることに気づきます。

仕事自体を楽しむ。この当たり前のようで誰も語っていないポジションこそ、倉貫書房が届けたいメッセージの居場所です。

セロトニン的なおもしろさ

結果を追うおもしろさも、もちろんあります。数字が伸びる快感、競争に勝つ高揚感。ただそれは、中毒性のあるアッパー系の快楽です。アドレナリン的なおもしろさと言ってもいいかもしれません。

ここで言いたいのは、それとは違うおもしろさです。じわーっと、ずっと続くおもしろさ。仕事に没頭しているときの静かな充実感。セロトニン的なおもしろさです。

「おもしろい」という言葉を使うと、どうしてもアドレナリン的な方に理解が引っ張られてしまいます。だからこそ、この違いをちゃんと言葉にしなければいけないと思っています。

効率化の先にある仕事

ここまで読んで、「プロセスを大事にするとは、のんびりやるということか」と思われるかもしれません。それは違います。

私たちの会社でも、効率化にはずっと取り組んできました。その中で気づいたのは、やり方を速くすることよりも、やらなくていいことを見つけてやめていくことの方が大きいということです。どれだけ効率的にやっても、そもそも不要なことをやっていれば意味がありません。「これは本当に必要か」を問い続けて、やらないことを増やしていく。そうすることで、さらに効率化されていきます。

背伸びをして、赤字を掘ってでも売上を拡大するようなことはしません。身の丈の中でベストを尽くす。外への膨張ではなく、内側を研ぎ澄ませる。その違いです。

効率化は、仕事のプロセスを楽しむための前提条件でもあります。無駄な作業に追われていたら、仕事をおもしろいとは思えません。効率化した先にこそ、仕事そのものに向き合える時間が生まれるのです。

「仕事はおもしろい」を届けたい

世の中には、仕事がおもしろいと思っている人がたくさんいます。でも今は、それを堂々と口にしづらい時代です。マイノリティになってしまっているように感じます。

その人たちが読んで、少しでも勇気づけられるものを作りたい。仕事がおもしろいと感じている人には「自分はおかしくなかった」と思ってもらえるように。仕事がつまらないと感じている人には「こんな考え方もあるのか」と知ってもらえるように。そんな思いで、倉貫書房を立ち上げました。

倉貫書房の最新刊は、仕事エンタメ小説シリーズ第二弾『新米マネージャー、最悪な未来を変える』（長瀬光弘著）です。新しくマネージャーになった主人公が、チームとの向き合い方に悩みながら成長していく物語です。ビジネス書ではなく小説という形で、仕事のおもしろさを届けたいという思いで刊行しています。

それが今では、エージェントとして人間の代わりに仕事をしてもらう段階に入っている。実際に使っていると、よほど頭のいい人と一緒に仕事をしている感覚。

大げさではなく、「新しい人類が来ている」という実感がある。

AIの話になると、多くの人が「人間は人間の得意なこと、AIはAIの得意なこと」と言う。棲み分けの発想だ。

しかし私は、そう楽観的には考えられない。人間にできることは、いずれAIにもできるようになるのではないか。

棲み分けようとすれば、AIの領域が広がるたびに居場所を明け渡していくだけだ。いずれレジスタンスのように抵抗するだけになる。それは得策ではない。

歴史を振り返ってみると、原始時代から中世にかけて、世界を支配していたのは武力だった。

力が強い者が支配した。武力なしには国も領土も守れなかった。身体の力こそが価値だった時代。それを変えたのが銃の登場だ。人間の筋力では対抗できないものが現れた。機関車や自動車もそう。

力そのものではなく「力をどう使うか」が問われるようになった。武力の時代から知力の時代への転換。

現代社会では、どれほど腕力が強くても、それだけで評価されることはない。身体の力は、かつての圧倒的な価値を失った。同じことが、今度は知力に起きようとしている。

AIは、そんじょそこらの頭のいい人より頭がいい。筋肉より強い銃が出てきたのと同じ構造ではないか。知力で戦おうとしても勝てないものが出現した。

知力だけを武器にしていた人が、かつて武力だけを武器にしていた人と同じ位置に立たされるのではないか。知力そのものの価値が、武力と同じように相対化される時代。

AIによる変化を、IT革命や産業革命と同じレベルで語る人が多い。私はもっと大きな括りだと考えている。

武力から知力への転換と同じスケールの、時代そのものの移行。「仕事が効率化される」「一部の仕事がなくなる」といった話もあるが、そのレベルではない。社会の根本的な価値観が変わるのではないかと思っている。

私たちが生きているうちに来てしまう変化だと思う。

武力の次に知力が来た。では、知力の次には何が来るのか。

正直なところ、まだ答えは出ていない。ただ、少なくとも知力だけに頼る時代は終わりつつある。日々AIと仕事をしていて、それだけは強く感じている。

前回の記事で書いたように、ソニックガーデンはチームではなくコミュニティだった。そのコミュニティに人が集まってきた後、最初に直面したのは「この人たちをどうマネジメントするか」という問いだった。

一般的な会社であれば、人が増えたら組織図をつくり、管理職を置き、評価制度を整え、ルールを増やしていく。それが当たり前だと思っていた。しかし私たちは、その当たり前をほとんどやらなかった。やらなかったというより、やる必要を感じなかったのだ。

最初から設計していたわけではない。ただ、振り返ると、技芸が育つ場にはいくつかの条件があった。管理をしなかったこと、採用に時間をかけたこと、仕組みで守ったこと、属人性を活かしたこと。一つずつ振り返ってみたい。

管理がない会社

ソニックガーデンには、一般的な会社にあるものの多くがない。

売上目標がない。管理職がいない。経費の決裁がない。上司への報告経路がない。指示命令がない。予実管理がない。オフィスもない。働く時間も場所も、各自に任されている。

こう並べると、会社として成り立つのかと思われるかもしれない。私自身、大企業で働いていた頃の感覚からすれば、信じられない光景だと思う。しかし、これが私たちの日常である。

では、この組織はどう動いているのか。

答えはシンプルで、一人ひとりが自分で考えて動いている。お客さまの現場に入ったプログラマは、自分で判断し、自分で仕事を進める。経費が必要なら自分の判断で使う。休みを取りたければ自分で調整する。誰かの許可を待つ必要がない。

ただし、これは放任とは違う。自由に動いているように見えて、全員が「いいソフトウェアをつくる」という同じ方向を向いている。技芸を磨き続けたいという意志を共有している。だから、バラバラにならない。『管理ゼロで成果はあがる』にも書いたが、管理をなくすことと放任は全く違うのだ。

私たちが目指してきた働き方を一言で表すなら、「遊ぶように働く」になる。仕事に没頭し、楽しみ、こだわり抜いている姿が、傍から見ると遊んでいるように映る。そういう状態のことだ。仕事を技芸として生きる人の、一つの理想形だと思っている。

お客さまとの打ち合わせも、ソフトウェアをつくることも、仲間といっしょにトラブル対応をすることも、侃侃諤諤の議論さえも、どれも遊ぶように働いている。ハッカソンのような遊びの場だけの話ではない。日常の仕事そのものが、そうなのだ。

技芸的な仕事は管理できない

管理をしなかったのは、理念が先にあったからではない。プログラマとして働いてきた中で、管理がなくても良い仕事はできると実感していたからだ。

私自身、プログラマとして最も高い生産性を発揮できたのは、自らの意思で「もっと良くしたい」と思えたときだった。そのプロダクトが自分の作品のように感じられたとき、満足のいくまで取り組みたいと思ったし、誰かに管理されなくても一生懸命に頑張った。

ソフトウェア開発は再現性のない仕事である。同じプログラマが同じ機能をつくっても、まったく同じコードにはならない。毎回が一回きりの設計であり、創造である。再現性がないからこそ、個人の腕が問われる。そこに技芸が生まれる。そして、技芸を磨くのは、本人の内側から湧く意志だけである。

再現性のない仕事では、品質も生産性も頭の中で起きている。外側から監視しても見えないし、細かい指示命令も不可能である。良い仕事を引き出すために最も重要なのは、本人のやる気なのだ。であれば、外発的な動機づけは極力なくした方がいい。誰かにマネジメントされるのではなく、自らをマネジメントする。これが、私たちが管理をしなかった本質的な理由である。

もちろん、管理がないからといってマネジメントがないわけではない。私は、マネジメントとは「いい感じにすること」だと考えている。会社経営とは、会社をいい感じにすることに責任を持つ仕事である。管理は、マネジメントの手段の一つに過ぎない。成果が出せるのであれば、管理という手段を使う必要はないのだ。

採用が場をつくる

管理なしで組織が成り立っていたのは、偶然ではない。採用に時間をかけていたからである。

創業から十年くらいの間、私たちはセルフマネジメントができて、かつ高いパフォーマンスを発揮できる人だけを採用していた。スキルがあるかどうかだけではない。自分で考えて動けるか。仲間と協力できるか。技芸を磨き続ける意志があるか。そうした人物像を見極めるために、採用には一年から二年をかけることもあった。

長い時間をかけて互いを知る過程で、信頼関係も自然と築かれていく。入社した時点で、すでに仲間としての土台ができている。だから、管理がなくても組織として動ける。

「採用基準を厳しくすれば管理はいらなくなる」。これは一つの結論ではある。しかし、最初からそう考えていたわけではない。理想を掲げて実践していたら、そういう人が集まってきた。そして、そういう人たちだから管理が必要なかった。順序が逆なのである。

この採用の姿勢について、私たちは「歓迎するが、迎合しない」と表現している。応募してくれる人を歓迎する。しかし、来てもらうために基準を下げたり、条件を交渉したりはしない。それをやると、コミュニティの文化が壊れてしまう。

管理すべきは人ではなく仕組み

管理のない組織がうまくいっていたのは事実だが、問題がなかったわけではない。

創業から五、六年目の頃、大きなセキュリティ事故を起こしかけたことがある。セルフマネジメントできるメンバーが、それぞれの意識で対応していた。しかし、組織が大きくなるにつれて、個々人の意識だけでは全体を網羅できなくなっていた。抜け漏れが発生したのだ。

緊急事態として、私をリーダーに期間限定の対策チームを立ち上げた。指示命令と情報共有を明確にして、ほぼ全社員で対応にあたった。調査の結果、実害には至らなかった。全社員がお客さまへの説明を担当し、むしろ全員の結束が強まった。

振り返ると、このエピソード自体が、管理のない組織だからこそ自発的に動けたことの証でもあった。指示を待っている人はいなかった。全員が自分ごととして対応した。

ただし、このとき学んだことがある。全員の好意と努力に頼りすぎていたのだ。網羅が必要なことに関しては、管理の仕組みが必要だった。

対策として、情報セキュリティチームを組成し、責任者を置いた。経営として支援する体制を整えた。その後、労務管理についても同様に仕組み化を進めた。ただし、管理しているのは一覧やチェックリストであり、人ではない。個々のメンバーには引き続きセルフマネジメントで取り組んでもらう。

管理すべきは事象や仕組みであって、人や成果ではない。仕組みは仕組みとして整え、人の創造性は自由にしておく。こうして、自由な働き方を維持しつつ、堅牢な組織になっていった。

属人性を排除しない

管理のない組織をつくる過程で、もう一つ意識的に選んだことがある。属人性を排除しなかったことだ。

一般的な組織論では、属人性は問題とされる。手順を標準化し、マニュアルをつくり、誰がやっても同じ結果になるようにする。私がいた大手SIerでは、開発工程やドキュメントのフォーマットを統一し、属人性の排除が徹底されていた。

しかし、「誰でもできる」は「誰がやっても同じ」でもある。標準化された手順に従うだけの仕事を、面白いと思える人はいない。人のやる気を奪い、創造性を殺してしまう。人を交換可能な部品のように扱えば、その人が成長することはない。

ソフトウェア開発のような再現性のない仕事では、品質を左右するのは個人の判断や感性や経験である。技芸の文脈では、属人性こそが価値だ。技芸は本質的に属人的なものなのである。だから、私たちは属人性を排除するのではなく、属人性を活かす場をつくることにした。

とはいえ、一人だけに依存してしまうのは問題である。その人が休めなくなるし、組織としても脆い。そこで私たちは、システム開発の考え方を借りることにした。「属人性の排除」ではなく「単一障害点の排除」である。

システムの世界では、一箇所が壊れても全体が止まらないように設計する。同じ発想を組織に当てはめた。小さなチームで助け合い、情報はオープンにし、繰り返しの作業はシステム化する。そうすれば、個人の創造性を活かしながら、一人が休んでも仕事は止まらない。

属人性を排除して全員を均一にするのではなく、個人の強みを活かしたまま、単一障害点だけをなくす。これもまた、技芸を磨く場をつくるための大切な考え方だと感じている。

技芸を磨く場を支える仕組み

ここまで読んで、「そこまで自由なら、フリーランスでいいのではないか」と思われるかもしれない。確かに、自由さだけならフリーランスの方が上かもしれない。しかし、フリーランスは自由だが孤独でもある。一方、従来の会社は安定しているが不自由なことが多い。

私たちが目指したのは、その両方のいいところを取った第三の形だった。管理のない組織で自由に働きながら、コミュニティとしての恩恵も得られる。仲間との学び合い、安定した収入、困ったときに助け合える関係。

その両立を支えているのが、報酬の仕組みでもある。私たちは評価制度をやめ、給与はほぼ一律にし、賞与は全員で山分けにした。

個人の成果を細かく評価して報酬に差をつけると、どうしても評価者の目を気にするようになる。成果として見えやすい仕事ばかりを選び、地味だが大切な仕事を誰もやらなくなる。報酬で差をつけることが、自ら動こうとする気持ちを阻害してしまうのだ。

私たちのようなビジネスでは、一人ひとりの仕事の性質は似ている。個人ごとに大きな差をつける合理性がない。それならば、報酬による差を排し、自ら良い仕事をしたいという気持ちで駆動する場をつくった方がいい。

こうした一つひとつの仕組みが、技芸を磨き合う場を支えている。どれも、最初から設計したわけではない。コミュニティをいい感じに運営しようとした結果、一つずつ積み重なっていったものである。

ただし、この仕組みには一つの前提がある。セルフマネジメントができる人たちで構成されている、ということだ。創業から十年の間、私たちはそういう人だけを採用してきた。

では、まだセルフマネジメントに至っていない人をどう迎え入れるか。この問いが、創業十年を機に浮上することになる。次の記事では、その問いから生まれた「徒弟制度」について書いてみたい。

参考記事

• 「管理」と「マネジメント」の違い〜管理という手段で成果はあがらない
• 管理ゼロで成果をあげる組織に変える実験と結果
• 「歓迎するが、迎合しない」という採用の姿勢で守る企業の文化
• 遊びから始まるプログラミング 〜 ハッカソンが育む文化と成長
• 数字や営業が苦手なプログラマだから辿り着いた「エクストリーム経営」

原文の趣旨は「インターネットで本当に金を生むのはコンテンツだ」という話だったが、やがて「良いコンテンツを作れば人が集まる」という意味で広く使われるようになった。

そして実際にそうなった。ブログ、SNS、YouTubeと、個人が発信できるメディアが増え、コンテンツを作れる人が影響力を持つ時代が来た。「発信の民主化」だ。しかし今、AIによって情報を作るコストもゼロに近づきつつある。

「発信の民主化」の次に来たのは「生成の民主化」だ。届けるコストがゼロの世界に、作るコストがゼロのコンテンツが大量に流れ込んでいる。

こうなると、コンテンツの供給は実質的に無限になる。供給が無限なら、コンテンツそのものの価値はゼロに近づいていく。

メディアにしても、検索結果にしても、AIが書いた「そこそこ良い記事」が溢れかえる。キュレーションで選別しようにも、その選別自体をAIに頼ることになり、最終的には「AIが書き、AIが選び、AIが届ける」という人間不在の循環に向かっているように感じる。

では “Content is King” は終わるのか。

終わるのはコンテンツそのものではない。終わるのは「集客のためのコンテンツ」ではないだろうか。

SEO対策のために書かれた記事、バズを狙って量産されたコンテンツ、アテンションを集めることが目的の発信。こうした「集客装置としてのコンテンツ」は、AIが最も得意とするところであり、真っ先に置き換えられる。コンテンツだけで稼ごうとするモデルは、AIによって無効化されていくだろう。

一方で、実践や体験に裏打ちされた考察、つまり「活動の記録としてのコンテンツ」は残る。実際に何かをやった人が、その過程で考えたことを書き残す。そこには、AIには生成できない固有の文脈がある。同じテンプレートで量産できないし、時間が経っても価値は減らない。むしろ後から振り返ったときに意味が増すことさえある。

つまり大事なのは、コンテンツの質そのものよりも、「誰が書いているのか」であり、さらに言えば「その人は何をしているのか、何を為したのか」だ。コンテンツの裏側に実体のある活動があるかどうか。実力や実績を伴う発信だけが、信頼されるものとして残っていくのではないか。

そう考えると、これまでのコンテンツマーケティングの常識は逆転しないか。できるだけ多くの人に届けるための最適化、つまり集客のテクニックに注力するのではなく、実体のある活動に集中して、その記録を淡々と残していく。欲しい人に着実に届けばそれでいい。

この先さらにAIによるマッチングの精度が上がっていけば、プロモーションのテクニックなしに、必要な人に必要なコンテンツが届く世界がありうる。それはまだ仮説に過ぎないけれど、もしそうなるのであれば、それは実に健全な状態だと思う。

考えてみれば、ブログとは元々 “Web Log”、つまりウェブ上の記録だった。自分の考えや活動を、未来の自分のために書き残しておく場所。それがSEOやソーシャルメディアの時代に「集客装置」に変質していった。AIがその集客装置としての役割を終わらせるなら、ブログは本来の姿に戻ることになる。

“Content is King” の終焉は、ブログの終わりではなく、ブログへの原点回帰なのかもしれないな。

「なぜ会社をつくったのですか？」

起業についての取材やインタビューで、よく聞かれる質問である。多くの場合、質問者は「実現したいビジネスがあったから」「大きな市場を見つけたから」といった答えを期待しているように感じる。事業の構想があり、それを実現するためにチームを組み、会社をつくる。それが起業の一般的なイメージだろう。

しかし、私の場合は違った。事業のために起業したのではない。一緒に働きたい仲間がいて、その仲間と長くやっていくために、会社という形を選んだのだ。

技芸は個人の営みだと思われがちである。確かに、技芸を磨くのは一人ひとりの鍛錬であり、上達するのも自分自身だ。しかし、私たちの仲間が技芸を磨き続けてこられたのは、それができる場があったからだと感じている。

そして、その場は一般的に言われる「チーム」とは、少し違うものだった。私たちの会社がどのようにして生まれ、なぜ「チーム」ではなく「コミュニティ」になったのか。その経緯を振り返ってみたい。

仲間を失わないために起業した

ソニックガーデンの前身は、大手SIerの社内ベンチャーだった。プログラマとしての理想を追い求め、志を同じくする仲間と新規事業に挑戦していた。しかし、大企業の中では、せっかく育てた仲間が会社都合で異動させられることが何度もあった。それでも諦めずに続け、社内ベンチャーとして２年ほどかけて、ようやく単月黒字が見えてきたところだった。

そのとき、後ろ盾になってくれていた社長が交代することになった。事業の存続も、仲間の行く先も、自分たちでは決められない。

自分がこれまで本当に大切にしてきたものは何か。考えた末にたどり着いた答えは、事業でもプロダクトでもなかった。一番大事なのは、一緒にやってきた仲間たちだった。この仲間たちと、会社の都合に左右されず、長くやっていきたい。そのために、独立するという手段を選んだ。こうして生まれたのが、株式会社ソニックガーデンだった。

独立にあたって、自分たちが何を目指すのかを改めて考えた。私自身の根底にあったのは、学生時代の原体験である。仲間とソフトウェアをつくり、使ってくれた人たちが喜んでくれた。使う人も、作る人も幸せにできるもの。それが「いいソフトウェア」だと考えている。後にそれを「いいソフトウェアをつくる」という企業理念の言葉にした。そして、プログラマが一生の仕事としてソフトウェア開発に取り組み続けるためのビジネスモデルとして、「納品のない受託開発」を考案した。

理想と実践を、ブログや講演を通じて発信し続けた。自分たちが理想を実践してみせることで、同じ思いを持つ人たちに「自分にもできるかもしれない」と感じてもらいたかった。最初は小さな声だったが、少しずつ反応が返ってくるようになった。

未開の地に、移住者がやってきた

そうしているうちに、人が集まってきた。私たちが求人を出して、スキルの合う人材を探したわけではない。事業の成長に合わせて計画的に採用したわけでもない。理想を掲げて、それを愚直に実践している姿を見て、「自分もそこに身を投じたい」と考えた人たちが、向こうからやってきたのだ。

それは、まだ誰も住んでいない未開の土地に、一人で暮らし始めたような感覚に近い。畑を耕し、家を建て、自分なりの生活をつくっていく。すると、その暮らしぶりに惹かれた人たちが、一人、また一人と移り住んでくる。移住者たちはそれぞれに自分の理由を持っている。土地の豊かさに魅力を感じた人もいれば、そこで暮らす人たちの生き方に共感した人もいる。やがて小さな集落ができ、いつの間にか村のようなものになっていく。

ソニックガーデンに集まってきた人たちも同じだった。「プログラマとしてもっと腕を磨きたい」「お客さまに直接価値を届ける仕事がしたい」「自分の技術で食べていけるようになりたい」。それぞれが自分自身の動機を持っていた。共通していたのは、私たちが掲げるビジョンへの共感と、プログラマとして技芸を磨き続けたいという意志である。

人が足りないから採用したのではない。理想を実践していたら、その場に加わりたいという人が現れた。この順序が大切だったと、後から振り返って思う。なぜなら、この順序こそが、私たちの会社の性格を決定づけていたからである。

お客さまの現場で知った「チーム」の力

私たちソニックガーデンは、「納品のない受託開発」を通じて、お客さまのソフトウェア開発を支援している。その仕事の特徴は、お客さまのチームの中に深く入り込むことにある。

外部の業者として指示を受けて作業するのではない。お客さまの内製メンバーのように振る舞い、ときには経営陣の一人のような立場で、事業とソフトウェアの両面から一緒に考える。お客さまと私たちのメンバーが組み合わさって、一つのチームになるのだ。それが私たちの提供する価値である。

だから、私たちのプログラマは、それぞれが異なるお客さまの現場に入っている。あるプログラマはスタートアップの創業チームに参加し、別のプログラマは老舗企業の新規事業チームで働いている。どの現場でも、お客さまのミッションを共有し、チームの一員として成果を出すことが求められる。

こうした仕事を続ける中で、チームというものの力を私たちはよく知っている。共通の目標に向かって、異なるスキルを持つメンバーが力を合わせる。互いの強みを活かし、弱みを補い合う。ミッションが明確であればあるほど、チームは強くなる。私たちは様々なお客さまの現場で、その力を何度も目の当たりにしてきた。

会社はチームではなかった

私たちのプログラマは、お客さまの現場ではチームの一員として働いている。しかし、ソニックガーデンという会社自体は、一つのチームとして動いているわけではない。全員が同じミッションに向かって、一丸となって働いているわけではないのだ。

では、ソニックガーデンとは何なのか。

様々なお客さまの現場に出ていったプログラマたちが、帰ってくる場所。それがソニックガーデンだった。

現場で得た経験や知見を持ち帰り、仲間と共有する。他の現場で起きている課題や工夫を聞いて、自分の仕事に活かす。技術的な相談をしたり、困ったときに助け合ったりする。新しい技術を一緒に学んだり、コードレビューを通じて互いの腕を磨いたりする。

その姿は、エンジニアのコミュニティや勉強会に近かった。いろんな会社で働くエンジニアたちが集まって、互いの知見を共有し、刺激し合う。あの空気感と似ている。ただし、私たちの場合、それが会社という形をとっていた。

チームには共通のミッションがある。メンバーはそのミッションを達成するために集まり、スキルによって選ばれる。ミッションが達成されれば解散することもある。目的ありきの集まりである。チームの経営は、船の経営に似ている。目的地を決めて、そこに向かって全員で漕ぎ進む。

一方、コミュニティにはゴールがない。参加者は、それぞれが自分自身の目的を持って集まってくる。共有しているのはミッションではなく、ビジョンや価値観である。だからコミュニティは、ミッションが変わっても存続し続ける。コミュニティの経営は、街の経営に近い。土地を耕し、住みやすい環境を整え、集まってきた人たちと一緒に暮らしを育てていく。先ほどの「未開の地に移住者がやってくる」という感覚は、まさにこれだったのだと思う。

ソニックガーデンに集まった人たちは、「いいソフトウェアをつくる」というビジョンに共感し、「プログラマを一生の仕事にする」という価値観を共有していた。しかし、日々の仕事で取り組むミッションは、一人ひとり異なる。それぞれのお客さまの現場で、それぞれのチームの一員として、それぞれのミッションに向き合っている。

つまり、ソニックガーデンはチームではなく、コミュニティだったのである。チームはお客さまとの間に生まれるもの。ソニックガーデンという会社は、同じ志を持つプログラマたちが集い、技芸を磨き合うコミュニティだった。

実践が先、理論は後だった

ソニックガーデンはチームである必要がなかった。むしろ、コミュニティだからこそ、長く続けられる場になり得た。チームはミッションが終われば解散する。しかし、コミュニティは続いていく。技芸を磨き続けるには、終わりのない場が必要なのである。

この「チームではなくコミュニティだった」という認識は、最初から持っていたわけではない。コミュニティという概念を学んでから組織を設計したわけでもない。理想を掲げて実践していたら、自然とそうなっていた。振り返ってみて、ようやく言葉がついたのである。

実践が先で、理論は後だった。

管理をやめたのも、徒弟制度を取り入れたのも、独自の評価の仕組みをつくったのも、最初から狙ってそうしたわけではない。コミュニティとしてのソニックガーデンを、いい感じに運営しようとした結果、一つひとつの実践が積み重なっていった。理論や方法論を先に学んで適用したのではなく、目の前の課題に向き合い続けた先に、それぞれの形が生まれた。

技芸を磨く場は、設計してつくるものではなく、理想を実践し続ける中で自然と育っていくものなのかもしれない。そして、そうした場は、チームよりもコミュニティと呼ぶ方がふさわしいのではないだろうか。

参考記事

• チームとコミュニティの違い、会社・組織をどう捉えるか
• コミュニティと会社の両立を目指した実験と結果 〜 多様性を受け入れて活かし合う組織
• コミュニティ型の組織で人間関係を耕し続けるカルチャーマネジメント

そもそもプログラミングとは「コードを書く行為（コーディング）」のことではない。ソフトウェアで問題を解決する知的活動の全体を指している。何を作るか考え、何を作らないか判断し、どう構成するか設計し、動くものに仕上げ、運用し続ける。その一連の営みがプログラミングだと私は考えている。

今、AIはその全工程で力を発揮している。設計の壁打ち、コードの生成、テストの作成、ドキュメントの整備。人が手を使って何かをすることはなく、AIエージェントに指示することで、作られていく。プログラミングのあらゆる場面が加速するようになった。かつてのプログラミングとは、もう別物と言っていい。

その結果、プログラミングの敷居は確実に下がった。たとえば、経理担当がAIを使って自社の業務ツールを作れるようになるかもしれない。これまでコードを書けなかった人が、ソフトウェアで自分の問題を解決できる。これは「プログラマが不要になった」のではない。誰でもプログラマになれるようになった、ということではないか。

ただし、経理担当が作れるのは、あくまで自分の手元の業務を助けるツールだろう。会社全体の経理システムを設計し、セキュリティを担保し、長期にわたって運用し続けることは、また別の話だ。複雑なシステムになればなるほど、設計の質、判断の精度、責任を持って維持し続ける力が求められる。そこに、プロフェッショナルなプログラマの価値がある。

つまり、AIによって「プログラマが不要になる」のではなく「プログラマの裾野が広がる」ということだ。裾野が広がった上で、なお高い成果を出せるプロが求められる。これは、多くの仕事と同じ構造だろう。

私たちソニックガーデンでも、日々のソフトウェア開発でAIを積極的に使う試行錯誤を続けている。手でコードを書く時間は減っているが、プログラミングの密度はむしろ上がっている。何を作り、何を作らないか。どう設計すれば長く使えるか。考えることに、より多くの時間を使えるようになった。

プログラマとは、コードを書く人のことではない。ソフトウェアで問題を解決する人のことだ。AIの時代になって、その意味がようやくはっきりしてきたように思う。プログラマの裾野が広がることも大歓迎だ。

せっかく作ったはずのシステムが、気づけば「使いにくい」「改修できない」状態になっている。現場から不満の声が上がり、開発会社に相談するたびに高額な見積もりが返ってくる。やがて「もう限界です、作り直しましょう」となり、また多額の費用をかけてリプレースに着手する。今度こそ将来を見据えた設計にしようと理想のシステムを作り上げるが、完成した頃には要件が変わっており、数年後にはまた同じことが繰り返される。

こうしたリプレースの繰り返しを止めるためには、経営レベルでのシステム戦略から見直しが必要となると考えている。その肝は、一過性のシステム開発とするのではなく、継続的に安定して動くよう保守を繰り返し、必要に応じて持続的な拡張（エンハンス）を続けていく戦略である。

従来の理想を描いて一気に作る考え方を「ビッグバン戦略」、それに対してシステムを育て続ける考え方を「エンハンス戦略」と呼ぶこととする。この記事では、エンハンス戦略とその実践事例について紹介する。

リプレースが繰り返される本当の理由

システム開発で繰り返されるリプレースの根本原因は、「ビッグバン戦略」と呼ぶべき考え方にあると考えている。

ビッグバン戦略とは、数年後の「理想の姿（To-be）」を先に描き、現状（As-is）とのギャップを埋める形でシステムを設計・構築する考え方だ。大規模なシステム導入などで広く採用されてきた。

しかし、「未来の理想を先に描く」という発想が、設計・心理・経済の三つの問題を引き起こす。

まず、設計の問題。未来を描いた時点から開発が完了するまでの間にも、ビジネスは変化し続ける。数年かけて完成したシステムが稼働する頃には、当初描いた「理想」がすでに古くなっていることは珍しくない。

次に、心理の問題。「理想の未来」を起点に設計すると、「将来必要になるかもしれない」という不安から、本当に欲しいかどうかもわからない機能まで盛り込んでしまいがちだ。「どうせ作るなら一度で全部やってしまおう」という心理も働き、要件はどんどん膨らんでいく。そして大きな投資をした後は「失敗できない」というプレッシャーが生まれ、途中で方向を修正することが難しくなる。

そして、経済の問題。膨らんだ要件の中には、稼働後に使われない機能が少なくない。使われなかった機能の開発費は、純粋な損失だ。さらに、大きく作るほど内部の複雑さが増し、改修コストが上がっていく。投資するほど身動きが取れなくなるという逆説。リプレースを検討しようにも、移行コストが読めないために判断が遅れ、傷口がさらに広がっていくことになる。

こうした問題が重なり合った結果、システムは「改修できないもの」になっていく。本当の課題は、バグやパフォーマンス不足ではなく、時間の経過とともに改修・保守のコストが増大し続けることにある。改修できなくなったとき、リプレースという選択肢を取らざるを得なくなる。こうして、同じことが繰り返される。

システムは「負債」にも「資産」にもなる

経営者の視点からすれば、システムへの投資は本来、資産形成のはずだ。しかし現実には、多くのシステムが時間の経過とともに「負債」として積み上がっていく。

改修のたびにコストがかかり、触れるほどに複雑さが増す。開発会社に相談するたびに高額な見積もりが返ってくる。「使い続けているのに、なぜこんなにお金がかかるのか」。その感覚こそ、システムが負債化しているサインだ。

一方で、システムが「資産」として機能している状態とはどういうものか。業務に使い続けるほどデータが蓄積され、そのデータをもとに意思決定ができる。新しい機能を加えるたびに、システム全体の価値が上がっていく。事業の変化にシステムが柔軟に対応できる。そうしたシステムこそが、競争力の源泉になる。

同じ「システムへの投資」でも、戦略次第で資産にも負債にもなる。ビッグバン戦略は、意図せずシステムを負債化させやすいと感じている。エンハンス戦略は、システムを資産として育てていくための考え方である。

エンハンス戦略とは何か

システムの負債化とリプレースの循環を断ち切るための考え方が、エンハンス戦略となる。エンハンス戦略の核心は、「理想の完成形を先に作らない」ことにある。代わりに、「今の業務に完全にフィットした最小構成を作り、継続的に育てていく」という姿勢をとる。

ビッグバン戦略に対し、エンハンス戦略は「将来にわたってリプレースしない」ことを目指す戦略だ。完成させることがゴールではなく、動き続けることがゴールだ。

この戦略においてもっとも大切なのは、「仕掛品を作らない」ことだ。要件定義書や設計書が積み上がっている状態は、製造業でいえば倉庫に眠る在庫と同じで、価値を生まない。常に「動くシステム」として出荷し続けることが、無駄をなくすもっとも確かな方法だと考えている。

小さく始めて、動く状態を維持しながら育てていく。「それはアジャイルと同じではないか」と感じるかもしれない。重なる部分はある。ただ、アジャイル開発が「どう作るか」という開発の進め方の話であるのに対し、エンハンス戦略は「どう投資するか」という経営判断の話だ。

アジャイル開発を採用していても、経営が「2年後までに理想のシステムを完成させる」と決めていれば、それはビッグバン戦略の中でアジャイルに作っているに過ぎない。完成形を定義せず、継続的に育てていくと決めること。エンハンス戦略は、その経営の意思決定から始まる。

なぜエンハンス戦略は機能するのか

エンハンス戦略が実際に機能するのは、システムをプロジェクトではなくプロダクトとして捉えているからだ。プロジェクトには完了があるが、プロダクトに完了はない。だからこそ、小さく始めることが大切になる。

「理想の未来」を描いてから作ると、使われるかどうかわからない機能まで盛り込んでしまう。しかし実際のところ、何が本当に必要かは、動かしてみるまでわからない。小さく作って動かすことで、初めて現場の反応が得られ、何を次に作るべきかが見えてくる。

そして、動く状態を維持したまま、少しずつ拡張していくことがエンハンス戦略の要だ。システムは常に本番で動いている。その上で、一つひとつのエンハンスを積み重ねていく。一度に大きく変えようとするほどリスクが高まる。小さな変更を継続的に重ねることで、リスクを抑えながら確実に育てていける。

この育て方を支えるのが、システムの構成要素の「寿命」の序列を意識することだ。建物に喩えれば、土地にあたるのがデータモデル、構造にあたるのがアーキテクチャ、内装にあたるのがプログラミング言語やフレームワークだ。寿命もこの順に長い。この序列に従い、まずデータモデルを整え、その上でアーキテクチャを固める。言語やフレームワークは必要に応じて部分的に入れ替えればいい。それは「リプレース」ではなく「エンハンス」だ。

ただし、この戦略は開発プロセスの工夫だけでは成り立たない。経営としての判断も必要になる。

まず、チームを継続させなければならない。プロジェクト型の開発では、完成とともにチームが解散する。エンハンス戦略では、システムの文脈を知っているエンジニアが継続的に関わることで初めて、小さな変更を安全に積み重ねられる。内製のチームもしくは内製に準じるような形で人材を抱え続ける判断も欠かせない。

加えて、コードの読みやすさや技術的負債のない構造を保つことへの投資も欠かせない。内的品質、つまりユーザーからは見えないがシステムの変更しやすさを左右する品質への投資は、エンジニアの仕事に見えるが、経営の判断でもある。ここを惜しむと、エンハンスのたびにコストが増し、やがてエンハンス戦略は成り立たなくなる。

そしてもう一つ、ビジネスと開発を分離させないことだ。受発注の関係になると、要件を固めてから発注し、完成品を受け取るサイクルになる。エンハンス戦略では、ビジネスの変化に開発がすぐに対応できる距離感が欠かせない。パートナーとして協働できる関係を、経営として構築することが大切だ。

実証：クラシコムでの実践

エンハンス戦略には、すでに実践の裏付けがある。私が取締役CTOを務めるクラシコムで、まさにこの戦略を実践している。

クラシコムの運営する「北欧、暮らしの道具店」は、単なるECサイトではなく、独自のコンテンツや多様なチャネルを組み合わせたライフカルチャープラットフォームである。それを支えているのが内製で育て続けてきたシステムだ。年商100億規模の上場企業がこれほどのシステムを内製で、しかも10数人のメンバーで作り続けている。

昨年からは、ソニックガーデンが「納品のない受託開発」でシステム開発に加わり、私が経営目線でシステム戦略を検討していく立場として関わっている。エンハンス戦略で大切なのは、内製かどうかよりも、システムの文脈を知ったチームが継続的に関わり続けることだ。納品して終わりではなく、パートナーとして一緒に育てていく関係があるからこそ、この戦略が成り立っている。

クラシコムの内製システムは10年以上の歴史がある。事業が成長していく中で、機能追加をしたり現場の要望に応えたりしていく中で、見通しの良いデータやアーキテクチャにはできない部分が出てきた。これまでの対応は間違いだったというわけではなく、その時々での最善だったとは思うが、どうしてもシステムの保守と拡張を同時に進めることが難しくなっていた。

エンハンス戦略はすべてのリプレースを否定するものではない。土台がしっかりしていない状態では、エンハンスを積み重ねることはできないからだ。

クラシコムの場合も、まずECの根幹となる受注管理システムの部分的なリプレースから始めた。ただし、その際に優先したのは「理想の完成形を作ること」ではなく、「もっとも寿命の長いデータモデルをしっかり整えること」だった。受注から仕入までの一連の流れをデータモデルとして定義し直すことで、業務の実態をソフトウェアで把握できる状態を作った。

このリプレース自体も、エンハンス戦略の考え方に従って進めた。最初から全機能を作り切るのではなく、まず最小限で動く状態を作ることを優先した。新システムと現行システムを並行稼働させながら、新システム側はエンハンスを続けていく。「完成してから切り替える」のではなく、「動く状態を保ちながら育てていく」という進め方。これはまさに、エンハンス戦略を置き換えの場面でも実践したものだと考えている。

この取り組みを通じて、エンハンス戦略で進めてよいという手応えを得た。小さくてもデータモデルが整ったことで、現場からのフィードバックを受けての改修速度が明らかに上がった。この先は、ソフトウェアを前提として業務全体とデータの流れをつかめるようになっていくだろう。

そして今まさに取り組んでいるのが、アーキテクチャの統合だ。複数の技術でバラバラに作られたシステムを、一つの統一された構成へ移行している。統合が進むほどに全体の見通しが良くなり、次に何を作るかのロードマップも立てやすくなる。データモデルを整えてから、アーキテクチャを統合する。この順番が、今回のエンハンス戦略を機能させるための正しい道筋だったと、実践を通じて感じている。

補足：「AIで安くリプレースすればいい」という考えについて

AIの登場で、コードを生成するコストは大きく下がった。「AIで安くリプレースすればいい」という発想が出てくるのはわかる。

ただ、コードが生成できても、それが業務ロジックとして正しいかどうかは別の話だ。テストを自動生成したとしても、そのテスト自体が正しいかどうかを確かめるのは、最終的に人間の仕事だ。膨大に生成されたコードを本番環境に適用するには、相応の検証コストがかかる。

加えて、データベースに蓄積されたデータには、コードには現れない「暗黙のルール」が宿っている。過去の業務上の例外処理や、長年の運用の中で育ってきた経緯がそこにある。AIはコードを変換できても、データの裏側にある文脈までは解釈できない。膨大なデータを一括移行するリスクは、ビジネスの停止につながりかねない。

全体リプレースは、一度でも相当なコストと覚悟が必要な出来事だ。それを数年おきに繰り返す前提でシステムを持つことは、経営として合理的ではないと感じている。

一方で、AIはエンハンス戦略との相性がとても良いと思っている。小さな改善を継続的に積み重ねるエンハンスの場面では、AIはとても頼もしいパートナーになる。既存のコードを読み解きながら変更点を提案したり、テストを補助したり、ドキュメントを整えたりと、日々の改善の質とスピードを上げてくれる。リプレースのためではなく、継続のためにAIを使う。そういう使い方の方が、システムを資産として育てていく考え方と自然に合うのではないかと思っている。

エンハンス戦略を広めていきたい

ビッグバン戦略に代わる考え方として、エンハンス戦略という言葉を多くの人に、特に経営者の判断指針として使ってもらえるようになれば嬉しい。

エンハンス戦略という言葉は私の造語だが、実践としてはすでに10年以上の裏付けがある。ソニックガーデンの「納品のない受託開発」での取り組みは、すべてがエンハンス戦略のもとに行われており、稼働から10年以上エンハンスし続けて事業成長を続けている事例もある。クラシコムでの実践が、さらにその確度を高めてきている。

エンハンス戦略で手に入るのは、事業や業務にとって過不足のないフィットした状態のソフトウェアなのだ。

ビジネスは変化し続けるものだ。その変化に寄り添い続けられるシステムを持つことが、これからの時代の競争力になっていくのではないか。エンハンス戦略という考え方が、一つの選択肢として定着していくことを願っている。

エンハンス戦略の背景にある、ソフトウェア開発の本質的な問題については、拙著『人が増えても速くならない』でより詳しく論じている。この記事と合わせて読んでいただけると嬉しい。

参考記事

• 変化を抱擁するシステムの作り方
• 「納品のない受託開発」とは
• 不確実な世界で成果をあげる〜変化を抱擁するアジャイル思考
• AI時代のコードを書かないソフトウェア開発

もしかして、人が幸せを感じるのは、「挑戦→試行錯誤→成長」のサイクルが回っている時なのではないか。これは、難易度と能力のちょうど良いところにいる「フロー状態」の話ではあるけど、試行錯誤がポイントなのかもしれないな、と。

何かに挑戦する。難しいからすぐにはできない。試行錯誤する。できるようになる。成長を実感する。すると、もう少し難しいことに挑みたくなる。また試行錯誤する。またできるようになる。

このサイクルが回り続けている時、人は充実を感じているように思う。仕事とか趣味とか生活とか関係なく、ここに人生を充実させるヒントがありそう。

ただ、同じ試行錯誤でも、面白い時とそうでない時がある。

ゲームやパズルを自分で解こうとしている時の試行錯誤は楽しい。でも、誰かに「これ解け」と言われてやらされる試行錯誤は、ただの苦行になる。やっていることは同じなのに、まるで違うものになってしまう。

その違いは「主体性」があるかどうかではないか。内発的動機付けと言ってもいい。

自分でやりたいと思ってやっている試行錯誤は面白い。望んでもいないのに試行錯誤させられるのは、ただの労働であり義務でしかない。主体性がなければ、挑戦は義務になり、試行錯誤は苦痛になり、成長しても喜びにならない。

「挑戦→試行錯誤→成長」のサイクルを回すエンジンは、主体性なのだろう。

どんな仕事でも、単にお金を稼ぐための労働だと思っているうちは、このサイクルには入れない。だけど、仕事が自らの挑戦の機会であり、試行錯誤ができる場所であり、そこから成長が得られるものだと捉えることができたら、労働として過ごす人生よりも、ずっと幸せなんじゃないか。

それこそが、仕事を「技芸」とする考え方なのだ。

私たちの仕事のゴールは、単に「システムを完成させること」ではありません。本来のゴールは「ビジネスが成長すること」であるはずです。

このテーマについてお話ししたスライドをこちらで公開しています。 

システムの本当の課題は何か

事業が変化し続ける中で、システムの真の課題はバグやセキュリティ、パフォーマンスの低下ではありません。それらは直せば済む話だからです。

本当の課題は、「改修・保守が難しくなること」そのものにあります。

多くのシステムは、時間の経過とともに変更コストが指数関数的に増大していきます。長く使うほどに改修が困難になり、身動きが取れなくなる。このコストを一定に保つためには、システムを「ソフトウェアらしく」作る必要があります。

ソフトウェアの常識は、製造業の真逆

現代のシステム開発において、多くの人が「製造業やハードウェアの常識」を持ち込んで間違った判断をしています。ソフトウェアらしさとは、直感に反するものです。

• 完成しても、終わりではない
• 人を増やしても、速く作れるわけではない
• たくさん作っても生産性が高いとは言えない
• 人に依存せず同じ品質で作ることはできない
• プレッシャーをかけても生産性は上がらない
• 見積もりを求めるほどに絶望感は増す
• 一度に大きく作れば得に見えて損をする
• 工程を分業しても、効率化につながらない

製造業のように「計画を立て、見積もりを出し、人を投入して一気に作る」というアプローチをソフトウェアに適用するとどうなるか。

人が増えるほど管理コストが増し、動かしてみるまで価値がわからず、完成した頃には要件が変わっている。そして、改修困難な負債だけが残ります。

このような「人を増やせば速くなる」という幻想が、いかにプロジェクトを壊すか。この本質については、私の著書『人が増えても速くならない』で詳しく解説しています。

「ソフトウェアらしさ」を守る4つの原則

変化を抱擁するために、私たちは以下の4つの原則を重視すべきです。

1. プロジェクトではなく、プロダクト: リリースをスタート地点とし、事業とともにチームを継続し、試行錯誤を繰り返します。
2. 製造ではなく、すべて設計と考える: 単に手を動かすのではなく、学習をサイクルに入れ、間違いを許容しながら進めます。
3. 外的品質に加えて、内的品質も重視: コードの読みやすさや、技術的負債のないシンプルな構造を維持します。
4. 小さく作って、大きく育てていく: まず最小限の動くものを作り、動く状態を維持したまま拡張していく。

マネジメントをアップデートする

体制とマネジメントも、ソフトウェアらしい形に変えていかなければなりません。

• 「受発注」から「協働」へ：上下関係ではなく、共に作るパートナーシップ。
• 「分業」から「多能工」へ：役割を固定せず、領域を超えて助け合う。
• 「計画」から「ロードマップ」へ：固定された予定ではなく、更新し続ける道筋。
• 「指示命令」から「自律組織」へ：現場が判断し、自ら考えて動けるチーム。

製造業の品質が「買った時点が最高（Point of Sales）」なのに対し、ソフトウェアの品質は「使っている時点が最高（Point of Use）」であるべきです。常にアップグレードされ、最新の状態が最も価値が高いことがソフトウェアの姿です。

いいソフトウェアをつくるために

私たちソニックガーデンでは、社会、お客さま、そして共に働く仲間のために「いいソフトウェア」をつくりたいと考えています。

それは、機能が良いだけでなく、開発方法が「いい」ものであり、関わる人を幸せにするものです。変化を恐れるのではなく、変化を抱擁する。そんな開発のあり方を、これからも追求していきます。

さらに詳しく知りたい方へ： 変化を抱擁し、ソフトウェアらしく開発を進めるための思考法をさらに知りたい方は、こちらの書籍もあわせてお読みください。

• 『人が増えても速くならない』
• 『「納品」をなくせばうまくいく』

最初のうちは全然だめだった。結局、自分で書いた方が早いし、品質も良かった。書かせることは諦めて、校正とか誤字チェックとかに使っていた。

段々と性能があがって、短めの文章なら頼んでも良いかという感じになった。適当なメモを渡しても、それなりの文章が書けるようになった。

それでも、長い文章は難しかったし、自分らしい表現は無理だった。

次に取り組んだのが、協働スタイル。構成を練るところから往復しながら、何度も書き直しをさせて、文章を組んでいく形。一定の段落ごとに書いていく感じはできた。

そうこうしているうちに、長文を読み込めるようになった。そこで、自分のブログを全部、読み込ませてみると、それなりに自分らしい文章を書いてくれるようになった。

ここで長年のブログを書いてきたことが活きた感じがする。公開されたブログなので、自分が著者であることを明示すれば、それまでの思想を前提とした文章が書けるようになった。

そうすると、書きたいテーマだけ与えれば、それを元に、いくつか構成案を考えるので、そこから選ぶ。出してくれた選択肢から選んだら、文章を書いてもらう。

書いてもらう際に、自分なりのエピソードなどを入れたいと指示して、ヒアリングをしてもらう。AIからの質問に答えていくと、それが文章になる。

自分のブログをもとに、新しいブログ記事が書かれていく。もしかすると私はいなくても、今後も再生産し続けるのではないか、という気がしてくる。それも良いか、と思う。

ただ過去を学習したAIは、それなりに「らしい」文章を書くのだが、それは過去の自分の考えでしかない。書かせてみたものの、自分では面白いとは思えない。

しかも、こちらも文章を書き続けてきた身としては、読み手としても経験値がある。

叩き台としての文章としては良いけれど、どうも自分としては気持ちの悪い表現も残る。その都度、学習させていっても、どうしてもAIは常識側に引っ張られている感じがする。

そう、段々とAIは賢くなった結果、とても優等生で、常識的な知能になってきている感じがする。ただの印象かもしれないけれど。一般的に喜ばれることを書こうとしがちだ。

なんだか違うんだよなーと思いながら、修正しているうちに、結局は全部書くことになっている。

もしくは、ざっと書いて渡したメモをもとに文章を書いてもらっても、なんだか小綺麗ではあるけど、勢いがなくなってしまっている。

だから、結局は、自分の手で書いたメモを、そのままブログやSNSに載せるようになった。けど、その方が沢山の反応をもらえてる気はする。

読むのが人間なので、雑なままでも、言葉足らずでも、綺麗な文章でなくても理解してくれる。もっと読んでくれる人間の知性を信じて良いのではないか。

果たして、人間が書いて人間が読む文章の間に、AIを介在させる意味はあるのだろうか。

そういえば自分にとって「書くこと」は思考を深めるための時間でもあった。書くことで考えが整理された。それは自分のための豊かな時間の使い方だ。そんな贅沢をAIに渡してしまうなんて。

では今の私にとってのAIはどんな役割なのか。過去の自分を覚えてくれている存在で、思考を促進するためのアイデアを出してくれる存在で、最初の読者として感想をくれる存在。

まぁ、すぐにまた変わるだろうけど。

この記事のまつもとさんの意見、本当にそう思う。私も同様の危機感は感じている。

とはいえ、事業会社を経営する立場としては経済合理性を考えると、内製のエンジニアチームでのジュニアの育成は説明可能な妥当性がなくて苦しい。

なぜなら、ジュニアの育成は、半年や１年では成果は出ない。新人研修やっただけでできる仕事ではないのがソフトウェア開発というものだから。

そして、ジュニアがいてもチームの生産性は高くなるどころか、育成コストを考えると全体の生産性が下がるのは目に見えている。そこに、さらにベテランとジュニアのAI活用による格差が広がっている。

今は転職が当たり前になった業界で、それ自体は良いこととするならば、数年かけて育成に時間と労力をかける判断に踏み切るのは簡単なことではない。

そうした中でも、ソニックガーデンではジュニアからの育成に取り組んでいる。大卒の新卒に限らず、未経験の第2新卒で他業種から転職してきた若者たちを受け入れて、徒弟制度で育てている。

もちろん短期的な経済合理性はないけれど、「いいソフトウェアをつくる。」という理念があるので、その理念に沿った活動として取り組んでいる。理念合理性と呼んでいる。

最近は、中学生に向けたプログラミング部活動「セタプロ」や、大学生の就業体験を兼ねた訓練「トレセン」なども取り組んでいる。

一生懸命にソフトウェア開発の作品作りに熱中して、そのために学んで練習を重ねている姿を見て感じることは、AIがどうなろうと、ここで頑張ったことは無駄にはならないだろうな、と。

効率だけを追い求めた先に「焼け野原」が広がるというのなら、効率やコスパという言葉で片付けられないような活動をするしか、肥沃な大地には育たないのではないかな。

（これは過去の技術革新で起きてきたことでもある）

先日、400人が投入されている大規模開発プロジェクトを目の当たりにしたが、ああいうのこそ、10分の1の人数で解決できそうだし、解決できるという世界にしていきたい。

「立派な会社のシステムは、多人数でないと作れない」というのは思い込みだと思っている。

以前から言い続けてきたが、ソフトウェア開発は「人数」ではなく「難易度」の問題である。同じ人数で良いが、熟練度の違う人材を集めた方が良い。

巨大なシステムは難易度が高く、熟練の人材が必要で、小さなシステムは難易度が低いので、経験の浅い人材でも出来る。

同じソフトウェアをつくるのに、「熟練の３人」と「初心者の３０人」、どちらが速く・良いものを作ることができるのか。リアリティーあるのは、その両者を混ぜた体制だが、それでも「熟練の３人」が勝る。

人数は多くしない方が生産性は高い。

人が増えても速くならない。これは今も昔も変わらない真理。

人海戦術から解放されるなら、エンジニアは少ない人数で全体を把握し、ユーザーに近いところで、分業せずに「自分の作品」として作れるようになる。これこそがソフトウェア開発の楽しさであり、エンジニアにとっての「福音」ではないか。

生成AIで、コードを書くことがなくなって寂しいというのは本当か？タイピングしたかったのか。しょうもないバグを修正したかったのか。本当にしたかったのは、優れたソフトウェアを生み出して、ユーザに喜んでもらうことだったのではないか。

そもそも、ソフトウェア開発をハードウェアの生産ラインのように「工場」として扱おうとしたのが間違いだったのだ。ソフトウェア開発は、作品作りであり、取り組むこと自体にも喜びのある技芸に回帰していきたい。それが仕事技芸論なのだ。

一つのソフトウェアを作るのに必要な人材は少なくなっても、社会から求められるソフトウェアの総数は、これまで以上に増えていく。それは生成AIとかでてくる以前から言われていることだ。

これからの開発者（エンジニア）には、求められることは増えていくし、難易度は高まっていく。プロとして求められる基準は、ぐっと上がっていく。スクール出て、プログラミング言語が使える位ではプロにはならない。

だけど、その方が健全なんだと思う。そして難しい仕事はなくならない。

だからこそ、より難しいことに挑戦し、より高みを目指していくような開発者になりたい若者たちは応援したいし、サポートしていきたい。人数は多くなくても良い。ソニックガーデンで取り組んでいる活動の芯にはこれがある。

ソフトウェア開発は、少ない人数で、より多くの価値を、より楽しく生み出せるようになる。それは社会全体にとっても、素晴らしいことではないかな。

テーマは「チームマネジメントの罠」です。対談相手は、DIOの編集長でもあり、新刊「新米マネージャー、最悪な未来を変える」の著者でもある長瀬さんです。

今回の対談では、新刊でも描かれている「マネジメントの本質」を深掘りし、多くの現場で陥りがちな**「3つの落とし穴」**についてお話ししています。

組織を「いい感じ」にしようと奮闘するマネージャーが、知らず知らずのうちにハマってしまう罠を、記事では以下の3つの切り口で整理していただきました。

• 1. 「あなた vs 私」という対立構造の罠 マネージャーが「管理する側」、メンバーが「される側」という二項対立の構造に陥ると、自律性は生まれません。この対立を解消し、「私たち（We）」として同じ方向を向くためのヒントを語っています。
• 2. 「仲良しグループ」の罠 心理的安全性を「単に仲良く、波風を立てないこと」だと誤解すると、組織は弱体化します。本当の意味で心理的安全なチームとは何か、その誤解を解いています。
• 3. 「個性を消して一律に扱う」罠 人を交換可能な「リソース」として捉え、一律のルールで縛ることは、個々の才能を殺すことになります。人間を「資産」ではなく「人」として扱う、これからの時代のマネジメントのあり方に触れました。

新刊『新米マネージャー、最悪な未来を変える』は、小説という形式を通じて、これらの「罠」をどう乗り越えていくかを追体験できる構成になっています。

対談記事では、小説の背景にある理論的な側面や、私自身がソニックガーデンでの経営を通じて大切にしている思想を、より具体的に言語化していただきました。

マネジメントに正解はありませんが、この対談が、皆さんのチームを「いい感じ」にするための一助になれば幸いです。

ぜひ、以下のリンクよりご一読ください。

▼掲載記事はこちら 「チームマネジメント3つの罠」に陥っていませんか？ 倉貫義人氏に聞く、自律型組織への処方箋

▼新刊「新米マネージャー、最悪な未来を変える」はこちら

これらの尺度を伸ばしていくために、私たちは何を積み重ねればよいのでしょうか。知識なのか、経験なのか、それともセンスのようなものなのか。今回は、ソフトウェア開発における「できる」の正体と、その身につけ方について整理します。

「わかる」と「できる」のあいだにあるもの

まず明確にしておきたいのは、知識としてわかっていることと、実際にできることの間には大きな隔たりがあるということです。

プログラミング言語の仕様を理解したからといって、良いソフトウェアが作れるわけではありません。これは、日本語の文法に詳しくても、面白い小説や心に響く文章が書けるとは限らないのと同じです。

ソフトウェア開発は、多分に身体性を伴うものです。たとえば自転車の乗り方を本で読んで理解しても、すぐには乗れません。車の運転も同様で、練習を重ねて乗れるようになると、車体が自分の身体の拡張であるかのように扱えるようになります。

ソフトウェア開発もこれと同じです。頭で理解するだけでなく、身体に馴染むまで練習を繰り返す必要があります。研修で知識を得ただけで一生できるようになることはありません。イメージした通りに手を動かせるようになるまで、鍛錬を積むしかないのです。

宮本武蔵の『五輪書』に、「千日の稽古をもって鍛となし、万日の稽古をもって錬となす」という言葉があります。「鍛錬」という言葉は、ここから来ています。千日（約3年）の稽古で基礎を固め、万日（約30年）の稽古を経てようやく自分のものとして練り上げられるとされています。

私は、ソフトウェア開発には宮本武蔵が目指した道と同じくらいの技芸としての奥行きや面白さがあると感じています。

試行錯誤が生む「面白い」という感覚

私が初めてプログラミングに触れたのは、小学生の頃なので40年ほども前の話になりますが、最初は知識もなく、説明書に書いてあるゲームのコードをそのまま打ち込んで、それが動くことから始まりました。そのときは「わかる」も「できる」もありません。

そこから、少し変えてみて動かしてみたり、似たようなゲームを作るためにを自分で打ち込んでみたり、動かなくなったら、なぜ動かないか考えて直してみたり、そんなことを繰り返していくうちに、動くことが快感になって、のめり込んでいきました。あれが面白いと感じた瞬間でした。

ソフトウェア開発に限らず、身体性を伴うことは技芸の特徴であり、その「できる」には繰り返しの体験が必要なのです。

プログラミングの良いところは、失敗しても修正が楽なので、何度も試行錯誤ができることや、できた結果がすぐに反応として返ってくるところです。ただ、現代だとスマホやウェブのアプリを作ろうとすると、前提知識が膨大になっていて「できる」を体験するまでの知識が多くなりすぎています。

もっと、初心者がプログラミングの素朴な面白さを体験したり、教わったりする機会を作っていきたいと考えています。

経験という名の「引き出し」

「できる」ようになった先には、「うまくできる」への道があります。ここで必要になるのが経験です。

私たちは、経験から得られた知見を「引き出し」と呼んでいます。引き出しとは、何かを作ろうとするときに、その作り方と完成形が具体的にイメージできることです。一度作った経験があれば、次に同じようなものを作ることは容易になります。

プロフェッショナルとして大事なことは、見積もり通りに仕事を完遂することです。試行錯誤は面白いものですが、仕事においては時間を溶かす要因にもなります。経験に基づいた設計ができれば、実装段階での試行錯誤や手戻りを最小限に抑えられます。

ベテランと初心者の決定的な差は、この「引き出し」の数と、それに基づいた設計能力にあります。

ベテランは、実際にコードを書く時間が驚くほど短いものです。それは手を動かす前に、頭の中で設計が終わっているからです。設計が固まっていれば、コーディングは単なる出力作業になり、手戻りは起きません。

この段階に達していると、生成AIは強力な武器になります。単なる出力作業をAIに任せることで、ベテランはさらに生産性を高められます。一方で初心者は、完成形のイメージが持てないまま手を動かそうとします。AIを使っても、結局は試行錯誤を繰り返すことになるため、ベテランとの差はなかなか埋まりません。

仮にベテランであっても、もし経験のない技術を扱う場合は、まず小さく試せる範囲のものを作ったり、あるいはその技術だけを試してみるという「スパイクを打つ」という手法をとります。そして、現代ではAIがその大きな助けになります。

「スキル」は身につけ、「センス」は磨く

熟達を考えるうえで、避けて通れないのが「センス」という言葉です。開発現場では「ひらめきが必要か」という問いをよく受けますが、私は不要だと考えています。

ソフトウェアは論理を積み上げて作るものです。思いつきで開発することはありません。もし「ひらめき」と呼べるものがあるとするなら、それは考え抜いた先に見つかるものであり、それもやはり経験に基づいています。

熟達に必要なのは、スキルとセンスの使い分けです。

スキルは、答えがある知識や技術です。本人が持っていないものを学習し、鍛錬によって身につけるものです。

対してセンスは、正解がないなかで「良し悪し」を判断する感覚です。これを私たちは審美眼と呼ぶこともあります。

「美しいコードとは何か」「良い設計とは何か」がわかること。コストや時間といった状況下で、適切なトレードオフの決断ができること。これらはスキルというより、磨き上げるべきセンスの領域です。AIは選択肢を提示してくれますが、最後に決めるのは自分自身であり、その判断にはセンスが求められます。

フィードバックと客観視でセンスを磨く

では、正解のないセンスをどうやって磨けばよいのでしょうか。

そこで重要になるのが、熟練者からのフィードバックです。自分が作ったものに対してレビューで「良い」「悪い」という判断をもらう。なぜ悪いのか、どうすれば良くなるのかという判断基準を、自分の中に少しずつインストールしていくのです。これには、作ったものにフィードバックをもらうループを回すのが一番の近道です。

加えて、センスを磨くためには「良いものを見ること」も欠かせません。自分の目が肥えていなければ、自分が作ったものに対しても妥当な良し悪しの判断が下せないからです。美しいものを見なければ、美しさを会得することはできません。ベテランが作る作品としてのコードを見ることは、自らの目を肥やすことにつながります。

さらに、後進のコードをレビューすることも重要な経験になります。今度は自分がフィードバックする立場になることで、より客観的な観点が得られるようになるからです。また、相手に良し悪しを説明するプロセスを通じて、自分の中にある感覚を理論化していくことにもなります。

鍛錬をつなげる仕組みとしての徒弟制度

知識を得て、経験を積み、センスを磨く。これは一朝一夕でできることではありません。特に、たった一人だけで熟練のソフトウェア開発者になるのは非常に困難で、相当な時間と才能が必要です。

そこで私たちソニックガーデンでは、あえて「徒弟制度」という形の育成の仕組みを導入しています。これは、昔の職人のように師匠の身の回りの世話をするといった類のものではなく、プロの技術を間近で見て学び、自ら実践し、フィードバックを受けるための合理的な育成の仕組みです。

私たちの徒弟制度では、経験豊富なベテランプログラマーが師匠である「親方」となり、数名の「弟子」を直接指導します。親方と弟子は、最初は同じオフィスで働いて、セルフマネジメントの基礎を身につけることから始まります。親方は、仕事の中で良いソフトウェアを作るための機会を与えます。

弟子は、ただ教わるだけでなく自ら実践しなければ身につきません。しかし、実践するだけでは正しいフォームは身につきません。だからこそ、親方がフィードバックを行うのです。できることを増やして、段階的に成長していくことをガイドします。

この徒弟制度という環境で成長を促進することはできますが、最終的に伸びるかどうかは本人次第です。面白さを原動力に、地道な練習とフィードバックを積み重ねること。それが、仕事を技芸とするための唯一の道だと言えるでしょう。