過去10年ほどの間にソフトウェア業界で過ごした経験がある方なら、おそらく一度は「アジャイル変革（アジャイルトランスフォーメーション）」を経験したことがあるでしょう。終わりの見えないスプリントプランニングに同席し、デイリースタンドアップで進捗を共有しながら、「これらに本当に意味があるのだろうか？」と疑問を抱いたことさえあるかもしれません。
こうしたフラストレーションは決して珍しいものではなく、大抵はプロダクトマネジメントとエンジニアリングの現場における現実のギャップ（断絶）から生じています。ビジネスリーダーは「予測可能性」を求めますが、ソフトウェア開発は本質的に予測不可能な営みです。厳格なメトリクスやダッシュボードによって予測可能性を無理に押し付けようとすると、アジャイルは失敗します。アジャイルという手法そのものが硬直した官僚主義に陥ってしまうのです。各種セレモニーは無駄なオーバーヘッドに感じられ、ユーザーストーリーの作成といったプラクティスも退屈なルーチンワークへと成り下がってしまうため、開発者には不満が募ります。
一方で、成熟したアジャイル組織では、リーダーシップ層が不確実性を受け入れ、ビジネスにとって最良の選択を下せるようチームに権限を委譲（エンパワー）します。メトリクスやダッシュボードを追うことが主目的ではなくなり、代わりに「ビジネス価値の提供」へと焦点がシフトするのです。これはすべてを開発者に丸投げするという意味ではなく、真のクロスファンクショナルチームとして開発者と緊密に協働していくことを意味します。
この記事を正しく読み解いていただくためにも、まずはアジャイルソフトウェア開発宣言の原点に立ち返っていただく必要があります。その中核となる価値観（コアバリュー）を思い出してください：
プロセスやツールよりも個人と対話を
包括的なドキュメントよりも動くソフトウェアを
契約交渉よりも顧客との協調を
計画に従うことよりも変化への対応を
この記事では、こうしたアジャイルの基盤となるプラクティスを、エージェンティックな現代のワークフローへとどのように橋渡しできるかを探求していきます。
エージェンティック開発のワークフロー#
エンタープライズ規模でのスケーリングを議論する前に、まず共通のベースラインを整理しておきましょう。これらは過去の記事でも触れてきたテーマですが、全体の文脈を揃えるためにおさらいしておきます：
- ストーリー作成はプロンプティングそのもの（Story writing is prompting）： エージェントを指揮する上で最も難しいのは、適切なコンテキストを与えることです。多くの開発者は質の高いストーリーを書くのに苦労しがちですが、これこそが現代において磨くべき最も重要なスキルです。優れたストーリーを書くスキルは、優れたプロンプトを書くスキルと完全に一致します。明確なビジネス上の妥当性と期待される成果を定義し、エージェントが消化しやすい形で情報を整理する——アジャイルの用語でいう「Definition of Ready（DoR：準備完了の定義）」に他なりません。
- 優先順位付けがワークフローを決定づける（Prioritisation dictates the workflow）： 従来のバックログリファインメントは、AI ツールの使い分けに直結します。「ビジネス価値（Business Value）」と「技術的確実性（Technical Certainty）」の2軸でタスクに優先順位を付けることで、フォアグラウンドで同期的に進める作業（Gemini CLI などとのペアプログラミング）と、バックグラウンドの非同期エージェント（Jules など）へ委任すべき作業を判断できます。
- エージェンティック・コーディングサイクル（The agentic coding cycle）： コーディングエージェントは極めて強力ですが、再現性や一貫性に欠けることが少なくありません。本質的に非決定的（Non-deterministic）だからです。この問題は、決定論的（Deterministic）なツールを組み合わせることで緩和できます。私はこれをよく「エージェントの自由度（Agency）を意図的に下げる」と表現しています。例えば、ビルドプロセスが常に「ビルド → テスト → リント → デプロイ」という手順であるなら、それをプロンプトで逐一指示すべきではありません。セッションが長引くにつれて、エージェントはいずれかのステップを確実に忘れてしまうからです。真の解決策は、そのプロセスを一連のカスタムツールとしてパッケージ化し、エージェントに渡すことです。そうすれば、途中のステップを勝手に省く余地を完全に排除できます。
この3つのプラクティスを押さえていれば、個人としてはすでに高効率なエージェンティック開発者と言えます。しかし、エンジニアリング組織全体を効果的に機能させるにはどうすればよいのでしょうか？
対話型アーキテクチャと組織知の共有#
エンタープライズソフトウェアの開発は困難を極めますが、特定のコードがなぜそのように書かれたのかという背景を後から把握するのも同じくらい骨の折れる作業です。チーム内の属人的な知識（Tribal knowledge）はあっという間に風化してしまいます。シニアエンジニアが退職すれば、その組織知も一緒に失われてしまうのが常です。この問題に対する従来の解決策は、社内 Wiki に網羅的なドキュメントを残すことでしたが、Wiki はメンテナンスが滞りがちで、検索性も低く、ルールとして徹底させるのも困難です。
長年、組織的な知識共有について私のお気に入りの記事の一つに、Martin Fowler のブログに掲載された Scaling Architecture Conversationally があります。著者らは、優れたアーキテクチャとはトップダウンの指示によってではなく、対話を通じて浸透していくものだと主張しています。また、そうした対話を ADR（Architecture Decision Records：アーキテクチャ決定記録）として形式知化し、時間の経過とともに風化させないためのアプローチについても論じています。
ADR は単なる Wiki 以上の価値を持ちます。意思決定がなされた特定の時点における歴史的スナップショットを提供するからです。その決定を正当化するに至った前提条件、仮説、制約事項が克明に記録されます。一見シンプルな概念ですが、これは将来のチームが必要に応じて変更を加えるための大きな力になります。最初の選択がなぜ行われたのかが記録されているため、当時の前提が現在も成り立っているかを客観的に評価でき、前提条件が変化した際にも（新たな ADR を発行することで）自信を持って過去の決定を更新・上書きできるのです。
エンジニアとしてのキャリアを重ねるにつれ、この仕事の本質は「不確実性のマネジメント」にあると強く実感するようになりました。ADR は、自分たちが何を理解していて、何をまだ理解していないのかを率直に見つめ直すための強力なツールです。「最初からすべてを知っている必要はない」と早く気付くほど、開発は前に進みます。これこそがアジャイルの本質です。前に進むために必要十分な情報だけを把握し、学びを積み重ねて不確実性を減らし、イテレーションを回していく。ソフトウェアは生き物であり、永遠に「完成」することはありません。
ADR は非構造化な Wiki に対して多くの利点を持ちますが、依然として大きな弱点を抱えています。それは「人間が ADR の存在を認知し、自発的に遵守すること」に依存している点です。特に大規模組織では、コミュニケーションそのものがボトルネックになります。情報のサイロ化が進行し、組織の各部門間で足並みを揃えるためだけに膨大な労力が費やされてしまうのです。
エージェント経由で組織知を配信する#
現代においてアーキテクチャをスケールさせるには、この組織知を直接エージェントへと注入しなければなりません。人間を介した公式の周知アナウンスだけに頼るのではなく、社内規程や ADR、統制手順、コーポレートスタンダードをテクノロジーによって直接エージェントへと配信・適用できるのです。組織固有のコンテキストがエージェントのコンテキストウィンドウ内に常駐していれば、組織のプラクティスが常に最新の状態で確実に適用されます。
アーキテクチャの視点から見ると、Model Context Protocol（MCP）サーバーは、この種の情報を公開・配信するための理想的な媒体です。アーキテクチャ委員会やセキュリティ委員会などの意思決定機関が新たな指針を出すたびに、中央で一元管理・更新できます。プロンプトやツール、Agent Skills はエージェントの振る舞いを制御する極めて効果的な手段であり、エンジニアが操作するコーディングエージェントだけでなく、CI/CD パイプライン内で稼働する自律エージェントからも共通して利用できます。
エージェントスキル（Agent Skills）がまだ MCP 仕様の標準に含まれていないのは過渡期の課題ですが、現在専用のワーキンググループで標準化が進められています。MCP サーバーを介してスキルをエージェントへ直接動的配信できるようになれば、スキルを常に最新に保つ運用の課題が解消され、開発者に新たな規約を周知・浸透させる摩擦は劇的に低減されるはずです。
プロダクトドキュメントも「消費されるプロダクト」である#
社内規程にとどまらず、まったく同じ仕組みがプロダクトのドキュメントにも当てはまります。従来の開発では、チームAが社内 API を構築した場合、開発者ポータルに OpenAPI 仕様書を公開し、チームBがそのマニュアルを読んで理解することを期待していました。しかしエージェンティックの時代において、静的なドキュメントは摩擦（フリクション）を生む原因にしかなりません。自チームのプロダクトが他チームに使われることを想定しているなら、そのドキュメントも相手の開発ツールが直接利用（コンシューム）できる形式であるべきです。
チームAがサービスをリリースする際には、API スキーマ、インテグレーション例、コンプライアンスチェック機能をツール群として公開する「専用 MCP サーバー」も併せて提供すべきです。チームBの開発者がそのサービスと連携したい場合、自身のコーディングエージェントをチームAの MCP サーバーに接続するだけで済みます。エージェントが自律的に API 構造を問い合わせ、連携ルールを把握し、クライアントコードを自動生成してくれるのです。「人間がマニュアルを読む」世界から「エージェントが API を解釈する」世界へと移行することで、アーキテクチャの設計意図や連携パターンを組織全体で齟齬なく正確に保つことができます。
セレモニーの自動化：非コーディングエージェントの活用#
コーディングエージェントの話題ばかりが注目されがちですが、多くのアジャイル開発現場を悩ませているマネジメントオーバーヘッドを削減する上では、非コーディングエージェント（Non-coding agents）を活用した最適化の余地が数多く存在します。
会議中の議事録作成や要約といった手近なタスク（Low-hanging fruits）から、バックログの優先順位の再評価、ユーザーストーリーのリファインメント、スパイク（調査タスク）のチケット起票に至るまで、非コーディングエージェントを導入することで、管理業務に奪われていた時間をエンジニアリング本来の価値創造へと取り戻すことができます。
こうしたプロセス指向のエージェントがチームを強化する具体例をいくつか挙げます：
- ストーリーのリファインメントと細分化（Story Refinement & Breakdown）： プロダクトオーナーが大まかなエピックを作成すると、エージェントがそれをレビューし、考慮漏れのエッジケースや暗黙の技術的前提、未処理のエラーパスなどを洗い出します。特定のスキルへのアクセスを付与しておけば、組織標準に準拠しているかも自動検証できます。不確実な論点があれば、さらなる技術調査用の「スパイク（Spike）チケット」として自動起票することも可能です。
- DoR（準備完了の定義）と DoD（完了の定義）の監査： 多くのアジャイル現場において、DoR や DoD は形骸化した Wiki のチェックリストに過ぎず、忘れ去られがちです。エージェントを既存のカンバンボード（Jira や GitHub Projects など）と連携させれば、ルールの遵守をプロアクティブに担保できます。チケットが「Ready for Dev（開発準備完了）」に移動した際、バックグラウンドのエージェントが内容をスキャンし、API スキーマや UI モックアップなどの必要なコンテキストが実際に添付されているかを確認します。不備があればステータス遷移にフラグを立てて差し戻します。同様に、チケットをクローズする前にも、テストコードの追加やドキュメントの更新が完了しているかをエージェントが検証します。
- データ駆動のレトロスペクティブ（振り返り）： スプリントのレトロスペクティブは、直近の出来事だけに引きずられる「利用可能性バイアス（Recency bias）」に陥りがちです。非コーディングエージェントは、スプリント期間中のチケット遷移履歴、プルリクエストのレビューコメント、Slack 等のチャットログを客観的にレビューし、データアナリストとして機能します。例えば「特定のマイクロサービスを変更したチケットは、PR レビューで平均4日間滞留している」といったファクトを提示し、チーム内でドメイン知識のサイロ化が発生していないか見直すきっかけを与えてくれます。
エージェントマネージャーによるワークフローのスケーリング#
ここ1年ほど、業界は主に単一エージェントの体験、とりわけコーディングエージェントの洗練に注力してきました。その過程で MCP、Agent Skills、Hooks といった新たな標準規格が次々と登場し、定着しつつあります。
その結果、ソフトウェアエンジニアのコアスキルは「コードを書くこと」から「エージェントをオーケストレーションすること」へとシフトし始めました。しかし、ここには見落とされがちなボトルネックが存在します。それは「人間の認知負荷（Cognitive load）」です。AI の利用によって引き起こされる新たなバーンアウト（燃え尽き症候群）に関する報告もすでに出始めています。
非同期エージェントにタスクを委任するのは一見魅力的に思えますが、バックグラウンドで走るタスクは確実に人間のメンタル帯域（メンタルモデルの容量）を削っていきます。タスクが進行中であることを意識し続け、完了したら出力をレビューし、そのコンテキストを自分のメインワークフローへと再統合しなければなりません。特に無関係な複数タスクを並行処理している場合、完全なコンテキストスイッチが発生するため、脳への負荷はさらに跳ね上がります。AI と同様に、人間側もまた「コンテキストの限界」に苦しんでいるというのは皮肉な話です。
しかし、ソフトウェアエンジニアリングの基本定理が述べているように：
コンピュータサイエンスにおけるあらゆる問題は、もう一層の間接化（Indirection）を導入することで解決できる。……間接化の層が多すぎるという問題を除いては。
今年、私たちは「エージェントマネージャー」、つまり他のエージェントを管理・統括するエージェントの台頭を目撃しています。この概念は最初コーディング分野（例えば Antigravity や scion など）で見られましたが、より広範な意味合いを持っています。
しかし、ここでさらなる課題が生まれます。1つや2つのエージェントの成果物をレビューするだけでも手一杯なのに、大量のエージェント群（フリート）が生み出すアウトプットを一体どうやって人間がレビューしきれるのでしょうか？ 簡単な答えはありませんが、私が考えるに、私たちはマルチエージェントシステムに対する信頼を着実に構築していくしかありません。セキュリティの格言にあるように、「信頼せよ、されど検証せよ（Trust, but verify）」です。
プロンプティング手法の工夫、フックやサンドボックス、決定論的ツールの導入によって単一エージェントへの信頼性を高めてきたのと同様に、エージェントマネージャーに対しても適切な「品質ゲート（Quality Gates）」を組み込む手法を確立していく必要があります。エージェントの評価（Evaluation）、監査性（Auditability）、そしてより成熟したエンジニアリングプラクティスが、このパラダイムシフトの成否を分ける基盤となるでしょう。
それでも、私たちは必ずこの壁を乗り越えられると信じています。私たちがコンパイラから出力されたアセンブリコードを一行ずつ目視確認することなく安心して実行できるのは、何十年にもわたるエンジニアリングプラクティスの積み重ねがあるからです。エージェントマネジメントの世界も、まったく同じ道を歩むことになるはずです。
未来の展望：エージェンティック・カンバン#
コーディングエージェントから「コードを書く作業」を取り払い、私たちが構築している「プロダクトそのもの」に焦点を当てたらどうなるでしょうか？ 私がこの思考実験を行ったところ、現在私たちが使っているカンバンボードとそう大きく変わらない形に行き着くことに気づきました。ただし、人間がチケットをピックアップするのではなく、エージェント同士が主に対話を繰り広げながら進めていくのです：
ここには、開発の各ステージ（Backlog、To Do、In Progress など）を表すおなじみのカラム（列）が並んでいますが、それぞれのカラムにはチケットを次のステージへと進めるために協働するエージェント群が配置されています。カラムにグローバルスキルを設定しておくことで、アーキテクチャ標準や統制手順といった重要なコンテキストを、関与するすべてのエージェントに共有できます。チケットをクリックしてエージェント間の会話フローを追うことで、すべてのステップを監査可能です。エージェントの方向性を修正したい場合は、チケットにコメントを投稿するだけです。人間のレビュープロセスを挟みたいなら、自分自身を「エージェント」の一員として組み込めばよいのです。
アジャイルの持つ視覚的マネジメントと、エージェントマネージャーの圧倒的な実行力を組み合わせることで、人間の認知負荷の限界を打破できます。アジャイルとエージェンティックの世界は、こうして見事に一周して結びつくのです。過去のセレモニーは未来のダッシュボードへと進化を遂げ、かつて終わりのないスプリントプランニングで私たちが学んだすべては、この先訪れる未来のための準備期間に過ぎなかったのだと証明されるでしょう。
このアプローチについてどう思われますか？ ぜひ下のコメント欄や、各種 SNS で皆さんのご意見を聞かせてください。
