事例で理解するTOC：構造のズレを見える化した現場の記録

（5600字・30分程度、お時間のある時にでも）

これは、TOC（制約理論）の要素が垣間見える、架空の現場のお話です。
とはいえ、理論を称賛したいわけでも、結論を押しつけたいわけでもありません。
現場で交わされる何気ない言葉やグチの中に、もし構造を見直すきっかけがあるとしたら──。
そんな思いで、ひとつの物語として描いてみました。

第1章　はじめに ―「なぜかうまくいかない」あの感じ

私たちの職場では、日々いろいろな改善の工夫がなされている。業務の手順を見直したり、チェックリストを導入したり、会議の頻度や内容を調整してみたり。どれも、そのときには一定の効果が見えた。実際、ちょっとした手戻りが減ったり、作業スピードが上がったりすることもあった。

けれど、時間が経つにつれて、また同じようなトラブルが繰り返されるようになる。

「どうして、またこうなるんだろう？」

最初は、誰かの確認ミスかと思った。あるいは、連携が悪かったのかもしれない。だが、注意していてもミスは起きるし、関係者が集まって情報を共有しても、なぜか最終的に現場が混乱することがある。

それは、「やるべきことがやれていない」という感覚ではなかった。むしろ、皆それぞれの持ち場で一生懸命やっている。でも、結果として全体が噛み合っていない。

そうしたことが何度か続くと、次第に「誰が悪い」という話よりも、「何かが根本的にずれているんじゃないか？」という疑問が頭をもたげてくる。

当時の私は、そんな違和感を強く感じていた。

それでも、それが何なのかはっきりとはわからなかった。ただひとつ思っていたのは、このモヤモヤはきっと、自分だけが感じているものではないはずだ、ということだった。

第2章　グチから始まった「気づきの芽」

ある日の昼休み、隣の部署の同僚と休憩スペースで顔を合わせた。 何気なく、「最近、またトラブル続いてるんだよね」とこぼしたところ、 「あー、うちもだよ。なんか、いつも似たような感じで巻き込まれてる」と返ってきた。

それは、ごく普通のグチのやりとりだった。でも、どこかで共通点のようなものを感じた。

「お互いそれなりにやってるのに、なんかうまくいかないんだよね」 「そうそう、設計が決まってないのに、現場が先に動かされることとかさ」 「うちは逆に、現場からの変更が来て、図面が何度も書き直しになるんだよ」

話していくうちに、それぞれの立場で“困っていること”が実はつながっているんじゃないか、という感覚が生まれてきた。

この段階では、まだ原因も、構造も、ましてやTOCの「クラウド図」なんて発想もなかった。ただ、「自分の部署の問題」だと思っていたものが、相手の部署にもつながっているらしいということが、ぼんやりと見えてきた。

そして、その“見えかけている何か”を逃したくなくて、「もう少しちゃんと話してみようか」と声をかけた。これは、正式な会議ではなく、ただの延長戦のような立ち話の続きだった。

だがこのとき、すでに「構造を見る」という行動が、静かに始まっていたのかもしれない。

第3章　一人の仮説が、もう一人の視点で形を持ち始める

あらためて椅子に座って向き合ってみると、思っていた以上にお互いが見えていなかったことに気づいた。

「設計が間に合わないから、早く現場を動かせって言われるんだけど、そのせいで手戻りが起きて余計に遅れるんだよね」 「現場としては、工程を止めると損失が出るし、とにかく動けって空気がある。設計が詰まってないのは分かってるけど、もう進めるしかないって感じで……」

少しずつ、それぞれの「譲れない理由」が見えてきた。どちらも間違っているわけではない。でも、それが結果として衝突している。

「これ、どっちかが間違ってるんじゃなくて、そもそも両方が正しいことをやろうとしてぶつかってるんじゃないかな？」

そのとき、私たちの頭に浮かんだのは、対立というより“板挟み”の構図だった。

この段階でようやく、頭の中で何となくイメージしていたものを紙に書いてみることにした。

• 設計部門：品質を確保するために、設計が固まるまで現場を動かしたくない
• 現場側：納期厳守と工程維持のために、設計が未完でも先に進めざるを得ない

それぞれに“正当な理由”があり、それがぶつかる。

そして、ぶつかっているのは「目的」ではなく「手段」だった。

このとき私たちは、まだTOCのクラウド図という言葉を知らなかった。 でも、描きかけた構図はまさにそれに近く、そこには確かに“問題の正体”のようなものが見え始めていた。

第4章　構造の“気配”が見えはじめた

