一括請負契約はソフトウェア開発にやっぱり向いていない

一括請負契約はソフトウェア開発にやっぱり向いていない、と改めて感じた。
理由は2つある。

【参考】
ERPの落とし穴part4～システム移行という名のデスマーチ: プログラマの思索

システムのリプレース案件が最も危険な理由: プログラマの思索

請負契約がソフトウェア開発者を苦しめている: プログラマの思索

【1】1つは、発注者は外部ベンダーにリスク転嫁しているつもりでも、リスク転嫁できていない。
結局、発注者に全てリスクで跳ね返ってくる。

発注者は、要件定義でガチガチに仕様を固めて、その仕様通りにリリースできたとしても、もし本番障害があれば、瑕疵担保責任でベンダーに追求できる。
民法の請負契約では、受託側は成果物の完成責任があるからだ。
しかし、その契約スタイルはソフトウェア開発になじまない。

たとえば、発注者が要件定義や外部設計をまとめて、ベンダーに開発工程を一括請負で委託したら、それが最後、発注側は外部ベンダーに作業指示を出すことはできない。
請負契約では、そもそも発注側が請負側に直接指示を出したり、管理したりすることを禁止しているからだ。
つまり、発注者がベンダーの作業の進捗管理を行うことは、契約上できない。

すると、発注者はベンダーに完全にお任せ状態になってしまい、ベンダーの進捗報告すらなければ、最後に、ベンダーから、納期が遅れてしまいます、と言われて慌ててしまう、みたいなケースが頻発しやすい。
納期が遅れたからと言って、成果物責任をベンダーに求めても、未完成で動かないシステムを納品されても困るわけで、発注者もベンダーもお互いに揉めるだけ。
せいぜい、紳士協定で、ベンダーさんに、進捗報告は定期的にしてね、と言うのが関の山。

つまり、一括請負契約で、ベンダー側にリスク転嫁しているつもりでも、発注者に全てリスクで跳ね返ってくる。

【2】もう一つは、品質を高めるインセンティブが働かないこと。

昔の製造業では、発注者側の大企業と下請けの中小企業で一括請負契約があったとしても、大企業側から優秀な技術者や管理者を下請け企業に派遣して、下請け企業の部品製造の品質管理や進捗管理を行う事例はよくあったらしい。
たぶん、大企業側は、自社製品のサプラチェーンを維持すること、サプライチェーン上の品質管理や進捗管理は自社で守るべき、という意識が強かったのだろう。
一方、下請け企業も、大企業の技術者から技術力や品質管理力を継承したり、大企業の管理者に進捗管理を委ねることで、自分たちは製造に専念できる、というメリットもあったのだろう。
つまり、製造業では、元請けと下請けという多重請負構造があったとしても、品質を高めるインセンティブが双方にあった、と思われる。

しかし、ソフトウェア開発では、発注者は外部ベンダーにベンダーロックインされて、ベンダーの言いなりになってしまう。

たとえば、ベンダーに委託して作らせたソフトウェアを、発注者自身で保守することは事実上難しい。
そもそも、発注者側では、情報システム部門に管理能力がない、とか、そもそもソフトウェア開発能力がない場合が多い。
発注者側に開発チームがいれば、まだ可能かもしれないが、他の会社が書いたソースを自分たちで保守するのは、非常に面倒なことは誰でも分かる。
結局、システムを作らせたベンダーにそのまま運用保守をお願いするしかないし、費用を値切らせたとしても、本番障害が出たとしたら、結局、費用を支払うしかない。

すると、そのシステムがビジネス上重要な役割を保つ場合であれば、ベンダーに依存してしまうしかない。
そして、ズルズルと保守を依頼するうちに、システムの減価償却が終わっても、リプレースするまでに、保守コストは膨れ上がってしまって、誰もその金額に手を出せなくなる。
ベンダー自身もそのシステムがブラックボックス化してしまっていることもよく知っている。
リプレースする時は、最初の初期投資額よりも倍の費用がかかってしまうこともザラではない。
また、リプレースという案件は、たいていソフトウェア開発案件として失敗しやすいことは昔から言われている。

ベンダー側としては、システムを納品してしまえば、そのシステムは発注者にとってブラックボックスであり、触らぬ神に祟りなしみたいな状態になるから、発注者がたとえ高飛車な態度を取っていても、困ることは知っている。
だから、ベンダーもそこそこの品質で納品してしまえばいい、みたいな結果に落ち着く。

発注者側も、複数のベンダーに相見積もりさせたり、コンペさせたりして、ベンダーロックインのリスクを回避しようとするが、他人が書いたソースを自分たちが保守したくはないし、リプレース案件が火を噴くことは誰でも知っているから、よほどのことがない限り、自分たちから火中の栗を拾うようなことはしない。
結局、ベンダーロックインになれば、発注者はリスク転嫁できていないことになる。

【3】こんな事を考えていたのは、ベンダーに一括請負で委託した案件では、経営陣からプロジェクトの進捗報告を求められた時、定量的なデータで報告する手段が結局無いからだ。
普通は、EVMを使って工数ベースで管理したり、発生原価を進行基準で計上するなどしてコスト管理するのだろうが、一括請負の作業が含まれると途端に、事実上は運用が難しくなる。

なぜなら、請負契約上、ベンダーに作業の計画工数や実績工数の報告を求めることはナンセンスだし、ベンダーに直接指示を出すような、ベンダー作業の進捗管理を行うことは禁止されている。
プロジェクトの原価計算を進行基準で運用したとしても、ベンダーから定期的に報告される進捗率をそのまま受け入れるしか無い。
その進捗率は普通はかさ上げされている場合が多いので、受け入れ検収したら、納品物の品質がすごく悪くて、そもそも使えない、だから、検収費用はすぐに支払えません、みたいなこともよくありがち。

本来は、ベンダーの現場に直接出向いて、現場にいる開発者の能力やモラールなどを感じ取ったり、ベンダーのプロジェクトリーダーから報告された進捗内容が本当に正しいのか、見極めたい。
しかし、請負契約だから結局できない。

【4】そんなことを考えると、一括請負契約は製造業のビジネスモデルに向いた契約スタイルであって、ソフトウェア開発には向いていないな、と改めて思う。

結局、ソフトウェア開発はたとえユーザ企業であっても、自社で内製開発するか、自分たちでソフトウェア開発案件をマネジメントできる能力を持っているか、というレベルが求められるのだろう。

アジャイル開発、そしてスクラムが注目されているのは、そういう古いソフトウェア開発のビジネスモデルではなく、内製開発を中心としたSaaSのようなビジネスモデルにとても向いているからだろう。

自分は、受託側で一括請負契約の案件で苦い経験がよくあったが、発注側でも一括請負契約の案件は、正直ベンダーコントロールすらできていない現場がほとんどなんだな、と改めて感じた。