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

概要

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

開催情報

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

議事次第

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

資料

議事要旨

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

官公庁でのアジャイル開発における品質保証の推奨パターン

  • 内部品質とは、バグ（動作不良や仕様のミス）の除去や、セキュリティ対策を充実させるなど、ユーザーには直接見えない部分の品質を高めるものであり、外部品質とは、画面や機能の使い勝手の向上や、ユーザーからのフィードバックによる機能追加などを行い、製品の価値を高めるものである。このように、品質は、内部品質と外部品質に大きく分けられ、品質保証のアプローチは内部と外部で異なると考えられることから、内部と外部で分けて議論すべきである。また、初期開発（新規開発）の場合と定期的にリリースを行うエンハンス（既存システムの維持・改善）の場合でも、品質保証に関する取組は異なると考える。内部開発と外部開発、初期開発とエンハンス開発でも品質保証の優先順位は変わってくるのではないか。
  • 資料2で挙げられているパターン（P.17）は内部品質に関する要素が多いと感じる。パターンの話とは逸れるが、ユーザーの使い勝手の良さに関しては、広く使ってもらえる人にリサーチインタビューをすること（UXリサーチ）が重要であるため、優先度を上げるべきである。
  • 過去に所属していた組織では、ユーザーテストのガイドラインを使って、ユーザーリサーチやテストを強く推奨していた。ガイドラインで定着させることが重要である。また、調達が終わった後に問題が生じた際に、契約上どのように修正するのかという課題もあるが、ユーザーテストの実施について最初の段階で計画しておくべきである。
  • ユーザーテストに関して、ウォーターフォール開発では、ほとんどの場合最後にテストをするが、アジャイル開発ではある程度UIができた段階でテストができるという特徴がある。完成品に近いものでテストできることがアジャイル開発の利点である。早くテストをすることで早期に課題を把握し、対応できるという点でメリットがある。
  • QA to AQ（QA：Quality Assurance（品質保証）、AQ：Agile Quality（アジャイル品質）)は民間においてもよく参照される考え方である。資料2のP.17にある「パターン1：QAを含むOneチーム」について、組織や体制変更を伴う場合は非常に難しいと考える。官公庁において、パターンとして現実的に導入可能であるかを踏まえて検討するべきである。
  • 重要なこととしては、内部品質を高め、チームの技術力を向上させることを目的に、モノづくりをしている現場の近くに、精通した専門家を置き、早期に間違いに気付ける体制を作ることが望ましい。性能テストやセキュリティテスト等の非機能要件を毎日実施したチームが、課題を早期に気が付き、品質が高まるという事例があった。そういったテストが実施できるような、余力のあるチームを作ることも重要である。
  • 資料2のP.17のパターン5の「品質チェックリスト」には、例えば、「毎スプリントでリグレッションテストを全件実施する」等の項目を入れることで、要求水準を明確にすることができる。デジタル庁の求める品質に関する期待値の最低レベルをチェックリストに反映させることで、デジタル庁が求める技術レベルに合ったベンダーを含めたチームを組成することができると思う。
  • 資料2のP.17の「パターン1：QAを含むOneチーム」と、「パターン2：品質スプリント」を組み合わせて、QA担当者がチームに加わり、品質スプリントで総合試験とユーザーテストの設計をすることで品質が向上するのではないか。
  • QA担当者として、テストの専門家を加えることが望ましい。設計の段階から提案をしてそれに基づき設計していくのが理想。受託企業側にQA担当者がいることはあるが、発注側にいるイメージはない。
  • 調達の要件の中で、QA担当者にふさわしい人材を開発チームにアサインすることを要求するのも、1つの案かもしれない。
  • 開発チーム内に適切な人材がいない場合は外部に求めることもある。資料2のP.17の「パターン2：品質スプリント」は取り入れやすいが、品質に関するスプリントが後にあることで、後でやればいいとなりかねない。そうならないような防止策を考える必要がある。
  • 特定の業務領域に深い知見を有するドメインエキスパートのような人がいることも重要であると考える。公共の業務や制度は複雑なので、ベンダーのみではカバーできない。官公庁は異動が多いため、担当者が詳しくない場合、仕様やテスト漏れにつながることから、詳しい人材がいるかどうかは重要である。

