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

概要

日時

令和7年（2025年）11月7日（金）13時00分から15時00分まで

場所

オンライン（Microsoft Teams）

議事次第

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

資料

出席委員

狩野座長
杉井委員
岡島委員
佐野委員
木村アドバイザー

議事要旨

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

「官公庁特有の制約（予算、品質保証、意思決定等）の洗い出し」について

官公庁におけるアジャイル開発の制約事項とは、必ず守らなければならない制約なのか、乗り越えられるものなのか、そこを区別して議論した方がよい。まず予算要求段階で留意すべき事項について議論を始めるのが望ましい。過去の経験において、所属組織のサービスガイドラインを作成した際、予算要求について十分に記載されておらず、どうするかという議論になった。また、予算要求の時点でアジャイル開発を採用するかどうかを見極める必要があると思う。（調達対象となるプロジェクトにおいて、アジャイル開発手法の採用・実践が効果的であるかを適切に職員が判断できるよう）「アジャイル開発採用基準ガイドブック（案）」といったドキュメントにも時系列を組み込むべきだと考える。
官公庁におけるアジャイル開発の制約の度合いも様々であり、新しい解釈を示してリスクを解消していくこともあれば、ユーザー機関の運用で補う等もあると考える。該当論点の議論の際に具体的に決めていきたい。
過去、自治体との共同研究の際、予算要求の方法が、アジャイル開発の場合と他の方法とで異なる点があった。要件定義はユーザーストーリーに基づいて価値を見積もることが必要である。プロジェクトの作業スコープが大きく変わらないが、開発手法の違いがあるため、その点について今後も議論していきたい。
委託先のベンダーにとっても、「アジャイル開発採用基準ガイドブック（案）」が役に立つガイドとなっていく想定か。ベンダーとしては、アジャイル開発が可能となっても、本来のアジャイル開発と実態が大きく異なることで、入札を躊躇したり、優先度が下ることもあると考える。

「アジャイル開発とウォーターフォール開発のハイブリッド開発実践のリスクとその対策」について

資料2のハイブリッド開発のイメージ図（P.11）に違和感がある。どのプロセスでアジャイル開発を適用するのか実務的な知見を含め委員にアイデアをいただきたい。諸外国では、最後のテストのリリースでハイブリッド開発を適用している例があるように、ハイブリッド開発にも様々なパターンがある。
チーム内ハイブリッドは、民間でも頻繁に行われていたスタイルで、ウォーターフォール開発からアジャイル開発への過渡期のイメージである。
同じシステムでも、機能要件を決めて作る部分と、アジャイル開発で作る部分と分けるというハイブリッド開発の考え方もある。
インフラやプラットフォーム等については、ウォーターフォール開発でしっかり形作る必要がある。一方でユーザーインターフェース等については、アジャイル開発を回していくという使い分けが必要である。
技術的なリスクを考慮しなければならない時は、チーム内ハイブリッド開発（V字型モデルの基本設計から結合テストまでの部分をアジャイル開発で実施するケース）もあり得るのではないか。
チーム間ハイブリッド開発（他チームと協働・連携した開発を進める必要がある場合に、自チームはアジャイル開発だが、他チームはウォーターフォール開発を実施するケース）については、他のシステムとの連携をイメージしているが、スケジュール上、マイルストーンに注意が必要だと考える。
現在進行中のプロジェクトや過去のチーム間ハイブリッド開発の経験から、情報システム部門はウォーターフォール開発で進めようとする一方、アジャイルチームと認識の違いがあり、インターフェース仕様の決定時期で意見が食い違うことがあった。しかし、アジャイル開発でも早い段階で仕様を決定したり、モックアップ（試作品）を使ってテストを進めたりすることは可能である。最終的には、開発途中で変更があれば柔軟に対応する姿勢が重要である。ただし、ガイドラインの書き方によって受け取り側の理解度やリスクが変わるため、その点にも注意が必要である。
プロジェクトの中でアジャイル開発に向いている部分と、向いていない部分があり、どのように機能分離することができるかについて実務的なガイドラインがあると役立つと考える。
（調達対象となるプロジェクトにおいて、アジャイル開発手法の採用・実践が効果的であるかを適切に職員が判断するための）「アジャイル開発採択チェックリスト（案）」内の「①仕様の不確実性」について、システムのKPIを決める際は、利用率などを指標にして機能完成後も継続的に改善が必要である。不確実性とは、自分たちでコントロールできない部分が該当するのではないか。
「仕様変更」の不確実性、というよりは、「リリース後のフィードバックを引き金とする、機能の追加・変更・削除」というニュアンスのほうがアジャイルの本質に近い表現だと考える。
不確実性とは、ユーザーにとっての価値が何かを探りながら軌道修正をしていくことだと考えるが、確定した仕様があって、アジャイル開発だから変更するという考え方はしないのではないか。

「アジャイル開発の採用推進に関するロードマップ（案）」について

大規模アジャイルフレームワークの一部には、経営者からマインドを変えて現場へ、というものがある認識である。一方で契約・調達・監査や制度面に関してはあまり書かれていない印象であり、参考になるかどうか分からない。
過去に所属していた組織では、過去3年間アジャイル開発の浸透を目指して様々な取組みを実施した。その中でロードマップもあったが、大筋は資料2（P.16）のサンプルと大きく変わらない。主な内容は、ガイドラインやルールの整備、契約書や予算要求用のひな形を作成した。さらに、アジャイル開発に馴染みのない職員にもその有効性を広めることを意識しており、本ロードマップには、この視点も加えるとよいと考える。
東京都の「アジャイル型開発プレイブック」と、インタビュー結果は公開されているので参考にしていただきたい。
アジャイル開発の有効性を実際に体験することで、有効性が大きければリスクを許容する等、考え方も柔軟に変えていける。発注者側の人材育成を早めに進めていくのが望ましい。
組織の開発支援体制にある「各開発チームを支援するチーム」と同じ意図だとは考えるが、必要に応じて、コーチ・アドバイザーも組み入れて、いわゆるCoEを、パイロットの関係者（発注者）を中心に組むことが望ましい。
行政の仕事では税金を使うため失敗が許されにくいというマインドがあるため、アジャイル開発と相性がよくない部分はある。しかし、最近は発注力や育成が課題になっており、トップダウンで意識改革を進めることも重要である。アジャイル開発導入時には発注者側の育成も必要で、プロダクトオーナーの役割を担える人材育成や研修・セミナーをロードマップに含めてほしい。

以上