Social Change!

エンジニアだけでチームを組むと、作ることがゴールになる

2026-09-11T16:59:13+09:00

先日の対談で、エンジニアだけでチームを組むと、作ることがゴールになってしまう、という話をした。

チームとは、共通の目的のために協力して行動する集団のこと。目的の達成を目指さないなら、チームではない。人が集まっているかどうかではなく、同じゴールを持っているかどうかで決まる。だから先にゴールを決める。必要な顔ぶれは、そこから決まる。

人数は関係ない。二人でもチームだ。逆に、一緒に働いていても、チームとは限らない。私たちソニックガーデンの親方と弟子は、毎日一緒に仕事をしているが、チームではない。育てる側と、上達する側の関係だ。チームは、形の違うピースの大きさが揃ってはじめて、一枚の絵になる。親方は弟子の上位互換で、弟子にできることは親方にもできる。だから、隣に置いても噛み合わない。

エンジニアだけを集めると、形の同じピースばかりが並ぶ。そこで共有できるゴールは、作ることしかない。つまり納品だ。動くものができたら、そこで終わる。どれだけ結束が強くても、その先へは行けない。AIエージェントがメンバーのように働くいま、同じ力量の人を何人も並べる理由も減っている。

作ることがゴールになるのは、作る人の腕の問題ではなく、構造の問題だ。完成をゴールにすると、その外側にあることは後回しになる。使われ方も、その先の運用も、締切が迫れば真っ先に削られる。引き継いだシステムが扱いにくいのは、たいていそれが理由だ。しかも、それに気づきにくい。そういうチームは、作り終えたときに、ちゃんと達成感を得てしまうからだ。

私たちが「納品のない受託開発」を始めたのは、この構造を変えるためだった。納品をなくせば、完成は区切りにならない。目指すのは、お客様の事業がうまくいくことになる。そうなれば、役割は違うまま、同じゴールを持てる。

このとき、事業を知っているのはお客様で、ソフトウェアを作れるのは私たちだ。形は違うが、大きさは揃っている。提案ができるのも、同じところを目指しているからだ。「一緒に悩んで、いいものつくる」とは、お客様とチームになるということだ。

社員はそれぞれ、お客様とチームを組んでいる。そうなると、私たちの社内でチームを組む場面は、ほとんどなくなる。では、ソニックガーデンという集まりは何なのか。コミュニティだと考えている。ありたい姿はあるが、達成して終わるゴールがないからだ。

ゴールを目指すチームであるならば、ゴール達成のために体制を考えることが王道だろう。コミュニティだったら、誰と一緒にいるかが先にくるけれど。

AIが書いた原稿は、自分で直さない〜書き手から、編集者へ

2026-09-09T09:24:00+09:00

AIで書いたな、と分かってしまう文章が増えました。ブログでも、資料でも。中身が薄くて長い。整ってはいるのに、面白くない。読み口が最後まで同じ調子で続く。いわゆる、AIっぽさです。

私も、ブログも本の原稿も講演資料も、いまはAIに書かせています。手を動かさなくなって、ずいぶん経ちました。それでも、AIが出力したものを、そのまま出すことはありません。

AIに書かせたから、AIっぽくなるわけではありません。本稿では、AIっぽさの正体は何か、AIは育てられるのか、AIに書かせるときに何をしているのか、これから求められるのはどんな能力なのかについて書きました。

AIっぽさは、編集が入っていないから

出てきた原稿がAIっぽいのは、AIの性能の問題ではありません。そこから編集作業をしていないから、AIっぽいまま出ることになるのです。

削られていない。順番が組み直されていない。自分なら使わない言い回しが、そのまま残っている。必要な情報が揃ったところで、原稿が止まっている。

ただ、情報が揃っているかを見ているのは、書く側の都合です。編集するなら、別のところを見ます。読み飛ばされないか、この順で頭に入るか、ここで飽きていないか。文章の良し悪しは、そちらで決まります。

AIが、読む人を考えていないわけではありません。想定読者を伝えれば、そのつもりで書いてきます。ただ、そこで詰まるかどうかは、読んでみないと分かりません。読む人の側に立って読み直す工程は、別に要るのです。

これは、AIが出てくる前から同じでした。自分で書いた文章でも、書きっぱなしで出すことはないはずです。読み返して、言い回しを変えて、順番を入れ替える。本や雑誌の原稿なら、そのあとに編集者が入ります。

自分の文章にするために必要なのは、書かせる力ではなく、編集する力です。

自分の文体は、AIに教えることができる

一方で、AIには書かせない、と決めている人もいます。AIが書くと、どれも同じような文章になる。当たり障りがなくて、つまらない。書くことに矜持のある人ほど、そう言います。かく言う私も、そういう時期がありました。

たしかに、素のAIに書かせれば、素のAIの文体が返ってきます。自分の文体を教えていないのだから、当たり前です。それはAIの限界ではありません。まだ何も教えていない、というだけです。

ただ、文体を教えるのは一度で済みません。何が自分らしくて、何がそうでないか。それは書いてみて、違うと感じて、初めて言葉になります。何度もフィードバックは必要です。

それでも教えたことが消えずに残れば、次はそのぶん違うものが出てきます。一度きりの指示ではなく、教えたことが積み上がっていく。AIは、育てることができるのです。

つまり、問われているのは、どんな指示を出すかではなく、どう育てるか、です。

文体は、指示するのではなく蓄積させる

原稿は、Gitで管理しています。GitHubに執筆用のリポジトリを一つ持っていて、ブログも本の原稿も講演のスライドも、AIで書くようになってからのものは全部そこに入っています。

置いてあるのは、大きく三つ。一つめは、スタイルガイド。文体、口調、使う言葉と使わない言葉。人格にあたる部分です。二つめは、書く手順とレビューの観点。三つめは、過去の原稿と企画書。積み上がったものが、次の素材になります。

ポイントは、このスタイルガイドを私が書いていないことです。

最初の版も、AIに作らせました。ブログを十五年以上書いてきて、本も何冊か出しています。それを全部読ませて、この書き手の文体をまとめてほしい、と。一人称に何を使うか、どんな言い回しを好むか。意識していなかったことが、いくつも並んでいました。

そのあとは、書かせるたびに増えます。原稿を読んで、ここは違う、と指摘する。その指摘のうち初めて出たものは、スタイルガイドに書き足しておいてほしい、と頼んであります。だから直させるたびに、ガイドも伸びていく。何度か忘れられて、それは前にも言った、と返すこともありますが、繰り返す回数は目に見えて減っていきます。

やっていることは単純です。頭の中にあった判断基準を、そのつど外に出して積んでいるだけ。プロンプトは消えますが、ガイドは残ります。

構成は先に決めて、分量は最後に決める

いきなり本文は書かせません。まず「ブリーフ」と呼んでいる企画書を作らせます。主張したいこと、対比の構造、想定読者、構成案、論点、タイトル案。それを先に固めます。

企画書なら短いので、読むのも直すのも楽です。ここが違う、この対比はもっとこうだ、と往復して詰めていく。曖昧なまま数千字を書かせてしまうと、直す量が増えるだけです。やり直す手間が、桁で違います。

一方で、分量は決めません。足りないより、多いほうがいい。

レビューをしていると、文字数はむしろ増えます。読み返すうちに、これも言っておきたかった、と気づくからです。書きながら考えが進むのは、AIに書かせても変わりません。だから途中では削らない。

圧縮するのは、最後です。これも丸ごとは任せません。任せると、残したかった一節まで消えます。圧縮案を差分で出させて、ここは残す、これは削っていい、と選んでから適用する。

自分で直すと、AIは学ばない

初稿は70点くらいで上がってきます。そこから何度もレビューする。このとき、私は原稿に一切手を入れません。直したい箇所は、全部AIに言葉で伝えます。

自分で直したほうが早い場面は、いくらでもあります。それでも触らない。AIを一回ごとに付き合いが切れる相手だと思っていると、つい手が出ます。頼み方を工夫し、出てきたものは手直しし、次はまた最初から頼む。同じことの繰り返しです。

部下なら、そうはしません。上がってきた原稿を黙って直して出せば、文章はよくなりますが、その部下は何も学びません。次に頼んでも、また同じところを直すことになる。手を入れた瞬間に、育つ機会を奪っている。

だから、「この言い回しは強すぎる」「この表現は自分では使わない」「この二つは意味が重なっている」と一つずつ返します。以前、講演資料3本に出したフィードバックを数えたら300回を超えていたことがありました。

人間の部下には、ここまでできない。何度も直させるのは申し訳ないし、戻ってくるまで早くても一日二日かかる。どこかで妥協することになります。

AIには、気を使わなくていい。何回でも直させられるし、戻ってくるのは数分です。捨てても惜しくない。作り直すコストが下がると、納得できないものを納得できないと言えます。

こうして返し続けていると、初稿そのものが変わってきます。何度も直させるのは変わりませんが、同じ指摘を繰り返さなくて済むぶん、前なら手が回らなかったところまで詰められるようになりました。

原稿は触らない。手を動かすのはAI。だけど、一貫して判断は自分がしているのです。

編集者しか、いなくなる

この記事でも、私は一文字も書いていません。やっているのは、上がってきた原稿を読んで、直すところを伝えることだけです。これは執筆ではなく、昔から編集と呼ばれてきた仕事です。ただし、間違いなく私が書いた作品としての自負があります。

ライターが書いて、編集者が直す。長いあいだ分かれていたこの分業が、編集に一本化されていくのでしょう。

では、編集者が一人いれば足りるのか。そうではありません。編集者の仕事に、別の編集者がレビューを入れることはあります。

今月出る新刊が、そうでした。AIが書き、私が編集して原稿にする。その原稿に、版元のミシマ社の編集者がさらに手を入れてくれました。それで見違えるほど面白くなった。編集は、重ねられます。

編集の細かい技術は、そのうちAIができるようになるでしょう。それでも、編集という行為はなくなりません。何を残し、何を削り、どの順で読ませるか。そこには必ず、意図が入るからです。

その意図は、どこから出てくるのか。読み手の側からです。編集という仕事の土台は、読むことだと感じています。

AIで書けるようになっても、編集は要ります。これから求められるのは、書き手としての能力よりも、読み手としての能力なのかもしれない。

AIに書かせても、考えを整理しているのは自分だった

2026-09-07T07:01:00+09:00

ブログを書き終えると、記事ができあがっていると同時に、自分の考えの方も整っているという時がある。むしろ、自分の考えを整理するために書いていると言っても良い。

なぜならば、読者に伝えようとして書くからだ。この言い方では届かない、そもそもなぜ自分はこんなことを言うのか。何度も読み返して直しているうちに、頭の中にあった思考のタネが、ロジックを伴った文章になっていく。

読み返すときは、自分ではない誰かの目で読んでいる。ここは飛躍している、ここは言葉が足りない。他人の視座で自分の文章を疑うから、考えの穴が見つかる。

書くことの果実は、できあがった文章よりも、この内省の方が大きいのかもしれない。

これは、AIと一緒に書くようになっても変わらなかった。

いまはエージェントに書かせることが基本だ。それでも、出てきた文章を読んで、これでは伝わらないと直す。なぜそう言えるのかを足す。順番を入れ替える。やっていることは、自分で打っていた頃と同じだ。

最初の読者は、いつでも自分だ。エージェントが書いたものを読んで、ここは伝わらないと返す。書き直してきたものを、また読む。ひとりで唸っていた時間が、キャッチボールになった。

書くことは、タイピングすることではない。誰かに読まれるために、外に出すことだ。しかも一回でポンと出して終わりではなく、伝わるまで何度も直していく。その仕上げていく行為が、AI時代の「書く」ということになる。

AI時代になって、文章は誰でも書けるものになった、と思われている。そうではない。

経験に伴った思想が載らない文章なら、誰でも書ける。だが、自分の経験から出た思想を載せて、伝わるところまで仕上げられる文章は、そう多くはない。誰でも書けるようになったのは、前者だけだ。

この仕上げる力は、AIの登場以前から必要だった。トレーニングみたいなもので、書けば書くほど上達していく。

上達した人がAIを使うと、時間が短くなる。同じ時間で、もっと密度を上げられる。差がつくのは、そこではないか。

ただし、仕上げる力だけでは足りない。経験のない分野では、出てきた文章の何が足りないのかがわからない。私にも、そういう領域はある。

だとすると、こだわるべきは、自分の手でタイピングすることではない。AIを使ったとしても、伝わるまで直しを繰り返して自分のものにできたのなら、それは自分の作品だ。

考えをまとめるために書く。その手段としてAIを使う。この二つは排他ではなく、併存できる。早く、そうした考え方が当たり前になると良いんだがなぁ。

ソフトウェアは組織である〜「所有か利用か」の次に来る、Software as an Organization

2026-09-03T13:13:00+09:00