デジタル庁におけるアジャイルCoEの機能・役割・フェーズ別運用

  • 資料2のP.24にまとめられている大枠に概ね同意である。「チェンジマネジメント」として求める役割に、アジャイル開発の好事例を広める役割があると良い。
  • アジャイルCoEは、実務能力に限らず、動機を持っている人＝チャンピオンと呼ばれる人材の集まりであると考える。多くの人に普及させるためには、熱意を持った人が望ましい。その他機能に関しては資料内容（P.24）に異論はない。
  • 他にアジャイルCoEに必要な条件として、専門性を有していることが重要である。また、部門横断で各部門の実務能力を持ち、アジャイル開発に納得して主体的に動ける人材が望ましい。民間の立場で、アジャイルCoEを育てたいという会社の支援を行っている経験上、熱意と専門性を兼ね備えた人材を探すのは非常に難しいと感じている。
  • アジャイルCoEの体制は、専任と兼任の両方のパターンが想定される。
  • ナレッジマネジメントに関連して、アジャイルCoEには現場からの意見を集約してチェックリストを改訂していく役割もある。
  • 資料にある「アジャイルCoE」と「アジャイルガバナンス・ナレッジマネジメント担当」の役割は、デジタル庁の職員が担うものと考えるが、異動が多いことを考慮するとアジャイル開発に詳しい人材が、毎回担当者としてアサインされることは困難である。スクラムアライアンス（2001年に設立されたスクラムの普及を目的とする非営利団体）が近い組織であり、体制面で参考になるのではないか。
  • 官公庁は異動が多いため、民間の事業者を担当者として雇うことも1つの案である。また、研修等の人材育成は伴走支援とは役割が異なり、アジャイル開発の専門知識がなくても務まることから、担当を分けてもいいと考えられる。研修等の人材育成の担当においても熱意はあるに越したことはないが、仮に無かったとしても役割やKPIを明確にすれば対応可能と思われる。研修は外部講師を雇うこともできる。
  • 伴走支援は専門性が必要であることから、一般職員は研修担当をデフォルトとしつつ、スキルや経験値に応じて伴走支援も担当することが現実的ではないかと考える。
  • 資料2のP.25の「（C）アジャイル開発成熟度フェーズに応じたCoEの運用」について、フェーズが上がるごとに体制を整えていくという仮説が立てられているが、ロードマップを作る段階で、アジャイル開発の有用性を伝えることや、組織としての目標を明確に立てることが必要である。仮説の時間軸や人数はロードマップやデジタル庁の目標の立て方による。
  • 民間企業のプロジェクトでも段階的に体制を整えていく手法として、同様のフェーズ論で実施していた。やはり広報して広めていくことも重要であり、案件拡大フェーズでは広報にも力をいれていくべきである。
  • 採用定着フェーズでは、アジャイル開発が当たり前になった段階で発展的解消となっているが、当たり前になるとチームのクオリティが下がる傾向も見られる。チームの支援組織は必要であると考える。

アジャイル開発におけるシステム監査

  • スプリントプランニングやデモ、意思決定等、いつ誰が実施したかは、後で見て分かるよう、記録に残していた。特に意思決定は仕様書含む契約書とリンクしていることが重要である。ガバナンスの観点で実施しているが、システム監査を受ける際にも役立つと考える。
  • アジャイル開発だからといって、システム監査に対して特別な対応をする必要はあまりなく、基本的にはプロジェクトを通して行ったことの証跡をドキュメントとして整備して、スクラムを機能させるために適切に業務を行っていれば、問題ない。
  • 過去に所属していた組織のアジャイル開発事業では、プロジェクトを通して実施したこと（プロダクトバックログのつくり方・更新等）について、全て証跡を残すように事業者に依頼していた。
  • 意思決定に大きな変化があった際の対応として、ある外部団体が出している非ウォーターフォール開発に関する契約書の雛形では、「連絡協議会」においては会議の開催や両者での合意等を議事録に残す、といったような記載があり、その通りに実行していた。

以上