ビギナーズガイド: 制約理論

「鎖の丈夫さはその中の一番弱い輪の丈夫さと同じにすぎない」という言葉を聞いたことがあるかもしれません。しかし、このことわざがプロジェクト管理にどのように当てはまるか考えたことはありますか？

制約理論では、弱い輪のことわざを基に、プロジェクトやプロセスの中で最も弱い輪を特定します。この「輪」を修正することで、プロジェクト全体を強化できます。この記事では、ボトルネックやプロジェクトの制限を改善するために、この理論をご自身のプロジェクトに適用する方法を説明します。

制約理論とは？

プロジェクト管理において、制約理論 (TOC) とは、プロジェクトの目的や目標の達成を妨げている最も重要なボトルネックや制限要因を特定するための問題解決手法です。たとえば、製品の発売が頻繁に遅れるとします。制約理論を使うと、発売を妨げる最大の要因を特定できます。そして、5 つの集中ステップを使ってその制約を取り除き、製品の発売に悪影響が及ばないようにすることができます。

制約理論によると、すべてのプロジェクトには 1 つの主な制約条件があるとされています。この主な制約条件、つまり鎖の中の最も弱い輪を解決することで、プロジェクトのプロセスをよりスムーズにすることができます。

プロジェクトやプロセスにおける最重要の制約条件を特定したら、その制約条件が制限要因でなくなるまで反復的に改善していきます。最初の制約条件を解決した後は、次に重要な制約条件が最重要の制約になります。そして、その制約条件に反復的に取り組むことを繰り返します。制約理論の目標は、プロジェクトの制限がなくなるまで、それぞれの弱い輪に対処していくことです。

制約理論の歴史

制約理論が初めて紹介されたのは、エリヤフ・ゴールドラット氏が執筆したフィクション作品「ザ・ゴール」でした。フィクションではありますが、この本では、製造やオペレーション管理のプロセスにおけるボトルネックに焦点を当て、企業が目標を達成することを妨げる最大の制限要因として制約理論を提唱しています。

「ザ・ゴール」は製造業の生産工場を舞台にしていることから、制約理論はリーン生産方式で初めて使われました。その後、他のプロジェクト管理方法論やリーンツールであるアジャイルやかんばんと同様に、プロジェクト管理に適用されました。

制約条件とは？

制約理論によれば、制約条件とは、プロジェクトの成功を妨げる第一の制限要因のことです。制約理論を使うことは、プロジェクトに含まれるランダムな制約条件を見つけることではなく、システム全体の中で最大の妨害要因やボトルネックを見つけ、その制約条件を解決することです。

最重要の制約条件を特定したら、それを取り除くか解決し、プロジェクトのプロセスを改善します。これにより、プロジェクトチームは、より早く、よりよく、より効果的に目標を達成できます。

プロジェクト管理における制約条件の例

制約条件は、計画プロセスや実装プロセス、さらにはプロジェクトチーム内など、プロジェクトやプロセスのあらゆる要素に現れる可能性があります。システム内の制約の種類を理解することで、制約条件を見つけやすくなります。

• ポリシー制約の例: 会社の手順によって仕事の速度を低下したり、手動での重複作業が増えている場合。(ポリシー制約は、プロジェクトやプロセス中に現れる最も一般的な制約です。)

• 内部制約の例: チームメンバーがプロジェクトに必要な特定のスキルを持っておらず、それがプロジェクトの成功を妨げている場合。

• 市場制約の例: 製品の供給量が予想以上に少ない、または理想的ではない場合。

• リソース制約の例: リソース管理計画で必要とされているものに比べて、プロジェクトに利用できるリソース、ツール、チームメンバーの数が少ない場合。

• 財務的制約の例: あるプロジェクトに投資するための資金が予想外に不足している場合。

• 文化的制約の例: 悪いプロセス (特に「ここではこうするんだ」とだけ言われ、十分に説明されないようなプロセス) のために、プロジェクトが効率的または効果的に行われていない場合。