翌日から、私たちは少しずつ周囲の人に声をかけてみることにした。 あくまで雑談の延長として、「この前、こんな話しててさ…」と軽く切り出す。

意外なほど反応は早かった。 「それ、うちのチームでも似たようなこと起きてるよ」 「なんか、設計と現場ってずっとそんな感じだよね」 「上からは“なんとかしろ”って言われるだけで、結局こっちで帳尻合わせてる」

そうした一言一言が、私たちの見えていた構造に少しずつ肉付けをしてくれた。

誰かが「手戻りが多い」と言えば、その背景に何があるのかを聞く。 「そもそも指示が曖昧で…」「調整の時間が取れなくて…」

話す相手が増えるごとに、断片的だった“構造”がより具体的になっていく。

当初は、設計と現場の２者間の話だと思っていたけれど、実際にはもっと多くの立場の人がこの問題に関わっていた。 たとえば資材調達部門は「発注を急がされるけど、仕様が確定しないから困っている」と言う。 現場監督は「工程会議では設計側の事情は話されない」と言う。

ひとつの部門の論理だけでは、見えてこないものがある。 それぞれが“自分の役割”として真面目に仕事をしているからこそ、逆に全体の構造が見えづらくなっているのだ。

私たちは、少しずつ確信を持ちはじめていた。 この問題は、誰か一人の努力や調整で解決するものではない。 構造そのものを、見える形にしない限り、また同じことが起こるだろう。

そう考えたとき、自然と次の行動が見えてきた。 「これ、ちゃんと図にしてみないか？」

問題の正体を、目に見える形で共有できるようにすること。 その一歩が、次のフェーズの始まりだった。

第5章　図にしてみる ―「クラウド図」らしきものができた

最初は、A4用紙の真ん中に「現場が混乱する」と書いた。 そこから、「なぜそうなるのか？」を問いかけながら、思いつく要因を左右に並べていった。

「設計が固まらないうちに現場が動くから？」 「でも、設計完了を待っていたら、工期に間に合わないからでは？」

そんな言葉の応酬が、グチから徐々に構造的なやり取りへと変わっていった。

ある日、こんな会話が交わされた。 「設計の見直しがあるたびに、現場の作業は一時停止。現場で段取りをやり直すだけで、丸1日潰れるんだよ」 「それ、うちも苦しいんだけどさ、発注者からの仕様変更が多くて。正直、最終図面を確定させられないんだ」 「じゃあ現場はどうすればいいの？ 完成間際にまた設計が変わったら、工程に間に合わないよ」

このとき、誰かがぽつりと漏らした。 「設計が完了してから着工するのが理想だけど、それだと間に合わない。じゃあ、どこで線を引けばいいんだろうね」

この会話をもとに、私たちは紙に次のような構図を書き出していった：

• 設計側の主張（D）：「設計が完了してから着工すべき」
• 現場側の主張（D’）：「設計が未完でも着工を始めるべき」

それぞれの背景には、強い“理由”があった。

• 設計側の前提（B）：「手戻りが発生すれば、品質が保てず、結果的に納期にも響く」
• 現場側の前提（C）：「工期が守れなければ、信頼を失い、次の仕事にも響く」

そこから導き出される目的はこうだった：

• Bの目的：「設計品質の確保」
• Cの目的：「工程の遵守」

そして、最終的に両者が目指している上位目的（A）は、単なる「成功」ではなく、 「決められた工期内に、品質と手戻りリスクをコントロールしながら完成させる」ことだった。

ただ、そのときに一つの問いが浮かんだ。 「設計が終わるのを待たないと現場は動けないのか？」

そこから議論は、新しい方向に動き始めた。 「いや、設計って、全部が一斉に決まるわけじゃないよな」 「そう。構造形式とか、建物の大きさとか、基本的な部分は比較的早く固まる」 「だったら、その“決まってる部分”を先に使えないか？」

このやり取りは、単なる発想の転換だった。 だが、現場にとっては非常に現実的なヒントだった。

「たとえば仮設配置や段取り、資材手配などは、構造の概略が見えればある程度できる」 「最後に詳細設計が確定したときに、準備済みの状態からすぐに動き出せば、リードタイムは短くなる」

つまり、設計と施工は「切断」されたフェーズではなく、 “重ねて進める”ことが可能な領域がある、ということに気づいたのだった。

この瞬間、私たちが見ていた図に、別の線が引かれたような気がした。 クラウド図は「対立」を整理するためのものだったが、 この気づきは、その対立に「打開の余地がある」ことを示してくれた。

