ゲーム分析の勧めー迷惑人間の取扱説明書ー

12-2.【事例９】番外編

　さて、この【事例９】では、私の行動について、「こんな重要な判断を勝手に行っていいのか？　なぜ、本社や上司に連絡して、その指示を仰がないのか？」という疑問を持たれる方が、数多くいらっしゃると思います。

　実は、ここまでの事例についても、「ゲーム分析という人間関係ではなく、そもそも組織の問題ではないのか？」、「著者が所属していた会社の組織は一体どうなっているのか？」といった疑問を感じた方が多くいらっしゃると思います。

　そこで、少し回り道になりますが、ここで、当時の私のいた会社の、私が所属していた組織についてご説明したいと思います。

　すなわち、これはバーンのゲーム分析に移る前に番外編になります。このため、そういったことにご興味がない方は、この『12-2.【事例９】番外編』を飛ばしていただいて、次の『12-3.【事例９】「何でも言ってください」のゲーム』に進んでいただければ幸いです。

　では、当時の私のいた会社の、私が所属していた組織についてご説明をしていきたいと思います。

　私が、化学プラントの設計を行う仕事をしており、当時、私のいた会社では、化学プラントを設計する組織が、基本設計部隊と詳細設計部隊に分かれていたことは既に述べました。

　基本設計と詳細設計の両部隊には、ともに、機械、電気・計装（計装とは、プラントの制御システムのことです）、建築といった専門分野のエンジニアがいました。私や【事例４】でご紹介した西田さんは、基本設計部隊に所属する機械のエンジニアになります。

　そして、一つの案件を、複数のエンジニアがチームを組んで担当しますが、化学プラントの詳細設計の場合は機械設備の占める割合が大きいので、プラントをいくつかのエリアに分けて、それぞれに機械のエンジニアを配置することが普通でした。

　たとえば、ある案件の基本設計の場合、基本設計部隊で機械エンジニアのAさん、電気・計装エンジニアのBさん、建築エンジニアのCさんの計３名でチームを作り、Aさんが全体を統括するマネージャーを担当します。

　さらに、この案件が詳細設計に移行すると、詳細設計部隊の人たちが同様に設計を引き継ぎますが、前述の通り、機械設計の割合が大きいので、工程を二つに分けて、たとえば、工程１を担当する機械エンジニアのDさん、工程２を担当する機械エンジニアのEさん、全工程を担当する電気・計装エンジニアのFさんとその部下のGさん、全工程を担当する建築エンジニアのCさん（基本設計と兼務）の計５名でチームを作り、Dさんが全体を統括するマネージャーを担当するという具合です。

　難しい案件になると、基本設計部隊のAさんが統括マネージャーをしたり、今回のようなオブザーバーとして詳細設計に参加していました。

　この例ですと、基本設計から詳細設計まで、AさんからGさんまで、兼務を含めて、７名のエンジニアが、その案件の設計を担当することになります。

　ここで特徴的なことは、７名のエンジニアが各々独立して設計を行うということです。もちろん、必要な基本情報は共有します。例えば、基本設計では、Aさんが設計の基本情報（専門的で恐縮ですが・・物資収支、熱収支、基本配置図、フローシートなどです）を作成して、それを電気・計装エンジニアのBさん、建築エンジニアのCさんに連絡しますが、Aさんが、BさんやCさんの設計に関与することはありません。また、詳細設計ですと、工程１を担当する機械エンジニアのDさんが、工程２を担当する機械エンジニアのEさんの設計に口を出すことはしません。

　このように、７名のエンジニアは必要な情報は共有したり、相互に交換したりしますが、各々の設計には、口を出さないというルールがありました。

　言い換えると、AさんからGさんまで各々が、あたかも小さなエンジニアリング会社を経営していて（たとえば、Aエンジ会社、Bエンジ会社、・・・）、それぞれが会社と契約しているかのように、エンジニア個人個人の独立性が極めて強い組織になっていました。

　この独立性の強さは、上下関係も同様でした。たとえば、基本設計部隊の機械エンジニアであるAさんは、基本設計部隊の機械部長のXさんの部下ですが、X部長はたくさんいる部下の個人個人の設計に関与することは基本的にはありません。では、X部長は何をしているのかというと、発生した案件の担当を割り振ったり、部全体の受注額を管理したり、予算や人事管理を行ったりと、部全体のマネージング業務をしていました。

　このため、X部長は、部下のAさんがどのような設計をしているのかといった細かなことは、全く把握していませんでした。

　エンジニア個人個人の独立性が極めて強いと言えば聞こえはいいのですが、個人個人の設計内容は誰にもチェックされることはありませんので、各エンジニアは何か問題が発生しても、相談相手はおらず、自分で解決しなければならないといった問題が内在した組織だったのです。

　ここで、晶析装置の試運転を考えてみましょう。

　私が、鉄さび問題を報告するならば、上司のX部長になりますが、X部長は私が新型の晶析装置の設計を担当していることは知っていますが、その晶析装置がどのような設計で製作されたかといったことは全く知りません。このため、私が、試運転の途中で鉄さびが出たという報告をしても、何もアドバイスはできません。もっと言うと、「お前が担当なのだから何とかしろ」というだけで、鉄さび問題そのものに全く関心を示さなかったでしょう。

　私が、この問題を、本社や上司に報告しなかったのは、このような理由からです。

　実際、当時の私の上司は、試運転の過程で鉄さびが出たこと、これに対して本来責任を負う詳細設計部隊が逃げだしたこと、私が何とか解決したこと・・・こういった一連の出来事の存在自体を知りません。当然、これらが、私の業務査定に反映されることも一切無かった訳です。

　確かに、このように整理すると、組織としての健全性という意味では、当時は大いに問題があったと思います。

　しかし、どのような組織も何がしかの問題を抱えています。

　完璧な組織は無いという観点に立てば、その組織の不完全さによって生じる人願関係のストレスにどう対処するかということが重要になってきます。

　もとより、人間関係のストレスは、組織の不完全さだけが原因で生じるのではなく、実に様々な原因で発生します。

　本書は、組織論を論じるのではなく、こういった様々な原因で発生する人間関係のストレスをゲーム分析で解析し、解決策を提示しようという目的で書かれたものです。

　このため、組織論を論じてもいいような事例でも、それは行わず、あくまで、ゲーム分析の観点から解析を行ってきたのです。

　では、次にこの事例をゲーム分析で解析してみましょう。