先日、ソフトウェアとは経営にとって何なのか、という話になりました。長く一緒に経営とソフトウェアに取り組んできたクラシコムの青木さんとの対話です。事業を動かす基幹システムを自分たちで作り、育て続けている会社で、私はそこでCTOを務めています。お互いに分かっているつもりでいたのに、いざ一言で言おうとすると、言葉が出てきませんでした。

道具、と言えばそうなのでしょう。ただ、道具と呼んだ瞬間に、使う人と使われるものに分かれてしまいます。買ってきて、置いておいて、必要なときに手に取る。ソフトウェアは、そうはいきません。動かし続け、直し続け、事業が変わればかたちを変えています。

サービスと呼ぶこともできます。Software as a Service という言い方は、すっかり定着しました。ただ、これは受け取る側から見た言葉です。作って、抱えて、変え続ける側から見た言葉が、まだありません。

その日は答えが出ませんでした。あとになって思ったのは、当てはめる言葉を探すより先に、比べる相手を間違えていたのではないか、ということです。ソフトウェアは、組織によく似ています。

ソフトウェアは、なぜ「完成」したことになるのか

理由の一つは、会計の扱いにあるように思います。ソフトウェアは、固定資産に計上されます。帳簿の上では、工場や建物と同じ列に並ぶ。何年かけて償却するかを決めて、時間とともに価値が目減りしていくものとして管理されます。

そうやってモノの側に置かれると、完成があるように見えてきます。工場なら、建ててしまえば、あとは動かすだけです。同じ感覚で、ソフトウェアも作り終えたら、あとは使うだけだと思ってしまう。

以前、システムは負債にも資産にもなると書きました。あれは帳簿の話ではなく、育て方の話です。会計上どう計上されようと、ソフトウェアが動き続けるものであることは変わりません。

作る側も、同じように考えています。緻密なスケジュールは引くのに、ロードマップを更新するという発想がない。完成させて引き渡すところまでが仕事だと考えていれば、そうなります。ソフトウェアを作る仕事は、長いあいだ製造業のかたちで語られてきました。

組織なら、こうはなりません。組織を固定資産に計上する会社はないし、「うちの組織は完成した」と言う経営者もいない。採用して、育てて、配置を変えて、制度を変えて、ずっとやり続ける。放っておけば緩んでいくことも、みんな知っています。

ソフトウェアについて言われてきたことは、そのまま組織について言えることでした。

技術的負債と組織的負債は、同じものだ

ソフトウェアには、保守性という言葉があります。あとから変えやすい状態を保っておくこと、と言い換えてもいい。機能が増えても、直したい箇所にすぐ手が届く。誰が読んでも、何をしているか分かる。目に見える成果とは別のところで、その状態を保つために手をかけ続けます。

放っておくと、その場しのぎの対応が積み重なって、あとから変えられなくなっていきます。技術的負債と呼ばれるものです。負債という言い方のとおり、溜まるほど身動きが取れなくなる。

組織でも、同じことが起きます。そのときは仕方のなかった特例が残り、例外に対応するためのルールが積み上がり、気づけば何かを変えようとするたびに、あちこちに断りを入れなければ動かなくなっている。以前、これを組織的負債と呼びました。

属人化も、どちらでも起きます。あの人がいないと回らない仕事が増えるのと、一人しか触れないプログラムが増えるのは、起きていることが変わりません。どちらも、書き残されていないこと、渡されていないことが原因です。

ソフトウェアには、内的品質と外的品質という分け方もあります。外的品質は、使う人から見える動きのこと。内的品質は、外からは見えない、変えやすさのことです。経営から見えるのは、たいてい外側だけになります。

組織も同じです。売上や成果は見えるけれど、人が育っているか、風通しがいいかは、数字に出てきません。内側への投資を後回しにしても、そのときは何も起きない。効いてくるのは、変えようとしたときです。新しい機能を足そうとして、あちこち直さないと入らないと分かる。新しい事業を始めようとして、任せられる人がいないと分かる。そこではじめて、後回しにしてきた年数が、まとめて表に出てきます。

ソフトウェアの品質特性は経営にも当てはまるのではないか、と以前に書いたことがあります。いま思えば、当てはまるのではなく、同じものを別の言葉で呼んでいただけでした。

構造が絡み合っているほど、伝えることと確かめることが増えていきます。『人が増えても速くならない』と一冊かけて書いたのはソフトウェア開発の話でしたが、組織でも変わりません。

経営がソフトウェアを設計するのは、必然になる

会社には、就業規則があり、稟議の仕組みがあり、決裁の順序があります。どれも、仕事のやり方を書き記したものです。誰が何をして、次に誰へ渡り、どこで承認されるのか。毎回ばらばらにならないように、決めて、書いておく。

ソフトウェアを作るというのは、これとほとんど同じことをしています。注文を受けてから届けるまでに何が起きるのか、どの数字をどこで確定させるのか、例外が出たら誰が判断するのか。決めて、書き記して、そのとおりに動かす。

違うのは、書いたものが自動で執行されるところです。就業規則なら、破ろうと思えば破れます。ソフトウェアに書かれていないことは、起きません。画面にないボタンは押せないし、通っていない経路は通らない。

そして、順序が逆になってきました。

DXという言葉で語られてきたのは、紙や人手でやっていた業務を、システムに移していくことでした。業務のかたちが先にあって、それを写し取るのが開発だった。いまは、ソフトウェアファーストという言い方があるように、ソフトウェアが先にあって、人がそこに乗って仕事をします。ネットの事業に限った話ではありません。店舗でも、工場でも、物流でも、ソフトウェアのないところに業務がなくなりつつあります。

そうなると、ソフトウェアをどう設計するかは、業務をどう設計するかと同じことになります。事業の組み立てを決めているのは、ソフトウェアの構造のほうだからです。

経営がソフトウェアの設計に関わるのは、だから必然です。人事制度を人任せにする経営者はいません。同じように、事業のかたちを決めているものを、外に預けたままにはできません。

経営とソフトウェアは、互いに決め合う

経営がソフトウェアの設計に関わると、決めるという行為が一方通行ではなくなります。

経営がソフトウェアを決めるのは、当たり前のことです。どういう事業にするか、どこで利益を取るか、何を捨てるか。決めたことが、そのままソフトウェアのかたちになります。

ソフトウェアの構造のほうが、経営の意思決定を縛ることもあります。

たとえば、購入の手続きを一段短くする機能を作るとします。作るかどうかを決めるには、その機能の良し悪しだけを見ていては済みません。手続きが短くなれば、買われる数はどれだけ増えるのか。支払いの確定するタイミングが変われば、売上をいつ立てるのかも変わる。在庫の引き当ても、問い合わせの受け方も、返品の扱いも動きます。

一つの機能を作るかどうかを考えることは、事業をどう組み立てるかを考えることと、同じでした。逆に、いまの作りでは入らないと分かれば、計画のほうを変えることになります。ソフトウェアが、事業計画の制約になる。

そして、動かした結果が返ってきます。ソフトウェアが動けば、数字が出る。何がどれだけ使われて、どこで止まっているのかが見える。それを見て、次を決める。

決めて、作って、動かして、また決める。この行き来が回っているとき、経営とソフトウェアは別々のものではありません。一体になっています。

そうなると、CTOの仕事は、作ることではないはずです。

技術を選び、設計を決め、動くものを作る。どれも要りますが、そこで閉じてしまうと、事業のほうから切り離せる役割になります。作って渡すところまでが担当だと決めた時点で、そこに納品が生まれる。

ソフトウェアの構造が事業の制約になるのなら、CTOは、その制約を経営の場に持ち込む人になります。この機能は入りますが、代わりに何を諦めますか。この作りのままだと、来期の計画はここで止まります。決める場で、それを言えるかどうか。

CTOの仕事は、動くシステムではなく作り続ける体制をつくることだと、以前に書きました。いま思えば、あれでもまだ半分です。体制をつくるだけでなく、ソフトウェアの側から経営の判断に関わるところまでが、その役割になってきています。

人の集まりだけが、組織なのか

ソフトウェアは組織に似ている、と書いてきました。逆にしても成り立ちます。組織も、ソフトウェアに似ています。ただの喩えなら、こうはなりません。

組織とは、人の集まりのことだ。長いあいだ、そう考えられてきました。その前提は、AIエージェントに仕事を任せはじめると、揺らぎます。

これまで人がやってきた仕事を、少しずつ代わってもらう。誰に何を任せるか、どこまで任せるか、うまくいかなければ渡し方をどう変えるか。AIエージェントを束ねる仕事は、組織のマネジメントによく似ています。人と組織のマネジメントが得意な人は、AIエージェントを使うのもうまい。

私たちも全社の標準として使っていますが、標準にするのは入り口を揃えるところまでです。使い方そのものは、現場ごとに変わっていきます。担当している事業が違えば、任せ方も、渡す情報も違ってくる。うまい使い方が見つかれば、それが広がっていく。

うまくいかないのは、導入して終わりにしたときです。ツールを配って、使い方を決めて、これで完了、としてしまう。使いながら使い方を変えていけるところがAIエージェントの面白さなのに、一過性の導入では、それごと捨ててしまうことになります。

こうなると、組織を人の集まりだと言い切るのが難しくなります。働き手のうち何割が人なのかは、これから会社ごとに変わっていくはずです。それでも、それを組織と呼ばなくなるわけではないでしょう。

Software as a Service から、Software as an Organization へ

組織という言葉の意味を、広げて考えてみます。人の集まりではなく、目的のために働くものたちの構造。そう置けば、人の集まりも、ソフトウェアも、同じ組織として扱えます。

ソフトウェアの持ち方は、これまで何度か変わってきました。かつては、各社が自前で作っていた。やがてパッケージ製品が出てきて、買ってきて入れるようになった。それがクラウドに乗って、Software as a Service、つまりSaaSになりました。所有から利用へ、という流れです。

では、その次に何が来るのか。

AIによって、内製できる範囲が広がりました。会計や人事のように、法や制度の変更に追いつく必要があるものは、これからも買ったほうが早い。ただ、自社のデータを収めて、自社のやり方で動かすものなら、自分たちで作って足りる場面が増えています。利用から、また所有のほうへ戻りはじめている。

問題は、その戻り先です。所有すると決めたときに、工場や建物と同じ持ち方をすれば、作って終わり、あとは償却するだけ、という扱いに逆戻りします。

だから、ソフトウェアを組織のように扱う考え方がいります。それが Software as an Organization です。

Service は、受け取る側から見た言葉でした。買って、使って、合わなければ乗り換える。Organization は、作り、変え、維持する側から見た言葉になります。

SaaSがなくなるとは思いません。買って使うほうが早いものは、これからも残ります。ただ、すべてをSaaSで揃える時代ではなくなってきました。自分たちで抱えるソフトウェアには、それにふさわしい言葉がいります。

組織もソフトウェアも、マネジメントに完了はない

マネジメントという言葉は、もともと進行形です。組織をマネジメントするというとき、いつか終わるとは誰も思っていません。人が入れ替われば手を入れ、事業が変われば形を変え、うまくいかなければ直す。それを続けることを、マネジメントと呼んでいます。

ソフトウェアも同じです。バージョンを上げることも、動かし続けることも、少しずつ良くしていくことも、どこかで終わる作業ではありません。

だとすれば、組織のマネジメントができている経営者なら、ソフトウェアのマネジメントもできるはずです。新しい何かを学び直す必要はない。すでに手の内にあるものを、対象を変えて使えばいい。

その逆も、すでに起きています。今年の6月、メルカリが、CTOだった方を最高人事責任者（CHRO）と最高AI責任者（CAIO）に就任させると発表しました。AIで開発が速くなっても、意思決定や組織のかたちが変わらなければ、その速さを活かせない、というのが会社の説明です。畑違いに見えるかもしれませんが、ソフトウェアと組織が同じものだとすれば、無理のない移り方でした。

会計が分からないまま経営するのは難しい、というのは、たぶん誰も否定しません。ソフトウェアも、それに近い位置まで来ていると感じています。事業がソフトウェアの上で動いているなら、そこが分からないままでは判断ができない。

ただし、プログラミングができるようになりましょう、という話ではありません。自分で書けたから分かるわけでもないし、AIに作らせられることとも違います。組織を見るときと同じ目で、ソフトウェアを見られるかどうかです。

かといって、技術は知らなくていい、ということでもありません。組織をマネジメントする人が、人のことを分からなくていいとは誰も思わないはずです。ソフトウェアも、中身への関心を手放したら、マネジメントにはなりません。

組織とは、ピープルソフトウェアである

私の持論ですが、ハードウェアでないものは、すべてソフトウェアだと考えています。形があって、触れて、置き場所がいるもの。それがハードウェアで、それ以外がソフトウェアです。

では、組織はどちらでしょうか。

