クライアントワークで安売りしないための「調査見積もり」の線引きと交渉術

クライアントや社内から、こんな依頼をされたことはありませんか？

「修正はしなくていいから、不具合の原因調査だけ作業の合間にやっておいて！」

「修正作業がないなら楽かも」「合間にサクッとやればいいか」と引き受けてみたものの、蓋を開けてみれば「別の開発者が書いたコードで仕様がカオス」「ログを追いかけたら丸1日溶けた」……なんて経験、一度はあるはずです。

結論から言います。「原因調査」は、プログラミングにおいて最も時間がかかる核心部分です。 修正しないからといって安易にタダや格安で受けると、自分の時間とメンタルを削る「安売り」につながってしまいます。

今回は、このような沼にハマらないための適切な見積もりの線引きと、クライアントへの納得感のある伝え方を解説します。

「調査だけならタダ（あるいは格安）」という勘違いが起きる理由は、開発者側とクライアント側で作業量の認識にズレがあるからです。

【開発者の感覚】
  原因特定（8割の労力）  ＋  コード修正（2割の労力）  ＝  全体の作業

【クライアントの感覚】
  原因特定（タダ・ついで） ＋  コード修正（有料の作業）  ＝  全体の作業

安売りしないために、まず以下の3つのロジックを頭に叩き込みましょう。

プログラムの不具合は、「どこが壊れているか」を見つけるまでが仕事のほとんどです。原因さえわかれば、修正自体は数行書き換えるだけで数分で終わることもザラにあります。つまり「調査＝作業の8割」なのです。

他人が書いたコードやドキュメントがないシステムを解読するのは、見知らぬ外国の街で地図を持たずに迷子を探すようなものです。1行書き換える前に、全体構造を把握するための「解読時間」が数時間〜1日単位で発生します。

人は作業を中断されて別のタスク（調査）に移り、再び元の作業に戻るまでに膨大な集中力を消費します。1日かかる調査が入れば、本来進めるはずだったメインの開発はストップします。これは「合間の作業」ではなく、メインタスクの圧迫です。

不具合調査を安売りしないための最もシンプルな解決策は、1次調査と2次調査のフェーズを明確に分け、上限時間（キャップ）を設定することです。

フェーズ	作業内容	目安時間	費用扱い
1次調査（初期確認）	現象の再現確認、ログ確認、調査見積もりの作成	最大1〜2時間	月額保守枠（または無料範囲）
2次調査（本格解析）	他人コードの解読、データ追跡、原因の特定	2時間〜1日以上	【有料】個別見積もり（スポット案件）

「1次調査を行いましたが、別担当者のロジック解読が必要なため、原因特定までにさらに約●時間の本調査が必要です。本調査（費用：〇〇円）を進めてもよろしいでしょうか？」

こうすることで、「気づいたら1日無料で作業させられていた」という状況を100%防ぐことができます。

「予算がないからなんとか保守内で……」と言われた場合は、「納期（SLA）を極端に伸ばす」という条件変更で対応するのがプロのやり方です。

引き受ける条件： メイン業務を優先し、1日15分〜30分程度しか調査に充てない。
回答の伝え方： 「合間での対応となるため、調査完了まで【約2日】お時間をいただきます。急ぎの場合は別案件としてスポット枠（即時対応）でお見積もりいたしますが、どちらにしましょうか？」

こう提示すると、クライアント側は「時間を優先して有償で頼む」か「急ぎではないので待つ（無理な割り込みを諦める）」の二択を選ばざるを得なくなります。

「調査だけだから」という言葉に惑わされず、正当な対価を受け取るための仕組みを作っていきましょう！