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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

スライドを開く（SpeakerDeck）

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

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

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

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

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

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

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

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

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

では、何を任せるのか。

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

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

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

そして、責任のこと。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Amazonで見る

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

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

これが、私の本心です。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Amazonで見る

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

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

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

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

予約が始まっています

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

• Amazonで予約する
• 楽天ブックスで予約する

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

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

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

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

創業して、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期の一年を、より詳しくまとめています）

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

スライドを開く（SlideShare）

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

スライドを開く（SlideShare）

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

スライドを開く（SpeakerDeck）

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

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

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

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

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

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

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

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

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

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

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

登壇資料はこちらです。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

本を作るたびに引っかかっていることがある。原稿を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（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が時代を問わず仕事の核心にあり続けてきた証でしょう。

その「先」が何なのか、最近すこし見えてきた。個人の仕事が速くなる話ではなく、チームの仕事が変わる話だ。Claude Code単体では片手落ちで、GitHubとセットで使ったときに、本当の変化が始まるのではないか。

エージェントに仕事を頼むと、成果物はファイルになる。ファイルはリポジトリに置かれ、変更の履歴が残り、誰がいつ何を変えたのかを辿れる。自分ひとりではない。チームの仲間も、それぞれのエージェントも、同じ場所を見て仕事をする。リポジトリは、エージェントにとっての職場みたいなものだ。

考えてみれば、ソフトウェア開発は、ナレッジワークの進化形だったのではないか。成果物をテキストで残し、変更を履歴で管理する。お互いの仕事をレビューし合い、課題はチケットにして見えるようにする。プログラマたちは、知識をチームで扱う仕事の方法論を確立してきた。

この方法論を他の仕事にも持ち込みたいと考えていたが、GitとGitHubの習熟をエンジニア以外に求めるには、壁が高すぎた。

やってみて気づいたのは、この壁が二つに分かれていたことだ。コマンドを操作する壁は、Claude Codeが消してしまった。自然言語で頼めば、コミットもプルリクエストもエージェントがやってくれる。

だが、コミットやブランチといったGitの概念を理解する壁は残った。そこが腹落ちしていないと、エージェントに頼むことすらできない。それは全社で進めてみての発見だった。それでも、概念は学べば越えられる。

Infrastructure as Codeという言葉がある。サーバーの構成をコードとして書くことで、再現も、レビューも、改善の蓄積もできるようになった。

同じことを、事業活動の全部でやればいい。経理でも人事でも広報でも、仕事の成果物をMarkdownで書いてリポジトリに置く。事業活動のすべてをコードにする、ということだ。

ソニックガーデンでは、これを非エンジニアも含めて、全社で進めている。社長の私自身が率先して、ブログの原稿も、講演資料も、経営の検討メモも、Markdownでリポジトリに入れた。

これは、2016年に全社リモートワークでオフィスを手放したとき以来の変革になる気がしている。あのときは、働く場所が物理からオンライン上のソフトウェアに移った。今度は、仕事そのものがソフトウェアの側に移っていく。

人の作業を補助するためにソフトウェアがあるのではなく、コードになった事業を、人とエージェントが一緒に改善し続けていく。ソフトウェアが先にある会社だ。

いま社内のリポジトリには毎日コミットが積み重なっている。会社が少しずつ、コードになっていってる感じがするな。

一方で、AIをうまく使いこなしている人もいる。問いを投げて自分の考えを深め、手間のかかる作業は任せる。そうやってパートナーのように付き合っている。その違いは、どこにあるのだろう。

AIを使いこなすには、実は2つの能力がいるのではないか。

ひとつは、出てきたものの良し悪しを判断する力である。たとえばAIが書いたコードを読んで設計の筋を見抜けるか、AIが書いた文章を読んで論理の飛びを見つけられるか。技術力に直結する力で、その分野での自分の専門性そのものに近い。

もうひとつは、AIに対して率直に意見を言える力だ。出てきた答えをそのまま受け取らず「今のこの状況だとそれはおかしくないか」「なぜそう言うのか」と問い返す。対等な相手として尊重しつつ、最後のハンドルは自分が握る。