組織に実体はありません。人が集まっているところを見ても、それだけでは組織とは言えない。机も建物も、組織そのものではない。役割があり、決めごとがあり、動き方があって、はじめて組織と呼ばれます。触れるものは、何もありません。組織には、ハードウェアがないのです。

だとすれば、組織もソフトウェアです。

ここまで書いてきた「ソフトウェア」は、正確に言えばコンピュータソフトウェアのことでした。それに対して、組織のほうはピープルソフトウェアと呼んでもいい。コンピュータの上で動くのか、人の上で動くのかが違うだけで、どちらもソフトウェアです。

最初の問いに戻ります。ソフトウェアとは、経営にとって何なのか。

答えは、組織です。そして組織もまた、ソフトウェアでした。別々の名前で呼んできた二つは、同じものだったのだと思います。

働き手が人でなくなっていくこれからは、その境目はもっと薄くなります。役割を切り分けずに全部を持つことも、渡して終わりにしないことも、組織について考えてきたことの延長にありました。ソフトウェアを持つというのは、もう一つの組織を持つということです。

私たちがアーキテクトを置かない理由〜全部を担える人を育てる、という選択

2026-08-24T08:00:00+09:00

先日、モダンなアーキテクチャとは何か、をテーマに対談する機会がありました。一般的に、アーキテクトとは、機能を提供し続けられる基盤を設計する専門職のこと。仕組みを作る人と、その仕組みの上でアプリケーションを作る人を分けて、前者を指す言葉とされています。

私たちソニックガーデンには、その役割がありません。全員をプログラマと呼び、設計から実装まで全部を担っています。なぜアーキテクトを置かないのか。今回、その理由を改めて言語化してみました。

アーキテクトを名乗っていた頃に、足りなかった視点

20代の頃は、私もアーキテクトを名乗っていました。自作のフレームワークを作って、社内に広めたりもしていました。

当時は、難しい問題を、スマートに解けるほうが優秀だと思っていました。どんな要件が来ても受け止められるように、先回りして拡張の仕組みを用意し、例外にも備えて、共通の基盤として整えておく。考え抜いて立派に作れば、評価されるし、喜ばれる。

経営する側に回ってみると、見え方が変わりました。先回りして備えた例外や拡張のほとんどは、実際には使われません。その例外は起きないから、作らなくていい。そう判断して捨てた瞬間に、難しさの8割が消えることがあります。難しい問題を、難しいまま解く必要などなかったのです。

当時の自分に足りなかったのは、設計の力ではありませんでした。事業の役に立つ、という視点です。立派な仕組みを作ること自体が目的になっていて、それが事業の役に立つのかどうかまでは、見ていなかったのです。

役割を切り出すと、そこに「納品」が生まれる

アーキテクチャを設計することは、いまでも大事な工程だと考えています。引っかかっているのは、そこだけを担う役割にすることのほうです。

役割として切り出すと、基盤を作って渡す、という区切りが生まれます。その区切りは、もう納品です。事業は続いていくのに、ソフトウェアだけがどこかで止まる理由はありません。実際、フレームワークごと入れ替えることもありますし、インフラでも、言語でも、必要なら変えます。冒頭の、モダンなアーキテクチャとは何か。私の答えは、変化に対応しやすい状態が保たれていることです。その状態は、渡して終わりにしない人がいて、はじめて保てます。

アーキテクチャをずっと改善し続ける役割、としてのアーキテクトなら、いてもいいのかもしれません。それでも、それだけをする人を置くのは、オーバーヘッドが大きい。だったら、全部やるほうがシンプルです。

事業からコードまで、すべてはソフトウェア開発の「工程」である

事業の戦略を考えることも、要件を整理することも、アーキテクチャを設計することも、コードを書くことも、すべてソフトウェア開発の工程です。役割ではなく、工程。ものづくりの側には、分けなければいけない理由はありません。

一人が全部を担うほど、事業とソフトウェアはぴったり合います。間に人が入るほど、伝言ゲームでズレていく。理屈でいえば、社長が一人で事業もソフトウェアも作れるのが、いちばんズレません。現代の事業において、ソフトウェアがなくていい会社はほとんどないのですから、経営とソフトウェアが一体になっているほど強い。

そして、事業まで理解して作るなら、求められたものを作るだけでは足りません。それはやめましょう、こちらのほうがいい、と提案できることまでを含めて、開発の仕事だと考えています。

できない前提で仕組みを作るか、できる前提で人を育てるか

こう書くと、それは難しい、と言われます。たしかに難しい。事業まで理解して、提案までできる人は、そう多くいません。

だから世の中は、別の形を選んできました。できる人が少ないなら、できない人のままでも仕事になるように、腕のいい人が土台を作る。アーキテクトが基盤を用意し、その上でたくさんの人に作ってもらう。効率よく人が動ける工場を作って、たくさん作る、という製造業の発想です。SIerにいた頃は、私もそう説明していました。

ただ、いま振り返ると、その考えは、作る人たちの可能性を信じていなかったのだと思います。いつまでもできないままであることを、前提にしているからです。

難しい仕事を担える人は、育てられる

私たちが立っているのは、逆の前提です。できる人が少ないなら、できるように育てればいい。

実際、私たちはお客様の会社にCTOのような立場で入り、事業計画やロードマップの検討から、作るところまでを一人で担ってきました。その全部を、プログラマの仕事と呼んでいます。

そして、5年ほど前から徒弟制度を始めました。まず、いいコードを書けるところを徹底する。いまなら、AIを使っていいコードを作れるところ、になります。そこから内部設計、データモデルの設計、要件の整理、事業戦略の検討、そして経営者の相談相手へと、担う範囲を少しずつ広げていきます。範囲が広がっても、仕事は取り替えません。役員も親方も、いまだにコードを書いています。できることが増えて、仕事の縁が広がっていく。

簡単ではありません。5年かけて、ようやく育つ階段が見えてきたところです。

それでも、本当にできないのだろうか、とは思うのです。明治のはじめに、国民のほとんどが文字を読めるようにしようと言ったら、難しいと言われたはずです。90年代に、全員がパソコンを使えるようになる、と言っても同じでしょう。いまは、ほとんどの人が文字を読み、パソコンを使っています。難しさの多くは、いまこの瞬間を見て、難しいと言っているだけなのかもしれません。もっと人間の可能性を信じていい、と考えています。

分けずに全部を担う仕事は、「技芸」になる

アーキテクトという役割を否定したいのではありません。アーキテクチャを考え、改善し続けることは、これからも欠かせない工程です。ただ、できないままを前提にした土台を作ることより、できる人を育てて増やしていくことのほうを、私たちは選びたいのです。

それに、これは効率だけの話でもありません。切り分けられた仕事は、どうしても他人事になっていきます。自分の作ったものが、誰の役に立ったのか。事業はうまくいったのか。それが見えないまま、頼まれたものを作り続けるのは、つまらないものです。

事業から作るところまで、分けずに担う仕事は、大変ですが、最後まで自分の手応えが残ります。作ったものが役に立てば、それが直接わかる。うまくいかなければ、作り替えればいい。そんな働き方を「技芸」と呼んで一冊にまとめたのが、9月に出る新刊『仕事技芸論』です。

「受託脳」から「提案脳」へ〜AI時代に、言われたことをやる仕事は残らない

2026-08-17T17:00:00+09:00

言われたことを、きちんとやる。世の中の仕事の多くは、その積み重ねで回っています。私も、大手SIerにいた10年あまり、そういう世界で働いていました。

11年前に、「受託脳」から「提案脳」へという記事を書きました。言われたものを言われた通りに作る働き方から、相手の先を見て自分から提案する働き方へ。ありがたいことに、いまも読まれ続けています。

当時これは、プロフェッショナルの条件の話でした。どちらの目線で働くかで、信頼も、任される仕事も変わってくるからです。

AIが出てきて、この話の意味あいが変わってきました。本稿では、受託脳と提案脳とは何か、AIの時代に何が変わるのか、そして提案脳へ変わっていくために何ができるのかについて書きました。

受託脳とは、指示を出した相手だけを見て働くこと

受託脳とは、言われたものを、言われた通りにきちんと作る仕事への向き合い方のことです。ゴールは完成させること。見ているのは、指示を出した相手。

受託開発になぞらえた私の造語ですが、業界の話ではありません。上司に言われた仕事をこなし、上司の顔色を見ながら進める。社内の仕事も、殆ど同じ形をしています。

デザインなど、自分にできない仕事を専門家に頼んだ経験から言うと、指摘をすればその通りに直してくれる人に、かえって不安になるのです。こちらがわからないから頼んだのに、こちらが正解を持っている前提で確認されるからです。私の好みではなく、私の先にいるユーザから見ていいものを作ってほしいのです。

目線には、3つの段階があると考えています。自分にできることだけを見ている自分目線。相手が何を求めているかに応える相手目線。そして、相手の先にいる人まで見る、相手の相手目線です。

3つめまで来ると、いちいち確認しなくても、いい感じに仕事が進みます。目的から外れていると思えば、対等な立場で諌めることもできる。それが、提案脳です。

AIは、究極の受託脳である

AIと受託脳には、共通点があります。言われたことを、きっちりやる。ゴールを、他人からもらって動く。

そしてAIは、従来のコンピュータと違い、曖昧な指示でも意図を汲み、正解のない問題にもそれなりの答えを出してきます。嫌がらず、疲れず、いくらでも。言われたことをやる領域では、もう人間の上位互換です。受託脳が目指してきた姿の完成形、いわば究極の受託脳です。

それでも、AIは提案脳にはなりません。頼まれた土俵の中で提案らしきものは出せても、困りごとを見つけて、頼まれる前に動き出す意志がない。言ったことの結果を、引き受けることもない。提案とは、いいアイデアを出すことではなく、その結果に責任を持つことです。中身は出せても、提案者にはなれない。

だから、言われたことをやる仕事は、これからAIのものになっていきます。人に残るのは、何をすべきかを決めて、結果を引き受ける仕事です。プロフェッショナルの条件の話だったものが、仕事が残るかどうかの話に変わったのです。

AIを使うということは、発注者にまわるということです。何を頼むかを決められない受託脳のままでは、AIを使いこなすこともできません。

目線は、できることが増えた結果として上がる

受託脳と提案脳の分かれ目は、目線にあります。ただ、掛け声で上がるものではありません。講演を聞いて目線が上がるなら、いくらでも上がっています。できることが増えた結果として、後から上がるものです。

だから、日々の仕事のやり方から変えます。私たちソニックガーデンで、若手がまず身につけるのは3つです。

一つめは、タスクばらし。大きな仕事を、自分で小さく分解してから取りかかることです。分解するには、何のための仕事かがわかっていないといけません。目的はいつも頼んだ相手の側にあるので、ばらすたびに相手を考えることになり、目線が自分から相手へ動きます。

二つめは、ふりかえり。自分の仕事のやり方を、定期的に自分で見直すことです。誰かに指摘されて直すのではなく、自分で気づいて変える。続けるうちに、自分の仕事を一段外から眺める癖がつきます。

三つめは、ザッソウ。雑談と相談です。結果が出てから報告するのではなく、生煮えのうちに相談してしまう。相談した瞬間、相手は評価する人から、一緒に考える仲間に変わります。同じ側に並ぶと、相手の見ている先まで見えてくる。目線が相手から、相手の相手へ動いていきます。

3つとも、特別な能力ではありません。難しいのは能力ではなく、染みついた習慣を変えることです。

私たちソニックガーデンでは、受託の経験が長い中途の人ほど切り替えに時間がかかるので、入社までに転換の期間を設けています。社内で「血の入れ替え」と呼ぶほどです。一方、新卒や第二新卒は、徒弟制度で親方のもとにつき、最初から提案脳で仕事を覚えます。受託脳は生まれつきではなく、環境が作った習慣。習慣なら、入れ替えられます。

提案とは、企画書を書くことではない

提案というと、企画書を作って、会議にかけて、承認をもらうことだと思われがちです。

SIerに勤めていた頃、社内の情報共有がうまくいっていないことが気になって、仲間と社内SNSを勝手に作ったことがあります。誰にも頼まれず、承認も取らずに始めたのに、使う人は増え続け、最後は会社の公式なツールになり、事業になりました。いまのソニックガーデンの前身です。

その後、これを事業にする社内ベンチャーでは、逆の失敗もしました。製品を売り込んで回っても、まったく売れない。売り込みをやめて、困りごとを聞いて回るようになってから、ようやく仕事が生まれ始めました。

提案の始まりは、困っている人を見つけて、動くものを作って見せること。頼まれてから考えるのでも、こちらの売りたいものを押し出すのでもなく、言われる前に、相手の困りごとから動き出す。その主体性が、提案を生みます。動いているものほど強い企画書はありません。

