下流工程の要件定義

いわゆる要件定義というものをあまりしてこなかった私のような人間でも、それなりに経験が長ければそれに近いことはやってるよね、というお話です。

基本的に、下流工程しかやらない方というのは、その人の他に必ず上流工程をやっている方が別にいて、その人から依頼を受けるか指示を受けるかして作業を行うわけです。でも、その指示ってどれだけ具体的なものなのでしょうか。一から十まで全て指示するようなことは不可能なので、それなりに曖昧性を保ったものになるはずです。

例えば、ある画面を作るという依頼を受けたとしましょう。その画面に表示されるオブジェクトや、画面の一覧みたいなものは仕様として定まっているかもしれません。
しかし、レスポンスが帰ってこない場合どうするかとか、同時にイベントが起きたらどっちを優先するのとか、そういったことまで考慮されていることは少ないでしょう。機能を実現する様々なモジュールとのつなげ方なんかもそうです。こういったことを決めるには、曖昧な部分をなくすために関係者に問い合わせて、設計を詳細化していくことになります。

この作業は、いわば顧客の要求を聞いて曖昧な部分をクリアにしていく作業で、名前としては設計ということになっていますが、顧客からの依頼を明文化するという意味では要件定義をやっているとも考えられるわけですね。

もちろん、コスト面の判断や、要件定義書と呼ばれる正式なドキュメントの知識は身につかないですが、下流工程の業務でもある程度意識していればその後上流工程に移った場合も、スムーズに移行できるのかなと思ったりしました。