後者は、経営者が得意としている部分ではないかと思う。

経営者は、自分ひとりで解決しようとしない。私自身、人事の専門家や弁護士、税理士と仕事をしてきた。どの領域でも、相手は私よりずっと詳しい。

その代わりに、経営者がやっているのは「なんとかする」ことだ。自分で全部考えて決めるというよりも、専門家の意見を踏まえつつ、うちの状況だと違うのではないかと問い返し、最後は自分で決めて責任を取る。意思決定と責任が、経営者の仕事なのだ。

AIへの付き合い方は、これとほとんど同じ構造をしている。世の中の経営者がAIをうまく使えているのは偶然ではなく、普段からやっている動き方を、AI相手にも自然に持ち込んでいるからではないだろうか。

とはいえ、自分より詳しい相手と仕事をする経験など、経営者じゃないとなかなか積めなかった。だが、AIは誰にとっても初めての「自分より詳しい部下」だ。経営者だけのものだった練習の場が、いま誰の手元にもある。

これからは、そうやって誰もが自分の専門外をAIに任せて成果を出すことが求められる時代になっていくんだろうな。

少し前なら、コーディングと言えばキーボードを叩いてコードを書くことだった。今は違う。エージェントが書くのが当たり前になり、人間が手で打つ方が特別なことになった。

私はこれを「手打ちコーディング」と呼んでいる。

「手打ちそば」も、昔はなかった言葉のはずだ。そばはそばだった。機械でそばが作られるようになって、初めて手で打つそばを「手打ち」と呼ぶようになった。標準が機械側に移ったときに、それまで標準だったものに名前がつく。コーディングにも、同じことが起きた。

そういえば「手打ち」と言いつつ、コーディングで実際にやっているのはキーボードを叩くことであって、手で書いているわけではない。それでも「手打ち」と呼ぶことに、自分でも違和感がない。比喩は不思議なものだ。この先、エージェントに指示を出して書かせることまで、いつか「手で書く」と呼ばれる日が来るのかもしれない。

これはコーディングだけの話ではない。文章を書くときも同じ。

この記事も、エージェントを使って書いている。多少のミスや違和感はある。それでも書き直させた方が、自分で手打ちするより早いし、楽だ。人間、一度楽を覚えると元には戻れない。

パンチカードからキーボードに変わったときも、きっと同じことが起きたのだろう。手打ちからエージェントに変わるのも、その延長線上の出来事だ。

やり方が変わるだけで、作ることそのものがなくなるわけではない。エージェントに任せても、プログラマがソフトウェアを作っていることに変わりはない。文章だって同じだ。

とはいえ、手打ちが残る世界もある。

文章の世界では、いまだに原稿用紙にペンで書く小説家がいると聞く。キーボードで打った方が圧倒的に早いのに、ペンで書いた方がいい作品ができると信じている。それも、人の手による作品作りのひとつの道だ。

ただし、コーディングはそうはならないだろう。小説と違って、コードの読み手は書き手の手の痕跡を求めて読んでいるわけではないからだ。コーディングはエージェントの手に渡って、それが当たり前になっていく。

手で打たなくなっても、作り手であることは変わらないんだろうな。

なぜ、Laravelのイベントで話すのか

私はソニックガーデンという会社を経営しています。日本の方ならご存じかもしれませんが、Ruby on Rails をもう15年やってきた会社で、社員もほとんどが Rails のスペシャリストばかりです。

では、なぜ Laravel のイベントで話すのか。私はもう一社、クラシコムという会社にも取締役CTOとして関わっています。「北欧、暮らしの道具店」を運営している上場企業で、その基幹システムを Laravel で作っているのです。最初は一人のエンジニアが Laravel で書いたものを、ずっとメンテナンスしながら育てて、いまや100億円規模の売上を支えるシステムになっています。