そして、動くものを作って見せるコストは、AIのおかげで当時とは比べものにならないほど下がっています。

提案脳の正体は、相手とチームになること

受託脳と提案脳の違いを突き詰めると、関係のあり方に行き着きます。受託脳は、発注と受注、上と下の関係の中にいます。会社の中なら、上司と部下です。何を作るかは頼んだ側が決め、成果の責任も頼んだ側が持つ。だから、言われた通りに作ることが正解になるのです。

提案脳の正体は、相手とチームになることです。何をやるべきかを一緒に考え、結果の責任まで一緒に受け持つ。「一緒に」が、核心です。

ただ、発注と受注の関係のままでは、チームにはなりにくい。私がいたシステム開発の世界で言えば、働いた人数と時間で請求する人月の仕組みでは、知恵を出して作らずに解決するほど、売上が減ってしまいます。そこで提案が出てこないのは、意識ではなく構造の問題です。

私が独立して「納品のない受託開発」というビジネスモデルを作ったのは、この構造ごと作り変えるためでした。納品の代わりに、月額定額で顧問のようにずっと関わる。作っても作らなくても売上が変わらないから、利害がぶつからず、それは作らなくても解決できますよ、と言えます。発注と受注ではなく、同じ問題に向かうチームになれるのです。「一緒に悩んで、いいものつくる」という私たちの約束は、そういう意味です。

自分で考えて動く仕事は、面白い

受託脳から提案脳へ。いまや仕事が人に残るかどうかの話になりましたが、やることは変わりません。相手の先を見て、頼まれる前に動き、相手とチームになる。

そして、自分で考えて動いていい仕事は、面白いのです。正解のない問題に向かって、やればやるほど上達していく。受託脳から提案脳への転換は、仕事の面白さを取り戻すことでもあります。

こうした話は、9月に出る新刊『自分と社会をいい感じにする仕事技芸論』（ミシマ社）にも書きました。このテーマで講演したときの資料は、こちらです。

スライドを開く（SpeakerDeck）

マネージャの責任は、自分でやることではない

2026-08-14T16:58:00+09:00

マネージャになった人たちを見ていると、うまくやれている人と、そうでない人がいる。その差は、能力の高さだけではなさそうだ。うまくいっていない人ほど、全部を自分で背負おうとしている。

私たちの会社では、マネージャの仕事を人を活かす「上司」と、人を育てる「親方」に分けて考えてきた。ここで書くのは、人を活かす側の話だ。

うまい人は、上司の使い方が違う。

自分で決めてから承認をもらいに行くのではなく、決める前に相談に行く。一緒に悩んでもらう。上司は、承認した人ではなく、一緒に決めた人になる。

これは、上司を「共犯」にするということだ。責任を押しつけるという意味ではない。決めたあとに持ち込めば、ただの報告になる。決める前に持ち込むから、共犯になる。

上に立つ側から見ても、相談されるのは嫌なことではない。決まったあとに報告だけ上がってくるほうが、よほど遠い。

メンバーに対しては、仕事ではなく、役割を与える。

作業を割り当てられた人は、その作業をやるだけになる。役割を任された人は、自分で考えはじめる。

人は、使命があると元気になる。ここはあなたに任せた、と言われた途端に顔つきが変わる。

13年前にも、少しハードルの高い仕事を任せて、期待を伝えると書いていた。任せること自体が、人を動かす。

では、何を任せるのか。

やりたいことを任せたほうが、元気は出そうに思える。だが、やりたい気持ちだけで任せると、できないまま時間が過ぎていく。周りも待たされる。

できることを任せると、頼られる。役に立って、感謝される。元気は、そこから出てくる。やりたいことは、たいていそのあとに出てくる。

やりたいことは、本人が持ってくるものだ。持ってきた人には、役割ではなく領域そのものを任せればいい。それはもう、リーダーの話になる。

そして、責任のこと。

マネージャになると、責任という言葉が重くなる。自分がやらなければ、と思う。

だが、責任を果たすというのは、与えられた使命を、なんとかすることだ。マネジメントとは、そういうことだ。価値観や倫理観に反しない限り、手段は問われない。

だとすれば、自分でやるかどうかは、手段の一つでしかない。人に頼る、やってもらう、感謝する。それも、なんとかするための手段だ。

上司を共犯にするのも、メンバーに役割を渡すのも、同じことだ。上にも下にも頼っている。

ひとりで背負わないほうが、結果として責任を果たせているのではないだろうか。

やりたいことがうまくいかないのは、頭の中に成功があるからだ

2026-08-13T10:53:00+09:00

会社を15年やってきて、振り返ってわかったことがある。自分がやりたいと思って始めたことは、だいたいうまくいかない。

うまくいったのは、やむにやまれず始めたことばかりだった。

起業したのも、起業家になりたかったからではない。前職で、事業を続けるには買い取るしかない状況になって独立した。オフィスをなくしたのも、地方の社員が増えて、そうするしかなかったからだ。

一方で、余裕が出てきたからと自分で考えて始めたことは、案外うまくいかずに、すっと終わっている。だから、やりたいことがあっても、二の足を踏むようになっていた。

ストレングスファインダーによると、私の強みのひとつは「戦略性」だそうだ。頭の中で先々を読んで、つなげて考えるのは得意なはずなのに、考えて始めたことほど、うまくいかない。

なぜ、自分で考えたことはうまくいかないのか。

この相談を、ザッソウラジオの収録でしてみた。エフェクチュエーションをテーマにした回だ。そこで仲山さんに言われた一言に、目から鱗が落ちた。

「自分がやりたいことは、コーゼーションになりがち」

コーゼーションとは、目標を先に決めて、逆算で計画する考え方。エフェクチュエーションの対になる概念だ。

そう、頭の中で考えた時点で、成功のイメージを先に作ってしまっているのだ。計画を立てて、思った通りにいかないと「失敗した」と認定して、やめてしまう。

うまくいかないから失敗するのではない。頭の中の成功と比べるから、失敗になるのだ。戦略性が強みというのも裏目に出て、つい成功の形まで作り込んでしまう。だが、現実は頭の中で考えた通りにはいかない。

やむにやまれず始めたことは、そもそも成功のイメージがない。ゴールは「なんとかする」だけ。抽象的だから、状況に合わせて形を変えられる。失敗と認定する瞬間が来ないまま、なんとかなるまで続けられる。

もちろん、流されていればいいという話ではない。引き受けたからには、うまくいくように必死で頑張る。そこは変わらない。

プログラミングの世界に「YAGNI」という原則がある。You Aren't Gonna Need It、そんなの要らないよ、の略だ。先を見越して作った機能はたいてい使われない。必要になってから作ればいい、という教えだ。

頭の中の予測はあてにならない。目の前の必要から作ったものだけが残る。エフェクチュエーションで大事なことは、YAGNIだったのだ。

だとすれば、手放すべきは、やりたいことではなく、頭の中で先に作ってしまう成功のイメージだ。やりたいことは、諦めなくてもいいのかもしれない。

この話をしたザッソウラジオのエフェクチュエーション回は、9月から配信されます。ゲストは『エフェクチュエーション』の著者の一人・神戸大学の吉田満梨さんと、デザイナーの青木亮作さんです。

自分で書いた本を、面白く読んでしまった〜アジャイルな執筆体験

2026-08-12T14:55:00+09:00

9月に、新刊『仕事技芸論』が出ます。今回の版元はミシマ社で、これまで書いてきたビジネス書というより、文芸に近い読みものに仕上がったと感じている。

その最終ゲラを読み終えて、不思議な感覚があった。自分で書いた本なのに、先が気になって、面白く読めてしまった。

それだけ、これまでの本と作り方が違ったからだった。

一つめ。テーマはミシマ社からの提案で、『仕事技芸論』というタイトルも三島さんの案だった。最後にタイトル会議も開かれたのだが、頭に「自分と社会をいい感じにする」が付いただけで、主タイトルは最初のまま生き残った。

二つめ。最初に目次を作らなかった。代わりに編集者から質問リストが届き、回答しやすいところから、ブログ記事として週に1本ずつ書いていった。書くたびに感想が返ってきて、それが嬉しくてまた次を書く。読者第一号に向けて連載しているような感覚だった。

三つめ。構成は編集者が組んだ。8割ほど書けたところで届いた目次は、私が書いた順番とはまったく違う並びだった。え、それを第1章に持ってくるのか。そんな驚きがあった。

四つめ。推敲も編集者に委ねた。今回は最初から、遠慮なく直してください、とお願いしてあった。編集者が主体で磨き、私が最終確認する進め方だった。

目次を決めずに、書けるところから書く。すると、形はあとから現れるという、アジャイルな執筆体験だった。これが著者として実に気持ちよく、もっと書きたい、と思いながら最後まで書き切った。

だから、出来上がった原稿は、自分が書いた文章のはずなのに、自分ひとりでは作れなかった本になっている。

これまでの本は、人に薦めるのが少し照れくさかった。自分で書いたものを、自分で自信作だと言うのは、どうにも据わりが悪い。でも、委ねた部分があるからこそ、照れずに誇れる作品になることもあるんだな。

『仕事技芸論』は9月18日発売。自信作、ぜひ読んで欲しいです。

自分と社会をいい感じにする仕事技芸論

Amazonで見る

「労働」から「技芸」へ〜久々の新刊『仕事技芸論』を9月に出します

2026-08-05T08:00:00+09:00

「一番伝えたいことは何ですか」

新しい本をつくるにあたって、出版社の方からそう問われたことがあります。しばらく考えて出てきた答えは、とてもシンプルなものでした。

いい仕事をしたい。そして、いい仕事をすれば、仕事はおもしろい。

これが、私の本心です。

ここ数年、「仕事は必要悪だ」「なるべく減らすべきだ」という空気が強くなってきました。たしかに、消耗するだけの仕事もあります。それでも、仕事そのものを減らすしかないものとして扱うことには、どこか違和感がありました。

仕事には、おもしろい仕事もあります。人生の時間の多くを費やす活動が、ただ耐えるだけの時間になってしまうのは、もったいない。そう思うのです。

では、仕事がおもしろいとは、どういうことなのでしょうか。

「労働」ではなく、「技芸」として働く

私が行き着いた答えは、仕事を「労働」ではなく「技芸」として捉え直す、ということでした。

技芸とは、「技」と「芸」のあいだにあるものです。再現性を重んじる「技術」と、感性や自由を求める「芸術」の中間に位置する。型を磨きながら、少しずつ自分の表現へと育てていく営みです。

19世紀末のイギリスに、ウィリアム・モリスたちが起こした「アーツ・アンド・クラフツ運動」がありました。産業革命によって人が機械の部品のように扱われはじめた時代に、手仕事の喜びと美しさを取り戻そうとした運動です。

本書で書いた「仕事技芸論」は、その現代版のつもりで書きました。情報革命とAIの時代に、働く私たちが、ただの労働力として消費されるのではなく、技芸を磨く存在として生きていく。そのための提案です。

これまで書いてきたことの、底にある一本

私はこれまで、いくつもの実践を本にしてきました。「納品のない受託開発」、リモートワーク、セルフマネジメントで動く組織、そして「ザッソウ」。

それぞれ、別々の話題に見えるかもしれません。けれども、書いている本人からすると、底に流れているものはずっと一つでした。それが「仕事を技芸とする」という考え方です。

私たちはこの理想を、長いあいだ「遊ぶように働く」と呼んできました。仕事に没頭している姿が、傍から見ると遊んでいるように映る、という意味です。今回は、より仕事の側に重心を戻して、「技芸」という言葉を選びました。指しているものは、同じです。

『仕事技芸論』は、その底にあった思想を、一冊の本として書き下ろしたものです。

これは、システム開発の本ではありません

本のタイトルは『自分と社会をいい感じにする仕事技芸論』。ミシマ社から、2026年9月18日に発売します。

自分と社会をいい感じにする仕事技芸論

Amazonで見る

装丁の地になっているのは、このブログのソースコードです。カテゴリの一覧に「仕事技芸論」が並んでいます。そこに、使い込まれた裁ちばさみが重なる。この本に書いたことは、このブログで書いてきたことでした。それが、そのまま一枚の絵になっています。

全部で五つの章があります。なぜ「技芸」なのか。「技芸」とは何か。「技芸」の磨き方。会社で「技芸」を磨くための仕組み。そして、AI時代に、それでも私たちが働く理由。

本の中では、ソフトウェア開発の話をたくさん例に出しています。私の本業がソフトウェアの会社の経営で、いちばん具体的に語れる領域だからです。

ただ、これはシステム開発の専門書ではありません。書いていることの本質は、考えて手を動かすあらゆる仕事に通じます。営業でも、教育でも、企画でも、医療でも。再現性のない、創造的な仕事に関わる人に向けて書きました。

予約が始まっています

