要件定義で何をすればいいのか

(自分のストーリーからこっちのpublicationに移した)

私はプログラマとして仕事をしているが、上流工程、特に要件定義が苦手だ。

これまでは、だいたい要件とか仕様は決まっていて、画面イメージや機能の細かな仕様を決めるところから始まるものが多かった。また、まずは作ってみてお客さんから指摘があったら修正すればよい、ただしお客さんに提供するスピードは重視する、というスタンスだったのもあり、予めがっちり決めてから開発を進めるというやり方自体を敬遠していた。方法自体断片的にしか知ってないのもある。要件定義書を書けばいいの?

「要件定義」で検索するとSIerの方が書いたであろうWebサイトがたくさんあって、読むと重厚なドキュメントをたくさん書かなきゃいけないような気分になる。

あまり難しく考えないでシンプルに考えよう。

「要件定義とは、システムやソフトウェアの開発において、実装すべき機能や満たすべ
き性能などのを明確にしていく作業のこと」
(http://e-words.jp/w/%E8%A6%81%E4%BB%B6%E5%AE%9A%E7%BE%A9.html)

の定義に従えば、

・僕がこれから作るものは何か?を決める作業

に注力すればいいようだ。

今回の場合は、すでにお客さんは欲しい物の画面イメージを僕に渡している。
画面レイアウトがあり、このボタンを押したら何が起こって、データがどう流れるかを決める、それを決めるのか。
おや、こう書くとなんだか設計をしている気分になる。設計と要件定義は違うはずだが・・?

あまり経験がないと要件定義で設計をしてしまうようだ。

要件とは、
何を作るかを決めること
であり、

設計は、
どのように作るかを決めること
である。

何を作るか?この画面。この画面、「なぜ」必要なのか?本当に役立つのか?

そう、僕は開発中でもなぜこの機能が必要か聞き、その背景を共有することで、無駄な機能を作らないようにし、要求に対するもっと適した仕様を提案してきた。それは自分が作っているシステムが役に立ってほしいし、お客さんにとってあらゆる意味で価値を生み出すものであって欲しいと願っている。

ならば、何を作るか決める要件定義においては、システムが必要とされている背景、理由を詳しく丁寧にヒアリングして、これらを共有することがまずは必要なことではないか。必要であろう機能を検討し採用するかどうかを話し合うことが必要なはずだ。

もう少し砕くと、

・顧客は何をしたいのか?何に困っているのかを考える
・業務をどういう形でシステムに置き換えるのか、利用するのかを考える
・システムに置き換えなくてはいけない範囲はどこかを考える

ことだ。(もちろんこれ以外に非機能要件など決めることはあるが)

今までもこのような意識合わせは開発中の随所で行ってきたが、あまりにも無意識でやっていたため、改めてフェーズの頭にまとめて行なう際に何をすればいいか分からなくなっていたようだ。言語化できたおかげで目の前がクリアになった。後は邁進するだけである。

Like what you read? Give Shinichi Sasaki a round of applause.

From a quick cheer to a standing ovation, clap to show how much you enjoyed this story.