Step.2 要件定義の事前準備
要件定義の作業に入る前の開始準備として、今直面している検討対象の内容にかかわらず、心得ておくべきことがあります。
ここでは、準備に必要な具体的な内容について、紹介していきます。
１ 要件定義で職員が得た知識は貴重な財産
【標準ガイドライン関連箇所：第３編第５章全般】
要件定義を担当した職員は、要件定義を行うことにより、サービス・業務の企画内容、情報システムの要件に係る背景、決定経緯、理由等のドキュメントには表現が難しい暗黙知（職員が暗黙のうちに有する、長年の経験や勘に基づく知識）などの知識を収集しつつ可能な限り客観的にドキュメント化（言語化）し、形式知として蓄積していきます。これらの知識は、設計・開発以降の工程において、詳細な仕様の決定、設計のレビュー、要件変更の決定や受入テストのシナリオ作成等の際に、重要な材料となります。
要件定義を担当した職員が途中で異動してしまい、これらの知識がなくなってしまうことで、設計・開発以降の工程で、無駄な作業の発生、誤った判断、実現したい内容からのかい離、利用者視点での品質の低下が発生し、プロジェクト全体の目標達成に影響を与えてしまうことが少なくありません。
このため、ＰＪＭＯは、これらの知識を有する職員が継続的にプロジェクトに取り掛かれるよう調整する必要がありますが、これらの知識を日常的に整理・文書化し、やむを得ず、これらの知識を有する職員がプロジェクトを離れてしまうときに、十分な引継ぎを行うよう備えておくことが重要です。
また、要件定義を複数人で行いクロスチェック等を行うことで、複数人にこれらの知識が蓄積され、相互に深めていく方法も効果的です。
- 事例5-1
発注者側のキーマン交代で目的が異なる情報システムが出来上がる
事例：発注者側のキーマン交代で目的が異なる情報システムが出来上がる ある省の業務システム開発プロジェクトにおいて、プロジェクト立上げ時から一人でＰＪＭＯを担当していた職員Ａさんが、設計・開発工程の途中で、異動することになりました。後任にはＡさんとは異なる情報システムの経験を持つＢさんが着任しました。急に決まった異動だったため、引継ぎ資料を準備する時間もなく、プロジェクトで作成したドキュメントの概要を、口頭で説明することで精一杯でした。  Ａさんが担当していた期間中、設計・開発事業者は、各機能の要件定義までの詳細な経緯をＡさんに確認し、それを踏まえて設計・開発を進めていました。交代後、Ｂさんも同様に確認を受けましたが、Ａさんから詳細な検討経緯等については引継ぎを受けていなかったため、Ｂさんは自身の経験に基づいた判断で、設計・開発事業者に回答や指示を行いました。その結果、開発された情報システムはＡさんが当初目指していた目的を達成しないものとなってしまいました。  この事例では、Ａさんが自身に蓄積された設計・開発工程までに得た知識を、日常的に文書化しておけば、引継ぎ資料として活用できたはずです。また、突然の担当者の交代は、人事異動だけではなく、急病や家族の介護等、不可抗力で発生することもあります。このことを想定し、各工程への関わりを複数名で行う体制を構築することにより、知識の蓄積がＡさん一人だけに集中する事態を避けられたはずです。 リリースまでには大量かつ多岐に渡る情報が発生するため、個人の頭の中だけに残すことは不可能です。連続して蓄積された知識は、情報システム開発における様々な作業で不可欠なもののため、主要な担当職員の交代は、プロジェクトの成否に大きな影響を及ぼします。情報システムの開発には、連続して蓄積された知識がとても重要なため、それらを残すための日常的な備えが必要です。 |
|---|
２ プロジェクト計画や業務要件を把握する
【標準ガイドライン関連箇所：第３編第５章全般】
要件定義では情報システム等に関わる詳細な要件も検討するため、どうしても各論に目がいきがちとなります。しかし、それぞれの要件は、政策目的やプロジェクト目標の達成、利用者への価値の提供のためにあることを忘れないでください。
例えば、関係者の要望を単に取り入れようとし、情報システムに求める要件が過度に増加することが多々ありますが、このような場合には、その要件の上位に当たる、法令、政策目的・目標の実現やプロジェクト目標の達成まで立ち返り、必要十分な情報システム化の範囲を選択することが大切です。
このため、要件定義を開始するに当たって、まずは、政策目的、目標、対象範囲、サービス・業務企画の方向性等、実施計画等を把握し、プロジェクトとして達成すべきゴールを把握します。その後、サービス・業務企画の活動でまとめた要件定義書の「業務要件定義」を確認し、サービス・業務から見た情報システムに対する要求を理解した上で、要件定義を行う範囲を特定します。