TOC思考プロセスの特徴

　昨今、CCPM（クリティカルチェーン・プロジェクトマネジメント）を、ITプロジェクトに導入し、大きな効果を上げた事例が出始めている。プロジェクト管理に関心をお持ちの読者なら、一度はCCPMの名前を聞いたことがあるのではないだろうか。CCPMの特徴は、プロジェクト管理における「リソース（人的資源）」を「制約条件」と捉えて管理することにある。

　このCCPMはエリヤフ・ゴールドラット博士によって考案されたもので、その元となったのが、「TOC（Theory of Constraint＝制約条件の理論）」という、システムや環境における「制約」に着目して管理・改善していくマネジメント理論である。ちなみにTOCの応用としてはCCPMのほかに、DBR（ドラム・バッファー・ロープ）という生産性改善手法も製造業を中心によく知られている。

　本連載では、CCPMやDBRを生み出した大本のTOCの問題解決手法にスポットを当てる。多くのTOC関連書籍などで「思考プロセス」として紹介されているものである（本連載では「TOC思考プロセス」と記述する）。これをどのようにIT現場で問題解決に役立てればよいかを、実践経験から得られた知見も交えつつ解説していく。

　TOC思考プロセスは、組織・システムにおける問題の根本原因を「制約」と捉え、その制約を解消する方法を考えられるようにする、体系的なアプローチである。TOC思考プロセスは、組織変革における問題解決を目的に開発されたもので、様々なツール（次回以降で解説予定）が用意されており、本来は体系的に活用することが前提とされており、書籍でもそのように解説されていることが多い。

　もちろんIT関連の組織全体で抜本的な生産性向上や品質向上の施策を打ちたいときにも、TOC思考プロセスをフルセットで利用してよい。しかし筆者の活用経験では、それらのツールの一つひとつを単独で活用することも可能である。例えば、特定のITプロジェクトを改善するための簡易問題分析ツールとして、その一部を活用してもよいだろう。また、プロジェクト管理の問題解決だけではなく、ソフトウェア開発における要求分析などで活用することも可能だ。

　実際にIT現場でTOC思考プロセスを活用した事例については、連載を続けるなかで紹介していく予定である。

組織・人間の特性にフォーカスする問題解決手法

　読者の方々は、普段の業務において、どのような問題解決の手法を使っているだろうか？問題解決によく使われる代表的な手法としては、「QC手法」や「なぜなぜ分析」、「MECE（Mutually Exclusive and Collectively Exhaustiveの略）」、「ロジックツリー」などが挙げられる。

　ちなみに筆者の所属するIT現場においては、昔ながらのQC手法が使われることが多い。ソフトウェア開発の現場では、品質管理手法としてのQC手法が定着していることが多く、QC手法による問題解決は、多くの人たちにとってなじみやすい手法といえるだろう。

　さて、これらの手法とTOC思考プロセスでは何が違うのだろうか。以下、TOC思考プロセスの特徴を詳しくみていくが、その前に、上記の代表的な問題解決手法の概要を表に整理しておこう。

　表で紹介した手法の多くは「業務改善における問題解決」をターゲットとしているが、TOC思考プロセスがターゲットとするのは、単なる「改善」ではなく、「変革」を生み出すための問題解決である。

　変革を生み出すためには、「根本原因」を追究し解決していかなければならない。その答えを出すことも容易ではないが、その結果、組織やそこで働く多くの人たちに変化を強制することも大変である。変化への抵抗勢力の前に、志半ばで挫折することもあるだろう。

　TOC思考プロセスは、このような通常困難を極める変革を素早く、容易に、そして確実に実行できるようにするため、（1）シンプルに限られた根本原因を追究、（2）組織・人間の特性にフォーカス、（3）組織変化への抵抗を抑える合意を形成する──という3つの特徴を持っている。以下順に説明しよう。