静岡の受託開発で追加費用と納期遅延を抑える

「最初の見積から金額が増えた」「完成予定日が何度も後ろへずれた」。静岡の中小企業や店舗から受託開発の相談を受けると、こうした経験を聞くことがあります。

私は初回の打ち合わせで、欲しい機能より先に、いま誰がどの順番で仕事をしているかを確認します。追加費用の火種は、技術の難しさよりも、発注側と開発側の「当然」のずれに隠れていることが多いからです。

見積書より先に、仕事の流れを一枚にする

「顧客管理を作りたい」だけでは、正確な見積は出せません。受付担当が入力し、責任者が承認し、月末に経理が集計するのか。電話で受けた変更を誰が直すのか。ここまで分かって、ようやく必要な画面、権限、保存する情報が見えてきます。

静岡市内の店舗を例にすれば、店頭のパソコンだけで使うのか、外出中の責任者も確認するのかで設計は変わります。焼津や藤枝の事業所と同じ情報を扱うなら、拠点ごとの閲覧範囲も先に決めたいところです。

現行業務の図は、きれいな資料でなくても構いません。手書き一枚でも、担当者と情報の動きが読めれば、見積の前提として十分に働きます。

要件定義は、希望を全部詰め込む作業ではありません。今回の予算と納期で実現する範囲を決める作業です。私たちは「顧客検索を作る」と書くだけでなく、何で検索できるか、誰が閲覧できるか、結果を何件ずつ表示するかまで言葉にします。

同時に、対象外も記録します。たとえば「初回はCSV出力まで。会計ソフトとの自動連携は次期」「過去十年分ではなく直近二年分を移行」といった線引きです。対象外が残っていない見積は、あとから期待の差が出やすくなります。

「顧客画面がある」では検収できません。「担当者が氏名と電話番号で検索し、該当顧客の履歴を閲覧できる」のように、操作と結果を一組にします。入力できる文字、必須項目、権限不足のときの表示も決めておくと、不具合か追加要望かで揉めにくくなります。

開発中の変更は珍しくありません。画面を見て初めて気づくこともあります。問題は変更そのものではなく、打ち合わせや電話で頼んだ内容が、費用と納期への影響を確認しないまま積み上がることです。

変更票には、依頼日、依頼者、理由、変更内容、費用への影響、納期への影響、採用するかどうかを残します。一般的には、影響調査に一〜三営業日ほど置くと判断しやすくなりますが、規模や接続先によって変わるため、あくまで目安です。

当初合意した動きになっていないなら不具合、合意後に新しい動きを足すなら仕様変更。この区別も変更票に残します。小さな文言修正まで大げさに扱う必要はありませんが、「誰が決めたか」だけは消さない。現場ではここが効きます。

完成品を初めて触るのが納品日では遅すぎます。画面の試作品、主要な登録の流れ、例外処理、データ移行後の件数という順で確認すると、手戻りを小さくできます。店舗なら実際に操作する人、製造や建設の現場なら事務所と現場の両方に触ってもらうのが現実的です。

検収期間は、小規模な仕組みなら五〜十営業日程度が一つの目安です。繁忙期や月末締めに重なる場合は、触る時間が取れず判定が遅れます。契約前に社内の確認日まで予定へ入れておくと、開発側だけを急がせる状態を避けられます。

静岡では、店舗、製造、食品、建設など、事務所だけでは業務が完結しない会社が少なくありません。現場確認を平日の空いた時間だけで済ませると、棚卸し、締め処理、予約の集中、担当者不在といった本番の負荷を見落とします。

私なら、要件確認の日とは別に、実際の処理が集中する時間を短く見せてもらいます。複数拠点がある場合は、移動と担当者の予定も工程表へ。試験用データの準備、端末の手配、社内説明の時間は開発作業ではありませんが、開始日を左右する立派な工程です。

小規模案件でも、現状確認、要件の確定、試作品の確認、本開発、操作試験、検収という節目を置きます。期間は内容次第で変わるため、最初から日付を断定するより、各節目で何が決まれば次へ進めるかを明記した工程表のほうが役に立ちます。

相談時に完成した仕様書は不要です。いま使っている帳票や表計算ファイル、困っている作業、希望時期が分かれば、既存の仕組みで足りる部分と、個別開発が必要な部分を一緒に切り分けられます。

NIR株式会社では、導入前の整理から運用後の改善まで、静岡の現場に合わせて進めています。受託開発を前提にせず、まず費用が増えやすい境目を確認したい方は、システム導入・開発を無料で相談するから状況をお聞かせください。曖昧な部分を曖昧なまま契約へ押し込まず、一つずつ言葉にするところから始めます。