過去10年間、ソフトウェア業界でかなりの時間を過ごしてきたなら、おそらくアジャイル変革を経験したことがあるでしょう。終わりのないスプリント計画会議に出席し、デイリースタンドアップで進捗を共有し、あるいはこのすべてに意味があるのかと疑問に思ったことさえあるかもしれません。
この不満は一般的であり、通常はプロダクトマネジメントとエンジニアリングの現実の間の断絶から生じています。ビジネスリーダーは予測可能性を求めますが、ソフトウェア開発は本質的に予測不可能です。企業が厳格な指標やダッシュボードを通じて予測可能性を強制しようとすると、アジャイルは失敗します。方法論が硬直した官僚主義になってしまうのです。セレモニーが無駄な作業のように感じられ、ストーリーの作成のような実践が退屈な雑用に変わるため、開発者は不満を抱きます。
一方、成熟したアジャイルの実践においては、リーダーシップは不確実性を認識し、ビジネスにとって最良の選択をする権限をチームに与えます。指標とダッシュボードは第一の目標ではなくなり、代わりにビジネス価値の提供に焦点が移ります。これはすべてを開発者の手に委ねるという意味ではなく、真に部門横断的なチームで開発者と緊密に協力することを意味します。
この前置きが必要なのは、この記事を正しく読むために、アジャイル宣言のルーツに再びつながってほしいからです。中核となる価値観を念頭に置いてください：
プロセスやツールよりも個人と対話を
包括的なドキュメントよりも動くソフトウェアを
契約交渉よりも顧客との協調を
計画に従うことよりも変化への対応を
この記事では、これらの基盤となるアジャイルの実践を、現代のエージェンティックなワークフローの時代にどのように移行できるかを探ります。
エージェンティックな開発ワークフロー#
エンタープライズの拡張について話す前に、ベースラインを確立する必要があります。これらのトピックについては以前の記事でも触れましたが、完全を期すためにここで改めて記載しておく価値があると思います。
- ストーリーを書くことはプロンプトを書くこと： エージェントに命令する上で最も難しい部分は、適切なコンテキストを与えることです。開発者はよく、良いストーリーを書くことに苦労します。しかし、それは今日培うことができる最も重要なスキルです。良いストーリーを書くために必要なスキルは、良いプロンプトを書くために必要なスキルとまったく同じです。それは、明確なビジネス上の正当性と期待される結果を伴って、消費しやすい方法で情報を整理することです。これはアジャイルの用語では**Definition of Ready (DoR)**として知られています。
- 優先順位付けがワークフローを決定する： 従来のバックログの洗練作業は、AIツールの管理に直接結びつきます。ビジネス価値対技術的確実性の次元に基づいてタスクに優先順位を付けることで、フォアグラウンドで同期的に作業するもの（Gemini CLIのようなツールとペアになる）と、バックグラウンドの非同期エージェント（Julesなど）に委任するものを決定できます。
- エージェンティックなコーディングサイクル： コーディングエージェントは非常に強力ですが、多くの場合、一貫性に欠けています。それらは定義上、非決定的です。この問題は、決定論的なツールを使用することで軽減できます。私はよくこれを「エージェントのエージェンシー（代理性）を減らす」と表現しています。たとえば、ビルドプロセスが常にビルド、テスト、リント、デプロイであることを知っている場合、プロンプトとしてこれを指定したくはありません。セッションが進むにつれて、エージェントは必然的に1つ以上のステップを忘れてしまいます。あなたが本当にしたいのは、このプロセスをカスタムツールとしてパッケージ化し、代わりにエージェントに提供して、それらのステップのいずれかを忘れるという選択肢を完全に排除することです。
これら3つの実践をマスターしていれば、あなたはすでに効果的なエージェンティック開発者です。しかし、エンジニアリング組織全体を効果的にするにはどうすればよいでしょうか？
会話型アーキテクチャと組織的知識の共有#
エンタープライズソフトウェアを書くことは難しいですが、特定のコードがなぜ書かれたのかを思い出すことも同じくらい難しい場合があります。暗黙知（部族の知識）はすぐに腐敗します。シニアエンジニアが辞める時、彼らの組織的な知識も一緒に去ってしまうことがよくあります。この問題に対する伝統的な解決策は、社内Wikiで網羅的なドキュメントを維持することですが、これらは維持し、発見し、強制することが難しい傾向があります。
長年、エンタープライズの知識共有に関する私のお気に入りの記事の1つは、マーティン・ファウラーのブログのこの記事です：Scaling Architecture Conversationally（アーキテクチャを会話によってスケーリングする）。著者たちは、優れたアーキテクチャはトップダウンの命令だけでなく、会話を通じて広がると主張しています。この投稿では、そうした会話をアーキテクチャ決定記録（ADR）に正式に記録して、時間が経っても失われないようにする方法についても探求されています。
ADRは単なるWikiを超えています。意思決定が行われた時点の歴史的スナップショットを提供します。それらは、その決定を正当化した特定の条件、前提、制約を捉えています。この概念は一見シンプルに見えますが、将来のチームが必要に応じて変更を加える力を与えます。最初の選択がなぜ行われたかという記録があるため、彼らはその決定が現在も有効かどうかを評価するツールを持ち、それらの制約が変化した際には、（新しいADRを発行することで）自信を持ってそれを覆すことができます。
年月が経つにつれて、この仕事の最も重要な部分は不確実性の管理であると私はますます信じるようになっています。ADRは、私たちが知っていることと知らないことについて正直になることを可能にするツールの1つです。すべてを知らなくても大丈夫だと早く気付くほど、良い結果が得られます。これがアジャイルであることの核心です。私たちは進歩するのに十分なだけを知り、不確実性を減らすために学びを蓄積し、反復する必要があります。ソフトウェアは生き物であり、決して完了することはありません。
ADRは構造化されていないWikiに対して複数の利点を提供しますが、それでも大きな欠点を共有しています。それは、人間がADRを認識し、それに従うことに依存しているという点です。特に大規模な組織では、コミュニケーションがボトルネックになります。情報のサイロ化が広まり、ビジネスのさまざまな部分を同期させるために多大な努力が費やされます。
エージェントを通じた知識の分配#
今日のアーキテクチャを拡張するには、この組織的知識を直接エージェントに注入しなければなりません。人間を通じた公式な放送チャネルに頼るだけでなく、テクノロジーを利用して、規制、ADR、管理手順、企業の基準を直接エージェントに放送することができます。組織のコンテキストがエージェントのコンテキストウィンドウ内に存在すれば、それらの実践が常に適用され、最新の状態に保たれることが保証されます。
アーキテクチャの観点から見ると、MCPサーバーはこの種の情報を公開するための理想的な媒体です。アーキテクチャ評議会、セキュリティ評議会、またはその他の委員会が決定を下すたびに、一元的に管理および更新できます。プロンプト、ツール、スキルはエージェントの行動を変える効果的な方法であり、エンジニアの手元にあるコーディングエージェントと、CI/CDパイプライン内の自動化エージェントの両方によって消費される可能性があります。
エージェントスキルがまだMCP仕様の一部ではないのは残念ですが、これに専念しているワーキンググループがあります。MCPサーバーを使用してスキルをエージェントに直接転送できるようになれば、スキルを最新に保つという課題は解決され、開発者に新しい標準を伝える際の摩擦が軽減されるでしょう。
プロダクトのドキュメントもまた、消費可能なプロダクトである#
内部ルールを超えて、このまったく同じメカニズムがプロダクトのドキュメントにも当てはまります。伝統的に、チームAが内部APIを構築する場合、彼らは開発者ポータルでOpenAPI仕様ファイルを公開し、チームBがマニュアルを読むことを期待します。エージェンティックな時代において、静的なドキュメントは摩擦を生み出します。あなたのプロダクトが他のチームによって消費されることを意図しているなら、そのドキュメントは彼らのツールによって消費可能であるべきです。
チームAがサービスを出荷するとき、APIスキーマ、統合例、コンプライアンスチェックをツールとして公開する専用のMCPサーバーも出荷するべきです。チームBの開発者がそのサービスと統合する必要がある場合、彼らは単に自分のコーディングエージェントをチームAのMCPサーバーに接続します。エージェントはAPI構造を照会し、統合ルールを読み取り、クライアントコードを自動的に記述できます。人間がマニュアルを読むことから、エージェントがAPIを読むことへと移行し、アーキテクチャの意図と統合パターンが企業全体で完全に維持されることを保証します。
セレモニーの自動化：非コーディングエージェント#
私たちはコーディングエージェントについて多くの時間を費やして話しますが、ほとんどのアジャイル実装につきものの管理上のオーバーヘッドを減らすために、非コーディングエージェントを利用して最適化する機会はたくさんあります。
会議中のメモ取りや要約といった簡単に実現できることから、バックログの再優先順位付け、ストーリーの洗練、スパイクの作成に至るまで、非コーディングエージェントを使用して、管理作業に費やされる多くの労力を取り戻し、エンジニアリングに再び焦点を当てることができます。
これらのプロセス指向のエージェントがチームを向上させるいくつかの方法を以下に示します：
- ストーリーの洗練とブレイクダウン： プロダクトオーナーがエピックの草案を作成した場合、エージェントはそれを見直して、欠落しているエッジケース、暗黙の技術的仮定、および処理されていないエラーパスを特定できます。エージェントに特定のスキルへのアクセス権を与えれば、組織の基準に自動的に準拠するようになります。不確実なポイントは、さらなる調査のために自動的にスパイクチケットに変換することができます。
- Definition of ReadyとDoneの監査： 多くのアジャイル設定では、DoRとDoDはしばしば忘れられがちな単なるWikiのチェックリストとして扱われています。エージェントを既存のカンバンボード（JiraやGitHub Projectsなど）にフックすることで、コンプライアンスをプロアクティブなものにできます。チケットが「Ready for Dev」に移動されたとき、バックグラウンドのエージェントはそれをスキャンして、APIスキーマやUIモックアップなどの必要なすべてのコンテキストが実際に添付されていることを確認できます。もし添付されていなければ、移行にフラグを立てます。同様に、チケットが閉じられる前に、エージェントはテストが追加され、ドキュメントが更新されたかを検証できます。
- データ主導のレトロスペクティブ： レトロスペクティブ（振り返り）は、しばしば「直近の出来事」へのバイアス（最新効果）に苦しめられます。非コーディングエージェントは、スプリントのチケットの移行、プルリクエストのコメント、およびチャットの会話スレッドをレビューすることで、客観的なデータアナリストとして機能できます。たとえば、特定のマイクロサービスに触れるチケットがレビューに平均して4日間費やされていることを指摘し、チームに対して対処が必要なドメイン知識のサイロが存在するかどうかを尋ねるように促すかもしれません。
エージェントマネージャーによるワークフローのスケーリング#
ここ1年ほど、業界は主に単一エージェントのエクスペリエンス、特にコーディングエージェントの洗練に焦点を当てており、新しい標準（MCP、スキル、フックなど）が出現し、統合されるのを見てきました。
その結果として、ソフトウェアエンジニアリングのキャリアのコアスキルは、コードの作成からエージェントのオーケストレーションへと軸足を移しました。しかし、ここには隠れたボトルネックがあります：人間の認知負荷です。AIの使用によって引き起こされる新しいタイプの燃え尽き症候群（バーンアウト）についての報告がすでにあります。
タスクを非同期エージェントに委任するのは素晴らしいことのように聞こえますが、バックグラウンドで実行されているすべてのタスクは、あなたの精神的帯域幅を消費します。タスクがアクティブであることを覚えておき、タスクが完了したらその出力をレビューし、コンテキストをメインのワークフローにマージし直す必要があります。これらが関連のないタスクである場合、コンテキストの完全な切り替えが必要になるため、ペナルティはさらに大きくなります。AIと同様に、私たち人間もコンテキストの問題に苦しんでいるのは皮肉なことです。
しかし、ソフトウェアエンジニアリングの基本定理が述べているように：
コンピュータサイエンスのすべての問題は、別のレベルのインダイレクション（間接化）によって解決できる… 間接化の層が多すぎるという問題を除いては。
今年、私たちは「エージェントマネージャー」、つまり他のエージェントを管理する責任を持つエージェントの台頭を目にしています。この概念は最初コーディング（例えば、Antigravityやscion）で見られましたが、より広範な意味を持っています。
しかし、これはより大きな問題を生み出します：1つのエージェント、あるいは少数のエージェントの作業をレビューすることですらすでに困難であるなら、エージェントのフリート（艦隊）の作業をどうやってレビューできるというのでしょうか？この質問に対する簡単な答えはありませんが、私の見解では、マルチエージェントシステムへの信頼を構築する方法を見つけ出す必要があります。あるいはさらに良いことに、セキュリティの世界で言われているように：「信頼せよ、しかし検証せよ」です。
プロンプティング技術を適用し、フック、サンドボックス、決定論的ツールを作成することで、単一エージェントシステムの信頼を高めることができるのと同じように、エージェントマネージャーに品質ゲートを追加する方法を見つける必要があります。エージェントの評価、監査可能性、およびより成熟したエンジニアリング実践は、この変化にとって不可欠なものとなるでしょう。
それにもかかわらず、私は私たちがそこにたどり着くと信じています。長年のエンジニアリングの実践こそが、正しいアセンブリコードが生成されたかどうかを確認するためにコンパイラからの出力を検査しないという自信を私たちに与えているのです。これも同じことです。
未来への視点：エージェンティックなカンバン#
コーディングエージェントからコードを取り上げ、代わりに構築しているプロダクトに焦点を当てたらどうなるでしょうか？私はこれを思考実験として行ってみましたが、現在私たちがカンバンボードで持っているものとそれほど変わらないことに気づきました。しかし、人間がチケットを選ぶ代わりに、主にエージェントがやり取りを行うのです。
開発のさまざまな段階（バックログ、To Do、進行中など）のための典型的な列がありますが、各列にはチケットを次の段階に進めるために協力して機能する一連のエージェントがあります。列にグローバルスキルを追加することで、たとえばアーキテクチャの標準や管理手順など、関与するすべてのエージェントに重要なコンテキストを提供できます。チケットをクリックし、エージェント間の会話フローを観察することで、すべてのステップを監査できます。エージェントを誘導する必要がありますか？チケットにコメントを追加してください。人間によるレビューステップを設けたいですか？自分自身を「エージェント」の1人として追加してください。
アジャイルの視覚的な管理とエージェントマネージャーの実行力を組み合わせることで、認知負荷の限界を解決できます。私たちはアジャイルとエージェンティックの世界を一周させて融合させるのです。過去のセレモニーは未来のダッシュボードへと進化し、私たちが終わりのないスプリント計画で学んだすべてが、次にやってくることへの準備にすぎなかったことを証明します。
このアプローチについてどう思いますか？下のコメント欄か、私のSNSであなたの考えをぜひ聞かせてください。
