前回の記事の最後に、こう問いかけた。「育った先に何があるのか。技芸をどう認め、どう報いるのか。結果で測れないものを、組織としてどう扱うか」。今回はこの問いに向き合ってみたい。

評価とは権力である

かつてプログラマとして、評価される側にいた。エンジニアとしての技術力には自信があった。しかし、技術力があるだけでは評価されない。それ自体は理解できる。

問題は、良い案件にアサインされるかどうかで評価が大きく変わることだった。上司が有能だったり、良いお客さまに恵まれたりすると、特別な力がなくても評価される。逆もまたしかり。つまり、評価には運が大きく影響する。運で自分の評価が変わることに、強い憤りを感じていた。

そもそも、人が他人を正確に評価することなどできるのだろうか。評価する・される関係では、対等な対話を築くことは難しい。評価される側は評価者の目を気にするようになり、評価のために仕事をするようになる。

嫌々仕事をする姿を見るのは耐えられなかった。評価で人を動かすのではなく、自主性・自立性を高める方にこそ力を注ぎたかった。

評価とは権力なのだ。やりたかったのは、その権力をなくすことだった。

内発的動機を守る

技芸は内発的な動機で駆動される。いいソフトウェアをつくりたい、自分の作品だと感じたい、作ったもので喜んでもらいたい。そうした気持ちは外からは与えられない。

こんな寓話がある。ある金持ちの芝生の庭で、近所の子供たちが勝手にサッカーをしていた。芝生が荒れて困った家主は、何度注意してもやめない子供たちに、サッカーの後に少しお金をあげることにした。何日か続けたあと、お金をあげるのをやめた。すると子供たちはサッカーをしなくなった。もともと楽しくてやっていたことが、お金のためにやることに変わってしまったのだ。

技芸的な仕事も同じだ。報酬差やランク付け、目標達成による昇進といった外発的な動機づけは、むしろ内発的な動機を壊してしまう。お金のことを気にせず、仕事に没頭できる環境をつくること。それが私たちの目指した姿だった。

評価のない十年

だから会社をつくったとき、評価制度はなくした。前に書いたように、給与はほぼ一律にし、賞与は全員で山分けにした。評価するのも、されるのも嫌いだったし、評価で人を動かすこともしたくなかった。

清々しかった。一定の基準を超える人だけを中途で採用していたから、フラットな運用で問題がなかった。自立した人たちが、自分の仕事に誇りを持ち、お互いを信頼して働く。評価がなくても、いい仕事は生まれていた。

評価面談の代わりにやっていたのは「すりあわせ」だ。半年に一度、社長である私と一人ひとりが1on1で対話する。YWTというメソッドを使い、やったこと（Y）、わかったこと（W）、次にやること（T）を一緒に確認していく。評価ではないので、うまくいったこともそうでなかったことも素直に出せる。失敗があっても、その先に繋がる学びがあればいい。

すりあわせと呼んでいるのは、本人の未来と会社の未来を「すりあわせる」機会だからだ。すりあう時には摩擦が生まれることもあるが、それは健全なことだと思っている。個人の思いを汲むことで、会社も進化できる。未来の目標を決めるのではなく、今の実感を起点にする対話だった。

フラットの限界

しかし、この仕組みには前提があった。セルフマネジメントができる人たちで構成されている、ということだ。

徒弟制度を導入するより前のことだ。まだ育成の仕組みがなかった頃、セルフマネジメントできる人たちのフラットな環境に、未熟な若者を迎え入れたことがあった。報酬に差はつけていたが、権利は他の社員と同等にしていたし、自主性も重んじていた。

結果として、うまくいかなかった。一方では、まだ仕事もできず成果も出せないのに、権利ばかりを主張するようになった。フラットだから、他の人と同じことを求める。それ自体がセルフマネジメントできていない証拠でもあった。

もう一方では、まわりの仕事のレベルが高すぎて、早々に辞めてしまった。

フラットは万能ではなかった。未熟な人をフラットに放り込むと、増長するか、潰れるか、どちらかになる。階段が必要だった。

この経験があったからこそ、創業十年を機に自主的に若者を採用すると決めたとき、最初から受け入れの仕組みを考えなければならないと思った。階段をつくるなら、何かしらの評価が必要になる。しかし、一般的な目標管理を導入する気にはなれなかった。

目標管理では技芸を測れない

多くの企業が取り入れている目標管理制度（MBO）は、半期ごとに目標を立て、達成度で評価する仕組みだ。しかし、技芸的な仕事にこのやり方を当てはめると、いくつもの問題が起きる。

まず、目標を立てる時点で駆け引きが始まる。高すぎる目標を設定すると達成できず低い評価になるから、絶妙にクリアできる水準に目標を置こうとする。結果として、低めの目標を設定した人が評価される構造になってしまう。

次に、半年の間に状況は変わり続ける。新しい仕事が始まったり、案件の内容が変わったりする。当初の目標にこだわれば仕事にならないし、目標を無視すれば評価できない。どちらにしてもズレが生じる。

