
84.クリティカルチェーン
本作は、プロジェクトを中心としたTOCの実践的活用方法について書かれています。
今までは、プロジェクトに関してどのようにTOCを取り入れればよいか分かりにくい部分もありましたが、その部分にのみ集中して話が展開します。
途中で、「ザ・ゴール2」に登場する人物が出てくる場面もあります。
個人的にはこのシリーズの中でもっとも実践で役立つ技術が書かれていると感じます。
プロジェクトの見積り
仕事上で見積りの作成や、プロジェクトリーダーをされた方は分かると思いますが、始めに行うのは「プロジェクトの見積り」です。
見積もる場合にはある程度仕様がはっきりとしている事が条件としてありますが、その条件を満たした上で、どのような考えから「プロジェクトの見積り」を決めるのでしょうか。
必要となる作業
作業の分配
作業順序
期間
経費
これらの条件を考慮して、人員の数や日程を調整します。その上で見積りを作成します。
一般的なプロジェクトでは、これらの中でもっとも「見積り金額」に関わる部分は「期間」とされています。これは
人員の数 × 期間 = 経費(人件費)
といった計算が成り立つからです。実際には、作り出す物によって付加価値をそれに付け加えます。
そのようなことから、見積りを作成する上で最も重点を置くべき所は「期間」をどのように設定するか、になります。
プロジェクト期間の考え方
本書では、プロジェクトの期間をどの様に設定し、それをどの様に活用していくのか、これをTOCを利用してどの様に考えればよいのか、それを示す事が目的です。
では、一般的にこの「プロジェクトの期間」はどの様に決められるのでしょうか?

