「魔女化しないためのプロジェクトマネージメント」

第一章「…要件定義の時に言った、ような」

要件定義ってなんぞやという感じなんですが。
とある人がこういうものを実現するためのシステム作りたんだけど？
と言う事がきっかけで、
じゃぁそれを実現するためにはどういうものが必要になるのかな
となり、
まずは何から決めましょうか？
となったときに出てくるのが要件定義というもの。
機能まで話が進んじゃうとそれはもう設計かな…。
まぁ、それは置いておいて。

この要件定義というものを決めるとなったときに難しいのが、それをどうやって決めていくかです。
大抵は情報システム部というようなところが中心となって、実際に使う人の意見を聞くなどして詰めていくのが理想だと思われます。
ただ、コレには罠があって人が集まれば集まるほど意見というものはまとまりにくくなります。
ある人はコレが必要、別の人はコレが必要…。
こういう状況になると発散していってしまい、打ち合わせがエンドレスになります。
4時間とか会議している時点でゲームオーバーでしょう…

こうならないために関係者だけを集めて用件詰めちゃえ！
と、なるのもよく見かけるパターンですが、コレにも罠があります。
このパターンで恐ろしいのは、「ある程度形になったところで」実際に運用する人達から文句が噴出するということです。
必要な機能がなかったり、余計な機能があったりとまぁ、色々なイベントが起こります。
それはもう泣きたくなるくらい。
その結果、機能追加、改修等が必要になってしまうわけです。

システムの方向性を決める第一歩。
ここをしっかりやっておかないと後々大きなずれとなってしまうのです。

そんなことわかってるし！
と思うのですが大抵この部分の時間と予算は削られます。
紙切れ一枚（エクセル方眼紙で1枚）なんてことも良くあります。
「そんな要件定義で大丈夫か？」
大丈夫だ問題ない時もあれば、この先暗雲立ちこめる世界が待っているときもあります。
良くも悪くも初めが肝心。
最後の最後に「それって要件定義の時いったよね」なんてことがないように初めにしっかりやっておきましょう。

つづく…。