10年ほど前、そのクラシコムで、Laravel Live Japan の主催者である濱崎さんと一緒に働いていました。当時の彼はまだジュニアと言ってもいいころでしたが、Laravel への愛がすごかった。最初に作ったエンジニアがいなくなったあとも、ほぼ彼一人でずっとメンテナンスを担い続けてくれた。その積み重ねがあって、クラシコムは大きなシステムを持てるようになったのです。

その濱崎さんが、海外を経て日本に帰ってきて、なんと Laravel のスタッフになっていました。そして日本で初めての Laravel Live Japan を立ち上げ、わざわざ私のオフィスまで来て、登壇を頼んでくれたのです。

正直に言うと、一度は断ろうかと思いました。なにしろ私はいまは経営者で、コードを書く仕事をしていない。この日の私の話も、一行もコードは出てきません。話すにしても、せめて Rails の話だろう、と。それでも、かつて一緒に働いた濱崎さんが立派になって凱旋し、日本で大きなイベントを立ち上げる。何か力添えできることがあればという気持ちで、登壇させてもらうことにしました。

DHHと、同じ言葉に行き着いた

今日は、ソフトウェア開発における職人的な熟達、マスタリーの話をします。それこそが、AI時代には欠かせないのではないか、と考えています。

濱崎さんと私に意外な共通点があったように、Laravel と Rails にも、もちろん共通点があります。同じルーツを持ち、「開発者の喜び（Developer Happiness）」を大事にするという哲学です。その縁もあってか、今年の Laravel Live Denmark では、Rails 作者の DHH が、Laravel 作者の Taylor Otwell と対談することになっているそうです。いろんなものが繋がって、いまここに来ている。そんな不思議な感覚があります。

その DHH が最近、AI時代にプログラマはどう生きていくのか、というテーマで動画を公開していました。とてもいい内容で、私自身も強く共感したので、すぐに本人に連絡をとり、日本語に翻訳して公開していいかと尋ねました。快諾してくれたので、私のブログに翻訳を載せています。

そこで DHH が使っていた言葉が、「The Arts and Crafts of Work」でした。仕事を、技芸として捉え直す。実は私も、ここ数年ずっと、仕事を技芸とする文化を広めたいと言い続けてきました。それぞれの場所で、独立して、まったく同じ言葉に行き着いていたのです。この「仕事技芸論」が、今日の話の背骨になります。

その記事が、こちらです。

「審美眼こそが真実」〜DHHが語るAIエージェント時代の技芸論

「手打ちコーディング」

会場には海外から来た方も多くいました。日本食はもう召し上がったでしょうか。蕎麦を食べた人はいても、「手打ち蕎麦」を食べた人と聞くと、ぐっと減ります。

「手打ち蕎麦」という言葉は、いつできたのか。昔は、蕎麦は蕎麦でした。機械で蕎麦が打たれるようになって初めて、手で打つ方が貴重になり、「手打ち蕎麦」という言葉が生まれたのです。

最近、同じことがコードにも起きています。私自身も、コーディングエージェントでソフトウェアを作っていて、もうほとんど自分の手でコードを書きません。そうなると、手で打つことの方が、貴重になってくる。「手打ちコーディング」というわけです。

ただ、手打ち蕎麦は機械より美味しいのですが、手打ちコーディングは、残念ながらAIの方がいい。だから手打ちコーディングは、いずれ滅びていくのだろうと思っています。

プログラマは、これからどうなるのか

コードを書くのはAI。設計もAI。では、自分の役割は何になるのか。ソフトウェア開発という仕事は、これからどうなるのか。自分のキャリアは、どうなってしまうのか。

おそらく、私たちも含めて、みなさんが不安に感じているところだと思います。

ソニックガーデンという会社は、そこにどう向き合ってきたのか。これからどう向き合おうとしているのか。私たちが一つ大事にしてきたのが、「遊ぶように働く」というキーワードです。

「遊ぶように働く」とは何か

定義はとてもシンプルです。

本人は、いたって真面目に、一生懸命にソフトウェア開発に向き合っている。それでも、周りから見ると、なんだかとても楽しそうで、夢中でやっているように見える。これが「遊ぶように働く」という状態です。

