--- type: guideline title: 各種留意事項 source: デジタル庁 ds_code: ds-121 category: government-system updated: 2021-03-30 source_url: https://www.digital.go.jp/assets/contents/node/basic_page/field_ref_resources/e2a06143-ed29-4f1d-9c31-0f06fca67afc/52bfa543/20220422_resources_standard_guidelines_guidebook_02.zip --- # 各種留意事項 ## 全般的な事項 ### 各種ドキュメントについて アジャイル開発では包括的なドキュメントよりも動くシステムを重視するからと言って、全くドキュメントを作成しなくてよい、というのは必ずしも正しい認識ではありません。ドキュメント作成が重視されがちなウォーターフォールと比較して、不必要なドキュメント（保守工程で参照される機会があまりなく、ソースコードでも代替できるプログラムの詳細設計書等）は省くという姿勢はありますが、例えばシステム全体の概要を認識するための構成図や基本設計、ERDやエンティティの定義、システム境界のインターフェース等をドキュメント化することはしばしば運用・保守や改修に役立ちます。 また、ウォーターフォールでは、情報システムを開発する前にドキュメントを作成して、要求や仕様を言語化しますが、アジャイル開発では、動くシステムによって要件を調整したり変更したりするため、ドキュメントの作成は主要な機能の開発後や運用開始前に行うことも多くなります。ドキュメントを作成しながら開発を進めることを妨げることはありませんが、構築した情報システムを基にドキュメントを作成する方が効率的なことも多く、開発の前や開発と並行して作成するドキュメントと、プロジェクトの後半又は終盤に作成するドキュメントとを見極め、後者のためにプロジェクトの後半又は終盤に作成期間をまとめて設けることが望ましいです。 ### 要件定義書について アジャイル開発であっても、限られた工数の中で際限なく変更を取り込めるわけではなく、従来の開発スタイルと同様に、あらかじめ作るべき機能やデータモデルなどを把握しておくことが重要です。特に、データモデル（ERDやエンティティ定義等）とシステム境界のインターフェースの定義は後から変更すると影響が大きいこともあり、予め整理・整頓しておくことが望ましいものの1つです。 プロジェクトの制約が厳しいほど、開発範囲と優先度を明確にし、スムーズにプロジェクトを運営することが必要となります。特に開発期間が短いプロジェクトでは、スプリント期間中にも要件が決まらず開発が滞ったり、関係者への根回し不足によって「ちゃぶ台返し」が発生したりしないように注意が必要です。 コラム：要件定義書における工夫

あるアジャイル開発を前提としたプロジェクトでは、発注者側の要件や思いを事業者に分かりやすく伝えて短期間での開発を円滑化するため、要件定義書で次のような工夫を行いました。

  • 要件定義書の別添として「システムイメージ（案）」を作成。利用者、関係者間での業務や情報のフローを図解するとともに、利用者向け機能（スマートフォンを想定）や業務担当者向け機能（PCを想定）の画面イメージ、画面遷移、入力・表示項目、統計データ分析のアウトプットイメージ等を、あくまで調達時点での案としながらも具体的に記載。

  • 管理するデータについても、Rawデータ、正規化データ、統計データ等に大きく分類した上で、主要なデータについてデータ項目やリレーション等を案として記載。

また、運用フェーズの品質確保と効率化のため、事業者から提案を求める事項として次のような工夫を行いました。

  • システム運用に関する事項を「稼働監視、セキュリティ監視、リソース監視等を適切に行う仕組みとして、基本的にはクラウドのマネージドサービスを活用することを想定しているが、必要な場合は理由を添えて想定するツールを提案すること」として、事業者からの提案を積極的に依頼。

  • 運用フェーズでの CI（継続的インテグレーション）について、インフラ層もコード化（Infrastracture as Code）してテスト環境や検証環境を容易に準備できることを要件とした上で、ツールや運用方法の提案を依頼。

  • ミドルウェア等のバージョンアップやアプリケーションの機能改修に伴う検証工数を削減するために、デプロイ方法（カナリアリリース後のローリングデプロイやブルー/グリーンデプロイ等）によってコストを下げながらバランスよく対応する方法の提案を依頼。
### 品質管理について アジャイル開発であっても従来の開発スタイルと同様に、品質の管理が重要です。そのために、発注者と受注者が協力して開発に取り組み、開発された情報システムの品質の良し悪しを発注者が判断する必要があります。 また、アジャイル開発は変更に柔軟に対応するのが特徴ですが、変更を際限なく取り込めるわけではありません。特に短納期のプロジェクトでは、プロダクトバックログやスプリントバックログの作成にあたって、品質を確保するために、残りのスプリント数などを考慮して要件に優先度をつけるなど現実的な判断を行うことが必要です。 ある省庁では、品質確保の工夫として、機能や実現方式等を動くシステムを用いて先行して決定する一方で、品質を確保するために専門のチームを設置し、これらを並行して進めました。 ## 第三者チェックの有効活用 まだ政府内ではアジャイル開発の事例は多くありません。アジャイル開発に初めて取り組む場合は、上手くいっているのか、このまま進めて大丈夫なのかといった不安が生じるだけでなく、当事者では気付けないリスクが潜在している可能性もあります。 そこで、開発手法としてアジャイル開発を採用する場合には、専門知識を有する第三者（CIO補佐官、外部の支援事業者など）による状況判断の機会を設けるようにしましょう。ただし、せっかくそのような機会を設けても、形式的なセレモニーとなっては意味がありません。プロジェクトの運営状況や課題について説明し、専門知識を有する第三者の理解と適切な助言を得られるようにしましょう。定期的に状況判断の機会を設けるだけでは不安な場合には、支援事業者に伴走型で支援してもらうことも選択肢の一つです。このような対策をしっかり行うことが、重要な機能が実現できなかった、利用者の求めるものと違う情報システムになってしまったなどといった問題を未然に防ぐことに繋がります。 状況判断の機会を、全体プランニングのタイミングでマイルストーンとして設定することも重要です。 ## 継続的なチーム体制の確立 システム開発プロジェクトは構築した情報システムをリリースして終わりではなく、その後も継続していくものです。情報システムがリリースされてから実際に情報システムが利用者に利用された結果、使い勝手の良し悪しなどがフィードバックされ、それを踏まえて改修していくことを考えると、むしろ、稼働を開始してからが始まりであるとさえいえます。 設計・開発の工程をふりかえり、保守開発において必要なチームの構想や工夫を整理しましょう。例えば、国民など、組織外の利用者のニーズが把握しきれず、仮説を立てて構築した機能については、実際の利用状況を分析したり、利用者のニーズを探索したりすることとなるため、それらのスキルを持ったメンバーを新たに迎えることを検討する必要があります。 また、情報システムを開発する段階で、ユーザーのログイン数やアクセス数、登録・変更等の処理件数といった利用状況を収集・可視化することができる仕組みを（情報の取り扱いやセキュリティに配慮しつつ）予め組み込んでおくと、分析に役立ちます。