September 23, 2004
要件定義という工程の考え方[Web系]
スポンサーリンク
Webの開発は3ヶ月というのが多いパターンですが、営業の段階で、すでに要件定義の期間が甘く考えられているケースが凄く多いような気がします。
システム開発ボリュームとデザイン制作ボリュームと互いの工程の線を引いた残りが要件定義と考えるケースが非常に多いです。3ヶ月のボリュームだと要件定義は2週間というのがパターンですね。2週間だと、週2回打ち合わせして、大体、設計者は画面設計込みで負荷100%Over。4回しか打ち合わせができません。
理想的に進めれば2回の打ち合わせで終わることもあるだろうと考えるし、逆に、永遠に終わらないことも考えられるので、努力と根性で終わらせるべき、極力短く終わりたい工程と思考停止したくなる人が多いところに原因があるような気がしています。
この工程は、顧客と足並みそろうように共にじっくり考え、実はここで80%のクオリティが決まるなどと言った考え方をせず、「顧客都合による手もどりを防ぐために同意を得る工程」と考える方に重きを置くような、制作、開発側のモノ作り意識が大きく影響しているのは否定できないのではないでしょうか?
設計者が、こういう状況をなんとかするならば最低限、要件定義の工程とアウトプットをパッケージ化し、営業が数字を積み上げられる材料としての根拠ある工数を提示してあげないと永遠に要件定義に対する認識は改まらないでしょう。
しかし要件定義こそ、オーバーヘッドが大きくリスクの高い工程に他ならないわけですが…。人間とは可視化されているものにしか頭が回りにくいという典型例なのかなと思います。
・・・と微妙に倦怠期っぽいかも、自分。
「情報大工のひとりごと」の機能と使い勝手の実装は不可分へのレスで書くネタでしたが、愚痴っぽいので、自分とこのエントリにしました。
スポンサーリンク
End Of
「要件定義という工程の考え方」