さらに、個人評価が強すぎると、チームの中で助け合おうという気持ちが薄れる。自分の目標達成に集中するあまり、困っている仲間に手を差し伸べることが損になってしまうのだ。

そして、評価をわかりやすくしようとすると、数字で測れるKPIに頼ることになる。しかし、チームで仕事をしていく上で、数字に現れてこない貢献は多い。ミーティングをさりげなくファシリテーションしてくれる人、大変そうにしている人のケアをしてくれる人。チーム全体には欠かせないが、数字には簡単には現れてこない。

数字で測れるものだけを見ていると、測れないものを見る力が衰えていく。評価する側も、される側も、数字に頼るほど頭を使わなくなってしまう。

数字そのものが悪いわけではない。数字はバロメータとして使えばいい。問題は、数字をノルマにしてしまうことだ。

そもそも、目標を立てるということは、未来を確定させようとする行為だ。一週間先ならまだ見通せるが、半年、一年となると不確実性が高すぎる。不確実な未来について確定した目標を決めて、その達成度で評価する。それは工業的な結果思考であり、技芸的なプロセス思考ではない。

今を一生懸命に生きる、できる範囲でベストを尽くす。私たちが大事にしたいのは、そちらの方だった。

徒弟制度とキャリブレーション

目標管理ではない方法が必要だった。そこで私たちが取り入れたのがキャリブレーションだ。前回までに書いた徒弟制度と、このキャリブレーションは表裏一体の関係にある。徒弟制度だけでは、昔ながらの権力構造を生み出してしまう可能性がある。親方が弟子を評価し、親方の意向で弟子の処遇が決まる。それでは、なくしたはずの権力が形を変えて戻ってきてしまう。

キャリブレーションとは、評価ではなく「期待のすり合わせ」だ。もともとは取締役CTOとして関わっているクラシコムで生まれた仕組みで、私たちも取り入れている。

目標の達成度で評価するのではなく、「今この人にどういうことができるのか」の実態を見る。見るのは二つの軸だ。一つはパフォーマンス。もう一つはコスト。ここでいうコストとは、教える手間、心配する負荷、代わりに判断する頻度といったマネジメント上のコミュニケーションコストのことだ。

この二つの軸で実態を見て、それに合ったロールを決め、ロールに紐づいた報酬を出す。期待に応えてくれたら、まず感謝する。それ以上の成果が安定して見られるようになったら、次のステップを用意する。

大事なのは「先に上げない」ことだ。クラシコムの青木社長はこれを「Tシャツピチピチ理論」と呼んでいる。子供にぴったりのTシャツを着せて、体が大きくなってピチピチになったら、ワンサイズ上げる。最初からブカブカの服は着せない。実態が先で、等級は後追い。

よくある失敗は、期待を込めて先に等級を上げてしまうことだ。有能な人が昇進を重ねた結果、能力を超えるポジションに就いてしまう。ピーターの法則と呼ばれるこの問題を、実態先行の仕組みが防ぐ。

全員でのコンセンサス

キャリブレーションのもう一つの要は、親方一人に任せないことだ。弟子のキャリブレーションは親方が行うが、一般的な会社のように上司一人で評価するのではなく、親方たち全員が集まり、経営陣が加わって、全員でコンセンサスをとっていく。

そうすることで、よりフェアになるし、親方一人に権力が集中しない。

キャリブレーションの場では、どういった観点で弟子たちを見ていくかを議論する。これが非常に難しく、面白い。以前の記事で示した「練度・広さ・セルフマネジメント」の尺度が基本的な指針になっているが、それだけではない。ロールに期待する内容そのものも、半年ごとに見直していく。事業も組織も変化するのだから、ロールの定義を固定しておく方が不自然だ。

こうして半年ごとに続けていくことで、育成に対する解像度が上がっていく。制度自体がアップデートされていくのだ。

一般的な人事制度は、一度決めたらずっと同じ内容で運用し続けることが多い。キャリブレーションは、変化に応じて柔軟に対応するアジャイル的な仕組みだと思っている。

モチベーションを高めようとするのではなく、モチベーションを阻害する要因を取り除く。評価のために頑張るのではなく、お客さまと仲間のために頑張れる状態をつくる。それがキャリブレーションの目指すところだ。

キャリアは探索的であっていい

私たちにとって、職種の前にソニックガーデンの仲間であることが先に来る。だから仕事の中身や役割は変わっていくことがあるし、変わる前提でいる。評価のための目標どころか、先々のことは本当に決めない。先のことを決めすぎないのが、技芸を大事にする組織のあり方だと思っている。

一人前の定義は時代や組織によって変わる。用意されたチェックリストをこなして昇格していくのではなく、回り道をしたり、失敗したりしながら、探索的にキャリアをつくっていく方が、結果として強くなる。