この図は、プロジェクトが完了する確立と時間を表すグラフですが、「期間」を考える場合、「確立上の中間」を選択して見積もる人はまずいないと思います。
プロジェクトが何事もなく完了すればいいのですが、1つでもトラブルが発生すると、それが引き金となりプロジェクトの完了が長引く可能性があるからです。
このような理由で、ある程度のマージンを確保した「期間」を見積もる事となります。
しかし、この図でみると中央のおよそ2倍のマージンを取っている事となります。ほんとにこのマージンは正等な物でしょうか?
プロジェクト期間の伸びる可能性
「期間」の伸びる原因について考えます。主に次にような事が挙げられます。
1.不確定要因が多い
例えば、外で行う工事の場合、天候によって出来ない作業もあります。また、仕様変更なども事前に予測する事は不可能です。
2.プロジェクトのステップ数(マネジメント数)が多い
これは、大きなプロジェクトになると、多くのステップから構成されますが、その場合に、各ステップ単位でマージンが取られる為、ステップ数に比例してマージンも大きくなります。
つまり
作業1 + 作業1 = 2 ではなく
作業1 + 作業1 + マネジメント1 = 3 となり、それぞれの作業マージン+マネジメント分までが含まれます。
3.「期間」を削られる事を前提に水増しする
見積もった「期間」を「長すぎる」という事で、削られる場合があります。このようなことが頻繁に行われている場合、当然削られる前提とした「期間」を見積もることになります。
その結果「期間」が実際に必要とされる日数より多く取られます。
しかし、余裕をもって確保されているにもかかわらず、なぜプロジェクトが見積もった「期間」を過ぎても完了しないのでしょうか?
プロジェクトが長引く理由
主だった理由として、次のような事が挙げられます。
1.余分な機能を詰め込む
特に、ソフトウェア開発の現場ではこのような事が日常茶飯事です。これは、望む機能を実装するために単純に「追加コードを作れば良い」といった考えに走ってしまうからです。
技術力の低いエンジニアの場合、構造を理解できないためにこのような行動になりがちです。
実際は、既に実装されている機能の組み合わせや、一部を変更するだけで実現出来る可能性も考慮する必要があります。
2.作業完了を報告しない
作業が完了したとしても、まだ期限に余裕がある場合は報告せずに、時間稼ぎをして、期日になった時点で報告が行われます。
これは、早く終わった場合に次回も同様に早く終われると上司は考え、次の作業時間がかなり短く設定されるからです。
つまり、早く作業が終わったとしても、次のステップでそれが活かされる事がありません。
3.作業の掛け持ち
複数の作業を同時に行う場合、1つのステップを完了させるために必要な期間は「平行作業を行うステップの合計」となります。
このような場合、3つのステップが終わらなければ次のステップは実行する事が出来ません。
4.学生症候群
学生の頃テストが近づいてきたら必死に勉強したことはないでしょうか?
または、夏休みの最後の1週間から、必死に宿題を片付けた事はないでしょうか?
つまり、これは期間を設けている場合に、その期間の終わり間際になってようやく作業を開始する事を意味します。
月末になると「今月の売上目標がぁ!」と、いった行動に身に覚えのある方はいないでしょうか。
このような事から、プロジェクトのマージンが無駄に消費されていきます。
コスト・スループット
解決方法について説明する前に「コスト」「スループット」が理解出来ないとわかりにくいため、先にこの2つを説明します。
1.コスト
実際に作業をする上で必要になる経費の事です。会社でも「コストを抑えて」この言葉を耳にする事はないでしょうか。
コストは「お金」をベースにした考え方で「安く作り出せればそれが会社の利益につながる」この考え方が基本にあります。
経費は作業時間と密接に関連する為、極力作業時間を短くする(パフォーマンスを上げる)という考え方となります。
例えば、コストを抑えて何かを作る場合、最小の経費で多くが作れれば良いと考えると思います。
これは、「全てのステップで必要な経費の合計を少なく抑える事」と考えられます。つまり、1つ1つのステップの経費を最小に抑える事に集中します。
その場合、製造では「高性能な機械」、プロジェクトでは「その分野のプロフェッショナル」を割り当て効率UPを図り、経費を抑えます。
この考え方では、各ステップのパフォーマンスを上げる事に集中する事から「部分最適化」と呼ばれています。
2.スループット
ある1つのステップでは無く「全てのステップ間での流量」に注目した考え方です。
すなわち、最初のステップと最後のステップ間の「流量」が重要となり、コスト管理での「部分最適化」とは異なります。
また、「流量」は「短い時間での物量」と定義する事が出来ます。
では、この「流量」はどの様に決まるのでしょうか?
これは、単純に「もっともパフォーマンスが低いステップでの流量」となります。
本書ではこれを「鎖(Chain)」を使って表現しています。これは「鎖」の強度を決めるのは「最もつながりの弱い輪」だからです。
この2つを比べると、どちらがより多くの利益を上げることが出来るでしょうか。利益とは
短い時間(全てのステップ合計時間)
少ない経費(全てのステップ合計経費)
物量(ステップの終わりで作り出される量)
この3つで、成り立ちます。しかし、経費は作業時間に密接に関連するため、作業時間を短くすると経費も少なくてすみます。そのように考えると
「全てのステップ間を短い時間で多くの量を作り出す事がもっとも利益を生み出す」
と考えられます。あれ?これは「スループット」の考え方と同じでは?と、理解出来ますよね。
例えば、コスト管理での「部分最適化」を行った場合、1つのステップのパフォーマンスは上がりますが、次のステップが遅い場合はそこが足かせとなって「最後のステップで作り出される量には変化ない」と、なります。つまり
「利益を考える上で最も重要なのはスループットに注目する事」
です。これがTOC理論を考える上で重要となります。
プロジェクトの正当な見積り
スループットの概念とコスト管理の問題点が分かった所で、実際にスループットを重視したプロジェクトの見積り方法について考えます。
大きなプロジェクトは複数のパス(ステップ間のつながり)によって構成され、そのパスは平行作業を意味します。また、それらの作業は最終的には1つのパスに合流し、プロジェクトは完結します。
つまり、全てのパスが完了状態にならないと、プロジェクトは完結する事が出来ません。
ここでは、「PERTチャート」を利用します。