これを実現するために、組織として大事にしてきたことが二つあります。

一つは、内発的動機づけです。外から与えられる評価や報酬やボーナスのため、あるいは怒られるから、仕事だからやる、のではない。いいソフトウェアを作りたい、いいコードを書きたい、いい設計をしたい、いいものが作れたら嬉しい。そういう自分自身の気持ちで作っていく。

もう一つは、フローです。チクセントミハイが提唱した概念で、難易度と自分のスキルがちょうど合うところにいると、人は夢中になれる。ゲームをしていて、ちょうどいい手応えの面のときに没頭してしまう、あの感覚です。仕事でも、同じことが起きるのではないか。

この内発的動機づけとフロー。私たちはこれを大事にしてきました。そして、それを大事にしてきたら、意外なことに、ビジネスとしてもしっかり成果を出すことができています。

ソニックガーデンには「ない」ものばかり

ソニックガーデンは創業15年、この夏で16年目に入ります。約60名の会社で、ほとんどが腕のあるプログラマたちです。

どんな仕事をしているかというと、いわゆる派遣ではなく、お客さまのCTOのような立場で参画します。CTOのような仕事ですから、事業戦略や経営戦略を考えながら、システムを設計し、ときにコーディングもし、運用もする。すべてを一気通貫でやる。しかも、弁護士やコンサルタントのように、一人で複数のクライアントを担当します。そういうプログラマたちが集まっている会社です。私たちはエクストリーム・プログラミングが好きなので、いわば「エクストリームなアジャイル」を目指してやってきました。

では、内発的動機づけとフローを、どうやって実現するのか。私たちは、いろんなものをなくしました。

売上目標がない。管理職もない。評価制度もない。指示命令もなければ、経費の決裁もない。オフィスもなければ、働く時間も決まっていない。ないないづくしです。

それでも会社は動いている。一人ひとりが、自分で考え、自分で判断し、自分で進めているからです。そのかわりに私たちが大事にしているのが、セルフマネジメントです。

なぜ、セルフマネジメントなのか

なぜセルフマネジメントなのか。ソフトウェア開発を考えてみてください。みなさん、一行一行「こう書け」と指示されますか。されないですよね。もし一行ずつ指示してくる上司がいるなら、その上司が自分で書けばいい。

プログラマは、指示を受ける側ではありません。AIを使うなら、むしろ指示を出す側です。細かく指示命令されるより、自分で考えて作った方が、生産性は高い。だとすれば、外からの指示や管理や評価は、なるべくなくしてしまった方がいいのではないか。

そう考えてやってみました。会社が潰れるかもしれないと思っていたのですが、意外なことに、ずっと成長を続けてくれています。

もちろんセルフマネジメントとは、自己管理さえできればいい、という話ではありません。周りの仲間とうまく協調していくこと、お客さまとうまくやっていくこと。そこまで含めてのセルフマネジメントです。

そういう人たちが集まると、何ができるか。上下のない、フラットなコミュニティが出来上がります。

セルフマネジメントできる人は、特に指示がなくても、自分から前向きに取り組みます。お客さまのシステムを作っているのに、それを自分の作品だと捉えている節がある。作品づくりそのものに喜びを感じているし、少しずつ上達していくことに喜びを感じている。ピーター・センゲは「自己マスタリー」という言葉を使いましたが、自分で自分を上達させていく状態になると、楽しくてしょうがない。そういう人たちが集まっているのが、ソニックガーデンというコミュニティです。

育てるために、徒弟制度を選んだ

セルフマネジメントで組織を作って、10年ほどやってきました。すると、私たちの会社はほとんど人が辞めないので、だんだん全体が年を取っていきます。それはそれでいいのですが、このままでは、ただ年を重ねただけの集団になってしまう。新陳代謝を起こしたくて、5年ほど前から、若い社員の採用を始めました。学生や新卒のような、ジュニアなプログラマの育成に、本格的に取り組み始めたのです。

