Social Change!

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

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

「成功したら、幸せになれる」。そう信じて走っている人は、多いのではないでしょうか。事業がうまくいったら、目標を達成したら、そのときようやく報われる。裏を返せば、成功するまでは幸せではない、ということになります。でも、その順番は本当に正しいのでしょうか。先日、岡山県津山市の起業家コミュニティに招かれて、「成功を追わない起業と経営」というテーマで[話をしてきました](https://kuranuki.sonicgarden.jp/archives/36088)。起業の場で「成功を追わない」とは、挑発的に聞こえるかもしれません。でも、これは私が15年、会社を経営してきて、振り返った先にある実感です。 ## 「成功を追わない起業」は、矛盾ではないいま、私はソニックガーデンという会社を、16期目まで続けてきました。社員は70人ほど、売上は11億円ほど。あわせて、上場企業の取締役CTOも務めています。こうして並べると、それなりに成功しているように見えるかもしれません。でも、成功を目指してここまで来たかというと、そうではありませんでした。起業というと、大きな志を掲げ、退路を断ち、未来から逆算して一発を狙う。そういうイメージがあります。周りにいる起業家も、裸一貫で、銀行から融資を受けて、仲間もいないところから立ち上げた、という人が多い。まぶしく見えます。私は、そうではありませんでした。始まりは、社内ベンチャーで一緒にやってきた仲間を、会社の都合で失いたくない、というだけのものでした。壮大なゴールから逆算したわけではない。いまあるものを受け入れて、目の前のことに手を打ち続けてきた。そうしていたら、いつの間にか15年が経っていました。だから「成功を追わない」というのは、努力しないとか、投げやりだ、という話ではありません。追いかけるゴールを先に決めて、それだけを目指す、というやり方をとらなかった。それだけのことです。 ## 「成功したら幸せになれる」の順番を疑う新しい事業は、1000に3つしか成功しないと言われます。もしそれが本当で、成功して初めて幸せになれるのだとしたら、残りの997は不幸になってしまう。そんな世の中には、あまり希望がないように思います。成功を目指すこと自体は、悪くありません。ただ、成功するまでは幸せじゃない、と自分で決めてしまうと、道のりがずっと苦しくなる。ゴールに着くまで、耐え続けることになるからです。幸せは成功しないと手に入らない、というのは、違うのではないか。成功するかしないかの前に、今すでに幸せであるかどうか。そちらのほうが、よほど大事なのではないでしょうか。 ## 起業には「成したい」と「ありたい」の二種類がある自分のやってきたことを振り返って、起業には二種類あるのではないか、と考えるようになりました。一つは、「成したい起業」。大金持ちになりたい、有名になりたい、あるいは、こういう社会問題を解決したい。何かを成し遂げたいという強い目的から始めるもの。今どきの起業には、この形が多い。立派だし、社会を前に進める力になります。ただ、成し遂げるまでは「まだ足りない」と言い続けることになる。成せないうちは、どうしてもしんどい。もう一つは、「ありたい起業」。いい状態であり続けたい、この関係を続けたい、というところから始めるもの。私は、こちらでした。5人で始めた会社で、その5人と楽しく働けている。その状態を、手放したくない。だから、続けたい。「ありたい」から始めると、ビジョンは、いつか達成して終わるゴールではなく、続けることで実現していくものになります。起業した当時から今にいたるまで、不幸だと感じたことはありませんでした。「成したい」を否定するつもりはありません。合っている人は、それでやればいい。ただ、「ありたい」から始める起業が、あってもいいのではないか。この「ありたい姿」のまま続けていくという話は、[別の記事](https://kuranuki.sonicgarden.jp/archives/36033)にも書きました。 ## 私の始まりは、仲間を守りたい、それだけだった私がソニックガーデンを始めたのは、35歳の頃に立ち上げた社内ベンチャーがもとになっています。上場企業の中で、新しい事業をやらせてもらった。少人数の小さなチームで、喧嘩しながら、なんとか単月黒字にこぎつけたところでした。ところが、いよいよこれからだ、という時に、会社がグループ内で次々と合併していく方針になりました。私たちの小さな事業も、鶴の一声で統合されたり、やめさせられたりしてもおかしくない。せっかくできたいいチームを、どうやったら守れるのか。考えた末に出た答えが、事業ごと買い取って独立する、というものでした。さすがに怖かった。起業したこともない人間が、安定した上場企業の立場を捨てて出ていく。踏み切れずにいたときに、2011年の東日本大震災が起きました。人はこんなに簡単に死ぬのか、と多くの人が思った。私も思いました。数年待てばまたチャンスがある、と大人たちは言ってくれたけれど、その数年のうちに終わってしまうかもしれない。だったら、やろうと。借金をして会社をつくり、事業と社員を買い取って、ソニックガーデンが始まりました。5人での創業です。その5人は、15年経った今も、まだ一緒に働いています。壮大なビジョンがあって起業したわけではない。目の前の仲間と、この働き方を、守りたかった。それだけでした。 ## ありたい姿は、変わり続けないと保てないいい状態を続けたい、と言うと、今のままでいい、変わらなくていい、と聞こえるかもしれません。でも、実際は逆でした。ありたい姿を保つために、私たちは変わり続けてきました。変えたくて変えたことは、ほとんどありません。たいていは、やむを得ず変えてきた。地方に住む社員が増えたので、東京の本社オフィスをなくして、みんなリモートワークにした。全員が離れて働くと管理しきれないので、管理をやめて、一人ひとりがセルフマネジメントで働くようにした。若い社員を採用し始めたら、育てる場所が要るので、[徒弟制度](https://kuranuki.sonicgarden.jp/archives/35992)をつくって、親方の家の近くに拠点を建てた。一つ何かが起きるたびに、頑なに守るのではなく、現実を受け入れて、手を打つ。その繰り返しでした。オフィスをなくしたのに、地方に拠点を建てる。ちぐはぐに見えるかもしれませんが、目の前の状況に合わせていったら、そうなった。面白いのは、これだけ変わり続けてきたのに、やりたかったことは何も変わっていない、ということです。仲間と楽しく良いソフトウェアをつくり続けたい。その一点だけは、15年前からずっと同じです。変わり続けたからこそ、変わらずにいられた。 ## 私のやり方は、エフェクチュエーションと呼ばれていたこういう進み方を、自分では特に意識したこともありませんでした。ただ「いいソフトウェアをつくる」ことに一生懸命だっただけです。ところが、そのやり方にはちゃんと名前がついていたと、あとから知りました。「エフェクチュエーション」という理論です。経営学者のサラス・サラスバシーが、優れた起業家たちに共通する思考様式を研究して見つけたものだそうです。日本では、神戸大学の吉田満梨先生たちが紹介されています。一般的な起業論は「コーゼーション」、因果論と呼ばれます。目標を決めて、そこから逆算する。夢に日付をつけて、足りないものは、お金でも人でも外から調達してくる。未来を予測して、計画通りに進める考え方です。エフェクチュエーションは、その逆です。未来から逆算しない。まず手元にあるもので始める。動いてみて、できたことを見て、次の一手を決める。チャレンジはするけれど、一か八かはしない。失敗しても致命傷にならない、許容できる範囲で試していく。こうした考え方に、いくつかの原則があります。手元にあるものから始める「手中の鳥」。損しても大丈夫な範囲で試す「許容可能な損失」。酸っぱいレモンしか手に入らなくても、工夫すればレモネードになるように、予期せぬ出来事さえ味方に変える「レモネード」。思ってもみなかった人と出会い、一緒に何かをつくっていく「クレイジーキルト」。そして、目的地を決めて一直線に進むのではなく、飛行機の操縦のように、風が吹けば舵を切りながら進んでいく。呼び名はいろいろですが、どれも、今あるものから始めて、変えながら進む、という同じ姿勢の現れです。理論を知らずにやっていたことが、優れた起業家の思考様式と同じだった。しかも津山で話したとき、逆算しないやり方に共感する、今まさにそうしている、という声が何人もの人から返ってきました。名前を知らないままやっていたことが、誰かの実感と重なる。面白いものです。吉田先生たちの本は、黄色い表紙の[『エフェクチュエーション』](https://amzn.to/4gCLWuh)。読むと、自分のやってきたことに名前がつくようで面白いので、おすすめです。 ## 成功を追わなくても、幸せに働き続けられる起業に、大きな志も、退路を断つ覚悟も、綿密な逆算も、必ずしも要りません。もちろん、それが合う人は、そのやり方でいい。でも、今あるものに満足して、小さく始めて、少しずつ良くしていく。そういう起業も、経営も、あっていいはずです。今のままでいい、という話ではありません。いい状態を続けるためには、変わり続ける必要がある。ただ、その変化は、遠くのゴールのためではなく、今ある手元のもの、周りにいる人たちを大事にした結果として、起きていく。成功を追わなくても、幸せに働き続けることはできる。私は、そう考えています。そしてこの15年、変わり続けるなかで手放さなかったものが一つだけあるとしたら、それは「[遊ぶように働く](https://kuranuki.sonicgarden.jp/archives/35972)」という、始めたときからの願いでした。その「遊ぶように働く」を、もう少し自分の言葉にできないかと考えて、仕事を「労働」ではなく「技芸」として捉える、という見方にたどり着きました。その話は、9月にミシマ社から出る『[自分と社会をいい感じにする仕事技芸論](https://amzn.to/3Rsmj5e)』に書いています。津山で話したときの資料も、あわせて載せておきます。 [スライドを開く（SpeakerDeck）](https://speakerdeck.com/kuranuki/cheng-gong-wozhui-wanaiqi-ye-tojing-ying-huan-jing-yali-chang-wohuo-kasuzhan-lue-homing-2026)

津山で「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枚に「気持ち悪い」と言って、なぜ気持ち悪いのかを自分で言語化してもいた。このスライドが気持ち悪いのは、私の大事なスタンスと違っているからだ、と。何が違和感で、何を大事にしたいのか。それを言葉にするのは、いつも自分の側だった。結果として、出来上がった資料は、自分で作ったのと同じようなものになっている。これは自分の作品だと言えるし、だから納得して壇上に立てる。[手は動かしていない](https://kuranuki.sonicgarden.jp/archives/36043)が、考えることは何ひとつ減っていない。むしろAIが賢くなった分、こちらの考えの浅さがすぐに露呈する。手は楽になっているが、頭は楽になっていない。 AIを使った作品は賞に応募できない、という話を聞く。「AIを使っていません」という表明が、作品の価値になることもあるようだ。AIを使うことを良しとしない風潮は、楽して成果をあげることへの忌避感から来ているのではないか。使ったら、ずるだというわけだ。 AIに丸投げしたら、そりゃダメだろう、とは思う。考えの浅いまま任せれば、浅いものが出来上がるだけだ。しかし、本気でAIを使ってみれば、決して楽ではないことがわかる。良いものを作ろうとすれば、結局は本人の力が要る。逆に、AIを駆使した上で、自分の思考を乗せることも、自分らしい表現にすることもできる。AIを使ったからといって、クリエイティビティが本人のものでなくなるわけではない。いずれ全員がAIを前提とするようになれば、結局はその土俵での差が出てくる。それなら、どんどん[AIを使いこなすこと](https://kuranuki.sonicgarden.jp/archives/36052)に取り組んだ方がいい。

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

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

ソニックガーデンは、本日7月1日をもって16期に入りました。ここまで続けてこられたのは、日頃からお付き合いいただいているお客さま、パートナーのみなさん、そして一緒に働いてくれる仲間たちのおかげです。あらためて、ありがとうございます。 15期は、事業も人も大きく広がった一年でした。クラシコムとの資本業務提携、韓国からの採用、高校を卒業したばかりのメンバーの入社、倉貫書房とミシマ社の業務提携など、これまでのソニックガーデンの枠を超えるような挑戦がいくつも重なりました。私たちは「思い出」を大切にする方針を掲げていて、それを実践する形で、全国各地でのハッケーション（合宿型の開発イベント）や、弟子合宿・親方合宿・コーポレート合宿なども積み重ねてきました。一緒に過ごした時間そのものが、私たちの財産になっていると感じています。 15期の後半、つまり今年の前半は、AIの登場によって会社そのものが大きく変わった時期でもありました。Claude Codeを全社の標準にすると決め、開発だけでなくコーポレートの仕事も含めて、AIを組み込んだ働き方へと組織を作り変えてきました。AIファーストな組織になっていく手応えを、この半年でつかんだように思います。そして16期を迎えるにあたり、経営体制もひとつ新しくします。2014年の入社から10年以上一緒にやってきた野上誠司が、本日より取締役執行役員に就任しました（[会社からのお知らせ](https://www.sonicgarden.jp/blog_articles/7841)）。あえて監督と執行を分けないことが、ソニックガーデンにとっては大事なのではないか。今回の経営体制を考えるときに、そう思いました。これは、仕事を「技芸」として捉えていることとも重なります。「納品のない受託開発」も、分業せずに一気通貫で取り組むからこそ大きな価値が出せますし、担っている本人も自分の仕事の手応えを最後まで感じ取ることができます。経営も同じです。意思決定と実務を切り離さず、自分で担い続けることで、手応えを保てるのだと考えています。 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は生まれ持った才能ではなく、後天的に鍛えることができる。このあたりは以前、[正論だけでは届かない](https://kuranuki.sonicgarden.jp/archives/34948)にも書きました。 ## 知性は、身体を土台にした五つの層でできている IQ、EQ、SQは、内から外への階層になっています。その内側と外側には何があるのか。AIと考えを行き来させながら整理してみたのが、次の五層です。完全な自説ではなく半ば言葉遊びですが、知性を眺める補助線にはなります。 ![知性の5層モデル。中心の身体（PQ）から、内面（IQ・EQ）、社会（SQ）、時間（TQ）、実存（XQ）へと外へ広がる同心円](https://kuranuki.sonicgarden.jp/rails/active_storage/blobs/proxy/eyJfcmFpbHMiOnsiZGF0YSI6MTMxNCwicHVyIjoiYmxvYl9pZCJ9fQ==--2d3b6d0fe6e262c359c1a4a4f42d2b569e90b0c8/2026-06-16-five-iq-layers.png) 中心は身体、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を底上げできるようになれば、差がつくのはその先になります。以前、[「頭がいい」が武器にならなくなる時代](https://kuranuki.sonicgarden.jp/archives/35966)で、腕力が相対化されたように知力も相対化されていく、と書きました。それが現実になりつつあります。では、何が残るのか。昔から変わらず、人を相手に成果へ変えてきた力、SQです。正しい答えはAIが出してくれても、それを誰にどう届け、人をどう動かすかは、人間に残り続けます。頭がいいだけでは、武器にならない。AIと働くほど、その実感は強くなっています。＊＊＊人を動かすことには、古くからの定番があります。デール・カーネギーの[『人を動かす』](https://amzn.to/43AWnqF)。1936年の本がいまも読み継がれているのは、SQが時代を問わず仕事の核心にあり続けてきた証でしょう。

事業活動のすべてをコードにする

2026-06-12T11:05:00+09:00

毎日、Claude Codeに仕事を頼んでいる。文章を書くのも、調べものも、資料づくりも。[優秀な部下が何人も増えたような感覚](https://kuranuki.sonicgarden.jp/archives/36023)で、それでいて、まだ先がありそうな気がしている。その「先」が何なのか、最近すこし見えてきた。個人の仕事が速くなる話ではなく、チームの仕事が変わる話だ。Claude Code単体では片手落ちで、GitHubとセットで使ったときに、本当の変化が始まるのではないか。エージェントに仕事を頼むと、成果物はファイルになる。ファイルはリポジトリに置かれ、変更の履歴が残り、誰がいつ何を変えたのかを辿れる。自分ひとりではない。チームの仲間も、それぞれのエージェントも、同じ場所を見て仕事をする。リポジトリは、エージェントにとっての職場みたいなものだ。考えてみれば、ソフトウェア開発は、ナレッジワークの進化形だったのではないか。成果物をテキストで残し、変更を履歴で管理する。お互いの仕事をレビューし合い、課題はチケットにして見えるようにする。プログラマたちは、知識をチームで扱う仕事の方法論を確立してきた。この方法論を他の仕事にも持ち込みたいと考えていたが、GitとGitHubの習熟をエンジニア以外に求めるには、壁が高すぎた。やってみて気づいたのは、この壁が二つに分かれていたことだ。コマンドを操作する壁は、Claude Codeが消してしまった。自然言語で頼めば、コミットもプルリクエストもエージェントがやってくれる。だが、コミットやブランチといったGitの概念を理解する壁は残った。そこが腹落ちしていないと、エージェントに頼むことすらできない。それは全社で進めてみての発見だった。それでも、概念は学べば越えられる。 Infrastructure as Codeという言葉がある。サーバーの構成をコードとして書くことで、再現も、レビューも、改善の蓄積もできるようになった。同じことを、事業活動の全部でやればいい。経理でも人事でも広報でも、仕事の成果物をMarkdownで書いてリポジトリに置く。事業活動のすべてをコードにする、ということだ。ソニックガーデンでは、これを非エンジニアも含めて、[全社で進めている](https://kuranuki.sonicgarden.jp/archives/36040)。社長の私自身が率先して、ブログの原稿も、講演資料も、経営の検討メモも、Markdownでリポジトリに入れた。これは、2016年に全社リモートワークで[オフィスを手放した](https://kuranuki.sonicgarden.jp/archives/21165)とき以来の変革になる気がしている。あのときは、働く場所が物理からオンライン上のソフトウェアに移った。今度は、仕事そのものがソフトウェアの側に移っていく。人の作業を補助するためにソフトウェアがあるのではなく、コードになった事業を、人とエージェントが一緒に改善し続けていく。ソフトウェアが先にある会社だ。いま社内のリポジトリには毎日コミットが積み重なっている。会社が少しずつ、コードになっていってる感じがするな。

AIを使いこなす力は、経営者の動き方と似ている

2026-06-08T19:15:00+09:00

AIの提案を鵜呑みにしてしまい、達成感を失ったり、うまく成果を出せずにいる人を見かけるようになった。AIは、問われたことに最適化した回答を返してくる。問う側の目線が短期になっていれば、返ってくる答えも短期になる。一方で、AIをうまく使いこなしている人もいる。問いを投げて自分の考えを深め、手間のかかる作業は任せる。そうやってパートナーのように付き合っている。その違いは、どこにあるのだろう。 AIを使いこなすには、実は2つの能力がいるのではないか。ひとつは、出てきたものの良し悪しを判断する力である。たとえばAIが書いたコードを読んで設計の筋を見抜けるか、AIが書いた文章を読んで論理の飛びを見つけられるか。技術力に直結する力で、その分野での自分の専門性そのものに近い。もうひとつは、AIに対して率直に意見を言える力だ。出てきた答えをそのまま受け取らず「今のこの状況だとそれはおかしくないか」「なぜそう言うのか」と問い返す。対等な相手として尊重しつつ、最後のハンドルは自分が握る。後者は、経営者が得意としている部分ではないかと思う。経営者は、自分ひとりで解決しようとしない。私自身、人事の専門家や弁護士、税理士と仕事をしてきた。どの領域でも、相手は私よりずっと詳しい。その代わりに、経営者がやっているのは「なんとかする」ことだ。自分で全部考えて決めるというよりも、専門家の意見を踏まえつつ、うちの状況だと違うのではないかと問い返し、最後は自分で決めて責任を取る。意思決定と責任が、経営者の仕事なのだ。 AIへの付き合い方は、これとほとんど同じ構造をしている。世の中の経営者がAIをうまく使えているのは偶然ではなく、普段からやっている動き方を、AI相手にも自然に持ち込んでいるからではないだろうか。とはいえ、自分より詳しい相手と仕事をする経験など、経営者じゃないとなかなか積めなかった。だが、AIは誰にとっても初めての「自分より詳しい部下」だ。経営者だけのものだった練習の場が、いま誰の手元にもある。これからは、そうやって誰もが自分の専門外をAIに任せて成果を出すことが求められる時代になっていくんだろうな。

「手打ちコーディング」がなくなっても、作り手であることは変わらない

2026-06-05T06:34:00+09:00

このごろ、プログラマが手でコードを打つことが、ほとんどなくなってきた。コーディングエージェントに任せた方が、キーボードを叩くより圧倒的に早いからだ。少し前なら、コーディングと言えばキーボードを叩いてコードを書くことだった。今は違う。エージェントが書くのが当たり前になり、人間が手で打つ方が特別なことになった。私はこれを「手打ちコーディング」と呼んでいる。「手打ちそば」も、昔はなかった言葉のはずだ。そばはそばだった。機械でそばが作られるようになって、初めて手で打つそばを「手打ち」と呼ぶようになった。標準が機械側に移ったときに、それまで標準だったものに名前がつく。コーディングにも、同じことが起きた。そういえば「手打ち」と言いつつ、コーディングで実際にやっているのはキーボードを叩くことであって、手で書いているわけではない。それでも「手打ち」と呼ぶことに、自分でも違和感がない。比喩は不思議なものだ。この先、エージェントに指示を出して書かせることまで、いつか「手で書く」と呼ばれる日が来るのかもしれない。これはコーディングだけの話ではない。文章を書くときも同じ。この記事も、エージェントを使って書いている。多少のミスや違和感はある。それでも書き直させた方が、自分で手打ちするより早いし、楽だ。人間、一度楽を覚えると元には戻れない。パンチカードからキーボードに変わったときも、きっと同じことが起きたのだろう。手打ちからエージェントに変わるのも、その延長線上の出来事だ。やり方が変わるだけで、作ることそのものがなくなるわけではない。エージェントに任せても、プログラマがソフトウェアを作っていることに変わりはない。文章だって同じだ。とはいえ、手打ちが残る世界もある。文章の世界では、いまだに原稿用紙にペンで書く小説家がいると聞く。キーボードで打った方が圧倒的に早いのに、ペンで書いた方がいい作品ができると信じている。それも、人の手による作品作りのひとつの道だ。ただし、コーディングはそうはならないだろう。小説と違って、コードの読み手は書き手の手の痕跡を求めて読んでいるわけではないからだ。コーディングはエージェントの手に渡って、それが当たり前になっていく。手で打たなくなっても、作り手であることは変わらないんだろうな。

AI時代の仕事技芸論〜ソフトウェア開発で「遊ぶように働く」職人的熟達のすすめ

2026-06-02T06:44:00+09:00

日本で初開催となった [Laravel Live Japan 2026](https://laravellive.jp) に、登壇者として呼んでいただきました。「AI時代の仕事技芸論」というテーマで話した内容を、当日の流れのまま書き起こします。スライドと動画は以下です。 ## なぜ、Laravelのイベントで話すのか私は[ソニックガーデン](https://www.sonicgarden.jp/)という会社を経営しています。日本の方ならご存じかもしれませんが、Ruby on Rails をもう15年やってきた会社で、社員もほとんどが Rails のスペシャリストばかりです。では、なぜ Laravel のイベントで話すのか。私はもう一社、[クラシコム](https://kurashicom.jp/)という会社にも取締役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時代にプログラマはどう生きていくのか、というテーマで[動画を公開していました](https://www.youtube.com/watch?v=JiWgKRgdgpI)。とてもいい内容で、私自身も強く共感したので、すぐに本人に連絡をとり、日本語に翻訳して公開していいかと尋ねました。快諾してくれたので、私のブログに翻訳を載せています。そこで DHH が使っていた言葉が、「The Arts and Crafts of Work」でした。仕事を、技芸として捉え直す。実は私も、ここ数年ずっと、仕事を技芸とする文化を広めたいと言い続けてきました。それぞれの場所で、独立して、まったく同じ言葉に行き着いていたのです。この「仕事技芸論」が、今日の話の背骨になります。その記事が、こちらです。 [「審美眼こそが真実」〜DHHが語るAIエージェント時代の技芸論](https://kuranuki.sonicgarden.jp/archives/36034) ## 「手打ちコーディング」会場には海外から来た方も多くいました。日本食はもう召し上がったでしょうか。蕎麦を食べた人はいても、「手打ち蕎麦」を食べた人と聞くと、ぐっと減ります。「手打ち蕎麦」という言葉は、いつできたのか。昔は、蕎麦は蕎麦でした。機械で蕎麦が打たれるようになって初めて、手で打つ方が貴重になり、「手打ち蕎麦」という言葉が生まれたのです。最近、同じことがコードにも起きています。私自身も、コーディングエージェントでソフトウェアを作っていて、もうほとんど自分の手でコードを書きません。そうなると、手で打つことの方が、貴重になってくる。「手打ちコーディング」というわけです。ただ、手打ち蕎麦は機械より美味しいのですが、手打ちコーディングは、残念ながらAIの方がいい。だから手打ちコーディングは、いずれ滅びていくのだろうと思っています。 ## プログラマは、これからどうなるのかコードを書くのはAI。設計もAI。では、自分の役割は何になるのか。ソフトウェア開発という仕事は、これからどうなるのか。自分のキャリアは、どうなってしまうのか。おそらく、私たちも含めて、みなさんが不安に感じているところだと思います。ソニックガーデンという会社は、そこにどう向き合ってきたのか。これからどう向き合おうとしているのか。私たちが一つ大事にしてきたのが、[「遊ぶように働く」](https://kuranuki.sonicgarden.jp/archives/35972)というキーワードです。 ## 「遊ぶように働く」とは何か定義はとてもシンプルです。本人は、いたって真面目に、一生懸命にソフトウェア開発に向き合っている。それでも、周りから見ると、なんだかとても楽しそうで、夢中でやっているように見える。これが「遊ぶように働く」という状態です。これを実現するために、組織として大事にしてきたことが二つあります。一つは、内発的動機づけです。外から与えられる評価や報酬やボーナスのため、あるいは怒られるから、仕事だからやる、のではない。いいソフトウェアを作りたい、いいコードを書きたい、いい設計をしたい、いいものが作れたら嬉しい。そういう自分自身の気持ちで作っていく。もう一つは、フローです。チクセントミハイが提唱した概念で、難易度と自分のスキルがちょうど合うところにいると、人は夢中になれる。ゲームをしていて、ちょうどいい手応えの面のときに没頭してしまう、あの感覚です。仕事でも、同じことが起きるのではないか。この内発的動機づけとフロー。私たちはこれを大事にしてきました。そして、それを大事にしてきたら、意外なことに、ビジネスとしてもしっかり成果を出すことができています。 ## ソニックガーデンには「ない」ものばかりソニックガーデンは創業15年、この夏で16年目に入ります。約60名の会社で、ほとんどが腕のあるプログラマたちです。どんな仕事をしているかというと、いわゆる派遣ではなく、お客さまのCTOのような立場で参画します。CTOのような仕事ですから、事業戦略や経営戦略を考えながら、システムを設計し、ときにコーディングもし、運用もする。すべてを一気通貫でやる。しかも、弁護士やコンサルタントのように、一人で複数のクライアントを担当します。そういうプログラマたちが集まっている会社です。私たちはエクストリーム・プログラミングが好きなので、いわば「エクストリームなアジャイル」を目指してやってきました。では、内発的動機づけとフローを、どうやって実現するのか。私たちは、いろんなものをなくしました。売上目標がない。管理職もない。評価制度もない。指示命令もなければ、経費の決裁もない。オフィスもなければ、働く時間も決まっていない。ないないづくしです。それでも会社は動いている。一人ひとりが、自分で考え、自分で判断し、自分で進めているからです。そのかわりに私たちが大事にしているのが、[セルフマネジメント](https://kuranuki.sonicgarden.jp/archives/31016)です。 ## なぜ、セルフマネジメントなのかなぜセルフマネジメントなのか。ソフトウェア開発を考えてみてください。みなさん、一行一行「こう書け」と指示されますか。されないですよね。もし一行ずつ指示してくる上司がいるなら、その上司が自分で書けばいい。プログラマは、指示を受ける側ではありません。AIを使うなら、むしろ指示を出す側です。細かく指示命令されるより、自分で考えて作った方が、生産性は高い。だとすれば、外からの指示や管理や評価は、なるべくなくしてしまった方がいいのではないか。そう考えてやってみました。会社が潰れるかもしれないと思っていたのですが、意外なことに、ずっと成長を続けてくれています。もちろんセルフマネジメントとは、自己管理さえできればいい、という話ではありません。周りの仲間とうまく協調していくこと、お客さまとうまくやっていくこと。そこまで含めてのセルフマネジメントです。そういう人たちが集まると、何ができるか。上下のない、フラットなコミュニティが出来上がります。セルフマネジメントできる人は、特に指示がなくても、自分から前向きに取り組みます。お客さまのシステムを作っているのに、それを自分の作品だと捉えている節がある。作品づくりそのものに喜びを感じているし、少しずつ上達していくことに喜びを感じている。ピーター・センゲは「自己マスタリー」という言葉を使いましたが、自分で自分を上達させていく状態になると、楽しくてしょうがない。そういう人たちが集まっているのが、ソニックガーデンというコミュニティです。 ## 育てるために、徒弟制度を選んだセルフマネジメントで組織を作って、10年ほどやってきました。すると、私たちの会社はほとんど人が辞めないので、だんだん全体が年を取っていきます。それはそれでいいのですが、このままでは、ただ年を重ねただけの集団になってしまう。新陳代謝を起こしたくて、5年ほど前から、若い社員の採用を始めました。学生や新卒のような、ジュニアなプログラマの育成に、本格的に取り組み始めたのです。 AI時代になって、若いプログラマを採用する会社はどんどん減っています。そんななか、私たちは今年、高卒の社員を採用しました。18歳、19歳の人たちが働いている。自分でもちょっと驚きます。それでも、若い人にはしっかりお金をかけて投資していきたい。そう考えてやっています。とはいえ、ソフトウェア開発の経験が浅い人が、フラットでセルフマネジメントな環境で、いきなり活躍できるかというと、そんなに甘くはありません。ソフトウェア開発は、本当に難しい。では、どうやって育てればいいのか。私たちが取り組んだのが、徒弟制度でした。正解というより、私たちの場合はこうしてきた、という話です。私たちは、師匠のことを「親方」と呼んでいます。親方と弟子の関係でやろう、と。弟子に入ると、まず親方のいる場所に引っ越します。親方は全国でリモートワークをしているので、弟子のあいだはリモートワークをやめて、親方のところへ移ってもらう。いまは岡山、広島、兵庫、愛知の4カ所に親方がいます。「親方にわざわざ出社させるのか」というと、それは違います。親方はもともと在宅勤務をしていたのだから、親方の家の近くにオフィスを借りる。若い人はそこへ引っ越してくる。広島などは、オフィスと部屋がくっついたような場所で、ほぼ住み込みのようにして一緒に働いています。そうやって、親方と弟子が一緒にソフトウェア開発をする。ずっとペアプログラミングをしているようなものです。そうしているうちに、だんだんと仕事の仕方を覚えていく。これは、非常にアナログで前時代的に見えるかもしれません。けれど、よく考えてみると、ソフトウェア開発とは、本来そういうものではないでしょうか。私たちは誰も、最初から一人きりでプログラミングできるようになったわけではない。私自身も、振り返れば師匠がいました。自分で考えたものを、結果だけ見せて「いい・悪い」と言われるのではない。やっている途中を見せて、「そのやり方は違う、こうするといい」と教えてもらう。なるほど、こうやるのか、と。途中の過程を、見せて、見てもらう。そして、いいソフトウェア、いい設計、いい振る舞いを見極める力は、一緒に働くことでしか身につかないのではないか。だから私たちは、徒弟制度という形で、一緒に働くことを選びました。実際にもう5年やってきて、最初に入ってくれた弟子たちは、戦力としてしっかり活躍するようになっています。 ## 仕事を、技芸として捉え直すここまで話してきたのは、こういうことです。ベテランが自分の作品として仕事をし、自己マスタリーで上達していき、徒弟制度でそれを次の世代に伝えていく。これを一言で表すなら何か。私たちはそれを、技芸（Arts and Crafts）だと考えています。仕事を、単なる労働だと捉える。時間だから働く、給料のために嫌々働く、生活のためには仕方なく働く。そうやって捉えていると、AI時代に仕事が奪われていくという話のなかで、つまらないものが、さらにつまらなくなっていきます。そうではない。仕事を技芸として捉え直すことで、より楽しく、より自分のものとして、より自分の人生を豊かにするものとして、考えることができるのではないか。この「アーツ・アンド・クラフツ」という言葉は、DHHと重なって驚いたのですが、もともと私は、19世紀の[ウィリアム・モリス](https://ja.wikipedia.org/wiki/ウィリアム・モリス)が好きで、彼の起こしたアーツ・アンド・クラフツ運動からオマージュして使っていました。技術（エンジニアリング）は再現性を究極まで高めていくもの。一方で芸術（アート）は、再現性ではなく、創造性でやっていくもの。その両方のあいだにあって、結果だけでなく過程を大事にする。それが、仕事を技芸として捉えるということに通じます。これはソニックガーデンに限った話ではありません。おそらくみなさんの中にも、技芸として大事にしたいという心があるはずです。多くのプログラマが、仕事を技芸とする働き方をできるようになれば、幸せなプログラマがもっと増えるのではないか。そう思っています。 ## ソフトウェア開発は、コードを書くことだけだったのかでは、過程を大事にするというのは、手打ちコーディングに戻ることなのか。いいえ、そうではありません。コーディングエージェントは、どんどん使えばいい。技術と芸術のあいだなのですから、エンジニアリングの効率化は、どんどん進めていけばいいのです。その一方で、こう問い直してみたい。ソフトウェア開発とは、コードを書くことだけだったのか。私たちの仕事は、コードを書くことが目的だったか。そうではなかったはずです。ソフトウェア開発とは、まず、何を作るのかを決めること。お客さまやユーザー、あるいは自分のアイデアをもとに、何を作るかを決める。次に、どう作るのかを設計する。どうすれば最適になるか、どうすれば長く使われるか、どうすれば保守性が高くなるか。そして、作ったものを運用し、改善し、育てていく。ここまでやって、初めてソフトウェア開発でした。分業、分業、分業と切り刻んでいくと、効率だけが求められて、技芸ではなくなります。「コードを書いていた人はいなくなる」と言われますが、ソフトウェア開発は、全部やればいい。全部をやるとき、AIは味方になります。AIがあることで、生産性が高まり、喜びの時間が増えるのです。 ## 「AI vs 私たち」ではなく「問題 vs AIと私たち」 AIへの向き合い方を、もう少し考えてみます。コードを書くのはAIがやってしまう。では、自分の仕事はどうなるのか。だったら今度は、「AIに奪われない仕事を探そう」となる。けれど、残念ながら、それももうありません。AIに奪われない安全圏を探しても、見つからない。ほとんどのことは、AIができてしまうからです。そうではなくて、AIとは一緒にやっていく方がいい。私たちの会社でよく使う言葉に、[「問題 vs 私たち」](https://kuranuki.sonicgarden.jp/archives/25729)というものがあります。あなた 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で登壇してきました：別々の道から、同じ場所で交わるということ](https://kuranuki.sonicgarden.jp/archives/36039)

「AIは高い」のではなく、使いこなせていないと高い〜全社でAIに振り切った一ヶ月

2026-05-30T17:37:00+09:00

この記事は、連載「[Claude on SonicGarden](https://www.sonicgarden.jp/tech/claudecode)」の最終回です。初日に、[全社でClaude Codeを標準にする理由](https://kuranuki.sonicgarden.jp/archives/36032)を書きました。そこから一ヶ月、ソニックガーデンのプログラマたちが毎日それぞれの現場を綴ってきました。最終日にあたる今回は、その外側の話です。経営者として何を見て、何を決めたのか。 [#claude_on_sonicgarden](https://x.com/hashtag/claude_on_sonicgarden) いまAIに本気で取り組もうとしている経営者の多くが、使えば使うほど料金が膨らんでいくことに、頭を悩ませているのではないでしょうか。実際、私たちソニックガーデンでも、この一ヶ月で利用料は2〜3倍に跳ね上がりました。請求額を見たときは、これは経営判断のいる金額だな、と慄きました。これだけのコストをかけて、本当に続けるべきなのか。かといって、使わなければ取り残される。どこまで本気で乗ればいいのか、決めきれない。だから、ひとまず様子見になる。私たちも、例外ではありませんでした。 ## 様子見は、慎重ではなく迷いのコストではないか様子見というのは、リスクを避けているように見えて、実は別のコストを払い続けている。決められないことのコストです。使うか使わないかを各自の判断に委ねているあいだ、組織は迷い続けます。迷いは目に見えないから、コストとして計上されません。けれど、確実に組織の勢いを奪っていきます。そう考えると、経営者の仕事は、正解を当てることではないのかもしれません。半年後にどのAIが勝っているかなんて、誰にもわからない。わからないなりに、迷いをどこかで終わらせること。それが、決めるということです。だから私たちソニックガーデンは、Claude Codeを全社の標準にすると決めました。より良いものが出たら、そのときはまた全員で乗り換えればいい。ばらばらに迷い続けるより、全員で決めて、全員で動く。 ## 一度知った便利さには、もう戻れないとはいえ、決めるにしても、コストは現実です。トークンの料金は、これからも上がっていくものとして見ておいたほうがいいでしょう。このとき、考え方は大きく二つに分かれます。一つは、保険をかける考え方。AIは使うけれど、いつ大きく値上がりしても止められるように、AIなしでも回る状態を残しておく。慎重な経営として、よくわかります。もう一つが、保険をかけずに振り切る考え方です。私たちソニックガーデンが選んだのは、後者でした。なぜか。そもそも、AIなしの状態に「戻る」ということが、もうできないからです。電気のことを考えてみます。洗濯機が電気で動くようになったのに、電気代が高くなるかもしれないから洗濯板も捨てずにとっておこう、とはなりません。掃除機があるのに、ほうきも忘れないように、ともならない。一度その便利さを知ってしまえば、人はもう、それがある前提で暮らし始めます。技術は、なかったことにはできない。 AIも、たぶん同じです。この生産性を知ってしまったら、なかった頃には戻れない。いつでも引き返せるように身構えながら、おっかなびっくり前に進む。ブレーキを踏みながらアクセルを踏むことは、もうできないのです。保険をかけたつもりでも、戻る場所のほうが、もう無いのですから。 ## 後戻りできる決断と、できない決断こうした振り切り方は、これまで殆どしてこなかった。普段は、経営の判断をできるだけ後戻りできる形にして、小さく試すところから始めます。やってみて、違えばやめる。それが殆どです。それでも稀に、後戻りのできない領域に踏み込むしかないときがあります。10年前、全社員リモートワークで[オフィスを手放した](https://kuranuki.sonicgarden.jp/archives/21165)ときが、そうでした。調べて、試して、準備はします。けれど最後は、不退転で決めるしかありません。あのときも、振り切った先で、会社とは器ではないのだと気づきました。非エンジニアも含めた全社員でAIに振り切る今回も、その類の決断だったと考えています。 ## 高いのではなく、使いこなせていないと高い戻れないのなら、やることは一つです。引き返すのではなく、使い倒して、先に行く。生産性を上げて、上がった分で、これまで以上の価値を生み出していく。料金が上がるのなら、その分は、そうやって稼げばいい。そもそも「AIは高い」というより、「使いこなせていないと高い」のではないでしょうか。ばらばらに使えば、料金だけがかさんでいきます。同じ金額でも、組織で使い方をそろえれば、そこから生まれる価値は変わってきます。だからこそ、組織で揃えることに意味があります。同じ道具を同じように使うからこそ、誰かの工夫が、そのまま誰かの学びになる。初日に書いた「壮大な部分最適化」で終わらせないために、組織で標準をそろえる。ケチって小さく使うのとは、逆の道です。 ## 振り切ってみて、変わったのは姿勢だった全社で振り切ってみて、見えてきたことがあります。一番大きかったのは、生産性でも、料金でもありませんでした。変わったのは、技術よりも、組織の姿勢のほうだったのです。象徴的だったのが、[弟子を育てる立場の親方たち](https://kuranuki.sonicgarden.jp/archives/36027)です。それまで親方たちは、育成にAIをどこまで使わせるか、距離を測りかねていました。手を動かして覚えるべき時期に、AIに頼らせていいのか。答えの出ない問いの前で、考えあぐねていたのです。ところが、ひとまず使わせてみようと振り切ったとたん、その先を考え始めました。AIがある前提で、人はどう育つのか。そもそも育成とは、何をすることなのか。立ち止まらせていた問いが、決めたことで、前に進む問いに変わったのです。弟子たちのほうも、それぞれに試行錯誤しながら、会社としての使い方を学ぶ勉強会を開くようになりました。そう、決めたことがもたらしたのは、便利な道具ではなく、迷いの終わりでした。迷いの消えた組織は、横並びで、安心して試せるようになります。これは現場の中にいると見えにくく、経営者の位置からだからこそ見えた変化でした。この変化は、エンジニアだけのものではありませんでした。コーポレートの仕事でも、エージェントとの協働が始まっています。非エンジニアの現場で何が起きているかは、また別の記事にゆずりますが、姿勢が変わったのは、会社全体だったのです。 ## 先に行ったうえで、考える振り切るというのは、勢いで突っ込むことではありません。立ち止まるのをやめて、次の問いに進むことです。あの親方たちが、使わせると決めたとたんに、AI前提の育成という次の問いへ進んだように。その先の答えを、私はまだ持っていません。AIで会社はどう変わるのか、仕事はどうなっていくのか、わからないことだらけです。それでも、もう進み始めています。半年後には、また景色が変わっているのでしょう。考えてから動くのではなく、動いてから考える。先に行ったうえで、考える。それが、私たちソニックガーデンの、この一ヶ月でした。＊＊＊ 1ヶ月の短期集中連載として、毎日1本ずつ綴ってきたこの連載も、今回が最終回です。毎日書き続けたソニックガーデンのプログラマたち、そして読んでくださったみなさん、1ヶ月間、お疲れ様でした。連載の記事一覧は、以下のページから辿れます。まとめページ: https://www.sonicgarden.jp/tech/claudecode ハッシュタグ: [#claude_on_sonicgarden](https://x.com/hashtag/claude_on_sonicgarden)

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

2026-05-29T09:12:00+09:00

日本では初開催となる [Laravel Live Japan 2026](https://laravellive.jp/ja) のDay 1（2026年5月26日）に、講演者として登壇させていただきました。タイトルは「AI時代の仕事技芸論：ソフトウェア開発で『遊ぶように働く』職人的熟達のすすめ (The Arts and Crafts of Work in the AI Era — Toward Mastery in Software Development)」。日本語で講演し、スライドは英語、字幕は自動翻訳でつけてもらいました。私は普段、Ruby on Railsを専業とするソニックガーデンの代表取締役を務めています。同時に、長くLaravelで基幹システムを育ててきたクラシコムの取締役CTOでもあります。RailsとLaravel、どちらの現場も知る立場から、AI時代のソフトウェア開発について話してきました。 ## かつての仲間からの招待と奇妙な符合今回、私が登壇することになったきっかけは、主催者である濱崎さん（Ryuta Hamasaki）からの招待でした。濱崎さんは、10年近く前にクラシコムで一緒に働いていた仲間です。当時の私は上司のような立場でした。その後、彼が海外へ渡っていくのを見送ったのでした。 ![](https://kuranuki.sonicgarden.jp/rails/active_storage/blobs/proxy/eyJfcmFpbHMiOnsiZGF0YSI6MTMwNSwicHVyIjoiYmxvYl9pZCJ9fQ==--98e6f7b8c8eee5199321aa751cebb9f30ef3bf56/2026-05-28-laravel-jp-hamasaki.jpg) その濱崎さんが日本に戻り、Laravelの本社で働くようになりました。そして日本で初めてのLaravel Live Japanを主催し、私を登壇者として招いてくれたのです。当日は久しぶりに顔を合わせ、今度は主催者と登壇者として、同じ場所に立つことになりました。感慨深いものがありました。別々の道を歩んだ者が、同じ場所で交わる。それは私と濱崎さんだけの話ではありません。今年のLaravel Live Denmark 2026では、Rails作者のDHHとLaravel作者のTaylor Otwellが対談することが決まっています。別々のフレームワークを生んだ二人が、同じステージに立つのです。そのRailsとLaravelも、もとをたどれば、同じところから生まれてきたものです。人も、フレームワークも、コミュニティも。歩んできた道は違っても、行き着く先で交わっていく。不思議な縁を感じる日でした。 ## AI時代のプログラマとしての生き方講演の出発点に置いたのは、そのDHHが最近たどり着いた「The Arts and Crafts of Work」という考え方です。私が以前から話してきた「[仕事技芸論](https://kuranuki.sonicgarden.jp/?category=arts_and_crafts#feed)」と、同じ言葉に行き着いていました。DHHの記事は、本人の許可をもらって私のブログで日本語訳を公開しています。 [「審美眼こそが真実」〜DHHが語るAIエージェント時代の技芸論](https://kuranuki.sonicgarden.jp/archives/36034) そこから広げて、こんなことを話しました。 - 「手打ちそば」のように「手打ちコーディング」という呼び方が生まれつつあること - ソニックガーデンが「遊ぶように働く」「セルフマネジメント」「徒弟制度」を続けてきたこと - AIを敵にせず「問題 vs AIと私たち」と捉えること - 「ソースコードに、設計の美しさは宿る」ということ講演の全文は、別途書き起こし記事として公開しています。 [AI時代の仕事技芸論〜ソフトウェア開発で「遊ぶように働く」職人的熟達のすすめ](https://kuranuki.sonicgarden.jp/archives/36042) スライドはSpeakerDeckで公開しています。講演の動画もYouTubeで公開されています。 ## 海外カンファレンスのような雰囲気会場の雰囲気も、とても良いものでした。言語やフレームワーク、職種や出身国。そうした違いを超えて、誰もが歓迎される空気がありました。海外のカンファレンスに参加しているような感覚で、純粋に楽しい時間でした。実際、登壇者の多くは海外からのスピーカーでした。日本人の登壇者は少なく、その日本人も英語で講演する人が多い。日本語で話した私は、むしろ少数派だったかもしれません。それでも、Laravel本社のJosh Cirreさんが講演のあとに英語で熱のこもった感想を寄せてくれるなど、私の話が海外の人にも同じように届いている手応えがありました。 ## いいソフトウェアをつくる会場には、扇子に好きな文字を書き入れてくれるブースがありました。私がお願いしたのは、「いいソフトウェアをつくる」です。 ![](https://kuranuki.sonicgarden.jp/rails/active_storage/blobs/proxy/eyJfcmFpbHMiOnsiZGF0YSI6MTMwNCwicHVyIjoiYmxvYl9pZCJ9fQ==--faeaca3b5add63b707eb892125068900eabe9d38/2026-05-28-laravel-jp-fan.jpg) これは、ソニックガーデンが長く掲げてきた言葉でもあります。Laravelのイベントで、その思いを扇子に書いてもらいました。使う道具は違っても、つくりたいものは同じなのだと思います。招いてくれた濱崎さん、運営の皆さん、登壇者と参加者の皆さん、ありがとうございました。

WordPressがなくなる日〜エンジニアリング原則の適用範囲を引き直す

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

15年以上、自分のブログをWordPressで運用してきた。エディタの世代交代に合わせて使い方を変え、プラグインを整理し、テーマを差し替えながら、長くつきあってきた道具である。途中、Mediumやnoteへの移行を検討したこともあったし、ヘッドレスCMSで自前のフロントを作る構想を持ったこともある。けれど、どれも決定打がないまま、結局はWordPressを使い続けてきた。それだけよくできた道具だったということでもある。それが、AIに任せて自前のサイトへ移すという作業が、思いのほか工数も時間もかからずに終わってしまった。エンジニアでない人がアプリを作れる時代である。これ自体は、いまや驚くような話ではない。注目すべきは、別のところにある。何がなくなったのか、という問いだ。そもそもCMSは、何を解決していたのだろうか。書き手が技術者でないことを補い、書き手と作り手の分業を可能にし、テンプレートで工数を減らし、デザインと内容を分離し、DBで記事を管理する。どれも、書き手と作り手が分かれていた時代、人間が手で書くコストが高かった時代の、制約への解だった。 AIは、その前提を崩した。書き手が直接マークアップを生成できる。HTMLを書くコストは、ほぼゼロだ。一覧ページも検索も、必要なら都度生成すればいい。CMSが解決していた課題の多くは、別のかたちで解消されつつある。 DRY原則は、いまも変わらず大切なのだと思う。重複は保守性を下げる。AIが生成したコードであっても、ロジックがDRYでなければ、変更したときに破綻が起きる。これはプログラミングの原則として残り続けるのだろう。しかし、HTMLはマークアップにすぎない。プログラミング言語ではなく、ロジックを含まない。同じようなマークアップが繰り返されていても、本質的な保守上の問題は起きにくい。AIが都度書き直せるなら、なおさらだろう。 CMSがやっていた「テンプレート化による再利用」は、ロジックの共通化というより、マークアップの共通化だったのではないか。それは人間が手で書くコストへの対応であって、エンジニアリング的な必然というわけではなかったのかもしれない。そう考えると、CMSは特定の制約下での最適解だったのだろう。WordPressが長きにわたって書き手たちの道具であり続けたのも、その制約に対する優れた解だったからこそだ。前提が変われば、その役割も変わっていくはずだ。私たちはこれまで、ロジックを持たないものにまで、エンジニアリングの原則を引き伸ばして適用してきた。人間のコストが高すぎたから、適用しないと現実が回らなかったのだ。けれど、その前提が変われば、合理性の中身も変わる。これまでの適用には、誤適用だった部分があったのかもしれない。ロジックには、これまで通りDRYを守る。けれど、マークアップやコンテンツにまでこだわる必要は、もうないのかもしれない。AIに任せて、都度書き直せばよいことも増えていくはずだ。 AIの時代に、何にエンジニアリング原則を適用し、何には適用しないのか。その線引きを、引き直す時期に来ているのではないか。

マイナビ転職『アンドエンジニア』で取材を受けました：技術を磨いた先にあるキャリアの広げ方

2026-05-11T17:37:00+09:00

マイナビ転職のエンジニア向けメディア「アンドエンジニア」から取材を受け、私のキャリアについての記事を掲載していただきました。大手SIerに入った若い頃から、社内ベンチャーを経て独立し、「納品のない受託開発」というビジネスモデルにたどり着くまで。その道のりを丁寧に聞いていただいた取材です。記事は以下のような構成になっています。 - 技術を突き詰めたくて飛び込んだSIerの世界。そこで直面したキャリアと受託開発の課題 - 「キャリアの軸」は手を動かし、専門性を磨いた先に - ソフトウェア開発者らしい考え方がビジネスモデルを生み出した - ソフトウェア開発って面白い。それが仕事でできるのは魅力でしかない取材を通じて改めて言葉にしてみて、自分の中で整理がついたことがありました。 ## キャリアの軸は、探すのではなく現れるもの若手のエンジニアと話していると、「自分の軸を早く見つけたい」という相談を受けることがあります。軸は探して見つけるものではありません。目の前の仕事に一生懸命取り組み、専門性を磨いていった先に、運が良ければ後から現れてくる。それが軸の正体です。私自身、SIerに入った当初から「アジャイルを軸にしよう」と決めていたわけではありません。ソフトウェア開発をいいものにしたいという思いを突き詰めた結果、エクストリーム・プログラミングに出会い、それが後から自分の軸として立ち上がってきました。軸を探す前に、まず一生懸命に目の前の仕事をする。順番としてはそちらの方がいいと考えています。 ## ソフトウェア開発の全プロセスを経験するもうひとつ大事だと考えているのが、「ソフトウェア開発の全プロセスを経験してほしい」ということです。企画から要件定義、設計、実装、デリバリー、運用、フィードバックの反映まで。この一連の流れを自分の手で回した経験があるかどうかで、エンジニアとしての視座はまるで変わってきます。大規模システムの一機能だけを担当している限り、ソフトウェアの全体像は見えてきません。AIがコードを書くようになった時代だからこそ、コーディングそのものよりも「全体を描ける人」の価値が上がっていきます。小さくてもいいから、自分が最初から最後まで関わったソフトウェアを持っていること。それがこれからのエンジニアの強みになっていくはずです。 ## 抽象度を上げて考える「納品のない受託開発」というビジネスモデルを生み出せたのは、ソフトウェア開発者ならではの思考の型があったように思います。一括請負型の受託開発に違和感を覚えたとき、「契約書の文言をどう変えるか」というレベルで考えるのではなく、「お客様とずっと寄り添いながら開発するにはどうしたらいいか」と一段抽象度を上げて考える。すると「そもそも納品をなくせばいい」という別の解にたどり着きます。問題の抽象度を上げてから具体に降ろし直すという思考は、ソフトウェアエンジニアが日々やっていることそのものです。そしてこの思考の型は、エンジニアリングの現場だけでなく、ビジネスや経営の課題にもそのまま使えます。エンジニアの考え方は、それ自体がひとつの強い武器になります。 --- エンジニアとしての専門性をどう積み上げるか、AI時代の技術者の価値とは何か。自分のたどってきた道を改めて言葉にする、いい機会になりました。手を動かし、技術を磨いた先に専門性がある。『納品のない受託開発』を生んだ倉貫義人に学ぶキャリアの広げ方 https://tenshoku.mynavi.jp/engineer/guide/articles/t0033

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

2026-05-08T12:04:00+09:00

先日、DHH（David Heinemeier Hansson）が出演したインタビュー動画「DHH's new way of writing code」（聞き手: Gergely Orosz、約1時間47分）を見ました。あまりに響くものがあったので、本人に日本語で要約紹介する許可を求めてメールを書きました。返信はこう来ました。 > Thank you! Yes, feel free to do so. Much of that thinking is inspired by Japanese philosophy. From omakase to kintsugi 🤌 （あの思考の多くは日本の哲学に着想を得ている。おまかせから金継ぎまで）元動画はこちらです（YouTube）: [DHH's new way of writing code](https://www.youtube.com/watch?v=JiWgKRgdgpI) こうして本人の許可を得ましたので公式に紹介します。動画を見ながら、私が長年「仕事技芸論」として書き続けてきたことと、彼の語る "Taste and Judgment（審美眼と判断力）" の時代観が、見事に重なっていることに興奮を覚えています。 ## 「審美眼こそが真実である」 DHHが繰り返した言葉がありました。"Aesthetics is truth."（審美眼こそが真実である）。数学や物理学の世界では、ある式が「美しい」と感じられるとき、それは「正しい可能性が高い」とされてきました。コードもまったく同じだと彼は語ります。エレガントで、抽象が適切で、訓練された目に「美しく」映る設計は、結果として保守しやすく、壊れにくいことが多い。これまで私たちは「数値で測れるもの」を尊び、「センス」や「審美眼」を非科学的なものとして遠ざけてきました。けれどDHHに言わせれば、審美眼こそが品質を見抜くもっとも繊細な感知装置なのです。 ## 道具を仕立てる喜び技芸はまず道具から始まります。DHH自身、Ubuntuから出発してArch Linuxへ、さらにHyprlandへと作業環境を組み替え、最終的に「Omakub」という独自の構成を作り上げました。「なぜLinuxのデスクトップ環境にそこまで時間を費やすのか」とよく聞かれるそうです。彼の答えはこうです。道具は技芸の延長であり、自分が惚れ込めない環境では美しいものは作れない、と。 Rubyの世界には Convention over Configuration（設定より規約）という有名な原則があります。DHHはこれを「Omakase（おまかせ）の一つのかたちだ」と言いました。お任せ——信頼に基づいて選択を委ねる文化——が、Railsの設計思想の根底にあるのです。Rails自体が、おまかせの体現なのだ、と。 ## Railsのルネッサンス Ruby on Rails は今、AIによってかつてない注目を浴びています。理由のひとつが、トークン効率です。 LLMにコードを書かせるとき、フレームワークが「Hello World」のために500行のボイラープレートを要求するなら、それだけでLLMの文脈と知性を浪費してしまう。Railsは規約があるからこそ、本当に意味のある5行だけを書けば済む。エージェント時代に理想的に適している、というのが彼の評価でした。 LinuxもRubyも、もう30年以上のものです。けれどAIという新しいレンズを通して、彼はこれらを再発見していると言います。「Beginner's mind」——禅の言う『初心（Shoshin）』が戻ってきた感覚だ、と。"I'm liking computers more now than I did 5 years ago."（5年前より今のほうがコンピュータが好きだ）。 ## 「週末で作れる」という傲慢プログラマの役割は変わりつつあります。一行ずつレンガを積む人ではなく、設計者であり検査官になる。書くことから、「読んで検証する（Read and Verify）」ことへ。だからこそ、何が美しく何が正しいかを見抜く審美眼が、機能的な要件として必要になってくるのです。ここでDHHが引き合いに出したのが、有名なDropboxの逸話でした。Hacker Newsで「Dropboxくらいrsyncを使えば週末で作れる」と書いた人がいた、というあの話です。それは究極の傲慢（Hubris）だ、とDHHは言います。デモとプロダクトを取り違えている。コアの同期ロジックは1%にすぎず、残り99%は20年続けるための長寿（Longevity）、エッジケース、チームの才能、ビジネスモデルだ、と。技芸とは、最初の一行ではなく、システムが20年生き続けることだ——。Basecampを20年以上運営してきた人の言葉として、深く響くものがあります。 ## 8時間睡眠と「これはセールではない、ただの価格だ」長く続けるための土台は、極めて物理的なものから始まります。 "I am a big believer in getting eight hours of sleep."（私は8時間睡眠を強く信じている）。シリコンバレーの「徹夜してでもhustleせよ」という神話に、彼ははっきりと反対を示しました。理由は単純です。プログラマの新しい役割が「Taste and Judgment」であるなら、寝不足は酔って仕事に来るのと同じだから。霧のかかった脳では、コードのなかの真実は見えない。20年この仕事に居続けるには、脳を精密機器として扱うしかない、と。ビジネスの面でも、DHHの哲学は徹底しています。37signalsには「セールはやらない」というルールがあります。期間限定割引もブラックフライデーも、心理的な価格操作も、いっさい行わない。「これはセールではない、ただの価格だ（It's not a sale, it's just the price）」。15ドルの価値があるなら、今日も明日も15ドルで売る。「今買わないと値上がりする」と顧客を急かすのは、価値ではなく操作で売っていることになる。本物の職人は、自分の仕事を買わせるために人を騙す必要はない、と彼は言い切りました。 ## 監督者（Director）になるエージェントとの実践に話が移ったとき、DHHは社内のエンジニア、ジェレミーの逸話を紹介しました。ジェレミーはエージェント（Claude Codeとカスタムスクリプト）を使い、約90分で100件のプルリクエストを生成しレビューしたといいます。これまでなら「効果が小さすぎて手をつけない」とされてきた最適化を、一気に終わらせた。これは、人間がすべての文字をタイプしていたら不可能です。しかし「監督者（Director）」にとっては不可能ではない。ジェレミーは書いていたのではなく、意図を定め、制約を与え、出力を検証していた。最後の Taste and Judgment のフィルターになっていたのです。問われたのは、自分の名前で「マージするのを誇りに思える（Proud to merge）」品質かどうかを見極める目だけでした。 DHHはこの役割を映画監督に喩えました。映画監督はカメラを持たず、照明をセットアップせず、台詞を演じない。それでも「美意識とビジョン」のすべてに責任を負う。何が「良い」かを決め、何が「ゴミ」かを切り捨てる。エージェント時代のプログラマは、そういう存在になっていく、と。これはソフトウェア開発の経済性そのものを変えます。シニアエンジニアに2時間かけて0.1%の改善が得られる仕事は、これまでなら「割に合わない」と切り捨てられてきました。それがエージェントなら2秒、レビューが2分で済むなら、ありとあらゆる磨きが「割に合う」ようになる。つまり「行数」を価値の指標にする時代は終わりました。生産コストがゼロに近づくとき、価値を持つのは「設計と判断」だけになる、と彼は断言します。だからこそ、CSSだけ・DBだけといった専門に閉じない、スタック全体を見渡せる「ジェネラリスト職人（Generalist Craftsman）」の時代がふたたび戻ってくる、というのが彼の見立てです。 ## 人月の神話を超えて DHHのもう一つの重要な指摘が、人月（man-month）に関するものでした。長らく、機能を増やしたければ人を増やすしかありませんでした。けれど人が増えれば、コミュニケーションのコストも掛け算で膨らんでいく。フレデリック・ブルックスが半世紀前に『人月の神話』で示したのは、ソフトウェア開発はそもそもスケールしないという冷たい事実でした。私自身、この『人月の神話』の現代版として位置付けて書いたのが、2023年に上梓した『[人が増えても速くならない〜変化を抱擁せよ〜](https://amzn.to/4cWSTnM)』という本です。経営者やマネージャーに向けて、なぜソフトウェア開発は人を増やしても速くならないのか、なぜ少人数で小さく作るしかないのかを、平易な言葉で書きました。出版から数年経っても、その本質はむしろAIの時代にこそ立ち上がってきていると感じています。 DHHは、AIエージェントこそ初めてこの呪縛を解く技術だ、と断言します。チームを大きくするのではなく、一人がエージェントを束ねる。3人のチームが、かつて30人を要した仕事をやってのける。コミュニケーションのオーバーヘッドが消えた分、純粋な創造の時間が増えていく。これは、私がソニックガーデンで長年実践し、本にも書いてきたことと深く響きます。職人ひとりが、信頼で結ばれた小さなチームのなかで[自律的に動く](https://kuranuki.sonicgarden.jp/archives/35950)。大きくしないことを意図的に選びながら、お客様に大きな価値を届ける。その「規模ではなく、技芸で勝つ」という選択が、いまDHHの語りのなかで世界規模の議論として立ち上がっているのを感じます。 ## CLIとBinstubs〜エージェントのための設計エージェントが当たり前に動く前提に立つと、システムの作り方そのものが変わります。人間にとってのGUIは便利でも、エージェントにとっては「ノイズが多く非効率」だとDHHは言います。エージェントが望むのはボタンのクリックではなく、コマンドの実行だ。だからこそ、CLI（コマンドラインインターフェース）が大きく復権している、と。彼はこれを「ハンドルとペダル（Handle and Pedal）」と呼んでいました。ソフトウェアという強力なエンジンを、エージェントというドライバーが操るための、明確な操作器具を整備せよ、ということです。具体的には、Railsの `bin/` ディレクトリに置かれるBinstubs（小さなスクリプト群）の活用を強調していました。エージェントに環境構築から考えさせるのではなく、`bin/test_feature` のような専用スクリプトを叩かせる。Pass/Failのシグナルがはっきりしているから、エージェントは自律的にコードを書き、テストを走らせ、エラーを修正し、また走らせる——というループに入れる。ただし、これが機能するのは設計が清廉なときだけです。スパゲッティのコードでは、エージェントも人間と同じように迷子になる。AIは良い設計を不要にするのではなく、むしろよりよい設計を要求するのです。底のロジックが乱雑なら、エージェントは「より速い乱雑さ（faster mess）」を生むだけだ、と彼は釘を刺しました。「壮麗なるモノリス（Majestic Monolith）」が今あらためて強いのも、ここに理由があります。50個のマイクロサービスより、ひとつのモノリスのほうが、エージェントが全体の文脈を保持しやすいのです。 ## Peak Software Engineer の終焉そして核心となる主張が語られました。"Peak Software Engineer."（ソフトウェアエンジニアの頂点）。過去20〜30年、ソフトウェアエンジニアは世界経済のボトルネックでした。何かを作るには、必ずプログラマを通さねばならなかった。それが高給と、強い影響力と、ある種の「司祭階級」のような立場をもたらしてきた。そのピークは過ぎつつある、というのがDHHの見立てです。AIがコーディングという「労働」をほぼゼロコストで生産できるなら、その希少性は薄れていく。世界は「生産の希少」から「生産の豊穣」へと動いている、と。ではコーディングが豊穣になるとき、何が希少になるのか。彼の答えは明快でした。**Taste and Judgment.** それだけだ、と。千行のコードを誰でも一秒で生成できる時代に、価値を持つのは「どの千行を残すべきか、どう形作るべきか」を判断できる人間だけになる。豊穣な時代に量産品の感触のソフトウェアは、無数に存在し、無価値になる。意味を持つのは、審美眼を備えた人間が下した、特定で独自の選択を宿した、魂のあるプロダクトだけだ——。それは「個人のルネッサンス（Renaissance of the Individual）」の幕開けでもあります。本格的なSaaSを作るのにかつては50人のチームが必要でした。今は、審美眼を備えた一人とエージェントの艦隊で、中堅企業に伍して戦える。ソロプレナーや少数精鋭の工房にとって、史上もっとも好ましい時代だ、とDHHは言い切りました。 ## 金継ぎ（Kintsugi）の儀式 DHHは自身の新しい仕事の儀式について語りました。エージェントはコードを90%、95%まで持っていってくれる。けれど最後の5%、「縁」「感触」「魂」のような部分は、いつもどこか合わない。彼はそこに「ほんの少しの助け（a little bit of help）」を加える。割れ目を継ぎ、輪郭を整える。それは日本の「金継ぎ」と同じだ、と彼は言いました。機械が始めた仕事を隠すのではなく、人間の判断と機械の出力を継ぎ合わせて、どちらか単独では作れない、より強く美しいものを作る。この「継ぐ」という行為こそが、新しい高次の職人技だ、と。朝起きてXやニュースを開くのをやめ、コーヒーとエージェントの前に座って「作る」ことから一日を始める。それが彼の新しい儀式（New Ritual）。"It is a flourishing experience."（それは開花の体験だ）。道具と戦うのではなく、道具と踊る感覚を、Rubyを発見した2003年以来感じていなかったFlowを、いま彼はあらためて取り戻している、と。 [エージェントに「降伏」してから](https://kuranuki.sonicgarden.jp/archives/36023)、私もまた近い感覚のなかにいます。 ## 「The Arts and Crafts of Work」という符合私はかねてより「仕事技芸論」を提唱してきました。仕事を「労働」ではなく「技芸」として捉え、技芸として向き合う文化を広げていく考え方です。その英訳として、私は "The Arts and Crafts of Work" という言葉を使ってきました。19世紀末にウィリアム・モリスたちが起こしたアーツ・アンド・クラフツ運動への敬意を込めた表現です。 DHHが繰り返し同じ "The Arts and Crafts of Work" を口にするのを聞いたとき、私は驚き、そして奇妙な喜びをおぼえました。仕事技芸論は、ソニックガーデンで職人たちと長年働き、彼らの仕事に立ち会うなかで、私自身の言葉として組み上げてきた考え方です。同じ時代の地平を見上げていた二人が、それぞれの場所で同じ言葉に行き着いた——そう受け止めています。ウィリアム・モリスから連なる「ものを作る人の倫理」が、海と時代を越えて、いまふたたびソフトウェアの現場で立ち上がっているのです。 ## プログラマは創造者として神格化される最後にDHHは静かに締めくくりました。これは「プログラミングの終わり」ではなく、「創造者としてのプログラマの神格化（the apotheosis of the programmer as a creator）」だ、と。ボトルネックを守る古いやり方にしがみつくのではなく、[ものを作る喜び](https://kuranuki.sonicgarden.jp/archives/36028)を再発見せよ。技芸を本当に愛しているなら、生きていて最も輝かしい時代だ、と。そこで問われるのは、コードを大量に速く書ける人ではなく、何が美しく何が正しいかを見抜ける人。製品を20年生き続けさせられる人。誠実な価格で売り続けられる人。AIエージェントの時代は、技芸を磨いてきた職人にとって、ようやく自分たちの土俵が広がる時代なのです。おまかせから金継ぎまで——DHHの返信を思い返すたびに、確信は深くなります。すでに私たちは、その土壌に立っています。怖れる必要はなく、開花として迎えればいいのです。 ## 動画は、ぜひ全部観てほしい動画そのものに勝るものはありません。1時間47分。短くはありません。けれど、彼の声色、間、笑い、迷いがあって初めて立ち上がる温度があります。要約ではどうしても削ぎ落とされる部分です。英語のリスニングがつらければ、いまは便利な道具があります。たとえばGeminiにYouTubeのURLを渡せば、文字起こしを取り出してくれます。そのうえで「日本語に訳して」と頼めばいい。完璧ではないとしても、十分な精度の日本語が手に入ります。 --- 元動画：[DHH's new way of writing code](https://www.youtube.com/watch?v=JiWgKRgdgpI)（聞き手: Gergely Orosz／英語、約1時間47分）

「ありたい姿」のまま、続けていく〜コミュニティと株式会社のあいだ

2026-05-07T19:17:00+09:00

株式会社という仕組みは、起業するときに何気なく選ぶ「器」のひとつに見えるかもしれません。けれど、15年かけて経営をしてみると、その器の見え方は大きく変わってきました。ソニックガーデンを立ち上げるとき、株式会社か合同会社か、どちらの形にするかで少しだけ迷ったことを覚えています。社内ベンチャーから引き継いだ企業向けSNSの事業をしていて、法人営業の場面では株式会社のほうが説明しやすい。その程度の理由で、株式会社を選びました。選んだ「株式会社」という仕組みについて、深く考えていたわけではありません。それから15年、ソニックガーデンの組織は何度も形を変えてきました。同時に、私の会社観も、その都度アップデートされてきました。安易に選んだはずの「株式会社」という仕組みが、いまの私には、コミュニティを社会と接続するためのプロトコルとして見えるようになっています。これは、15年かけて辿り着いた発見です。 ## 「ありたい姿」は、最初から手に入っていた私はもともと、大きな上場企業で働いていました。大企業ならではの良さも知っていましたが、同時に、仕方がないとはいえ良いとは思えないところも知っていました。だから、上場企業や大企業への憧れはまったくありませんでした。むしろ、学生時代に働いていたベンチャーの雰囲気や、大学院の研究室のような自由な空気が好きでした。そんな私が会社を立ち上げたので、規模を大きくすることや、それに伴う売上の拡大、社員の増大には、たいしたモチベーションがありませんでした。一緒に起業した仲間たちと楽しく仕事を続けていきたい、というくらいの「志の低い」起業だったと言えます。だから、創業当初に掲げたビジョンは「プログラマを一生の仕事にする」という、内向きのものでした。幸い、売上が立って軌道に乗り始めた社内ベンチャーを買い取る形で起業したこともあって、2011年の創業初年度から黒字でした。社内ベンチャー時代は苦労しましたが、会社になってからは、自分たちの報酬額を自分たちで決められます。会社員のころから少しは下げたものの、慎ましく暮らせば十分に利益も残せました。経営の素人ばかりだったので、当然それなりに苦労もしました。それでも、大企業のしがらみや周囲のやっかみがなく、ひたすら前向きに頑張ることはできました。報酬は大きくはありませんでしたが、それだけで十分に幸せだったのかもしれません。つまり、起業した時点で、すでに満足できる状態だったとも言えます。なりたい姿があって、そこに向かってギャップを埋めていく、というタイプの起業ではありませんでした。「ありたい姿」はあったのですが、それは創業時から手に入っていたのです。今から振り返ると、これはアジャイル的な経営スタイルだったのだと思います。多くのスタートアップは、為したいことや上場などのゴールを設定して、そこへ向けてギャップを埋めるように頑張ります。しかし私たちは、起業したときから今ある状態をベストと捉え、そこから一つひとつ積み上げてきました。時には方向を変え、積み上げてきたからこそ新しい挑戦もできた。どうなるか予想できなかったからこそ、予想もつかない今に辿り着いたのだと思います。 ## ビジョンと「納品のない受託開発」創業時、私たちは5人でした。最初のビジョン「プログラマを一生の仕事にする」は、どうやって決めたのでしょうか。社内ベンチャーの頃は、ビジョンなど考えたことがありませんでした。新規事業を立ち上げるのに必死だったからです。大企業の屋根を外れて、自分たちの会社になったとき、なにか拠り所が必要だと感じました。たまたま読んだ『ビジョナリー・カンパニー2』にあった、同じバスに乗る人たちの顔ぶれを見て行き先を決める、という考え方を信じることにしました。私たちは全員がプログラマでした。私自身の原点を思い返して、このビジョンに決めました。同時に、社内ベンチャーで続けていた企業向けSNS事業だけでは、このビジョンは実現しないと考えました。私たちが本当にやっていきたいのはソフトウェア開発でした。だから、改めて受託開発の世界に戻ることにしました。とはいえ、従来の受託開発には多くの問題があります。だから、ビジネスモデルから変えることに挑戦しました。それで生み出されたのが「納品のない受託開発」というサービスです。 ## 採用に時間をかけるという発見受託開発である限り、お客さまが増えるほどプログラマも必要になります。しかも「納品のない受託開発」は顧問型で、契約が継続するので、たくさんのお客さまには対応できません。そのため、新しい人を採用しようということになりました。ここで、苦い失敗がありました。人材紹介の会社経由で、フリーランスの方に入ってもらったのです。凄い経歴のベテランの方、という触れ込みでした。しかし、いざ一緒に働き始めると、私たちのカルチャーとはまったく合いませんでした。プログラミングは多少できましたが、レビューをしてくれない、こちらのレビューを受け入れてくれない。その経験を境に、人材紹介経由のフリーランス採用はやめました。代わりに取り組んだのは、自分たちの考え方を発信することでした。コーポレートサイトを作り込み、自分たちの理想や開発手法について書きました。創業当初だったので、私が一言一句すべて書きました。同時に、私のブログ「Social Change!」で考えをしっかりと伝え始めました。そのブログは、15年たった今も続いています。そうしていると、ぽつりぽつりと応募がくるようになりました。私たちはカルチャーこそが重要だと考えて、フィットするかどうかを見極めるために時間をかけるようになりました。転職の相談を受けてから、半年以上の期間をかけて決断する。その時間をかけるスタイルは、今も続いています。当時はまだ自分たち創業メンバーを入れても一桁の人数だったので、報酬の差はもちろん、役割や権限も含めて役員と社員の違いはほとんどありませんでした。一緒に会社のことを考え、一緒に働いていました。これも今に続くカルチャーです。リモートワークも、この頃から始まりました。カルチャーを守り、「ありたい姿」でい続けることを優先していた私たちにとって、採用は事業拡大の手段ではありませんでした。目の前で困っているお客さまを助けるために必要な仲間であり、仕事という楽しみを一緒に過ごせる友人でもある、そんな人を増やす手段です。だから「人ありきで案件を準備する。案件のための採用はしない」という[ピープルファーストの姿勢](https://kuranuki.sonicgarden.jp/archives/35997)を貫いてきました。 ## 「ギルド」という挑戦の断念それでも、採用を慎重にしていると、増えていくお客さまにすべて応えきれません。お待ちいただくか、お断りするしかない場面に経営者である私は苦慮していました。とはいえ、採用のハードルを下げることはしたくなかった。そこで取り組んだのが「ギルド」でした。フランチャイズに近い形で、「納品のない受託開発」を他社にもできるようにし、お客さまを紹介していくモデルです。ソニックガーデン自体を大きくする必要はない、お客さまを救えればいい、という発想でした。しかし、これは失敗しました。理由は、開発手法の難易度と、それを実現するための教育コストの高さです。「納品のない受託開発」で提供しているのは、一人で顧客との対話から実装、運用までを一気通貫でこなす幅広さと、ヒアリング能力や保守性の高いコードといった高度な技術です。即戦力のベテランでさえ、入社前から準備し、入社後も1年以上かけて、ようやく独り立ちできるのが現実でした。ギルドに加入したからといって、すぐにできるものではありませんでした。教育するとなれば、相当な期間と労力が必要になります。加入したい側にとっても、私たちにとっても、手っ取り早い手段ではありませんでした。それなら結局、社員として採用しているのと変わらない。事実、ギルドとしてフリーランスで契約していた人のなかから、社員として加わってくれた人たちもいます。そうしたこともあって、ギルドという形は諦めました。 ## オフィスを手放してわかったこと 20名ほどの組織になっていく頃、地方在住で在宅勤務をする社員が増えてきました。その流れもあって、2016年にはオフィスを撤廃しました。物理オフィスを持たない会社、全社員リモートワークを始めたのもこの頃です。バーチャルオフィスを使った仮想出勤というスタイルでした。上司・部下の関係を持たない[ホラクラシー的な組織](https://kuranuki.sonicgarden.jp/archives/35956)として、注目もされました。オフィスをなくしてみて、改めて「会社とは何か」を考えるようになりました。会社とは、ビルやオフィスのことではない。学校と校舎の違いと同じで、オフィスは器にすぎません。理念とビジネスモデルがあって、そこに集まる人たちがいれば、会社と呼べる。そう気づいたのは、オフィスを手放してからのことでした。しかし、器を持たないからこそ、内側を支える仕組みがなお重要になります。30名近くになるまで、社員の自主性のみに頼った経営を続けてきましたが、それだけでは会社としての運営に綻びが生まれてしまう。その大きな出来事が、2017年に起こしたセキュリティ事故でした。結果として未遂で終わりましたが、改めて会社としての経営をしっかり整え直す機会となりました。自由でフラットなカルチャーは維持しつつ、抜け漏れなくお客さまに安心していただくこと、社員も働く上で安心できること。リモートワークやホラクラシー的な仕組みの土台には、しっかりしたセルフマネジメントと会社経営が必要なのです。ビジョンの共有だけでなく、ガバナンスにも力を入れるようになりました。 ## 「株式会社」というOSの自由度そこから、労務や財務、さまざまな面での法令遵守はもちろん、セキュリティ診断や個人情報保護の認証取得など、外部審査も活用しながら、内部統制のとれた会社にしてきました。その過程で考えたのは、株式会社という仕組みが、資本主義に則った形ではあるけれど、その「OS」の上では相当に自由度が大きいということでした。守るべきものはありますが、社内の制度や倫理については、経営者にかなり任されています。しかも、株主と経営者が一体となっていれば、なおのことです。資本を創業者かつ経営者である私が握っている、ということの重要性に、ここで初めて気づきました。楽しい仲間たちと、素晴らしいお客さまと、「遊ぶように働く」状態で長く続けていける。それが望む理想だとしたら、その「ありたい姿」は既に手に入っています。あとは、それを続けていけるかどうかです。 ## 若い世代を迎え入れるそうした思いがあって、創業10年を機に、若い人たちを[徒弟制度](https://kuranuki.sonicgarden.jp/archives/35992)で迎え入れることにしました。若い人たちにソニックガーデンのカルチャーや理念を継いでいってほしい。それに、若い人がいるだけで会社には活気が溢れます。ベテラン社員にとっては、後進を育てるという新しい挑戦の場にもなる。今は60名ほどの会社になりました。この先も大きくなるかどうかは、わかりません。以前「のれん分け」のような仕組みも考えたことがありましたが、会社という仕組みの柔軟さと、それを新しく作ることの大変さを比べると、何も再発明する必要はないのではないか、と考えるようになりました。子会社のような形はあり得るかもしれない、とは思っていますが、それも今は決めていません。改めて思うのは、会社の規模は社長が決めるものではない、ということです。創業当時、私は少数精鋭で大きくしたくないとさえ思っていました。一方で、大きくしたいと思っても大きくできない会社もあるでしょう。会社の規模は、社会が決めるものなのではないでしょうか。社会に求められれば、自然と大きくなっていくのだと思います。 ## コミュニティと株式会社のあいだソニックガーデンは、同じビジョンに向かって進む仲間たちのコミュニティとしての組織でありつつ、資本市場でビジネスを成立させ、経済を循環させていく株式会社でもあります。私にとって、どちらかではいけませんでした。両方を成立させることが大事だったと、今なら思えます。理想を掲げているだけで、現実社会に影響を及ぼせないようでは、希望がありません。一方で、めちゃくちゃ稼ぐことができても、それが「ありたい姿」とかけ離れていては、幸せとは言えない。両方が大事なのです。株式会社という仕組みは、コミュニティである私たちが、社会と接続するために必要なプロトコルでした。コミュニティであり続けられるように、会社の仕組みを整えていくこと。それが経営の一つの仕事です。逆に、コミュニティを守ることができるなら、その仕組みは、いかようにでも変えていけるでしょう。創業時には考えもしませんでしたが、上場やバイアウトといった選択肢も、まったく排除はしていません。ただし、それは経済的な出口戦略としてではなく、ここまで作ってきた会社のあり方を引き継いでいくための手段として、です。コミュニティを守れる選択であれば、形は問いません。こうした新しい会社の形が、これから「ありたい姿」で起業しようとする人たちにとっての一つの希望になっていくと嬉しい。

AIを組織で使うということ〜全社標準としてのClaude Code

2026-05-01T00:02:00+09:00

生成AIが業務に入ってきてから、社内でAIを使う人が増えました。便利だ、生産性が上がる、そんな声を耳にすることも多いはずです。けれど、多くの企業の実態を見ると、AIの活用は個人レベルにとどまっているケースが少なくありません。興味のある人が思い思いにツールを試し、部署ごとに別々のサービスを契約し、誰がどう使っているかは曖昧なまま。「AIを導入した」と言いつつ、組織として何かが変わったかと問われると、答えに詰まってしまう。これは言ってみれば「壮大な部分最適化」です。一人ひとりは速くなっているのに、組織として何が変わったのかは、見えてこないのです。 ## 個人の効率化と組織の変革は違う個人がAIを使って速く仕事ができるようになる、それ自体は良いことです。ただ、それは個人の中で完結する効率化にすぎず、一人ひとりが速くなるだけでは、組織そのもののかたちは変わりません。組織として何かを変えるためには、別の動き方が必要になります。誰かが見つけた知見が、別の誰かに伝わる。誰かが踏んだ落とし穴を、別の誰かが踏まずに済む。一人ひとりの試行錯誤が、組織全体のナレッジとして蓄積されていく。そういう循環が回って初めて、組織としての練度が上がっていきます。そのためには、全員が同じ道具を使うことが大前提になります。バラバラの道具では知見も分断されてしまい、「使いたい人が使えばいい」のままでは、組織には何も残りません。道具を揃えるとは、そこに組織として向き合うという意思表示でもあるのです。 ## 本当の変化はワークフローから組織が本当に変わるのは、ワークフローが変わるときです。個人の作業が速くなっても、ワークフロー全体が以前のままなら、ボトルネックは別の場所に移るだけで、全体の流れは変わりません。仕事の受け渡しの順番、誰がいつ何を判断するか、どこに承認が入るか——そういった一連のかたちが変わって初めて、組織の動き方が変わります。そして、ワークフローは個人では変えられません。自分の作業範囲だけを最適化しても、関わる人たちが同じ前提を共有していなければ、新しい流れは成り立たない。だからこそ、全社で揃えて取り組む必要があるのです。その先には、ビジネスモデルそのものを問い直す段階も控えています。AIエージェントが当たり前に動く前提でビジネスを設計し直せば、仕事のかたちや収益構造そのものが変わっていく。すぐに答えの出る話ではありませんが、そこまで見据えて備えていく必要があります。 ## エージェントが現れて、開発のかたちが変わる特にソフトウェア開発の世界では、AIによって仕事のかたちそのものが変わりつつあります。注目すべきは、AIエージェントの登場です。チャット型やコード補完型と違い、エージェント型のAIは、目的を伝えると自律的に手を動かします。履歴を残しながら、対話を重ねて成果物を少しずつ直していけます。人間がエディタの前に座り、自分の手でコードを書く——という従来の開発の前提が、ここで変わります。人間はエージェントに何を作ってほしいかを伝え、エージェントが書いたものをレビューし、方向性を調整する。コードを書く主体が、人間からエージェントに移っていきます。これは効率化の話ではありません。プログラマの仕事のかたちが変わる、パラダイムの移行です。 ## なぜ全社標準にこだわるのかソニックガーデンは、これまで会社として使う技術を「全社標準」として定めてきました。Ruby on Rails、Amazon Web Services、GitHub。プログラマが各自で好きな道具を選ぶのではなく、全員が同じ技術を使うことに意味があると考えてきたからです。この考え方の根っこには、私が前職でSIerに勤めていた頃の経験があります。一般的な受託開発の現場では、プロジェクトごとに技術選定をし、アーキテクチャから考え直すのが当たり前でした。エンジニアにとっては新しい技術を試せる機会でもあるのですが、それでは案件を終えるたびに知見が散らばってしまい、組織として何も積み上がっていきません。こなれていない技術でお客さまの案件に取り組むことが、プロフェッショナルとしてどうなのか、という疑問もずっと感じていました。だからソニックガーデンでは、社内で技術を統一し、ミドルウェアを整備し、ナレッジを蓄積していく形をとってきました。お客さまの案件で最高のパフォーマンスを出せるのは、この前提があってこそです。たとえばRailsを全社で揃えているからこそ、書き方のコツやハマりどころを回避するノウハウを、プログラマ同士で同じ言葉のまま共有できます。誰かが見つけた工夫が、別のメンバーの学びになる。一人ひとりの経験が、そうやって組織のナレッジとして積み重なっていくのです。技術選定が分かれていれば、こうはなりません。 ## Claude Codeを全社標準に加えた 2026年3月、その全社標準にClaude Codeを加えました。ある日突然「これにします」と決めたわけではありません。それまでも社内ではAIエージェントの活用が進んでいて、メンバーそれぞれが自分なりにベストだと思うツールを試していました。誰かに強制されるわけでもなく、現場で試行錯誤しながら、自分のスタイルを作っていた段階がしばらく続きました。そうしているうちに、自然と使い手が増え、評価も定まってきたのがClaude Codeでした。実態としてデファクトスタンダードになっていたものを、会社として正式に位置づけ直したかたちです。 Claude Codeを多くのメンバーが選んだのは、現時点でモデルの賢さと、新しい考え方や実装が出てくるスピードが、他のエージェントよりも優れていたからです。成果物を作っていくという目的に対して、最も適しているという感触が、現場の中で共有されていきました。ただし、半年後の勢力図は誰にもわかりません。AIの進化は速く、今ベストとされるものが、半年後にも同じ位置にいる保証はどこにもない。それでも全社標準を決めるのは、現時点のベストに全員でコミットするためです。より良いものが出てきたら、そのときも全員で乗り換える。バラバラに乗り換えるのではなく、組織として乗り換える。全社標準とは、そういう意思決定の仕方です。この取り組みは、エンジニアだけにとどまりません。コーポレート部門も含め、ソニックガーデンでは社員全員がClaude Codeを使い、エージェント型の働き方に移行していこうとしています。プログラマではない仕事も、エージェントとの協働で大きく変わるはずだと考えているからです。これについては、また別の記事で詳しく書きたいと思います。 ## 現場の記録を、当事者の言葉でソニックガーデンのプログラマたちにとって、AIエージェントとの協働はすでに日常です。コードを書くパートナーとして、Claude Codeが常に隣にいる。何ができて、何が難しいのか。どう指示を出せばよいのか。どこに気をつけるべきか。日々の現場で、新しい知見が生まれ続けています。それは、プログラマ自身の言葉で語られるべきものです。経営者の私が概念で語るよりも、毎日コードを書いている当事者の体験として語る方が、ずっとリアリティがあります。そこで、ソニックガーデンのプログラマたちが、Claude Codeにまつわる記事を1ヶ月間毎日書いていくことにしました。テーマは自由。ノウハウでもいい、トラブルの記録でもいい、新しい使い方の発見でも、エージェントと働くことについての所感でもいい。各自がZennやQiitaなどの個人アカウントで投稿していきます。 1ヶ月の短期集中連載として、5月1日から始まります。記事の一覧は以下のページから辿れます。まとめページ: https://www.sonicgarden.jp/tech/claudecode ハッシュタグ: [#claude\_on\_sonicgarden](https://x.com/hashtag/claude\_on\_sonicgarden)

Findyさんに取材を受けました：徒弟制度と高卒採用、AI時代の若手育成

2026-04-25T18:19:00+09:00

エンジニア向けサービスのFindyさんから取材を受け、ソニックガーデンの若手育成についての記事を掲載していただきました。 AIがコードを書く時代に、ソフトウェアの会社がどうやって若手を育てるのか。10年続けてきた中途採用のみのスタンスから若手採用へと舵を切り、徒弟制度を導入し、2026年4月には高卒採用にも踏み出した経緯と、いまの現在地について話してきました。記事は以下のような構成になっています。 - ソニックガーデンが自分たちで若手育成を始めるまで - 「マネージャーとメンバー」から「親方と弟子」へ - AIがコードを書く時代でも、教え方は変わらなかった - 先のことはわからない。だから目の前のことをやる答えが見えない時代に、いまできる最善のことをやる。そんな姿勢を、丁寧にまとめていただきました。関心のある方は、ぜひ読んでみてください。ソニックガーデンが若手を育て始めて見えてきたもの。徒弟制度、高卒採用──正解のないAI時代のひとつの実践 https://findy-code.io/media/articles/special-interview-sonicgarden_inc

「動けばいい」では、もったいない〜AI時代にプログラミングを学ぶ意味

2026-04-22T14:01:00+09:00

AIがコードを書く時代になりました。プロンプトを投げれば、動くプログラムはすぐに手に入ります。検索して見つけたサンプルを、理解しないまま繋ぎ合わせる必要もありません。こうした時代に、これからプログラミングを学ぼうとする学生にとって、学ぶ意味はどこにあるのでしょうか。実のところ、社会人として現場にいる私たち自身も、同じ問いに向き合っています。AIに任せる範囲が広がるほど、人が手を動かすことの意味を、自分の言葉で語りにくくなっていく。それでも、一つだけ確信していることがあります。学生のうちに体験しておいてほしいことがある、ということです。 ## 仕事ではAIを、学びでは自分の手を念のため書いておくと、仕事でAIを活用することを、私たち自身は積極的に推奨しています。私もAIエージェントと一緒に日々働いているし、社内でもAI活用はすっかり当たり前になりました。成果を出すのが仕事である以上、わざわざ遅いほうを選ぶ理由はありません。ただ、学びの話になると、少し事情が変わります。動くだけのコードを手にするのが目的なら、AIに任せた方が速い。これは否定しようがない事実です。けれど、AIに任せて動くものができたとして、その体験から作り手に何が残るでしょうか。動いたという結果はあるかもしれない。課題は提出できるかもしれない。けれど、作り手自身の中に、何か確かなものが残っているかは別の話です。「動けばいい」で済ませてしまうと、作ることの面白さに触れないまま終わってしまいます。仕事ならそれでも成果が出るならいい。けれど、学びや面白さの芯を育てたい場面では、あえてAIに任せないほうが得られるものが大きい。そう考えています。 ## 作って面白い、が出発点プログラミングの学び方について、よく「どの言語から始めるか」「どの教材を使うか」と議論されます。どれも大事な問いではあります。けれど、もっと大事なことがあると思っています。それは「作って面白い」という体験を、自分の中にしっかりと根づかせることです。自分の頭で考えて、自分の手で形にして、動かしてみる。想像通りに動くこともあれば、全然動かないこともある。動かないから、調べて、直して、また動かす。動いたときには嬉しい。誰かに見せて、喜ばれたらもっと嬉しい。私自身、[学生から若手の頃にかけて、プログラミングに没頭した時間](https://kuranuki.sonicgarden.jp/archives/35193)がありました。仲間と作っては動かし、議論しては直す。誰に指示されたわけでもないのに、寝食を忘れて続けていました。あの時間があったからこそ、その後ずっとソフトウェアの仕事を続けてこられた、と振り返って思います。逆に言えば、あの体験がなければ、今の自分はいません。この一連の体験が、プログラミングの面白さの芯です。技術の習得や知識の積み上げは、この芯があってこそ続けられる。逆に芯がないまま学ぼうとすると、どこかで続かなくなります。面白さは才能ではなく、体験することで発火するものです。 AIの時代になっても、この面白さは失われません。むしろ、AIに任せられる部分が増えたからこそ、「何を作るか」「なぜ作るか」を考える時間が増え、自分の作品だと感じられる余地は広がっているとも言えます。つくりたいものがあって、それをつくる。そこに没頭できる時間を持てること。それがプログラミングを学ぶ一番の意味だと、私は思っています。 ## 面白さの芯を持つ人は、強い AIによって効率化が進むほど、面白さの芯を持っている人と持っていない人の差は、これから大きく開いていくのではないか、と感じています。芯がある人は、AIを道具として使いこなします。何を作りたいのか、どこを面白くしたいのか、自分の中に基準があるからです。AIにどんな指示を出すかも、出てきた結果をどう判断するかも、自分の芯から決められる。AIが速くなるほど、自分の芯から生み出せる仕事の量と質が増えていく。芯がない人は、AIに使われていきます。とりあえず動けばいい、それらしくできていればいい。判断の軸を外側に預けてしまうから、AIの出力に引きずられる。仕事の手応えは薄くなり、続けるほどに自分の輪郭がぼやけていく。これは学生だけの話ではありません。社会人としてキャリアを重ねた人にも、同じことが起きています。私自身、自分の芯が揺らいでいないか、ときどき問い直すことがあります。芯は、知識として教わるものではありません。自分で何かを作り、夢中になり、動かしてみる。そのプロセスの中でしか育たない。だから、芯を持てる体験をどこかで一度持っておくことが、これからの時代を生きる上で、ますます大事になっていくのだと思います。 ## 一人では、没頭できないただ、その芯は一人で育てるには限界があります。一人でつくっているだけでは、どこかで物足りなくなる瞬間が来るのです。仲間と一緒に、一つのものをつくってみる。同じ画面を見て、意見を出し合い、ぶつかり、落としどころを見つけ、また動かす。一人では絶対にたどり着けなかったアイデアが、会話の中から出てくる。一人では詰まっていた問題が、誰かの一言でほどける。こういう体験は、独学ではなかなか得られません。大学の授業やサークルで、グループ開発をした経験がある方もいるかもしれません。けれど、平日の昼間に朝から夕方まで、同じチームで一つのソフトウェアに没頭する、というような時間は、なかなか取れないはずです。バイトや授業の合間に少しずつ、というのでは、没頭には至りにくい。もちろん、社会人になっても、仲間と打ち込む時間はあります。けれど、納期や数字に追われながらの時間と、ただ夢中になってつくる時間とは、同じようでいて質が違います。多くの現場では、責任や効率が優先されるうちに、没頭の感覚が少しずつ遠ざかっていきます。もっとも、それはすべての会社の話ではありません。私たちソニックガーデン自身、納期に追われる開発ではなくお客さまと一緒にソフトウェアを育て続ける形を選び、大人になっても夢中で働ける環境を意図してつくってきました。仕事は本来、夢中になれるものだ、という確信があったからです。没頭は、時間と集中の密度があって初めて生まれるものです。仲間と過ごす濃い時間の中で、ソフトウェアが少しずつ形になっていく。手が動き、会話が生まれ、何かが動いたときに一緒に喜ぶ。この経験は、社会人になってもそう何度も味わえるものではなく、とても得難いものだと思います。一度でもこの濃さの時間を過ごしておくと、ソフトウェアづくりへの構えが変わります。 ## プロのやり方を、そばで見る面白さを味わい、仲間と没頭する時間を経たその先に、もう一つ見えてくるものがあります。「プロはどう仕事をしているのか」という世界です。プロが書くコード、プロが使うツール、プロが交わす会話。そのどれもが、教科書には書かれていないやり方でできています。なぜその実装を選んだのか。なぜそのタイミングでお客さまと話したのか。なぜそこで立ち止まって考え直したのか。こうした判断の一つひとつは、言葉にして教えるのが難しいものです。だからプロの仕事は、そばで見るのが一番早い。同じ机で、同じ画面を見て、同じ問いを一緒に考える。それが、本を読んで学ぶのとは違う、プロのさわりに触れる方法です。私たちの会社でも、この「そばで見る」ことを大切にしてきました。若手は最初、先輩のそばで、その仕事の進め方を写し取るところから始めます。コードだけではなく、考え方の癖、判断のタイミング、お客さまへの言葉の選び方まで含めて、丸ごと見る。それが一番早い、と感じているからです。ただ、学生のうちから、こだわりを持って仕事をしているプロのそばに身を置ける機会は、そう多くはありません。インターン、アルバイト、研究室の先輩、知人の紹介で入った現場。形はどうあれ、そういう機会に出会ったら、意識して掴んでおくといい。一度でもプロの世界に触れておくと、そこから先の進み方が変わってきます。 ## 若いうちに、こだわりを持って没頭する今の学生は、AIをはじめ、便利な道具をたくさん手にしています。そのこと自体はとても恵まれている。けれど、便利さの中だけで完結してしまうと、面白さの芯が立ち上がる前に、すべてが手早く片付いてしまうかもしれない。それは少しもったいないことに思えるのです。面白さに発火する。仲間と没頭する。こだわりの手触りに触れる。この三つを、できれば若いうちに、まとまった時間の中で経験してほしい。大人になってからの働き方は、そこで一度掴んだ感覚をもとに、自分で選び取っていけばいい。夢中になれる仕事を選ぶこともできるし、自分で環境をつくることもできる。けれど、一度もその感覚に触れないまま社会に出てしまうと、選ぶときの物差しが持てない。だから若いうちに一度、というのが、社会人として現場を見てきた私の実感です。 --- 付け加えておくと、今年の夏、私たちソニックガーデンでも学生向けのキャンプを開催します。夏のあいだ、チームで一つのソフトウェアに取り組む場です。キャッチコピーは「あなたのこだわりが、いいソフトウェアをつくる。」これを読んで、そういう夏を過ごしてみたい、と感じた学生がいたら、一つの選択肢として見てもらえたら嬉しく思います。ソニックガーデンキャンプ 2026 https://www.sonicgarden.jp/join_us/camp/2026