mtx2s’s blog

エンジニアリングをエンジニアリングする。

周囲から頼られ、「優秀だ」と評されるソフトウェアエンジニアの6つのタイプ

多くの組織には、確かな実力を備え、周囲から頼られ、一目（いちもく）置かれるソフトウェアエンジニアがいる。組織の中でも限られた存在だ。純粋な技術力の高さだけでなく、仕事を通じて周囲に貢献し、確かな信頼を獲得している人物である。

“他者から頼られる”というのも、優れたエンジニアの一つの表れ方だろう。

たとえば、困っているといつも助けてくれる人。難易度の高い問題を解決してくれる人。チームや組織の能力を引き上げてくれる人。事業やプロジェクトの意思決定を技術面から支えてくれる人など。誰から、どのような場面で頼られているかは、それぞれ異なる。

彼らに一貫しているのは、扱うスコープこそ違えど、周囲にインパクトをもたらし、その結果として信頼を得ている点である。与えられた責務を着実に果たすだけでなく、周囲や組織にも貢献する人物だ。

それでは、彼らはどのようなスコープを担い、どのようなコンピテンシーを有しているのだろうか。そして、AI時代にそれはどう変わるのか。本記事では、他者から頼られるタイプの優れたエンジニアを6つに分類し、考察する。

なお、ここで扱う“優れたエンジニア”は、あくまでも“他者から頼られるタイプ”に限定している。優秀さそのものを網羅的に定義しようとしているわけではない。

本記事のAI音声解説版をポッドキャストで“準備中”
🎧ぜひ番組「FLOW(er)ラジオ」をフォローしてお待ちください！

他者から頼られるタイプの優れたエンジニアは、誰から何を頼られているのか

私がこれまで観察してきたなかで、優秀だと言われるエンジニアの多くは、成果を通じて周囲の信頼を獲得し、頼られる存在になっていた。もちろん、「頼られること」が優秀さのすべてではない。それでも、優秀さが周囲との関係に表れる一つの典型的な形であった。

そのため、本人と他者との関係性によって、評価の観点に違いが出る。それはそうだろう。優れたアーキテクチャを描いたところで、他職種のメンバーが「素晴らしい」と褒めてくれることなどない。そこで見られるのは、自分たちが抱える課題や目標にどう影響を与え、価値をもたらすかである。

つまり、優秀さは、純粋な「技術力の高さ」だけで評されるものではない。能力を成果へ結びつけ、関係する個人や組織・集団に対し、継続的に貢献した結果として、「頼られる」という関係にも表れるのだ。本記事では、そうした優秀さの表れ方に焦点を当てている。

そこで、エンジニアとの典型的な関係性に基づいて、評価の側面を6つに分類した。それぞれの立場から、どのような貢献が評価され、どのようなエンジニアが頼りになる存在と見なされるのか。私の観察に基づく主観的な整理であるが、順に見ていこう。

誤解しないで欲しいのだが、これらは互いに排他的な分類ではない。一人のエンジニアが、複数のタイプにまたがることもある。

① チーム内のエンジニアに頼られるエンジニア

チーム内で評価されるのは、チームの課題を解決し、日々の開発を前進させるエンジニアである。さらに、チームの仕事をより高い水準へと引き上げてくれる。

  • 担当システムの構造や背景を深く理解しており、変更時の影響範囲を正確に見抜く。
  • コード以外の技術レイヤーにも精通しており、インフラやミドルウェアが絡む複雑な障害の特定や、システム全体のチューニングを主導できる。
  • 自分のタスクが行き詰まった時に、いつでも親身になって助けてくれる。
  • 新しい技術や開発手法を、誰もが扱える仕組みに落とし込み、チームの開発効率や品質を高めてくれる。
  • 設計や方針の議論において、他とは異なる視点や発想から意見を出し、その場にブレイクスルーをもたらしてくれる。

ここで求められるのは、突出した技術力や深い専門性だけではない。自らが得た知見を、皆で活用できる仕組みに変える力も評価される。物事を多角的に捉え、チームに新たな視点をもたらす力も重要だ。

こうした存在は、「このチームなら困難も乗り越えられる」という安心感を周囲にもたらす。日々共に働くなかで、その思考や仕事ぶりにも触れられるため、憧れの対象やロールモデルにもなりやすい。

② 社内他チームのエンジニアに頼られるエンジニア

チームの境界を越えた連携では、技術課題の解決をリードし、存在感を示すエンジニアが高い評価を得る。

  • 複数チームが関わる複雑なアーキテクチャや設計を整理し、全体の方向性をリードしてくれる。
  • チーム間での機能連携や共通開発を行う際、チーム外のコードであっても、その背景を深く理解したうえで、適切な変更を加えられる。
  • 組織全体が扱う開発環境を改善・進化させ、全体の開発効率と品質を底上げしてくれる。
  • 複数システムにまたがる障害でも、全体を俯瞰してチームを越えた調査を主導し、真の原因を迅速に突き止めてくれる。

ここで評価されるのは、複数のシステムやチームを横断して理解する力だ。自チームの担当領域だけに閉じず、関連するシステムや各チームの背景・制約まで捉える。その理解に基づいて、チーム間の依存関係を整理する。そして、全体最適の設計や共通の仕組みを形にし、問題を解決へと導いていく。

こうしたエンジニアは、チームの垣根を越えて頼られ、組織横断の技術的な相談役となっている。

③ エンジニアリングマネージャーに頼られるエンジニア

EMが頼るのは、チームを技術面でリードするだけでなく、判断の難しい局面で対等に意見を交わし、技術的な方向性を示してくれるエンジニアだ。

  • たとえばレガシーシステムの刷新など、技術的な不確実性が高く困難なプロジェクトであっても安心して任せられ、自走して確実に解決まで導いてくれる。
  • 判断の難しい技術的な局面でも、トレードオフを明確にしたうえで、進むべき現実的な方向性を示してくれる。
  • 現場の頑張りや運用に依存していた課題に対し、自分の責務を越えた領域であっても自律的に解決策を検討し、的確な提案をしてくれる。

彼らは、自らが担う責務の範囲にとどまらず、より上位の課題にも遠慮なく踏み込む。高い技術力や問題解決力を持ちながら、俯瞰的な視点からチームや組織全体の課題にも関心を向けている。そうして、周囲やEMを巻き込みながら、技術や仕組みによって解決へ導いていく。

こうしたエンジニアは、EMにとって単なる一人のメンバーではない。技術面からチームを共に導くパートナーであり、「右腕」的存在である。

④ 他職種の社員に頼られるエンジニア

他職種のメンバーが頼りにするのは、ユーザーやビジネスの事情も踏まえて、現実的な解決策を一緒に考えられるエンジニアである。技術的な都合だけを一方的に押し付けたりはしない。

  • 技術的な背景や仕組みを、専門知識がなくても理解できる言葉で分かりやすく説明してくれる。
  • 単に「できる、できない」の回答にとどまらず、技術的な制約を踏まえたうえで、実現可能なアプローチや代替案を提案してくれる。
  • 企画や仕様の検討段階において、技術的な観点から新たな気づきを与え、生み出すプロダクトの価値を高めてくれる。

彼らが果たすのは、技術と非技術の間をつなぐ役割だ。技術的な背景や制約をエンジニア以外にも理解できる言葉へ翻訳し、実現可能なアプローチや代替案を示す。さらに、企画や仕様の検討段階から技術的な観点を持ち込むことで、プロダクトの価値や意思決定の質を高める。

結果として、こうしたエンジニアの活躍が、組織内でのエンジニアリングのプレゼンスを高めている。エンジニアリングが、事業やプロダクトの価値を高める存在として認識されているのだ。

他職種の社員にとって、彼らは単なる実装の担い手ではない。サービスやプロダクトを共につくるパートナーとして信頼され、真っ先に相談を持ちかけられる存在である。

⑤ 経営者に頼られるエンジニア

経営者にとって、自社の技術的な状況を正しく伝え、経営の意思決定を支えてくれるエンジニアの存在は心強い。とりわけ、エンジニアとしての背景を持たない経営者にとって、彼らが果たす役割は大きい。

  • 技術的な投資判断について相談でき、技術を事業成長につなげる方法を提案してくれる。
  • 全社的な技術課題を構造的に整理し、目指す組織像と、そこへ至る技術戦略やロードマップを明確に示してくれる。
  • 経営方針や事業戦略をエンジニアリングのコンテキストへ正しく翻訳し、目標達成に向けて組織の実行力を最大化してくれる。

彼らが担うのは、経営戦略を技術戦略と実行へつなぐ役割だ。技術面でのビジョンを示し、現状とのギャップを明らかにして、技術戦略とロードマップを描く。さらに、その実行を自らリードし、最後までやり切る。

その結果、技術組織や開発環境が整い、社内のエンジニアたちが能力を十分に発揮できるようになる。

技術面から経営の意思決定を支え、事業の方向性にも影響を与える。そこまで信頼されたエンジニアは、経営者の「右腕」*1と呼ばれるようになる。

⑥ 社外のエンジニアに頼られるエンジニア

彼らは、エンジニアが日々直面する課題に対して、解決策や新たな視点を継続的に提供する存在だ。組織の枠を越えて多くのエンジニアから頼られ、その知見や成果物が広く参照されている。

  • 多くのエンジニアが現場で直面する課題を解決するOSSや開発ツールを提供し、社外の開発コミュニティへ広く貢献している。
  • 自身の深い実践や検証に基づく技術記事・書籍の執筆や登壇を通じて、多くのエンジニアが実務で活用できる質の高い知見を発信している。

彼らが行うのは、自らの知識や経験、アイデアを、他者が活用できる形へと変えることだ。個別の課題から得た知見を汎化し、言葉や成果物として公開する。その過程や、公開後に寄せられるフィードバックからも学ぶ。実践と発信を繰り返しながら、知見を磨き続ける。

その問題設定や考え方、成果物が広く認知されるにつれ、技術コミュニティに新たな議論や実践が生まれる。それらは、さらに新たな手法や成果物へとつながっていく。こうして、技術コミュニティにおける知識や実践の発展を牽引する存在となる。

エンジニアがもたらすインパクト ＝ スコープ × コンピテンシー

前節では、エンジニアが組織やコミュニティにもたらす価値、すなわち「インパクト」の具体像を、6つの立場から見てきた。

そのインパクトは、担う「スコープ」と、発揮する「コンピテンシー」の組み合わせに大きく左右される*2。そこで本節では、6タイプのエンジニアが、どのようなスコープを担い、どのようなコンピテンシーを発揮するのかを考察する。

スコープとは、その人が担う職務と責任の範囲である。ジョブディスクリプションに記される内容と言ってもよい。担う役割や役職によって、一定の範囲が定められやすい。ただし、日本ではスコープが明示されないことも多い。自ら役割を広げる人もいれば、狭く捉える人もいる。

コンピテンシーは、「ハイパフォーマーに共通して見られる行動特性」といった言われ方をする。少々わかりにくい。知識やスキル、経験といったその人の有する能力は、使わなければ宝の持ち腐れだ。それらを駆使し、成果に結びつける再現性のある思考や行動のパターン。これこそが、コンピテンシーである。

それでは、6タイプのエンジニアが持つスコープとコンピテンシーを考察してみよう。比較には、書籍『ITエンジニアの転職学』内のフレームワークを用いることにした。

www.kodansha.co.jp

6タイプのエンジニアが担うスコープを2軸で捉える

ここでは、6タイプのエンジニアが担うスコープを、2つの軸にプロットする。

縦軸は「どのような課題を解くか」を表す。上側はユーザー・事業・組織課題、下側は技術課題である。横軸は「どのように成果を生み出すか」を表す*3。左側は自らの専門性や成果物による貢献、右側は他者や組織を動かすことによる貢献である。

こうして眺めてみると、主に社外へ影響を与える⑥（社外の～）以外は、全体的に中央から右側に分布していることが分かる。他者から頼られ、「優れている」と評されるエンジニアは、自分一人の直接的な貢献に閉じず、リーダーシップを発揮し、他者や組織を通じてインパクトを広げているということだ。

上下方向については、どちらにも活躍の場がある。ユーザー・事業・組織課題を解くことも、技術課題を解くことも、優れたエンジニアとして評価される。

ただし、右上に配置された⑤（経営者に～）は、CTOやエンジニアリングVPに求められる役割とも大きく重なる。これらの役職は一般的に、エンジニアリングマネジメントのキャリアパス上に位置づけられる*4*5。つまり、優れたエンジニアであると同時に、エンジニアリングマネジメント職でも高く評価される人物像である。

そして、特にCTOは、スタッフプラスエンジニアとしてのICキャリアからも到達し得る。どちらの経路をたどったかによって、組織寄りか技術寄りか、そのリーダーシップの重心も変わるのだろう。

⑥（社外の～）のスコープは、その人の専門性による。図では技術課題を専門とする場合をイメージして下側をスコープとした。組織課題を専門とするなら、もちろん上側にスコープを持つことになる。

出典: James Stanier (著), 風間 勇志 (翻訳), 高口 太朗 (翻訳) 『シニアエンジニアリングリーダーのしごと ―組織を導き、育てる力を磨く』オライリー・ジャパン, 2026年5月20日, 「1.1.1 並行するキャリアパス」内の表を参考に筆者が作成

6タイプのエンジニアが発揮するコンピテンシーを6つの軸から捉える

次に、エンジニアの行動を6つの能力軸*6から捉え、6タイプごとにどの能力が強く表れているかを整理する。能力の組み合わせや発揮のされ方を眺めることで、それぞれのコンピテンシーが見えてくるはずだ。

表中の「◎」は特に強く、「○」は比較的強く、その能力の発揮が観察・評価されることを示す。一方、「—」は、その能力が発揮されないことを意味しない。そのタイプでは表立って観察されにくく、評価の中心にもなりにくい能力である。

6タイプのエンジニアすべてに共通するのは、「2. 専門性の深さと広さ」であるが、その表れ方はタイプによって異なる。専門性は、「◎」や「○」が付いた他の能力を発揮する土台として機能するからだ。

そうして専門性によって支えられる能力の重心が、①から⑤までで少しずつ異なる。その違いが、表にもよく表れている。

エンジニアリング現場に近い①（チーム内の～）や②（他チームの～）では、「1. 設計力・実装力」が強く表れる。ただし、①で評価される行動はテックリード*7に、②で評価される行動はアーキテクト*8に期待されるものと近い。前者は主にチームを対象に、技術的な方向を定め、実行を導く。後者は、複数のチームやシステムにまたがる重要な技術領域を対象に、その方向性や品質に責任を持つ。ただし、アーキテクトであれば、②の「1. 設計力・実装力」は、「○」より「◎」であって欲しいところか。

③（EMに～）は、①（チーム内の～）と②（他チームの～）の特徴を併せ持つ。だがこれは、パートナーとするEMが担うスコープにも左右される。単一のチームを担うEMであれば①に近く、複数のチームを統括するエンジニアリングディレクターであれば②にも近づく。今回の整理は、比較的後者に寄っている。

④（他職種の～）と⑤（経営者に～）を見てみると、やはり「5. 事業・顧客貢献」が特に強く出ている。両者の大きな違いは、「4. 組織貢献」に対する評価だ。

④で「4. 組織貢献」が「—」となるのは、ここでの組織貢献を、開発組織の能力や仕組みを高める行動として捉えているためだ。④では、そうした行動よりも、技術を事業や顧客の価値へつなぐ行動が直接評価される。

⑤で評価される能力は、CTOやエンジニアリングVPに求められる能力と大きく重なる。ICのキャリアパスでは、経営幹部のスコープを補完するスタッフプラスの「右腕」アーキタイプに近い。

⑥（社外の～）では、「6. 情報発信・プレゼンス」が際立つ。専門性を言葉や成果物へ変換し、組織の外へ届けることでインパクトを生み出すからだ。「1. 設計力・実装力」の評価は、扱う領域によって変わり得る。それでも、その活動の鍵を握るのが「2. 専門性の深さと広さ」であることに変わりはない。

EMに頼られるエンジニアと、EMには共通点がある

ここで少し趣向を変えて、EMのスコープとコンピテンシーも見てみよう。

分析に使用したフレームワークの出典元である書籍『ITエンジニアの転職学』には、年収1,000万円以上のEMを分析した結果が掲載されている*9。もちろん、高収入だからといって、優れたEMであるとは限らない。ここでは、このデータを比較のための参考材料として用いる。

このデータを参考に、スコープとコンピテンシーを書き出すと、下図のようになる。

出典: 赤川 朗 著『ITエンジニアの転職学 2万人の選択から見えた、後悔しないキャリア戦略』講談社, 2025年, 図2-1と図2-6を参考に筆者が作成

スコープを見ると、EMと③（EMに～）や⑤（経営者に～）には重なる領域が多い。両者は異なる役割を担いながらも、チームや組織を前進させるミッションを共有し、互いを補完するパートナーだからだ。

コンピテンシーにも共通点が多い。特に、「3. 推進力・プロジェクト貢献」と「4. 組織貢献」が強く表れる点は共通している。

特に③との近さからは、EMから評価されるエンジニアと、高収入層のEMとの間に、能力面での親和性が見えてくる。前者がエンジニアリングマネジメント職へ移る際には、それまで培った能力を活かしやすい。後者もICへ戻れば、③タイプのエンジニアとして能力を発揮しやすいのかもしれない。

