デジタル庁の有識者検討会が大規模システム開発へのアジャイル手法適用に関する議論を公開した。複数チーム・複数事業者が関与するプロジェクトで、プロダクトオーナーの役割や契約単位の設計、評価のあり方などが論点として浮上している。政府の情報システム調達を変える端緒となる可能性があり、受注を目指すIT事業者は早い段階での構造理解が求められる。

大規模開発で複数事業者の連携が焦点に

検討会では、複数のチームが連携する大規模アジャイル開発のハードルについて議論が交わされた。チーム間のインターフェースを可能な限りシンプルに設計し、システムの疎結合とチーム構造を一致させることの重要性が指摘されている。また、複数事業者がチームをまたいで参加する場合の責任所在の明確化が必須であり、契約の調達単位とチーム単位の不整合が混乱を招くリスクがあるとの見解が示された。発注者にとっても、プロダクトオーナーを誰が担い全体アーキテクチャをどう統括するかが実務上の課題となっている。

EC構築事例に見る疎結合型発注の実態

検討会では、民間のECシステム構築事例が共有された。フロントエンドのWebサービスとバックエンドのデータ分析基盤を別々に発注し、それぞれでアジャイル開発を行う手法である。両者の間ではデータの流れを疎結合に保ちつつ、各チームにプロダクトオーナーを配置し、定期的な連携の場を設けることで全体の整合性を担保していた。契約書にテスト時の協力や技術的影響範囲への配慮を明記こそしていないが、発注時点で事前に伝達することで事業者間の円滑な協働を実現している。技術要素の違いを踏まえた発注の分離が、開発速度の向上に寄与した事例と言える。

ベロシティ偏重を脱却する評価の再定義

スクラムチームの評価方法については、ベロシティやストーリーポイントだけに依存することへの懸念が表明された。民間事例では、プロダクト価値向上に直結する稼働時間と障害対応などの非価値創出時間を区分して経営層に報告する手法も紹介されている。リリース前の開発期間では進捗のトラッキングにベロシティが用いられる一方、リリース後はシステム利用率など本来の目的達成度で測るべきだとされた。検討会では「評価」よりも「フィードバック」という表現が実態に即しているとの意見が大勢を占め、発注者と受注者が率直にコミュニケーションできる場の設計が重要視されている。

デジタル庁の調達指針に波及する論点

デジタル庁内のアジャイル開発体制についても具体的な課題が提起された。複数ベンダーが参加する事例では、プロダクトオーナーが集まる目的型のPOチームを組成することが理想とされるが、各チームの立ち上がり時期のずれにより実現が難しいケースが報告されている。Scrum@ScaleやLeSSといったフレームワークの適用を望んでも、チーム組成のタイミングが揃わなければ機能しないという現場の制約が明らかになった。今回の議論が今後、政府情報システムの調達ガイドライン等に反映されれば、受注事業者に求められる開発体制や契約形態にも直接的な影響が及ぶと考えられる。