日本で開発を発注するとき、最初に決まるのは契約形態だ

海外の会社から、日本での開発について相談を受けることがある。話を聞いていると、詰まっている場所はだいたい同じところだ。

技術ではない。契約形態と体制の話で止まっている。

日本の開発発注には、海外から見ると理解しにくい前提がいくつかある。今回はそれを整理しておく。

■ 契約形態は3つある

日本で開発を外部に出すとき、契約は実質3種類に分かれる。

請負契約。準委任契約。派遣（SES）。

この3つは、何を買っているのかが根本的に違う。

請負は「成果物」を買う契約だ。発注側は完成したシステムを受け取り、検収する。作り方や体制には口を出さない代わりに、完成しなければ受注側の責任になる。

準委任は「作業」を買う契約だ。成果物の完成義務はない。善管注意義務、つまり専門家として誠実に作業する義務があるだけだ。

SESは実態としては人を月単位で借りる形に近い。指揮命令は受注側にあるという建前で運用される。

海外の感覚で言えば、請負が fixed-price、準委任が time and materials に近い。ただ、responsibility の切れ方が違う。

■ 請負を選ぶと、要件を後から変えられない

ここが一番よく揉める。

請負契約は、契約時点で成果物が定義されていることが前提になっている。だから要件が変われば、原則として追加費用と追加期間が発生する。

海外のプロダクト開発の感覚で「作りながら決める」と言うと、請負契約では、その都度が変更契約になる。

要件が固まっていない段階で請負を選ぶのは、ほぼ確実に失敗する。にもかかわらず、発注側は請負を選びたがる。金額が固定されて見えるからだ。

固定されて見えるだけで、実際には固定されていない。

■ 検収基準を決めずに始めると、終われない

請負には検収がある。発注側が成果物を確認し、契約通りかを判断する工程だ。

この検収の基準を契約時に文書化していないと、プロジェクトの終盤で「これは完成しているのか」を巡って止まる。

日本の開発現場で炎上している案件の相当数は、技術的な難易度ではなく、この検収の合意が無いことで止まっている。

決めるべきは、動作条件、対象ブラウザ、性能要件、そして「直す」と「追加開発」の境界だ。最後の一つが特に効く。

■ 1人月100〜150万円が、届く先の話

単価の目安を書いておく。発注側が支払う金額だ。

中堅のエンジニアで、1人月100万円前後。上位層で150万円前後。これが日本の開発発注におけるひとつの基準になる。

ただ、この金額がそのまま手を動かす人に渡ることは、まずない。

日本の開発業界には多重下請け構造がある。元請けが受注し、二次請けに出し、三次請けに出す。各段階でマージンが抜かれる。

つまり上位層の単価として150万円を払っても、実際にコードを書いている人には、その一部しか届いていない可能性がある。中堅の水準にも満たない人が座っていることもある。

これは道義的な話をしたいのではない。発注側にとっての実務的な問題として重要だ。

支払っている金額に対して、どの水準のエンジニアが実際に手を動かしているのかが見えなくなる。

■ 体制図を見せてもらう

だから、契約前に確認すべきことがある。

実際に開発する人は、契約相手の社員か。違うなら、何次請けまであるか。その人たちの経験年数はどれくらいか。

聞いて答えられない、あるいは答えたがらない場合、それ自体が判断材料になる。

もう一つ。打ち合わせに出てくる人と、コードを書く人が同じかどうか。

英語で話せるのが営業担当だけ、という構成はよくある。その場合、技術的な意思決定はすべて翻訳を経由することになる。仕様の細部は、そこで確実に落ちる。

■ 自分ならこう進める

海外から日本で開発を出す場合、私ならこう組む。

まず、要件が固まっていない段階では準委任で始める。最初の1〜2ヶ月で作りながら要件を固め、そこから先を請負にするか判断する。

次に、検収基準を要件定義と同時に書く。後回しにしない。

そして、発注側の側に技術が分かる人間を置く。社内にいないなら、外から入れる。

ここが要点だ。ベンダーを管理するのではなく、ベンダーと同じ言語で話せる人間を発注側に置く。

日本のベンダーは、技術的に妥当な要求には応える。問題は、要求が技術的に妥当な形で伝わらないことのほうにある。