ディレクションを科学する と 私の日記

自己紹介とディレクションを科学していきます。

要件定義や設計書の初期でのサービスについて。前編

よく初期の段階でシステム開発側がこんな機能があったら便利とか、ここはこういうケースもあると思うので、このような機能を付加しましょうとか 打ち合わせで行っているケースってないでしょうか。

 

どこのシステム会社もそうだと思うのですが、見積時は多少のバッファはのせていると思います。注文時も基本的にはこの多少のバッファが入ったもので受注するはずです。

 

なので、要件定義や設計初期は多少のバッファがある状態からスタートします。

ここで顧客へのサービスだと思うのですが、打ち合わせ中に工数がかかるであろう機能の提案を開発側から行ったりします。 それで顧客が大喜びするのであれば、ぜひというところですが、顧客が「可能であれば」程度のことってよくあると思います。

その可能であれば程度の機能を盛り込むことで工数があがり、バッファをここで使ってしまうことになります。

 

さて、システム開発は短いものでも一か月長いものであれば半年とか1年とかざらにあります。ウオーターフォールで開発しているのであれば、要件定義や設計からかなり時間がたった後でテストプログラムが開発されます。この時に顧客は実際にさわってみて確認や評価を行います。 

この時に必ずでてくるのが、想定外の要望です。しかもシステムのロジックを少しは変えないといけないものだったり。。

なぜこれが出てくるかというと

・顧客が触ってから初めてイメージがついた

・要件定義や設計の時に考慮が漏れていた。

・期間がたったので顧客のビジネスロジックが変わった。

 事情が変わった。

 

また、同時にこのころ顧客から連絡があるのが不具合の指摘。

これはできていませんねとかこれは違うと思いますとか。。

 

この開発側が困った状態の時に要望がでてきます。

普通であれば、追加と判断できるものもなかなか追加とは言えず

工数やスケジュールはそのままで受けないと仕方がないケースは多いと思います。

私はこの時に初めて見積時にとっておいたバッファを使うべきだと思います。

 

後編では、後からなぜ要望がでてくるのかを記載してそこの要望がでてくるのが

わがままでも何でもなく確実にあることなのだということを記載します。