2017年12月16日 / 最終更新日 : 2017年12月17日高科システム開発

要件定義を簡単にするたった一つのシンプルな方法

ソフトウェア開発で一番難しいと言われている工程が、要件定義です。
なぜ難しいのか？を説明した上で、発注する側としてどうしたらいいのか？
要件定義する側としてどうすればいいのか？を今までの経験から考えてみます。

なぜ要件定義は難しいのか？

ソフトウェア開発では１つとして同じプロジェクトが存在しません。
少しでも条件が変わると、全く別物を作らなくてはいけなくなることも多々あります。
つまり過去の経験が活かしにくいのです。
これが他のものづくり関連の仕事と、ソフトウェアとの大きな違いです。
全てのプロジェクトがある種、研究開発のような性質を抱えているのです。

腕のいいエンジニアはどうしてるか？

腕がいいと言われるエンジニアは、過去の経験は活かしにくいけれども、
ある程度リスクの見積もりができる人です。
新人よりも経験のある作業が多いので、どのくらい時間がかかるのかわかるのです。
そして不確実な部分が確実にある、という前提でスケジュールを組むので、
そこまでスケジュールにズレがないのです。
あったとしても、だいたいこのくらいで挽回できるという見積もりを最初から組んでおくのです。
また、作業自体が速いので、遅れたとしても挽回が速いという理由もあります。

発注する側としてはどうしたらいいのか？

ソフトウェアを発注するのはとても難しい作業です。
特にシステム開発の知識がないとなれば、
「なんとなくこんな感じ」という発注になってしまうのも仕方ないことかもしれません。
しかし、これだとエンジニアからすると不確実な部分（あなたが何を望んでいるのかがわからない部分）
が大きすぎるため、かなりリスクが高いと思われてしまいます。
その結果、見積もり金額は高くなってしまいますね。

ではどうすればいいのでしょうか？
まずは、とにかく機能をシンプルにしましょう。
○○だけ！とか、しかできない！くらいの思い切った絞り込みをして、まずは最小のプロダクトを作ってみる。
そして必要に応じて機能を追加していくほうがうまくいきます。
最初からあれもこれも。。。そしてこれもやりたい！という発注をすると、
どの機能も中途半端なソフトウェアが出来上がります。

色々とつけたくなる気持ちはわかります。
みなさんが普段目にする、世の中に出ているソフトウェアはとても高機能ですからね。
でもそれらは何年もの時間、何百人ものエンジニアが１つ１つ機能を改善して来た結果なのです。
いきなりそれを全て真似て作る！となると、かなりの初期投資が必要になりますし、
お金をかけれたとしてもスケジュールが遅れるリスクが跳ね上がります。