もっとも、EMがICへ戻る動機は、③タイプとして活躍したいからではないだろう。どちらかと言えば、①（チーム内の～）や②（他チームの～）を念頭に置いたキャリアチェンジが多いように思える。EMと③の間に能力面での親和性があっても、本人が望む役割は別である。

AI時代のエンジニアは何が変わり、何が変わらないのか

AI時代を迎えた今、活躍するエンジニアのコンピテンシーには、どのような変化が起きるのだろうか。6つの能力軸ごとに整理してみよう。

  1. 設計力・実装力: 重心が変わる。
    • 単純な量の側面で言えば、設計や実装は、AIによってコモディティ化し、相対的な価値が下がる。
    • よりエンジニアに求められるのは、“優れたUX”や、“その実現を支え、継続的かつ安全に進化させるための構造”を見極める力ではないか。
    • さらに、AIによる生成物の妥当性を判断し、一貫したシステムへ統合する力が求められる。
  2. 専門性の深さと広さ: 重心が変わる。
    • AIは、膨大な情報量・知識量を有している。しかし、AI自身がそれを適切に使いこなせるわけではない。
    • AIが現実世界の事情や制約のすべてにアクセスできるわけでもない。そこには、言語化されていない暗黙知も含まれる。
    • だからこそ、エンジニアには、膨大な選択肢から最適なアプローチを導き出す専門性の深さと広さが問われる。
  3. 推進力・プロジェクト貢献: 重要性が増す。
    • プロジェクトは、初期に大きな不確実性を抱え、実行と学習を通じてそれを減らしていく営みである。
    • その過程には、トレードオフを伴う意思決定や、関係者間の調整と合意形成が数多く含まれる。AIによる加速で、こうした頻度も高まる。
    • こうした意思決定を恐れず大胆に舵を切るリーダーシップが求められる。
  4. 組織貢献: 重要性が増す。
    • 従来通り、チームや組織全体の成果を底上げし、組織の成長に寄与する力が求められるが、その足場がAIの登場で変化し続けている。
    • 個々人がそれに追随するだけでは、タスク単位での個人間の処理速度の差が広がるだけである。それでは組織としての成果につながらない。
    • 評価されるのは、自分だけがAIを巧みに使う人ではない。チーム全体や組織全体が安全かつ効果的に使える仕組みを作り、変化する環境に適応させられる人である。
  5. 事業・顧客貢献: 重要性が増す。
    • AIによって加速したプロダクト開発では、職種ごとの分業はハンドオフによる時間的・文脈的ロスが大きくなる。
    • したがって、チームは互いの専門性を越えて協働する真のクロスファンクショナル性が求められる。
    • エンジニアは事業や顧客を深く知り、「なぜ、何を作るか」に積極的に関わり、デリバリー結果の価値を高めることに注力する。
  6. 情報発信・プレゼンス: 重要性は変わらない。
    • 重要性は変わらないが、この能力を発揮するためのスキルや専門性は、より高度になる。
    • AIによって、「アウトプットの民主化」のような状況が起きているからだ。
    • このコモディティ化から抜け出してプレゼンスを示すには、AIを使っただけでは真似できない、自身のリアルな実践に根ざした独自性が不可欠になる。

以上のように、各能力の使われ方や重心、要求水準には変化が表れはじめている。これは、私自身の実感でもある。

しかし、今回整理したエンジニアの6タイプと、それぞれに見られるコンピテンシーの基本的なパターンは、おそらく変わらないだろう。

すべての能力を等しく高めることは困難だからこそ、自分はどのスコープで活躍するのか焦点を定めたい。そのスコープにおける関係性の中で、どの能力を伸ばすべきかを考えることも、AI時代のキャリアを描く一つの方法となるだろう。

◇　◇　◇　◇　◇

最後に、少しだけ拙著を紹介したい。

『チームの力で組織を動かす』では、ソフトウェア開発を加速するためのチーム設計・組織設計について体系的に解説している。この記事が「優れたエンジニアとはどのような人物か」を個人の側から考えたものだとすれば、本書は、エンジニアが力を発揮できる組織をどうつくるかを考えたものでもある。興味を持っていただけたなら、ぜひ手に取ってみてほしい。

gihyo.jp

参考文献

*1:Will Larson (著), 増井 雄一郎 (解説), 長谷川 圭 (翻訳)『スタッフエンジニア　マネジメントを超えるリーダーシップ』日経BP, 2023年5月3日, 第1章内「スタッフエンジニアの典型」より

*2:James Stanier (著), 風間 勇志 (翻訳), 高口 太朗 (翻訳) 『シニアエンジニアリングリーダーのしごと ―組織を導き、育てる力を磨く』オライリー・ジャパン, 2026年5月20日, 「1.3 コンピテンシー」より

*3:赤川 朗 (著)『ITエンジニアの転職学 2万人の選択から見えた、後悔しないキャリア戦略』講談社, 2025年10月24日, 第2章内「ITエンジニアの８つのキャリアパスと年収別能力イメージ」より

*4:James Stanier (著), 風間 勇志 (翻訳), 高口 太朗 (翻訳) 『シニアエンジニアリングリーダーのしごと ―組織を導き、育てる力を磨く』オライリー・ジャパン, 2026年5月20日, 「1.1.1 並行するキャリアパス」より

*5:Will Larson (著), 増井 雄一郎 (解説), 長谷川 圭 (翻訳)『スタッフエンジニア　マネジメントを超えるリーダーシップ』日経BP, 2023年5月3日, 第1章内の図「エンジニアリングのキャリアラダーにおける２本の路線」より

*6:赤川 朗 (著)『ITエンジニアの転職学 2万人の選択から見えた、後悔しないキャリア戦略』講談社, 2025年10月24日, 第2章内「6つの能力定義」より

*7:Will Larson (著), 増井 雄一郎 (解説), 長谷川 圭 (翻訳)『スタッフエンジニア　マネジメントを超えるリーダーシップ』日経BP, 2023年5月3日, 第1章内「スタッフエンジニアの典型」より

*8:Will Larson (著), 増井 雄一郎 (解説), 長谷川 圭 (翻訳)『スタッフエンジニア　マネジメントを超えるリーダーシップ』日経BP, 2023年5月3日, 第1章内「スタッフエンジニアの典型」より

*9:赤川 朗 (著)『ITエンジニアの転職学 2万人の選択から見えた、後悔しないキャリア戦略』講談社, 2025年10月24日, 第2章内「ITエンジニアの８つのキャリアパスと年収別能力イメージ」より

AIの成果物品質をAI任せにも人間頼みにもしない。自動化>AI>人間の優先順で責務分割する

ソフトウェアデリバリーの各作業をAI Agentに任せる範囲が広がるにつれ、成果物レビューは負荷として人間に重くのしかかる。その守備範囲はいまや実装のみならず、設計、そして仕様へと広がっている。

この状況は、純粋に“苦痛”であるとともに、ソフトウェアデリバリーのフロー上でボトルネックとなりうる。つまり、開発生産性を低下させる要因だ。SPACEフレームワークで言えば、「満足度と幸福度」だけでなく、「効率とフロー」に関する指標も悪化していることを示す。

本稿では、コードレビューだけでなく、仕様、設計、実装に至るまでの成果物レビューをどのように仕組み化すべきかについて考察した結果を、一つの“ガイドライン”として示す。

その目的は、素早いソフトウェアデリバリーを通じてビジネス価値やユーザー価値を探索するための、高速なフィードバックループを実現することである。

🎧本記事のAI音声解説版をポッドキャストで公開中
open.spotify.com

参考資料

本稿は、先週火曜（2026年6月2日）のイベント登壇で話した内容を土台としつつ、その背景や考え方、具体的な実践方法についてさらに踏み込んで整理したものだ。

また、この登壇自体は、2026年4月に公開した記事「人間によるコードレビューに依存しすぎない“速さと品質の両立”を開発ライフサイクル全体で支える」を出発点としている。

mtx2s.hatenablog.com

ガイドライン

1. 基本方針

  1. ソフトウェア開発における品質（内部品質・外部品質を含む）は、自動化・AI Agent・人間の3者で構成される“システム”によって保証する。
  2. ルールやアルゴリズムに基づいて検証・評価可能な既知の制約や品質基準は、自動化によって保証する。
  3. 自動化では扱えない品質観点については、AI Agentが学習した知識や与えられたContextに基づく推論によって保証する。
  4. AI Agentは品質保証の実施によって得た知見をシステムへフィードバックし、継続的な品質保証能力の向上に活用する。
  5. 以下に該当するケースは、人間を品質保証プロセスに含める。ここで人間が行った判断およびその理由は、今後の品質保証に活用できるよう、自動・半自動でシステムへ反映する。
    1. 高度な意思決定を伴う事項
      • 例: 複数の選択肢に明確な正解がなく、トレードオフを伴う判断
    2. 事前に定義された高リスク領域や事業上の重要度が高い領域
      • 例: お金を扱うコンポーネントや、他社との差別化となる技術など
  6. 人間は品質基準や判断基準を定義するとともに、本システムによる品質保証が有効に機能するための設計・運用・改善に責任を持つ。
  7. システムの整備が不十分で、自動化およびAI Agentが未対応または十分な精度で対応できない領域については、人間が暫定的に品質保証を補完する。

2. 開発ワークフロー内での各レビューの考え方

  1. 上流のアウトプット品質が低い場合、それを入力として生成・評価される下流のアウトプット品質は保証できない。そのため、品質保証は可能な限り各工程で完結（自工程完結）し、後工程へ不良を流さない。
  2. ソフトウェア開発は不確実性が高く、後工程で前工程のアウトプットに対する問題や改善点が発見されることがある。そのため、必要に応じて前工程へフィードバックしながら反復的に品質を向上させる。
  3. フィードバックによる手戻りコストを抑えるため、一度に扱う成果物や変更は、品質保証と開発効率のバランスを考慮した適切な大きさに保つ。

3. 仕様レビュー

前提: 仕様書とそれに関連するドキュメントがあらかじめAI Agentによって生成されている。

3.1. 自動化の役割

  • 自動化が担える範囲が非常に限定的であるため、ここでは定義しない。

3.2. AI Agentの役割

  • 要求と仕様の整合性を検証する。
  • 仕様の抜け漏れ（非機能要求への対応含む）を検出する。
  • 曖昧な記述や複数解釈可能な表現を検出する。
  • 既存機能の仕様との矛盾や不整合を検出する。
  • 仕様の検証可能性や受け入れ条件の妥当性を評価する。

3.3. 人間の役割

  • AI Agentが参照できないContextや暗黙知に起因する誤解や抜け漏れを補完する。
  • AI Agentが提示した課題や改善案に対し、要求や業務上の意図を踏まえて対応方針を判断する。

4. 設計レビュー

前提: 設計書とそれに関連するドキュメントがあらかじめAI Agentによって生成されている。

4.1. 自動化の役割

  • 自動化が担える範囲が非常に限定的であるため、ここでは定義しない。

4.2. AI Agentの役割

  • 設計ガイドラインとの整合性を検証する。
  • 仕様と設計の整合性を検証する。
  • 設計の抜け漏れ（非機能要求への対応含む）を検出する。
  • 曖昧な記述や複数解釈可能な表現を検出する。
  • 既存設計・既存実装との矛盾や不整合を検出する。
  • 設計構造（責務分割、依存関係、コンポーネント境界、データの構造とフロー、I/Fなど）の妥当性を評価する。
  • テスト観点の設計への反映漏れを検出する。
  • 設計上の課題やリスクに対する代替案を提示する。

4.3. 人間の役割

  • AI Agentが提示した課題や代替案に対し、トレードオフを踏まえて採用方針を判断する。
  • 高リスク領域や事業上の重要度が高い領域について、人間の観点から設計を評価する。

5. 実装レビュー

前提: テストを含め、必要なすべてのコードがあらかじめAI Agentによって生成されている。

5.1. 自動化の役割

  • コンパイル、型チェック、静的解析により、機械的に検出可能な欠陥を検証する。
  • Linter・Formatter等により、コーディング規約への準拠を検証する。
  • 自動テストにより、振る舞いと構造（アーキテクチャ）に関する既知の制約や品質基準への準拠を検証する。
  • 依存ライブラリ、ライセンス、脆弱性など、外部依存に関する既知の制約への準拠を検証する。

5.2. AI Agentの役割

  • 設計・仕様と実装の整合性を検証する。
  • 実装の抜け漏れや過剰実装を検出する。
  • コードの保守性（理解容易性、変更容易性、テスト容易性など）を評価する。
  • 既存実装との矛盾や不整合を検出する。
  • テスト観点・テスト対象・テスト内容の不足や誤りを検出する。
  • 自動テストによる検証が困難な箇所や品質特性を検証する。

5.3. 人間の役割

  • AI Agentが提示した課題や改善案に対し、トレードオフを踏まえて対応方針を判断する。
  • 高リスク領域や事業上の重要度が高い領域について、人間の観点から実装を評価する。

ソフトウェアシステム内部をどこまで理解しておくべきか？

AI時代において、開発者はどこまでコードを理解すべきだろうか。

自身ではコードを書かず、AI Agentに任せることが多くなるほど、コードへの理解は薄れていく。たとえコードレビューを通して理解したとしても、自分の手で書いた時より理解度は浅くならざるを得ない。

これは、ブラックボックス化が進むということだ。そこに仕様変更を加えなければならなくなったり、本番トラブルが発生したりした時はどうするのか。そう考えると、不安になるのも無理はない。

しかし、少なくとも構造については理解しておくべきだろう。レイヤーごとのアーキテクチャ、内部で適用されているデザインパターン、データ設計だ。マルチリポの構成や、コードのディレクトリ構造もそうだろう。それに加え、インフラ構成やデプロイメント構成、トポロジーといったシステム構成も含まれる。

これらを理解しているかどうかで、コードリーディングの速さや深みは大きく変わる。また、トレードオフを伴う高度な意思決定を行う際にも欠かせない。

一方で、次の3つの理由から、コードの細部まですべて理解しようと構えすぎるのも、あまり生産的ではないと考える。

  • 外部品質の保証はテストが高効率である
  • AI Agentを活用することでコードリーディングは効率化できる
  • 変更箇所のトレーサビリティはドキュメントで担保されている

≫外部品質の保証はテストが高効率である

まず、本ガイドラインが目指す品質保証システムでは、外部品質を可能な限りテストによって保証することを目指している。

それによって本番トラブル発生リスクを抑えるとともに、たとえ障害が発生したとしても、「障害範囲の局所化」と「修復時間の短縮」に向けた仕組みでカバーすることを想定している。これらについては、登壇資料のP31-P33にまとめた。

≫AI Agentを活用することでコードリーディングは効率化できる

次に、AI Agentによるコードリーディングを活用すれば、コードの理解は比較的素早く、容易になる。変更箇所の要約や処理フローの説明、関連モジュールの特定などは、AI Agentが得意とする領域である。これは言うまでもないだろう。

ここで、構造に対する前提知識が大いに役立つはずだ。

≫変更箇所のトレーサビリティはドキュメントで担保されている

さらに、従来のやり方でも、誰もがすべてのコードを把握していたわけではなかった。本番トラブル発生時に、原因となったコードを書いたエンジニアが常に対応していたわけでもない。ログや症状を手掛かりに、その場で原因を突き止め、対処していた。特に、開発と保守・運用を分離している組織では、ドキュメントをもとにこういった対応をやってきた。

そういった観点からも、コードを完全に理解しなければ保守や運用ができないと考えるべきではない。

そのうえ、本品質保証システムでは、トレーサビリティによってコードを理解しやすい環境が作られている。仕様や設計に関するドキュメントが作成され、それらが実装へと落とし込まれるからだ。

このように述べると、各種ドキュメントをコード変更に合わせて常に最新化し続けることを想像するかもしれないが、そうではない。PRやcommitのコメントから、その当時に作成したドキュメントへ辿れるよう、コードと一緒にリポジトリへ保存されていれば十分である。

それによって、コード変更の背景や意思決定の経緯を後から追跡できる。我々は以前から、コミット履歴や関連資料を手掛かりにコードを理解してきたのだから。

さいごに

私自身は、AI時代の開発ワークフローとして「Spec-firstなSDD（仕様駆動開発）」に一定の期待を寄せている。その理由は、ドキュメントの連鎖によって、AI Agentに十分なContextを与えながら開発を進められるからだ。また、その仕組みは、本稿で述べてきた品質保証システムの基盤にもなる。

ただしこれは、「ソース」と呼ばれるもの、いわゆる「SSoT（Single Source of Truth）」を、コードから仕様書に変えようという話ではない。コードの変更とそのためのドキュメントを一緒にリポジトリへコミットし、必要に応じて過去の意思決定や設計意図を参照できれば十分である。この点は前節で述べたとおりであり、Spec-anchoredやSpec-as-sourceである必要はない。

一方で、設計や実装、そしてそれらのレビューの多くをAI Agentに任せる時代において、人間は何に責任を持つのだろうか。