発売は9月ですが、『自分と社会をいい感じにする仕事技芸論』（ミシマ社）の予約はもう始まっています。

単行本のソフトカバーで、224ページ。定価は2,420円（税込）です。

そして、この本に書いた考えのもとになった文章は、実はこのブログでずっと書いてきたものです。連載「仕事技芸論」として、少しずつ公開してきました。本になる前の原型は、いまもここで読むことができます。

ただ、本は原型のままではありません。ミシマ社の編集の手が入って、見違えるほど面白くなりました。同じことを書いているはずなのに、順番が変わり、言葉が磨かれ、読み物として別のものになっています。自分で書いた文章を、一人の読者として面白く読んでしまうほどでした。編集という仕事もまた、ひとつの技芸なのだと思います。

いい仕事は、それ自体がおもしろい。仕事が技芸になったとき、働くことと遊ぶことの境目はなくなります。そのことを、一冊の本にしました。

「AIで開発会社は要らなくなる」のか〜16期、社是を「いいソフトウェアをつくる。」に

2026-08-04T08:00:00+09:00

ソニックガーデンは、この7月から16期に入りました。もう1ヶ月が過ぎてしまいましたが、15期の最後の全体会で、一年を振り返りながら、16期に向けて考えていることを話しました。その内容を、ここにも書いておきます。

創業して、15年。始めたときは、10年も続くのだろうかと思っていました。それが15年続いて、いまは70人ほどの仲間がいる会社になりました。まずは、お客さま、パートナーのみなさん、一緒に働く仲間たちに感謝しています。

今年に入って、AIの存在感が一気に増しました。私たちの業界には特に大きく効いてきます。「誰でもシステム開発ができるようになるなら、システム開発を仕事にする会社は要らなくなるのではないか」。そう不安に思う人もいるでしょう。

けれど私は、一周回って、これはむしろ大きなチャンスだと見ています。少なくとも、ソニックガーデンが届けている価値においては、AIは追い風だと考えています。

15期は、広がりの一年だった

まず15期を振り返ると、事業も人も、大きく広がった一年でした。

クラシコムとの資本業務提携。ソニックガーデンとして初めて、株式を使った取り交わしをしました。といっても生株ではなく、ストックオプションのような形で、経営に直接関与するものではありません。長くお付き合いしてきたお客さまと、パートナーとして長期の関係を築くための実験です。一度できたので、他の会社とも進めていけそうです。

採用も広がりました。ご縁をいただいて韓国で新卒採用のイベントを開いたところ、100名以上が集まってくれて、そのうち優秀な3名に入ってもらえることになりました。高校を卒業したばかりのメンバーも、4名が入社しています。

そのほかにも、NHKでの放送、倉貫書房の1冊目とミシマ社との業務提携、世田谷区で始めた小中学生向けのプログラミング部活動「セタプロ」、久しぶりに全社が集まったn2jk合宿。ガバナンスの面では、プライバシーマークから国際標準のISMSへと踏み出しました。ここ数年かけて固めてきたものの、ひとつの区切りです。

一つひとつを数えると、思っていた以上に、いろいろやっていた期でした。

AIを組み込んだ会社に、作り変えた

そして15期の後半、つまり今年の前半は、AIによって会社そのものが変わった時期でもありました。Claude Codeを全社の標準にすると決めて、開発だけでなくコーポレートの仕事も含めて、エージェントを前提とした働き方に組織を作り変えてきました。そのときに何を考えて決めたのかは、以前の記事に書いたとおりです。

私自身、本を書くのもブログを書くのも、いまは完全にエージェントと一緒に作る形になりました。どこまでやれるのかは、まだ誰にもわかりません。それでも私たちは、先駆けて試していきたい。振り回される必要はありませんが、うまく使いこなす側に回るということです。

その上で、ソニックガーデンにとってAIは追い風だと考えている理由が、三つあります。

システムは、使い始めてからが本番だ

システム開発会社は、システムを作れば、それで役割を果たしたことになるのでしょうか。私は、そうではないと考えています。システムは、使い始めてからが本番です。

本番では、必ず何かが起きます。トラブルが起きる。セキュリティの問題が出る。動かなくなることもあれば、ユーザーが急に増えることもある。そのとき、誰が責任を取るのか。

AIがあるのだから、自分たちだけで作ってしまう。それもアリだと思います。実際、そうやって内製していく会社は増えていくでしょう。ただ、いざ本番で何かが起きたとき、その先まで自分たちで引き受けられるか。そこは分けて考えたほうがいい気がしています。

現場で責任を負うとは、お金を払うことでも、謝ることでもありません。何かが起きても、なんとかする。それができることが、責任を果たすということです。では、その力はどこから来るのか。お金をいくら積んでも、人数をそろえても、なんとかできるわけではない。最後に効いてくるのは、技術力です。

私自身、クラシコムの取締役CTOとして100億規模の事業を支えるシステムに関わっていますが、「AIがあるから自分だけでやります、エンジニアも雇いません」とは、とても言えません。怖くてできない、というのが正直なところです。その現場責任を、自分だけで負い切れないからです。だからプロに頼み続ける。この構造は、AIが出てこようが変わりません。AIは責任を負ってくれないのですから。

だからこそ、私たちも心構えを変えてはいけません。AIは使うべきです。手打ちにこだわるのはナンセンスだと思っています。ただ、「AIが出してきたので、よくわかりません」では、責任を果たせない。何を作っているのか、それがどう動くのか、どう設計されているのか、どこで意思決定をするのか。そこを自分の手の内に置いておく。それさえできていれば、私たちは期待され続けるはずです。

人月を捨てたから、速くなった分が余白になる

二つ目に効いてくるのが、ビジネスモデルです。私たちは「納品のない受託開発」で、15年前から人月を放棄してきました。時間単価では仕事をしない。それを実績として15年続けてきた会社は、ほぼありません。

これが、いまの時代にどう効くか。仕事が速く進むようになったとき、その分がまるごと私たちの余白になります。次の改善に手が回るし、新しいことを試す時間も生まれる。時間で売っていたら、速くなるほど売上が減っていくので、生産性を上げることが自分の首を絞めてしまう。業界全体で見れば、そこに苦しさを感じている会社は多いはずです。とはいえ、いまから急に人月をやめると言っても、簡単なことではないでしょう。

15年前、こんなに生産性が上がる時代が来るとは思っていませんでした。それでも、品質と生産性を上げることをよしとして、みんなで取り組んできた。そのカルチャーが、AIで加速したときに追い風になっている。

ただし、ここに甘んじるつもりはありません。生産性の中身は、私たち自身も変わってきています。これまでソニックガーデンが持っていた目安や、働き方の基準も、来期をかけて見直していきます。

弟子の一期生が、主力になる

そして三つ目は、この追い風を受け取る人が育ってきたことです。AIによって、若手が一気に主力になっていくと見ています。とくに、弟子の一期生。弟子と呼び、一期生と呼んでいるうちに、もう30歳前後になり、5年ほど続けてくれました。普通の会社でも、5年いれば中堅です。実力も伴ってきて、「納品のない受託開発」の責任者を担うに値するくらいまで来た、と親方たちも言っていますし、私もそう見ています。

その世代がAIを使いこなせば、生産能力はベテランに匹敵していきます。数年前まで、うちは20代の若手とベテランに分かれていて、その間にあたる30代がほとんどいませんでした。それが、これから30代の分厚い会社になっていく。20代、30代、40代がつながると、少し上の背中を追いかけられるし、少し下に教えることで自分の型も定まる。世代が飛んでいると、この受け渡しが起きません。30代のメンバーには、会社の主力として、その顔になってもらいたいと思っています。

AIと人間を分けるのは、主体性だ

では、AIの時代に、ソニックガーデンで働くプログラマに求められるものは何か。私が考えていることを、いくつか挙げてみます。

まず、AIは使い倒す。これはAIに限りません。クラウドが出てきたときも、私たちは先駆けて使ってきました。新しい道具は、どんどん使って自分の力にしていく。

その上で、AIと人間の一番の違いは何かというと、主体性だと思っています。AIは、主体性を持てません。問いを出すのは人間だし、最初の一歩を踏み出すのも人間です。裏を返せば、主体性のない仕事は、AIに置き換わっていく。もともと私たちが「セルフマネジメント」と言ってきたのは、一人ひとりが主体性を持つ、ということでした。

主体性を持って、何をするのか。ひとつは、意思決定です。AIが出してきたものをそのまま受け取るのでも、言われた通りにやるのでもなく、自分で決める。たとえAIの出力をそのまま使うにしても、「これでいい」と自分で決める。

意思決定は、才能ではありません。練習です。頭のよさと仕事の成果が別物なのも、ここに関わっています。私はたまたま35歳から経営という仕事に就いて、何かあれば最後は自分が問われる場に立ってきました。合理的とは言い切れなくても、しょうがない、これで決めよう、と決め続けてきた。その積み重ねで、いろいろなことを決められるようになった感覚があります。大きな場面も小さな場面もありますが、怖がらずに自分で決めてほしい。決めたあとの始末をつけるのも、自分なのですから。

裏返しになりますが、チャレンジも続けなければなりません。人は、失敗して初めて一人前になるのだと思っています。私自身、経営者としてやれていると思えたのは、赤字続きで大失敗して、それでもなんとかリカバリーできた、助けてくれる仲間がいた、と実感できたときからでした。失敗するためには、チャレンジがいる。全員がチャレンジする会社になっていけたらと思います。

チャレンジと意思決定を積み上げていくと、だんだん自分の持論を持てるようになります。持論があれば、相手が経営者だろうと社長だろうと、対等に話ができる。経営者や社長になるほど、一緒に議論してくれる相手を求めているものです。

社是を「いいソフトウェアをつくる。」に更新した

そして、理念をアップデートします。

これまで私たちは、三つの理念を掲げてきました。社会に対して「いいソフトウェアをつくる。」、お客さまに対して「一緒に悩んで、いいものつくる。」、仲間に対して「いいコードと、生きていく。」。

このうち「いいコードと、生きていく。」は、捨てるわけではありません。ただ、AIがいいコードを書けるようになっていくと、いいコードそのものは、私たちだけの強みではなくなるかもしれない。いいコードの裏にはいい設計があり、その裏にはいい意思決定がある。そう考えると、いまの私たちが最も大事にすべきなのは、コードの手前にある「プログラマの働き方」なのだと思うのです。だから「いいコードと、生きていく。」は、前面から一歩下がって、その土台に回ってもらうことにしました。

同時に、「プログラマ」という言葉を取り戻します。一時期、採用の場面で「プログラマ」と名乗るのをやめようか、という話がありました。けれど、みんな結局プログラマと言っているし、私もこの言葉が好きです。エージェント型のAIを使うようになって、私は自分の本を正々堂々と「自分で書いた」と言えています。それと同じで、AIを使っていても、自分で意思決定しているなら、それはプログラミングをしている。パンチカードがキーボードに変わり、キーボードがエージェントに変わっただけのことです。

そのプログラマという言葉とともに、「プログラマを一生の仕事にする。」を、もう一度掲げます。以前この言葉を外したのは、「一生」は重い、「仕事」は遊びか仕事か曖昧だ、と言われたからでした。けれど、いままさに書いている「仕事技芸論」で、私は、仕事は究極の技芸であり、行き着けば遊びになる、と主張しています。だったら、いいのではないか。先の見えない時代に「一生やるんだぞ」と言えることは、むしろ力強いのではないか。

三つの理念を毎回となえるのは大変なので、いちばん大事なことを中心に置くことにしました。それが「社是」です。会社として是とする、ということ。

社是：いいソフトウェアをつくる。
お客さまへの価値：一緒に悩んで、いいものつくる。
ありたい姿：プログラマを一生の仕事にする。

この三つは、コーポレートサイトの「私たちについて」にも掲げました。

「ありたい姿」というのは、未来の約束ではありません。いまの私たちは、もうプログラマを一生の仕事にできているはずだ、という現在の言葉です。この会社が10年、20年、30年と続いて、私が何度も前言撤回しながらもこの言葉を撤回せずにいられたら、「やっぱりできたね」と言える。そういう言葉として置いています。

社是にした「いいソフトウェア」とは何か。ユーザーと作り手の両方が幸せになるもの、だと考えています。それには三つの観点があります。目的がいい。ユーザーの習慣を変えること。体験がいい。ユーザーが使ってよかったと思えること。そして、作り方がいい。作り手自身が、作ってよかったと思えること。この三つがそろって、初めていいソフトウェアになります。

これからも、変化していく

16期にあわせて、経営体制もひとつ新しくしました。長く執行役員を務めてきた野上誠司が、取締役執行役員に就任しています（詳しくは別の記事に書きました）。