この図について説明すると1つの四角が、1つのステップを表します。
中央のオレンジ色の部分は「最も時間のかかるパス」を表します。これを「クリティカルパス」と呼びます。
「X」は競合を表しており、同じリソースが複数のパスで利用されます。
「FB」は合流バッファを表し、通常はパスが合流する手前に配置しますが、競合するリソースがある場合は、そのリソースの前に配置します。但し、クリティカルパス上の競合に関しては考えません。
「PB」はプロジェクトバッファを表し、合流したパス全てのバッファとして扱います。
「緑の線」は競合するリソースを結ぶ線を表し「クリティカルチェイン」と呼びます。
コスト管理の考え方に基づいてプロジェクトを見積もる場合、このような図とはなりません。1つのステップ対してマージン(バッファ)が確保されます。
つまり、全てのステップでマージンが確保されるため、多く取られます。
しかし、スループットを考える場合、個々のステップに注目するのではなく全体として考える必要があります。
では、いったいどのように考えるべきなのでしょうか?要点を挙げておきます。
1.最も時間のかかるパス(クリティカルパス)を見つける
製造だけでなくプロジェクトでもスループットを考える場合は「ボトルネック(制約条件)」となる部分を見つけ出す事から始めます。
そして、その「ボトルネック」となるパスを中心に考えます。つまり、最も重要なパスと位置づけます。
2.競合を考える
例えば1人のエキスパートがいたとして、あるステップに関しては必ずこのエキスパートが居なければ進められない状況のとき、複数のパスで同様に、同じタイミングでそのエキスパートが必要となるステップが存在している場合を指します。
この場合、極力競合を回避するように、作業順を考える必要があります。
3.合流バッファ
パスが合流する部分を指します。パスが合流する部分というのは、全てのパスが完了している必要があります。
その手前にバッファを配置する事で1つのパスが遅れた場合でも、バッファで吸収出来ます。よって、合流の手前の各パスに合流バッファを配置します。
但し注意が必要です、クリティカルパス以外のパスで競合が発生している場合は、その競合の前にバッファを配置する事が望ましいです。
これは、競合ステップを開始するタイミングをずらす役割があります。つまり、競合ステップまでが早く完了した場合、バッファを使わずに早く始める事が出来ます。
また、遅れた場合においてもバッファによって、遅れを吸収出来ます。
4.プロジェクトバッファ
プロジェクト全体でのバッファを最後に配置する事で、多少の遅れが発生した場合にでも、対処可能となります。
5.期限ではなく、期間を設定する
期限を設けることがどのような弊害があるかは「学生症候群」が発生する可能性があると、前に説明しました。
そのため、期限は設定せず、ステップにかかる「期間」を設定します。この期間はマージンを考慮せずに考えます。
これは、合流バッファやプロジェクトバッファがあるため、個々のステップでマージンを考慮する必要がありません。
6.可能ならばステップを開始する
1つのパスを最後まで完了することが出来る状態の時は、即座に開始します。
逆に、パス上のどれか1つのステップでも作業が出来ない状態の時(他の仕事で人が居ない)場合は、開始を見合わせます。
途中でパスを中断した場合、他の作業を行い、再びパスを再開しますが、複数の作業を平行して行っていく場合には、作業の切り替え時間が必要になります。
つまり、何をすべきかを「選択」し、一旦作業を開始した場合はその作業を完了するまで「集中」して終わらせる。この「選択と集中」によって、時間を効率良く利用出来ます。
7.作業の開始予告を通知する
特に、競合部分においては、出来る限り短い期間で完了させる必要があるため、作業が開始出来る少し前の段階から「何日後から開始出来る」事を、伝えておく必要があります。
そうする事で、事前準備が可能となり、速やかに作業を開始出来ます。
8.進捗の管理はバッファの残量を見る
全てのステップ間の関係で管理を行うことから、単純な進捗管理が行えません。
そこで、その進捗を管理するには各パスで儲けられた「合流バッファ」および、プロジェクト全体での「プロジェクトバッファ」の残量で管理を行います。
つまり、バッファが減っていない場合は早く完了する見込みがあります。バッファが無くなっている場合は、そのバッファの関連する作業が遅れている状況です。
以上に注意を払い、プロジェクトの管理を行えば、今までのような
「全てのステップにおいて、マージンを考慮する」
無駄を省く事が出来ます。
プロジェクトの価値
複数のプロジェクトが存在している場合にどの案件を行うのか、どのプロジェクトが価値をもたらすのか、その判断方法について説明します。
一般的には、次の2つを基準に考えられます。
1.回収期間(Payback Period)
投資をどれぐらいの期間で回収する事が出来るのかを基準とします。
つまり「時間」を基準としてそのプロジェクトの価値を判断します。
2.正味現在価値(Net Present Value)
将来の投資や収入を、現在の価値に換算する事です。つまり、金利やインフレを考慮した価値の事です。
例えば、1000万円投資を行い、それがインフレや金利などで1100万円になると予測を立て、それを価値と考えます。
つまり「お金」を基準としてそのプロジェクトの価値を判断します。
これら2つの方法はそれぞれ「時間」「お金」を別々の次元で捕らえて考えていますが、実際にはこの2つを同時に考える必要があります。
ことわざでも「時は金なり」と、言われている通りこの2つを考慮した新しい指標が必要です。
例えば、あなたがある会社の経営者だったとします。新しい人材を確保してその教育費に2000万円用意していました。うまく教育が出来れば、来年には更なる売り上げの増加が見込めていました。
ある日、取引先の会社が資金繰りに困っているとのことで、融資を申し出てきました。この会社とは付き合いが長く、持ちつ持たれつの関係だったため、この教育費として確保したお金を融資する事としました。
結局その融資のおかげで会社は持ち直し、1年後には更に大きな会社となり、無事利息を含めた全てのお金が返済されました。
さて、経営者であるあなたは2000万円と多少の利息を受け取ってそれで満足しますか?
普通に考えると、その2000万円で社員を教育していれば売り上げが50%UP出来たかもしれないのです。しかし、利息で50%というのはありえません。
つまり、ここに矛盾が発生します。
利息では、投資したお金に対する価値が低く見積もられるのです。本書ではこの問題点を解決するための新たな指標を示しています。
フラッシュ
といえば、カードゲームが思い浮かびますがまったく関係ありません(笑
先ほどの例からも分かるように、プロジェクトに対する投資に関しては、「時間」の価値を考慮する必要があります。
そこで、考え出されたのが「ダラーデイズ(dollar-days)」という考え方です。
つまり、「時間とお金の乗法の和」がプロジェクトの価値を表す指標になる、ということです。
例えば、100万円投資して1日経つと、100ダラーデイズとなり2日経つと200ダラーデイズとなります。
10日後には、1000ダラーデイズとなりますが、ここで投資した100万円が返って来たとしても、まだ900ダラーデイズ残っている事となります。
「お金」と「回収期間」を使って考えると、このような考えになりますが、これでは価値が低く見積もられてしまうのです。
つまり、「お金」と「投資」は従来の考え方では同意語として考えられる事が多いのですが、明らかなる違いがあります。
先の例では、残った900ダラーデイズを洗い流してやる(フラッシュする)事でその価値を見積もる事が出来るということです。
まとめ
今回も非常に興味深い内容でした。学んだ事をどの様に文章で表現すればいいのか苦労しましたが、この積み重ねが一番頭に残る方法です。
皆さんも一度試してみてください。
但し、この書籍に書かれている部分で、ソフトウェアエンジニアの視点で見た時に1つだけ違和感を感じる点があります。
それは、コストの部分なのですが、エキスパートな人を雇えば、その分経費を抑えられると書かれているのですが、これだと同じ作業を行っても、能力の高い人は報酬が少なくなってしまいます。
本来、早く終わらせることが出来るのであれば、他の作業に手を付ける事も出来ますので、エキスパートな人は高い価値を生み出す事になります。
そうしたことから、ソフトウェアエンジニアについては単純に工数で計算すると、正しい評価が出来ない状況となります。
0 → 1 を作る人と、1 → 2 を作る人でも、価値は全く異なります。
これらを考慮したうえで、正しいコストを導き出すことが、重要となります。
コスト計算の際には「技術に対して重みづけ」が必要であることを付け加えておきたいと思います。
いいなと思ったら応援しよう!