従来通りの説明責任を負うとするならば、人間が設計や実装の細部まで理解しておかなければならない。だが、それでは自分でコードを書いた方が効率が良いかもしれない。AI Agentに頼ると、どうしても理解が浅くなる。AI Agentを利用する価値はどこにあるのだろうか。それではAI Agentは、単にコストだけが増える存在になってしまう。

おそらくここが、パラダイムシフトとなるポイントなのだろう。

そもそもこれまでも、一人ひとり、あるいはチーム全体でも、コードベースのすべてを深く理解しているとは限らなかった。レガシーシステム化し、ブラックボックスとなったソフトウェアシステムであっても、責任を持って変更・運用してきた。

ソフトウェアデリバリーにおいて、今後、人間が負う責任とは、AI Agentに設計や実装を行わせる仕組みそのものに対する責任ではないだろうか。誤った設計・実装をAI Agentが作り上げたなら、その成果物を修正するだけでなく、それを生み出した仕組み上の欠陥を正すのだ。

そして、本番への欠陥流出を最小化し、たとえ障害が発生してもその影響を局所化し、迅速に復旧できる仕組みを構築する。そして、そのシステムを継続的に改善し続ける。

AI時代のエンジニアに求められる責任とは、個々の設計や実装に対する責任よりも、そのようなソフトウェアデリバリーシステムそのものに対する責任に重きが置かれるのだろう。

しかし、それは技術力が不要になることを意味しない。高度な意思決定や、例外的な状況への対応が求められるからだ。手を動かす機会が失われつつある時代に、どのように技術力を身につけ、維持し続けるか。新たな課題に向き合うことになる。

◇　◇　◇　◇　◇

本稿では品質保証システムを中心に述べた。しかし、その有効性はチーム設計や組織設計とも切り離せない。

この「組織設計」というテーマにも関心がある方は、拙著『チームの力で組織を動かす』で扱っているチーム責務や組織設計の話も参考にして欲しい。カバー裏にも書いてあるのだが、本書はアジャイル、リーン、DevOps、マイクロサービス、チームトポロジー、コンウェイの法則といった考え方をもとに、チーム設計・組織設計を論じたものである。

gihyo.jp

人間によるコードレビューに依存しすぎない“速さと品質の両立”を開発ライフサイクル全体で支える

AIコーディングエージェントの普及により、コード生成のスループットは、人間によるコードレビュー能力を上回り始めている。実際、AI導入によってPR数が増加しているという報告も多い。

もともとコードレビューは、AI導入以前から負荷が集中しやすく、フロー上のボトルネックになりやすい工程であった。コーディングが加速したことで、それがより顕著になったと見るべきだろう。

この状況を放置すると、AIによる開発生産性向上は、レビュー工程で相殺されてしまう。

では、人間によるコードレビューは、本当に不可避なコストなのだろうか。それとも、削減あるいは再設計できる余地があるのだろうか。私自身も、非常に興味のあるテーマだ。

本稿では、この問いを起点に、AI時代におけるSDLC（ソフトウェア開発ライフサイクル）の再設計について考える。

なお、議論では、使い捨てのソフトウェアや、極端に高い信頼性・サービスレベルを要求されるシステムは対象としない。後者の領域では、法規制や安全要求、監査要件の制約が強く、コードレビューの位置づけも大きく異なる。

🎧 本記事のAI音声解説版をポッドキャストで公開中
open.spotify.com

コードレビューを巡る議論は「速さ」と「品質」のスタンスの違いとして現れる

人間によるコードレビューを巡る議論では、強調点の違いとして、品質リスクを重く見る立場と、フロー停滞のコストを重く見る立場がある。そこにはグラデーションがあるが、議論を整理するために、ここでは両端のスタンスをあえて抽象化して置いてみよう。

  • 品質懸念: 人間によるコードレビューを残す
    • スタンス: 「AIの品質は不完全である」
    • 思想: AIを過度に信頼して任せきりにせず、信頼性や保守性を守るために、人間によるコードの理解と意思決定が不可欠である。
  • 停滞懸念: 人間によるコードレビューをやめる
    • スタンス: 「人間はボトルネックである」
    • 思想: AI導入の効果を最大化し、開発スループットを極限まで高めるには、人間を外し、完全自動化された品質保証を目指すべき。

これを見ると、コードレビューに対する両者の主張は確かに対立しているが、それはスタンスの違いから生じる解決策の違いであることが分かる。

そしてこの違いは、必ずしも人ごとに分かれているわけではなく、一人のエンジニアの中にも同時に存在しうる。AI導入によって、極限まで開発スピードや効率を高めたいという点では、意見が一致しているはずだ。

また、実際の現場には、全面維持と全面廃止の二極ではなく、変更リスクや工程成熟度に応じてレビューのあり方を調整したいという中間的な立場も多い。

問題は、AI活用でソフトウェアデリバリーのスピードを上げながら、品質をどう担保するかである。

では、コードレビューが担ってきた役割とは何か。それを別の手段で担保できるなら、この対立は解消できるはずである。

コードレビューが担ってきた役割

コードレビューの役割にはさまざまな捉え方があるが、本稿では議論を進めるため、特に重要な4つの機能に絞って整理する。それは、変更容易性・品質保証・緊急対応・説明責任に関わるリスクを低減する機能である。

以下に、その主要なリスクを挙げる。品質懸念が強く意識される環境では、これらのリスクはより重く評価されやすい。

変更容易性に対するリスクの削減

コードレビューは、繰り返される変更によって生じる複雑性の増大を抑え、変更容易性を維持する役割を担ってきた。

AIによってコード生成が加速すると、保守性の劣化も同じ速度で進む。さらに、コードベースが複雑化すると、人間だけでなくAIの生成品質も低下する。

品質保証に対するリスクの削減

コードレビューは、実装のヌケモレや動作上の不具合、セキュリティの脆弱性などの早期発見を担ってきた。

現時点では、AIによるコードレビューだけで、すべての問題を安定的に検出できるとは言いがたい。とくに仕様意図や現場固有の文脈、専門知識への依存が強い論点では限界が残る。それらを見逃せば、プロダクトの信頼性を落としかねない。

緊急対応に対するリスクの削減

コードレビューは、コード変更者以外のエンジニアにも変更内容の理解を促し、チーム内に知識を共有させる役割を担ってきた。

この機会が失われると、変更内容が属人化し、本番トラブル発生時に問題の特定が困難になる。結果として、恒久対策どころか一次対応すらも遅れ、MTTRが悪化する。サービス影響が長期化し、ユーザーへの影響も拡大する。

説明責任に対するリスクの削減

コードレビューは、コーディングに対するホーソン効果によって、コード品質を高める作用がある。「誰も見ないコード」よりも「誰かに見られるコード」の方が、自然と丁寧に書こうとする心理的メカニズムが働くからだ。

現在でも、AIが生成したコードを十分に理解せず、そのままPRとして提出する問題が指摘されている。レビューという場がなければこの傾向はさらに強まり、変更の意図を説明できないコードが蓄積される可能性がある。これは単なる品質の問題ではなく、説明責任の不在である。

補足: コードレビューの価値

本稿では議論のために前述の4つに整理したが、近年におけるコードレビューの役割や価値は、より多様化している*1。ここでその点を補足しておきたい。

まず、コードレビューは、実装者とレビュアーがやり取りしながらよりよい実装を探る「問題解決の場」であり*2、その過程は設計意図や判断根拠の記録としても残る。

また、Googleにおけるコードレビューのテーマは、「教育」「規範の維持」「ゲートキーピング」「事故防止」の4つに整理されている*3。

さらに、コードレビューを通して、新しいコードを理解する開発者が増えるという効果も報告されている*4。冗長化が促され、コードの共同所有化が進むということだ。

したがって、コードレビューを削減・再設計するのであれば、こうした機能をどこで担保するのかまで含めて考える必要もある。

mtx2s.hatenablog.com

コードレビューだけにフォーカスすると議論は噛み合わない

コードレビューを巡る議論が噛み合わないのは、前提としている環境が異なるためである。前節で整理したリスクの捉え方も、その前提によって大きく変わる。

ここでは、停滞懸念のスタンスが優位に働く環境について考えてみよう。そこでは、品質懸念が一定程度軽減されていることが前提となる。

たとえば、コーディングのAI化が組織内でどこまで進んでいるかによって、リスクの捉え方は大きく変わる。活用が進んでいる組織では、運用の仕方次第で、AI生成コードに伴う変更容易性や品質保証のリスクを一定程度抑えられている場合もある。

同様に、継続的インテグレーション環境が整備されている場合、自動テストや静的解析による検証が常時機能し、変更容易性や品質保証に対するリスクは低く見積もられる。

さらに、継続的デリバリーや本番運用環境が十分に整備されていれば、リリースは段階的に行われ、影響範囲は制御される。異常は即時に検知され、変更と結び付けて追跡できるため、ロールバックや安全な実験も迅速に行え、結果として品質保証や緊急対応に対するリスクも低減される。

このようなトレーサビリティが確保された環境では、変更と結果の因果関係を後から検証できるため、運用効率だけでなく、変更に対する説明可能性も担保されやすくなる。

逆に言えば、こうした基盤がまだ十分でない組織では、人間によるコードレビューの削減は慎重に進める必要がある。いきなり無くすのはリスクが高いので、まずは自動化や可観測性を整えるほうが現実的だろう。

コードレビュー工程に固執せずSDLC全体の再設計で解消する

前節で述べた環境は、コードレビューが担っていた役割を「シフトレフト」と「シフトライト」によってSDLC全体へ分散した構造である。コードレビュー工程だけでリスクを軽減するより、現実的なアプローチだ。

人間によるコードレビュー負荷を軽減・解消しつつ、品質懸念を解消するには、次のような構造が必要になる。

  1. 生成段階で品質を作る
  2. レビュー工程で品質を補強する
  3. パイプラインで品質を保証する
  4. 本番で品質を回復できるようにする

1. 生成段階で品質を作る

成果物の品質は、それを生み出す工程で作り込むべきものである。トヨタではこれを「自工程完結」と呼び、後続工程に不良を流さないことを徹底している。

この原則はソフトウェア開発にもそのまま当てはまる。コードの品質はコーディング時に作り込むものであり、コードレビューを含む後工程での品質保証はあくまでセーフティネットに過ぎない。

したがって、人間によるコードレビューを削減するのであれば、AIコーディングの精度そのものを高める仕組みを設計する必要がある。

たとえば、次に挙げるような対策が考えられる。当然ながら、AIを活用したとしても成果物の最終的な責任は人間に帰属するという大前提は変わらない。

  • コンテキスト供給を強化する:
    • ASTによるコード解析や、MCP等を通じたリポジトリ・ドキュメント・スキーマへのアクセスを組み合わせ、関連コードや依存関係をAIに参照させる。文脈不足による誤生成を防ぐ。
  • 規範と設計資産をAI可読にする:
    • コーディング規約や設計ガイドライン、過去の教訓や陥りやすい罠を、AIが参照しやすい構造で明文化する。プロジェクト固有の制約や文化を生成プロセスに反映させる。
  • 生成の粒度を小さくする:
    • INVEST等でタスクを細分化し、Stacked PRsやインクリメンタルリファクタリング等を用いて小さな変更と検証を反復する。巨大変更による検証困難なリスクを抑える。
  • ペアプロ・モブプロを活用する:
    • 二名以上のエンジニアがコーディングに関わることで、コーディングとコードレビューを一体化する*5。これを知識共有・育成の場としても活用する。ホーソン効果も期待できる。
  • 要求を構造化し実装計画へ落とす:
    • 状況に応じてSpec-firstな手法やPLANモードを用い、抽象的な要求を仕様・設計・タスクへ分解し、制約や手順を明示した実装可能な仕様へと変換する。解釈ブレやハルシネーションを抑制し、変更意図を追跡可能にする。
  • 検証条件を構造化し合格基準を定義する:
    • EARSやGherkin等で振る舞いと受け入れ条件を明確に定義し、検証基準を事前に固定する。生成物の正否判定を機械的に行えるようにする。
  • テスト生成で自己修正ループを回す:
    • 実装と並行してテストコードを生成し、実行結果をフィードバックとして修正を繰り返すループを構築する。
  • 生成直後に自己検証を行う:
    • 別ロールのAIやチェック観点を分離したプロンプトを用い、仕様適合性や設計妥当性を検証する。誤解や欠落を生成直後に検出する。

2. レビュー工程で品質を補強する

コードレビュー工程が生まれた背景には、コーディングの成果物を別の主体が検査し、品質を担保するという考えがある。現代ではより多面的な役割も担うが、その本質は、製造業における検品と同様のゲートキーピングにある。

コードレビューは、機能的にはコーディングの一部と捉えることができる。工程が分離されているのは、コーディングとレビューで主体者が異なるためであり、前者はコード変更者、後者はレビュアーが担う。

しかし、人間によるコードレビューを代替できる場合、主体者はコード変更者に一貫し、両工程は一体のものとして扱える。

この構造では、工程間で発生していた待ち時間が解消される。レビューそのものの時間短縮にとどまらず、「レビュー待ち」によるフローの滞留がなくなり、実装から統合ブランチへのマージまでが滑らかに接続される。

これは、非同期型から同期型への転換であり、コーディングに対するフィードバックループを高速化する。継続的レビューと呼べる状態である。

以下に、現時点で取り得る対策を考えてみる。

  • リスクに応じてレビュー要否を切り分ける:
    • 信頼性要求が一律でない前提のもと、変更内容や影響範囲に応じたティア分類を導入し、低リスク変更はAIレビューと自動テストを通過条件とすることで人手レビューを省略する。
  • レビューを専門領域ごとに分離する:
    • ロジック・設計・セキュリティ・性能などの観点ごとにレビューを分割し、それぞれに特化したチェックを適用することで、観点の抜け漏れを減らす。
  • 複数の視点で検証する:
    • 異なる特性を持つエージェントや複数モデルを組み合わせ、同一対象を多角的に評価することで、見落としや偏りの影響を緩和する。
  • レビューを反復させる:
    • AIレビューの非決定性による出力の揺らぎを補うため、複数回実行や修正後の再レビューを自動化し、検出のばらつきを低減する。
  • 指摘を評価しトリアージする:
    • 指摘の妥当性を別モデルやルールベースで再評価し、信頼度スコアや重大度に基づいてフィルタリングすることで、不適切なフィードバックを排除し、対応優先度を明確にする。
  • 修正まで含めて自動化する:
    • 指摘に留まらず、修正案の提示から再検証・再レビューまでを自動化する。人手の介在を最小化し、品質改善のサイクルを高速化する。

3. パイプラインで品質を保証する

生成AIを用いた品質保証の課題は、その非決定性にある。すべてをAIに委ねるのではなく、従来の技術や仕組みと組み合わせ、適材適所で配置することが重要である。

具体的には、AIレビュー工程の前後に、決定論的なゲートやガードレール、フィルタを多層的に配置する。前段では機械的に判定可能な低レイヤーの問題を除去し、AIが論理構造のレビューに集中できる環境を整える。後段では仕様・要件・ガバナンスからの逸脱を防ぐ。

このように、AIの不確実性を決定論的な枠組みで拘束することで、パイプラインを流れるコード変更の品質を高い信頼性で制御できる。

以下に、その具体例を挙げる。

  • 静的解析でコード品質を均質化する:
    • プロジェクトに合わせてルールをチューニングした静的解析を運用し、過検知や誤検知を抑えつつ、実行前に特定可能な脆弱性やアンチパターンを検知・是正する。
  • 自動テストで振る舞いを保証する:
    • ユニットテストや回帰テストをパイプライン上で常時実行し、AIによる変更が既存機能や意図した仕様を破壊していないかを検証する。機能の正当性を継続的に担保する。
  • 自動テストで構造を保証する:
    • ArchUnit等を用いて依存関係やレイヤー構造を検証し、AI生成コードによる設計規約の逸脱やアーキテクチャの腐敗を防ぎ、構造の秩序を維持する。
  • 依存関係とライセンスを検証する:
    • 追加ライブラリのライセンスや既知の脆弱性を自動スキャンし、法的リスクやセキュリティ上の問題をゲートで遮断する。サプライチェーンリスクを低減する。
  • 非機能要件を継続的に検証する:
    • パフォーマンスやセキュリティの自動テストを組み込み、AIが見落としがちな非機能要件の充足を確認する。品質基準の逸脱を早期に検知する。

4. 本番で品質を回復できるようにする

システムの品質は、故障を防ぐことだけでなく、いかに早く回復できるかによっても決まる。

可用性（Availability）は、MTBF（平均故障間隔）とMTTR（平均修復時間）で表される。

Availability = \frac{MTBF}{MTBF + MTTR}

MTBFを伸ばすことも重要だが、MTTRを短縮する方が可用性への寄与は大きい。MTTRがゼロに近づくほど、MTBFの長さに関わらず可用性は100%に近づくからだ。

もちろん、瞬断すら許容できない業務ドメインもある。ただ、一般的なWebサービスでは、故障が致命的でない限り、一度の長時間停止より数度の瞬断のほうが相対的に影響が小さくなるケースも多い。

近年のソフトウェアシステムは複雑化が進み、デリバリー速度も求められている。故障を完全に防ぐことは、コストと時間の両面で現実的に難しい。

