全3052文字
PR

Q.民需系のシステム開発を手掛けるエンジニアです。体制上はサブリーダーですが、実質的なリーダーとしてこのプロジェクトを任されています。受注提案時の概算費用と、企画フェーズ終了後に再提出した費用に大きな差が生じたことで、顧客を怒らせてしまいました。その差分を説明しても「システム開発のプロだったら、差分となる機能は当然要求されるものだと分かっていたはずだ」とかなり叱られています。妥協点を探る打ち合わせは重い雰囲気でつらいです。システム開発とはそういうものだと割り切るべきかと思うのですが、とても憂鬱です。

 開発費用が膨れることは、よくある話です。結果的に概算費用の2倍に膨れたというような悲鳴を、顧客側から耳にすることがあります。金額の差が大きいほどその調整の難度は高まります。つらいかもしれませんが、何度も打ち合わせして両社が妥協する条件を詰めていくしかありません。

社内でも議論が多いシステム開発の見積もり

 完成品の売買ではこのような問題は起こりません。車やバイクを例に取ると、まず商談で見積書をもらいます。ナビゲーションやETC車載器、ドライブレコーダーといったオプションを付けた見積書も作ってもらうと比較検討しやすいです。オプションが不要な場合はその価格分が減るので、総計は一目瞭然です。見積書よりも実際の購入価格が高くなることは通常ないはずです。以上が見積書に対する一般的なイメージでしょう。

 一方で、システム開発が主体の場合、概算費用の見積もりは難しいです。受注活動中の提案業務は、顧客から費用をもらわないので社内費用の対応になります。要件確認まで多大な時間をかけられない状況の中、顧客からは見積もり精度の高いアウトプットを求められます。

 どうやって見積もりを作成するのかというと、顧客から提示されるRFP(提案依頼書)を基にします。RFPには読み手のエンジニアによって認識が異なるような機能条件があります。他にも、顧客側が常識だと捉えて当然システム化されるものだというものは、書かれていないことが多々あります。中には「なんちゃってRFP」かといったレベルのものもあるようです。これらが見積もりリスクになります。

 顧客の予算を探りながら、営業部門とエンジニアで提案作業を進めているのではないでしょうか。開発会社は各社各様の経験値を基に、見積もりの効率化を図る工夫をしているのだと思います。

 概算費用の見積もりにリスクがあることをエンジニアは分かっています。そのためのリスク金額を積んでおきたいという慎重なエンジニアと、安値で競合他社にコスト優位で受注を獲得したい営業部門の間で喧々囂々(けんけんごうごう)することがあります。

 多くの場合、受注したいという思いから、システム開発範囲や機能を制約する前提条件を付けて提案します。開発要件の追加がある想定で、見積金額が変動する可能性がある旨のただし書きを添えます。詳細の企画や要件定義フェーズ後に、より精度の高い費用を提示するということです。

「見積もり」「費用」ではなく参考価格として提示

 筆者も仕事柄、顧客向けに提案書を作成します。社会保険手続きのアウトソーシング提案における費用見積もりです。エンジニアの受注提案活動と似ています。

 実際のところ、顧客にヒアリングしてみないと分かりません。例えば、1000人規模の企業を想定します。正社員中心の会社とパートやアルバイトが多い会社では、運用工数が全く違います。入社と退社が多いほど、手続き数が増えるからです。高年齢の就業者数が多い場合は、高年齢雇用継続給付金の申請が多くなります。

 企業側で使用する人事情報や給与計算システムのデータ理解も必要です。人事情報や給与計算データを連係するからです。そのデータ連係では、桁数やコード設計の調査が必要です。当方側で使用するシステムのコード定義との差分を洗い出す必要があります。例えば、社員番号や住所の桁数、あるいは支給区分(例、月給者:1/時給者:2)や性別コード(例、男:1/女:2)といったものです。

 コードの違いは必ずあります。社会保険手続きに必要なデータ項目が足りないこともあります。連係するデータを企業側で加工してもらえるのか、受け取ったデータを当方側で加工するのかによって運用工数が変わります。

 概算費用を出してほしいと望む顧客に向けた提案書には「見積もり」「費用」という言葉は使いません。顧客事例を基に、従業員数(正社員数/パート社員数/高年齢社員数)から類型して「事例別・参考価格」として複数パターンで表記しています。IT企業のシステム開発費用に比べると安い月額費用です。

 IT企業におけるシステム開発の総費用は、千万円や億円の単位となる大きな金額でしょう。当初の概算費用との大きな差異は調整の難度が高く、トラブルになりやすいです。

 受注提案段階の開発費用は不透明なので、事例として参考価格で提示するほうがよいと思います。確定するイメージを持つ「開発見積もり」や「費用」という単語は、開発側が参画した企画フェーズや要件定義後に使ってはいかがでしょうか。はじめに顧客から提示されたRFPから想定したシステム実現範囲や要件との ギャップが見えてきているはずです。