ソフトウェア開発において要件定義は重要です。
要件定義如何でプロジェクトの生き死にが分かれると言っても過言ではありません。
ただ、「ようけん」という音の響きが今一つなようで、
どうにも中小企業のエンジニアやコンサルタントの方々はナメている節があります。
すこしその辺りについてお話しさせてください。
要件定義の目的
ソフトウェア開発プロジェクトの目的は「ソフトウェアを完成させること」です。
当然ですが、このソフトの完成って何？を定義する必要があります。
つまりは「達成すべき目標」です。
”製造における紙の使用率を50%低減”
”不良率・不具合率の20%低減”
“部品欠品率の30%低減”
“在庫保有率の20%削減”
“段取時間の20%削減”
おそらくこういったものになるかと思います。
KPIやKGIと呼ばれるものですね。
しかし、ソフトウェアの開発者側からしたら、そんなことどうでも良いです。
ちゃんとソフトウェアを使わずに、目標未達だと言われたらたまったものではありません。
そこで我々開発者側が定義するのは「機能一覧」ということになります。
「我々はこういう機能を持った仕組みを作ろうと思います。
あなたの掲げる目標に合致してますか？とりあえず僕らはこれを実現することをゴールとしますよ。」
とお伺いを立てる内容ですね。
要件定義書の最初には達成すべき目標が申し訳程度に書かれ、その後機能がずらっと並びます。
機能の結びつきが分かり辛ければ画面イメージと画面遷移もつけます。
要件定義の目的は、機能一覧の洗い出し合意を得ることなのです。
これができれば設計にバトンを渡すことができます。
要件定義の問題
響きの問題
「ようけん」というと普通「用件」を想像します。
「ご用件は何でしょうか？」の「用件」です。
「最近の技術者に要件定義ができる力を持った者が少ない」と嘆く経営者もいますが、
そもそも最近の技術者は「用件定義」だと思っている人が少なくありません。
「何かお困りですか？」と聞いています。
プログラマーであればそれでも良いかもしれません。
お客様が練られた機能一覧を出してくれることも多いので、
特に要件定義を必要としないのでしょう。
しかし、超上流工程も担当するエンジニアやコンサルタントがその程度では困ります。
・製造における紙の使用を減らしたい
・不良率・不具合率が高くて困っている
・部品欠品率が高い気がする
・在庫保有率に問題がある
・段取時間を何とかしたい
要件？要望？要求？みたいなリストを作ってもゴミです。
優先度もわからなければ、達成すべき目標がわかりません。
もう過ぎたことですが、
この謎なリストに優先順位をつけて機能一覧に起こす事も僕の仕事でした。
更に開発も行って導入するところまでやって、
売上金額の半分以上がコンサルタントの取り分。
しかも説教好きのじじい共。愚図愚図と説教・・・と、この辺でやめておきましょう。
ただの負け惜しみです。
忘れてください。
ちっ、早く身罷（みまか）られれば良いのに。
要件定義の位置づけの問題
要件定義には機能面や画面の話が絡んできます。
捉え方によっては設計とみることもできます。
この「設計」っぽい感じがちょっと困るんですよね。
お客様にも「設計」はノータッチを貫く人がいます。
「画面とか機能とかは、開発者側に任せるよ」
またプログラマーも要件定義で画面イメージや機能一覧を出したがらなかったりします。
「設計フェーズでやるから今はやらないよ」
この解決策は人それぞれだと思いますが、
僕が考える要件定義は「機能一覧」を作成し合意をとることです。
これがきっちりできれば、プロジェクトに於いて相当数の事故が未然に防げます。
それができなければ怪我は免れません。
総括
繰り返しになりますが要件定義は重要な分野です。
プロジェクトの死活に関わります。
大変なお仕事ですが頑張ってみてください。
本音は「お客様が決めてくれないから開発できませーん」
が一番楽ですけどね。
おわり
コメントを残す