したがって、「いかに故障を防ぐか」にばかり腐心するのではなく、「いかに素早く検知し、復旧できるか」を設計することも重要になる。いわゆる「Design for Failure」の考え方である。

これは、MTBFを軽視するということではない。品質をある程度引き上げると、予防コストが効果に見合わなくなる収穫逓減しゅうかくていげんの領域において、残りの不確実性を検知・復旧の仕組みで受け止めるという合理的な選択肢だ。

この思想は、問題がAI起因か否かに関わらない。以下に、そのための具体例を挙げる。

  • 段階的に公開し影響範囲を制御する:
    • カナリアリリース等により、変更を小さな単位で段階的に本番投入し、トラフィックを制御する。障害時の影響範囲（Blast Radius）を限定する。
  • 本番で挙動を観測し妥当性を検証する:
    • フィーチャーフラグやダークローンチを用いてデプロイと公開を分離し、本番環境で挙動を観測・検証する。全面公開前に変更の妥当性を確認する。
  • ロールバックを高速かつ標準化する:
    • ロールバックを迅速に実行できるようにし、ワンクリックでの切り戻しや事前定義された手順をデプロイフローに組み込む。復旧時間を最小化する。
  • 異常検知と原因特定を即時化する:
    • ログ・メトリクス・トレースを統合した可観測性基盤により異常を即時に検知し、変更履歴と関連付けて分析できるようにする。原因特定を高速化する。
  • 多層防御でランタイムの耐性を高める:
    • サーキットブレーカー、レートリミット、キルスイッチなどを組み合わせ、障害の伝播を抑制する。影響を局所化し、システム全体への波及を防ぐ。
  • 事後学習を仕組み化し生成品質へ還元する:
    • ポストモーテムなどインシデント分析の結果をコーディング規約や検証ルールとして明文化し、AIのプロンプトやチェックプロセスに反映する。本番での失敗を次の生成精度向上に繋げる。

終わりに: 「速さ」と「品質」の両立は構造の再設計によって実現する

人間によるコードレビューをゼロに近づけようとすると、そこで担保してきた役割はSDLC全体へと分散される。単にコードレビューを自動化すればよいという話ではない。

つまり、問題は、レビューという工程そのものではなく、そこで担保してきた機能をどこでどう実現するかにある。

論点は、「人間によるコードレビューが必要かどうか」ではなく、速さと品質をどう両立させるかにある。その視野はコードレビュー工程にとどまらず、開発から運用までを含むSDLC全体に広がる。問われているのは構造そのものだ。

重要なのは、自分たちのシステムに内在するリスクを見極め、それに応じた構造を設計することである。求められる信頼性水準によって、人間によるコードレビューの必要性もまた変わる。

そのためには、「コードレビューで守る」という前提に依存しすぎず、その役割を構造で担保するという発想への転換、つまりアンラーニングが求められる。

参考文献

*1:mtx2s「何となくのコードレビューを小さくて素早く価値あるプロセスに変えるための参考値や考え方」mtx2s's blog on はてなブログ, 2024年12月23日, 「コードレビューの価値」より

*2:Peter C. Rigby, Christian Bird「Convergent Software Peer Review Practices」ESEC/FSE (European Software Engineering Conference and the ACM SIGSOFT Symposium on The Foundations of Software Engineering), 2013年8月, 「4.3 Defects vs Discussion」より

*3:Caitlin Sadowski, Emma Söderberg, Luke Church, Michal Sipko, Alberto Bacchelli「Modern Code Review: A Case Study at Google」ICSE-SEIP (40th International Conference on Software Engineering: Software Engineering in Practice Track), 2018年5月, 「4.2 Current expectations」より

*4:Peter C. Rigby, Christian Bird「Convergent Software Peer Review Practices」ESEC/FSE (European Software Engineering Conference and the ACM SIGSOFT Symposium on The Foundations of Software Engineering), 2013年8月, 「5. SHARING KNOWLEDGE THROUGH REVIEW」より

*5:Robert C. Martin 著／角 征典, 角谷 信太郎 翻訳『Clean Agile 基本に立ち戻れ』KADOKAWA, 2020年, 「第5章 テクニカルプラクティス」内の「コードレビューとしてのペアリング」より

コードベースの分散度合いや複雑性、規模がAI導入効果にどう影響するか

2025年から2026年にかけての年末年始は、YouTubeで「AI Engineer」チャンネルにどっぷり浸っていた。ここにはAIエンジニアリングの最前線を走るカンファレンスの登壇動画が豊富にアーカイブされている。その中から、過去半年以内に公開されたものを優先的に漁り、最新情報を貪った。

数多くの登壇の中でも特に興味深かったのが、「コードベースの特性がAI導入効果に与える影響」についての議論だ。モノリポかマルチリポ（ポリリポ）かといった分散度合い、そして複雑性や規模が、AIによる生産性向上をいかに阻害、あるいは促進するのか。

本稿では、そこから得た洞察を整理し、コードベースとAI導入効果の関係について、深く掘り下げてみたい。

🎧 本記事のAI音声解説版をポッドキャストで公開中

open.spotify.com

【ご視聴時の注意点】AI生成解説のため、内容には一部、原文から逸脱した軽微な誤りや、不自然な表現が含まれる可能性があります。大筋の理解には役立ちますが、詳細や正確な情報については、引き続き本ブログ記事をご確認ください。

リポジトリの分散度合い（モノリポとマルチリポ）

AIコーディングエージェントの普及に伴い、改めてモノリポの優位性が注目されている。その理由は、全ソースコードが一箇所に集約されている方が、AIにとってコンテキストの断絶が起きにくく、生成物の精度が向上しやすいからである。各モデルが有するコンテキストウィンドウの拡大も、追い風になっているのだろう。

もともとリポジトリ戦略は、ソフトウェアアーキテクチャや組織構造と密接な関係にある。

シンプルなモノリスから、FEとBEの分離、そしてクラウド登場以降に進んだマイクロサービスを始めとする分散アーキテクチャへ。その過程で、リポジトリも分割統治──マルチリポ化が進んだ。

複数チームでのソフトウェア開発では、何らかの境界でソフトウェアをコンポーネント分割し、マルチリポによるチーム単位での分割統治を選択する利点は大いにあった。

しかし、AIエージェントの登場がこの前提を揺るがしている。単なるコード補完の域を超え、リポジトリ全体を俯瞰して複雑なタスクを遂行するエージェントにとって、マルチリポによる物理的な境界は「コンテキストの壁」として機能してしまう。

モノリポの方がAI導入効果が高まるのであれば、リポジトリ戦略を転換すべきかもしれない──。マルチリポで開発を続けてきた組織にとっても、そんな考えがふと頭によぎる。

とは言え、リポジトリの移行は低コストではない。単なる「感覚」ではなく、客観的なインパクトを知る必要がある。

そもそもモノリポかマルチリポかの選択は、従来からトレードオフの関係にあった*1。そこに新たな変数として「AI導入効果」が加わった今、その影響をどこまで考慮すべきか。この問いに対し、JellyfishがOpenAIと提携して行った調査結果を紹介していたのが、Nick Arcolanoの登壇である*2。

【調査結果】分散度が高まるほどAI導入効果は減衰する

Arcolanoが解説した調査では、リポジトリの分散度合いが、AI導入によるPR数増加にどの程度の影響を与えるかに焦点をあてている。*3

分散度合いは、「集約型（centralized）」から「バランス型（balanced）」「分散型（distributed）」「高度分散型（highly distributed）」の4段階に分けられている。そのうえで、各セグメントにおいて、AI導入率が未導入（0%）から完全導入（100%）に移行することでPR数が何倍になるかの増加率を数値化している。

結果は、次の通りとなった。

分散度合い 1人あたりのPR数 増加率
集約型 2.7 3.9倍
バランス型 3.1 4.1倍
分散型 3.9 2.1倍
高度分散型 5.3 -

出典: Nick Arcolano（Jellyfish）「What Data from 20m Pull Requests Reveal About AI Transformation」AI Engineer, 2025年11月25日, 14:32~ （動画内のグラフをもとに筆者が作成）

まず、表を見て驚くのは、分散度が高いほどPR数が多くなっている点だが、「マルチリポの方が生産性が高い」ということではない。これは、一機能の開発で複数のリポジトリに変更が波及しているという、マルチリポの構造的問題に過ぎない。

特筆すべきは、AI導入による「増加率」の顕著な差だ。集約型やバランス型では約4倍という劇的な効果が得られているのに対し、分散型ではその半分にとどまる。さらに「高度分散型」に至っては、AI導入とPR数の変化に相関が見られず、むしろ微減の傾向さえ確認された。

もちろん、PR数の増加がそのまま生産性の向上を意味するわけではない。スタンフォードのYegor Denisov-Blanchの示す、ある企業のcommitベースのデータでは、AI導入によって「手戻り（rework）」が増加する傾向も見て取れる*4。

しかし、目安にはなる。先述のcommitベースのデータからも、AI導入以降、機能追加（added）が増加傾向を示しているからだ。

出典: Yegor Denisov-Blanch (Stanford)「Does AI Actually Boost Developer Productivity? (100k Devs Study)」AI Engineer, 2025年7月24日, 9:09~ （動画内のグラフをもとに筆者が作成）

【洞察】リポジトリの境界はAIにとってのコンテキストの壁である

Arcolanoは、AIコーディングエージェントが分散型のリポジトリ戦略を得意としない理由を、リポジトリ間の関係性が記述されていないことにある、と指摘している*5。

シニアエンジニアの脳内にのみ存在するリポジトリの関係図に、AIはアクセスできない。それがコンテキストの欠落となって、ハルシネーションを誘発し、生成物の品質を低下させる。

AI時代におけるモノリポの真価は、その圧倒的な「視野」と「操作範囲」の広さにある。コードが地続きのコンテキストとして存在することで、AIは全体最適に基づいた分析を行い、コンポーネントを横断するアトミックな変更を一括で完結できる。*6。

対照的に、マルチリポ構成はAIに「情報の断片」を用いた個別作業を強いる。リポジトリ間の整合性を保つための調整コストが、AI本来のスピードを相殺してしまうのだ。

この構図は、人間にとっても同様だ。同時に扱うリポジトリが増えるほど開発は煩雑になる。コンテキストウィンドウならぬ、脳内のワーキングメモリが飽和し、認知負荷が増大する。

そもそも、単一の機能改修で常に複数リポジトリへの変更を強いられるなら、“チームがソフトウェアを分割統治している” 状態とは言い難い。マルチリポの利点を活かせていないのだ。

それはおそらく、ソフトウェアアーキテクチャの問題だろう。リポジトリ間の凝集度が低く、結合度が極めて高いという欠陥を示唆している可能性がある。

もちろん、明確に技術スタックが異なるようなFEとBEを境界とした分散なら分かる。しかし、たとえば複数のBEシステムが複雑に絡み合っているなら問題だ。

結局、AI導入効果が伸び悩む背景には、AI以前の問題である「旧来の設計不備」が横たわっていることも多い。

【戦略】境界の妥当性検証と戦略的集約の検討をはじめる

マルチリポ環境でAI導入効果を最大化するためにまず着手すべきは、“リポジトリ境界の妥当性”、延（ひ）いては “コンポーネント境界の妥当性” の検証である。

もし単一の機能改修において、定常的にリポジトリを跨ぐ変更が発生しているなら、それは分割の単位が不適切である可能性が高い。それなら、リアーキテクチャを検討する。セットで変更されることが多いリポジトリなら、単純に、統合してしまってもよい。

リポジトリ移行やリアーキテクチャは時間と労力を要する仕事だが、長い目で見れば、AIの文脈理解を助けるだけでなく、保守コストの削減にも直結する。

一方で、ソフトウェアアーキテクチャやリポジトリ分割は適切でも、複数のリポジトリを横断して変更しなければならないこともある。ドメイン駆動設計で言う「境界付けられたコンテキスト」をまたいだ機能開発など、ざらにあるからだ。

このようなケースが頻発するのであれば、リポジトリの集約も検討の余地がある。

ただし、あまりに巨大なモノリポは、ビルド・テストの遅延やCI/CDの複雑化を伴う。そのトレードオフを踏まえたうえでの判断になるだろう。

選択肢の一つとして、ハイブリッドなリポジトリ戦略もある*7。コアなものは一つのリポジトリに集め、そうでないものはマルチリポで管理するアプローチだ。この「戦略的集約」こそが、AIの視野を確保しつつ、システムの肥大化を制御する現実的な解となるのかもしれない。

コードベースの状態（グリーンフィールド/ブラウンフィールドと低複雑度/高複雑度）

エンジニアの日常は、見通しの悪い絡み合ったコードとの奮闘に多くの時間が費やされる。新規にソフトウェアを開発するプロジェクトより、既存ソフトウェアの保守・拡張にあたることが多いからだ。

追加開発を長年繰り返してきたコードベースは、時代遅れなコードや複雑な依存関係が堆積し、それが開発の自由度を奪う。タスクの難易度が高まるほど、この制約は足かせとして重くのしかかる。

こうした開発環境の差異を、建築業の用語を借りて「グリーンフィールド」と「ブラウンフィールド」というメタファーで表現することがある。

グリーンフィールドとは汚染されていない未開発な土地を指す。再開発または再利用しようとしている、既存汚染物質を伴う用地のことはブラウンフィールドと呼ばれる。

（引用: Neal Ford, Rebecca Parsons, Patrick Kua 著／島田 浩二 翻訳『進化的アーキテクチャ ─絶え間ない変化を支える』2018年, オライリー・ジャパン, 6.2）

ソフトウェア開発においては、新規にソフトウェアを開発するプロジェクトをグリーンフィールド、既存のソフトウェアを扱うプロジェクトをブラウンフィールドと呼ぶ。

引用文内での「汚染」という言葉は、既存ソフトウェアに蓄積された “時代遅れなコード” や “複雑な依存関係” といった、エンジニアリング活動の足かせを象徴している。つまり、既存ソフトウェアを扱うプロジェクトは、開発生産性が低くなりがちだと古くから認識されていた。

AI時代において、ブラウンフィールドのこの問題は打開されたのだろうか。

【調査結果】ブラウンフィールドかつ複雑なタスクはAIとの相性が悪い

スタンフォードのYegor Denisov-Blanchは、「プロジェクトの成熟度（project maturity）」と「タスクの複雑性（task complexity）」の組み合わせの4象限で評価した結果を紹介していた*8。「プロジェクトの成熟度」は、グリーンフィールドかブラウンフィールドで分類されている。

出典: Yegor Denisov-Blanch (Stanford)「Does AI Actually Boost Developer Productivity? (100k Devs Study)」AI Engineer, 2025年7月24日, 13:28~ （動画内の図をもとに筆者が作成）

データが示す傾向は明白だ。AI導入による恩恵は、グリーンフィールドかつ低複雑性のタスクで最大化される一方、ブラウンフィールドかつ高複雑性の条件下では著しく減衰する。

なお、ここで言う生産性とは、コード行数やcommit数、PR数といった単純な指標ではない。独自のモデルを用ったcommitベースでのコード評価によって、バグによる手戻りなどの変更が取り除かれた結果が用いられている。*9

【洞察】AIは2種類の複雑性を区別できない

Denisov-Blanchは調査結果に対し「根本的な原因は不明」としているが、AIを駆使する多くの開発者にとっては納得感ある結果と映ったはずだ。

AIによるコード生成において、タスクの複雑性が増せば実行時間は長迷するだけでなく、成果物の品質低下で手戻りも生じる。これは日常的にAIを活用する者なら誰もが抱く肌感覚だろう。

特にブラウンフィールドのコードベースにおいては、必然的に内包される「本質的複雑性」に加え、過去の成り行きで積み重なった「偶有的複雑性」が混在する。この二重の複雑性がタスクの難易度を高め、AIのパフォーマンスを阻害する主因ではないか。

ソフトウェアには、解くべき課題に由来する「本質的複雑性（essential complexity）」と、レガシーな設計や場当たり的な回避策による「偶有的複雑性（accidental complexity）」が内包されている*10。後者はしばしば技術的負債と化す。

結局のところ、コードベースの複雑性に起因するのではないか、というのが私の見立てだ。もちろん、ブランフィールドのコードベースの方が規模が大きいかもしれず、それが一因であることも考えられる。それは、後述する別の議論で扱うことにしよう。

先述の通り、歴史の長いプロジェクトほど内部構造が複雑化しやすい。異なる機能間のロジックが明確に分離されておらず、絡み合い、本来あるべき境界線が消失している。

この複雑な依存関係を解きほぐすのは人間にとっても困難だが、それはAIにとっても同様だ。むしろ、開発者が持つ暗黙知にアクセスできないAIが介入することで、構造をさらに悪化させるリスクさえ内包している。

NetflixのJake Nationsによれば、AIは、二種類の複雑性──本質的複雑性と偶有的複雑性──を区別しない。*11

混在するこれら二つの複雑性を分離・整理するには、開発の背景、歴史的経緯、ドメイン知識に基づく高度な経験則が不可欠となる。だが、コンテキストが不足したAIには、そのような分離は行えない。ロジックも技術的負債も、単なる “既存コードの一部” として等価に認識されるだけだ。

