要件定義を制する者はプロジェクトを制する

システム開発の工程は
要件定義⇒基本設計⇒詳細設計⇒製造⇒単体テスト⇒結合テスト⇒ユーザーテスト⇒リリース
という順序を辿ることが一般的です。
開発する規模や内容によって間に他の工程が入ったりしますが、だいたいはこんな感じです。
まずは要件定義からお話ししましょう。

で、要件定義って？

開発の入り口、要件定義って何をするのでしょう。
要件定義とは何を作るのかを決めること。です。
お客さまの「欲しい」を聞き出して、明確な文章に書きだしていきます。

お客さまの希望を書き出すだけなので一見楽そうに見えますが、システム開発の出発点としてのここの工程は、経験を供わない人が行うと後々悲惨なことになる注意すべき工程です。

後でやりなおしとならない様に要件定義を行う上での注意点を並べてみました。

完成までのイメージをはっきりとさせよう

お客さまの要望を聞きながら、SEもしくはSI（以降SE）は画面やデータの全体の流れをイメージして、処理のフローがどこかで途切れていたり、データが突然発生していればお客さまに確認します。

これができないと必要な開発期間や人員が分からず、請求する料金も出てきません。

システムに詳しくないお客さまは希望したいものだけを言いいます。
途中データがどうなっているところまで意識していることはそうありません。
そこで要件定義のヒヤリングが不足していると、作り始めてから実は必要だったということがあり、追加の費用や期日の延期となってもめる話はいっぱいあります。
本当にいっぱいあります。

完成のイメージを明確にする。
これが出来ているか出来ていないかで、プロジェクトが平穏に終わるか、戦場になるかが分れる分水嶺となります。
お客さまの言葉を聞き逃さない上で、頭をフル回転してイメージを膨らませましょう。

CRUDは必ず押さえておけ

上の話の流れになりますが、CRUD（クラッド）は確実に確認しましょう。

CRUD（クラッド）とは４つの基本機能のイニシャルを並べた用語で、Create（生成）、Read（読み取り）、Update（更新）、Delete（削除）のことで、Read（読み取り）は１件表示とリスト表示とあります。

経験上お客さまはReadの部分を強く意識して、そのデータがどこから来るのかは考えてない場合があります。上でも触れましたね。

そこで改めてデータは手で画面に入力するのですか？と尋ねると、当然だろ何言ってんだみたいな反応があったりして、胃の痛みが治まる暇もありません。
ですが、聞いておかないと後々で入力画面や更新、削除画面が必要と騒ぐとになって、結局胃の痛みは治まらないのです。

データの表示はどうするのか。登録はどうするのか。変更は、削除はどうするのか。一覧表示をするのか。どの項目を一覧にだすのか。漏れなく確認してください。

実現できるかを確認する

フィージビリティという言葉があります。日本語で実現可能性と言います。
フローを考えているうちに、これどうやって実現するの？できるの？と思うことがで出てくることがあります。

フィージビリティはなるべく早い段階で確認して不安を除いておきましょう。

というのも、やっぱ無理となった場合の手戻りがプロジェクトの計画に大きな影響があるからです。下手をするとプロジェクト自体が消えかねません。

なので、フィージビリティでぞわぞわしたら、出来る出来ると安請け合いしないで、確認させてくださいと言えるようにしましょう。

また開発が始まってから、やっぱ無理ということが度々あります。そんな時のために代替え案は複数用意しておきましょう。

最初にリリース日を決めない

本当にもう一番困ったのが、これ。
中身は何も固まっていないのに、期限だけ決める。

本来の理想とする流れは、
何を作るか決まる⇒開発期間が決まる⇒リリース日が決まる
という順番です。

期限だけ最初に決めた後で伺った要求が、とてもではないが決めた期限では間に合わない量だったというのは枚挙に暇がありません。そんな時なんて顔をしていいか分からなくなります。

いつ出来るかなんては作業量が決まって初めて分かるものなのです。

それでも。それでもです。広告との兼ね合いとかで期限だけ決まってしまった場合。
どこまで作って、どこかを削るとか。期限までは必要な部分だけを作り、二次開発として後回しにするとか。お金を積んで、人員を大量投入して作り上げるとか。
お客さまとどこから担保出来てどこからできないかの線引きはしっかりと取引しましょう。

ここで出来る出来ると安請け合いして開発者が地獄を見ない様に、PMにはしっかりと管理していただきたいと切に願います。ほんとに。

というか要件定義の期限は守ろう

要件定義はお客さんの意見を聞いて、まとめて、文章に起こして、お客さんに確認して終わりです。
開発量によっては何度もお客さんと意見を調整する必要がありますが、さほど時間をかける工程ではありません。

ただお客さん側で関わる部署が多くて、なかなか調整がつかず、決め事が決まらないままずるずる伸びる場合があります。

以前携わったところでは、要件定義だけで開発期間の１／３までかかり、それでいて期限が伸びることも、人員が増えることもなく、ひたすらに地獄だった現場がありました。日程の調整の連続でお客さまとは凄まじく険悪になっていましたが、このプロジェクトは途中で外れたので完成を見なかったのですが、完成したのかな。

それでも、それでもお客さまの都合というのはあります。
その場合は要件が決まっている部分だけでもとにかく進める。というか、要件を伺っている間でも、フォーマットなり書きっぷりなり、基本設計で固めるべき部分はあるので、後戻り上等で進めるておくべきだと思います。

要件定義は期日までに。そして決まったら基本変えない。
大きいプロジェクトは要件が固まってから、初めて人員を招集してもバチは当たらないと思うのですが、どうでしょう。

基本設計の範囲を侵さない

お客さまの意見をヒヤリングしていると興が乗って、話が微に入り細に入り進むことや、要件定義書を作成するときに、分かりやすいようにと張り切ってそのまま基本設計で表現すべきところを書き込んでしまったりすることがあります。

要件定義で固めすぎて、基本設計に書くことがない、もしくは詳細設計で書くところを基本設計で書かれることがあります。

例えば画面の細かいレイアウトを要件定義に盛り込んだとしましょう。基本設計にも画面設計書というのを別に作ります。
そしてレイアウトの修正の指示があると、変更箇所は要件定義書と画面設計書の二か所を直す必要があるのです。

二重管理は修正の手間を増やすだけでなく、片方だけ直した場合に正解が分からなくなり、バグの温床となります。

お客さまの要求を聞くSEはどこからが要件定義に盛り込んで、どこからが基本設計に入れるのかを考えながら聞いておかないと、面倒なことになります。

要件定義は開発で一番クリエイティブな部分

以上が要件定義の注意点ですがどうでしょうか。
要件定義で大事なのは想像力です。
まだ全く完成されていないシステムの完成イメージをどれだけ強く思い描けるかにかかっています。

お客さまの持つイメージはたいがいフワっとしていて、そこから「完成した。あとは作るだけ。」というところまで引き上げていきます。

成果物としてはとても小さなもので、評価としても小さくなりがちですが、ここでのちょっとのずれは後の工程の大きなずれにつながっていきます。
後の工程はテスト工程でいくらでも修正の機会はありますが、要件定義の出戻りだけはプロジェクトの影響が半端ありません。

なので一番慎重に進めていただきたい工程だと思っています。

システム開発プロジェクトに携わる人にとって幸いとなりますように。