ソフトウェア開発201の鉄則 原理43:要求:なぜこの要求項目が含まれたかを記憶せよ

要旨

* 要件は、いくつもの活動が積み増さなって決定されるものだ
* そのようないくつもの活動と、その結果を、一つの要件の背景として記録すること 
* 後に要件変更が発生した時に、その要件を決定するに至った過程と整合性をとルためである
* 決定のために参照した文献へのポインタ、議論の議事録といったものを記録すること。これが、一つの「進化する」要件のために必要な活動である

解説

「あれ、これ、誰が決めたんだけ？」と後から首を捻る要件、ありますね。

この原理の「要求」の項目にいくつも記述があるが、要求は、難しいものである。一つの要求を決めるのに、たくさんの活動とたくさんの決定を要するものだ。

ヒアリング、議論、調査、アンケート、プロトタイプ。様々な活動から導き出されるものである。

それぞれの結果は、矛盾するものもあるだろう。

「起動時間がX秒以内であること」その以内が必要という意見と、いや、そのための実装なら他の機能が必要という意見。その度に、なんらかの理由をつけて、いったんその時点での最新の仮決定をするはずだ。

そんなことの繰り返しだから、きっと、そんな理由、後にきっと、忘れるだろう。

なので、その一つ一つに、どこで、誰が、どのような過程を経て決めたのか、を記録しておこう、ということ。

要件を決めるのに一番大事なのは、「決める」ことだ。大体、決まらない。

あまりいい言い方ではないが、「強引でもいいから、決める」姿勢の方がいいように思う。その決定が全て仮決定で、のちの議論で変更してもいい、という前提で。

決まっていない、より、仮ですが、こうしています、といった方が、のちの活動がずっと進むはずだ。

そして、その時に、その「仮」をどうやって決めたか、が添えられていると、その一つ一つの仮の意味合いが増し、より効果的だろう。

なお、よくこの手で、「上役に決める」というケースがある。社長のツルの一言、といったもの。

この手は、要件活動の最初からツルの一言があるのであれば、仕方ない。最初からそれは割り切って進めればいいので。

散々議論やプロトを繰り返して、最終段で上長がそれを覆すようであれば、そんなプロジェクトは、抜けた方がいい。上長のために開発やってるんじゃないから、ネ。