AI時代になって、若いプログラマを採用する会社はどんどん減っています。そんななか、私たちは今年、高卒の社員を採用しました。18歳、19歳の人たちが働いている。自分でもちょっと驚きます。それでも、若い人にはしっかりお金をかけて投資していきたい。そう考えてやっています。

とはいえ、ソフトウェア開発の経験が浅い人が、フラットでセルフマネジメントな環境で、いきなり活躍できるかというと、そんなに甘くはありません。ソフトウェア開発は、本当に難しい。では、どうやって育てればいいのか。

私たちが取り組んだのが、徒弟制度でした。正解というより、私たちの場合はこうしてきた、という話です。

私たちは、師匠のことを「親方」と呼んでいます。親方と弟子の関係でやろう、と。弟子に入ると、まず親方のいる場所に引っ越します。親方は全国でリモートワークをしているので、弟子のあいだはリモートワークをやめて、親方のところへ移ってもらう。いまは岡山、広島、兵庫、愛知の4カ所に親方がいます。

「親方にわざわざ出社させるのか」というと、それは違います。親方はもともと在宅勤務をしていたのだから、親方の家の近くにオフィスを借りる。若い人はそこへ引っ越してくる。広島などは、オフィスと部屋がくっついたような場所で、ほぼ住み込みのようにして一緒に働いています。

そうやって、親方と弟子が一緒にソフトウェア開発をする。ずっとペアプログラミングをしているようなものです。そうしているうちに、だんだんと仕事の仕方を覚えていく。

これは、非常にアナログで前時代的に見えるかもしれません。けれど、よく考えてみると、ソフトウェア開発とは、本来そういうものではないでしょうか。私たちは誰も、最初から一人きりでプログラミングできるようになったわけではない。私自身も、振り返れば師匠がいました。自分で考えたものを、結果だけ見せて「いい・悪い」と言われるのではない。やっている途中を見せて、「そのやり方は違う、こうするといい」と教えてもらう。なるほど、こうやるのか、と。途中の過程を、見せて、見てもらう。

そして、いいソフトウェア、いい設計、いい振る舞いを見極める力は、一緒に働くことでしか身につかないのではないか。だから私たちは、徒弟制度という形で、一緒に働くことを選びました。実際にもう5年やってきて、最初に入ってくれた弟子たちは、戦力としてしっかり活躍するようになっています。

仕事を、技芸として捉え直す

ここまで話してきたのは、こういうことです。ベテランが自分の作品として仕事をし、自己マスタリーで上達していき、徒弟制度でそれを次の世代に伝えていく。これを一言で表すなら何か。私たちはそれを、技芸（Arts and Crafts）だと考えています。

仕事を、単なる労働だと捉える。時間だから働く、給料のために嫌々働く、生活のためには仕方なく働く。そうやって捉えていると、AI時代に仕事が奪われていくという話のなかで、つまらないものが、さらにつまらなくなっていきます。

そうではない。仕事を技芸として捉え直すことで、より楽しく、より自分のものとして、より自分の人生を豊かにするものとして、考えることができるのではないか。

この「アーツ・アンド・クラフツ」という言葉は、DHHと重なって驚いたのですが、もともと私は、19世紀のウィリアム・モリスが好きで、彼の起こしたアーツ・アンド・クラフツ運動からオマージュして使っていました。技術（エンジニアリング）は再現性を究極まで高めていくもの。一方で芸術（アート）は、再現性ではなく、創造性でやっていくもの。その両方のあいだにあって、結果だけでなく過程を大事にする。それが、仕事を技芸として捉えるということに通じます。

これはソニックガーデンに限った話ではありません。おそらくみなさんの中にも、技芸として大事にしたいという心があるはずです。多くのプログラマが、仕事を技芸とする働き方をできるようになれば、幸せなプログラマがもっと増えるのではないか。そう思っています。

ソフトウェア開発は、コードを書くことだけだったのか

