読者です 読者をやめる 読者になる 読者になる

megamouthの葬列

長い旅路の終わり

0円贖罪という儀式

システム構築の仕事につきものの話で、なんらかの問題があって、システムが納期に納品できない時、または納品したシステムに問題があった、などの事態が起こった時に、この業界で必ずたまに行われることがある。

まず、下請けである我々の営業とPM、時には私のようなエンジニアがすぐに元請けのオフィスに呼び出され、会議室で先方の担当者にネチネチと嫌味を言われながら、平身低頭、進捗遅れやミスを謝罪し、時には報告書なども提出して経緯を説明する。

「ふむ、ならばその罪、許さぬこともない」と元請けが納得した後、決まってごく稀に行われるのが、元請けによる、スケジュール延期の代償としての追加仕様の実装や、修正ついでの機能追加などの提案である。

よく考えてみればわかると思うのだが、スケジュールが遅れたのでリスケして、スケジュールを正常に戻す、というならわかるが、さらにそこに、ロクに制作期間の見積もりもできていない追加仕様をぶっこめば、さらにスケジュールは不確定となって、リスケの意味が全くなくなるし、何らかのバグの修正のついでに機能追加して、突貫作業の結果としてさらにバグが混入すれば、より事態は悪化することになるだろう。

彼らは、同じプロジェクトを動かす仲間として、ミスをリカバーしてプロジェクトを完遂させる、という視点ではなく、どちらかというと、下請けの「誠意」を具体的に見せることに異常にこだわる。ようは、元請けはそのまた元請け(またはエンドクライアント)に持っていける、ミスを償うだけの「無料のお土産」を下請けに要求するのだ。


私はこれを「0円贖罪*1」と呼んでいる。


こういう席に同席したこともある私だが、時々、ここで追加仕様の実装に代えて「ではミスによって引き起こされた御社の損害を賠償させていただきます」と言ってみたらどうなるだろうか?と想像することがある。

おそらく、我らの営業は狼狽して「それは無理だ!」と叫び、元請けの担当者は顔を真っ赤にして、「自分のミスを棚に上げて、開き直るのか!」と激怒するだろう。

開き直るもなにも、実際にこちらに(ある程度)責任があって、こういう事態が生じているのであるから、それを金銭で償うのは、一般社会では至極当然の行為である。しかしこのような席では、金銭による賠償を申し出るのは絶対的なタブーになっているのだ。


金銭での賠償の諸問題

何故そうなるのか、ということを考えるために、もし、ここで、実際に金銭による賠償という解決策を選んだ場合に起こりうる事態を挙げてみる。

  1. 元請けと下請けの責任比率の算定と、逸失利益の算出という非常にやっかいな作業が発生する
  2. 元請けがさらにその元請け、またはエンドクライアントに、同じ金銭交渉をせざるを得なくなる
  3. 我らの営業やディレクターの成績に具体的な傷がつくことになる
  4. 金銭的解決をしたら最後、その下請けのペナルティが確定し、今後発注できなくなるし、こちらも受注できなくなる

まず最初の「責任比率の算定と、逸失利益の算出」だが、スケジュールを決めるのは実質的に元請けだし、仕様を最終的に承認するのも元請けである。下請けが間抜けであれば別だが、進捗の遅れが発生するのは、工数とスケジュールの算定が甘かったり、後から急に思いつきの追加仕様をぶっ込んできたのが原因であることが多いのが理由だし、バグの発生原因も、仕様が無意味に複雑だったり、矛盾していたりすることが原因になっていることも多い。

つまり責任比率を真面目に算定するなら、元請け側により多くの責任がある場合がほとんどなのだ。


逸失利益についてだが、「1日遅れる毎に○円の違約金」といった契約事項が実行されることは、(例えそのような契約書を交わしていたとしても)よほどの場合を除いて、ない。前述の責任比率が問題となって、裁判沙汰になった時に必ず揉めるからである。
また、バグの発生によって、実際に損害を被るエンドクライアントが、その損害を算出しようにも、法的にも明白に説明可能な金額を出すことはかなり難しい。例えば、ある業務システムが1,2日止まったので、Excelやメールで処理したが、具体的に幾ら損したのか、というのは中々算出できるものではないからだ。(もちろん、そのためにバイトを急遽雇ったとか、ユーザーにお詫びのQuoカードを配ったとか、ECサイトが1日止まったので機会損失があったとか、それほどの規模の話になると本稿の話は通用しない。金銭による損害補償にまで話が及ぶだろう)

最終的には元請けがエンドクライアントと同様の交渉を行うコストを考えると、元請けはこの手を取りたがらないというよりは、「取れない」のが実情である。



また3,4に関して補足すると、例えば、この事態が「スケジュールは遅延したが、結果としてよりよいシステムが出来上がった」というゴールにたどり着いたとすると、下請け、元請けともに、担当者は「困難なプロジェクトをなんとか成立させた」という評価を得る事ができる。場合によっては、これは「スケジュール通りに、当初の想定の仕様のシステムを完成させる」ことより名誉なことであったりもする(!)

金銭での賠償=ペナルティの確定はこのストーリーを台無しにする。また、ペナルティが確定することにより、元請けが、次回以降、我々に発注することはおそらく出来なくなる公算が高い(上層部が許さない)が、ちゃんとシステムを開発できる下請けというのは実は、それほどすぐに見つかるものではない。ちゃんと仕事ができるかもわからない、新たな制作会社とワークフローを確立するコストも考えると、元請けは元請けで下請けをおいそれと切るわけにはいかないのである。


以上をまとめると、「金銭的解決」とはミスの「解決」ではなく「確定」を意味しており、元請け側にもミスを「確定」したいという意思はないことがわかる。そういう意味で言うと、元請けや下請けの我々が「0円贖罪」の儀式において模索しているのは、お互いの「ミスの隠蔽」なのだ、と言えなくもない。
(最近は本能的に、そのことをわかっている元請けが増えてきたので、会議室に呼び出されても、それほどネチネチ嫌味を言われることは実はあまりなかったりする)

0円贖罪で得られる物

なんという不毛な儀式だろう。こんな儀式はすぐにやめるべきだ。と誰しもが思ったところだろうが、実はこの儀式を止める解決策は既に存在する。

クラウドソーシングである。(と、ここにLancersとCloudWorksのアフィリエイト付きバナーを貼る)


クラウドソーシングであれば、発注側が成果物や進捗を気に入らなければ、簡単に報酬を無しにしたり減額したりできるし、受注側が異議を唱えてもクラウドソーシングサイト側が調停してくれる(よね?知らないけど)。なので、0円贖罪という不毛な儀式が入り込む余地がないのである。

とはいえ、これは自動車事故の示談交渉を保険会社にやってもらうのに似ていて、手数料(保険料)はかかるし、お互いが納得のいく結論になり難いという欠点もある。また、自動車事故と違って、発注側も受注側も逃げ放題なので、お互いのモラルハザードを引き起こしやすいという重大な問題もある。(もっと詳しく知りたい方は、ググるなり、クラウドソーシングサイトのスレでも見てみれば、おおよそはわかると思う)

つまり、「0円贖罪」もまた、社会的に不可欠な営みの一つなのである。滑稽に見えようが、無駄に見えようが、今後も必要な儀式としてシステム開発の現場で受け継がれていくことであろう。




追記

一部、大げさで誤解を招く表現がありましたので、修正しました。なお、幸いにして私の元請けは皆こんなことをしません。しないのです。しないったら!

*1:某番組の0円食堂とかけてみたがあまり上手くいっていない