<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0" xmlns:content="http://purl.org/rss/1.0/modules/content/" xmlns:wfw="http://wellformedweb.org/CommentAPI/" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:atom="http://www.w3.org/2005/Atom" xmlns:sy="http://purl.org/rss/1.0/modules/syndication/" xmlns:slash="http://purl.org/rss/1.0/modules/slash/">
  <channel>
    <title>Social Change!</title>
    <atom:link href="https://kuranuki.sonicgarden.jp/feed" rel="self" type="application/rss+xml"/>
    <link>https://kuranuki.sonicgarden.jp</link>
    <description>「仕事を技芸とする文化を広げる」をコンセプトに、ソニックガーデン代表・倉貫義人が運営するメディア。経営・マネジメント・チームづくり・働き方・ソフトウェア開発についての考察と発見を発信しています。</description>
    <language>ja</language>
    <lastBuildDate>Wed, 08 Jul 2026 17:25:31 +0900</lastBuildDate>
    <sy:updatePeriod>hourly</sy:updatePeriod>
    <sy:updateFrequency>1</sy:updateFrequency>
    <image>
      <url>https://kuranuki.sonicgarden.jp/favicon.png</url>
      <title>Social Change!</title>
      <link>https://kuranuki.sonicgarden.jp</link>
      <width>32</width>
      <height>32</height>
    </image>
    <item>
      <title>本気でAIを使うと、まったく楽にならない</title>
      <link>https://kuranuki.sonicgarden.jp/archives/36086</link>
      <dc:creator>
        <![CDATA[倉貫 義人]]>
      </dc:creator>
      <pubDate>Mon, 06 Jul 2026 11:37:00 +0900</pubDate>
      <category>
        <![CDATA[思考メモ]]>
      </category>
      <guid isPermaLink="false">https://kuranuki-wp.sonicgarden.jp/?p=36086</guid>
      <description>
        <![CDATA[今週来週で講演や登壇が続く。そのうち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)に取り組んだ方がいい。
]]>
      </description>
      <content:encoded>
        <![CDATA[今週来週で講演や登壇が続く。そのうち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)に取り組んだ方がいい。
]]>
      </content:encoded>
    </item>
    <item>
      <title>ソニックガーデン、16期がはじまりました</title>
      <link>https://kuranuki.sonicgarden.jp/archives/36085</link>
      <dc:creator>
        <![CDATA[倉貫 義人]]>
      </dc:creator>
      <pubDate>Wed, 01 Jul 2026 20:58:00 +0900</pubDate>
      <category>
        <![CDATA[活動の記録]]>
      </category>
      <guid isPermaLink="false">https://kuranuki-wp.sonicgarden.jp/?p=36085</guid>
      <description>
        <![CDATA[ソニックガーデンは、本日7月1日をもって16期に入りました。

ここまで続けてこられたのは、日頃からお付き合いいただいているお客さま、パートナーのみなさん、そして一緒に働いてくれる仲間たちのおかげです。あらためて、ありがとうございます。

15期は、事業も人も大きく広がった一年でした。クラシコムとの資本業務提携、韓国からの採用、高校を卒業したばかりのメンバーの入社、倉貫書房とミシマ社の業務提携など、これまでのソニックガーデンの枠を超えるような挑戦がいくつも重なりました。

私たちは「思い出」を大切にする方針を掲げていて、それを実践する形で、全国各地でのハッケーション（合宿型の開発イベント）や、弟子合宿・親方合宿・コーポレート合宿なども積み重ねてきました。一緒に過ごした時間そのものが、私たちの財産になっていると感じています。

15期の後半、つまり今年の前半は、AIの登場によって会社そのものが大きく変わった時期でもありました。Claude Codeを全社の標準にすると決め、開発だけでなくコーポレートの仕事も含めて、AIを組み込んだ働き方へと組織を作り変えてきました。AIファーストな組織になっていく手応えを、この半年でつかんだように思います。

そして16期を迎えるにあたり、経営体制もひとつ新しくします。2014年の入社から10年以上一緒にやってきた野上誠司が、本日より取締役執行役員に就任しました（[会社からのお知らせ](https://www.sonicgarden.jp/blog_articles/7841)）。

あえて監督と執行を分けないことが、ソニックガーデンにとっては大事なのではないか。今回の経営体制を考えるときに、そう思いました。

これは、仕事を「技芸」として捉えていることとも重なります。「納品のない受託開発」も、分業せずに一気通貫で取り組むからこそ大きな価値が出せますし、担っている本人も自分の仕事の手応えを最後まで感じ取ることができます。経営も同じです。意思決定と実務を切り離さず、自分で担い続けることで、手応えを保てるのだと考えています。

16期も、ソニックガーデンらしく、変化を楽しみながら進んでいきます。どうぞよろしくお願いいたします。
]]>
      </description>
      <content:encoded>
        <![CDATA[ソニックガーデンは、本日7月1日をもって16期に入りました。

ここまで続けてこられたのは、日頃からお付き合いいただいているお客さま、パートナーのみなさん、そして一緒に働いてくれる仲間たちのおかげです。あらためて、ありがとうございます。

15期は、事業も人も大きく広がった一年でした。クラシコムとの資本業務提携、韓国からの採用、高校を卒業したばかりのメンバーの入社、倉貫書房とミシマ社の業務提携など、これまでのソニックガーデンの枠を超えるような挑戦がいくつも重なりました。

私たちは「思い出」を大切にする方針を掲げていて、それを実践する形で、全国各地でのハッケーション（合宿型の開発イベント）や、弟子合宿・親方合宿・コーポレート合宿なども積み重ねてきました。一緒に過ごした時間そのものが、私たちの財産になっていると感じています。

15期の後半、つまり今年の前半は、AIの登場によって会社そのものが大きく変わった時期でもありました。Claude Codeを全社の標準にすると決め、開発だけでなくコーポレートの仕事も含めて、AIを組み込んだ働き方へと組織を作り変えてきました。AIファーストな組織になっていく手応えを、この半年でつかんだように思います。

そして16期を迎えるにあたり、経営体制もひとつ新しくします。2014年の入社から10年以上一緒にやってきた野上誠司が、本日より取締役執行役員に就任しました（[会社からのお知らせ](https://www.sonicgarden.jp/blog_articles/7841)）。

あえて監督と執行を分けないことが、ソニックガーデンにとっては大事なのではないか。今回の経営体制を考えるときに、そう思いました。

これは、仕事を「技芸」として捉えていることとも重なります。「納品のない受託開発」も、分業せずに一気通貫で取り組むからこそ大きな価値が出せますし、担っている本人も自分の仕事の手応えを最後まで感じ取ることができます。経営も同じです。意思決定と実務を切り離さず、自分で担い続けることで、手応えを保てるのだと考えています。

16期も、ソニックガーデンらしく、変化を楽しみながら進んでいきます。どうぞよろしくお願いいたします。
]]>
      </content:encoded>
      <enclosure url="/rails/active_storage/blobs/proxy/eyJfcmFpbHMiOnsiZGF0YSI6MTMxNywicHVyIjoiYmxvYl9pZCJ9fQ==--852ab6e4a20379a87b66956f6670d1201053e1d3/2026-07-01-16th-start.jpg" type="image/jpeg"/>
    </item>
    <item>
      <title>書籍制作にもSSoTと冪等性を持ち込みたい</title>
      <link>https://kuranuki.sonicgarden.jp/archives/36084</link>
      <dc:creator>
        <![CDATA[倉貫 義人]]>
      </dc:creator>
      <pubDate>Tue, 30 Jun 2026 10:36:00 +0900</pubDate>
      <category>
        <![CDATA[思考メモ]]>
      </category>
      <guid isPermaLink="false">https://kuranuki-wp.sonicgarden.jp/?p=36084</guid>
      <description>
        <![CDATA[新刊の原稿を書き終えて、編集者から初校ゲラが届いた。指摘は的確で、ありがたい。ただ、この先の工程を思うと、気が重い。

本を作るたびに引っかかっていることがある。原稿を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と冪等性は、ソフトウェア開発だけのものではない。
]]>
      </description>
      <content:encoded>
        <![CDATA[新刊の原稿を書き終えて、編集者から初校ゲラが届いた。指摘は的確で、ありがたい。ただ、この先の工程を思うと、気が重い。

本を作るたびに引っかかっていることがある。原稿を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と冪等性は、ソフトウェア開発だけのものではない。
]]>
      </content:encoded>
    </item>
    <item>
      <title>「頭がいい」だけでは、仕事はできない〜IQ・EQを成果に変える「SQ」という出口</title>
      <link>https://kuranuki.sonicgarden.jp/archives/36083</link>
      <dc:creator>
        <![CDATA[倉貫 義人]]>
      </dc:creator>
      <pubDate>Thu, 18 Jun 2026 07:33:00 +0900</pubDate>
      <category>
        <![CDATA[仕事と経営]]>
      </category>
      <guid isPermaLink="false">https://kuranuki-wp.sonicgarden.jp/?p=36083</guid>
      <description>
        <![CDATA[「頭がいい」ことと、「仕事ができる」ことは、別のもの。

的確な分析も、筋の通った正論も、それだけでは人は動きません。頭の中にある正しさは、人を通って外に出てはじめて、成果に変わります。

頭の良さとは別の何かが、仕事の成果を分けている。その差は、どこから来るのか。

## 「頭がいい」は、知性の一部でしかない

「頭がいい」と言うとき、たいてい思い浮かべるのは一種類の能力です。論理的に考え、難しいことを理解する、いわゆる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が時代を問わず仕事の核心にあり続けてきた証でしょう。
]]>
      </description>
      <content:encoded>
        <![CDATA[「頭がいい」ことと、「仕事ができる」ことは、別のもの。

的確な分析も、筋の通った正論も、それだけでは人は動きません。頭の中にある正しさは、人を通って外に出てはじめて、成果に変わります。

頭の良さとは別の何かが、仕事の成果を分けている。その差は、どこから来るのか。

## 「頭がいい」は、知性の一部でしかない

「頭がいい」と言うとき、たいてい思い浮かべるのは一種類の能力です。論理的に考え、難しいことを理解する、いわゆる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が時代を問わず仕事の核心にあり続けてきた証でしょう。
]]>
      </content:encoded>
      <enclosure url="/rails/active_storage/blobs/proxy/eyJfcmFpbHMiOnsiZGF0YSI6MTMxMywicHVyIjoiYmxvYl9pZCJ9fQ==--321b898f8285c7335c3b2fbc896b99dfb31738a8/2026-06-16-five-iq.jpg" type="image/jpeg"/>
    </item>
    <item>
      <title>事業活動のすべてをコードにする</title>
      <link>https://kuranuki.sonicgarden.jp/archives/36082</link>
      <dc:creator>
        <![CDATA[倉貫 義人]]>
      </dc:creator>
      <pubDate>Fri, 12 Jun 2026 11:05:00 +0900</pubDate>
      <category>
        <![CDATA[思考メモ]]>
      </category>
      <guid isPermaLink="false">https://kuranuki-wp.sonicgarden.jp/?p=36082</guid>
      <description>
        <![CDATA[毎日、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)とき以来の変革になる気がしている。あのときは、働く場所が物理からオンライン上のソフトウェアに移った。今度は、仕事そのものがソフトウェアの側に移っていく。

人の作業を補助するためにソフトウェアがあるのではなく、コードになった事業を、人とエージェントが一緒に改善し続けていく。ソフトウェアが先にある会社だ。

いま社内のリポジトリには毎日コミットが積み重なっている。会社が少しずつ、コードになっていってる感じがするな。
]]>
      </description>
      <content:encoded>
        <![CDATA[毎日、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)とき以来の変革になる気がしている。あのときは、働く場所が物理からオンライン上のソフトウェアに移った。今度は、仕事そのものがソフトウェアの側に移っていく。

人の作業を補助するためにソフトウェアがあるのではなく、コードになった事業を、人とエージェントが一緒に改善し続けていく。ソフトウェアが先にある会社だ。

いま社内のリポジトリには毎日コミットが積み重なっている。会社が少しずつ、コードになっていってる感じがするな。
]]>
      </content:encoded>
    </item>
    <item>
      <title>AIを使いこなす力は、経営者の動き方と似ている</title>
      <link>https://kuranuki.sonicgarden.jp/archives/36052</link>
      <dc:creator>
        <![CDATA[倉貫 義人]]>
      </dc:creator>
      <pubDate>Mon, 08 Jun 2026 19:15:00 +0900</pubDate>
      <category>
        <![CDATA[思考メモ]]>
      </category>
      <guid isPermaLink="false">https://kuranuki-wp.sonicgarden.jp/?p=36052</guid>
      <description>
        <![CDATA[AIの提案を鵜呑みにしてしまい、達成感を失ったり、うまく成果を出せずにいる人を見かけるようになった。AIは、問われたことに最適化した回答を返してくる。問う側の目線が短期になっていれば、返ってくる答えも短期になる。

一方で、AIをうまく使いこなしている人もいる。問いを投げて自分の考えを深め、手間のかかる作業は任せる。そうやってパートナーのように付き合っている。その違いは、どこにあるのだろう。

AIを使いこなすには、実は2つの能力がいるのではないか。

ひとつは、出てきたものの良し悪しを判断する力である。たとえばAIが書いたコードを読んで設計の筋を見抜けるか、AIが書いた文章を読んで論理の飛びを見つけられるか。技術力に直結する力で、その分野での自分の専門性そのものに近い。

もうひとつは、AIに対して率直に意見を言える力だ。出てきた答えをそのまま受け取らず「今のこの状況だとそれはおかしくないか」「なぜそう言うのか」と問い返す。対等な相手として尊重しつつ、最後のハンドルは自分が握る。

後者は、経営者が得意としている部分ではないかと思う。

経営者は、自分ひとりで解決しようとしない。私自身、人事の専門家や弁護士、税理士と仕事をしてきた。どの領域でも、相手は私よりずっと詳しい。

その代わりに、経営者がやっているのは「なんとかする」ことだ。自分で全部考えて決めるというよりも、専門家の意見を踏まえつつ、うちの状況だと違うのではないかと問い返し、最後は自分で決めて責任を取る。意思決定と責任が、経営者の仕事なのだ。

AIへの付き合い方は、これとほとんど同じ構造をしている。世の中の経営者がAIをうまく使えているのは偶然ではなく、普段からやっている動き方を、AI相手にも自然に持ち込んでいるからではないだろうか。

とはいえ、自分より詳しい相手と仕事をする経験など、経営者じゃないとなかなか積めなかった。だが、AIは誰にとっても初めての「自分より詳しい部下」だ。経営者だけのものだった練習の場が、いま誰の手元にもある。

これからは、そうやって誰もが自分の専門外をAIに任せて成果を出すことが求められる時代になっていくんだろうな。]]>
      </description>
      <content:encoded>
        <![CDATA[AIの提案を鵜呑みにしてしまい、達成感を失ったり、うまく成果を出せずにいる人を見かけるようになった。AIは、問われたことに最適化した回答を返してくる。問う側の目線が短期になっていれば、返ってくる答えも短期になる。

一方で、AIをうまく使いこなしている人もいる。問いを投げて自分の考えを深め、手間のかかる作業は任せる。そうやってパートナーのように付き合っている。その違いは、どこにあるのだろう。

AIを使いこなすには、実は2つの能力がいるのではないか。

ひとつは、出てきたものの良し悪しを判断する力である。たとえばAIが書いたコードを読んで設計の筋を見抜けるか、AIが書いた文章を読んで論理の飛びを見つけられるか。技術力に直結する力で、その分野での自分の専門性そのものに近い。

もうひとつは、AIに対して率直に意見を言える力だ。出てきた答えをそのまま受け取らず「今のこの状況だとそれはおかしくないか」「なぜそう言うのか」と問い返す。対等な相手として尊重しつつ、最後のハンドルは自分が握る。

後者は、経営者が得意としている部分ではないかと思う。

経営者は、自分ひとりで解決しようとしない。私自身、人事の専門家や弁護士、税理士と仕事をしてきた。どの領域でも、相手は私よりずっと詳しい。

その代わりに、経営者がやっているのは「なんとかする」ことだ。自分で全部考えて決めるというよりも、専門家の意見を踏まえつつ、うちの状況だと違うのではないかと問い返し、最後は自分で決めて責任を取る。意思決定と責任が、経営者の仕事なのだ。

AIへの付き合い方は、これとほとんど同じ構造をしている。世の中の経営者がAIをうまく使えているのは偶然ではなく、普段からやっている動き方を、AI相手にも自然に持ち込んでいるからではないだろうか。

とはいえ、自分より詳しい相手と仕事をする経験など、経営者じゃないとなかなか積めなかった。だが、AIは誰にとっても初めての「自分より詳しい部下」だ。経営者だけのものだった練習の場が、いま誰の手元にもある。

これからは、そうやって誰もが自分の専門外をAIに任せて成果を出すことが求められる時代になっていくんだろうな。]]>
      </content:encoded>
    </item>
    <item>
      <title>「手打ちコーディング」がなくなっても、作り手であることは変わらない</title>
      <link>https://kuranuki.sonicgarden.jp/archives/36043</link>
      <dc:creator>
        <![CDATA[倉貫 義人]]>
      </dc:creator>
      <pubDate>Fri, 05 Jun 2026 06:34:00 +0900</pubDate>
      <category>
        <![CDATA[思考メモ]]>
      </category>
      <guid isPermaLink="false">https://kuranuki-wp.sonicgarden.jp/?p=36043</guid>
      <description>
        <![CDATA[このごろ、プログラマが手でコードを打つことが、ほとんどなくなってきた。コーディングエージェントに任せた方が、キーボードを叩くより圧倒的に早いからだ。

少し前なら、コーディングと言えばキーボードを叩いてコードを書くことだった。今は違う。エージェントが書くのが当たり前になり、人間が手で打つ方が特別なことになった。

私はこれを「手打ちコーディング」と呼んでいる。

「手打ちそば」も、昔はなかった言葉のはずだ。そばはそばだった。機械でそばが作られるようになって、初めて手で打つそばを「手打ち」と呼ぶようになった。標準が機械側に移ったときに、それまで標準だったものに名前がつく。コーディングにも、同じことが起きた。

そういえば「手打ち」と言いつつ、コーディングで実際にやっているのはキーボードを叩くことであって、手で書いているわけではない。それでも「手打ち」と呼ぶことに、自分でも違和感がない。比喩は不思議なものだ。この先、エージェントに指示を出して書かせることまで、いつか「手で書く」と呼ばれる日が来るのかもしれない。

これはコーディングだけの話ではない。文章を書くときも同じ。

この記事も、エージェントを使って書いている。多少のミスや違和感はある。それでも書き直させた方が、自分で手打ちするより早いし、楽だ。人間、一度楽を覚えると元には戻れない。

パンチカードからキーボードに変わったときも、きっと同じことが起きたのだろう。手打ちからエージェントに変わるのも、その延長線上の出来事だ。

やり方が変わるだけで、作ることそのものがなくなるわけではない。エージェントに任せても、プログラマがソフトウェアを作っていることに変わりはない。文章だって同じだ。

とはいえ、手打ちが残る世界もある。

文章の世界では、いまだに原稿用紙にペンで書く小説家がいると聞く。キーボードで打った方が圧倒的に早いのに、ペンで書いた方がいい作品ができると信じている。それも、人の手による作品作りのひとつの道だ。

ただし、コーディングはそうはならないだろう。小説と違って、コードの読み手は書き手の手の痕跡を求めて読んでいるわけではないからだ。コーディングはエージェントの手に渡って、それが当たり前になっていく。

手で打たなくなっても、作り手であることは変わらないんだろうな。
]]>
      </description>
      <content:encoded>
        <![CDATA[このごろ、プログラマが手でコードを打つことが、ほとんどなくなってきた。コーディングエージェントに任せた方が、キーボードを叩くより圧倒的に早いからだ。

少し前なら、コーディングと言えばキーボードを叩いてコードを書くことだった。今は違う。エージェントが書くのが当たり前になり、人間が手で打つ方が特別なことになった。

私はこれを「手打ちコーディング」と呼んでいる。

「手打ちそば」も、昔はなかった言葉のはずだ。そばはそばだった。機械でそばが作られるようになって、初めて手で打つそばを「手打ち」と呼ぶようになった。標準が機械側に移ったときに、それまで標準だったものに名前がつく。コーディングにも、同じことが起きた。

そういえば「手打ち」と言いつつ、コーディングで実際にやっているのはキーボードを叩くことであって、手で書いているわけではない。それでも「手打ち」と呼ぶことに、自分でも違和感がない。比喩は不思議なものだ。この先、エージェントに指示を出して書かせることまで、いつか「手で書く」と呼ばれる日が来るのかもしれない。

これはコーディングだけの話ではない。文章を書くときも同じ。

この記事も、エージェントを使って書いている。多少のミスや違和感はある。それでも書き直させた方が、自分で手打ちするより早いし、楽だ。人間、一度楽を覚えると元には戻れない。

パンチカードからキーボードに変わったときも、きっと同じことが起きたのだろう。手打ちからエージェントに変わるのも、その延長線上の出来事だ。

やり方が変わるだけで、作ることそのものがなくなるわけではない。エージェントに任せても、プログラマがソフトウェアを作っていることに変わりはない。文章だって同じだ。

とはいえ、手打ちが残る世界もある。

文章の世界では、いまだに原稿用紙にペンで書く小説家がいると聞く。キーボードで打った方が圧倒的に早いのに、ペンで書いた方がいい作品ができると信じている。それも、人の手による作品作りのひとつの道だ。

ただし、コーディングはそうはならないだろう。小説と違って、コードの読み手は書き手の手の痕跡を求めて読んでいるわけではないからだ。コーディングはエージェントの手に渡って、それが当たり前になっていく。

手で打たなくなっても、作り手であることは変わらないんだろうな。
]]>
      </content:encoded>
    </item>
    <item>
      <title>AI時代の仕事技芸論〜ソフトウェア開発で「遊ぶように働く」職人的熟達のすすめ</title>
      <link>https://kuranuki.sonicgarden.jp/archives/36042</link>
      <dc:creator>
        <![CDATA[倉貫 義人]]>
      </dc:creator>
      <pubDate>Tue, 02 Jun 2026 06:44:00 +0900</pubDate>
      <category>
        <![CDATA[仕事技芸論]]>
      </category>
      <guid isPermaLink="false">https://kuranuki-wp.sonicgarden.jp/?p=36042</guid>
      <description>
        <![CDATA[日本で初開催となった [Laravel Live Japan 2026](https://laravellive.jp) に、登壇者として呼んでいただきました。「AI時代の仕事技芸論」というテーマで話した内容を、当日の流れのまま書き起こします。スライドと動画は以下です。

<iframe class="speakerdeck-iframe" frameborder="0" src="https://speakerdeck.com/player/b13e31674c454ebba8081648f4b85410" title="AI時代の仕事技芸論 — ソフトウェア開発で「遊ぶように働く」職人的熟達のすすめ" allowfullscreen="true" allow="web-share" style="border: 0px; background: padding-box padding-box rgba(0, 0, 0, 0.1); margin: 0px; padding: 0px; border-radius: 6px; box-shadow: rgba(0, 0, 0, 0.2) 0px 5px 40px; width: 100%; height: auto; aspect-ratio: 560 / 315;" data-ratio="1.7777777777777777"></iframe>

<iframe src="https://www.youtube.com/embed/TR25AkhjiRc?si=LOqqfO7-jB21NwLR&amp;start=19484" title="YouTube video player" frameborder="0" allow="accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture; web-share" referrerpolicy="strict-origin-when-cross-origin" allowfullscreen style="width: 100%; height: auto; aspect-ratio: 560 / 315; border: 0; border-radius: 6px;"></iframe>

## なぜ、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)
]]>
      </description>
      <content:encoded>
        <![CDATA[日本で初開催となった [Laravel Live Japan 2026](https://laravellive.jp) に、登壇者として呼んでいただきました。「AI時代の仕事技芸論」というテーマで話した内容を、当日の流れのまま書き起こします。スライドと動画は以下です。

<iframe class="speakerdeck-iframe" frameborder="0" src="https://speakerdeck.com/player/b13e31674c454ebba8081648f4b85410" title="AI時代の仕事技芸論 — ソフトウェア開発で「遊ぶように働く」職人的熟達のすすめ" allowfullscreen="true" allow="web-share" style="border: 0px; background: padding-box padding-box rgba(0, 0, 0, 0.1); margin: 0px; padding: 0px; border-radius: 6px; box-shadow: rgba(0, 0, 0, 0.2) 0px 5px 40px; width: 100%; height: auto; aspect-ratio: 560 / 315;" data-ratio="1.7777777777777777"></iframe>

<iframe src="https://www.youtube.com/embed/TR25AkhjiRc?si=LOqqfO7-jB21NwLR&amp;start=19484" title="YouTube video player" frameborder="0" allow="accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture; web-share" referrerpolicy="strict-origin-when-cross-origin" allowfullscreen style="width: 100%; height: auto; aspect-ratio: 560 / 315; border: 0; border-radius: 6px;"></iframe>

## なぜ、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)
]]>
      </content:encoded>
      <enclosure url="/rails/active_storage/blobs/proxy/eyJfcmFpbHMiOnsiZGF0YSI6MTMwOCwicHVyIjoiYmxvYl9pZCJ9fQ==--353b18e2b6873a93ddad70892982971902c32d5f/2026-05-30-ai-craft.jpg" type="image/jpeg"/>
    </item>
    <item>
      <title>「AIは高い」のではなく、使いこなせていないと高い〜全社でAIに振り切った一ヶ月</title>
      <link>https://kuranuki.sonicgarden.jp/archives/36040</link>
      <dc:creator>
        <![CDATA[倉貫 義人]]>
      </dc:creator>
      <pubDate>Sat, 30 May 2026 17:37:00 +0900</pubDate>
      <category>
        <![CDATA[仕事と経営]]>
      </category>
      <guid isPermaLink="false">https://kuranuki-wp.sonicgarden.jp/?p=36040</guid>
      <description>
        <![CDATA[この記事は、連載「[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)
]]>
      </description>
      <content:encoded>
        <![CDATA[この記事は、連載「[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)
]]>
      </content:encoded>
      <enclosure url="/rails/active_storage/blobs/proxy/eyJfcmFpbHMiOnsiZGF0YSI6MTMwNiwicHVyIjoiYmxvYl9pZCJ9fQ==--3959466e6ab3f546077d61b8360adcc034e912d8/2026-05-31-no-return.jpg" type="image/jpeg"/>
    </item>
    <item>
      <title>Laravel Live Japan 2026で登壇してきました：別々の道から、同じ場所で交わるということ</title>
      <link>https://kuranuki.sonicgarden.jp/archives/36039</link>
      <dc:creator>
        <![CDATA[倉貫 義人]]>
      </dc:creator>
      <pubDate>Fri, 29 May 2026 09:12:00 +0900</pubDate>
      <category>
        <![CDATA[活動の記録]]>
      </category>
      <guid isPermaLink="false">https://kuranuki-wp.sonicgarden.jp/?p=36039</guid>
      <description>
        <![CDATA[日本では初開催となる [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で公開しています。

<iframe class="speakerdeck-iframe" frameborder="0" src="https://speakerdeck.com/player/7ebf0856c9a54ae08babc5519501b249" title="The Arts and Crafts of Work in the AI Era — Toward Mastery in Software Development" allowfullscreen="true" allow="web-share" style="border: 0px; background: padding-box padding-box rgba(0, 0, 0, 0.1); margin: 0px; padding: 0px; border-radius: 6px; box-shadow: rgba(0, 0, 0, 0.2) 0px 5px 40px; width: 100%; height: auto; aspect-ratio: 560 / 315;" data-ratio="1.7777777777777777"></iframe>

講演の動画もYouTubeで公開されています。

<iframe src="https://www.youtube.com/embed/TR25AkhjiRc?si=LOqqfO7-jB21NwLR&amp;start=19484" title="YouTube video player" frameborder="0" allow="accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture; web-share" referrerpolicy="strict-origin-when-cross-origin" allowfullscreen style="width: 100%; height: auto; aspect-ratio: 560 / 315; border: 0; border-radius: 6px;"></iframe>

## 海外カンファレンスのような雰囲気

会場の雰囲気も、とても良いものでした。言語やフレームワーク、職種や出身国。そうした違いを超えて、誰もが歓迎される空気がありました。海外のカンファレンスに参加しているような感覚で、純粋に楽しい時間でした。

実際、登壇者の多くは海外からのスピーカーでした。日本人の登壇者は少なく、その日本人も英語で講演する人が多い。日本語で話した私は、むしろ少数派だったかもしれません。それでも、Laravel本社のJosh Cirreさんが講演のあとに英語で熱のこもった感想を寄せてくれるなど、私の話が海外の人にも同じように届いている手応えがありました。

## いいソフトウェアをつくる

会場には、扇子に好きな文字を書き入れてくれるブースがありました。私がお願いしたのは、「いいソフトウェアをつくる」です。

![](https://kuranuki.sonicgarden.jp/rails/active_storage/blobs/proxy/eyJfcmFpbHMiOnsiZGF0YSI6MTMwNCwicHVyIjoiYmxvYl9pZCJ9fQ==--faeaca3b5add63b707eb892125068900eabe9d38/2026-05-28-laravel-jp-fan.jpg)

これは、ソニックガーデンが長く掲げてきた言葉でもあります。Laravelのイベントで、その思いを扇子に書いてもらいました。使う道具は違っても、つくりたいものは同じなのだと思います。

招いてくれた濱崎さん、運営の皆さん、登壇者と参加者の皆さん、ありがとうございました。]]>
      </description>
      <content:encoded>
        <![CDATA[日本では初開催となる [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で公開しています。

<iframe class="speakerdeck-iframe" frameborder="0" src="https://speakerdeck.com/player/7ebf0856c9a54ae08babc5519501b249" title="The Arts and Crafts of Work in the AI Era — Toward Mastery in Software Development" allowfullscreen="true" allow="web-share" style="border: 0px; background: padding-box padding-box rgba(0, 0, 0, 0.1); margin: 0px; padding: 0px; border-radius: 6px; box-shadow: rgba(0, 0, 0, 0.2) 0px 5px 40px; width: 100%; height: auto; aspect-ratio: 560 / 315;" data-ratio="1.7777777777777777"></iframe>

講演の動画もYouTubeで公開されています。

<iframe src="https://www.youtube.com/embed/TR25AkhjiRc?si=LOqqfO7-jB21NwLR&amp;start=19484" title="YouTube video player" frameborder="0" allow="accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture; web-share" referrerpolicy="strict-origin-when-cross-origin" allowfullscreen style="width: 100%; height: auto; aspect-ratio: 560 / 315; border: 0; border-radius: 6px;"></iframe>

## 海外カンファレンスのような雰囲気

会場の雰囲気も、とても良いものでした。言語やフレームワーク、職種や出身国。そうした違いを超えて、誰もが歓迎される空気がありました。海外のカンファレンスに参加しているような感覚で、純粋に楽しい時間でした。

実際、登壇者の多くは海外からのスピーカーでした。日本人の登壇者は少なく、その日本人も英語で講演する人が多い。日本語で話した私は、むしろ少数派だったかもしれません。それでも、Laravel本社のJosh Cirreさんが講演のあとに英語で熱のこもった感想を寄せてくれるなど、私の話が海外の人にも同じように届いている手応えがありました。

## いいソフトウェアをつくる

会場には、扇子に好きな文字を書き入れてくれるブースがありました。私がお願いしたのは、「いいソフトウェアをつくる」です。

![](https://kuranuki.sonicgarden.jp/rails/active_storage/blobs/proxy/eyJfcmFpbHMiOnsiZGF0YSI6MTMwNCwicHVyIjoiYmxvYl9pZCJ9fQ==--faeaca3b5add63b707eb892125068900eabe9d38/2026-05-28-laravel-jp-fan.jpg)

これは、ソニックガーデンが長く掲げてきた言葉でもあります。Laravelのイベントで、その思いを扇子に書いてもらいました。使う道具は違っても、つくりたいものは同じなのだと思います。

招いてくれた濱崎さん、運営の皆さん、登壇者と参加者の皆さん、ありがとうございました。]]>
      </content:encoded>
      <enclosure url="/rails/active_storage/blobs/proxy/eyJfcmFpbHMiOnsiZGF0YSI6MTMwNywicHVyIjoiYmxvYl9pZCJ9fQ==--751a9e4e4f154dc2398227d8c689626bcd4facc1/2026-05-28-laravel-jp-venue.jpg" type="image/jpeg"/>
    </item>
    <item>
      <title>WordPressがなくなる日〜エンジニアリング原則の適用範囲を引き直す</title>
      <link>https://kuranuki.sonicgarden.jp/archives/36036</link>
      <dc:creator>
        <![CDATA[倉貫 義人]]>
      </dc:creator>
      <pubDate>Fri, 15 May 2026 09:24:00 +0900</pubDate>
      <category>
        <![CDATA[思考メモ]]>
      </category>
      <guid isPermaLink="false">https://kuranuki-wp.sonicgarden.jp/?p=36036</guid>
      <description>
        <![CDATA[15年以上、自分のブログをWordPressで運用してきた。エディタの世代交代に合わせて使い方を変え、プラグインを整理し、テーマを差し替えながら、長くつきあってきた道具である。

途中、Mediumやnoteへの移行を検討したこともあったし、ヘッドレスCMSで自前のフロントを作る構想を持ったこともある。けれど、どれも決定打がないまま、結局はWordPressを使い続けてきた。それだけよくできた道具だったということでもある。

それが、AIに任せて自前のサイトへ移すという作業が、思いのほか工数も時間もかからずに終わってしまった。エンジニアでない人がアプリを作れる時代である。これ自体は、いまや驚くような話ではない。

注目すべきは、別のところにある。何がなくなったのか、という問いだ。

そもそもCMSは、何を解決していたのだろうか。書き手が技術者でないことを補い、書き手と作り手の分業を可能にし、テンプレートで工数を減らし、デザインと内容を分離し、DBで記事を管理する。どれも、書き手と作り手が分かれていた時代、人間が手で書くコストが高かった時代の、制約への解だった。

AIは、その前提を崩した。書き手が直接マークアップを生成できる。HTMLを書くコストは、ほぼゼロだ。一覧ページも検索も、必要なら都度生成すればいい。CMSが解決していた課題の多くは、別のかたちで解消されつつある。

DRY原則は、いまも変わらず大切なのだと思う。重複は保守性を下げる。AIが生成したコードであっても、ロジックがDRYでなければ、変更したときに破綻が起きる。これはプログラミングの原則として残り続けるのだろう。

しかし、HTMLはマークアップにすぎない。プログラミング言語ではなく、ロジックを含まない。同じようなマークアップが繰り返されていても、本質的な保守上の問題は起きにくい。AIが都度書き直せるなら、なおさらだろう。

CMSがやっていた「テンプレート化による再利用」は、ロジックの共通化というより、マークアップの共通化だったのではないか。それは人間が手で書くコストへの対応であって、エンジニアリング的な必然というわけではなかったのかもしれない。

そう考えると、CMSは特定の制約下での最適解だったのだろう。WordPressが長きにわたって書き手たちの道具であり続けたのも、その制約に対する優れた解だったからこそだ。前提が変われば、その役割も変わっていくはずだ。

私たちはこれまで、ロジックを持たないものにまで、エンジニアリングの原則を引き伸ばして適用してきた。人間のコストが高すぎたから、適用しないと現実が回らなかったのだ。けれど、その前提が変われば、合理性の中身も変わる。これまでの適用には、誤適用だった部分があったのかもしれない。

ロジックには、これまで通りDRYを守る。けれど、マークアップやコンテンツにまでこだわる必要は、もうないのかもしれない。AIに任せて、都度書き直せばよいことも増えていくはずだ。

AIの時代に、何にエンジニアリング原則を適用し、何には適用しないのか。

その線引きを、引き直す時期に来ているのではないか。
]]>
      </description>
      <content:encoded>
        <![CDATA[15年以上、自分のブログをWordPressで運用してきた。エディタの世代交代に合わせて使い方を変え、プラグインを整理し、テーマを差し替えながら、長くつきあってきた道具である。

途中、Mediumやnoteへの移行を検討したこともあったし、ヘッドレスCMSで自前のフロントを作る構想を持ったこともある。けれど、どれも決定打がないまま、結局はWordPressを使い続けてきた。それだけよくできた道具だったということでもある。

それが、AIに任せて自前のサイトへ移すという作業が、思いのほか工数も時間もかからずに終わってしまった。エンジニアでない人がアプリを作れる時代である。これ自体は、いまや驚くような話ではない。

注目すべきは、別のところにある。何がなくなったのか、という問いだ。

そもそもCMSは、何を解決していたのだろうか。書き手が技術者でないことを補い、書き手と作り手の分業を可能にし、テンプレートで工数を減らし、デザインと内容を分離し、DBで記事を管理する。どれも、書き手と作り手が分かれていた時代、人間が手で書くコストが高かった時代の、制約への解だった。

AIは、その前提を崩した。書き手が直接マークアップを生成できる。HTMLを書くコストは、ほぼゼロだ。一覧ページも検索も、必要なら都度生成すればいい。CMSが解決していた課題の多くは、別のかたちで解消されつつある。

DRY原則は、いまも変わらず大切なのだと思う。重複は保守性を下げる。AIが生成したコードであっても、ロジックがDRYでなければ、変更したときに破綻が起きる。これはプログラミングの原則として残り続けるのだろう。

しかし、HTMLはマークアップにすぎない。プログラミング言語ではなく、ロジックを含まない。同じようなマークアップが繰り返されていても、本質的な保守上の問題は起きにくい。AIが都度書き直せるなら、なおさらだろう。

CMSがやっていた「テンプレート化による再利用」は、ロジックの共通化というより、マークアップの共通化だったのではないか。それは人間が手で書くコストへの対応であって、エンジニアリング的な必然というわけではなかったのかもしれない。

そう考えると、CMSは特定の制約下での最適解だったのだろう。WordPressが長きにわたって書き手たちの道具であり続けたのも、その制約に対する優れた解だったからこそだ。前提が変われば、その役割も変わっていくはずだ。

私たちはこれまで、ロジックを持たないものにまで、エンジニアリングの原則を引き伸ばして適用してきた。人間のコストが高すぎたから、適用しないと現実が回らなかったのだ。けれど、その前提が変われば、合理性の中身も変わる。これまでの適用には、誤適用だった部分があったのかもしれない。

ロジックには、これまで通りDRYを守る。けれど、マークアップやコンテンツにまでこだわる必要は、もうないのかもしれない。AIに任せて、都度書き直せばよいことも増えていくはずだ。

AIの時代に、何にエンジニアリング原則を適用し、何には適用しないのか。

その線引きを、引き直す時期に来ているのではないか。
]]>
      </content:encoded>
    </item>
    <item>
      <title>マイナビ転職『アンドエンジニア』で取材を受けました：技術を磨いた先にあるキャリアの広げ方</title>
      <link>https://kuranuki.sonicgarden.jp/archives/36035</link>
      <dc:creator>
        <![CDATA[倉貫 義人]]>
      </dc:creator>
      <pubDate>Mon, 11 May 2026 17:37:00 +0900</pubDate>
      <category>
        <![CDATA[活動の記録]]>
      </category>
      <guid isPermaLink="false">https://kuranuki-wp.sonicgarden.jp/?p=36035</guid>
      <description>
        <![CDATA[マイナビ転職のエンジニア向けメディア「アンドエンジニア」から取材を受け、私のキャリアについての記事を掲載していただきました。

大手SIerに入った若い頃から、社内ベンチャーを経て独立し、「納品のない受託開発」というビジネスモデルにたどり着くまで。その道のりを丁寧に聞いていただいた取材です。

記事は以下のような構成になっています。

- 技術を突き詰めたくて飛び込んだSIerの世界。そこで直面したキャリアと受託開発の課題
- 「キャリアの軸」は手を動かし、専門性を磨いた先に
- ソフトウェア開発者らしい考え方がビジネスモデルを生み出した
- ソフトウェア開発って面白い。それが仕事でできるのは魅力でしかない

取材を通じて改めて言葉にしてみて、自分の中で整理がついたことがありました。

## キャリアの軸は、探すのではなく現れるもの

若手のエンジニアと話していると、「自分の軸を早く見つけたい」という相談を受けることがあります。

軸は探して見つけるものではありません。目の前の仕事に一生懸命取り組み、専門性を磨いていった先に、運が良ければ後から現れてくる。それが軸の正体です。

私自身、SIerに入った当初から「アジャイルを軸にしよう」と決めていたわけではありません。ソフトウェア開発をいいものにしたいという思いを突き詰めた結果、エクストリーム・プログラミングに出会い、それが後から自分の軸として立ち上がってきました。

軸を探す前に、まず一生懸命に目の前の仕事をする。順番としてはそちらの方がいいと考えています。

## ソフトウェア開発の全プロセスを経験する

もうひとつ大事だと考えているのが、「ソフトウェア開発の全プロセスを経験してほしい」ということです。

企画から要件定義、設計、実装、デリバリー、運用、フィードバックの反映まで。この一連の流れを自分の手で回した経験があるかどうかで、エンジニアとしての視座はまるで変わってきます。

大規模システムの一機能だけを担当している限り、ソフトウェアの全体像は見えてきません。AIがコードを書くようになった時代だからこそ、コーディングそのものよりも「全体を描ける人」の価値が上がっていきます。

小さくてもいいから、自分が最初から最後まで関わったソフトウェアを持っていること。それがこれからのエンジニアの強みになっていくはずです。

## 抽象度を上げて考える

「納品のない受託開発」というビジネスモデルを生み出せたのは、ソフトウェア開発者ならではの思考の型があったように思います。

一括請負型の受託開発に違和感を覚えたとき、「契約書の文言をどう変えるか」というレベルで考えるのではなく、「お客様とずっと寄り添いながら開発するにはどうしたらいいか」と一段抽象度を上げて考える。すると「そもそも納品をなくせばいい」という別の解にたどり着きます。

問題の抽象度を上げてから具体に降ろし直すという思考は、ソフトウェアエンジニアが日々やっていることそのものです。そしてこの思考の型は、エンジニアリングの現場だけでなく、ビジネスや経営の課題にもそのまま使えます。エンジニアの考え方は、それ自体がひとつの強い武器になります。

---

エンジニアとしての専門性をどう積み上げるか、AI時代の技術者の価値とは何か。自分のたどってきた道を改めて言葉にする、いい機会になりました。

手を動かし、技術を磨いた先に専門性がある。『納品のない受託開発』を生んだ倉貫義人に学ぶキャリアの広げ方
https://tenshoku.mynavi.jp/engineer/guide/articles/t0033
]]>
      </description>
      <content:encoded>
        <![CDATA[マイナビ転職のエンジニア向けメディア「アンドエンジニア」から取材を受け、私のキャリアについての記事を掲載していただきました。

大手SIerに入った若い頃から、社内ベンチャーを経て独立し、「納品のない受託開発」というビジネスモデルにたどり着くまで。その道のりを丁寧に聞いていただいた取材です。

記事は以下のような構成になっています。

- 技術を突き詰めたくて飛び込んだSIerの世界。そこで直面したキャリアと受託開発の課題
- 「キャリアの軸」は手を動かし、専門性を磨いた先に
- ソフトウェア開発者らしい考え方がビジネスモデルを生み出した
- ソフトウェア開発って面白い。それが仕事でできるのは魅力でしかない

取材を通じて改めて言葉にしてみて、自分の中で整理がついたことがありました。

## キャリアの軸は、探すのではなく現れるもの

若手のエンジニアと話していると、「自分の軸を早く見つけたい」という相談を受けることがあります。

軸は探して見つけるものではありません。目の前の仕事に一生懸命取り組み、専門性を磨いていった先に、運が良ければ後から現れてくる。それが軸の正体です。

私自身、SIerに入った当初から「アジャイルを軸にしよう」と決めていたわけではありません。ソフトウェア開発をいいものにしたいという思いを突き詰めた結果、エクストリーム・プログラミングに出会い、それが後から自分の軸として立ち上がってきました。

軸を探す前に、まず一生懸命に目の前の仕事をする。順番としてはそちらの方がいいと考えています。

## ソフトウェア開発の全プロセスを経験する

もうひとつ大事だと考えているのが、「ソフトウェア開発の全プロセスを経験してほしい」ということです。

企画から要件定義、設計、実装、デリバリー、運用、フィードバックの反映まで。この一連の流れを自分の手で回した経験があるかどうかで、エンジニアとしての視座はまるで変わってきます。

大規模システムの一機能だけを担当している限り、ソフトウェアの全体像は見えてきません。AIがコードを書くようになった時代だからこそ、コーディングそのものよりも「全体を描ける人」の価値が上がっていきます。

小さくてもいいから、自分が最初から最後まで関わったソフトウェアを持っていること。それがこれからのエンジニアの強みになっていくはずです。

## 抽象度を上げて考える

「納品のない受託開発」というビジネスモデルを生み出せたのは、ソフトウェア開発者ならではの思考の型があったように思います。

一括請負型の受託開発に違和感を覚えたとき、「契約書の文言をどう変えるか」というレベルで考えるのではなく、「お客様とずっと寄り添いながら開発するにはどうしたらいいか」と一段抽象度を上げて考える。すると「そもそも納品をなくせばいい」という別の解にたどり着きます。

問題の抽象度を上げてから具体に降ろし直すという思考は、ソフトウェアエンジニアが日々やっていることそのものです。そしてこの思考の型は、エンジニアリングの現場だけでなく、ビジネスや経営の課題にもそのまま使えます。エンジニアの考え方は、それ自体がひとつの強い武器になります。

---

エンジニアとしての専門性をどう積み上げるか、AI時代の技術者の価値とは何か。自分のたどってきた道を改めて言葉にする、いい機会になりました。

手を動かし、技術を磨いた先に専門性がある。『納品のない受託開発』を生んだ倉貫義人に学ぶキャリアの広げ方
https://tenshoku.mynavi.jp/engineer/guide/articles/t0033
]]>
      </content:encoded>
      <enclosure url="/rails/active_storage/blobs/proxy/eyJfcmFpbHMiOnsiZGF0YSI6MTI5OSwicHVyIjoiYmxvYl9pZCJ9fQ==--43c6fe35279b00251a3b691f1be64ecab40065d7/2026-05-02-mynavi.jpg" type="image/jpeg"/>
    </item>
    <item>
      <title>「審美眼こそが真実」〜DHHが語るAIエージェント時代の技芸論</title>
      <link>https://kuranuki.sonicgarden.jp/archives/36034</link>
      <dc:creator>
        <![CDATA[倉貫 義人]]>
      </dc:creator>
      <pubDate>Fri, 08 May 2026 12:04:00 +0900</pubDate>
      <category>
        <![CDATA[仕事技芸論]]>
      </category>
      <guid isPermaLink="false">https://kuranuki-wp.sonicgarden.jp/?p=36034</guid>
      <description>
        <![CDATA[先日、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分）
]]>
      </description>
      <content:encoded>
        <![CDATA[先日、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分）
]]>
      </content:encoded>
      <enclosure url="/rails/active_storage/blobs/proxy/eyJfcmFpbHMiOnsiZGF0YSI6MTI5OCwicHVyIjoiYmxvYl9pZCJ9fQ==--29539996d614a259f0b62915508f5f5a2aec4922/2026-05-07-dhh-craft-v2.jpg" type="image/jpeg"/>
    </item>
    <item>
      <title>「ありたい姿」のまま、続けていく〜コミュニティと株式会社のあいだ</title>
      <link>https://kuranuki.sonicgarden.jp/archives/36033</link>
      <dc:creator>
        <![CDATA[倉貫 義人]]>
      </dc:creator>
      <pubDate>Thu, 07 May 2026 19:17:00 +0900</pubDate>
      <category>
        <![CDATA[仕事と経営]]>
      </category>
      <guid isPermaLink="false">https://kuranuki-wp.sonicgarden.jp/?p=36033</guid>
      <description>
        <![CDATA[株式会社という仕組みは、起業するときに何気なく選ぶ「器」のひとつに見えるかもしれません。けれど、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名ほどの会社になりました。

この先も大きくなるかどうかは、わかりません。以前「のれん分け」のような仕組みも考えたことがありましたが、会社という仕組みの柔軟さと、それを新しく作ることの大変さを比べると、何も再発明する必要はないのではないか、と考えるようになりました。子会社のような形はあり得るかもしれない、とは思っていますが、それも今は決めていません。

改めて思うのは、会社の規模は社長が決めるものではない、ということです。創業当時、私は少数精鋭で大きくしたくないとさえ思っていました。一方で、大きくしたいと思っても大きくできない会社もあるでしょう。会社の規模は、社会が決めるものなのではないでしょうか。社会に求められれば、自然と大きくなっていくのだと思います。

## コミュニティと株式会社のあいだ

ソニックガーデンは、同じビジョンに向かって進む仲間たちのコミュニティとしての組織でありつつ、資本市場でビジネスを成立させ、経済を循環させていく株式会社でもあります。

私にとって、どちらかではいけませんでした。両方を成立させることが大事だったと、今なら思えます。理想を掲げているだけで、現実社会に影響を及ぼせないようでは、希望がありません。一方で、めちゃくちゃ稼ぐことができても、それが「ありたい姿」とかけ離れていては、幸せとは言えない。両方が大事なのです。

株式会社という仕組みは、コミュニティである私たちが、社会と接続するために必要なプロトコルでした。コミュニティであり続けられるように、会社の仕組みを整えていくこと。それが経営の一つの仕事です。逆に、コミュニティを守ることができるなら、その仕組みは、いかようにでも変えていけるでしょう。

創業時には考えもしませんでしたが、上場やバイアウトといった選択肢も、まったく排除はしていません。ただし、それは経済的な出口戦略としてではなく、ここまで作ってきた会社のあり方を引き継いでいくための手段として、です。コミュニティを守れる選択であれば、形は問いません。

こうした新しい会社の形が、これから「ありたい姿」で起業しようとする人たちにとっての一つの希望になっていくと嬉しい。
]]>
      </description>
      <content:encoded>
        <![CDATA[株式会社という仕組みは、起業するときに何気なく選ぶ「器」のひとつに見えるかもしれません。けれど、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名ほどの会社になりました。

この先も大きくなるかどうかは、わかりません。以前「のれん分け」のような仕組みも考えたことがありましたが、会社という仕組みの柔軟さと、それを新しく作ることの大変さを比べると、何も再発明する必要はないのではないか、と考えるようになりました。子会社のような形はあり得るかもしれない、とは思っていますが、それも今は決めていません。

改めて思うのは、会社の規模は社長が決めるものではない、ということです。創業当時、私は少数精鋭で大きくしたくないとさえ思っていました。一方で、大きくしたいと思っても大きくできない会社もあるでしょう。会社の規模は、社会が決めるものなのではないでしょうか。社会に求められれば、自然と大きくなっていくのだと思います。

## コミュニティと株式会社のあいだ

ソニックガーデンは、同じビジョンに向かって進む仲間たちのコミュニティとしての組織でありつつ、資本市場でビジネスを成立させ、経済を循環させていく株式会社でもあります。

私にとって、どちらかではいけませんでした。両方を成立させることが大事だったと、今なら思えます。理想を掲げているだけで、現実社会に影響を及ぼせないようでは、希望がありません。一方で、めちゃくちゃ稼ぐことができても、それが「ありたい姿」とかけ離れていては、幸せとは言えない。両方が大事なのです。

株式会社という仕組みは、コミュニティである私たちが、社会と接続するために必要なプロトコルでした。コミュニティであり続けられるように、会社の仕組みを整えていくこと。それが経営の一つの仕事です。逆に、コミュニティを守ることができるなら、その仕組みは、いかようにでも変えていけるでしょう。

創業時には考えもしませんでしたが、上場やバイアウトといった選択肢も、まったく排除はしていません。ただし、それは経済的な出口戦略としてではなく、ここまで作ってきた会社のあり方を引き継いでいくための手段として、です。コミュニティを守れる選択であれば、形は問いません。

こうした新しい会社の形が、これから「ありたい姿」で起業しようとする人たちにとっての一つの希望になっていくと嬉しい。
]]>
      </content:encoded>
      <enclosure url="/rails/active_storage/blobs/proxy/eyJfcmFpbHMiOnsiZGF0YSI6MTI5NiwicHVyIjoiYmxvYl9pZCJ9fQ==--ab1b0ab4f8a4627cfcd067f9ebe6a5254505b5e2/2026-05-07-as-we-are.jpg" type="image/jpeg"/>
    </item>
    <item>
      <title>AIを組織で使うということ〜全社標準としてのClaude Code</title>
      <link>https://kuranuki.sonicgarden.jp/archives/36032</link>
      <dc:creator>
        <![CDATA[倉貫 義人]]>
      </dc:creator>
      <pubDate>Fri, 01 May 2026 00:02:00 +0900</pubDate>
      <category>
        <![CDATA[仕事と経営]]>
      </category>
      <guid isPermaLink="false">https://kuranuki-wp.sonicgarden.jp/?p=36032</guid>
      <description>
        <![CDATA[生成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)
]]>
      </description>
      <content:encoded>
        <![CDATA[生成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)
]]>
      </content:encoded>
      <enclosure url="/rails/active_storage/blobs/proxy/eyJfcmFpbHMiOnsiZGF0YSI6MTI5MywicHVyIjoiYmxvYl9pZCJ9fQ==--d80c14c7ebe8423030659edf0a6bbc340446a881/2026-04-28-claude-sg-v2.jpg" type="image/jpeg"/>
    </item>
    <item>
      <title>Findyさんに取材を受けました：徒弟制度と高卒採用、AI時代の若手育成</title>
      <link>https://kuranuki.sonicgarden.jp/archives/36031</link>
      <dc:creator>
        <![CDATA[倉貫 義人]]>
      </dc:creator>
      <pubDate>Sat, 25 Apr 2026 18:19:00 +0900</pubDate>
      <category>
        <![CDATA[活動の記録]]>
      </category>
      <guid isPermaLink="false">https://kuranuki-wp.sonicgarden.jp/?p=36031</guid>
      <description>
        <![CDATA[エンジニア向けサービスのFindyさんから取材を受け、ソニックガーデンの若手育成についての記事を掲載していただきました。

AIがコードを書く時代に、ソフトウェアの会社がどうやって若手を育てるのか。10年続けてきた中途採用のみのスタンスから若手採用へと舵を切り、徒弟制度を導入し、2026年4月には高卒採用にも踏み出した経緯と、いまの現在地について話してきました。

記事は以下のような構成になっています。

- ソニックガーデンが自分たちで若手育成を始めるまで
- 「マネージャーとメンバー」から「親方と弟子」へ
- AIがコードを書く時代でも、教え方は変わらなかった
- 先のことはわからない。だから目の前のことをやる

答えが見えない時代に、いまできる最善のことをやる。そんな姿勢を、丁寧にまとめていただきました。

関心のある方は、ぜひ読んでみてください。

ソニックガーデンが若手を育て始めて見えてきたもの。徒弟制度、高卒採用──正解のないAI時代のひとつの実践
https://findy-code.io/media/articles/special-interview-sonicgarden_inc
]]>
      </description>
      <content:encoded>
        <![CDATA[エンジニア向けサービスのFindyさんから取材を受け、ソニックガーデンの若手育成についての記事を掲載していただきました。

AIがコードを書く時代に、ソフトウェアの会社がどうやって若手を育てるのか。10年続けてきた中途採用のみのスタンスから若手採用へと舵を切り、徒弟制度を導入し、2026年4月には高卒採用にも踏み出した経緯と、いまの現在地について話してきました。

記事は以下のような構成になっています。

- ソニックガーデンが自分たちで若手育成を始めるまで
- 「マネージャーとメンバー」から「親方と弟子」へ
- AIがコードを書く時代でも、教え方は変わらなかった
- 先のことはわからない。だから目の前のことをやる

答えが見えない時代に、いまできる最善のことをやる。そんな姿勢を、丁寧にまとめていただきました。

関心のある方は、ぜひ読んでみてください。

ソニックガーデンが若手を育て始めて見えてきたもの。徒弟制度、高卒採用──正解のないAI時代のひとつの実践
https://findy-code.io/media/articles/special-interview-sonicgarden_inc
]]>
      </content:encoded>
      <enclosure url="/rails/active_storage/blobs/proxy/eyJfcmFpbHMiOnsiZGF0YSI6MTI5MSwicHVyIjoiYmxvYl9pZCJ9fQ==--448b21f06cc334b559e77d94ecaa0ec2ac11772e/2026-04-25-findy.jpg" type="image/jpeg"/>
    </item>
    <item>
      <title>「動けばいい」では、もったいない〜AI時代にプログラミングを学ぶ意味</title>
      <link>https://kuranuki.sonicgarden.jp/archives/36028</link>
      <dc:creator>
        <![CDATA[倉貫 義人]]>
      </dc:creator>
      <pubDate>Wed, 22 Apr 2026 14:01:00 +0900</pubDate>
      <category>
        <![CDATA[仕事と経営]]>
      </category>
      <guid isPermaLink="false">https://kuranuki-wp.sonicgarden.jp/?p=36028</guid>
      <description>
        <![CDATA[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
]]>
      </description>
      <content:encoded>
        <![CDATA[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
]]>
      </content:encoded>
      <enclosure url="/rails/active_storage/blobs/proxy/eyJfcmFpbHMiOnsiZGF0YSI6MTI4OCwicHVyIjoiYmxvYl9pZCJ9fQ==--334824ecd62094d29888e0ae118cab79ba7bdfa5/2026-04-21-good-soft.jpg" type="image/jpeg"/>
    </item>
    <item>
      <title>弟子の仕事は「見る」こと〜AI時代の「見て盗む」2.0</title>
      <link>https://kuranuki.sonicgarden.jp/archives/36027</link>
      <dc:creator>
        <![CDATA[倉貫 義人]]>
      </dc:creator>
      <pubDate>Mon, 20 Apr 2026 18:09:00 +0900</pubDate>
      <category>
        <![CDATA[思考メモ]]>
      </category>
      <guid isPermaLink="false">https://kuranuki-wp.sonicgarden.jp/?p=36027</guid>
      <description>
        <![CDATA[以前のブログで、育成に必要なのは[観察と自己決定だ](https://kuranuki.sonicgarden.jp/archives/34902)と書いた。親方が弟子のプロセスを見て、課題とフィードバックを渡すという話だった。

しかし「見る」が大事なのは、弟子にとっても同じだ。ただし向きが逆だ。親方が見るのは弟子のプロセス、弟子が見るのは親方のプロセスだ。

教えるとき、「説明→実践→フィードバック」で進めがちだ。一見まっとうだが、落とし穴がある。「お手本なし」で試させることになるのだ。特にAIの使い方や仕事の進め方には、確立された手本がない。

最近、エンジニア以外のメンバーにもAIを触ってもらっている。口で説明してもなかなか伝わらないが、画面を見せるとすぐ伝わる。百聞は一見に如かず、とはよく言ったものだ。これくらいでいいのか、こういう粒度でやり取りするのか、と具体が伝わる。

伝わっているのは成果物ではなく、プロセスの方だ。

弟子が見るべきも、まさにそのプロセスだ。最初は親方のコピーであるべきだ。同じやり方で同じ品質と生産性を出せてから、自己流を磨けばいい。

コピーのポイントは、見よう見まねではない。親方がその時々に何を考えているのか、思考プロセスごとコピーしようとすることだ。お客様との会話も、AIの使い方も、動作確認の方法も。見て、真似る。

「学ぶ」の語源は「真似ぶ」だと言われる。思考まで真似ようとすれば、とてつもない集中力がいる。それくらい真剣に「見る」ことが必要なのだ。

親方のほうから場を作ってやればいい。「2時間この案件に取り組むから横で見ておいて」と弟子を呼ぶ。それで十分に伝わる。教える側がまずやって見せる。それが遠回りに見えて、一番の近道なのだろう。

親方と弟子の「見る」は対になっている。親方が課題とフィードバックを渡し、弟子は思考プロセスを写し取る。双方向に機能することで、徒弟制度は回る。

そう考えると、弟子の一番の仕事は「見る」ことそのものだ。最初のうちは中途半端に仕事を振って試行錯誤させるより、親方の仕事を徹底的に観察・理解・再現させた方が、立ち上がりが早い。

このサイクルを回すほど、解像度も精度も上がっていく。それがトレーニングになる。

これは、昔ながらの「見て盗め」の発想だ。ただ古い「見て盗め」には欠点があった。熟練者の手が速すぎて、何をやっているか見えない。

AI時代では事情が違う。親方とAIの会話ログに、暗黙知が言語化されて残る。手が速すぎて見えなかった仕事も、弟子は後からAIで確認できる。

見て盗む2.0だ。AI時代だからこそ、むしろ効く学び方になっているのではないか。
]]>
      </description>
      <content:encoded>
        <![CDATA[以前のブログで、育成に必要なのは[観察と自己決定だ](https://kuranuki.sonicgarden.jp/archives/34902)と書いた。親方が弟子のプロセスを見て、課題とフィードバックを渡すという話だった。

しかし「見る」が大事なのは、弟子にとっても同じだ。ただし向きが逆だ。親方が見るのは弟子のプロセス、弟子が見るのは親方のプロセスだ。

教えるとき、「説明→実践→フィードバック」で進めがちだ。一見まっとうだが、落とし穴がある。「お手本なし」で試させることになるのだ。特にAIの使い方や仕事の進め方には、確立された手本がない。

最近、エンジニア以外のメンバーにもAIを触ってもらっている。口で説明してもなかなか伝わらないが、画面を見せるとすぐ伝わる。百聞は一見に如かず、とはよく言ったものだ。これくらいでいいのか、こういう粒度でやり取りするのか、と具体が伝わる。

伝わっているのは成果物ではなく、プロセスの方だ。

弟子が見るべきも、まさにそのプロセスだ。最初は親方のコピーであるべきだ。同じやり方で同じ品質と生産性を出せてから、自己流を磨けばいい。

コピーのポイントは、見よう見まねではない。親方がその時々に何を考えているのか、思考プロセスごとコピーしようとすることだ。お客様との会話も、AIの使い方も、動作確認の方法も。見て、真似る。

「学ぶ」の語源は「真似ぶ」だと言われる。思考まで真似ようとすれば、とてつもない集中力がいる。それくらい真剣に「見る」ことが必要なのだ。

親方のほうから場を作ってやればいい。「2時間この案件に取り組むから横で見ておいて」と弟子を呼ぶ。それで十分に伝わる。教える側がまずやって見せる。それが遠回りに見えて、一番の近道なのだろう。

親方と弟子の「見る」は対になっている。親方が課題とフィードバックを渡し、弟子は思考プロセスを写し取る。双方向に機能することで、徒弟制度は回る。

そう考えると、弟子の一番の仕事は「見る」ことそのものだ。最初のうちは中途半端に仕事を振って試行錯誤させるより、親方の仕事を徹底的に観察・理解・再現させた方が、立ち上がりが早い。

このサイクルを回すほど、解像度も精度も上がっていく。それがトレーニングになる。

これは、昔ながらの「見て盗め」の発想だ。ただ古い「見て盗め」には欠点があった。熟練者の手が速すぎて、何をやっているか見えない。

AI時代では事情が違う。親方とAIの会話ログに、暗黙知が言語化されて残る。手が速すぎて見えなかった仕事も、弟子は後からAIで確認できる。

見て盗む2.0だ。AI時代だからこそ、むしろ効く学び方になっているのではないか。
]]>
      </content:encoded>
    </item>
    <item>
      <title>技芸を「評価」することはできるのか〜目標管理からキャリブレーションへ</title>
      <link>https://kuranuki.sonicgarden.jp/archives/36025</link>
      <dc:creator>
        <![CDATA[倉貫 義人]]>
      </dc:creator>
      <pubDate>Tue, 14 Apr 2026 11:55:32 +0900</pubDate>
      <category>
        <![CDATA[仕事技芸論]]>
      </category>
      <guid isPermaLink="false">https://kuranuki-wp.sonicgarden.jp/?p=36025</guid>
      <description>
        <![CDATA[<p>本記事は、仕事を労働ではなく「技芸」として捉え直す「仕事技芸論」シリーズの記事です。 前回の記事の最後に、こう問いかけた。「育った先に何があるのか。技芸をどう認め、どう報いるのか。結果で測れないものを、組織としてどう扱う [&#8230;]</p>
<p><a class="btn btn-secondary understrap-read-more-link" href="https://kuranuki-wp.sonicgarden.jp/archives/36025">続きを読む&#8230;<span class="screen-reader-text"> from 技芸を「評価」することはできるのか〜目標管理からキャリブレーションへ</span></a></p>
]]>
      </description>
      <content:encoded>
        <![CDATA[
<p>本記事は、仕事を労働ではなく「技芸」として捉え直す「<a href="https://kuranuki.sonicgarden.jp/category/arts_and_crafts">仕事技芸論</a>」シリーズの記事です。</p>



<p><a href="https://kuranuki.sonicgarden.jp/archives/36006">前回の記事</a>の最後に、こう問いかけた。「育った先に何があるのか。技芸をどう認め、どう報いるのか。結果で測れないものを、組織としてどう扱うか」。今回はこの問いに向き合ってみたい。</p>



<div id="ez-toc-container" class="ez-toc-v2_0_82_2 counter-hierarchy ez-toc-counter ez-toc-custom ez-toc-container-direction">
<div class="ez-toc-title-container">
<p class="ez-toc-title" style="cursor:inherit">目次</p>
<span class="ez-toc-title-toggle"><a href="#" class="ez-toc-pull-right ez-toc-btn ez-toc-btn-xs ez-toc-btn-default ez-toc-toggle" aria-label="Toggle Table of Content"><span class="ez-toc-js-icon-con"><span class=""><span class="eztoc-hide" style="display:none;">Toggle</span><span class="ez-toc-icon-toggle-span"><svg style="fill: #999;color:#999" xmlns="http://www.w3.org/2000/svg" class="list-377408" width="20px" height="20px" viewBox="0 0 24 24" fill="none"><path d="M6 6H4v2h2V6zm14 0H8v2h12V6zM4 11h2v2H4v-2zm16 0H8v2h12v-2zM4 16h2v2H4v-2zm16 0H8v2h12v-2z" fill="currentColor"></path></svg><svg style="fill: #999;color:#999" class="arrow-unsorted-368013" xmlns="http://www.w3.org/2000/svg" width="10px" height="10px" viewBox="0 0 24 24" version="1.2" baseProfile="tiny"><path d="M18.2 9.3l-6.2-6.3-6.2 6.3c-.2.2-.3.4-.3.7s.1.5.3.7c.2.2.4.3.7.3h11c.3 0 .5-.1.7-.3.2-.2.3-.5.3-.7s-.1-.5-.3-.7zM5.8 14.7l6.2 6.3 6.2-6.3c.2-.2.3-.5.3-.7s-.1-.5-.3-.7c-.2-.2-.4-.3-.7-.3h-11c-.3 0-.5.1-.7.3-.2.2-.3.5-.3.7s.1.5.3.7z"/></svg></span></span></span></a></span></div>
<nav><ul class='ez-toc-list ez-toc-list-level-1 ' ><li class='ez-toc-page-1 ez-toc-heading-level-2'><a class="ez-toc-link ez-toc-heading-1" href="https://kuranuki-wp.sonicgarden.jp/archives/36025/#%E8%A9%95%E4%BE%A1%E3%81%A8%E3%81%AF%E6%A8%A9%E5%8A%9B%E3%81%A7%E3%81%82%E3%82%8B" >評価とは権力である</a></li><li class='ez-toc-page-1 ez-toc-heading-level-2'><a class="ez-toc-link ez-toc-heading-2" href="https://kuranuki-wp.sonicgarden.jp/archives/36025/#%E5%86%85%E7%99%BA%E7%9A%84%E5%8B%95%E6%A9%9F%E3%82%92%E5%AE%88%E3%82%8B" >内発的動機を守る</a></li><li class='ez-toc-page-1 ez-toc-heading-level-2'><a class="ez-toc-link ez-toc-heading-3" href="https://kuranuki-wp.sonicgarden.jp/archives/36025/#%E8%A9%95%E4%BE%A1%E3%81%AE%E3%81%AA%E3%81%84%E5%8D%81%E5%B9%B4" >評価のない十年</a></li><li class='ez-toc-page-1 ez-toc-heading-level-2'><a class="ez-toc-link ez-toc-heading-4" href="https://kuranuki-wp.sonicgarden.jp/archives/36025/#%E3%83%95%E3%83%A9%E3%83%83%E3%83%88%E3%81%AE%E9%99%90%E7%95%8C" >フラットの限界</a></li><li class='ez-toc-page-1 ez-toc-heading-level-2'><a class="ez-toc-link ez-toc-heading-5" href="https://kuranuki-wp.sonicgarden.jp/archives/36025/#%E7%9B%AE%E6%A8%99%E7%AE%A1%E7%90%86%E3%81%A7%E3%81%AF%E6%8A%80%E8%8A%B8%E3%82%92%E6%B8%AC%E3%82%8C%E3%81%AA%E3%81%84" >目標管理では技芸を測れない</a></li><li class='ez-toc-page-1 ez-toc-heading-level-2'><a class="ez-toc-link ez-toc-heading-6" href="https://kuranuki-wp.sonicgarden.jp/archives/36025/#%E5%BE%92%E5%BC%9F%E5%88%B6%E5%BA%A6%E3%81%A8%E3%82%AD%E3%83%A3%E3%83%AA%E3%83%96%E3%83%AC%E3%83%BC%E3%82%B7%E3%83%A7%E3%83%B3" >徒弟制度とキャリブレーション</a></li><li class='ez-toc-page-1 ez-toc-heading-level-2'><a class="ez-toc-link ez-toc-heading-7" href="https://kuranuki-wp.sonicgarden.jp/archives/36025/#%E5%85%A8%E5%93%A1%E3%81%A7%E3%81%AE%E3%82%B3%E3%83%B3%E3%82%BB%E3%83%B3%E3%82%B5%E3%82%B9" >全員でのコンセンサス</a></li><li class='ez-toc-page-1 ez-toc-heading-level-2'><a class="ez-toc-link ez-toc-heading-8" href="https://kuranuki-wp.sonicgarden.jp/archives/36025/#%E3%82%AD%E3%83%A3%E3%83%AA%E3%82%A2%E3%81%AF%E6%8E%A2%E7%B4%A2%E7%9A%84%E3%81%A7%E3%81%82%E3%81%A3%E3%81%A6%E3%81%84%E3%81%84" >キャリアは探索的であっていい</a></li><li class='ez-toc-page-1 ez-toc-heading-level-2'><a class="ez-toc-link ez-toc-heading-9" href="https://kuranuki-wp.sonicgarden.jp/archives/36025/#%E7%B5%90%E6%9E%9C%E3%82%88%E3%82%8A%E3%83%97%E3%83%AD%E3%82%BB%E3%82%B9%E3%82%92%E5%A4%A7%E4%BA%8B%E3%81%AB%E3%81%99%E3%82%8B" >結果よりプロセスを大事にする</a></li><li class='ez-toc-page-1 ez-toc-heading-level-2'><a class="ez-toc-link ez-toc-heading-10" href="https://kuranuki-wp.sonicgarden.jp/archives/36025/#%E5%8F%82%E8%80%83%E8%A8%98%E4%BA%8B" >参考記事</a></li></ul></nav></div>
<h2 class="wp-block-heading"><span class="ez-toc-section" id="%E8%A9%95%E4%BE%A1%E3%81%A8%E3%81%AF%E6%A8%A9%E5%8A%9B%E3%81%A7%E3%81%82%E3%82%8B"></span>評価とは権力である<span class="ez-toc-section-end"></span></h2>



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



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



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



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



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



<h2 class="wp-block-heading"><span class="ez-toc-section" id="%E5%86%85%E7%99%BA%E7%9A%84%E5%8B%95%E6%A9%9F%E3%82%92%E5%AE%88%E3%82%8B"></span>内発的動機を守る<span class="ez-toc-section-end"></span></h2>



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



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



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



<h2 class="wp-block-heading"><span class="ez-toc-section" id="%E8%A9%95%E4%BE%A1%E3%81%AE%E3%81%AA%E3%81%84%E5%8D%81%E5%B9%B4"></span>評価のない十年<span class="ez-toc-section-end"></span></h2>



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



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



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



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



<h2 class="wp-block-heading"><span class="ez-toc-section" id="%E3%83%95%E3%83%A9%E3%83%83%E3%83%88%E3%81%AE%E9%99%90%E7%95%8C"></span>フラットの限界<span class="ez-toc-section-end"></span></h2>



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



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



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



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



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



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



<h2 class="wp-block-heading"><span class="ez-toc-section" id="%E7%9B%AE%E6%A8%99%E7%AE%A1%E7%90%86%E3%81%A7%E3%81%AF%E6%8A%80%E8%8A%B8%E3%82%92%E6%B8%AC%E3%82%8C%E3%81%AA%E3%81%84"></span>目標管理では技芸を測れない<span class="ez-toc-section-end"></span></h2>



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



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



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



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



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



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



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



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



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



<h2 class="wp-block-heading"><span class="ez-toc-section" id="%E5%BE%92%E5%BC%9F%E5%88%B6%E5%BA%A6%E3%81%A8%E3%82%AD%E3%83%A3%E3%83%AA%E3%83%96%E3%83%AC%E3%83%BC%E3%82%B7%E3%83%A7%E3%83%B3"></span>徒弟制度とキャリブレーション<span class="ez-toc-section-end"></span></h2>



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



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



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



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



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



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



<h2 class="wp-block-heading"><span class="ez-toc-section" id="%E5%85%A8%E5%93%A1%E3%81%A7%E3%81%AE%E3%82%B3%E3%83%B3%E3%82%BB%E3%83%B3%E3%82%B5%E3%82%B9"></span>全員でのコンセンサス<span class="ez-toc-section-end"></span></h2>



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



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



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



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



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



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



<h2 class="wp-block-heading"><span class="ez-toc-section" id="%E3%82%AD%E3%83%A3%E3%83%AA%E3%82%A2%E3%81%AF%E6%8E%A2%E7%B4%A2%E7%9A%84%E3%81%A7%E3%81%82%E3%81%A3%E3%81%A6%E3%81%84%E3%81%84"></span>キャリアは探索的であっていい<span class="ez-toc-section-end"></span></h2>



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



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



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



<h2 class="wp-block-heading"><span class="ez-toc-section" id="%E7%B5%90%E6%9E%9C%E3%82%88%E3%82%8A%E3%83%97%E3%83%AD%E3%82%BB%E3%82%B9%E3%82%92%E5%A4%A7%E4%BA%8B%E3%81%AB%E3%81%99%E3%82%8B"></span>結果よりプロセスを大事にする<span class="ez-toc-section-end"></span></h2>



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



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



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



<h2 class="wp-block-heading"><span class="ez-toc-section" id="%E5%8F%82%E8%80%83%E8%A8%98%E4%BA%8B"></span>参考記事<span class="ez-toc-section-end"></span></h2>



<ul class="wp-block-list">
<li><a href="https://kuranuki.sonicgarden.jp/archives/34867">アジャイル思考でつくるエンジニア組織の人事制度〜「評価」から「期待のすり合わせ」へ</a></li>



<li><a href="https://kuranuki.sonicgarden.jp/archives/35997">自立した人が「ここがいい」と思える会社〜人事の専門家に話した経営スタンス</a></li>



<li><a href="https://kuranuki.sonicgarden.jp/archives/25707">個人評価をなくした会社の1on1面談の仕方「すりあわせ」</a></li>



<li><a href="https://kuranuki.sonicgarden.jp/archives/34416">キャリア自律の考え方〜キャリアかビジョンか</a></li>



<li><a href="https://kuranuki.sonicgarden.jp/archives/30599">予測型マインドセットと適応型マインドセットの違い、アジャイル思考の本質</a></li>



<li><a href="https://jinjibu.jp/article/detl/tonari/3600/">&#8220;評価&#8221;ではなく&#8221;期待&#8221;をする　目標管理をしないクラシコムの「キャリブレーション」</a></li>
</ul>



<p></p>
]]>
      </content:encoded>
      <enclosure url="/rails/active_storage/blobs/proxy/eyJfcmFpbHMiOnsiZGF0YSI6MTI3MywicHVyIjoiYmxvYl9pZCJ9fQ==--f47e8ff2020de18394661d0f0004fc60f6dcf452/2026-04-13-craft-reward.jpg" type="image/jpeg"/>
    </item>
    <item>
      <title>エージェントで仕事を始めて変わったこと：降伏してから見えた景色</title>
      <link>https://kuranuki.sonicgarden.jp/archives/36023</link>
      <dc:creator>
        <![CDATA[倉貫 義人]]>
      </dc:creator>
      <pubDate>Sat, 11 Apr 2026 15:04:25 +0900</pubDate>
      <category>
        <![CDATA[思考メモ]]>
      </category>
      <guid isPermaLink="false">https://kuranuki-wp.sonicgarden.jp/?p=36023</guid>
      <description>
        <![CDATA[<p>AIエージェントを使い始めて、仕事のやり方が変わった。 チャットの時代は、AIは頭だけの存在だった。考えてはくれるが、手は動かしてくれない。エージェントは違う。手も動かしてくれる。しかも、優秀な手だ。なんだったら、頭もい [&#8230;]</p>
<p><a class="btn btn-secondary understrap-read-more-link" href="https://kuranuki-wp.sonicgarden.jp/archives/36023">続きを読む&#8230;<span class="screen-reader-text"> from エージェントで仕事を始めて変わったこと：降伏してから見えた景色</span></a></p>
]]>
      </description>
      <content:encoded>
        <![CDATA[
<p>AIエージェントを使い始めて、仕事のやり方が変わった。</p>



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



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



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



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



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



<p>閑話休題。</p>



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



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



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



<p>車の運転に似ている気がする。</p>



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



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



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



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



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



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



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



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



<p>AIエージェントも、車と同じ感覚でいる。怖さはあるが、降伏した先に、思っていたのとは違う景色がある。</p>
]]>
      </content:encoded>
    </item>
  </channel>
</rss>