では、過程を大事にするというのは、手打ちコーディングに戻ることなのか。いいえ、そうではありません。コーディングエージェントは、どんどん使えばいい。技術と芸術のあいだなのですから、エンジニアリングの効率化は、どんどん進めていけばいいのです。

その一方で、こう問い直してみたい。ソフトウェア開発とは、コードを書くことだけだったのか。

私たちの仕事は、コードを書くことが目的だったか。そうではなかったはずです。ソフトウェア開発とは、まず、何を作るのかを決めること。お客さまやユーザー、あるいは自分のアイデアをもとに、何を作るかを決める。次に、どう作るのかを設計する。どうすれば最適になるか、どうすれば長く使われるか、どうすれば保守性が高くなるか。そして、作ったものを運用し、改善し、育てていく。ここまでやって、初めてソフトウェア開発でした。

分業、分業、分業と切り刻んでいくと、効率だけが求められて、技芸ではなくなります。「コードを書いていた人はいなくなる」と言われますが、ソフトウェア開発は、全部やればいい。全部をやるとき、AIは味方になります。AIがあることで、生産性が高まり、喜びの時間が増えるのです。

「AI vs 私たち」ではなく「問題 vs AIと私たち」

AIへの向き合い方を、もう少し考えてみます。

コードを書くのはAIがやってしまう。では、自分の仕事はどうなるのか。だったら今度は、「AIに奪われない仕事を探そう」となる。けれど、残念ながら、それももうありません。AIに奪われない安全圏を探しても、見つからない。ほとんどのことは、AIができてしまうからです。

そうではなくて、AIとは一緒にやっていく方がいい。私たちの会社でよく使う言葉に、「問題 vs 私たち」というものがあります。あなた vs 私、ではない。問題に対して、私たちが同じ側に立って向き合う。そこにAIが加わる。これからは、「問題 vs AIと私たち」です。AIを敵にするのではなく、同じ側に置いて、課題に、事業に、社会の問題に向き合っていく。それが、AI時代のソフトウェア開発者に求められる姿勢ではないかと思います。

似たことは、10年以上エンジニアをやってきた人なら、覚えがあるはずです。クラウドが出てきたとき、「インフラの仕事はどうなるんだ」と言われました。けれど、Infrastructure as Code が登場して、プログラマがインフラまで自分で見られるようになった。これは、プログラマにとっての福音でした。AWSのおかげで、自分でインフラまで用意できるようになったのです。

同じことが、AIでも起きているだけです。AIで効率化されても、ソフトウェア開発という仕事がなくなることはない。そのかわり、一人でできる仕事の幅が広がる。昔はパンチカードを打つだけの人がいましたが、いまそんな人はいません。それと同じで、できることの幅が広がり、少ない人数で大きなソフトウェアが作れるようになる。これは、いいことです。より良いソフトウェアが増えていくし、AIとともに、より良いソフトウェアを作れるプログラマが生き残っていく。

ソースコードに、設計の美しさは宿る

今日、私はずっと「プログラマ」と言ってきました。「エンジニア」ではなく、あえて「プログラマ」と言いたい。なぜなら、依然として、ソースコードが重要だからです。

DHHは「Aesthetics is truth.（審美眼こそが真実である）」と言っています。最終的に、ソフトウェアを動かすのは何か。それはソースコードです。GitHubに保存するのも、自然言語の仕様ではなく、ソースコードです。文脈として日本語を残すことはあっても、コンピュータを動かすのはソースコードなのです。

だから、ソースコードを大事にしていかなければいけない。とはいえ、それは手で打たなければいけない、ということではありません。

プロの敷居は、むしろ高くなる

そうした審美眼を持ったプログラマは、これからどうなるのか。

AIによって、プログラミングの裾野は、すごく広がるでしょう。誰でもプログラムを作れる時代が来る。その一方で、プロフェッショナルなプログラマの敷居は、おそらく高くなります。

少し前なら、儲かるからプログラマになる、流行っているからプログラマになる、柔軟に働けるから、リモートワークができるから。そんな理由でプログラマを選ぶ人もいました。これからは、そういう付随する動機で選ぶ人は、減っていくかもしれません。

