どんな変化（変革）にも、どれほど大きな利益・恩恵があると言われようが、何か悪いことが起きそうな不安が付きものです。といって、その不安は簡単に解消するのか、得られる利益に比べたら取るに足らないのか、証明しようにも実用的な方法が無い場合が余りにも多い。想像すらできない未知への不安もあります。しかも、その価値をゴール（目標）への金額的な貢献に翻訳するのは難しいのが普通です。
概念実証（POC：Proof-of-concept）という言葉は、コンセプト（考え方、概念）が実際に役に立ち有効なものである論理的な証拠を与えることの一般的な表現です。理論的には、優れた未来ツリー（FRT：Future-Reality-Tree）があれば、その証拠を示せるはずですが、不安をすべて消すには不十分だと思います。特に未知への不安はそれでは消えません。
コンセプトの正しさを証明するもっとロバストな方法はシミュレーションです。ただし、その背後にある仮定が、そのコンセプトを導入しようとしている環境で本当に正しいかについては最大限の注意が必要です。それに、他人が開発したコンピュータ・シミュレーションにどんな前提条件があるか確認するのは簡単ではありません。慎重にチェックしないといけない種類の前提条件のひとつは不確実性に対する挙動です。もう1つ重要な面は、そのシミュレーションに盛り込まれていない現実の現象を見つけることです。たとえば、ほとんどのシミュレーションは、パーキンソンの法則のような人間の振る舞いを考慮していません。
ということで、やはり一番ロバストな概念実証法は実証実験です。しかし、実証実験（Pilot：パイロット）は、何が本当の価値か理解を深めてもらえるもので、且つ、悪い副作用とその影響を暴露して、それを除去または軽減するチャンスを与えるものでなければなりません。
実証実験では相当もめ事が起きます。ですので、通常のプロジェクトに比べて、必要以上に経営幹部の注力（マネージメント・アテンション）が割かれます。実証実験の目的はあくまでコンセプトの実証です。ということは、実証実験のプランニング段階で一番最初にすべき仕事は、そもそも実証したいコンセプトは何か、また、不確実性がどれくらい軽減するかの見積もりを含め、実験で得られるメリットを明確にすることだ、ということです。
たとえば、CCPMのコンセプトを実証するための実験対象プロジェクトを選ぶ場合を考えてみましょう。CCPMの狙いは、もし可能なら見積もりより早く、納期内にプロジェクトを終えることです。このCCPMのコンセプトには、計画段階では、クリティカルチェーン工程の作成、タスク期間のカット、バッファの挿入（主にプロジェクトバッファ）が含まれます。一方、実行段階では、組織でただ一つの優先順位づけの仕掛けとしてバッファ管理を使うことが重要な知見です。したがって、特定のプロジェクトを選ぶ際は、選んだプロジェクトに特別に注意が払われ、単に恣意的に良い結果が報告されて、納期が守れている可能性もあるという懸念にちゃんと対処しないといけません。
とにかく、実証実験は、提案のコンセプトは著しく大きな価値を生むのは確かだが、大きなダメージを与える可能性もあるという強い確信がない限り、やってはいけないということを理解しておくのが大事です。
適切な実証実験を設計する上で重要な点は次のとおりです：
- 提案のコンセプトを完全実施することで被る潜在的なダメージを大幅に軽減できる。
- 完全実施したときの価値について信頼できる情報を提供する。
- 貴重なマネージメント・アテンションを大きく消費しない。
- 実証実験への投資が必要以上に大きくない。
- 組織全体でもめ事が少ない。つまり、組織全体として日常のマネジメントとパフォーマンスへの影響はそれほど大きくない。
実証実験を計画することに対する助言：
実験終了後にそのコンセプトを完全実施するか否か決定するための、評価指標と意思決定ルールを事前に決めておきなさい。
そういう重大な意思決定で事前に評価指標とルールを決めておかないと、意思決定そのものが行われない可能性が高く、そもそもその実験をするに至った価値の確信と悪影響の懸念の対立状態が解消されずに、永久に悩み続けないといけなくなる恐れがあります。
TOC導入の実証実験を検討する上で役に立つ重要な事例は、流通チェーンの事例です。地理的に広大な領域、沢山の地域倉庫、膨大な数の小売業者、それらをすべてカバーする完全なインプリメンテーションの規模は、今までのルールを捨てて、TOCの動的ソリューションに変えるという意思決定を非常に難しいものにします。そういう状況で経営者と幹部管理者にありそうな懸念の一部を挙げておきましょう：
- アベイラビリティが向上しても、売上の大幅な増加に繋がらない。
- たとえば、常に顧客には無いものに代わる妥当な選択肢があるから。
- あるいは、品薄なものは売れ筋ではないから。
- 結局在庫が減らず、キャッシュ・フローへの悪影響は相変わらずで、今よりもっと増えるのではないか。
- 輸送コストが高くなる。
- 非常に小さなバッチの沢山のSKU（品物）も一緒にトラックに積むと、また別の問題が発生する。
- 新しいソフトウェアの扱いに慣れて、それを何か所ものサイトに導入するには長い時間がかかるので、日々のマネジメントに問題が生じて、組織のパフォーマンスが低下する。
といういうことで、アベイラビリティの劇的な向上と在庫の大幅削減という決定的な競争力が獲得できるという、気前のいい約束に期待しつつも、上記のような懸念があって、少数の試験プロジェクトを選んだ実証実験を選ばざるを得なくなります。
そういう実証実験はどうやるのがよいのか？
いくつか選択肢があります：
- まず中央倉庫にソリューションを導入することから始めて、地域倉庫が合流するのを待つ。
- 3つ4つの地域倉庫に絞る。
- 売れ行きの良いものと悪いもの両方を含んだ1つの製品ファミリーを選定して、中央倉庫からいくつかの、あるいはすべての地域倉庫に至るルートをカバーする。
何が優れた実証実験の特性なのかという問題は、TOCの導入で最重要な未解決問題の1つです。私は、次回のTOCICOカンファレンスの期間中に、TOCICOがTOCの著名な専門家を何人か招集して、是非この問題を公開で議論して欲しいと思います。
ここで私は、上記の流通における実証実験の選択肢について、自分の意見を述べておきたい。
TOCの補充ソリューションが本当に有効かどうかは、流通チェーン全体に渡って明確な優先順位に従った安定で柔軟なフローを維持できるか否かにかかっています。可能な限り素早くかつ多頻度な補充を維持するには、サプライヤーとの関係を慎重に見直さなければなりません。様々異なるサプライヤーの数の問題は、膨大な数の小規模小売業者への対応の難しさに勝るとも劣らず非常に難しい。サプライヤーと小売業者の隅々まで着実にインプリメントを浸透させられるかどうかは、導入計画全体の成否を握る重要な部分です。
実証実験の結果で失望させるわけにはいきません。中央倉庫だけの実証実験だと、チェーンの末端のプロセスに至らないうちに反証が現れます。地域倉庫は、担当する地域のサプライチェーンの視野で大きなバッチで注文してくるのは変わらないので、中央倉庫は高い水準の在庫を抱えざるを得なくなります。それでは、結果に失望されて、導入自体あっけなく打ち切りになるでしょう。
一方、いくつかの地域倉庫に絞ると、悪い副作用が2つ生じます。 ひとつは、中央倉庫が地域倉庫への短時間かつ信頼性の高い補充を保証できない限り、地域倉庫のアベイラビリティは疑わしくなり、やはり失望されることです。もう一つは、実証実験の対象になった地域倉庫が特別な扱いを要求してそう扱われるだろうことです。実証実験は良い結果が出るでしょうが、より厳しい条件で我慢しないといけないその他すべてから、非常に大きな抵抗が生じるでしょう。
ですから、私なら、ひとつの製品ファミリーを選んで、中央倉庫とすべての地域倉庫を入れ、その製品について実証実験を実行します。特に別の組織が小売店を運営する場合、実証実験の一員に小売店まで含める差し迫った理由があるとは、私は思いません。この実証実験の成果は、極めて高いアベイラビリティを保証しながら、中央倉庫と地域倉庫を合わせた全体の在庫が多少とも削減されることです。小売店がバッチで注文してくるのは変わりませんが、小売の数が多いお陰で、バッチが大きい悪影響が随分緩和されるのです（訳注：在庫を上流に集約したことで、末端の変動が統計的に均されること）。大部分のトラックが実証実験の対象でない品物も一緒に運ぶとしても、この経験で、輸送コストとトラックの積載量に及ぶ実際の影響がどうなるかの理解が深まるはずです。
私は、この記事が、TOCの様々なアプリケーションにおける実証実験の実行計画に潜む問題の提起になるだろうと期待しています。
著者：エリ・シュラーゲンハイム
飽くなき挑戦心こそが私の人生をより興味深いものにしてくれます。私は組織が不確実性を無視しているのを見ると心配でたまりませんし、またそのようなリーダーに盲目的に従っている人々を理解することができません。