プロジェクト管理において制約理論を適用するタイミング

ゴールドラット氏の制約理論は、非効率なプロセスを特定し、ボトルネックや問題を解決して改善するために有効な方法です。

とはいえ、ちょっとした修正や簡単な調整だけで済むようなプロジェクトに制約理論を適用しようとするべきではありません。たとえば、あまり複雑でないプロジェクトの問題は、ブレーンストーミングで解決してみてください。しかし、プロジェクトやプロセスが複雑であったり、ミッションクリティカルであったりする場合には、ボトルネックを減らすために制約理論を利用することが有益です。

制約理論を使うと、次のようなことが可能になります。

• ビジネスに大きな影響を与える進行中のプロセスを改善する

• 期待外れの製品導入や会社の目標未達成に対応する

• 今あるものだけを使って (追加の投資やチームメンバーを必要とせずに) チームを改善する

• 主要なプロジェクトの潜在的な問題を予測し、解決する

• プロジェクトリスク管理プロセスを強化する

同様に、プロジェクト管理のトライアングルを使って制約に取り組むこともできます。この方法では、品質の高い製品を提供するために、スコープ、コスト、時間のバランスを取らなくてはいけない「3 つの制約」の問題を可視化します。

プロジェクト管理における制約条件の 2 つの活用法

制約理論を使用する最初の最も基本的な方法は、5 つの集中ステップを使用することです。5 つの集中ステップでは、チームは制約条件が解決するまで作業を進めます。

また、主な制約条件の特定に苦労している場合は、思考プロセスを使って制約条件を見つけてから、それを解決するために 5 つの集中ステップに沿ってフォローアップします。

5 つの集中ステップ

5 つの集中ステップは、制約条件を特定して対処するのに役立ちます。これは、制約理論を使用する最も基本的でわかりやすい方法です。

ステップ 1: プロジェクトの主な制約条件を特定する

5 つの集中ステップの最初に、ボトルネックを探すことから始めます。ボトルネックとは、最も時間のかかるプロセス、プロジェクトの妨げになっている人やプロセス、プロジェクトの成功に対する最大のリスクなどです。

たとえば、エンジニアリングチームがしばしば数週間遅れで機能を納品しているとします。5 つのステップのうち、最初のステップでは、プロジェクトのリードタイムに影響を与えている可能性があるものを把握することに集中します。たとえば、プロダクトバックログで各機能の内容が不明瞭になっていないか、自分の作業量を測定するためのよりよいシステムが必要ではないか？などです。エンジニアリングチームのプロセスを調べてみると、プロジェクト管理ツールで作業に適切なタグ付けがされておらず、チームは各作業にどれくらいの時間がかかるのか把握できていないことがわかります。

ステップ 2: 制約条件を最大限に利用する

ステップ 2 では、既存のリソースを利用しながら制約条件を解決していきます。制約理論を使うことの利点の一つは、追加の投資や必要性を最小限に抑えることができることです。この段階では、「今あるリソースで、制約となっている条件をどのように最大化できるか」を考えます。制約条件を解決して、その条件が最重要の制限要因でなくなると、制約が「打破」された、つまり取り払われたことになります。

上記の例を参考に、エンジニアリングチームのバックログに追加される作業に適切なタグを付ける方法について、一連のガイドラインを確立します。チームでトレーニングセッションを開催し、全員にプロセスを説明して、疑問点が解決されるようにします。また、チームには継続的な改善を奨励し、タグ付けプロセスをより明確にするための変更を提案します。

ステップ 3: すべてを制約条件に従属させる

このステップでは、制約条件を昇格させて、プロジェクト内のすべてのものが制約条件に対する修正案を後押ししていることを確認します。従属させるということは、その制約条件よりも重要度の低いものがすべてそれに追随するようにするということです。あなたが解決しようとしている制約条件は、最大のボトルネックや障害であり、プロジェクトにおける他のすべてのものは、定義上、それよりも重要度が低いということを覚えておいてください。