私はむしろ、それを良かったと思っています。付随する理由でプログラマを選ぶのではなく、ここにいるみなさんも、そして私も、プログラミングが好きだからプログラマを選んでいる。これからの社会は、その動機が、より尊重される場所になっていくのではないか。

いいソフトウェアを、つくる

ソニックガーデンの理念は、ずっと変わらず「いいソフトウェアをつくる（Make Great Software）」です。

時代が変わろうが、道具が変わろうが、いろんなことが起きていきます。社会は変わっていくし、不安になることもある。それでも、私たちは、いいソフトウェアを一生懸命につくりましょう。

私の話は、以上です。ご清聴、ありがとうございました。

質疑応答：弟子は、いつ親方に聞くのか

司会の方から、こんな質問をもらいました。

親方と弟子のチームが、AIとも一緒に働いているとき、弟子が疑問を持ったら、AIに聞くのは簡単です。では、AIにではなく親方に聞くべきときが来た、と弟子はどうやって分かるのでしょうか。

いい質問ですね。実は、AIに聞くか親方に聞くか、を分けてはいません。弟子も親方も、ずっとAIに質問しながら進めていきます。どちらかというと、AIは一緒に作るもの。そのうえで、出来上がったものがいいものかどうかは、親方に見てもらう。そういう関係になっています。

当日の様子や会場の雰囲気は、別の記事に書いています。

Laravel Live Japan 2026で登壇してきました：別々の道から、同じ場所で交わるということ

いまAIに本気で取り組もうとしている経営者の多くが、使えば使うほど料金が膨らんでいくことに、頭を悩ませているのではないでしょうか。実際、私たちソニックガーデンでも、この一ヶ月で利用料は2〜3倍に跳ね上がりました。請求額を見たときは、これは経営判断のいる金額だな、と慄きました。

これだけのコストをかけて、本当に続けるべきなのか。かといって、使わなければ取り残される。どこまで本気で乗ればいいのか、決めきれない。だから、ひとまず様子見になる。私たちも、例外ではありませんでした。

様子見は、慎重ではなく迷いのコストではないか

様子見というのは、リスクを避けているように見えて、実は別のコストを払い続けている。決められないことのコストです。使うか使わないかを各自の判断に委ねているあいだ、組織は迷い続けます。迷いは目に見えないから、コストとして計上されません。けれど、確実に組織の勢いを奪っていきます。

そう考えると、経営者の仕事は、正解を当てることではないのかもしれません。半年後にどのAIが勝っているかなんて、誰にもわからない。わからないなりに、迷いをどこかで終わらせること。それが、決めるということです。

だから私たちソニックガーデンは、Claude Codeを全社の標準にすると決めました。より良いものが出たら、そのときはまた全員で乗り換えればいい。ばらばらに迷い続けるより、全員で決めて、全員で動く。

一度知った便利さには、もう戻れない

とはいえ、決めるにしても、コストは現実です。トークンの料金は、これからも上がっていくものとして見ておいたほうがいいでしょう。

このとき、考え方は大きく二つに分かれます。一つは、保険をかける考え方。AIは使うけれど、いつ大きく値上がりしても止められるように、AIなしでも回る状態を残しておく。慎重な経営として、よくわかります。もう一つが、保険をかけずに振り切る考え方です。

私たちソニックガーデンが選んだのは、後者でした。なぜか。そもそも、AIなしの状態に「戻る」ということが、もうできないからです。

電気のことを考えてみます。洗濯機が電気で動くようになったのに、電気代が高くなるかもしれないから洗濯板も捨てずにとっておこう、とはなりません。掃除機があるのに、ほうきも忘れないように、ともならない。一度その便利さを知ってしまえば、人はもう、それがある前提で暮らし始めます。技術は、なかったことにはできない。

AIも、たぶん同じです。この生産性を知ってしまったら、なかった頃には戻れない。いつでも引き返せるように身構えながら、おっかなびっくり前に進む。ブレーキを踏みながらアクセルを踏むことは、もうできないのです。保険をかけたつもりでも、戻る場所のほうが、もう無いのですから。

