新しいプロジェクトが立ち上がると、まずは入念な要件定義から始めます。仕様を決め、工数を見積もり、予算と納期を調整し、開発を進めていくことになりますが、この時、クライアントからは様々な要望を言われることでしょう。
要望を全て呑めばどんどん受注はしやすくなりますが、それは後々とんでもないトラブルを引き起こす元になりかねません。被害を避けるために、どんなリスクがあるのか、あらかじめ理解しておきましょう。

デスマーチを誘発する

どんなクライアントからもほぼ必ず要求されるのが、納期と予算の調整です。「出来るだけ早く」「なおかつ安く」製品が欲しいというのは当然ですので、こればかりは仕方のないことでしょう。
ライバル会社との受注競争を考えると、ひたすら頷いてしまいそうになりますが、それは開発チームに過剰な負担をかけることになってしまいます。無茶な納期で受注してしまうことで、長時間の残業が発生し、結果として赤字になってしまっては、元も子もありませんよね。
この時気を付けなければならないのは、「例え余裕があってもサービスし過ぎてはならない」ということです。あまりにもクライアントに好条件で受注してしまうと、次の案件以降も、同条件での契約を求められることになってしまいます。
赤字の上に納期がキツい、ブラック案件の見本のような状況を招かないためにも、安請け合いには気をつけましょう。

不要な要件まで見積もりしてしまう

特に要件定義や見積もり時点で多いのが、「とりあえず今ある業務全てをシステム化して欲しい」といった、具体性のない要望です。一見当たり前のことを言っているように思えますが、意外と複雑な業務を簡単な一つの作業に纏められることも少なくありません。
こうした業務の分析と効率化は、クライアントの評価も高くなる上、開発の負担も少なくなる一石二鳥の手段ですので、地道に取り組んでみましょう。

違法性のあるシステムになっている可能性がある

クライアントが提案した仕様や要望は、全てが正しいとは限りません。例えば勤怠システムでは、残業時間や有休など、非常に複雑な計算が必要になるケースが少なくないのです。
中には意図的ではなく、法令を知らずに違反してしまうような計算を提案されることもありますので、そうした場合は毅然と間違いを正さなくてはなりません。

システムの将来性が無くなる

パッケージの販売では、企業ごとに独自のカスタマイズを加えることが一般的ですよね。大抵の機能は他の企業では使えないものですが、中には汎用的に使える機能もないわけではありません。
そうした機能はパッケージに逆輸入することもあり、製品の強みをより一層引き立てることが出来ますが、あまりに激しいカスタマイズをしてしまうと、全く別物のシステムになってしまいます。仮に元のパッケージに新機能が追加されても、それを適用できなくなってしまっては、魅力も半減です。
カスタマイズ要件は、システムの将来性を考慮しつつ受注するよう意識してみてください。

クライアントと良い関係を作るには

ここまで挙げたように、全ての要望を唯々諾々と呑んでしまうと、クライアント側にとっても、受注する側にとっても、良い結果はもたらしません。要望をうまく調整し、取捨選択を経て、効率化することこそ、SEの腕の見せ所ですので意識して要件定義に臨んでみてください。