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

概要

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

開催情報

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

議事次第

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

資料

議事要旨

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

プロダクトオーナー選定条件と育成施策

組織の規模が大きくなると、他部門との連携や調整コストが増えるため、意思決定に時間を要することがあった。そのため、スクラムチームにプロダクトオーナー（PO）を1人立てるのではなく、POチームを組成し、チーム内で役割を分けて運営することがある。
POチームの役割は、マーケティング部門やデザイン部門等の他部門調整については、POチームで実施していくパターンと、1人がハブになり、各部門と調整するパターンがあると考える。
東京都の「アジャイル型開発プレイブック（以下「プレイブック」という。）」に記載のある「POA（プロダクトオーナーアドバイザー、本有識者検討会においては、「PO補佐」と呼称することとする。）」は、プロダクトバックログの精査等を担っており、ベンダーから割り当てることを想定している。なお、デジタル庁で同様にPO補佐を立ち上げる場合は、他部門調整にはベンダーではなくデジタル庁の人材を配置するべきと考える。
過去に所属していた組織の事例でも、PO（組織内の人材）が上位者にレクをし、承認を得ることが多かった。そのような組織内調整もPOの役割だと認識している。
PO補佐は民間でも実績があり、有効性もあると考える。調達時に、ベンダーにPO補佐の役割を依頼することを想定している。一方、POは仕様決定や、ステークホルダー調整等を実施する想定のため、デジタル庁においてPOチームに（東京都のプレイブックに記載の）全体統括のような役割の部門が含まれるかなどは整理が必要と考える。
参画中のあるプロジェクトでは、プロジェクトマネジメントオフィス（PMO）がコストやスケジュール管理やステアリングコミッティに対する報告等を実施している。ただ、各スクラムチームが自律的にコストやスケジュールを判断する能力が不足していることから、PMOが各スクラムチームからとりまとめるだけという形にできておらず、結果としてPMOが予算等を策定し、上層部へ報告する際に、スクラムチームの実感との乖離が生まれるケースがあるという課題はある。全体統括は、その配下にうまく進められているスクラムチームが存在することが前提で成り立つものだと考える。
POについては、半分はチームと共に稼働し、残りの半分の時間はユーザーへのヒアリング等に費やすのが適切だと考える。官公庁のプロジェクトであれば、他省庁との連携に50％、プロダクトの方向性について50％の時間を割くのが適切ではないか。また、スクラムの中で、PO補佐はチームとの稼働に50％、POと方向性の検討に50％の時間を割くのが望ましいと考える。
スクラムイベントに要する時間からPOの稼働率を算出すると、最低限20％くらいとなるが、プロジェクト初期は特に稼働割合は多くならざるをえないと考える。
最低限20％の稼働の確保が必要という意見は、極めて能力が高い人材だという前提のもと成り立つ話である。そのため、20%という基準を基にチェックリストを作成するのは適切ではない。
アジャイル開発に関する実務経験を1～2か月行った後、研修を受ける方が学習効果は高いと考える。プロダクトの一部機能を担当してリリースする等、ごく小さな範囲でもよいので、POとしての経験を積むことが大事である。
過去に所属していた組織では、PO補佐がアジャイル開発やPOの役割について説明をし、伴走しながら指導をした。また、内1～2名がPOの外部研修を受けていた。

ベンダーに求められる能力・経験

アジャイル開発の実績等を有するベンダーを整理したデジタル庁内のデータベースであるベンダープールの作成や、ベンダー選定において必要な観点として、アジャイル開発ができるという会社は多いが、実績を有するかどうかだけではなく、求めるスキルとして、アジャイルコーチができるかどうかを基準にすると良い。
過去に所属していた組織では、アジャイルコミュニティに属して意欲的に活躍するメンバーがいる会社を中心に選定していた。
デジタル庁で調達する際には、アジャイルコーチの経験者がいることを調達条件に加えるのは有効かもしれない。
外部登壇の頻度が高く、アジャイルコミュニティで良質な情報発信をしているような、アジャイルカルチャーが根強いベンダーか否かが重要であると考える。
公共調達の観点から、ベンダープールを作成することが適切か、或いはその内容の位置づけについて、留意しなければならない。入札制度で公平性を損なわない範囲で、どういった要件を設定するかは検討するべきである。
一般的にベンダー選定の際にはベンダープールの作成は有効であるが、官公庁においては公平性を確保する観点が重要であることから定期的な見直しが必要である。位置づけもあくまで声掛け候補リストとするのがよいと思われる。
アジャイルコーチのスキルを有している人材は1～2名必要だが、それに加えてソフトウェアエンジニアリングのスキルが高い人材が多くいれば、全体的なリスクを下げることができる。
発注側の負担は大きいが、発注側がベンダーのスキルを評価することができる総合評価方式が望ましい。
変更容易性が高いものを作成することができる人材が望ましいため、アジャイルという言葉を多く使わず、別の文言でチェック観点を作成するのが良い。