結果、過去の奇妙なワークアラウンドやレガシーな設計思想の上に、AIが生成したコードがさらに塗り重ねられる。そうしてコードベースが抱える偶有的複雑性はさらに悪化する。

こうしてAI導入による速度的メリットは、肥大化する複雑性と手戻りのコストによって容易に相殺されてしまう。では、この「AIが複雑性を増幅させる」という不可避な停滞を前に、どのような選択をすべきなのだろうか。

【戦略】「Easyボタン」を捨て、開発ワークフローを選択的に切り替える

「期待する動作さえすれば良し」と振り切るのであれば、少なくとも内部品質の手直しコストを削減できるが、それで本当に良いのだろうか。これは従来の言葉で言えば、「『クイック＆ダーティ』を選択してスピードを優先し、品質を犠牲にするのか」という古典的な問いである。

だが、AIによって開発が加速した世界において、この選択はかつてないほど深刻な状況を招く。Capital OneのMax Kanat-Alexanderが指摘するように、質の低いPR（bad rubber stamp PRs）を量産し、形骸化したレビューを繰り返せば、コードベースは複雑化の一途を辿る悪循環に陥る*12。その悪化スピードは、これまでの比ではない。

Nationsは、AIによって助長されたこのクイック＆ダーティな選択肢を「究極の “Easy” ボタン（ultimate easy button）」と呼んだ。

ここでいう「Easy」とは、Rich Hickeyが提唱した「Simple」と対比される概念だ*13。端的に言えばクイック&ダーティを指す。目先のスピードと引き換えに「後回しにされた複雑性」を受け入れるトレードオフだ。従来で言えば、StackOverflowからの安易なコピペがその典型例と言える。

対する「Simple」は、「Complex（複雑）」の対極にあり、要素が絡み合わず、保守性の高い構造を指す。これは設計や実装に対する深い洞察と、熟慮の末にのみ到達できる境地である。

では、安易な「Easyボタン」に逃げるのではなく、AIを駆使して「Simple」をいかに実現すべきか──。

鍵となるのは、複雑なタスクにおいて、通常のワークフローから、より「コンテキストエンジニアリング」に重心を移したアプローチへと切り替えることだ。

通常のワークフローに欠けているのは、変更対象となるコードベースの綿密な調査と、そこから導き出される詳細な実装計画である。これらを抜きにして、いきなりAIにコード生成を命じたところで、到底満足な結果は得られない。

このアプローチは、AIにアドホックな指示を出して実装を継ぎはぎしていく「最も素朴な手法（most naive way）」*14とはパラダイムが異なる。目指すべきは「正確なコードの生成」そのものではなく、それを可能にする「精度の高い実装計画」をいかに構築するかという、AIとの協働のあり方だ。

Nationsもそうであるが、HumanLayerのDex Horthyは、その有望な手法としてRPI（Research, Plan, Implement）を詳述している*15*16。これはDenisov-Blanchの調査結果も踏まえ、「ブラウンフィールドにおける複雑なタスクを効果的に実行するためのコンテキストエンジニアリング」として位置づけられる。

RPI以外にも、簡易にやるならAIコーディングツールの「PLANモード」の活用もそうだろう。また、仕様の詳細化まで含めるなら「SDD（スペック駆動開発）」も同様の志向を持つと言える（※ただし、Horthyは一部のSDDツールに対しては否定的な見解を示している*17）。

コードベースの規模

複雑化と並び、規模の膨張もまた、業務システムやWebサービスのブラウンフィールドプロジェクトにとって無視できない障壁となる。「リーマンの法則（Lehman's laws of software evolution）*18」が、これを的確に言い表している。

  • 複雑性の増大（Increasing complexity）:
    • 継続的に変更されるソフトウェアは、リファクタリング等の明示的な改善を行わない限り、内部の構造的複雑性が増大する。
  • 継続的な成長（Continuing growth）:
    • ソフトウェアは、ユーザーの満足度を維持するため、継続的に機能を拡張し続けなければならない。

「継続的な成長」による継続的な機能拡張の結果は、それらの累積に伴うコードベース規模の巨大化である。特にAIによって開発が高速化された現代では、このサイクルまでもが加速し、コードの膨張スピードはかつての比ではない。

ここで懸念すべきは、「コードベースの規模そのものが、AI導入効果を減衰させる変数になり得るか」という点だ。

【調査結果】規模が大きくなるほどAI導入効果は低減する

Denisov-Blanchは、コードベースの規模が拡大するほど、AI導入による生産性向上の恩恵が目減りするというグラフを提示している*19。これは厳密な実証データのプロットではなく、研究チームが数多くの事例を観測する中で導き出した、理論的な傾向を視覚化したものである。

出典: Yegor Denisov-Blanch (Stanford)「Does AI Actually Boost Developer Productivity? (100k Devs Study)」AI Engineer, 2025年7月24日, 15:35~ （動画内のグラフをもとに筆者が作成）

提示されたグラフでは、コードベースの規模が大きくなるにつれ、AIの寄与率が急激に減衰していく曲線が描かれている。このグラフは、縦軸に「AIによる生産性向上の推定効果」、横軸にコードベースサイズ（1K LOCから10M LOCまでの対数スケール）を取る。

現実のプロジェクトに目を向けると、この減衰は決して無視できない。業務システムやWebサービスのブラウンフィールドプロジェクトが扱うコードベースが、1-2K LOCということは稀だろう。ある調査によれば、一般的なソフトウェア開発におけるコード行数の中央値は31.8K LOC、75パーセンタイル値は96.1K LOCに達する*20。

この統計を先の曲線に当てはめるならば、現代のブラウンフィールドプロジェクトの多くは、そのコードベース規模により、AI導入効果が大きく減衰していることになる。

【洞察】物理的な量そのものがAIの推論精度を汚染する

Denisov-Blanchは、規模の拡大がAIのパフォーマンスを低下させる背景として、以下の3点を挙げている*21。

  1. コンテキストウィンドウの限界:
    • 大きなコンテキストウィンドウを持つモデルであっても、扱うコンテキスト長（トークン数）が増えるほど、コーディングパフォーマンスのスコアが落ちてしまう。
  2. SN比:
    • 本来注目すべきロジック以外の「ノイズ」の混入が増え、モデルを誤った推論へと誘導する。
  3. 複雑性（Complexity）:
    • 規模に比例して依存関係やドメインロジックが増え、複雑性が高まる。

これらの要因のうち、2と3は本質的には「コードベースの複雑性」に帰属する問題であり、既に考察した通りである。

したがって、巨大なコードベースを扱う際に生じる「規模そのもの」に起因する影響を解明するため、ここでは「コンテキストウィンドウの限界」に焦点を絞って掘り下げたい。

【戦略】効果的なコンテキストエンジニアリングでスマートゾーンを維持する

大容量のコンテキストウィンドウを持つモデルを採用するのは一つの解決策だが、無計画な対話を重ねれば、そのリソースは瞬時に枯渇する。モデルによっては、容量が逼迫すると古い情報を自動圧縮（auto compaction）するものもあるが*22、それはあくまで対症療法に過ぎない。

Horthyは、ウィンドウ容量の半分に満たない段階でもパフォーマンスの低下が始まると指摘し、その閾値を超えた領域を「ダムゾーン（dumb zone）」と定義した。例えばClaude Codeにおいては、容量の約40%がその境界線になると述べている*23。

そこで求められるのは、コンテキストを最小限に保ち、AIのパフォーマンスを最大化させる「スマートゾーン（smart zone）」を維持する工夫だ。そのためには、コンテキストウィンドウの内部構造に対する深い理解と、戦略的なコンテキストエンジニアリングが不可欠となる。

ウィンドウを占有するのは、プロンプトやコードだけではない。システムが予約している領域に加え、MCPツールのメタ情報や CLAUDE.md といったユーザー定義領域も含まれる。特に後者を無秩序に肥大化させている場合、AIの「思考の余白」を自ら奪っていることに他ならない。

コンテキストとは、単に情報を詰め込めばよいという性質のものではないのだ。だからこそ、次の4点に意識を向けたい。

  1. コンテキストのリフレッシュ*24:
    • AIとの対話が迷走し始めたら、/clear などを使い、コンテキストをリセットして新しいウィンドウでやり直す。
  2. サブエージェントによる階層化*25:
    • サブエージェントを活用することで、推論のプロセスを各々のウィンドウに閉じ込める。メインエージェントには「結果」のみを返却させることで、親ウィンドウの汚染を防ぐ。
  3. 動的なスキルロードの活用*26:
    • エージェントスキルを利用し、必要な情報のみをオンデマンドで読み込ませる。常にすべてのドキュメントを読み込ませるような静的な管理を避ける。
  4. 意図的な圧縮（Intentional compaction）*27*28:
    • RPIのようにプロセスをフェーズ分けし、各段階の成果をMarkdown等に集約する。次フェーズでそれらを参照することで、中間過程の膨大なトークンを破棄し、本質的なコンテキストの密度を高める。

これらの手法は、単なる機能の知識にとどまらず、コンテキストウィンドウの構造やAIコーディングツールの内部挙動に対する深い洞察、そして実践を通じた習熟が不可欠であることを示唆している。

従来のコーディングにおいて、優秀なエンジニアがIDEやエディタを使いこなしていたのと同様に、AI時代においてもツールの習熟は不可欠なのである。

さいごに: 「人間にとって良い環境は、AIにとっても良い」

ここまで考察してきたリポジトリ戦略、コードの複雑性、そして規模の問題は、すべて地続きの課題である。大規模なコードベースは宿命的に複雑性を内包し、大規模化を避けようとすればリポジトリを分散管理の方向へ進ませる。

しかし、いずれにしても本質的な問いは、「AIがそのタスクを遂行するために必要なコンテキストを、ノイズなく、かつ地続きに把握できているか」という点に集約される。

AIが真にパフォーマンスを発揮できるのは、境界が明確で、不必要な依存がなく、関心が適切に分離された見通しの良いコードベースだ。これは、私たちが理想としてきたソフトウェアアーキテクチャそのものに他ならない。

セッションの中でKanat-Alexanderが述べた「人間にとって良い環境は、AIにとっても良い（What's good for human is good for AI）」という言葉*29が、それをよく言い表している。

参考文献

*1:Molisha Shah「Monorepo vs Polyrepo: AI's New Rules for Repo Architecture」Augment Code, 2025年10月11日, What We Thought We Knew

*2:Nicholas Arcolano「AI Coding Tools Not Paying Off? Your Code Architecture Might Be to Blame.」Jellyfish, 2025年10月16日

*3:Nick Arcolano（Jellyfish）「What Data from 20m Pull Requests Reveal About AI Transformation」AI Engineer, 2025年11月25日, 14:32~

*4:Yegor Denisov-Blanch (Stanford)「Does AI Actually Boost Developer Productivity? (100k Devs Study)」AI Engineer, 2025年7月24日, 9:06~

*5:Nick Arcolano（Jellyfish）「What Data from 20m Pull Requests Reveal About AI Transformation」AI Engineer, 2025年11月25日, 14:32~

*6:Rohit Radhakrishnan「Monorepo vs. Polyrepo for Multi-Stack Vibe Coding: A Developer’s Decision Framework」Medium, 2025年9月12日

*7:Molisha Shah「Monorepo vs Polyrepo: AI's New Rules for Repo Architecture」Augment Code, 2025年10月11日, What This Means in Practice

*8:Yegor Denisov-Blanch (Stanford)「Does AI Actually Boost Developer Productivity? (100k Devs Study)」AI Engineer, 2025年7月24日, 13:21~

*9:Yegor Denisov-Blanch (Stanford)「Does AI Actually Boost Developer Productivity? (100k Devs Study)」AI Engineer, 2025年7月24日, 6:18~

*10:フレデリック・P・ブルックス,Jr. 著, 滝沢 徹, 牧野 祐子, 富澤 昇 訳『人月の神話【新装版】』丸善出版, 2014年, 第16章

*11:Jake Nations（Netflix）「The Infinite Software Crisis」AI Engineer, 2025年12月21日, 07:42~

*12:Max Kanat-Alexander (Capital One)「Developer Experience in the Age of AI Coding Agents」AI Engineer, 2025年12月24日, 15:00~

*13:Rich Hickey「Simple Made Easy」InfoQ, 2011年10月20日

*14:Dex Horthy（HumanLayer）「No Vibes Allowed: Solving Hard Problems in Complex Codebases」AI Engineer, 2025年12月3日, 2:56~

*15:Jake Nations（Netflix）「The Infinite Software Crisis」AI Engineer, 2025年12月21日, 10:55~

*16:Dex Horthy（HumanLayer）「No Vibes Allowed: Solving Hard Problems in Complex Codebases」AI Engineer, 2025年12月3日, 7:45~

*17:Dex Horthy（HumanLayer）「No Vibes Allowed: Solving Hard Problems in Complex Codebases」AI Engineer, 2025年12月3日, 17:41~

*18:「Lehman's laws of software evolution」Wikipedia

*19:Yegor Denisov-Blanch (Stanford)「Does AI Actually Boost Developer Productivity? (100k Devs Study)」AI Engineer, 2025年7月24日, 15:35~

*20:『ソフトウェア開発分析データ集2022』独立行政法人情報処理推進機構（IPA）, 2022年, P16 表1-2-5 SLOC規模

*21:Yegor Denisov-Blanch (Stanford)「Does AI Actually Boost Developer Productivity? (100k Devs Study)」AI Engineer, 2025年7月24日, 16:15~

*22:平川 知秀「Claude Codeのコンテキストウィンドウを完全に理解する」gihyo.jp, 2025年12月23日, 「Auto Compactの領域」

*23:Dex Horthy（HumanLayer）「No Vibes Allowed: Solving Hard Problems in Complex Codebases」AI Engineer, 2025年12月3日, 5:55~

*24:Dex Horthy（HumanLayer）「No Vibes Allowed: Solving Hard Problems in Complex Codebases」AI Engineer, 2025年12月3日, 3:09~

*25:Dex Horthy（HumanLayer）「No Vibes Allowed: Solving Hard Problems in Complex Codebases」AI Engineer, 2025年12月3日, 6:28~

*26:Barry Zhang & Mahesh Murag（Anthropic）「Don't Build Agents, Build Skills Instead」AI Engineer, 2025年12月9日, 4:21~

*27:Dex Horthy（HumanLayer）「No Vibes Allowed: Solving Hard Problems in Complex Codebases」AI Engineer, 2025年12月3日, 3:48~

*28:Dex Horthy（HumanLayer）「No Vibes Allowed: Solving Hard Problems in Complex Codebases」AI Engineer, 2025年12月3日, 7:26~

*29:Max Kanat-Alexander (Capital One)「Developer Experience in the Age of AI Coding Agents」AI Engineer, 2025年12月24日, 17:42~

RPI/SDD/AI-DLCによるAI-native開発──AI-assisted, AI-firstのさらにその先へ

gooseに代表される「RPI」、KiroやSpec Kitなどの「SDD（仕様駆動開発）」、そしてAWSの「AI-DLC」。これら次世代のアプローチは、AI-nativeな開発プロセスを、単なる概念から具体的な実装へと押し上げつつある。

いずれもAI-drivenという点では共通しており、広義にはAI-DLC（AI駆動開発ライフサイクル）の実践手法と捉えられるが、その内実は三者三様だ。複雑なコードの改修に焦点をあてるRPI, よく練られた仕様に基づいてコードを組み上げるSDD, そして組織全体のプロセス変革を目指すAWSのAI-DLC。課題解決の主眼も成果物の位置づけも大きく異なる。

本稿ではまず、“AI-native” な手法と “非AI-native” な手法の違いを明らかにする。そのうえで、前者の最新アプローチであるRPI/SDD/AI-DLCが持つ思想の違いを整理していく。

🎧 本記事のAI音声解説版をポッドキャストで公開中

open.spotify.com

【ご視聴時の注意点】AI生成解説のため、内容には一部、原文から逸脱した軽微な誤りや、不自然な表現が含まれる可能性があります。大筋の理解には役立ちますが、詳細や正確な情報については、引き続き本ブログ記事をご確認ください。

AIネイティブ（AI-native）と非AIネイティブ（AI-assisted, AI-first）

現状のAI活用状況は、まだまだLiftの域を越えず、Shiftに至っていない、というのが私の印象だ。

この「Lift」と「Shift」という言葉は、ソフトウェアシステムのクラウド化が進み始めた2010年代によく使われた。オンプレミスのシステムをそのままクラウドに移行するのがLift、アーキテクチャや構成をクラウド前提で最適化する方式がShiftである。

クラウドのポテンシャルを最大限に引き出すには、Liftだけでは不十分であり、Shiftしなければならなかった。そうすることで、システムがはじめて “クラウドネイティブ” と呼ばれるものになった。

AIを活用したSDLC/PDLCも同様であり、現状はまだLiftであってShiftに至っていない。すなわち、AIネイティブ化されておらず、AIエージェントのポテンシャルを完全には引き出せていないということだ。

AI導入によるワークフローの変化には、次の3段階がある。なお、これらの用語に統一化された明確な定義があるわけではなさそうなので、多分に私の解釈に基づいていることに留意してほしい。

  1. AI-assisted: 既存のワークフローをそのままに、部分的な作業をAIで効率化するアプローチ
  2. AI-first: 既存のワークフローの中で、AIの活用を最優先に置くアプローチ
  3. AI-native: ワークフローそのものを、AIエージェント前提に構築するアプローチ