ソニックガーデンは、経営と執行を分けません。開発と運用を分業しないのと同じです。一体でやることに手触りがあり、そこにクラフトがある。私たちは、そうやって技芸として仕事をしてきました。だから取締役になっても、立場や距離が大きく変わるわけではなく、これまでの延長にあります。その延長の先には、副社長の藤原も、私もいます。

だいぶ変わるように見えるかもしれません。それでも根っこは、これまでと同じです。これからも変化していく。その予言だけを残して、16期もやっていきます。どうぞよろしくお願いいたします。

あわせて読みたい

採用トップ｜株式会社ソニックガーデン（「プログラマを一生の仕事にする。」を掲げた、仲間を迎えるためのページです）

【15期社史#0】AI時代に私たちはどう働くか？効率化の先に「豊かさ」を追い求めた1年（ソニックガーデンの公式社史。15期の一年を、より詳しくまとめています）

リーダーに求められる主体性とは何か

2026-08-03T16:53:00+09:00

会社として扱う領域が増えてくると、そこを任せる人が要る。事業が広がるたび、新しい機能が必要になるたび、誰に任せるかを考えることになる。

仕事のできるメンバーに任せればいい、というものでもなかった。言われたことをやりきる人でも、領域そのものを任せると動かなくなる。

リーダーに求められるものは何なのか。主体性、と言ってしまえばそれまでだが、もう少し分けられる気がする。

三つある。やりたいことがあること、持論があること、なんとかできること。

一つめは、やりたいことがあるかどうか。

やりたいことがない人に領域を任せると、無理にひねり出すことになる。逆に、やりたいことがある人は、任せる前から自分で動き始めている。

ただし、そのやりたいことは、会社が向かおうとしている方向、つまりソースと繋がっていないといけない。まったく別の方を向いているなら、それは会社の中でやることではない。

やりたいことがないのは、悪いことではない。任された仕事をきちんとやりきる人は、本当に貴重だ。置き場所が違うだけだと思っている。

二つめは、持論があるかどうか。

やりたいことがあれば持論もある、というわけではない。的確な意見は言うのに背負う気のない人もいれば、やりたいと言うわりに見立てのない人もいる。

社長はこう言うけど、会社としてはこうです。そう言えるかどうかだ。持論がなければ、言われたことしかできない。

これは11年前に書いたことと同じだった。「受託脳」から「提案脳」へという記事で、対等の立場から発注主の意見を諌めるところまで来たら本物だ、と書いていた。相手が顧客から社長に変わっただけだ。

三つめは、なんとかできるかどうか。

言うだけでは何も動かない。といって、全部を自分でやり切る必要はない。周りを巻き込んでも、誰かに頼っても、できる人を連れてきてもいい。とにかく、なんとかする。優秀だと言うとき、指しているのは結局そういうことだ。

ただ、なんとかできるだけでも足りない。前の二つがなければ、その力は言われたことをやる方にしか向かない。

やりたいことがあって、持論があって、なんとかできる。この三つを束ねたものが、リーダーに求められる主体性なのではないだろうか。

長く続けたチームは、難しい仕事に手が届く〜弟子とベテランがはじめて一堂に集まった合宿

2026-07-30T21:35:00+09:00

同じ会社に長くいることは、停滞なのでしょうか。

転職を重ねてキャリアを積むのが当たり前になりました。一つの場所に留まっている人は、機会を逃しているように語られることもあります。私はもう15年、同じ会社で、同じ仲間とやってきました。

先週、熱海で社内の合宿をしてきました。木曜の午後に集合して、金曜のお昼に解散。まるまる24時間を一緒に過ごす一泊二日です。集まったのは、プログラマだけで約50人。

私たちはこれを「ビジョン合宿」と呼んでいます。パソコンを開かず、開発もせず、会社のことをひたすら話す場です。創業まもない頃から続けてきて、進め方は11年前に公開しました。仕事は止まるし費用もかかるので、利益だけを考えれば合理的ではありません。それでも続けているのは、組織のケアになっているからだと考えています。

15年やっても、芯は変わっていなかった

初日は、私が90分ほど話しました。使ったのは、創業したときのスライドです。15年分を順に辿ったのではなく、あのころ何を考えていたかを、そのまま話しました。

話してみて自分でも意外だったのは、芯の部分が思った以上に変わっていなかったことです。やり方はずいぶん変えてきたつもりでいましたが、何のためにやるのかというところは、あのときのままでした。

いまの会社には、社歴が10年を超える人もいれば、入って1年経たない人もいます。過去を懐かしむためではなく、同じ時間の流れをみんなで感じてほしかった。

そのうえで、いまの私の考えも話しました。AIで仕事がどう変わっていくのか、この会社をこれからどう続けていくのか。

当日使った資料を、置いておきます。どちらも2011年、創業した年のものです。

技術者からベンチャー企業経営者へ

スライドを開く（SlideShare）

「納品のない受託開発」にみるソフトウェア受託開発の未来

スライドを開く（SlideShare）

分けずに集まったから、視座の階段が渡った

今回の合宿には、これまでと違うことが一つありました。弟子とベテランが、同じ部屋にいたことです。

これまでは、二つに分けて合宿をしてきました。育っている途中の人と、長くやっている人では、話すべきことが違うからです。

分ける必要がなくなったのは、みんなが育ったからでした。弟子のうち一番年次が上の人は5年目に入り、開発責任者の仕事に近づいてきました。30代の人たちも、ベテランの仕事に手が届くようになってきています。弟子から大ベテランまで、きれいなグラデーションができていました。

それが効いたのは、トークのあとの質疑でした。年代別に4人ずつのグループで話し合って質問を考えてもらい、若い人のテーブルから順に受けていきます。

テーブルが進むにつれて、質問の視座が上がっていきました。はじめはコードの書き方の話。それが「納品のない受託開発」の価値は何かという話になり、やがて組織として提供できるものは何か、というところまで上がっていく。

その行き先には、心当たりがありました。「納品のない受託開発」の価値は何か。この日に使ったスライドの、もう一本がまさにそのテーマでした。15年前に自分が立てた問いに、若い人たちの質問が戻ってきたことになります。

視座は、説明して渡せるものではありません。でも、質問が並ぶのを聞いていれば、自分の少し先に何があるのかは見えたはずです。分けて合宿をしていたら、これは起きませんでした。

翌日の午前は、一人ずつ話して場を締める時間にあてました。3つのグループに分ける予定でしたが、前日の一体感を分けてしまうのが惜しくなって、急に全員でやることに変えました。50人が車座になって、一人ずつ話す。時間はかかりましたが、前日に感じた一体感は私の思い込みではなかったとわかりました。

新卒から大ベテランまで、立っている場所は違います。それでも、同じありたい姿を見ている仲間でした。会社をチームではなくコミュニティとして考えてきたことが、この日はよく見えました。

長く一緒に働くと、難しい仕事に手が届く

その一体感は、ただ長くいるから生まれたものではないと思っています。

一緒にやってきた仲間のなかから、経営を担う取締役が出ました。若手を育てる親方をしている人もいるし、お客さまの会社でCTOのような立場を担っている人もいます。

肩書きは増えましたが、みんなプログラマのままです。私たちにとってプログラマとは、コードを書く人ではなく、ソフトウェアを作る人のことだからです。

なぜそうなったのか。ソニックガーデンは、技芸の場だからだと考えています。そして技芸には、型があります。たい焼きの型のように同じものを抜くための型ではなく、武道や芸事の流派でいう型のことです。共通の型を土台にして、その上で一人ひとりが個性を発揮していきます。

その型を受け渡すために徒弟制度があります。そして型が身についた先には、ベテランになるほど難しい仕事に挑戦し続ける気概と、そうできる環境があります。

私たちが大事にしてきたのは、遊ぶように働くこと、つまりフローの状態で働くことです。フローは、自分の能力と仕事の難易度が釣り合っているときに入る、没頭して時間を忘れるような状態のこと。簡単すぎれば飽きるし、難しすぎれば手が止まります。

だから続けるには、難易度を上げ続けなければなりません。長く一緒にやってくるなかで、私たちはこれをずっとチューニングしてきました。

ただ長くいるだけでは、こうはなりませんでした。長くいながら、一生懸命に挑戦を続けること。そして会社の側も、挑戦できる機会を出し続けること。その両方が要ります。

15年前に一緒に起業した仲間と、「いいソフトウェアをつくる」「プログラマを一生の仕事にする」を変えずにやってきただけです。ありたい姿のまま続けてきたら、手が届く仕事が増えていました。

一つの場所に長く留まることは、停滞と呼ばれがちです。でも、同じ場所で挑戦を続けることには、それだけの価値があるのではないかと考えています。

「エフェクチュエーション」という起業〜成功を追わず、ありたい姿を続ける

2026-07-21T16:00:00+09:00

「成功したら、幸せになれる」。そう信じて走っている人は、多いのではないでしょうか。事業がうまくいったら、目標を達成したら、そのときようやく報われる。裏を返せば、成功するまでは幸せではない、ということになります。

でも、その順番は本当に正しいのでしょうか。

先日、岡山県津山市の起業家コミュニティに招かれて、「成功を追わない起業と経営」というテーマで話をしてきました。起業の場で「成功を追わない」とは、挑発的に聞こえるかもしれません。でも、これは私が15年、会社を経営してきて、振り返った先にある実感です。

「成功を追わない起業」は、矛盾ではない

いま、私はソニックガーデンという会社を、16期目まで続けてきました。社員は70人ほど、売上は11億円ほど。あわせて、上場企業の取締役CTOも務めています。こうして並べると、それなりに成功しているように見えるかもしれません。でも、成功を目指してここまで来たかというと、そうではありませんでした。

起業というと、大きな志を掲げ、退路を断ち、未来から逆算して一発を狙う。そういうイメージがあります。周りにいる起業家も、裸一貫で、銀行から融資を受けて、仲間もいないところから立ち上げた、という人が多い。まぶしく見えます。

私は、そうではありませんでした。始まりは、社内ベンチャーで一緒にやってきた仲間を、会社の都合で失いたくない、というだけのものでした。壮大なゴールから逆算したわけではない。いまあるものを受け入れて、目の前のことに手を打ち続けてきた。そうしていたら、いつの間にか15年が経っていました。

だから「成功を追わない」というのは、努力しないとか、投げやりだ、という話ではありません。追いかけるゴールを先に決めて、それだけを目指す、というやり方をとらなかった。それだけのことです。

「成功したら幸せになれる」の順番を疑う

新しい事業は、1000に3つしか成功しないと言われます。もしそれが本当で、成功して初めて幸せになれるのだとしたら、残りの997は不幸になってしまう。そんな世の中には、あまり希望がないように思います。

成功を目指すこと自体は、悪くありません。ただ、成功するまでは幸せじゃない、と自分で決めてしまうと、道のりがずっと苦しくなる。ゴールに着くまで、耐え続けることになるからです。

幸せは成功しないと手に入らない、というのは、違うのではないか。成功するかしないかの前に、今すでに幸せであるかどうか。そちらのほうが、よほど大事なのではないでしょうか。

起業には「成したい」と「ありたい」の二種類がある

自分のやってきたことを振り返って、起業には二種類あるのではないか、と考えるようになりました。

一つは、「成したい起業」。大金持ちになりたい、有名になりたい、あるいは、こういう社会問題を解決したい。何かを成し遂げたいという強い目的から始めるもの。今どきの起業には、この形が多い。立派だし、社会を前に進める力になります。ただ、成し遂げるまでは「まだ足りない」と言い続けることになる。成せないうちは、どうしてもしんどい。

もう一つは、「ありたい起業」。いい状態であり続けたい、この関係を続けたい、というところから始めるもの。私は、こちらでした。5人で始めた会社で、その5人と楽しく働けている。その状態を、手放したくない。だから、続けたい。「ありたい」から始めると、ビジョンは、いつか達成して終わるゴールではなく、続けることで実現していくものになります。起業した当時から今にいたるまで、不幸だと感じたことはありませんでした。

「成したい」を否定するつもりはありません。合っている人は、それでやればいい。ただ、「ありたい」から始める起業が、あってもいいのではないか。この「ありたい姿」のまま続けていくという話は、別の記事にも書きました。

私の始まりは、仲間を守りたい、それだけだった

私がソニックガーデンを始めたのは、35歳の頃に立ち上げた社内ベンチャーがもとになっています。上場企業の中で、新しい事業をやらせてもらった。少人数の小さなチームで、喧嘩しながら、なんとか単月黒字にこぎつけたところでした。

ところが、いよいよこれからだ、という時に、会社がグループ内で次々と合併していく方針になりました。私たちの小さな事業も、鶴の一声で統合されたり、やめさせられたりしてもおかしくない。せっかくできたいいチームを、どうやったら守れるのか。考えた末に出た答えが、事業ごと買い取って独立する、というものでした。

