関連記事

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

プロジェクトという言葉を聞いてどういったイメージが思い浮かべるでしょうか。自分の

イメージではIT企業の仕事のやり方の中のひとつというイメージしかなく、具体的にどの

ようなものなのか、といったことまではわかりません。

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

プロジェクト(英: project)は、何らかの目標を達成するための計画を指す。

小さな目標の達成のためのものではなく、大きな目標を集団で実行するもの

を指すことがある。その計画の実現のための個々のタスク(仕事)の実行ま

でを含めて指すこともある。

既存の組織の枠をはずし、各組織から臨時に人を集めて実行する集団をプロ

ジェクトと呼ぶこともある。これらは、英語でも同様である。ソフトウェア

の設計では、統合設計環境における設計単位をプロジェクトと呼ぶ。

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

ここ最近は『クリティカルチェーン―なぜ、プロジェクトは予定どおりに進まないの

か?』という本を読んでいました。

本書の題名に「プロジェクト」という言葉があるように、プロジェクトが予定通り進ま

ない問題に対してどう処理していくべきか、上手く処理した場合、どのような結果が得

られるのかといったことが書かれています。

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

す。

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

『クリティカルチェーン』という本のストーリーは、大学のエグゼクティブMBAのク

ラスを舞台としたお話です。主人公の教授と、各業界から現行のプロジェクトの納期

短縮という課題を解決するために集まったプロジェクト・リーダーらが、議論しなが

ら現実的な解決方法を模索していきます。

この本の著者であるエリヤフ・ゴールドラットさんが書いた本で『クリティカルチェ

ーン』以外の本はおもしろく読むことができたのですが、本書は1回で内容を把握す

るには難しいかなと思いました。

その中で「こんなやり方があったんだぁ」と感心した部分があったのでその部分につ

いて書いていきます。

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

p312

「わかりました。つまりデベロッパーが入札を受け付ける際に、

リードタイムを短くすることと、もしそれを果たせない場合は

大きなペナルティーを課すことを条件として明記すれば、他の

業者は怖がって誰も入札しない。

デベロッパーの投資利益率はずっと高くなるしリスクも軽減で

きる。一方仕事が取れたこの下請け業者は大きな利益を得られ

る」

「そうですね。おっしゃるとおりです。今のデベロッパーと下

請けの関係はWin-Loseではなく、Lose-Loseです。デベロッパー

はリードタイムが長くなって、それもいつになったら終わるか

わからない。

一方、下請け業者は価格を競い合って、同業同士お互いの首を

絞めあっている」「もしこれに気づく下請けがいれば大きな競

争優位性を築くことができる」

「それができる下請けは、価格を高くしてもちゃんと仕事が取

れる。問題は他のプロジェクトと同じで、リードタイムを短く

することなど無理だと下請け業者が思っていることだ。という

ことは、最初に目を覚ました者の勝ちだ」

引用ここまで

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

ね。

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

この会話以前にデベロッパーが下請け業者を選ぶ際の判断基準が「価格」でした。い

かに安く下請け業者を選ぶか、反対に下請け業者はいかに安くするかに腐心しなけれ

ばなりません。

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

通常は納期どおり製品を納めることが普通だと思われますが、本書では「遅れた方が

助かる」と書かれています。なぜなら、仕事をとるためにほとんど利益が出ない契約

だが、顧客からの仕様変更があると作業が遅れても仕方ないと思われる、加えて契約

期間より延長した分多く料金を払ってもらえるとのこと。

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

デベロッパーの側ですが、納期遅延はキャッシュフロー、手元現金に悪影響があるよ

うです。ほとんどのデベロッパーは十分に資金を持っておらず投資額の方がはるかに

大きいので、お金を借り入れてプロジェクトを行っているところが多いようです。

このような状況なので、例えばプロジェクト期間中に銀行への支払利息の支払いや他

社への支払いなどで資金繰りが行き詰る可能性が高くなってしまうということでしょ

う。

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

下請け業者にとっては仕様変更によって多く料金を得られても、納期の遅延によって

元請に悪影響があり、最悪の場合倒産となったら両者とも利益がなくなるということ

ですね。

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

そのような場合は、本書の場合はデベロッパーになりますが、元請となる会社は資金

繰りを考えればリードタイムの短縮、なるべく短い期間で仕事をして欲しいはずです

。ですが、元請は「価格」で選んでしまう。その解決策として上記で引用した

「わかりました。つまりデベロッパーが入札を受け付ける際に、

リードタイムを短くすることと、もしそれを果たせない場合は

大きなペナルティーを課すことを条件として明記すれば、他の

業者は怖がって誰も入札しない。

デベロッパーの投資利益率はずっと高くなるしリスクも軽減で

きる。一方仕事が取れたこの下請け業者は大きな利益を得られ

る」

ということになって、下請け業者は価格競争を回避できる。元請の側は資金繰り上助

かる、ということです。ここでの注意点ですが、本書では「大きなペナルティーを課

すよう下請けがデベロッパーを説得する」と書かれています。

「デベロッパー」ではなく「下請け業者」がデベロッパーを説得する、です。これに

よって価格を高くしても仕事がとれる、とのこと。

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

「理論上、本の中の話ではわかる。しかしそのやり方は現場で使えるのか?」という

言葉が聞こえてきそうです。自分も今回の記事でとりあげたような、建設現場での仕

事やIT企業でSEやプログラマーとして仕事に携わった経験があるわけではありません。

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

三本木亮さんの事例

P383

「本書を訳していて面白かったのは、第20章に、テッドが建築業界のジ

レンマ(プロジェクトの完成が遅れてもメリットこそあれ、デメリット

はない)を説明する件があるのだが、これが実に的を射ていたことだ。

私が自らのプロジェクトで日々経験している状況、まさにそのものなの

だ。一棟ごとに工期の完成時期の完成時期は組まれているのだが、これ

まで工期どおりに工事が終わったためしがない。

予定どおりにいかなくても当たり前、仕方ないと考えているのだ。いか

にプロジェクト・マネジメントをおろそかにしていたのか、本書訳者と

して恥ずかしい思いがする」

引用ここまで

という風にあります。本書の内容はアメリカだけに当てはまる事例かと思っていまし

たが、日本でも同じような状況なのですね。

リードタイム短縮は在庫の削減や売掛金の早期回収につながり、資金繰りが良くなる

本書では、他社より早く仕事ができることが競争優位性につながる、ということに対

して「なるほどなぁ」と思いました。リードタイム短縮の効果というのは、今までの

過去記事で書いた工場の事例で在庫の削減や売掛金の早期回収につながり、手元の現

金が増えて資金繰り上有利になる、というものでした。

それがプロジェクトマネジメントでも同じような効果が得られて競争優位につながっ

ています。他にも思ったのは「ホワイトカラーの仕事も同じようにすればいいのでは

?」と思いました。

納期は職種ごと、部署ごとに決まっていると思いますが、例えば早く仕事を終わらせ

ることに対して何かインセンティブを与えればみんな頑張るんじゃないか、というこ

とです。

早く仕事ができるようになることの見返りが必要

多くの人は早く仕事が終わっても期限までダラダラやってしまうのではないでしょう

か?早くやったらやったで仕事を増やされます。みんなそれを嫌がって本当はもっと

できるんだけど、残業代を得るという目的で仕事をしてしまう人もいるのではないで

しょうか?

その理由って頑張っても利益が少ない、むしろ負担が増えてしまう。だから、通常よ

りも早く仕事ができるようになったら給料が少し増えるとか、何かしらの努力に対す

る見返りがあればいろいろと変ってくるのではないかなぁと思います。