つまり、“組織を動かすシステム” の最適化を “既存のワークフローの延長線上” で実現するか（1や2）、“AIエージェントを基盤として” 再構築するか（3）で、AIネイティブかどうかが分かれる。無論、後者がAIネイティブである。DORAレポート2025では前者を「Augmenting」, 後者を「Evolving」と呼んでいる*1。

GitHub Copilotを振り返れば、コード補完は典型的なAI-assistedであり、Chatもまた、その延長線上に位置づけられる。いずれも、従来のままのワークフローを前提とした支援にとどまっている。

しかし、2025年5月から6月にかけて、Claude Codeの正式リリースやGitHub Copilot ChatへのAgent modeの搭載などが進んだことで状況は変わり始めた。これにより、AI-firstな運用が現実的な選択肢となり、さらにAI-nativeへと向かう可能性も視野に入った。

とはいえ、実際の現場では、多くがAI-firstの段階にとどまっていたのではないだろうか。その背景には、AIエージェントの活用が、依然として個人単位のワークフローに閉じており、組織やプロセス全体の再設計にまでは踏み込めていない、という構造的な要因がある。

「個人の生産性は高まったが、チーム・組織の生産性は大きく変わらない」という声を耳にすることがある。これこそ、“個人単位のワークフローに閉じた現状” を、端的に言い表している。

AI-firstが限界を迎える3つの構造的理由

AI-firstという言葉自体には、大きな解釈の幅が存在する。本節ではその中でも、明示的なプロセス設計を伴わず、アドホックにプロンプトを与えながら、AIエージェントと協働で成果物を作り上げていく開発スタイルをAI-firstとして扱う。

そのうえで、このスタイルには本質的な限界がある。いくつかの問題を抱えているからだ。

そのなかでも特に次の3点が大きい。これらに共通しているのは、“人間が頭の中で管理しているコンテキスト” を、そのままAIエージェントに丸投げする点にある。

  1. コードが複雑になりやすい / 複雑なコード相手ではうまく機能しない:
    • AIは「シンプル」化より「簡単」に実現する方法*2を好む。結果として複雑化が進行する。
  2. スペックドリフトが生じやすい:
    • 仕様の漏れや曖昧さをAIが勝手に “それっぽく” 補完してしまう。人間がそれに気づけない。
  3. チーム・組織の生産性が、個人のAI活用スキルに大きく依存する:
    • AIを使いこなす技術が「個人の職人技」に留まり、チーム・組織全体を底上げする仕組みが欠如している。

1について補足すると、こうなる理由の1つは、AIエージェントが、本質的複雑性と偶有的複雑性を区別できないことで生じる*3。コードベース上でこれらが絡み合って存在するからだ。

ソフトウェアには、解決すべき問題そのものに起因する「本質的複雑性」と、過去の回避策や古いフレームワークによる「偶有的複雑性」を内在している*4。後者は技術的負債にもなり得る。

AIはこの二つが絡み合った状態から「どこでビジネスロジックが終わり、どこからが古い仕組みなのか」という境界線を見出すことができず、単に古いロジックの上に新しい層を重ねてしまう。つまり、“簡単に実現する方法” を選択しがちだ。結果、コード設計はシンプルにならず、より複雑化する。

これが、AIエージェントに「リファクタリングして」と投げても、うまくいかないことがある理由の1つなのだろう。

AIで加速した世界では、こうして複雑化したコードの蓄積も加速する。あっという間に、追加開発や保守が困難な状況に陥ってしまうのだ。

1の複雑性の話だけでなく、2や3についても、対策として採用されやすいのは、人間の介入を増やす方向性だろう。つまり、AIによる最終成果物を、人間が “後から” 丹念に “レビュー” することでカバーするアプローチである。

しかし、これでは時間もかかる上に、手戻りも大きい。これが、AI導入効果の制約となる。AIによる加速が、そのままレビューという “人間のボトルネック” を肥大化させる結果となり、組織としての真の導入効果を損なってしまうのだ。

AI-nativeなフロー: ワーク&ハンドオフからインタラクティブAIフローへ

AI-nativeな手法の特徴は、最終的な実装（コード生成）の前に、コンテキストを構造化し、実行の指針となる中間成果物を段階的に確定させる開発プロセスにある。これらを、“AIエージェントが駆動” して、人間と協働でフローを進める。

こうすることで、AIの非決定性の削減に注力し、期待する成果物を得ようとする。つまり、後ではなく、先に手間をかけるのだ。そこで作成された中間成果物が、AIエージェントに対する制約となる。

一見するとウォーターフォールモデルへの回帰のようでもあるが、そうではない。フィードバックサイクルの長さが違う*5。AI-nativeなワークフロー/プロセスのサイクルは、数時間から数日レベルだ。これは、アジャイル手法による数週間レベルよりもはるかに短い。

また、工程単位での分業ではない点も異なる。特に、SDDや、AWSのAI-DLCは、クロスファンクショナルやペア・モブで全工程を進めることを想定されたものだ。

従来のような、“ワーク&ハンドオフ” の連続によるフローは、AI時代には適さない。着手した個々のワーク（WIP）がAIで加速するほど、ハンドオフでの待ち時間が最大のボトルネックとなるからだ。

そのうえ、工程をまたぐたびに生じる「引き継ぎのムダ*6」によって情報劣化が生じる。すなわち、コンテキストが欠落することでAIによる “勝手な推論” が混入し、スペックドリフトなどを誘発する。

だからこそ、全工程をクロスファンクショナルに進め、コンテキストをシームレスに繋ぎ、共有し続けることが合理的となる。

その最適解が、AIエージェントが情報の構造化をリードし、人間がその場で判断を下す「インタラクティブAIフロー」とでも言うべきスタイルだ。これは、Human-in-the-loopのもとで、人間が高速にOODAループを回し続けるプロセス*7に他ならない。

人間はパイロットであり、AIエージェントは航空機の制御システムだとイメージするとよいだろう。

RPI/SDD/AI-DLCの実践がもたらすAI-native化

RPI, SDD, そしてAWSのAI-DLC。これらは呼称こそ異なるが、いずれもインタラクティブAIフローを体現する、紛れもないAI-nativeな開発アプローチである。

少々ややこしいのは、RPIをSDDと呼ぶこともでき*8、SDDをAI-DLCの一形態として定義する見方もある*9という点だ。これらを包括的に捉えるならば、すべては AI-DLC（AI-Driven Development Life Cycle, AI駆動開発ライフサイクル） という大きな概念に集約される。

では、なぜ複数のモデル名が存在するのか。

それは、それぞれが解決しようとする “課題の重点” が異なっているからだ。本節では、そこに焦点をあてる。

RPI（Research, Plan, Implement）

RPIが目指すのは、“複雑なコードベースに対する適切な変更を可能にする” ことだ。AIによる技術的負債予備軍の大量生産を防ぐため、人間がリサーチ結果をレビューし、アーキテクチャ上の決定を計画に固定するプロセスである。

このモデルは、オープンソースのAIエージェントであるgooseで用いられていることでも知られており、ドキュメントにはこう記されている。

多くの人は、AIエージェントを「このコードをリファクタリングする」、「この機能を削除する」、「この新機能を追加する」といった形で直接実行に移します。これは、特に小さな変更やコードベースではうまく機能する場合もありますが、複雑な変更ではうまくいかないことがよくあります。

引用: 「Research → Plan → Implement Pattern | goose」ページ内の文章をGoogle翻訳

gooseでは、複雑なコードベースの変更を体系的に処理するために、レシピを用いた構造化されたRPIワークフローを採​​用しています。

引用: 「Research → Plan → Implement Pattern | goose」ページ内の文章をGoogle翻訳

ワークフローは、その名が示す通りだ。

Research（調査） → Plan（実装計画） → Implement（実装実行）

gooseのRPIでは、このPlanによる成果物を「Source of Truth」としている。徹底的なResearchに基づき、Planが精緻に組み上がれば、AIによるImplementの再現性と成功率は飛躍的に高まる。

RPIは、コンテキストウィンドウを適切に活用するための戦略である点にも注目したい。

AIエージェントは、巨大すぎるコードベースや大量のドキュメントといった膨大な情報を前にすると、推論精度が著しく低下する傾向がある。そのため、人間がアドホックなプロンプトで直接的にImplementを命じるのは迷走を招くおそれがある。だからこそ、事前にResearch, Planという段階を経て、情報の絞り込みを行う。

実際、gooseのRPIレシピでは、Research工程においてサブエージェントを活用し、メインのコンテキストウィンドウをノイズで圧迫させない工夫も見られる。

AIにとってのコンテキストウィンドウは、人間の脳で言うところの「ワーキングメモリ」だ。それはすなわち、AIにとっての「認知負荷」を考慮に作業を進める必要性を示している。たとえ巨大なコンテキストウィンドウを持っていても、溢れてしまうこともあれば、迷子（Lost in the Middle）になることもある。

つまりRPIとは、AIエージェントの “認知負荷” を適切に管理する設計プロセスなのだ。情報の海から必要なコンテキストだけをすくい上げ、純度の高い “Plan” に昇華させることで、最終的な “Implement” の成功確率を決定論的なレベルへと近づけるための戦略なのだ。

SDD（Spec-Driven Development）

RPIが「手順の合意」に重点を置くのに対し、SDDは “振る舞いの合意” に重点を置く。仕様書の中に “期待される入出力” や “満たすべき制約” を明文化し、それを人間とAIの間での “検証可能な契約” へと昇華させるのが、その本質的な狙いである。

これにより、AIが実装時に行う恣意的な補完（スペックドリフト）を抑止し、成果物が要件を満たしているかを客観的に評価可能な状態にする。

ワークフローは、各フレームワークの実装に準じるが、概ね次の3ステップで構成される。

Specify（仕様策定） → Plan（実装計画） → Implement（実装実行）

Kiroのモデルに寄せたcc-sddでのスラッシュコマンド*10では、次のようになる。

  • Specify: /spec-init, /spec-requirements
  • Plan: /spec-design, /spec-tasks
  • Implement: /spec-impl

GitHubのSpac Kitではこうだ。

  • Specify: /specify
  • Plan: /plan, /tasks
  • Implement: /implement

RPIでは、Planの成果物を「Source of Truth（SoT）」としていたが、SDDではその位置づけにおいて思想が分かれる。

ひとつは、Specifyによる成果物を永続的なSoTとする思想だ。従来の開発ではコードをSoTとしていた。しかしこの思想では、コードを一種の副産物とみなす*11。従って、エンジニアがコードを直接変更することはなく、仕様を変更し、AIに再生成させることでコードを追随させる。

もうひとつは、Specifyによる成果物を「コードを正しく生成するためのガイド」と位置づける思想だ。ここでのSoTは、従来通りあくまでもコードである。仕様書はAIとの合意形成を加速させ、実装の精度を高めるための中間成果物として機能する。

これらのことから、SDDには3つのレベルがあるとされる*12。

  1. Spec-first: 熟考された仕様を最初に書き、それをガイドとしてAIが開発を行う。あくまでその場のタスクを完結させるための手法。
  2. Spec-anchored: タスク完了後も仕様を保持し続ける。機能の拡張やメンテナンスの際にも常にその仕様を起点とし、継続的に活用する。
  3. Spec-as-source: 仕様をSoTとする究極の形。人間は仕様のみを編集し、コードには一切触れない。コードは仕様から生成される副産物。

先に挙げたcc-sddやSpec Kitは、1のSpec-firstに位置づけられるだろう。2のSpec-anchoredを目指している可能性もある。

いずれにしても、実装根拠となるドキュメントがコードと共にリポジトリに管理されることで、コンテキストの完全なトレーサビリティが確保される点は、極めて大きな恩恵だ。これにより、将来の拡張時においても、AIは過去の意図を正確に踏まえた推論が可能になる。

また、SDDはこれらのワークフローをペアやモブで実施することも意識している。AIが構造化を駆動し、人間がその場で判断を下す。この同期的な協働こそが、従来の「ワーク＆ハンドオフ」型のフローから脱却し、待機時間をゼロに抑え、情報の劣化を最小化する解なのである。

AWSのAI-DLC（AI-Driven Development Life Cycle）:

AWSが定義するAI-DLCは、AIの自律性とスピードを最大限に引き出すためのプロセス・体制を定義し、組織全体をAIネイティブ化するための方法論（メソドロジー）である。

ここで重視されるのは、AIとの共生を前提に再構築された「儀式」そのものだ。特に、AIがファシリテーターとして人間に問いを投げかけ、作業を誘導する「会話の方向の逆転（Reverse the Conversation Direction）」を基本原則とする。

ワークフローは以下の3段階で構成される（日本語訳はAWSドキュメント*13に準拠）。

Inception（開始） → Construction（構築） → Operations（運用）

Inception: ビジネス上の「Intent（意図）」を、開発可能な最小単位である「Unit」へと分解するフェーズ。AIが「モブ・エラボレーション」の進行役となり、ユーザーストーリーや非機能要件、テスト基準を提案。チーム全員がその場で検証・修正を行うことで、認識の齟齬を瞬時に解消する。これはRPIやSDDにおけるResearch/Specifyを、より組織レベルへ昇華させたものといえる。

Construction: Unitをデプロイ可能な成果物へと変換するフェーズ。AIがモデリングからコード生成、ユニットテストまでを連続的に実行する。人間は「モブ・プログラミング」や「モブ・テスティング」を通じて成果物を即座に評価し、品質とビジネス目標への整合性をリアルタイムで担保する。

Operations: システムのデプロイ、監視、および保守を行うフェーズ。AIがテレメトリデータを分析して異常検知やSLA違反の予測を自動化し、解決アクションを提案する。人間は提案の検証と承認に専念することで、運用の圧倒的な効率化を実現する。

“DLC” と名乗るだけあって、Operationsまでカバーしている点が、RPIやSDDとは大きく異なる。

AWSのAI-DLCもまた、SDDと同様に実装根拠のトレーサビリティ確保を意図している。AIが生成したすべてのUnitと決定プロセスが記録されることで、ブラックボックス化を防ぐ設計となっている。

ホワイトペーパーのAppendix Aとして付属されたプロンプトを試すことで、その片鱗に触れることができる。また、AWS LabsのGitHubに、aidlc-workflowsというリポジトリもあるので、こちらを試してみるのもよいだろう。これらはKiroやAmazon Q Developerへの導入が可能だ。

どれを導入するかより、どう使い分けるか

AI-nativeなアプローチ（RPI, SDD, AI-DLC）と、非AI-nativeなアプローチ（AI-assisted / AI-first）は、択一問題ではない。いずれも銀の弾丸ではなく、少なくとも現時点では、解決すべき課題の性質に応じて戦略的に使い分けることこそが肝要だろう。

まず、RPI, SDD, AI-DLCは、先述した次の3つの問題を解消・軽減する対策として位置づけられる。ここから、選択の基準が見えてくる。

  1. コードが複雑になりやすい / 複雑なコード相手ではうまく機能しない → RPI
  2. スペックドリフトが生じやすい → SDD
  3. チーム・組織の生産性が、個人のAI活用スキルに大きく依存する → AI-DLC（SDD）

これを踏まえたうえで検討するなら、それぞれの用途を以下のように基準化できる。

小規模なバグ修正、定型的なリファクタリング

  • アプローチ: 非AI-native
  • 判断基準: 前提知識が限定的で、AIが迷走するリスクが低いとき。ドキュメントを生成・レビューするオーバーヘッドを避け、AIへの直接的な指示で手軽さと速度を優先するシーン。

影響範囲が不明瞭、技術的に複雑性の高い既存コードの変更

  • アプローチ: RPI
  • 判断基準: 巨大なコードベースや古い負債に手を入れる際、いきなりコードを書かせるとAIが破壊的な変更を行うリスクがあるとき。事前の調査と計画によって、AIの認知負荷を制御する必要があるシーン。
  • 補足: 現時点で言えば、非常に複雑なものについては、非AI-nativeなアプローチや人手に頼る手法が効果的な場合もある。

単機能の開発

  • アプローチ: SDD
  • 判断基準: リファインメントによって既に最小単位に分割されたプロダクトバックログアイテムを扱うとき。実装前に「振る舞いの契約」を交わし、スペックドリフトを抑止したいシーン。

抽象度が高く、分割・詳細化前の開発

  • アプローチ: AI-DLC（InceptionからConstructionまで）
  • 判断基準: ビジネス上の意図がまだ抽象的で、それを開発可能な単位（Unit）へ分解する段階からAIを介入させたいとき。AIをファシリテーターとして、チーム全体の合意形成を加速させたいシーン。

おわりに: 成熟を待つより、まずやってみる

AIエージェントによるSDLC/PDLCの変容は未だ過渡期の真っ只中にあり、今後も変化が続くだろう。今日採用した技術や方法論が明日には別のものに置き換わっている、といった事態も珍しくはない。

こうした状況下では、新しいツールや手法への着手を億劫に感じるのも無理はない。導入に要した労力が、技術の陳腐化によって無駄になることを避けたいという心理は、合理的ですらある。

