「AIと働く人」と「AIと働く組織」の違い - AIフルーエンシーとトークン資本から考える、2つのAI協働

グロースエクスパートナーズグループのリレーブログ企画6日目です。5日目はAIエージェントでdocxを読み解くためのDocker環境構築でした。まだご覧になっていない方は、ぜひそちらもチェックしてみてください！

生成AIの活用は、単なる作業代行から、思考支援や判断支援を含む「AIとの協働」へと広がっています。AnthropicのAIフルーエンシー（AI Fluency）は、単にAIを利用することではなく、人とAIが協働しながら仕事を進める力を指します。

一方で「AIと協働する個人」が増えても「AIと協働する組織」にはならなそう、ということも分かってきました。サティア・ナデラが提唱したトークン資本（Token Capital）は、業務を通じてAIを育て続けるような仕組みの必要性を示しています。

本稿では、AIフルーエンシーとトークン資本という二つの概念を紹介しながら、「AIと働く人」と「AIと働く組織」の違いについて考えていきます。

クラウドが開発と運用をつないだように、AI駆動開発は要件定義と実装をつなぐのか

AI駆動開発によって、システム開発の未来はどうなるのか。そうした議論が増えてきています。

私の著書では「ITの歴史から学ぶ」ことをテーマにしてきました。そこで本記事では、過去の技術変化を手がかりに、AI駆動開発の未来を考えてみます。

特に注目したいのは、クラウドと生成AIの技術的な共通性です。クラウドは、インフラ作業を操作可能にすることで、開発と運用の関係を変えました。同じように、生成AIは、言語を使った作業を操作可能にすることで、要件定義と実装の関係を変えるかもしれません。

本記事では、クラウドの歴史を振り返りながら、AI駆動開発が「要件定義と実装のつながり」をどう変えるのかを考えます。

AI駆動開発で、なぜミドルエンジニアは不安になるのか ── AIによる分業の終わりと始まり

AI駆動開発が「使える」となってきたことで、20代後半から30代中盤のミドルエンジニアが疲弊しているという話を聞きました。たしかに、エンジニアの中でも「AIは楽しい・これでもっと良くなる」という意見と「不安だ・これからどうなるのだろう」という意見に分かれているようです。

私の周りでは、特にベテランが楽しんで、ミドルが不安になっているような構図を感じています。

この記事では、システム開発における30年間の分業と統合の歴史を振り返りつつ、それぞれの世代が何を経験してきたのかを整理します。そのうえで、AI駆動開発が既存の分業をどのように統合しようとしているのかを見ていきます。そして、これがベテランとミドルの違いに、どのように影響しているのかを考えます。

最後には、AI駆動開発が「分業の終わり」ではなく、AIを前提にした「新たな分業の始まり」でもある、という見方を提示します。

AIは「思考支援モード」で使う―組織力を高めるガイド型AIエージェントとは

仕事の中で生成AIが使われるようになり「見た目は整っているが中身がズレてて、受け手に再作業の負担を押しつける成果物」が増えたと感じる人も多いでしょう。これを「ワークスロップ」と呼びます。

ワークスロップは、AIが悪いのではなく、AIを使う側が、仕事の中身を十分に理解していないことに起因します。準備が曖昧なままAIに依頼し、生成物をきちんとに評価しないまま流してしまえば、どれだけ見た目が整っていても、成果物としては十分ではありません。

つまり、ワークスロップとは、人の「仕事に対する構造理解の強弱」がAIによって増幅された結果だといえます。AIは熟練者にとっては仕事を効率化する道具になりますが、仕事の経験が浅い人にとっては、かえって「それっぽい成果物」を生み出しやすい道具になってしまう。

だからこそ必要なのは、AIに単に作業を代行させることではなく、人間が仕事をどう準備し、どう評価し、どう調整するかを支えることです。言い換えれば、AIを使う側に適度な思考の負荷をかけ、仕事の構造に沿って考えられるようにすることが重要になります。

この記事では、まずワークスロップの問題を、仕事の進め方の観点から整理します。そのうえで、AIを人の思考を支える「思考支援モード」として使う方法を述べ、さらに固有業務では、その支援を仕組みとして埋め込む「ガイド型AIエージェント」という考え方までつなげていきます。

クライアントに「便利に使われる人」から「信頼される人」になるために考えること

クライアントとの日常業務は、特に問題なく進んでいる。
必要な情報共有もされ、打ち合わせでは意見交換も行われる。雑談もするし、関係が悪いわけでもない。

ところが、新しい取り組みを始めたいときや、トラブルが起きたとき、方針や判断が必要な場面になると、最初に声がかからない。
別の誰かに先に相談が行き、あとから共有される。

もしかすると、あなたはクライアントにとって「便利に使える人」であっても「信頼できる人」ではないのかもしれません。

このブログは、グロースエクスパートナーズ Advent Calendar 2025の14日目です。

マッチョスクラム問題とスクラム教問題を解決する「別の強さ」について

スクラムは、アジャイルを実現する標準的なフレームワークとして広く普及しています。とはいえ、以下のような「スクラムの理想」を押し付けすぎると、うまくいかないことがあります。

• チームは自己管理し、改善し続けなくてはならない
• 全員が積極的にアウトカムにコミットする必要がある
• スクラムガイドに従っていくべきだ

これらは、表面的には「正しい」ことですが、行き過ぎれば、チームやメンバーを苦しめることがあります。そこで、この問題に「マッチョスクラム問題」と「スクラム教問題」という名前をつけて整理し、その解決策を考えてみました。

フルスタックエンジニアの終焉？生成AI後の未来を産業史から考える

生成AIによって、エンジニアがどう変わっていくのか？という、さまざまな論考が生まれているので参戦してみます。

98年からエンジニアをしている僕からすれば「開発生産性の向上」というのは常に提示されきたテーマで、生成AIは大きなジャンプではあったものの、産業の進化としては正常な流れなのかな、と思います。

というわけで、よくある「一般的な産業の進化はこうだったから、IT業界もこうなるはず」という感じの論考をChatGPTにまとめてもらいました。