今日は要件定義の前段階について考えてみたいと思います。
大切なのはこのシステムで何をしたいか？
それよりも大事なことがあります。
それは、誰を儲けさせるのか？ということです
いくらで？
いつまでに？
その間のコスト負担はどうするのか？
ドラッカーが言っている、お客様はだれか？と言うことです。
そんなことは、要件定義書には、書いていません。
そこを決めたあとの話だからです。
一番いいのは、リーンキャンパスを発注先と一緒に書くのもいいでしょう。
それを、発注者と、確認して、互いの共通認識として持っておくことは大切です。
”当たり前の話だ”と思うかもしれません
でもお客様に認識がずれてしまうことがよくあります。
弊社で、あるシステムの Web 開発をしていた時に、私は依頼主が儲かるように考えて、WEBアプリを企画、製造して行きました。
それで実際サンプルアプリを作って、私の元請け大きな仕事取ることができ、そこは大きな利益が見込めるものとなりました。
良かったなーと思っていました。
しかし金額が高いと言われました。
元請業者は、他の下請けも使っているんですがそこよりも高いと言われました
他との値段の比較をされてしまいました。
他の下請けは作業者であり、要件定義書がある状態で、その仕様書をみて、ひたすら作業するだけです。ですから作業工数で請求します。
でも弊社では依頼されたお客様の利益を最大限にすることを目標にして います。
ですからサンプルを作る段階から、どうやったら、発注先が儲かるか？を念頭において、企画から入ります。
ライバルを調査したり、海外でのアプリとの比較、日本での市場調査等、いろんな事柄を検証し比較し、いわば商品の企画から進めていきます。
ですから、どうしても、ただの作業者とは違い、時間がかかります。
しかも未知数の技術も選定してやっている。
将来スケールアウトしても大丈夫なように、PHPは捨てています。
しかし、発注者は、それをはるかに上回る利益を、得ているわけです。
ただまだお金になっていない。
受託はしたけど、契約は来年かもしれない、、、
今回の問題は、売上が立つまでの費用をどのように補うのか？
とうい点を話し合っていませんでした。
だから、ほかの業者と金額を比較されてしまう。
こういう箇所をツメておくことも要件定義では大切だと感じました。
リーンキャンバス、今度から発注元と協議して書いておこうと思いました。
リーンキャンパスのサンプルはこちらから。ご自由にお使いください。
