お客様の追加要望や仕様変更を抑えるために守るべき開発のルール

お客様からシステム開発の依頼を受けて、見積書を提出して受注したものの、当初よりも仕様変更や機能追加が増えてしまい、結局赤字プロジェクトになってしまった・・こんなことは実際によく聞く話ではありますが、これでは何のために開発を請負ったのかが分からなくなってしまいます。

お客様から開発案件を請負うからには利益を出すことが求められますが、それを邪魔するのが仕様変更や機能追加などのお客様要望です。今回はそうしたお客様要望を極力抑えるために守るべき開発のルールをご紹介していきたいと思います。

各フェーズごとに仕様凍結しながら開発を進める

過度なお客様の追加要望を抑えるのに一番効果的なのがこれ。「各フェーズごとに仕様凍結をしながら工程を進めること」です。究極を言えば、このルールさえしっかり守っておけば、そんなにひどい赤字をたたき出すことはないでしょう。

要件定義のフェーズでは、お客様がシステム化することで効率化させたいことの要件をまとめていきます。例えば「請求書をシステムから発行できること」や「仕入れデータの一括取り込みができること」など。

そしてお客様と打ち合わせを重ねて要件定義書を作成したら、お客様説明を行い、必ずお客様承認をいただいてください。お客様承認をいただくことで仕様凍結として、SE側の不手際以外の、お客様起因による要件追加は行わないようにしましょう。

これは基本設計フェーズ、詳細設計フェーズについても同様です。要件から仕様を固めたら、設計書を作成し、お客様説明した後に承認をいただき、仕様凍結をすることを忘れてはいけません。

こうしたことは赤字を抑えるだけでなく、システム開発を円滑に進める上でも非常にな大事なことなので、絶対に厳守するようにしてください。

お客様にも機能追加は原則不可であることの共通認識を

システムは形のない商品であり、最悪は後からでも修正ができてしまいますので、当初は想定していなかった機能についても、お客様は後になってから要望を出してしまいがちです。

ですが機能追加を断り、お客様から「システムを発注しているのに、何でやってくれないの？」と言われてトラブルになってはいけませんので、仕様凍結後の機能追加はできない旨は、お客様との共通認識にしておく必要があります。そのため開発案件を受注する段階で、開発の進め方については、お客様にしっかりと説明しておくことも忘れてはいけません。

最終的にどんなシステムが出来上がるかは、SEの能力もありますが、お客様の力添えも必要になります。もし仕様を詰めきることができなければ、それはお客様にも一定の責任はあるのです。お客様を巻き込んでのシステム開発をしていくことを心がけましょう。

追加要望は必ず見積もりから対応

これも当ブログ内では何度も言っていることですが、仕様凍結後にどうしても機能追加や仕様変更をしたいのであれば、簡単に安請け合いすることなく、別途見積書の提出から始めましょう。

お客様もどうしても欲しい機能であれば追加費用を払ってでもお願いしますし、追加費用を払ってまで欲しくない機能であれば、今回の開発ではあきらめることになるでしょう。

運用でカバーする方法を提案

追加費用を払うほどではない小さい要望だったとしても、ただあきらめてもらうのではなく、既存の機能を駆使して何かしらの運用でカバーできる方法があれば、その旨もお伝えしてあげましょう。

そうした気遣いができることも、SEにとっては大事なことです。

時には気丈な態度で臨むことも大事

ビジネスという立場上、支払いをするのはお客様ですから、お客様の要望を聞き入れることは大事なことです。しかし開発のルールを無視してまで、無尽蔵に要望を聞き入れる必要はありません。

しっかりと開発の進め方について事前に説明していれば、追加要望を断ったからといって、信頼関係が壊れることはありません。サービスをすることだけがお客様満足度を高めるとは限りません。SEとして信頼関係を作っていくのであれば、しっかりと線引きをしていくことも大事なのです。

機能追加を請負いすぎて工程遅延となりお客様に迷惑をかけるよりも、しっかりと工程を守って事前の約束をしっかりと守ることの方がよっぽど信頼度は高まります。SEとお客様は対等であるというぐらいの気持ちを持って、時には気丈な態度で臨むことも、お客様からの追加要望や仕様変更を極力抑えるためのポイントとなります。

 

おわりに

お客様からの仕様変更や追加機能などの要望を抑えるためには、各工程を終わらせるごとに、お客様確認のもと、仕様凍結しながら開発を進めていくようにします。

システム開発はお客様とSEが力を合わせて行っていく共同作業です。仕様凍結後の変更は原則禁止というルールは、お客様に責任をなすりつけるという意味ではなく、お互いにとってためになる開発のルールとなるはずです。

プロジェクトを円滑に進める上でも重要なことですので、しっかりと守っていくようにしましょう。