後戻りできる決断と、できない決断

こうした振り切り方は、これまで殆どしてこなかった。普段は、経営の判断をできるだけ後戻りできる形にして、小さく試すところから始めます。やってみて、違えばやめる。それが殆どです。

それでも稀に、後戻りのできない領域に踏み込むしかないときがあります。10年前、全社員リモートワークでオフィスを手放したときが、そうでした。調べて、試して、準備はします。けれど最後は、不退転で決めるしかありません。あのときも、振り切った先で、会社とは器ではないのだと気づきました。

非エンジニアも含めた全社員でAIに振り切る今回も、その類の決断だったと考えています。

高いのではなく、使いこなせていないと高い

戻れないのなら、やることは一つです。引き返すのではなく、使い倒して、先に行く。生産性を上げて、上がった分で、これまで以上の価値を生み出していく。料金が上がるのなら、その分は、そうやって稼げばいい。

そもそも「AIは高い」というより、「使いこなせていないと高い」のではないでしょうか。ばらばらに使えば、料金だけがかさんでいきます。同じ金額でも、組織で使い方をそろえれば、そこから生まれる価値は変わってきます。

だからこそ、組織で揃えることに意味があります。同じ道具を同じように使うからこそ、誰かの工夫が、そのまま誰かの学びになる。初日に書いた「壮大な部分最適化」で終わらせないために、組織で標準をそろえる。ケチって小さく使うのとは、逆の道です。

振り切ってみて、変わったのは姿勢だった

全社で振り切ってみて、見えてきたことがあります。

一番大きかったのは、生産性でも、料金でもありませんでした。変わったのは、技術よりも、組織の姿勢のほうだったのです。

象徴的だったのが、弟子を育てる立場の親方たちです。それまで親方たちは、育成にAIをどこまで使わせるか、距離を測りかねていました。手を動かして覚えるべき時期に、AIに頼らせていいのか。答えの出ない問いの前で、考えあぐねていたのです。

ところが、ひとまず使わせてみようと振り切ったとたん、その先を考え始めました。AIがある前提で、人はどう育つのか。そもそも育成とは、何をすることなのか。立ち止まらせていた問いが、決めたことで、前に進む問いに変わったのです。

弟子たちのほうも、それぞれに試行錯誤しながら、会社としての使い方を学ぶ勉強会を開くようになりました。そう、決めたことがもたらしたのは、便利な道具ではなく、迷いの終わりでした。迷いの消えた組織は、横並びで、安心して試せるようになります。これは現場の中にいると見えにくく、経営者の位置からだからこそ見えた変化でした。

この変化は、エンジニアだけのものではありませんでした。コーポレートの仕事でも、エージェントとの協働が始まっています。非エンジニアの現場で何が起きているかは、また別の記事にゆずりますが、姿勢が変わったのは、会社全体だったのです。

先に行ったうえで、考える

振り切るというのは、勢いで突っ込むことではありません。立ち止まるのをやめて、次の問いに進むことです。あの親方たちが、使わせると決めたとたんに、AI前提の育成という次の問いへ進んだように。

その先の答えを、私はまだ持っていません。AIで会社はどう変わるのか、仕事はどうなっていくのか、わからないことだらけです。それでも、もう進み始めています。半年後には、また景色が変わっているのでしょう。

考えてから動くのではなく、動いてから考える。先に行ったうえで、考える。それが、私たちソニックガーデンの、この一ヶ月でした。

＊ ＊ ＊

1ヶ月の短期集中連載として、毎日1本ずつ綴ってきたこの連載も、今回が最終回です。毎日書き続けたソニックガーデンのプログラマたち、そして読んでくださったみなさん、1ヶ月間、お疲れ様でした。

連載の記事一覧は、以下のページから辿れます。

まとめページ: https://www.sonicgarden.jp/tech/claudecode

ハッシュタグ: #claudeonsonicgarden