システム開発の固定価格契約は安心か？ 未確定な仕様と検収の確認
見積書の総額が決まると、予算の問題も片付いたように感じる。ところが開発が始まると、「その処理は対象外です」「仕様の変更になります」というやり取りが続く。最初の金額は変わらなくても、業務に必要な範囲がその金額に入っていなければ、安心は長く続かない。
逆に、作業時間に応じて支払えば変更しやすいという説明にも、抜けがある。変更する自由を持った発注側が優先順位を決められなければ、時間と費用だけが積み上がる。契約の選択で問いたいのは、固定か柔軟かという好みより、何が未確定で、誰が次の判断をするのかである。
本記事では、価格を確定する発注と、投入時間を基に支払う発注の使い分けを考える。海外の調達指針を判断材料にするが、日本の請負・準委任などの法的分類と同一視しない。具体的な条項の適否ではなく、発注前に揃える業務上の条件を扱う。
この記事の目次
固定するのは金額だけではない
米国連邦調達規則FARは、確定固定価格の適用を考える条件として、仕様が十分に明確で、当初に合理的な価格を設定できることを挙げている。これは米国政府の調達規則であり、固定価格の方が民間開発の成功率を高めるという実証研究ではない。FAR 16.202
ここから実務向けに引き出せる問いは、「完成したと判断できるか」である。画面数が分かるだけでは足りない。対象となる業務、例外時の動作、接続先から受け取れる情報、発注側が提供する資料まで揃うと、双方が同じ完成像に近づく。
たとえば既存帳票の出力を置き換える仕事でも、通常月の見本しかなければ、訂正・取消し・年度更新が見積もりから漏れる可能性がある。これらを確認できるなら、対象範囲を決めて価格を比較しやすい。確認できない部分まで確定したことにしても、未知の仕事そのものは消えない。
また、固定価格は、どんな追加要望も最初の金額で実現する約束ではない。何を変更とするか、変更時に費用・日程・優先順位をどう見直すかを、最初の合意に含める必要がある。価格表だけを比較して、範囲の違いを後回しにしない。
時間で払うなら、発注側の判断も仕事になる
FARの時間・材料費方式の説明は、作業範囲や期間を正確に見積もりにくい状況を想定する一方、受注者の費用管理を自動的に促す方式ではないとして、適切な監督を求めている。この要件を日本企業へそのまま課すのではなく、柔軟性には管理が伴うという設計上の論点として読む。FAR 16.601
時間の支払いで見たいのは、稼働した事実に加え、その時間で何が分かったか、次に何を作るべきかである。未知の接続仕様を調べて実装案を絞れたなら、画面が増えなくても意味のある成果になり得る。一方、判断者不在で同じ案を作り直しているなら、柔軟な契約より意思決定の遅れが問題だ。
編集上の提案は、着手前に、次に確認する成果、支出を見直す区切り、継続・縮小・終了を決める人を置くことだ。特定の日数や予算比率を万能な基準にはしない。難しい仕事ほど時間払いが正しいのではなく、学んだ内容を次の作業へ反映する能力があるかが分かれ目になる。
発注側にその時間がない場合、時間払いへ変えるだけでは解決しない。対象を狭めて先に調査する、判断者を確保する、未確定な部分の着手を遅らせる、といった準備を先行させたい。受注者へ「良い感じに進めて」と任せることと、変更を協働で選ぶことは違う。
開発方式と支払い方式を、一対一にしない
英国政府のアジャイル契約ガイダンスは、固定価格と時間払いを含む複数の方式を検討している。全体が不明確なまま一括固定する問題を指摘する一方、反復や段階ごとに範囲を定めて固定価格を用いる選択肢もある。アジャイルだから必ず時間払いという整理にはなっていない。英国政府「Contracting For Agile Guidance Note」
したがって、社内の決裁書には「アジャイルを採用」とだけ書くより、今回の発注で確かめる範囲を示す方がよい。利用者の操作を試す段階なのか、既に確認した処理を実装する段階なのかで、合理的な約束は違う。
ただし、契約を小分けにすれば必ず得になるわけでもない。毎回の調達や引継ぎが重くなれば、開発以外の費用が増える。段階を分ける理由は、請求書を細かくするためではなく、次の約束をする前に重要な不確実性を減らすためである。
同じ販売管理の改修でも、選択は変わる
以下は架空の案件である。取引先への出力ファイルを更新するが、項目・例外・受入テストが確認できている。この範囲なら、合意した完成条件と変更手続きを付けて固定額の提案を比べる意味がある。毎週内容を変える自由より、決まった処理を満たすことが重要だからだ。
条件を変え、利用部門ごとに受注手順が異なり、共通化する範囲も決まっていないとする。ここで全体価格を先に競わせると、会社ごとに想定する仕事が違うまま比較することになる。まず手順と例外を確かめる段階を発注し、その結果から実装範囲を選ぶ案へ切り替える。
さらに、業務責任者が不在で、見つかった例外を誰も判断できないならどうか。調査を始めるだけでは未決事項が増える可能性がある。この場合は、判断者と対象業務の優先順位を確保してから進む。時間払いを選ぶ条件自体が欠けているのである。
この例に、固定額と時間払いの優劣を証明する数値はない。選択を逆転させているのは、同じ業務名でも範囲を確定できるか、分かったことを発注側が決定へ変えられるかという違いだ。
販売管理の例で価格を固定するなら、未確定点をどう残すかも合意が必要です。先に調査する、期間と支出上限を区切る、対象を限定して残りを分ける案を比べます。本文の米国・英国の制度は比較材料です。日本で使う条項にそのまま置き換えず、変更・検収・支払・成果物の権利を当事者間で具体化します。
成果払いに変えれば解決するのか
時間で払うことへの不安から、成果に応じて払う案も考えられる。英国のガイダンスにも複数の支払い設計がある。しかし、何を成果とするかが曖昧なら、支払いの名前を変えても争点は残る。機能を納めたことと、その機能が業務で使われたことも同じではない。
たとえば利用率を条件にしても、社内への案内や業務変更を発注側が行わなければ、開発会社だけでは動かせない。相手が管理できない結果を丸ごと責任にするより、双方が実行する仕事と、確認可能な到達点を切り分ける必要がある。これは成果払いを否定する理由ではなく、成立条件を確かめる理由だ。
最初に作った資料や試作品を、後の担当が利用できる形で引き継げるかも確認したい。段階発注で次へ進む判断ができても、知識が担当者の記憶だけに残れば、次の契約で調べ直すことになる。何が分かったかを残す仕事まで含めて、最初の段階の価格と範囲を比較する。
見積もり比較の前に、三つの欄を埋める
比較表には、今回できるようにする業務、まだ分からない条件、その条件が分かった後の決定者を並べたい。未確定欄が空白なら、本当に未知がないのか、単に確認していないのかを区別する。価格の低さは、その後で同じ範囲について比べる。
受注側の見積もりにも、前提と除外事項を明示してもらう。高い見積もりが無駄を含むとは限らず、低い見積もりが効率的とも限らない。想定した例外や支援範囲の違いを揃えてこそ、価格差を判断できる。
範囲と完成条件を説明できる部分は、価格の約束を具体化する。未確定な部分は、まず何を確かめるかを発注し、次の支出を判断する。どちらもできないなら、契約名を変える前に発注側の準備を進める。予算を守る出発点は、総額を早く書くことより、その金額で何を決め、何を完成させるかを揃えることにある。