アジャイル開発に関する有識者検討会（第6回）

概要

本検討会の概要は、アジャイル開発に関する有識者検討会をご覧ください。

開催情報

日時：: 令和8年（2026年）1月8日（木）10時00分から12時00分まで
場所：: オンライン（Microsoft Teams）
出席委員：: 狩野座長、杉井委員、岡島委員、佐野委員、木村アドバイザー

議事次第

開会
座長の挨拶
議事
- 前回の有識者検討会の振り返り
- 論点と仮説の共有及び議論
- 今後のスケジュール
閉会・諸連絡

資料

議事要旨

事務局から前回の検討会の振り返り、今回の検討会での論点と仮説について説明があった後、討議が行われた。各委員からの主な意見は以下のとおり。

大規模アジャイル開発実践におけるポイント

今までの検討会で、プロダクトオーナー（PO）の育成は困難であることや、（開発規模が大きければアジャイル開発が上手くいくというわけではなく）開発規模が小さいものであっても簡単にはいかないという議論をしてきた。複数チームが連携して行う大規模な開発のケースについても、アジャイル開発を導入することは難しいと考えざるを得ない。もし大規模化の議論を取り入れるのであれば、まず大規模開発に向けたロードマップのような、必要な要件や条件等をステップを踏んでいく形でまとめていくことが望ましい。
チーム間の接触ポイントや、システムにおけるインターフェイスはよりシンプルに設計した上で、可能な限り少なくし、各チームが動きやすい構造を作ることが大事である。「コンウェイの法則」のように、チームの構造の設計とシステムの疎結合の設計を可能な限り合わせることが望ましい。
複数のチームが一つの方向を向いているかは、POにとって難しい課題である。プロダクトゴールを全員で意識しながら進めることが重要ではないか。
大規模なシステムを作っていくには、システム全体のアーキテクチャ（システム設計）等より広い観点で考えるべきポイントが非常に多くあり、アジャイル開発の場合、全体のアーキテクチャを統括する役割は誰が握るのか、というような実務的な観点も持つ必要がある。
複数のチームにまたがる活動になるため、データの流れを俯瞰して見ることができ、影響範囲が分かる状態にしておくことが重要である。各チームの技術的な統一性も重要であり、技術選定やアーキテクチャの検討等もあらかじめ決めておくべきである。
チームの単位と契約の調達単位の組み合わせが問題になるのではないかと考える。システムごとにチームを分けて分割発注すると、責任の所在が不明瞭になり混乱が生じると考える。また、複数の事業者がチームをまたいで参加する場合、責任の所在を契約段階で整理する必要があると考える。
民間の事例で、例えばECシステムを構築する際に、スクラムチーム同士を疎結合する場合にECサイトのフロントエンドのWebサービス部分と、バックエンドのデータ分析基盤を別々に発注し、それぞれアジャイル開発することがある。両者間で疎結合としてデータが流れるため、データの増減などに注意しつつ、双方でテストを実施する等、連携してアジャイル開発をしていた。2つのチームは、プロジェクトの責任者を1人、また各チームにPOを1人ずつ立て、定期的にPO同士が話をする場を設けていた。発注にあたっては、技術要素が異なるため、得意分野ごとに事業者へ発注しつつ、データの流れには注意し、個別サービスやユーザーの違いを踏まえてそれぞれのチームがアジャイル開発を進めていた。また、チーム間で連携できる状態を維持するために、チームごとのPOがそれぞれバックログを作成し、依頼をする形であった。契約書に明記はしていないが、テストの時は協力することや、技術的な影響範囲も含め適切に連携することを伝えていた。
プロジェクト事例の共有だが、現在携わっているプロジェクトのシステムでは、システム部分に複数の事業者が入っており、全てのチームが複数の会社で構成されている。チーム構成は様々であるが、1つの会社が過半数を超えているチームは立ち上がりが早い一方で、管理側や作っているドメインと合わない場合は問題が生じることもある。また、月次の定例を行う際は、たくさんの会社と定例をしなければならないという管理側にとっての懸念もある。契約書の中で、他の会社との連携やチームの連携についての事項は記載していない。定期的にチーム間（ドメイン間）連携をしてテストするという、横連携を取る仕組みを大事にしている。
資料2のP.14やP.15で記載されている、「Scrum@Scale」や「LeSS」、「Nexus」について、NexusとLeSSは1つの大きなシステムの開発を、複数チームで進めるためのフレームワークであり、Scrum@Scaleは組織全体のアジリティ（機敏さ）向上を目的としたフレームワークである。それぞれの性質が異なるため、ドキュメントを作成する際には、その違いを明確にすべく注意書きが必要である。

スクラムチームに対する評価

