『クリティカルチェーン』から納期短縮により下請け業者が価格競争を回避して入札を得る方法

プロジェクトという言葉を聞いてどういったイメージが思い浮かべるでしょうか。自分のイメージではIT企業の仕事のやり方の中のひとつというイメージしかなく、具体的にどのようなものなのか、といったことまではわかりません。

プロジェクトとはwikipediaには以下のように書かれています。
プロジェクト – Wikipedia

プロジェクト（英: project）は、何らかの目標を達成するための計画を指す。小さな目標の達成のためのものではなく、大きな目標を集団で実行するものを指すことがある。その計画の実現のための個々のタスク（仕事）の実行までを含めて指すこともある。

既存の組織の枠をはずし、各組織から臨時に人を集めて実行する集団をプロジェクトと呼ぶこともある。これらは、英語でも同様である。ソフトウェアの設計では、統合設計環境における設計単位をプロジェクトと呼ぶ。

ふむ、なんとなくイメージはできました。要は「計画」ということですよね。

ここ最近は『クリティカルチェーン―なぜ、プロジェクトは予定どおりに進まないのか?』という本を読んでいました。

本書の題名に「プロジェクト」という言葉があるように、プロジェクトが予定通り進まない問題に対してどう処理していくべきか、上手く処理した場合、どのような結果が得られるのかといったことが書かれています。

今回は本書を読んでいて感心したことがあるので、その部分をつらつらと書いていきます。

他社より早く仕事ができることが競争優位性につながる
1. 他社より早く仕事ができることが競争優位性につながる
2. デベロッパーが下請け業者を選ぶ際の判断基準
納期遅延によるキャッシュフローへの影響
実際の現実的な問題としてはどうなのか？
あわせて読みたい

他社より早く仕事ができることが競争優位性につながる

『クリティカルチェーン』という本のストーリーは、大学のエグゼクティブMBAのクラスを舞台としたお話です。主人公の教授と、各業界から現行のプロジェクトの納期短縮という課題を解決するために集まったプロジェクト・リーダーらが、議論しながら現実的な解決方法を模索していきます。

この本の著者であるエリヤフ・ゴールドラットさんが書いた本で『クリティカルチェーン』以外の本はおもしろく読むことができたのですが、本書は１回で内容を把握するには難しいかなと思いました。

その中で「こんなやり方があったんだぁ」と感心した部分があったのでその部分について書いていきます。

他社より早く仕事ができることが競争優位性につながる

p312
「わかりました。つまりデベロッパーが入札を受け付ける際に、リードタイムを短くすることと、もしそれを果たせない場合は大きなペナルティーを課すことを条件として明記すれば、他の業者は怖がって誰も入札しない。

デベロッパーの投資利益率はずっと高くなるしリスクも軽減できる。一方仕事が取れたこの下請け業者は大きな利益を得られる」

「そうですね。おっしゃるとおりです。今のデベロッパーと下請けの関係はWin-Loseではなく、Lose-Loseです。デベロッパーはリードタイムが長くなって、それもいつになったら終わるかわからない。

一方、下請け業者は価格を競い合って、同業同士お互いの首を絞めあっている」「もしこれに気づく下請けがいれば大きな競争優位性を築くことができる」

「それができる下請けは、価格を高くしてもちゃんと仕事が取れる。問題は他のプロジェクトと同じで、リードタイムを短くすることなど無理だと下請け業者が思っていることだ。ということは、最初に目を覚ました者の勝ちだ」

引用ここまで

要は他社より明らかに早く仕事ができることが競争優位性につながるということですね。

デベロッパーが下請け業者を選ぶ際の判断基準

この会話以前にデベロッパーが下請け業者を選ぶ際の判断基準が「価格」でした。いかに安く下請け業者を選ぶか、反対に下請け業者はいかに安くするかに腐心しなければなりません。

納期遅延によるキャッシュフローへの影響

通常は納期どおり製品を納めることが普通だと思われますが、本書では「遅れた方が助かる」と書かれています。なぜなら、仕事をとるためにほとんど利益が出ない契約だが、顧客からの仕様変更があると作業が遅れても仕方ないと思われる、加えて契約期間より延長した分多く料金を払ってもらえるとのこと。

納期遅延はキャッシュフロー、手元現金に悪影響がある

デベロッパーの側ですが、納期遅延はキャッシュフロー、手元現金に悪影響があるようです。ほとんどのデベロッパーは十分に資金を持っておらず投資額の方がはるかに大きいので、お金を借り入れてプロジェクトを行っているところが多いようです。

このような状況なので、例えばプロジェクト期間中に銀行への支払利息の支払いや他社への支払いなどで資金繰りが行き詰る可能性が高くなってしまうということでしょう。

納期遅延は下請業者にとってメリットはあるが・・・

下請け業者にとっては仕様変更によって多く料金を得られても、納期の遅延によって元請に悪影響があり、最悪の場合倒産となったら両者とも利益がなくなるということですね。

資金繰りを良くするにはリードタイムの短縮が必要

そのような場合は、本書の場合はデベロッパーになりますが、元請となる会社は資金繰りを考えればリードタイムの短縮、なるべく短い期間で仕事をして欲しいはずです。ですが、元請は「価格」で選んでしまう。その解決策として上記で引用した

「わかりました。つまりデベロッパーが入札を受け付ける際に、リードタイムを短くすることと、もしそれを果たせない場合は大きなペナルティーを課すことを条件として明記すれば、他の業者は怖がって誰も入札しない。

デベロッパーの投資利益率はずっと高くなるしリスクも軽減できる。一方仕事が取れたこの下請け業者は大きな利益を得られる」

ということになって、下請け業者は価格競争を回避できる。元請の側は資金繰り上助かる、ということです。ここでの注意点ですが、本書では「大きなペナルティーを課すよう下請けがデベロッパーを説得する」と書かれています。

「デベロッパー」ではなく「下請け業者」がデベロッパーを説得する、です。これによって価格を高くしても仕事がとれる、とのこと。

実際の現実的な問題としてはどうなのか？

「理論上、本の中の話ではわかる。しかしそのやり方は現場で使えるのか？」という言葉が聞こえてきそうです。自分も今回の記事でとりあげたような、建設現場での仕事やIT企業でSEやプログラマーとして仕事に携わった経験があるわけではありません。

しかし本書を訳した三本木亮さんによると以下のように書かれています。

三本木亮さんの事例

P383
「本書を訳していて面白かったのは、第20章に、テッドが建築業界のジレンマ（プロジェクトの完成が遅れてもメリットこそあれ、デメリットはない）を説明する件があるのだが、これが実に的を射ていたことだ。

私が自らのプロジェクトで日々経験している状況、まさにそのものなのだ。一棟ごとに工期の完成時期の完成時期は組まれているのだが、これまで工期どおりに工事が終わったためしがない。

予定どおりにいかなくても当たり前、仕方ないと考えているのだ。いかにプロジェクト・マネジメントをおろそかにしていたのか、本書訳者として恥ずかしい思いがする」

引用ここまで

という風にあります。本書の内容はアメリカだけに当てはまる事例かと思っていましたが、日本でも同じような状況なのですね。