先ほどの例の続きですが、新しいエンジニアリングチームのメンバーには、バックログシステムのトレーニングを受けさせましょう。適切にタグ付けされていないタスクには取り組まないようにします。タグがないと、チームはその作業の必要事項を明確に理解できないためです。バックログを頻繁に監査し、すべての作業が適切にタグ付けされていることを確認します。

ステップ 4: 制約条件を緩和する (オプション)

このステップは、まだ制約条件を解決していない場合にのみ必要です。この時点で、制約条件が深刻な障害となっている場合は、問題を解決するために、より多くのリソースを投入することを検討します。

エンジニアリングチームの例では、あなたが作成したタグ付けシステムをチームが使いこなせなかったり、タグに簡単にアクセスできなかったりする場合は、よりよいツールへの投資を検討しましょう。ご想像のとおり、Asana のエンジニアリングチームは Asana を使用しています。その理由をご確認ください。

ステップ 5: 必要に応じて繰り返す

この時点で、あなたのプロジェクトにとって最大の制限要因が解決されました。おめでとうございます！これで最重要の制約条件を解決したので、今度は 2 番目の制約要因が最重要の制約条件になりました。必要であれば、その制約条件を解決するために、もう一度このプロセスを実行してください。

例の続きですが、あなたのエンジニアリングチームは、新しいツールを気に入っているとします。今 2 番目から 1 番目になった最重要の制約条件は、顧客のニーズに応えるために適切な機能を構築することを優先させることです。この問題を解決するために、5 つの集中ステップを再度実行できます。

思考プロセス

物事がうまくいっておらず、何かが妨げになっていることはわかっているが、プロジェクトの制約条件を特定するのに苦労しているという場合は、思考プロセスを利用することもできます。思考プロセスでは、決定木を使ってプロジェクトやプロセスの主な制約条件を特定します。決定木とは、プロジェクトの意思決定と、それぞれの意思決定から分岐する潜在的な結果を樹木のように表現したモデルです。バリューストリームマッピングを行ったことがある方は、決定木を作成したことがあるかもしれません。決定木を使って制約条件を特定した後は、それを解決するために、5 つの集中ステップを使います。

思考プロセスでは、3 つの質問を投げかけ、決定木を使って答えを導き出します。

どのような制約条件を変える必要があるのか？

この質問に答えるには、現状問題構造ツリー (CRT) を使います。CRT では、プロジェクトの問題を症状と見なし、その原因を探すことになります。プロジェクトのさまざまな問題を扱っている場合、CRT を使って因果関係図を描き、多くの望ましくない結果の根本原因を突き止めることができます。その根本原因こそが、あなたの最大の制限要因、すなわち主な制約条件なのです。

その制約条件を何に変えることができるか？

この質問に答えるには、未来問題構造ツリー (FRT) を使います。FRT では、理想的なプロジェクトプロセスがどのようなものであるべきかをツリーでマッピングします。このツリーを現在のプロセスと比較して、現在うまく機能していないものを特定することができます。これらの変更はインジェクションと呼ばれ、プロジェクトの問題を現実の解決策に変えるのに役立ちます。

その制約条件をどのように変えられるのか？

この質問に答えるには、対立解消図 (EC) を使います。EC を使って、明確な解決策がないプロセスをマッピングします。EC では、各プロジェクトのニーズの背景にある前提条件を理解し、その前提条件との競合を特定できます。その競合を特定したら、制約条件を解決できます。

制約理論によるリスクの軽減

制約理論は、既存プロジェクトのリスクを軽減し、ボトルネックを改善するための優れた方法です。プロジェクトの改善活動に行き詰まりを感じたら、制約理論を使って最大の制限要因を特定することを検討してみてください。そして、5 つの集中ステップを使って制約を解決します。制約理論を活用することで、プロジェクトやプロセスを継続的に進化させ、最もインパクトのある仕事を成し遂げることができるのです。