さすがに怖かった。起業したこともない人間が、安定した上場企業の立場を捨てて出ていく。踏み切れずにいたときに、2011年の東日本大震災が起きました。人はこんなに簡単に死ぬのか、と多くの人が思った。私も思いました。数年待てばまたチャンスがある、と大人たちは言ってくれたけれど、その数年のうちに終わってしまうかもしれない。だったら、やろうと。

借金をして会社をつくり、事業と社員を買い取って、ソニックガーデンが始まりました。5人での創業です。その5人は、15年経った今も、まだ一緒に働いています。壮大なビジョンがあって起業したわけではない。目の前の仲間と、この働き方を、守りたかった。それだけでした。

ありたい姿は、変わり続けないと保てない

いい状態を続けたい、と言うと、今のままでいい、変わらなくていい、と聞こえるかもしれません。でも、実際は逆でした。ありたい姿を保つために、私たちは変わり続けてきました。

変えたくて変えたことは、ほとんどありません。たいていは、やむを得ず変えてきた。地方に住む社員が増えたので、東京の本社オフィスをなくして、みんなリモートワークにした。全員が離れて働くと管理しきれないので、管理をやめて、一人ひとりがセルフマネジメントで働くようにした。若い社員を採用し始めたら、育てる場所が要るので、徒弟制度をつくって、親方の家の近くに拠点を建てた。

一つ何かが起きるたびに、頑なに守るのではなく、現実を受け入れて、手を打つ。その繰り返しでした。オフィスをなくしたのに、地方に拠点を建てる。ちぐはぐに見えるかもしれませんが、目の前の状況に合わせていったら、そうなった。

面白いのは、これだけ変わり続けてきたのに、やりたかったことは何も変わっていない、ということです。仲間と楽しく良いソフトウェアをつくり続けたい。その一点だけは、15年前からずっと同じです。変わり続けたからこそ、変わらずにいられた。

私のやり方は、エフェクチュエーションと呼ばれていた

こういう進み方を、自分では特に意識したこともありませんでした。ただ「いいソフトウェアをつくる」ことに一生懸命だっただけです。ところが、そのやり方にはちゃんと名前がついていたと、あとから知りました。「エフェクチュエーション」という理論です。

経営学者のサラス・サラスバシーが、優れた起業家たちに共通する思考様式を研究して見つけたものだそうです。日本では、神戸大学の吉田満梨先生たちが紹介されています。

一般的な起業論は「コーゼーション」、因果論と呼ばれます。目標を決めて、そこから逆算する。夢に日付をつけて、足りないものは、お金でも人でも外から調達してくる。未来を予測して、計画通りに進める考え方です。

エフェクチュエーションは、その逆です。未来から逆算しない。まず手元にあるもので始める。動いてみて、できたことを見て、次の一手を決める。チャレンジはするけれど、一か八かはしない。失敗しても致命傷にならない、許容できる範囲で試していく。

こうした考え方に、いくつかの原則があります。手元にあるものから始める「手中の鳥」。損しても大丈夫な範囲で試す「許容可能な損失」。酸っぱいレモンしか手に入らなくても、工夫すればレモネードになるように、予期せぬ出来事さえ味方に変える「レモネード」。思ってもみなかった人と出会い、一緒に何かをつくっていく「クレイジーキルト」。そして、目的地を決めて一直線に進むのではなく、飛行機の操縦のように、風が吹けば舵を切りながら進んでいく。呼び名はいろいろですが、どれも、今あるものから始めて、変えながら進む、という同じ姿勢の現れです。

理論を知らずにやっていたことが、優れた起業家の思考様式と同じだった。しかも津山で話したとき、逆算しないやり方に共感する、今まさにそうしている、という声が何人もの人から返ってきました。名前を知らないままやっていたことが、誰かの実感と重なる。面白いものです。吉田先生たちの本は、黄色い表紙の『エフェクチュエーション』。読むと、自分のやってきたことに名前がつくようで面白いので、おすすめです。

成功を追わなくても、幸せに働き続けられる

起業に、大きな志も、退路を断つ覚悟も、綿密な逆算も、必ずしも要りません。もちろん、それが合う人は、そのやり方でいい。でも、今あるものに満足して、小さく始めて、少しずつ良くしていく。そういう起業も、経営も、あっていいはずです。

今のままでいい、という話ではありません。いい状態を続けるためには、変わり続ける必要がある。ただ、その変化は、遠くのゴールのためではなく、今ある手元のもの、周りにいる人たちを大事にした結果として、起きていく。

成功を追わなくても、幸せに働き続けることはできる。私は、そう考えています。そしてこの15年、変わり続けるなかで手放さなかったものが一つだけあるとしたら、それは「遊ぶように働く」という、始めたときからの願いでした。

その「遊ぶように働く」を、もう少し自分の言葉にできないかと考えて、仕事を「労働」ではなく「技芸」として捉える、という見方にたどり着きました。その話は、9月にミシマ社から出る『自分と社会をいい感じにする仕事技芸論』に書いています。

津山で話したときの資料も、あわせて載せておきます。

スライドを開く（SpeakerDeck）

津山で「Homing 2026」に登壇してきました：成功を追わない起業と経営

2026-07-14T18:47:00+09:00

岡山県津山市で開かれた「Homing 2026」の第1回に、ゲストとして登壇してきました。会場は津山市立図書館。地域で新しい挑戦をしたい人たちが集まる、事業アイデア創出コミュニティのイベントです。

Homing は2018年から続いていて、今年で9年目になるそうです。津山を拠点に、創業を目指す人や、地域で何かを始めたい人が集い、応援し合う。そういう場が地方で長く続いていること自体が、すばらしいことだと思いました。

会場に来ていたのは、これから起業を考えている人、すでに事業をしている人、支援機関の方など。社会人が中心で、津山の方が多く、なかには隣町の鏡野町から来てくださった方もいました。

いただいたテーマは「成功を追わない起業と経営」。起業のイベントで「成功を追わない」とは何事か、と思われそうですが、これは私が15年やってきたことを、振り返った先にある言葉です。

起業というと、大きな志を掲げて、退路を断って、綿密な計画で挑むもの、というイメージがあります。でも、私の始まりは「一緒に働く仲間を守りたい」という、それだけのものでした。壮大なゴールを掲げて逆算したのではなく、いまあるものを受け入れて、目の前のことに手を打ち続けてきた。そうしていたら、いつの間にか15年が経っていた。そういう話をしました。

面白いのは、この進み方には「エフェクチュエーション」という名前がついていたことです。優れた起業家に共通する思考様式を、経営学者のサラス・サラスバシーが研究して見つけたもの。手元にあるものから始める、損しても大丈夫な範囲で試す、出会った人と協働する。私はこの理論を知らずにやっていました。日本では、神戸大学の吉田満梨先生たちが紹介されています。

講演のあとの質疑や交流会でも、この「エフェクチュエーション」に反応してくださる方が多くいました。「逆算しないやり方に共感した」「今まさにやっているけれど、そういう呼び方なんですね」といった声をいただきました。理論を知らずに続けてきたことが、誰かの実感と重なるのは、面白いものです。

もうひとつ、アンケートで印象的だったのが「起業のイメージが変わって、勇気が持てました」という感想です。私が伝えたかったのは、まさにそこでした。成功を追いかけなくても、幸せに働き続けられる。そんな起業や経営があってもいい。誰かを変えようというのではなく、私はこうやってきた、という話をしただけですが、それが誰かの何かのきっかけになったのなら、話した甲斐があったと思います。

岡山は、うちの若手が育つ拠点「親方ハウス」がある土地でもあります。東京の本社オフィスはなくしたのに、岡山には土地を買ってオフィスを建てた。そういうご縁のある場所で話せたのも、感慨深いものがありました。

お招きいただいた Homing の皆さん、暑いなか集まってくださった参加者の皆さん、ありがとうございました。

主催のレプタイルさんが、当日の様子を開催レポートにまとめてくださいました。講演の内容や、質疑・交流会での反応まで丁寧に書いていただいて、ありがたいかぎりです。

Homing 2026 DAY01 開催レポート → https://homing-tsuyama.jp/2026/07/13/第9期-homing-2026-day01-開催レポート/

講演でも触れた「仕事を、労働ではなく技芸として捉える」という話は、9月18日にミシマ社から発売される新刊『自分と社会をいい感じにする仕事技芸論』で書いています。予約の受付も始まりました。

『自分と社会をいい感じにする仕事技芸論』（ミシマ社）→ https://amzn.to/3Rsmj5e

登壇資料はこちらです。

Scrum Fest Sendai 2026 にキーノート登壇してきました：AI時代の仕事技芸論

2026-07-13T09:21:00+09:00

先日、仙台で開催された「Scrum Fest Sendai 2026」に、キーノートスピーカーとして登壇してきました。会場は enspace、現地とオンラインのハイブリッド開催です。

Scrum Fest Sendai は、アジャイルやスクラムに関心のある人たちが集まるコミュニティのイベントです。私自身、アジャイルのコミュニティに顔を出すのは久しぶりで、その空気を楽しませてもらいました。

XPが登場した25年ほど前から、私はこの世界にいます。そのアジャイルのコミュニティがこれほど盛り上がって、地方でも開催されるようになったことには、感慨深いものがありました。ここは、自分のホームだったな、と思えました。

キーノートのテーマは「AI時代の仕事技芸論」。AIがコードを書き、設計やテストまで担うようになった今、ソフトウェア開発という仕事はどうなっていくのか。私たちソニックガーデンで15年やってきた「遊ぶように働く」というあり方を軸に、話をしました。

納品のない受託開発、管理をなくしたセルフマネジメント、親方と弟子の徒弟制度。ソニックガーデンの実践を紹介しながら、最後に「仕事を、労働ではなく技芸として捉え直す」という話に着地させました。

今回はアジャイルの祭典での登壇でしたが、あえて「アジャイルのやり方」の話はしませんでした。

ただ、これだけ広まってくると、「アジャイル」という言葉が先行して、その理想に取り組むための仕組みが、どんどん複雑になっているようにも見えます。認定制度なども、かえって難しくしているのかもしれません。浸透したがゆえのこと、とも言えるのでしょう。

でも、もともとはもっとシンプルなものだったのではないか。お客様やユーザーを見て、貢献できるソフトウェアをつくること。つくる人自身も幸せになれるような、つくり方をすること。それが、私たちソニックガーデンが取り組みつづけた「いいソフトウェアをつくる。」の定義。

それに一生懸命に取り組んでいけば、難しい制度や仕組みや認定がなくても、きっと誰から見ても「アジャイルだな」と思ってもらえるはずだ。私たちがアジャイルを目指してこなかったのに、結果としてそう呼ばれる形になっていたのは、たぶん、そういうことなのだろう。

会場の皆さんに、どう受け取ってもらえたのか、質疑応答での反応も含めて、私にとっても学びの多い時間になりました。

今日お話しした内容は、9月18日にミシマ社から発売される新刊『自分と社会をいい感じにする仕事技芸論』にまとめています。予約の受付も始まりました。

『自分と社会をいい感じにする仕事技芸論』（ミシマ社）→ https://amzn.to/3Rsmj5e

登壇資料はこちらです。

本気でAIを使うと、まったく楽にならない

2026-07-06T11:37:00+09:00

今週来週で講演や登壇が続く。そのうち2つは新ネタで話すことになり、資料作りに追われている。かなり追い込まれているが、AIのおかげで、資料だけはなんとか進んでいる。

AIを使うと、脳が拡張された感覚があって、品質もスピードも確かに上がる。しかし、まったく楽にはなっていない。

講演資料は、自分が壇上に立って発表するものだ。納得のいっていない内容のまま話すのは嫌だ。だから、納得がいくまでAIにフィードバックを続けることになる。

ふと気になって、AIとのやり取りのログを数えてみた。いま作っている3本の講演資料に対して、私が出したフィードバックは、合わせて300回を超えていた。

中身を見返すと、タイトル案に「うーん、違うなぁ」「迷子に入ってきたな」と言い続けていたり、3周回って「今のままでも良い気はしてきた」と戻ってきたりしている。スライドの1枚に「気持ち悪い」と言って、なぜ気持ち悪いのかを自分で言語化してもいた。このスライドが気持ち悪いのは、私の大事なスタンスと違っているからだ、と。何が違和感で、何を大事にしたいのか。それを言葉にするのは、いつも自分の側だった。

結果として、出来上がった資料は、自分で作ったのと同じようなものになっている。これは自分の作品だと言えるし、だから納得して壇上に立てる。手は動かしていないが、考えることは何ひとつ減っていない。むしろAIが賢くなった分、こちらの考えの浅さがすぐに露呈する。手は楽になっているが、頭は楽になっていない。

AIを使った作品は賞に応募できない、という話を聞く。「AIを使っていません」という表明が、作品の価値になることもあるようだ。AIを使うことを良しとしない風潮は、楽して成果をあげることへの忌避感から来ているのではないか。使ったら、ずるだというわけだ。

