Social Change!

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

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

弟子の仕事は「見る」こと〜AI時代の「見て盗む」2.0

2026-04-20T18:09:00+09:00

以前のブログで、育成に必要なのは[観察と自己決定だ](https://kuranuki.sonicgarden.jp/archives/34902)と書いた。親方が弟子のプロセスを見て、課題とフィードバックを渡すという話だった。しかし「見る」が大事なのは、弟子にとっても同じだ。ただし向きが逆だ。親方が見るのは弟子のプロセス、弟子が見るのは親方のプロセスだ。教えるとき、「説明→実践→フィードバック」で進めがちだ。一見まっとうだが、落とし穴がある。「お手本なし」で試させることになるのだ。特にAIの使い方や仕事の進め方には、確立された手本がない。最近、エンジニア以外のメンバーにもAIを触ってもらっている。口で説明してもなかなか伝わらないが、画面を見せるとすぐ伝わる。百聞は一見に如かず、とはよく言ったものだ。これくらいでいいのか、こういう粒度でやり取りするのか、と具体が伝わる。伝わっているのは成果物ではなく、プロセスの方だ。弟子が見るべきも、まさにそのプロセスだ。最初は親方のコピーであるべきだ。同じやり方で同じ品質と生産性を出せてから、自己流を磨けばいい。コピーのポイントは、見よう見まねではない。親方がその時々に何を考えているのか、思考プロセスごとコピーしようとすることだ。お客様との会話も、AIの使い方も、動作確認の方法も。見て、真似る。「学ぶ」の語源は「真似ぶ」だと言われる。思考まで真似ようとすれば、とてつもない集中力がいる。それくらい真剣に「見る」ことが必要なのだ。親方のほうから場を作ってやればいい。「2時間この案件に取り組むから横で見ておいて」と弟子を呼ぶ。それで十分に伝わる。教える側がまずやって見せる。それが遠回りに見えて、一番の近道なのだろう。親方と弟子の「見る」は対になっている。親方が課題とフィードバックを渡し、弟子は思考プロセスを写し取る。双方向に機能することで、徒弟制度は回る。そう考えると、弟子の一番の仕事は「見る」ことそのものだ。最初のうちは中途半端に仕事を振って試行錯誤させるより、親方の仕事を徹底的に観察・理解・再現させた方が、立ち上がりが早い。このサイクルを回すほど、解像度も精度も上がっていく。それがトレーニングになる。これは、昔ながらの「見て盗め」の発想だ。ただ古い「見て盗め」には欠点があった。熟練者の手が速すぎて、何をやっているか見えない。 AI時代では事情が違う。親方とAIの会話ログに、暗黙知が言語化されて残る。手が速すぎて見えなかった仕事も、弟子は後からAIで確認できる。見て盗む2.0だ。AI時代だからこそ、むしろ効く学び方になっているのではないか。

技芸を「評価」することはできるのか〜目標管理からキャリブレーションへ

2026-04-14T11:55:32+09:00

本記事は、仕事を労働ではなく「技芸」として捉え直す「仕事技芸論」シリーズの記事です。

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

評価とは権力である

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

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

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

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

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

内発的動機を守る

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

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

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

評価のない十年

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

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

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

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

フラットの限界

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

全員でのコンセンサス

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

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

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

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

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

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

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

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

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

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

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

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

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

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

参考記事

エージェントで仕事を始めて変わったこと：降伏してから見えた景色

2026-04-11T15:04:25+09:00

AIエージェントを使い始めて、仕事のやり方が変わった。

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

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

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

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

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

閑話休題。

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

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

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

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

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

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

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

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

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

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

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

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

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

寺子屋ミシマ社〜仕事編〜で登壇してきました：「クリエイティブ読書」という試み

2026-04-08T23:18:41+09:00

紀伊國屋書店梅田本店にて開催された「寺子屋ミシマ社〜仕事編〜いい仕事をしたい！入門」に登壇させていただきました。ミシマ社の三島邦弘さんとのトークイベントです。

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

ミシマ社との出会い

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

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

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

三島さんとのトーク

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

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

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

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

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

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

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

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

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

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

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

うれしい時間

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

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

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

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

技芸はどう育つのか〜徒弟制度の実践と親方の学び

2026-04-03T12:37:02+09:00

本記事は、仕事を労働ではなく「技芸」として捉え直す「仕事技芸論」シリーズの記事です。

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

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

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

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

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

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

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

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

遊びが先、徒弟制度は後

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

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

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

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

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

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

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

親方という存在

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

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

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

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

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

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

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

観察こそが親方の仕事

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

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

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

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

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

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

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

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

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

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

一人では育てられない

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

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

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

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

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

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

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

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

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

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

棟梁としての経営者

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

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

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

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

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

参考記事

チャットとエージェントの違い、その次は

2026-04-02T08:37:07+09:00

2026年4月時点でのAIの使い方には、大きく分けて「チャット」と「エージェント」がある。この二つの違いは、機能の差ではなく、ループを回すのが誰かという構造の違いだと考えている。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

自立した人が「ここがいい」と思える会社〜人事の専門家に話した経営スタンス

2026-03-31T12:44:02+09:00

人事の専門家の方からインタビューを受けて、採用・評価・労務・組織のことをひと通り話した。聞かれて答えているうちに自分でも整理がついた感じがあったので、まとめてみることにした。

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

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

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

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

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

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

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

2つの話がある。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

一人残業禁止

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

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

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

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

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

思い出に投資する

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

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

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

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

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

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

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

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

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

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

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

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

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

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

師匠と弟子という関係を選んだ理由〜技芸の育成と徒弟制度

2026-03-29T20:50:00+09:00

本記事は、仕事を労働ではなく「技芸」として捉え直す「仕事技芸論」シリーズの記事です。

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

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

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

技芸の育成は可能なのか

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

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

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

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

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

なぜ「徒弟制度」なのか

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

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

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

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

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

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

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

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

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

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

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

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

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

再発明した徒弟制度

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

参考記事

AIエージェントとする仕事はペアワークだった

2026-03-26T14:44:17+09:00

AIの性能があがっていったことで、仕事してるときはずっと横に人がいてくれてる感じになった。Claude Codeを使うようになったら、自分はチャットでやりとりするだけで成果物ができて、リファインもしていける。

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

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

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

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

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

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

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

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

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

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

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

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

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