スクラムチームの安定化に向けた対策

1つ目は、委託先ベンダーの入れ替え時の引継ぎについては、単年度調達の場合でも、年度更新後の一定期間は引継ぎ義務を負うことを調達時の契約（仕様書）において明記しておくことが望ましいと考えられる。2つ目は、行政機関の事例ではないが、委託先ベンダーが契約した開発環境で開発を進めていたところ、途中で委託先ベンダーを変更する際や開発を中断する際に、引継ぎや中間生成物（データ等）の引き渡しを委託先ベンダーから適切に行ってもらえない事例があった。開発環境自体をデジタル庁側のライセンスで設定すれば、委託者ベンダーからの引き渡しは不要となるため、生じない問題であることから、長期の開発が想定される場合は、開発環境をデジタル庁側で設定する方がよい場合もあると考えられる。ただし、独自環境内での開発の場合、ベンダー側のコストが上がることも考えられることから、開発対象によって必要性は適宜検討が必要となる。
過去に所属していた組織の事例では、なるべく発注者側で開発環境を持つようにしていた。ソースコードや資材は発注者側が持っているので別のベンダーへの引継ぎも可能である。引継ぎは、対象物によるが、当事者が自身で行うことができるよう環境を整えることが重要である。
POもスクラムマスターも同時に変わることがないようにするべきである。
リスクを下げるためにはマルチベンダー状態を作ることが有効ではないか。
マルチベンダー状態については、調達の段階でコンソーシアム形式を採用する案もあるが、1つの事業体として調達することになり、その中の一部だけ継続するかどうかという問題もある。大規模な調達の場合、部分的に調達業者を変えることも可能だが、あまり事例がないのが現状である。
（単年度調達が原則でありその都度ベンダーが交代となる可能性がある官公庁とは異なり、）民間でベンダーを交代する場合の多くは、能力不適合によるパターンである。このパターンであれば、発注側が契約を打ち切る場合は、発注側がコントロールできるから問題ない認識である。
発注側が、能力不適合と判断してベンダーとの契約を打ち切る場合は、他のベンダーとゼロから作り直すことになるため、それまで作ってきたものを引き継ぐことはない。
成熟したプロダクトでよくあるのが、優秀で多忙な人がリーダーシップを取りつつ周囲に役割分担し、PO業務を進め、部下へ段階的に業務を移譲後、昇進して別ミッションへ移るという流れである。このように、実質的な対応はPOの部下に担当させる等、異動があった時に引継ぎがスムーズに行えるよう普段から準備しておくことは有用である。
POが異動になることを見据えて、他のメンバーへ課題や知識を共有しておくことは必要である。
引継ぎ期間は、ステークホルダーやチーム外などの外部との関係構築のために3ヶ月くらいが適切ではないか。
これまでに携わった事例では、PO補佐は、肩書きはなかったが、実質的な指揮を執っている人物という認知をされていた。
アジャイルCoEが、異動してきたPOに対して指導を行い、アジャイル開発が軌道に乗るまで寄り添って伴走支援することが大事だと考える。今年度の計画やマイルストーンを整理しておくことも重要である。
過去に所属していた組織では、アジャイルCoEは明示的な組織ではないが、アジャイル開発の有識者数名で構成されており、アジャイル開発に関して困ったことを聞く相談窓口として機能していた。元々技術支援やノウハウの支援を受け付ける仕組みがあり、その仕組み経由で相談を受けていた。
支援は、要求内容や支援者の空き状況により様々であるが、プロダクトバックログの書き方やアジャイル開発の概念を教える等を行った。
スクラムマスター交代時の対策について、ベロシティはチームごとに異なるものであるため、指標数値を引継ぐのではなく、参考情報として、ベロシティの計測方法やエラー率等を引継ぐ方が良い。

以上