各種留意事項

全般的な事項

各種ドキュメントについて

アジャイル開発では包括的なドキュメントよりも動くシステムを重視するからと言って、全くドキュメントを作成しなくてよい、というのは必ずしも正しい認識ではありません。ドキュメント作成が重視されがちなウォーターフォールと比較して、不必要なドキュメント（保守工程で参照される機会があまりなく、ソースコードでも代替できるプログラムの詳細設計書等）は省くという姿勢はありますが、例えばシステム全体の概要を認識するための構成図や基本設計、ERDやエンティティの定義、システム境界のインターフェース等をドキュメント化することはしばしば運用・保守や改修に役立ちます。

また、ウォーターフォールでは、情報システムを開発する前にドキュメントを作成して、要求や仕様を言語化しますが、アジャイル開発では、動くシステムによって要件を調整したり変更したりするため、ドキュメントの作成は主要な機能の開発後や運用開始前に行うことも多くなります。ドキュメントを作成しながら開発を進めることを妨げることはありませんが、構築した情報システムを基にドキュメントを作成する方が効率的なことも多く、開発の前や開発と並行して作成するドキュメントと、プロジェクトの後半又は終盤に作成するドキュメントとを見極め、後者のためにプロジェクトの後半又は終盤に作成期間をまとめて設けることが望ましいです。

要件定義書について

アジャイル開発であっても、限られた工数の中で際限なく変更を取り込めるわけではなく、従来の開発スタイルと同様に、あらかじめ作るべき機能やデータモデルなどを把握しておくことが重要です。特に、データモデル（ERDやエンティティ定義等）とシステム境界のインターフェースの定義は後から変更すると影響が大きいこともあり、予め整理・整頓しておくことが望ましいものの1つです。

プロジェクトの制約が厳しいほど、開発範囲と優先度を明確にし、スムーズにプロジェクトを運営することが必要となります。特に開発期間が短いプロジェクトでは、スプリント期間中にも要件が決まらず開発が滞ったり、関係者への根回し不足によって「ちゃぶ台返し」が発生したりしないように注意が必要です。

コラム：要件定義書における工夫

品質管理について

アジャイル開発であっても従来の開発スタイルと同様に、品質の管理が重要です。そのために、発注者と受注者が協力して開発に取り組み、開発された情報システムの品質の良し悪しを発注者が判断する必要があります。

また、アジャイル開発は変更に柔軟に対応するのが特徴ですが、変更を際限なく取り込めるわけではありません。特に短納期のプロジェクトでは、プロダクトバックログやスプリントバックログの作成にあたって、品質を確保するために、残りのスプリント数などを考慮して要件に優先度をつけるなど現実的な判断を行うことが必要です。

ある省庁では、品質確保の工夫として、機能や実現方式等を動くシステムを用いて先行して決定する一方で、品質を確保するために専門のチームを設置し、これらを並行して進めました。

第三者チェックの有効活用

まだ政府内ではアジャイル開発の事例は多くありません。アジャイル開発に初めて取り組む場合は、上手くいっているのか、このまま進めて大丈夫なのかといった不安が生じるだけでなく、当事者では気付けないリスクが潜在している可能性もあります。

そこで、開発手法としてアジャイル開発を採用する場合には、専門知識を有する第三者（CIO補佐官、外部の支援事業者など）による状況判断の機会を設けるようにしましょう。ただし、せっかくそのような機会を設けても、形式的なセレモニーとなっては意味がありません。プロジェクトの運営状況や課題について説明し、専門知識を有する第三者の理解と適切な助言を得られるようにしましょう。定期的に状況判断の機会を設けるだけでは不安な場合には、支援事業者に伴走型で支援してもらうことも選択肢の一つです。このような対策をしっかり行うことが、重要な機能が実現できなかった、利用者の求めるものと違う情報システムになってしまったなどといった問題を未然に防ぐことに繋がります。

状況判断の機会を、全体プランニングのタイミングでマイルストーンとして設定することも重要です。

継続的なチーム体制の確立

システム開発プロジェクトは構築した情報システムをリリースして終わりではなく、その後も継続していくものです。情報システムがリリースされてから実際に情報システムが利用者に利用された結果、使い勝手の良し悪しなどがフィードバックされ、それを踏まえて改修していくことを考えると、むしろ、稼働を開始してからが始まりであるとさえいえます。

設計・開発の工程をふりかえり、保守開発において必要なチームの構想や工夫を整理しましょう。例えば、国民など、組織外の利用者のニーズが把握しきれず、仮説を立てて構築した機能については、実際の利用状況を分析したり、利用者のニーズを探索したりすることとなるため、それらのスキルを持ったメンバーを新たに迎えることを検討する必要があります。

また、情報システムを開発する段階で、ユーザーのログイン数やアクセス数、登録・変更等の処理件数といった利用状況を収集・可視化することができる仕組みを（情報の取り扱いやセキュリティに配慮しつつ）予め組み込んでおくと、分析に役立ちます。