代理店管理システムのPMOで学んだTOC（制約理論）と CCPM

1 日前
読了時間: 6分

「TOC的な事象」ってなんですか

保険会社の代理店管理システムのプロジェクトで、PMOをやっていたときの話です。業務部門とシステム部門を含むプロジェクト全体の進捗・課題・リスク・変更・予算を管理して、定期的にプロジェクトオーナーや役員が出席するステアリングコミッティに報告する、という仕事をしていました。

あるとき進捗が遅延していて、クライアントの偉い方と、当時の上司であるPMが原因について話をしていました。「進捗が遅延している理由は、いわゆるTOC的な事象が発生していますね」、上司がそう言っていたのを今でも覚えています。正直、その場では何を言っているのかさっぱり分からず、ぽかんとしていました。

後で上司に聞いたら、「TOC（制約理論）の考え方はゴールドラットの『ザ・ゴール』に書いてある。PMOをやるなら必須だから読んでおけ」と言われました。いや、アサインするときに教えてほしかった、と思いましたが。。。

TOC（制約理論）とは

『ザ・ゴール』はエリヤフ・ゴールドラットが書いた、小説仕立てのビジネス書です。もともとアメリカで出版されたのですが、日本では長らく翻訳版が出版されませんでした。理由は「これ以上日本企業の競争力が上がると困る」という警戒感があったからだとか。時代も変わるものです。

読んだ本

『ザ・ゴール』があまりにPMOの仕事に示唆を与えてくれたので、当時買ったKindleで関連書籍も読み進めました。

『ザ・ゴール2 ── 思考プロセス』
『クリティカルチェーン』
『チェンジ・ザ・ルール！』
『ザ・チョイス ── 複雑さに惑わされるな！』

正直に言うと、ちゃんと覚えているのは『ザ・ゴール』くらいです。それくらい最初の1冊が強烈でした。

TOC/CCPMから見たプロジェクト管理あるある

TOCを踏まえてプロジェクトを見ると、よくある問題がきれいに説明できます。

学生症候群（Student Syndrome）：余裕があると思うと、期限ギリギリになるまでタスクに本格着手しない。結果、予期せぬトラブルが後半に起きて結局遅れる。
パーキンソンの法則（Parkinson's Law）：「与えられた時間のすべてを使い切るまで仕事は膨張する」。予定より早く終わっても見直しや品質向上に時間を使ってしまい、早く終わった分が後続タスクに引き継がれない。
マルチタスクの弊害：複数のプロジェクトやタスクを並行して行うことで、思考の切り替えコスト（段取り替え）が発生し、すべてのタスクの完了がドミノ倒しのように遅れる。

これに対する解決策として体系化されたのがCCPM（クリティカルチェーン・プロジェクトマネジメント）で、コアとなる考え方は3つです。

各タスクの個別バッファを削って「プロジェクトバッファ」へ一括管理する
タスクの順序（依存関係）に加えてリソースも考慮したスケジュールで、クリティカルパスを明確にする
マルチタスクをやめる

整理すると、TOC（制約理論）は「問題の根本原因を特定する」ための思想・理論で、CCPMは「その原因を解決するための」具体的な実践手法、という関係になります。

プロジェクト事例：なぜ「人」が制約になったのか

実際に経験した保険代理店管理システムのプロジェクトの話です。

対象業務は、代理店の手数料計算（異動・解約による戻入等の複雑な再計算）や、代理店の評価・査定ロジックなど、それまでExcelなどのEUC（エンドユーザーコンピューティング）で属人的に回っていた業務のシステム化でした。

ここで少し寄り道して、なぜ保険会社の代理店管理業務では「人」が制約になりやすいのか、について書いておきます。契約管理システムのような基幹系と違って、代理店の手数料計算や査定ロジックは、中小・中堅の保険会社や、近年代理店チャネルに力を入れ始めた会社ほど、伝統的にシステム投資がされてきていません。異動・解約による戻入計算のような例外処理が多く、ルール自体が複雑かつ頻繁に変わるため、マニュアル化・文書化がされにくい。結果として、業務知識が特定の担当者の頭の中とExcelファイルに溜め込まれる「属人化」が起きやすい構造になっています。

このプロジェクトでも、まさにそれが起きていました。設計書をレビューできる人が、現行業務を回している実質2人しかいなかったんです。レビューが追いつかず、プロジェクトは遅延しました。

ボトルネックは開発チームでもPMでもなく、「現行の複雑な業務（異動・解約の戻入計算や査定ロジック）を理解し、設計書をレビューできる、たった2人の業務実務者」だったわけです。これがまさにTOCでいう「制約」でした。

対策として、以下を行いました。

スコープの削減（優先度の高い業務から順にシステム化）
新スコープに沿ったスケジュールへの変更（期限は会社的にマストだったので、そこは動かさない）
レビューできる担当者のリソースを確保し、それに合わせて全体スケジュールを作成
依存関係を含めた全体WBSの作成
3週間のプロジェクトバッファをねん出し、一括管理

全体2年のプロジェクトのうち、残り1年でこの3週間のバッファをうまく取り崩しながら、当初予定していたスケジュール通りにすべての開発・テスト・リリースを終えることができました。

業務側の担当者も本当に頑張ってくれて、管掌役員にかけあって通常業務をできる限り外してもらい、開発ベンダーには詳細なレビュー日程を出させて、担当者のOutlookの予定にレビュー時間をブロックし、すぐ埋まってしまう会議室も先に押さえて、実際にその場に張り付いてレビューが進んでいるかを見張る、というところまでやっていました。

このケースは特殊な話ではなく、代理店の手数料計算や評価・査定に関するシステムは、中小・中堅の保険会社や、近年代理店チャネルに力を入れ始めた会社では、契約管理システムほど投資されてこなかったため、属人的な手作業が残っているケースが結構あるようです。

業務に精通したレビュー担当者のリソース確保と、それに合わせたWBS作成がTOC（制約）への対応、3週間のプロジェクトバッファの捻出とその一括管理がCCPMの効いた部分だったと思います。

まとめ

昔のプロジェクトを思い出しながらまとめてみました。ゴールドラットの本を夜中に読みながら、慣れないTOCやCCPMを理解して、リプラン内容をステコミに報告する準備をするのは正直しんどくて、毎日終電に揺られながら資料を作っていました。当時はつらかったですが、今振り返ると懐かしいです。

PMOはコンサル案件の中では軽く見られがちですが、構想しても実行されなければ意味がないので、常駐して現場に寄り添いながら進める支援は、個人的にはとても好きな仕事です。プロジェクトを進めていると課題は尽きないので、ディスカッションペーパーを大量にアウトプットする機会もあり、コンサルの「お作法」を学ぶにはとても良い機会だと思います。

余談：最近TOCコンサルって聞かなくなった

最近、TOCコンサルってあまり聞かなくなったなと思って、GoogleやSNS（X/Facebookなど）で検索してみたのですが、出てくるのは少し古い記事ばかり（自分がコンサルを始めた2010年代より前に創業した会社のサイトなど）でした。もしかしたら私が知らないだけで今も盛り上がっているのかもしれませんが、せっかくなので今回は昔の思い出を振り返って記事にしてみました。