これは、RPIやSDD, AWSのAI-DLCも例外ではない。実際、SDDは、Technology Radarにおいて未だ「Assess」のフェーズにある（2026年1月時点）。

しかし、成熟を待っていては、その間に個人や組織の成長は止まってしまう。たとえ成熟期が訪れたとしても、そこに至るまでの試行錯誤や変遷を知らぬままでは、技術の “本質” を見抜き、使いこなすことは困難だろう。

変化の激しい今だからこそ、あえて荒削りな技術に触れ、その違いや進化の経緯を肌で感じるべきだ。その実戦的な理解の積み重ねこそが、次の新しい波を最大限に活用する力を養い、ひいては個人としても組織としても、競争優位を生む源泉になるのではないだろうか。

参考文献

*1:2025 DORA State of AI-assisted Software Development Report」DORA, 2025年, P82-P83

*2:Rich Hickey「Simple Made Easy」InfoQ, 2011年10月20日

*3:Jake Nations（Netflix）「The Infinite Software Crisis」AI Engineer, 2025年12月21日, 「Simple vs. Easy (Rich Hickey’s Definition) 」07:40~

*4:フレデリック・P・ブルックス,Jr. 著, 滝沢 徹, 牧野 祐子, 富澤 昇 訳『人月の神話【新装版】』丸善出版, 2014年, 第16章

*5:Liu Shangqi「Spec-driven development: Unpacking one of 2025’s key new AI-assisted engineering practices」Thoughtworks United States, 2025年12月4日, 「Is spec-driven development just a return to waterfall?」

*6:メアリー・ポッペンディーク, トム・ポッペンディーク 著／平鍋健児 監訳／高嶋優子, 天野勝 訳『リーン開発の本質 ソフトウエア開発に活かす7つの原則』日経BP, 2008年, 第4章

*7:mtx2s「AI導入により生じる“自動化のパラドックス”と“デスキリング”に打ち勝つ」mtx2s on note, 2025年12月1日

*8:Jake Nations（Netflix）「The Infinite Software Crisis」AI Engineer, 2025年12月21日, 「Simple vs. Easy (Rich Hickey’s Definition) 」11:08~

*9:「GitHub - gotalab/cc-sdd: Spec-driven development (SDD) for your team's workflow. Kiro style commands that enforce structured requirements→design→tasks workflow and steering, transforming how you build with AI. Support Claude Code, Codex, Cursor, Github Copilot, Gemini CLI and Windsurf.」

*10:「cc-sdd/docs/guides/ja/command-reference.md at main · gotalab/cc-sdd · GitHub」

*11:Liu Shangqi「Spec-driven development: Unpacking one of 2025’s key new AI-assisted engineering practices」Thoughtworks United States, 2025年12月4日, 「Defining spec-driven development and competing interpretations of it」

*12:Birgitta Böckeler「Understanding Spec-Driven-Development: Kiro, spec-kit, and Tessl」martinfowler.com, 2025年10月15日

*13:Masao Kanamori 訳「AI 駆動開発ライフサイクル:ソフトウェアエンジニアリングの再構築」Amazon Web Services ブログ, 2025年8月8日

ソフトウェアエンジニアの本質は“課題解決”なのか？

「エンジニアの本質は課題解決である」というよく聞く台詞に対し、ずっと、軽い違和感があった。いや、決して強い反論があるわけではない。しかし、なぜかこの言葉が響いてこない。

この感覚がはっきりと表出したのは、実は最近だ。以前から感じてはいたものの、強く意識することはなかった。突き詰める対象になるほど、問題として捉えてこなかったのだろう。

だが、ソフトウェアエンジニアリングの現場にAIエージェントが入り込んだ今こそ、この違和感を言語化すべきだと思い至った。エンジニアが多くの時間を割いてきたコーディングは、AIが代替しつつある。その精度は高まり、担える領域も、確実に広がっている。

だからこそ、エンジニアという職種の本質を、あらためて問い直す必要があるのではないか。「エンジニアの本質は課題解決である」という言葉は、そのためのよい切り口になる。

🎧 本記事のAI音声解説版をポッドキャストで公開中

open.spotify.com

【ご視聴時の注意点】AI生成解説のため、内容には一部、原文から逸脱した軽微な誤りや、不自然な表現が含まれる可能性があります。大筋の理解には役立ちますが、詳細や正確な情報については、引き続き本ブログ記事をご確認ください。

「エンジニアの本質は課題解決である」という言葉には限定性と多義性がある

違和感をもう少し掘り下げてみると、この言葉が持つ「限定性」と「多義性」という性質に気づく。つまり、範囲を絞り込み、同時に意味を広げてしまう──その二つの性質が、同時に含まれている。

この言葉は、次のような構造を持っている。

  1. 「エンジニアの」という限定性
  2. 「課題解決」という言葉の多義性
  3. 「課題解決である」という限定性

「エンジニアの」と限定する不自然さ

そもそも「課題解決」という営みは、エンジニア職に固有のものだろうか。

ビジネスに関わる多くの職種にとって、程度の差はあっても、その本質は課題解決にあるはずだ。企業のミッションは、抽象度をあげれば課題解決に行き着く。そこに参加する限り、いずれの職種の本質も、課題解決と言える。

したがって、特定の職種を指して、その本質が「課題解決にある」と語ることに不自然さがある。

おそらくこの限定性の背景には、「手段が目的化しやすい」という、エンジニアという専門職特有の事情があるのではないか。

専門職には、その専門技術を追求する面白さがある。そこに没頭するがあまり、何のために技術を行使しているのかを忘れやすい。これは、デザイナーがデザイン性にばかり気を取られ、機能性を見失ってしまう構造とよく似ている。

それを戒（いまし）める言葉として、「エンジニアの本質は課題解決だ」という表現が使われるのだ。つまり、「コードを書くこと」そのものを、エンジニアの仕事だと捉えすぎることへの “批判” も少なからず含まれているのだろう。

「課題解決」という言葉への解像度の低さ

「課題解決」という言葉は、響きがビジネス的で格好良いが、便利に使われすぎる側面もある。何を指しているのか、分かったようで分からない。

「エンジニアの本質は課題解決」と言ったとき、どこからどこまでを指しているのだろうか。一般に「課題解決」と呼ばれる営みは、少なくとも次のようなプロセスを含んでいる。

  1. 現状把握: 今、何が起きているか
  2. あるべき姿の設定: 本来どうなっているのが理想か
  3. 問題の特定: 現状と理想のギャップは何か
  4. 原因分析: なぜそのギャップが生じているのか
  5. 課題の設定: ギャップを埋めるために、具体的に何を解決すべきか
  6. 解決策（ソリューション）の実行: 具体的な手段を講じる

では、この一連のプロセス全体が「エンジニアの本質」なのか。それとも、最後の6だけを指して「課題解決」と呼んでいるのだろうか。ここが誤解を受けやすい。

本来ここで言われているのは、よく知られた「三人の石切り工」の話に近いのだろう。たとえ6だけを担っていたとしても、1から6全体を通して課題を解決している、という認識を持てということだ。

しかし、「課題解決」という言葉は、文脈によっては受託開発の構造を想起させやすい。そこではウォーターフォール型の工程分離が前提となり、1から5はいわゆる「上流」、6の実行は「下流」として、異なる役割が割り当てられることが多い。

その結果、「課題解決」という言葉が、エンジニアが主に担う6の役割を指す責務の話として受け取られてしまう場合がある。

さらに、このような「あるべき姿と現状のギャップ」を対象とする課題解決だけが、エンジニアリングの営みではない。

新しい価値を生み出すことや、既にある価値を維持し、将来へ継承していくことは、必ずしも明確な「問題」から始まるわけではない。それでも、エンジニアリングの重要な役割であることに変わりはない。

こうした営みもまた、抽象度を上げれば「課題解決」という枠組みの中に含めて捉えることができる。そして、その広がりこそが、この言葉を分かりにくくしている理由でもあるのではないだろうか。

「課題解決である」との断定によって否定される多義性

「である」という限定的な言い回しは、「課題解決」が持つ多義性を包み込む余地を、かえって狭めてはいないだろうか。

その結果、課題解決が狭義の意味に閉じてしまうような印象を与えかねない。聞き手の意識が、価値創造や維持・継承へと向かう余地を、あらかじめ狭めてしまっているようにも感じられる。

いや、むしろ話し手自身も、狭義の課題解決という枠組みの中でしか、物事を捉えられていないのではないか。それは、ソフトウェアエンジニアという職能の可能性を、静かに狭めてしまう行為にもなり得る。

私はそこに、危うさを感じるのだ。

エンジニアリングの提供価値とは何か？

エンジニアの本質とは、つまりエンジニアリングの生み出す価値そのものと言える。そこには、少なくとも次の三つの観点がある。

  • 複雑性を秩序に変換する
  • 再現性と効率性を創出する
  • 持続可能性を維持する

複雑性を秩序に変換する

ソフトウェア開発とは、そもそも不確実なものを扱う営みである。

エンジニアリングの本質は、「不確実性の削減」と述べられることもある*1。「不確実性コーン」が示すように、ソフトウェア開発は、不確実な状態から確実な状態へと変えていく活動だ。

言い換えれば、絶え間ない探索と論理を手がかりとして、複雑性に秩序をもたらす営みである。

再現性と効率性を創出する

ソフトウェアは、同じことを、同じように、何度でもできる。再配布可能な知識やスキルのパッケージでもある。

ビジネス向けの業務アプリケーションや、コンシューマー向けの便利ツールは、その典型例だ。ソフトウェアゲームもまた、同じ構造を持っている。

さらに、ソフトウェアで処理される知識やスキル、手続きは、人間が処理するよりも速く、そして安定している。その結果として、人間の能力は拡張される。

持続可能性を維持する

ソフトウェアは、完成した瞬間から “変わり続けること” を宿命付けられた成果物だ。変更が容易でなければ、もはや “ソフト” とは言えず、その価値が失われていく。

ソフトウェアの稼働期間が長いほど、その “振る舞い” に変更が入る。そこに耐えうる “構造” を維持し進化させ続けること。それが、単なるプログラミングとエンジニアリングを分ける*2*3。

こうした持続可能性の維持は、設計や実装の巧拙（こうせつ）だけで決まるものではない。むしろ、変更を前提にした意思決定や、構造への投資の積み重ねによって形作られる。

エンジニアの本質とは？

ここまでの議論を踏まえ、定義の言語化をGeminiやChatGPTと繰り返した。そのうえで導き出されたエンジニアの本質は、次のとおりだ。

──論理の力で、混沌とした現実に再現性のある秩序を与えることで、価値を持続的に創出し、人間の可能性を拡張し続けること──

一言で言い切れる定義にはならなかった。だが、これまで見てきたエンジニアリングの価値を、無理なく包含している。あえて短縮するなら、「再現性ある価値の継続的な創出」といったところか。

企業で働くエンジニアの価値は、自社のミッションのもと、目の前のユーザーや顧客、ビジネス、あるいは社会に向き合い、この役割定義を実行することで具現化される。

さいごに: AI時代でもエンジニアの本質は変わらない

AIがコーディングを代替するようになっても、エンジニアのアイデンティティが崩壊するわけではない。なぜなら、その本質は変わっていないからだ。今後、AIが担う領域がさらに広がっても同じだろう。

コードを書く機会が減ることに喪失感をおぼえる人もいる。だが、コーディングエージェントとの協働は、新しい知的な楽しさももたらしている。ケント・ベックが「50年に及ぶプログラミング経験の中で、今が一番楽しい」と述べているのも、その一例だ*4。

手段が目的化しやすいのは、専門職種の宿命でもある。だがそれは、対象に深く没頭している証であり、知的好奇心の表れでもある。その追求は、個人の満足にとどまらず、組織に新たな可能性や能力の飛躍をもたらすこともある。

つまり、夢中になることは、エンジニアリングの原動力でもある。AIとの協働で形は変わっても、技術への探究心は持ち続けるべきだ。

その探究の先で、混沌とした現実に秩序を与え、再現性ある価値として社会に残していく。そこにこそ、AI時代においても変わらないエンジニアの本質がある。

なお、年末にこのテーマに向き合ったのは、先日登壇したパネルディスカッションで、「エンジニアの本質は課題解決である」という言葉への違和感を表明してしまったことがきっかけだった。それをあらためて整理し、言葉にしてみようとしたのが、本記事の試みである。

findy.connpass.com

余談ではあるが、AI時代においても本質が変わらないという点では、ソフトウェア開発組織の設計原理についても同様だ。AIによって開発が加速するほど、組織構造に由来する摩擦は無視できなくなる。チームや組織として、持続的に価値を生み出すための考え方については、拙著『チームの力で組織を動かす 〜ソフトウェア開発を加速するチーム指向の組織設計』で詳しく扱っている。

gihyo.jp

参考文献

*1:広木大地 著『エンジニアリング組織論への招待 ~不確実性に向き合う思考と組織のリファクタリング』技術評論社, 2018年, 1-2

*2:Robert C. Martin 著／角 征典, 高木 正弘 翻訳『Clean Architecture 達人に学ぶソフトウェアの構造と設計』KADOKAWA, 2018年, 第2章

*3:Titus Winters, Tom Manshreck, Hyrum Wright 編／竹辺 靖昭 監訳／久富木 隆一 訳『Googleのソフトウェアエンジニアリング─持続可能なプログラミングを支える技術、文化、プロセス』オライリー・ジャパン, 2021年, 1章

*4:「TDD, AI agents and coding with Kent Beck」The Pragmatic Engineer, 2025年6月, 03:05-03:10参照

AIで加速する個人、伸びないデリバリー──2025 DORAレポートが示すフローと摩擦の真実

AIツールを導入した結果、コーディングなど個人の作業スピードは上がった。けれど、チームや組織レベルのパフォーマンスはほとんど変わらない。むしろ、問題や混乱を招いている──そんな経験はないだろうか。

このギャップこそ、AI導入を進めた多くの組織が直面しているミステリーだ。

AI導入に関する2025年版のDORAレポートは、その原因が個人のスキルではなく、組織全体を動かす「システム」にあると指摘している。AIの真価を引き出せるかどうかは、ツールの性能や個人のスキル以上に、それらを組み込む組織構造やプロセスに左右される。

本稿では、ソフトウェアデリバリーにおけるAIの力を最大限に引き出すための二つの鍵、「フロー」と「摩擦」に焦点を当てる。組織の流れをどう整え、どのように摩擦を取り除くべきか。その核心を探っていこう。

🎧 本記事のAI音声解説版をポッドキャストで公開中

open.spotify.com

【ご視聴時の注意点】AI生成解説のため、内容には一部、原文から逸脱した軽微な誤りや、不自然な表現が含まれる可能性があります。大筋の理解には役立ちますが、詳細や正確な情報については、引き続き本ブログ記事をご確認ください。

主な参考文献

今回取り上げる文献は、2025年9月24日に公開された「2025 DORA State of AI-assisted Software Development Report」である。Google CloudのDORA（ドーラ）チームが、AI支援がソフトウェアデリバリーにもたらす影響を体系的に調査した最新レポートだ。

cloud.google.com

特徴的なのは、調査の焦点が「AIを導入すべきか」ではなく、「導入後に組織がどう変化したのか」に置かれている点である。約5,000名の開発実務者の回答と100時間超の定性調査から、生産性や品質、チームパフォーマンスへの影響が多面的に整理されている。

本稿では、このレポートが示す実態を入り口に、AI導入後の組織で生じている問題の構造を明らかにしていく。その第一歩となるのが、冒頭で触れた “ミステリー”──すなわち昨年の「2024 DORAアノマリー」である。

前回2024年度の調査で発覚した「DORAアノマリー」という現象

まず押さえておきたいのは、昨年の調査で発生した “異変” である。

DORAによる2024年の調査では、AIを積極的に導入した組織ほど、ソフトウェアデリバリーの「スループット（throughput）」が落ち、「不安定性（instability）」が増した*1。

AIを入れたのにパフォーマンスが悪化する──これが「2024 DORAアノマリー（異常事態）」と呼ばれる現象だ*2。本来の目的である生産性向上とは逆の結果を招いた。

なぜそんなことが起きたのか。そして、2025年度の結果はどう変化したのか──。

2025年度の調査の核心は、AIによる “増幅” とシステムによる “相乗効果”

2025年度のレポートが強調する核心は、次の2点である。

  • AIは、鏡であり力を増幅する存在（amplifier）である*3
  • システムは、その力の相乗効果を生み出す存在（force multiplier）である*4

ここで言う「システム」とは、ソフトウェアデリバリーを支える組織構造・プロセス・技術・文化といった環境全体を指す。いわゆるソフトウェアシステムのことではない。

AIは、システムの “良い部分” だけでなく “悪い部分” までも映し出し、増幅する。システムに非効率やボトルネックがあれば、その弱点もAIのスピードによって一気に表面化する。

こうした状況の中で、2024年時点では、多くの組織がAI導入を始めたばかりであり、システム側の準備が追いついていなかった。

そう、2024年のアノマリーは、この構造によって起きていたのである。

実際、2025年度の調査では、システム側をAIのスピードに適応させた組織ほどスループットが回復している*5。