AIに丸投げしたら、そりゃダメだろう、とは思う。考えの浅いまま任せれば、浅いものが出来上がるだけだ。しかし、本気でAIを使ってみれば、決して楽ではないことがわかる。良いものを作ろうとすれば、結局は本人の力が要る。逆に、AIを駆使した上で、自分の思考を乗せることも、自分らしい表現にすることもできる。AIを使ったからといって、クリエイティビティが本人のものでなくなるわけではない。

いずれ全員がAIを前提とするようになれば、結局はその土俵での差が出てくる。それなら、どんどんAIを使いこなすことに取り組んだ方がいい。

ソニックガーデン、16期がはじまりました

2026-07-01T20:58:00+09:00

ソニックガーデンは、本日7月1日をもって16期に入りました。

ここまで続けてこられたのは、日頃からお付き合いいただいているお客さま、パートナーのみなさん、そして一緒に働いてくれる仲間たちのおかげです。あらためて、ありがとうございます。

15期は、事業も人も大きく広がった一年でした。クラシコムとの資本業務提携、韓国からの採用、高校を卒業したばかりのメンバーの入社、倉貫書房とミシマ社の業務提携など、これまでのソニックガーデンの枠を超えるような挑戦がいくつも重なりました。

私たちは「思い出」を大切にする方針を掲げていて、それを実践する形で、全国各地でのハッケーション（合宿型の開発イベント）や、弟子合宿・親方合宿・コーポレート合宿なども積み重ねてきました。一緒に過ごした時間そのものが、私たちの財産になっていると感じています。

15期の後半、つまり今年の前半は、AIの登場によって会社そのものが大きく変わった時期でもありました。Claude Codeを全社の標準にすると決め、開発だけでなくコーポレートの仕事も含めて、AIを組み込んだ働き方へと組織を作り変えてきました。AIファーストな組織になっていく手応えを、この半年でつかんだように思います。

そして16期を迎えるにあたり、経営体制もひとつ新しくします。2014年の入社から10年以上一緒にやってきた野上誠司が、本日より取締役執行役員に就任しました（会社からのお知らせ）。

あえて監督と執行を分けないことが、ソニックガーデンにとっては大事なのではないか。今回の経営体制を考えるときに、そう思いました。

これは、仕事を「技芸」として捉えていることとも重なります。「納品のない受託開発」も、分業せずに一気通貫で取り組むからこそ大きな価値が出せますし、担っている本人も自分の仕事の手応えを最後まで感じ取ることができます。経営も同じです。意思決定と実務を切り離さず、自分で担い続けることで、手応えを保てるのだと考えています。

16期も、ソニックガーデンらしく、変化を楽しみながら進んでいきます。どうぞよろしくお願いいたします。

書籍制作にもSSoTと冪等性を持ち込みたい

2026-06-30T10:36:00+09:00

新刊の原稿を書き終えて、編集者から初校ゲラが届いた。指摘は的確で、ありがたい。ただ、この先の工程を思うと、気が重い。

本を作るたびに引っかかっていることがある。原稿をInDesign（組版ソフト）に流し込んだ瞬間から、「正本」が行方不明になる問題だ。

原稿はMarkdownで書く。Gitで版管理もしている。ところがInDesignに流し込んで組版を始めると、修正の主戦場がInDesign側に移る。校正で見つかった誤字、リライト、改行の調整。それらはすべてInDesignのファイル上で直される。元の原稿には戻ってこない。

プログラマの目には、これはSSoT（Single Source of Truth）の崩壊に見える。正本がどこにもない。いや、正確にはInDesignのファイルが事実上の正本になっているのだが、それはMarkdownのように差分を取ったりGitで管理したりできるものではない。増刷や改訂のたびに「どれが最新版か分からない」が起きる。

では、InDesignを使わなければいいのか。CSS組版ツールを使えば、原稿ファイルから直接PDFを生成できる。SSoTは保たれる。だが、そう簡単な話ではない。

組版の現場で行われている微調整は、ちょっと代えが効かない。写真の回り込み、見開きの左右バランス、1行あふれたテキストの処理。ゲラを見ればわかるが、こうした調整は画面を見ながら手を動かさないと追いつかない。コードだけで再現しようとすると、エンジニアリングコストが跳ね上がる。

問題はInDesignではない。工程にある。

これはインフラの世界で起きたことに似ている。

昔のサーバー管理は、SSHで入って手作業で設定を変えていた。設定ファイルを直接編集し、手順書を頼りにコマンドを打つ。うまくいったら手順書にメモを追記する。やがてサーバーが増え、手順書と現実が乖離する。SSoTの崩壊だ。

これを解決したのがIaC（Infrastructure as Code）だった。設定をコードで記述し、ツールが自動で適用する。何度実行しても同じ結果になる。冪等性の担保。

書籍制作にも、同じ発想を持ち込めるのではないか。

Markdownを正本（SSoT）として維持しつつ、InDesignは「ヘッドレスなレンダリングエンジン」として使う。プロが作ったInDesignテンプレートをデザインシステムとして用意し、Markdownの見出しや本文をスタイルと1対1で対応させる。

目視で見つけた微調整（「32ページの図をY方向に2mm上げる」「このテキストフレームのトラッキングを詰める」）は、InDesign上で直接直すのではなく、レシピファイルにデータとして書き出す。

スクリプトがMarkdownとレシピを読み込み、流し込みと微調整を自動で実行する。何度ビルドしても同じ紙面が再現される。冪等性だ。

SSoTと冪等性が確保されていれば、AIとの相性は抜群に良い。正本が一箇所にあり、何度やり直しても壊れないなら、AIに任せられる範囲が一気に広がる。

MCPを介してAIが入ると、こうなる。InDesignにプラグインを常駐させてMCPサーバーとして動かし、人間は組版画面を見ながらAIに指示する。「32ページのキャプションが1行あふれてるから直して」。AIが文脈を判断して、文章を数文字削るか、オブジェクトを数ミリ動かすかを決め、変更をMarkdownとレシピファイルの両方に書き戻す。

人間はマウスを触らない。でも最高品質の組版画面を確認しながら、SSoTの更新と画面の修正が同時に起きている。APIもMCPも、そろそろ手が届くところまで来ている。

ツールを捨てるのではなく、工程をアップデートする。SSoTと冪等性は、ソフトウェア開発だけのものではない。

「頭がいい」だけでは、仕事はできない〜IQ・EQを成果に変える「SQ」という出口

2026-06-18T07:33:00+09:00

「頭がいい」ことと、「仕事ができる」ことは、別のもの。

的確な分析も、筋の通った正論も、それだけでは人は動きません。頭の中にある正しさは、人を通って外に出てはじめて、成果に変わります。

頭の良さとは別の何かが、仕事の成果を分けている。その差は、どこから来るのか。

「頭がいい」は、知性の一部でしかない

「頭がいい」と言うとき、たいてい思い浮かべるのは一種類の能力です。論理的に考え、難しいことを理解する、いわゆるIQ（Intelligence Quotient、知能指数）の高さ。大事な力ですが、知性の一部でしかありません。

もう一つ、よく知られた知性にEQ（Emotional Intelligence Quotient、心の知能指数）があります。自分の感情を扱い、相手に共感する力です。ただ、IQもEQも、自分の内側で完結している。正しく考えられること、相手を思いやれること。どちらも大切ですが、そのままでは、まだ外には出ていません。

IQもEQも、SQを通らないと成果にならない

その内側の知性が外に出て成果になる、その出口がSQ（Social Intelligence Quotient、社会的知能指数）です。他者を認識し、組織の力学を読み、人と協働する力。いわば、内面の知性を人に向けて差し出すインタフェース。特に現代において、成果を直接左右しているのは、このSQではないでしょうか。

IQは内面のエンジンのようなものです。性能が高くても、エンジンだけでは車は進まない。タイヤに繋がってはじめて前に出る。EQも、それだけでは足りません。共感できるだけでは「いい人だね」で止まってしまう。気持ちを汲めることと、人を動かせることは、別のことです。

IQの論理も、EQの共感も、SQというインタフェースを通って、はじめて成果に変わります。誰に、いつ、どの順番で話すか。そもそも、どんな場面でも通じる唯一の正解などありません。同じ中身でも、相手や状況によって効くやり方は変わります。

正論が通らないのは、偶然ではありません。仕事の問題の多くが「技術的な問題」ではなく「適応課題」だからです。技術的な問題は正しい知識で片づくけれど、適応課題は、関わる人の考えや関係が変わらないと動かない。IQで片づくのは前者まで。後者に効くのがSQです。

SQを駆動するのは「理性」ではないか

では、SQは別の新しい知能なのか。そうではなく、SQを動かしているのは「理性」ではないか、と考えています。

理性とは、論理だけを押し通さず、感情だけにも流されず、相手と目的に応じてどちらをどう使うかを見極める力です。IQが「何が正しいか」を、EQが「相手がどう感じているか」を教える。それをどう混ぜるか判断するのが理性です。つまり、論理と感情のどちらも使いこなし、場面に合わせてバランスをとる。その働きが、SQの高さに繋がります。

これは仮説ですが、IQが高くてEQが多少弱くても、理性が効いていればSQは成り立つように思います。共感が得意でなくても、「ここは論理で押さないほうがいい」と判断できれば、人は動かせることもあるかもしれない。

SQは、後天的に鍛えられる

偉そうに書いていますが、私がSQの大切さに気づいたのは、ずいぶん経ってからでした。

20代の私は、典型的な「正論モンスター」でした。正しいことを言っているのだから動いて当然だと思い、相手のメンツを潰していることにも気づかない。IQだけで仕事をして、インタフェースがひどい状態だったのです。

転機は、立場の違う人たちと組む仕事を任されたとき。読んだ『ピープルウェア』の一文が刺さりました。「われわれの抱える主要な問題は、そもそも技術的ではなく社会学的なものである」。技術の問題だと思っていたものが、人と人の問題だった。

そこから、やり方を少しずつ変えました。たとえば「提案」をやめて「相談」にする。「こうすべきだ」ではなく「困っているので一緒に考えてほしい」と。中身は同じなのに、入り口を変えただけで、身構えていた相手が味方になる。

正論を捨てたわけではありません。届け方を覚えただけ。IQの答えを、理性を駆使して適切に出力する。それだけで、同じ自分のまま仕事の進み方が変わりました。SQは生まれ持った才能ではなく、後天的に鍛えることができる。このあたりは以前、正論だけでは届かないにも書きました。

知性は、身体を土台にした五つの層でできている

IQ、EQ、SQは、内から外への階層になっています。その内側と外側には何があるのか。AIと考えを行き来させながら整理してみたのが、次の五層です。完全な自説ではなく半ば言葉遊びですが、知性を眺める補助線にはなります。

中心は身体、PQ（Physical Quotient、身体的知能）。問いは「どう生きるか」。いつの時代も、人の土台は身体にあります。心身が健やかでなければ、どんな知性も発揮できない。一番地味で忘れられやすい層ですが、すべての土台です。

その外が、内面のIQとEQ。さらに外が、他者と関わるSQ。

SQのさらに外にも、層は続きます。一つはTQ（Time Quotient、時間の知能）。「いつ動くか」、時流やタイミングを読む力です。SQが目の前の「空間」を相手にするなら、TQは「時間」を味方につける力。そして一番外がXQ（Existential Quotient、実存的知能）。「なぜやるか」、利害を超えて意味や大義を問う力です。

この五つのうち、土台として欠かせないのがPQ、成果を直接分けるのが出口のSQだと考えています。

IQが底上げされる時代に、差がつくもの

SQが大事なのは、今に始まった話ではありません。昔から、知性を成果に変えてきたのはSQでした。ただ、AIの時代になって、その重みはいっそう増しています。

AIは、IQを増幅する道具です。分析も整理も調べものも、IQ寄りの作業の多くを引き受ける。誰もが、これまでより速く深く考えられるようになりました。とはいえ、IQが要らなくなるわけではない。何を問い、出てきた答えをどう見極めるかは、こちらの頭次第です。けれど、誰もがIQを底上げできるようになれば、差がつくのはその先になります。

以前、「頭がいい」が武器にならなくなる時代で、腕力が相対化されたように知力も相対化されていく、と書きました。それが現実になりつつあります。では、何が残るのか。昔から変わらず、人を相手に成果へ変えてきた力、SQです。正しい答えはAIが出してくれても、それを誰にどう届け、人をどう動かすかは、人間に残り続けます。

頭がいいだけでは、武器にならない。AIと働くほど、その実感は強くなっています。

＊＊＊

人を動かすことには、古くからの定番があります。デール・カーネギーの『人を動かす』。1936年の本がいまも読み継がれているのは、SQが時代を問わず仕事の核心にあり続けてきた証でしょう。