ソフトウェアは、神の祝福であると同時に呪いでもある。最近、ビッグデータ、インダストリー4.0、完璧な予測アルゴリズムといったものに、皆が大々的に駆り立てられているのは、ソフトウェアなら私たちが分からないことを教えてくれるはずだという期待の表れです。つまり、不確かさへの恐怖を和らげて、組織の真に最適な経営を実現して最高の業績の達成しようという希望を取り戻そうとしているのです。
故ゴールドラット博士は、ソフトウェアの効果について2冊の本を書きました。彼は、遡ること1990年、膨大なデータに圧倒された我々に予想される損失を示したThe Haystack Syndrome（訳注：『ゴールドラット博士のコストに縛られるな! 利益を最大化するTOC意思決定プロセス』三本木亮 訳、ダイヤモンド社、2005年）という本を出版しました。彼は、「情報」とは訊ねられた質問に対する答えであると定義することで、答えを発見することの潜在的な価値を明確に示しました。ゴールドラット博士によれば、ソフトウェアの中核の害は、細部に捕らわれて全体を見失うことです（訳注：木を見て森を見ず）。
もう1冊は、2000年出版の博士と私Eli Schragenheim、Carol Ptak氏3人の共著、Necessary but Not Sufficient（訳注：『チェンジ・ザ・ルール！』三本木亮 訳、ダイヤモンド社、2002年）という本で、ERPの世界を詳しく調べて、どうやればユーザーが真の価値を得られるか明確に示す必要性を説いたものです。
ソフトウェアには、組織にとって明確な2つのメリットがあります。データベースの維持と素早い計算です。3つ目としてコミュニケーションの管理を挙げる人もいるでしょう。因みに、TOCの柱の一本にもなっているシンプルさとは、この場合、計算の背後にあるロジックがユーザーにとって明快で納得いくものになっていることです。ゴールドラット博士は、自分が80年代後半に開発したソフトウェアを「Disaster（大惨事）」と呼んで、ロジックを理解せずソフトウェアを使うユーザーに何が起こるか強く警告しました。
シンプルさを取るか高度さを取るかは、ソフトウェアの重大なジレンマです。シンプルさは、優れた意思決定と効果的な行動を通じて価値をもたらします。高度さは、主にソフトウェア開発者の（「我々はそれができる」という）能力の証しであり、複雑で不確かな環境でも最高のパフォーマンスを達成できるという希望を与えてくれるものです。 しかし、TOCは、組織を最適化する唯一の方法は、すべてのリソースが最適なパフォーマンスを発揮することだという現在の常識に異議を唱えています。TOCの主張は、（今だ満たされない顧客の潜在的なニーズみたいな）真に重要なものにフォーカスすれば、最適化では思いもよらないブレークスルーを達成できるというものです。
ソフトウェアには、間接的だが、もうひとつ重要な利点があります：
ソフトウェアは、ユーザーにその肝になるポリシーに準じた特定のプロセスを強制する！
どんなポリシーにも良い点と悪い点があるので、ソフトウェアのこの性質から、多くの個別的ジレンマが生じます。ですから、それを強制するソフトウェアが神の祝福か呪いかは、そのポリシーとその効果次第です。
通常、ソフトウェアベンダーは、ユーザーに非常に沢山の選択肢を与えて、自分の重要なパラメータに合わせてポリシーを選ばせることで、このジレンマを解消しています。それに対して、ゴールドラット博士は、人が犯し易い重大な過ちを最小に抑えるのに必死でした。彼の真に迫る表現があります：「我々はユーザーが自殺する手助けをしてはならない」 この恐怖から、ゴールドラット博士はユーザーが選べるポリシーの幅を狭めました。不確実性にうまく対処できる十分効果的なポリシーに拘るのが、TOCの哲学です。そこがまさにTOCのすべてのポリシーと具体的なソリューションの源です。
しかし、TOCのソリューションは、あり得るすべての状況を網羅できないので、一時的な逸脱が必要なときもあります。つまり、基本的なポリシーからある程度の逸脱を考えるのを許すか、ソフトウェアの指示を無視させるか、いずれかでユーザーにある程度選択を委ねる必要があるということです。とは言っても、そう滅多にその必要はないはずだし、どっち道ユーザーはすべての結果に責任を負わないといけません。
この最後の点を簡単に説明する例を一つ挙げておきます。あるSKUの目標在庫は1,000個で、今現在システム内に999個しか在庫がないとしましょう。あなたはたった1個分の補充指示を出しますか？ もし「それは場合に依る」というのがあなたの答えなら、あなたは一定の逸脱は必要だろうと認めるということです。ゴールドラット博士自身も、計画負荷（Planned-load）に基づいて補充指示を投入するという、やや手の込んだルールを提案しました。そうすると、常に最も弱いリンクが手空きにならない状態を保つために、時には補充指示を早目に投入することになり、それは投入を絞るというルールからの逸脱になります。
一般的には、どんなソフトウェアも、非常に異なる2つの基準に基づいて評価しなければなりません：
- 既存のものに比べてそのソフトウェアが生み出す正味の付加価値（純付加価値）。新しい技術の価値を評価する6つの質問は、まさにそのための強力なツールだ。
- そのソフトウェアが引き起こす潜在的な損失！
ソフトウェアが損失を与えるケースは下記の3つあります。
ソフトウェア自体の動作
- ユーザーを誤解させる、またはプログラムをクラッシュさせる不具合。
- 誤った手順や間違ったアルゴリズムを助長する。
- 選択肢が多過ぎてユーザーに間違った判断をさせる。
- 要注意：何も価値を生まない機能はどれも、実は混乱やミスで害を及ぼすだけだ。
ソフトウェアのモデリングとインストール
- これは、インストール時に沢山のクリティカルな選択やパラメータを正しくソフトウェアに設定しなければならない、ERP、CRMなど大規模なソフトウェアパッケージすべてに当てはまる。 DBR、SDBRまたはCCPMなどのTOCパッケージも、バッファサイズなど、ある程度パラメータのモデリングや修正が必要である。この段階で大きなミスを犯すと、甚大な損害を被る可能性がある!!!
ユーザーによるソフトウェアの誤使用
- これは、ソフトウェアで害を及ぼすケースで最も恐ろしいものだ。ソフトウェアとそれ固有のインストールが良くても、自分にロジックの理解が必要だとは思わないユーザーが、甚大な害を及ぼす可能性がある。
TOCのソフトウェアパッケージは、既存のERPやMRPにリンクしたアドイン・モジュールの形で使われるのが以前から多くありました。そのためのインターフェースがインストールを難しくしています。CCPMソフトウェアも、以前はMicrosoft Projectのアドインとしてよく使われましたが、新しいCCPMパッケージのいくつかはスタンドアロン・パッケージになっています。しかし、プロジェクトを管理するにも、発注や予算の管理のために、時にはERPとのインターフェースが必要になります。そのように異なるパッケージとの間の同期が必須な場合は、インストールでも難しい部分であるインターフェースの設定に特に大きな負担がかかります。
とにかく私が言いたいのは、どんなソフトウェアであれ、ユーザーにそのロジックと機能を完全に理解させる責任は我々にあるということです。役に立つだろう選択肢を制限すると大きな損失を被るかもしれません。まして完全にロジックを理解せずにユーザーがソフトウェアの指示を無視するのは、さらに危険です。
これは、TOCを推進するチャンピオンやコンサルタントは、新入社員が仕事を引き継ぐときに知識をどう保存するかを含めて、顧客が適正な知識レベルを維持することに責任を負わないといけないということです。ところが、どういうわけか、現在のS&Tテンプレートには、継続的なトレーニングを担保するに必要な教育活動が含まれていません。
私は、いつか将来、TOCの方法論をベースにした完璧なERPとビジネスインテリジェンス・ソフトウェアを是非とも見てみたい。そのカギを握る洞察は、ユーザーの直感に基づいたデータを厳密な数値解析と結合する必要があるということに違いありません。私は、TOC流の意思決定支援（DSTOC：Decision-Support in TOC Way）構想の中で、ずっとそういう努力をしてきたし、この洞察をソフトウェア業界全体に行き渡らせるべきだと思っています。
著者：エリ・シュラーゲンハイム
飽くなき挑戦心こそが私の人生をより興味深いものにしてくれます。私は組織が不確実性を無視しているのを見ると心配でたまりませんし、またそのようなリーダーに盲目的に従っている人々を理解することができません。