この結果は、W・エドワーズ・デミングによる1993年の言葉を思い起こさせる。

悪いシステムは、良い人をいつも打ち負かす。

引用: John Hunter「A Bad System Will Beat a Good Person Every Time」The W. Edwards Deming Institute, 2015年, 記事内の文を筆者が翻訳

30年以上経ったAI時代でもなお、この原則は変わらない。AIの効果を引き出せるかどうかは、ツールや個人の能力だけでなく、それを支えるシステムの成熟度に大きく依存する。

次節では、システムの成熟度を高めるために何が必要なのか、レポートの示唆を見ていく。

AI導入による個人への効果を組織の成果に “変換” するためのシステム強化

AI導入の効果がもっとも顕著に現れるのは、「個人の生産性（individual effectiveness）」である*6。これは多くの開発者が実感しているだろう。

しかし、それで満足していては、組織パフォーマンスは向上しない。

個人レベルで増幅された効果を、チームや組織の成果へと変換するためには、システム側で相乗効果を生み出す必要がある。どれだけシステムを強化できるかが、その成否を決める。

DORAが有効性を確認した取り組みは次の2つである。

  • バリューストリームマネジメント（VSM）*7
  • プラットフォームエンジニアリング*8

「VSM」は、ソフトウェアがアイデアから顧客に届くまでのフローを可視化し、滞留たいりゅう箇所を特定・改善するための手法である。どこか一工程でもスループットが下がれば、そこがボトルネックとなり全体の性能を押し下げる。それを解消しなければ、AIがもたらした個人レベルの生産性向上も組織全体へ波及しない。

一方「プラットフォーム」は、DevOpsの観点（DORAの “D” は DevOps の “D” である）では、社内開発者向けのCI/CDやセルフサービス型インフラなどを指す*9。これらが整備されていれば、フローは速く、かつ安定する。結果として、VSMの成果にも寄与する。

いずれにせよ、焦点となるのは「フロー」である。

AI時代こそ “フロー” に注意を傾ける

VSMの実践とは、端的に言えばフローに目を向けることだ。これまでのソフトウェア開発では、人員配置や工数といった “リソース” に比べ、システム全体の “フロー” は意識されにくかった。

バリューストリームは、複数のプロセスが連なるパイプラインのように捉えると理解しやすい。その中をいくつものジョブが流れていく。このジョブの単位がフロー（フローユニット）だ。

VSMとは、この流れの中でボトルネックを特定し、取り除く実践である。これはソフトウェアシステムのパフォーマンスチューニングに近い。

バリューストリームやフローは、組織づくりを考えるうえで欠かせないテーマであり、拙著『チームの力で組織を動かす』でも基礎概念として整理している。そこで用いている説明の一部を、下記に引用する。

　たとえば、バリューストリーム内に、A, B, Cという3つのプロセスがあったとしましょう。これらのスループット上限がそれぞれ5, 3, 4である時、バリューストリーム全体のスループットは3です。Bのスループット上限である3がボトルネックになっているからです。

　ここで、Cのスループット上限を5に高めたとしても、やはりバリューストリーム全体のスループットは3のままです。Cのスループットがいくら高くても、BからCへのフローユニットの引き渡しは、Bのスループット上限である3でしか行われないからです。

引用: 『チームの力で組織を動かす 〜ソフトウェア開発を加速するチーム指向の組織設計』技術評論社, 2025年, 2-2-3

AI導入によって一部工程（プロセスやステージ）のスループットがいくら増幅されても、下流工程がそれを受け止められなければ、全体のスループットは変わらない。

次に、開発者にとってもっと身近な具体例を考えてみたい。

よくある例: AI導入でコーディングが速くなった代償としてコードレビューで詰まる

AIの導入によってコーディング速度が上がり、プルリクエスト数が一気に増えた──そんな経験を持つ組織は少なくないだろう。

典型的な開発プロセスを示すカンバンボードは、次の4ステージで構成される*10。

  1. To Do
  2. 進行中（設計や実装）
  3. コードレビュー
  4. 完了

「進行中」のスループットだけが上がると、「コードレビュー」に多くのチケットが滞留たいりゅうする。レビューさえ通れば、あとは自動化されたCIが流れを進めてくれるため、ボトルネックは明らかにレビュー工程にある。

つまり、この状態でのAI導入は「設計・実装」工程における “個人の生産性” を高めただけで、システム全体の流れは変わっていない。

レビュー工程に長い待ち行列ができる光景は、AI以前から珍しくない。それを放置したままAI導入を進めれば、その待ち行列は拡大するだけだ。これこそ、AIが鏡となってシステムの “悪い部分” を増幅した典型例である。

ここで多くの組織は、ボトルネックの解消に向けて対策を検討しはじめる。たとえば次のような手段だ。

  • 「WIP制限」を導入する
  • ペアプロの導入によって、レビュー自体を不要にする
  • コードレビューにもAIを活用し、負荷を軽減する
  • 一部のプルリクエストをAIレビューのみで通過させる

これらの施策でレビュー工程の詰まりが解消されれば、ボトルネックは別の場所に変わる。それをまた解消する。パフォーマンスチューニング同様、VSMもこの繰り返しである。

しかし、なぜレビュー工程は詰まるのか。たとえば開発者が期限に追われ、自分の作業を優先し、レビューを後回しにしているのかもしれない。

こうした構造的な原因を取り除かない限り、システムは本質的に強化されない。表面の問題は解消されても、流れの奥底に潜む “詰まりやすさ” は残ったままだ。

その構造的な問題こそが、次に述べる「摩擦」である。

フローを詰まらせる見えない “摩擦” の正体

フローを阻害する本質的な要因として、DORAレポートは「摩擦（friction）*11」を挙げている*12。摩擦とは、個人の作業を妨げたり、遅らせたりする要因の総称だ。これが少ないほどフローは滑らかになり、組織全体のスピードが上がる。

しかしレポートは、AI導入が「個人の生産性」や「コード品質（code quality）」を高める一方で、「摩擦」や「燃え尽き症候群（burnout）」にはほとんど影響を与えない、という興味深い結果を示した。これは “stubborn results（動かない結果）” と表現されている*13。

なぜこれらはAIでは解消されないのか。その中でもフローを直接阻害する「摩擦」による “見えにくい抵抗” に焦点を当てて考えていく。

気づかぬうちに効率を失ってしまう、現実のフローの複雑さ

現実のフローは想像以上に複雑で、さまざまな経路が絡み合う中で効率を失いやすい。その経路は、バリューストリームやカンバンボードでは捉えきれない領域や粒度にまで広がる。結果として、個々の集中力を奪い、チーム全体の流れを鈍らせてしまう。

たとえば──

  • 集中してコーディングしたいのに、頻繁にミーティングや割り込みタスクで中断される
  • ちょっとした変更でも、複数チームでの確認や誰かの承認が必要になる
  • 必要な情報がすぐに見つからない
  • ツールが使いにくい

これらはすべて、フローを阻害する摩擦である。DORAレポートが紹介する2019年のマイクロソフトの調査でも、開発者の一日を妨げる要因として同様の問題が指摘されている*14*15。

こうした摩擦による停滞は、少なからず、組織設計に起因する。組織構造に歪ひずみがあるとバリューストリームは複雑になり、フローはすぐに効率性を失う。さらにコミュニケーションの経路も入り組み、コストが増大する。

その帰結として、コンウェイの法則*16が示す通り、システム構造──すなわち内部品質──にまで悪影響が及ぶ。

とはいえ、こうした組織設計上の問題は、AI導入だけでは解決しにくい。そもそも問題の存在に気づくことすら難しい。では、どう取り組めばよいのか。

フローを詰まらせる組織設計アンチパターン

どのような設計が、組織にどのような影響を与えるのか。それがわかれば、組織設計者は現状に合わない設計を避け、より適した構造を選びやすくなる。

そこで役立つのが、組織設計に関する「アンチパターン」である。『チームの力で組織を動かす』では、16のアンチパターンを収録しており、そのうち8つはフロー（およびコミュニケーション）の効率を悪化させるパターンだ。

その簡易版としてまとめたのが、資料「内部品質・フロー効率・コミュニケーションコストを悪化させ、現場を苦しめかねない16の組織設計アンチパターン［超簡易版］」である。

P15からP24までが、その8つのアンチパターン集となっており、下に貼り付けたスライドが、その1つめのパターン「スパゲッティ組織」だ（P17）。

mtx2s「内部品質・フロー効率・コミュニケーションコストを悪化させ現場を苦しめかねない16の組織設計アンチパターン［超簡易版］」SpeakerDeck, 2025年, P15-P24

AIによる音声解説はこちら。

open.spotify.com

こうしたアンチパターンによってプロセスが非効率化している組織は、DORAレポートの7類型のひとつである「クラスター3: プロセスに制約される（constrained by process）*17」に当てはまりやすい。

クラスター3のチームは、技術的には安定したシステム基盤を持ちながらも、煩雑はんざつなプロセスがメンバーの努力を消耗させている。その結果として、「摩擦」や「燃え尽き症候群」が生じやすくなり、ワークフローは過度に負荷の高いものとなる。いくら基盤が整っていても、その状態では顧客価値やビジネス価値を十分に高めることは難しい。

言い換えれば、組織設計上の問題が解決されない限り、技術的な安定性だけではフローは守れない、ということだ。組織構造自体が、自体が過酷で持続不可能な環境を生み出している。

DORAレポートも次のように指摘している。

Treat your AI adoption as an organizational transformation.

（AI導入を組織変革として捉えよ）

引用: 「2025 DORA State of AI-assisted Software Development Report」DORA, 2025年, P17（日本語訳は筆者によるもの）

AIの導入は、組織構造そのものを見直す契機と捉えるべきである。その際の設計思想として重要になるのが、次に述べる「ストリームアラインド」というアプローチだ。

“ストリームアラインド” での継続的なフロー改善

レポートでも述べられているように、VSMによるフロー改善は “単発” で終わる取り組みではない*18。

したがって、改善の主体となる組織体制も “継続的” であることが望ましい。プロジェクトごとに都度チームを組み替えるような体制では、バリューストリームが安定せず、改善した効果も蓄積されにくい。

継続的な体制を構築するうえでは、チームを「ストリームアラインド（Stream-aligned）」として編成するアプローチが有効だ。『チームの力で組織を動かす』でも、この考え方を指針として整理している。

プロジェクトに対してチームを編成するのではなく、バリューストリームに対してチームを編成します。チームをストリームに専属配備するということです。それは、開発チームであっても企画チームであっても、スクラムチームのような機能横断型のチームであっても同様です。

引用: 『チームの力で組織を動かす 〜ソフトウェア開発を加速するチーム指向の組織設計』技術評論社, 2025年, 6-1

バリューストリームに専属するチームは、メンバー構成も責務も安定し、継続的な改善に取り組むことができる。日々の業務を通して実験し、学び、適応を積み重ねることで、摩擦が削減され、フローの効率性は確実に向上する。

このようなチームを「ストリームアラインドチーム*19」と名付けた『チームトポロジー』はDevOpsを基盤としており、同じくDevOpsの体系に立脚したDORAレポートとも高い親和性がある。AI導入を組織変革として進めるのであれば、ストリームアラインド型の体制はその基盤になりうる。

摩擦を軽減する “AIケイパビリティ”

摩擦の軽減に向けては、組織設計の改善だけでなく、日々の働き方そのものを変えるアプローチも有効である。

DORAレポートでは、AI導入と組み合わせた際に摩擦の減少が確認された二つのケイパビリティが紹介されている。

  1. 明確に伝達されたAIスタンス（Clear and communicated AI stance）
  2. 小さなバッチでの作業（Working in small batches）

明確に伝達されたAIスタンス

組織がAI利用に関する明確な方針を持ち、それが現場まで徹底的に共有されている状態を指す*20。

方針が不明瞭であれば、開発者は「使ってよいのか」「どこまで任せてよいのか」といった不安を抱えやすい。こうした迷い自体が摩擦となり、AI活用の速度を落とす。

明確なスタンスは、開発者を余計な不安から解放し、“創ること” に集中できる環境を生む。その結果、「摩擦」の減少だけでなく、「個人の生産性」「スループット」「組織パフォーマンス」の向上にも寄与する。

小さなバッチサイズでの作業

短時間で完了可能な作業単位に分割し、コード変更行数を抑え、1回のデプロイに含まれる変更数を小さく保つプラクティスである*21。AI以前からDevOpsやリーンソフトウェア開発で推奨されるプラクティスでもある。

しかし、AI導入が進むと逆にバッチが肥大化しやすい。するとどうなるだろうか。

たとえばプルリクエストのサイズが大きくなれば、レビューが重くなり品質担保も難しくなる。これは典型的な摩擦の発生である。

一方で、小さなバッチは「個人の生産性」を下げる側面もある。AIは大量の変更を一気に進める場面で特に強力だが、このケイパビリティはその伸び代を意図的に抑えるからだ。

とはいえ、「個人の生産性」は手段であり目的ではない。それよりも、このケイパビリティの効果である「摩擦」の軽減と「プロダクトパフォーマンス（product performance）」の向上を増幅させたい。部分最適より全体最適だ。

最後に

ここまで見てきたように、AIの効果を最大化するために重要なのは、個人の高速化ではなく、システム全体の「フローを整え、摩擦を減らすこと」である。

AI導入によって個々のアウトプットが増えても、組織のシステムがそのスピードに対応していなければ、本来の効果は相殺されてしまう。これは、デミングが述べた原則の現代的な再確認でもある。

では、私たちはどこを測り、どう改善すべきか。

個人レベルの「活動量」だけに着目するのではなく、システムレベルの「パフォーマンス」や「効率とフロー」の観点でモニタリングし、改善を続ける必要がある*22。

DORAのクラスター分析が示す通り、スループットが高いチームは、不安定性が低いチームでもある*23。高速でありながら安定している──そこが目指すべき姿だ。

そのための重要なAIケイパビリティが「ユーザー中心主義（User-centric focus）」である*24。ユーザー価値に結びつかないアウトプットを高速に生成しても意味はない。フロー改善と価値創出は常にセットで取り組む必要がある。

本稿では、DORAレポートを軸にフローと摩擦の視点から解説した。バリューストリームやフローの改善に関心があれば、拙著『チームの力で組織を動かす 〜ソフトウェア開発を加速するチーム指向の組織設計』も手にとってみて欲しい。組織構造とフローの関係について、体系的に整理している。

gihyo.jp

*1:「2025 DORA State of AI-assisted Software Development Report」DORA, 2025年, P35

*2:「2025 DORA State of AI-assisted Software Development Report」DORA, 2025年, P9

*3:「2025 DORA State of AI-assisted Software Development Report」DORA, 2025年, P87

*4:「2025 DORA State of AI-assisted Software Development Report」DORA, 2025年, P70およびP74

*5:「2025 DORA State of AI-assisted Software Development Report」DORA, 2025年, P42

*6:「2025 DORA State of AI-assisted Software Development Report」DORA, 2025年, P38 Figure 28

*7:「2025 DORA State of AI-assisted Software Development Report」DORA, 2025年, P73

*8:「2025 DORA State of AI-assisted Software Development Report」DORA, 2025年, P65

*9:「プラットフォーム エンジニアリングとは」Google Cloud

*10:Dan Radigan「カンバン」Atlassian,, ボトルネックの減少

*11:「2025 DORA State of AI-assisted Software Development Report」DORA, 2025年, P37

*12:「2025 DORA State of AI-assisted Software Development Report」DORA, 2025年, P77の "You’re no longer just optimizing a small step; you’re removing friction from the system’s biggest constraint." など（constraintとは、TOCでは「ボトルネック」を指す）

*13:「2025 DORA State of AI-assisted Software Development Report」DORA, 2025年, P39

*14:「2025 DORA State of AI-assisted Software Development Report」DORA, 2025年, P40

*15:Meyer, André N., Earl T. Barr, Christian Bird, and Thomas Zimmermann「Today was a good day: The daily life of software developers」IEEE Transactions on Software Engineering, 2019, 47, no. 5. (2019): 863–-880

*16:Melvin E. Conway「How Do Committees Invent?」Mel Conway’s Home Page, 1968年

*17:「2025 DORA State of AI-assisted Software Development Report」DORA, 2025年, P17

*18:「2025 DORA State of AI-assisted Software Development Report」DORA, 2025年, P76

*19:マシュー・スケルトン, マニュエル・パイス 著／原田 騎郎, 永瀬 美穂, 吉羽 龍太郎 訳『チームトポロジー 価値あるソフトウェアをすばやく届ける適応型組織設計』日本能率協会マネジメントセンター, 2021年, CHAPTER5

*20:「2025 DORA State of AI-assisted Software Development Report」DORA, 2025年, P51-P53

*21:「2025 DORA State of AI-assisted Software Development Report」DORA, 2025年, P58

*22:Nicole Forsgren, Margaret-Anne Storey, Chandra Maddila, Thomas Zimmermann, Brian Houck, Jenna Butler「The SPACE of Developer Productivity: There's more to it than you think.」『ACM Queue』2021年

*23:「2025 DORA State of AI-assisted Software Development Report」DORA, 2025年, P19 Figure 10

*24:「2025 DORA State of AI-assisted Software Development Report」DORA, 2025年, P95