民間企業に在籍していた際の事例では、資料に記載されているようなベロシティ（開発チームが1回のスプリントで完了したストーリーポイントの合計値）は行っておらず、経営層に「チームの状況はどうなっているか」と問われることが多かったため、リリースの回数やデプロイ数、バグの数を報告していた。また、それぞれのチームの①プロダクト価値向上に繋がる開発の稼働時間（ポジティブ稼働）、②障害対応や再発防止策等のプロダクト価値に繋がらない稼働時間（ネガティブ稼働）、③リリース作業やデータ集計作業など必要だができる限り少なくするべき稼働時間（減らすべき稼働）、④定例会議等の稼働時間を、経営層に示すために計測していた。
アジャイル開発の正当性の説明や安心感を与える観点で、どのような評価やレポートを行うかについては、リリース前の開発期間に見せるものと、リリース後に見せるもので変わる。リリース前は、特に大規模開発では期間が長いため、リリース日までに終わるかどうかに関心が集まる傾向にあり、ベロシティやストーリーポイントをトラッキングしていくことが考えられる。リリース後は、目的に合わせてシステムの利用率等を追っていくものと考えている。これらは官公庁・民間問わず共通して必要な指標だと考えられる。
プロダクトの評価は、スプリントレビューで一部のユーザーに使用してもらい、業務時間が短縮されたか等の計測はするが、経営層に報告する内容は、ベロシティやストーリーポイントが多い印象である。
資料上の表現として、評価＝ベンダーの評価をイメージしシビアな印象を与えるため、「評価」という言葉を使う意図を明確化すると良い。アジャイルの場合は、フィードバックを与えて評価し続けることも、発注側の役割の一つという形が伝わるよう誤解を生まない表現にするべきである。
CoE等のプロジェクト外部の人がスプリントレビューに入って状況評価をするパターンについて、経験としてはあまり多くない。民間では、プロダクトの責任者や開発責任者が経営層に状況報告することは多くあった。一方、発注者がベンダーを評価することについては、実際には伝えづらいことが多いなどの難しい面がある。自身がよく行っていたのは、発注側1から2名と受注側のベンダーの営業責任者、開発リーダー数名と定例ミーティング（ヘッドクォーターミーティング）を実施して、率直なコミュニケーションを取っていた。
例えばチーム外のCoEなどがスプリントレビューに入って評価するのではなく、課題解決のためにステークホルダーに対しタイムリーに説明し合意形成を図ることだと考えるため、「評価」という表現に違和感がある。
PMOとして各チームのスプリントレビューに参加した経験があるが、評価ではなくフィードバックをしていた。フィードバックをするために、情報収集として状況の確認をすることは、非常に重要である。数字の収集は必要だが、その中でもベロシティの扱いは難しいため、複数チームで開発する場合は、ベロシティを単純に他のチームと比較するべきではないと明記しておくことが望ましい。
これまでの議論も踏まえ、「評価」ではなく「フィードバック」という言葉で表現するほうが適切と考える。

デジタル庁におけるアジャイル開発体制

複数のベンダーがチームに入っている事例では、定例でドメイン横断のコミュニケーションの時間を設けていたが、POチームは明確には存在していなかった。POチームの役割として資料2のP.22に記載されている「POチームの役割」にある「リリース計画の調整」や「各チームの開発状況の共有」はPMOが担っていた（エピックの優先順位付けは行っていない）。この事例では、POコミュニティのようなもので、目的を持たず横連携が必要であるため、まず集まることが先行していた。他方、POチームは目的を持って集まるという点で異なる。目的を持って集まる場合の場面や条件として、本来はScrum@ScaleやLeSS、Nexusの要素を入れたかったが、各チームの立ち上がりのタイミングが異なり、POチームを組成することが困難であった。スタートを合わせられるのであれば、POコミュニティではなくPOチームを作ることが理想である。
アジャイル開発体制をパターン化して図示することは、なかなか納得感が得られず困難であり、また、機能や役割を詳細に定義し、ガイドに載せてたとしても汎用性がなくなる。アジャイル開発体制とは、コミュニケーションやマネジメントに関する要件に限定して考えるべきではないか。
デジタル庁におけるアジャイル開発体制について、大規模開発やハイブリッド開発など、全般的な課題は限られた資料上では語り尽くせないため、どこまで絞って書くかが重要である。
成功するパターンに再現性はないが、失敗するパターンには再現性がある。「これは絶対にやってはいけない」といったアンチパターンや必ず留意すべき点を載せると読み手にとって参考になるのではないか。また、一般的には、「POは必ず一人でなければならない」、「優先順位は一人で決めなければならない」と記載されていることがあるが、実際にそれで運用できるのかどうかという懸念は存在するはずである。したがって、「POは一人と書かれているが、こうした場合にはこのような問題が想定されるので、こう対応すると良いが、かなり大変になる」といった点まで記載すると読者や実務者にとって非常に参考になると考えている。
「大規模システムアジャイル開発」という表現は「大規模システム」と「大規模アジャイル開発」が混在する可能性があるため、表現については再検討いただきたい。
法制度等のビジネスドメインに詳しいエキスパートの役割は、POの役割の中でも重要である。POでその役割を担えない場合は、外部の有識者をチームに入れる、又はアドバイザーとして入れることも一つの案である。ビジネスドメインに関するエキスパートの役割を資料2のP.21に掲載されているパターン①に組み込むと良いと考える。また、補足になるが、プロダクトバックログアイテムの優先順位の決定について、行政機関では説明責任が求められると思われるため、根拠づけが必要だと考える。
想定担当者について、デジタル庁には参事官補佐や係長といった行政人材以外に民間人材も多いため、民間人材をどのようにチームに組み込むか整理が必要と考える。また、POやPO補佐も参事官補佐や係長が担う想定になっているが、業務負担が大きいためデジタル庁側と相談して整理するべきである。

以上