システム開発の現場レポート②：受注までのあれこれ Part2

システム開発の現場って分かり難いですよね。
システムを作って提供と言う漠然とは判るでしょうが
内容は意外にもブラックボックスで開発費用も曖昧で、髙いのか安いのか？
中小企業様のシステムをモデルに開発現場を裏側からレポートして見ます。

自社の合理化に向けた前向きな、新規案件のシステム開発要望です。

この様な案件は、システム屋冥利に尽きるやりがいや自分たちも学ばせて頂ける案件です。

この様な依頼をして来る経営者は前向きでシステムを経営投資的な案件と捉えている方が多いです。

比較的、問題の本質も理解して頂いておりゴールも明確です。

我々はその内容に基づき、ゴールへのシステムアシストをするだけです。

進め方ですが

経営者や担当者とヒアリングを行ない

・現状の問題点や目指すゴールを共有します。
・現状のお仕事の流れを明確にします。（インプット、アウトプット）

これらの内容を基に、仕様案と工数（費用、スケジュール）を作成。

実際ここまでが、受注までの動きになりますが。

この進み方も二通り有ります。

①先に仕様作成のヒアリング＆コンサル費用を頂き、その後正式受注。
②第一回目のヒアリングで概算見積りを提示して、受注時に見積りの40％請求して開始。

この選択はお客様の判断になりますが、ここは本当に難しい所です。
発注側と受注側のどちらがリスクを取るかになりますが。

①は受注側は破談になっても工数費は請求できるので安心ですが。
②は発注側にとっては、概算見積り依頼内容とのギャップが心配です。
受注側も概算見積り以上の要件が有った場合の追加請求が難しいです。

しかし、お客様は②を選ぶケースが多いです。
（コンサル費と言う目に見え難い物への投資が不安な様です）

②の事例が多いですが、ここの概算見積りは経験に頼る以外有りません。
過去には見積り以上の工数が掛かり泣いたケースも多々あります。

DBテーブル数、画面数、出力数、処理の難しさ、新技術の活用・・
これらを勘案して概算見積りを提出します。

ここはビジネスライクになりますが、範囲は明確にさせて頂きます。
この範囲を曖昧にして、開発範囲を明文化させて頂きます。

これが後々に活きて来ます。

この明文化を曖昧にすると、出来上り時に「言った言わない」が有り
システム満足よりも、ユーザー不満足となり両社の関係が悪化します。
＊これも過去に経験済み

なので、この明文化（ドキュメント化）はシステム屋の命綱、生命線です。

この明文化した資料がお客様への受注段階の成果物になります。

ここからがいよいよ活動開始になります。