システム開発におけるプロジェクト計画書を作成することをテーマに、それぞれの章立ての内容を解説している。今回は、プロジェクト計画書の要件定義の章に記載する内容について述べる。
→ プロジェクト計画書の全体（章立て）は こちら
要件定義工程では、次工程のシステム設計を進めるためにシステムに求められる機能、動作、UIなどのシステムの仕様を明確にしていく。
なお、ここではプロジェクト計画書に記載する内容を述べる。要件定義やシステム仕様に関する考え方や具体的な進め方の詳細については別途まとめ中。
6章 要件定義
この章では、要件定義工程をどう進めるのか計画を述べる。計画というものは最終的にWBSでタスクにまで詳細化されなければならないので、この工程の作業をWBSにブレークダウンできる内容にするということを意識する必要がある。ブレークダウンできる内容にするには、下記の考え方で整理すればよい。
① その工程の大まかな流れを示す（＝２．要件定義工程の内容と流れ）
② ということは、①ではどんなことを実施するのかを決める必要がある（＝２．要件定義工程の内容と流れ）
③ 加えて、なぜ②のようなことを実施するのかの説明も必要（＝１．要件定義工程の目的と方針）
これを読みやすいように、その工程の「目的と方針」→「内容」→「作業の流れ」という構図にすれば、要件定義工程の筋道を概ね理解できる内容となるかと思う。ただ、今回は「目的と方針」を冒頭にして、「全体イメージ、作業の内容」をまとめて最後に「システム仕様」の詳細を書くことにした。（書いていくうちにこうなってしまった・・・）
１．移行の目的と方針
「目的と方針」では、後述する「２．要件定義工程の内容」に先立ち、そもそもこの工程の目的は何であるのかということを明確にして進め方の方向性を示す。目的と方向性を示すことでその工程でやるべき内容が見えてくる。
ポイント：
・目的：この工程の簡単な説明と何を目指すのかを明確にしておく（簡潔に書けばよい）。これはプロジェクトによって異なるので正解はない。ただし、企画書（プロジェクト発注側が作成する）や提案書（プロジェクト受注側が作成する）の内容に相違が無いかは注意したい。下記の例では「システムの仕様の確定を確定し合意すること」とした。この目的を達成できるように次節以降で、要件定義工程の内容を掘り下げていくことになる。
・方針：要件定義工程を進めるうえで、定めておくべきことを述べる。進め方、体制、環境など５W1HやQCDの観点で、こういう風に進めるということを明記しておく。こちらも目的と同様に、企画書や提案書といった前提となる資料の内容との整合性は確認しておきたい。
・そもそも「方針」とは何か。「方針」について詳しい記事 → 方針とは何か
・決めるべきいろいろな方針に関する記事 → プロジェクト推進のためのいろいろな方針(作成中)
・要件定義とは → 要件定義とは（作成中）
| 例： １．要件定義工程の目的 要件定義工程では、基本設計工程及び詳細設計工程に先立ち、業務要件、機能要件、非機能要件を整理し、システム仕様を確定させる。また、確定したすべてのシステム仕様を記載したシステム仕様書を作成し、貴社と弊社にてその内容を合意する。 |
| 例： ２．要件定義工程の方針 要件定義工程の方針を下記に示す。 ①システムの仕様を確定するまでのおおよその流れは以下の通りである １．業務要件を整理・確定し、ユースケースを洗い出す ２．ユースケースに基づき、機能要件の整理・確定し、システム仕様書を作成する ３．業務要件を基に非機能要件の整理・確定し、システム仕様書を作成する ②要件定義工程では、貴社にて作成した「XXXシステム更改プロジェクト 提案依頼書 別紙８ XXXシステム更改追加開発要件一覧（.xlsx）」の内容を基に、システム仕様書を作成するまでの整理や確認を行う ③要件及びシステム仕様においては、それぞれ識別子を割り振り紐づけを行うことで整合性を確保する 紐づけの構造は以下の通りとする [業務要件] → [機能要件]及び[非機能要件] → [システム仕様] また、次工程以降の設計やテストの内容に対しても紐づけを行いトレースできるようにする ④要件定義工程の成果物はテスト工程のInputとなる。このため、テスト仕様書を作成することを意識した内容とし、本工程で作成する成果物の品質チェックにおいてはその観点を取り入れたレビューを行う ⑤要件定義書の内容において、要件定義工程以降に要件の変更が生じた際には、XXXXシステム更改プロジェクト 管理計画書 X章 変更管理」の内容に従い対応する ⑥要件定義工程は弊社が主体で進めるが、貴社には下記の内容について協力いただくものとする
|
参考：
・今回の例では、方針として主に6つのことを記載してみた
① 要件定義工程の全体の流れ
② 要件定義工程を進めるうえでベースとなる資料
③ 各要件とシステム仕様はトレースできるようにする
④ システム仕様はテスト仕様書のInputになり得る内容であること
⑤ 要件の変更は「変更管理」に則って対応する
⑥ 業務側の役割
２．要件定義工程の内容と流れ
要件定義工程の大まかな流れを示す。改めてになるが、要件定義工程で実施することは、業務要件、機能要件、非機能要件を整理し、システム仕様書を作成することである（あくまでこの計画書では）。作業をフローチャートにまとめると、おおよその流れが理解しやすい（＝作業の全体イメージ）。また、ただ、フローチャートのそれぞれのボックス（長方形の図形）に対して、どのようなことを実施するのかがわかる説明もあった方が良い（＝作業の内容）。
ポイント：
・作業と成果物を明確に記載にする（本当は縦軸に登場人物を追加して「承認」などの作業プロセスも設けたかった）
・InputとOutput（成果物）はできるだけ詳細に記述したい。下記の例は少々手を抜いている・・・例えば、[機能整理]のボックスは、機能一覧をベースに必要に応じて修正を加えることを想定しているが、下記のフローチャートだけでは読み取れない
| 例： 要件整理において、システム仕様書を作成するまでの流れのイメージと作業の内容を以下に示す。 ＜作業の全体イメージ＞ 
（※）システム仕様の詳細については、次節「３．システム仕様」にて述べる |
参考：
・業務要件については、予め業務側（ビジネス側）で整理されているものなので、新たに何かを作成するというよりは、整理が十分であるかを確認する
・非機能要件は、正直、機能要件とは異なり少々設定しにくいかもしれない。機能要件は必要な機能が明確に表現できるが、非機能要件はシステムを横断的に設定するものが多くややふんわりした印象。非機能要件はどのようなことを設定すれば良いかについては別途まとめる
・できれば、フローチャート、作業内容については、開発するシステム及び開発チームそれぞれに対して何を実施するのかを大まかに示したいところ。体制と役割、環境についても触れておくと計画書としての完成度は高まる
・非機能整理は、システム設計にかかわらず移行などの要件も加えているが移行計画などで整理してもよい
・ユースケースについて → こちら
３．システムの仕様
要件定義工程ではシステム仕様書を作成すると述べてきたが、ここではシステムの仕様とは何かを具体的に示す。目的と方針で述べてたかったが、長くなってしまうのでここでは新たな節を設けて記載しておくことにした。なお、以下の「項目」列は一例を記載している。ほかにも色々と要素はあると思う。
| 例： ＜機能要件にかかわるシステム仕様一覧＞
|
＜非機能要件にかかわるシステム仕様一覧＞
|
あとがき
「目的と方針」→「内容」→「作業の流れ」という構図で書いていたが、いろいろと手を加えるうちに、構造が変わってしまった・・・。本当は、「１．要件定義工程の目的と方針」で、「３．システムの仕様」にあるシステム仕様の概念や詳細を述べて、更に「２．要件定義工程の内容と流れ」にある＜作業の全体イメージ＞の図を盛り込んで、要件定義工程の全体像を示したかった。そのようにして次の節で「２．要件定義工程の内容と流れ」に作業内容をもっと深堀り（例えばユースケースの整理としてはどんな作業をするのかなど）すると納得できるものができるの、だ、が、、、他の工程もその内容にすると、エライ時間がかかってしまう気がするので、一旦、上記の感じに落ち着いた。スケジュールや役割・体制については触れてもいいかなとも思うが、実際にはプロジェクト計画とは別にパワポで要件定工程の進め方の説明資料を作成して、工程開始前に関係者全体に説明する形式の方がプロジェクト計画書の内容がごちゃごちゃしなくて済む。
あとは、筆者自身も要件定義には詳しくないので、いろいろと作業の詳細を洗い出して調べてまとめるとなると時間がかかってしまうというのも上記の内容になってしまった理由の一つ。上記の内容については、節を別のページに分けてもっと内容を盛り込むべきかなど、今後いろいろと検討したい。（作業の内容は役割と成果物がわかるフローチャート形式するとわかりやすいし）
今回は要件定義について、いろいろ調べてみたが、要件定義に関連する書籍がいろいろとあるので学習教材には困らなかったことはありがたい。そういった書籍の紹介もいいかもしれない。
今後は設計についても調べていこうと思うが、こちらは、インフラ、アプリ、ＤＢとまあ盛りだくさんでボリュームがあり大変そうだなぁ・・・ぢ道にやるしかない