キャリブレーションの仕組みは、この探索を支える。今の実態を見て等級を決めるから、回り道をしても損にならない。寄り道した経験が、いつか思わぬ形で活きることがある。私たちの主事業はクライアントワークだが、当人のやりたいことを重視した結果、自社プロダクトが生まれたこともある。キャリアを探索的にすることで、組織も強くなり、できることも増えていく。それは「結果で測る」のではなく「プロセスを信じる」ということだ。

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

結果をコミットするために仕事をしているわけではない。やることの方を大事にし、しかもやることのプロセス自体が楽しく、やりがいのあるものでないといけない。「結果ありきで手段は問わない」を突き詰めると、最悪のケースは不正会計のようなことが起きる。

努力はするが無理はしない。ベストエフォートで頑張り、結果はついてくるだろうし、ついてこなかったらそれはしょうがない。仕事をやっていること自体、仲間とコミュニケーションを取ること、仕事を通じて人生を豊かにすること。それが私たちの価値観だ。

四章を通じて、コミュニティ、セルフマネジメント、徒弟制度、そして評価と語ってきた。組織を技芸で満たすために、私たちはこうした道を歩んできた。権力ではなく信頼で、結果ではなくプロセスで、制度ではなく文化で。それが、技芸を組織で育むということなのだと思う。

参考記事

• アジャイル思考でつくるエンジニア組織の人事制度〜「評価」から「期待のすり合わせ」へ
• 自立した人が「ここがいい」と思える会社〜人事の専門家に話した経営スタンス
• 個人評価をなくした会社の1on1面談の仕方「すりあわせ」
• キャリア自律の考え方〜キャリアかビジョンか
• 予測型マインドセットと適応型マインドセットの違い、アジャイル思考の本質
• “評価”ではなく”期待”をする　目標管理をしないクラシコムの「キャリブレーション」

チャットの時代は、AIは頭だけの存在だった。考えてはくれるが、手は動かしてくれない。エージェントは違う。手も動かしてくれる。しかも、優秀な手だ。なんだったら、頭もいい。自分よりも頭がいい。

頭の良さで対抗しない方がいい。私は降伏した。無駄な抵抗をやめて、考えることも委ねるようにした。そこから少しずつ変わっていった。

考える力や文章を書く力が衰えていく感覚がある。怖い体験だった。

だけど、任せた方が早く良いものができる。粗い状態から始まるが、ブラッシュアップすらも任せていける。納得がいくまで繰り返せばいい。

今の私の仕事は、エージェントに仕事を頼むことだ。ある部下に仕事を頼んで、別の部下の相談にのって、また別の部下に仕事を頼む。その部下たちはすべてエージェントだ。人間である上司の私はお手玉状態で、4エージェントくらいが限界だ。

閑話休題。

エージェントに任せると、能力が衰える。それは事実だと思う。しかし、だんだんとエージェントの使い方が上達してくる。どんなものでも仕組み化できないかと考えるようになる。手放して、失うと同時に、何か別のスキルを獲得したような感じがする。

エージェントを使っていると、自分の頭脳が拡張された感じがする。自分で考えているのか、AIが考えているのか、あまり意識しなくなる。境界が曖昧になっていく。

だけど、アウトプットの量と質は確実に上がっている。

車の運転に似ている気がする。

右に曲がるときにハンドルを何度の角度まで回すかなんて、覚えていない。操作の詳細を考えることなく動かせる。車のサイズが変わっても、すぐに慣れる。ある時から、車は体の一部になった。

車に乗るようになったら、足腰が弱くなっていく。毎日歩いていた人が歩かなくなれば当然だ。しかし、その分、楽に遠くまで行けるようになる。行動範囲が広がる。

初めて車の免許を手に入れて、自分の車を持ったとき。遥か遠くまで行けるようになって、世界が自由になったような気持ちになった。それを、今あらためて感じている。この歳になって、そんな気持ちになれるのは僥倖だ。

AIの活用も同じだ。頭脳は弱くなるけど、AIを操作する能力が上達することで、もとの頭脳だけでやるよりも、はるかにたくさんのことができる。

実際、車が登場したときの状況に似ているのかもしれない。当時、馬車や徒歩の人たちは抵抗しただろう。しかし誰もが車を運転するようになれば、足が速いことや体が丈夫なことは誤差になる。

身体の弱さがハンディキャップにならなくなった。それはむしろ喜ばしいことだ。AIも同じで、頭脳の差がハンディキャップにならなくなる時代が来るのかもしれない。

運転には慣れが必要だ。センスがあればレーサーになれるが、ほとんどの人はそんなことを求めていない。普通に運転できればいい。

一方で、車が普及しても、いまだに歩く人はいるし、ジムで走ったりもする。だから、自分の頭脳を鍛える時間をとってもいい。頭脳を鍛えるのに適しているのはプログラミングではないか、と思ったりもする。

AIエージェントも、車と同じ感覚でいる。怖さはあるが、降伏した先に、思っていたのとは違う景色がある。

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

ミシマ社との出会い

ミシマ社の三島さんとの出会いは、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” の終焉は、ブログの終わりではなく、ブログへの原点回帰なのかもしれないな。