それまで私たちは、「設計完了の有無」という白黒の発想で話をしていた。 でも実際には、設計は段階的に進み、その途中経過にも活用価値がある。

そのことに気づいた瞬間、対立の構造は“妥協”ではなく、“工夫による解決”へと変わったのだった。

クラウド図によって問題が整理されたことで、 現実的な打開策が浮かび上がったのである。

そして、これこそが「構造を見える化することの価値」なのだと、私たちは実感していた。

この構造的なズレが、納期遅延や手戻り、再工程など、あらゆる無駄を生んでいた。 つまり、設計と施工の衝突は、単なる意見の違いではなく、 **全体のスループットを確実に低下させる“見えにくい制約”**だったのだ。

第6章　後から知ったTOCという考え方

数日後、偶然見かけたある資料で「TOC（制約理論）」という言葉に出会った。

読み進めていくと、そこには、私たちが紙に書いていた構図とそっくりな図が紹介されていた。

それは「クラウド図」と呼ばれるもので、 相反する2つの行動（DとD’）が、それぞれ異なる目的（BとC）を達成しようとする中で、 共通の上位目的（A）に向かっているという構造だった。

「まさにこれだ」と思った。

それは、理論を学んだというよりも、自分たちのやっていたことに名前がついた瞬間だった。

“感覚としてやっていたこと”が、“理論として整理されていた”というだけで、 なんだか自分たちの取り組みに確信が持てたような気がした。

クラウド図は、問題の本質を「対立」ではなく「目的のずれ」として捉える。

私たちが直感的にやっていた「構造を見る」ということは、まさにその第一歩だったのだ。

理論の言葉はあとから知った。だが、それがあったからこそ、 私たちの気づきが「気まぐれな偶然」ではなく「再現可能な思考」だとわかった。

第7章　部分最適の先にある“全体を観る”という発想

現場の工夫、業務の見直し、チェックリストの作成、会議体の改善。 私たちはこれまでに、数えきれないほどの“努力”を積み重ねてきた。

それは決して無駄だったわけではない。 小さな改善の一つひとつが、確かに目の前の課題を少しずつよくしてきた。

ただ、そこには限界もあった。

たとえば、設計側が図面の品質を上げようと詳細化を進めれば進めるほど、 現場では時間を失い、工程に影響が出る。 逆に、現場が早期に着工しようとすれば、設計は十分な精査を行えなくなる。

どちらも「その場では正しい」。けれど、それらがぶつかることで全体としての非効率が生まれていた。

そのとき私たちはようやく、“部分最適”という言葉の意味を実感として理解した。

各部門は、それぞれの目標を持ち、それぞれの正義を背負って動いている。 しかし、組織全体としての目的を見据えたとき、 それらの正義がときに衝突し、足を引っ張り合う構造をつくってしまうことがある。

TOCは、その構造を「見える化」するための思考の枠組みを与えてくれた。

誰かが悪いわけではない。 誰かが間違っているわけでもない。

ただ、“全体としてどうなっているか”という視点が抜け落ちているだけなのだ。

この視点を持てたとき、はじめて私たちは「努力の向け先」を変えることができるようになる。

努力を責めるのではなく、構造を疑ってみること。 それこそが、本当の意味で“改善”を進めるための出発点なのだと気づいた。

第8章　おわりに ― 対話から始まる“静かな改革”

ふり返ってみれば、最初のきっかけはただの雑談だった。 「最近、また現場が混乱しててさ」

そこにあったのは、問題を解決しようという強い意志でも、改革を成し遂げようという使命感でもない。ただ、「何かおかしい」「このままでいいのか」という、ほんの小さな違和感だった。

それでも、その違和感を誰かに話してみたことで、少しずつ景色が変わり始めた。

形式張った会議ではなく、立ち話のような自由な場で、グチのような言葉の中から共感が生まれた。 共感が対話を呼び、対話が構造の発見につながった。

気づけば、TOCという理論にたどり着いていた。

だが重要なのは、理論を知っていたことではない。 「構造に目を向ける」という発想が、自分たちの手の届くところにあったということだ。

今すぐ何かを大きく変えられなくても、誰かを説得できなくても、 私たちは知っている。 「ズレているのは人ではなく、構造かもしれない」という問いを持つだけで、見える世界が変わることを。

TOCは、声を上げることなく始まる。 現場の中で、静かに、確かに、“気づき”として芽を出す。

そしてその気づきは、いつか“静かな改革”へとつながっていく。