全体像を見るために ~ インテグレートされた工場の作り方
前回、『最適解を組み合わせても、良い生産システムは作れない』というテーマの話を書いたら、知り合いの方から「専門じゃないので理解しにくいが、面白そうなので簡単にわかりやすく教えてほしいい」という主旨の質問をいただいた。その方は音楽好きなので、わたしはこうお答えした。
「例えば音楽にたとえてみます。合唱では、あるパートが最初から最後までずっと全力で歌ってもダメですよね。休むところは休み、手を抜くところは上手に手を抜く。それで全体としては、流れのある良い音楽になるのです。」
合唱では(オーケストラなどでも同じだと思うが)、すべてのパートが常に全力で歌っていたら、やかましくて音楽としては聞くに堪えない。「全力で」のところを、「ピアノ・フォルテの強弱はつけるが、一つひとつの音符にすべてきっちり気合いを込めて」にかえても、結果は似たり寄ったりであろう。やはり全体としては、力んだだけで陰影に乏しい演奏になる。強弱だけでなく、間合い、リズム、音程、音質など、すべてが各声部の間でちゃんと調和して、はじめて美しい音楽が生まれるのである。
だから、よく素人が錯覚するように、「才能ある上手な歌い手が集まれば、良い演奏ができる」という訳にはいかない。曲の全体像を見て、ここはソプラノが主役だから中声部は和声の支えに回るべし、とか、テナーがテーマの旋律を歌い始めたら女声は動きを目立たせるな、といった協力関係が必要になるのだ。こうした指示を与えるのが指揮者の役割なのである。指揮者の仕事とは、全体の中で部分を位置づけ、部分のできることを見て全体を構築していくことにある。これをインテグレーションの能力とよぶ。アンサンブルが小さければ、あるいは皆が知っている短い曲ならば、指揮者なしでもなんとか音楽をまとめることはできる。だが楽曲が大きくなり、メンバーが多くなると指揮者が必要になる。
ただ、ここで素人にはしばしば、第二の誤解が生まれる。それは、「全体の構想は指揮者だけが分かっていれば良い。あとの大勢は、指揮棒にしたがって動けば十分だ」という誤解である。誰かスーパーマン的なリーダーがいて、その指示と命令のもと、大きな組織が機敏に動く。これが組織の理想像だ、という思い込みは結構根強い。こうした組織の動かし方を、”Command
and Control”という。軍隊的な組織はその典型である。
しかし、こういうモデルは現実にはうまく機能しない。それは別にリーダーの能力不足のためではない。そもそも「指示と命令」型の組織では、“指示されない限り自分では何も動かない・考えない”タイプの人間が量産される傾向が強い。現場の末端が先を読んで行動しないので、問題はすべてリーダーが対処することになる。しかしリーダーが強烈であればあるほど、その周辺にはイエスマンばかりが集まり、都合の悪い情報は上がらなくなる。だから問題の数がある臨界値を超えてしまうと、組織は急激に機能不全に陥っていく。普段は良くても、大変なときに限ってぽっきり折れやすい、レジリエンシーの低い組織モデルなのだ。
だから実際には、組織の構成員が、皆ちゃんと全体を理解した上で、自分の役割を果たすべきだということになる。合唱のたとえに戻すと、一人一人が、楽曲全体の構造を分かった上で、自分のパートを歌うのが望ましい、ということになる。全体像を示し、各人に伝えるのは、指揮者の役目である。また逆に、歌い手側の中にも、全体像に対する独自の意見を持つ者がいるだろう。中には、指揮者が気がつかなかった提案だってあるかもしれない。だからそうした意見を聞くことも大事である。採用するかは、最終的には指揮者の判断になるだろうが。
こうした点を踏まえた上で、前回紹介した、典型的な(下手な)工場の作り方を見ると、「指揮者のいない演奏会」のような状態になっていることに気がつく。製造機械と、周辺設備と、建築の三つのパートが、全体像を見ないまま並行して進んでいく。だから途中で手戻りが多くなりがちだし、できた者に一貫性が欠けているため、見えない非効率の温床になりがちなのだ。
どうしてこういう仕事の進め方になるかというと、「工場という名の生産システム」の全体像を見て、それを最適化しようという視点が足りないからだ。工場を、システムではなく、「機械」と「周辺設備」と「建屋」の単なる集合体としてとらえている。各部分を別の部署で担当し、足し算の論理で作り上げようとしている。
では、より良い工場の作り方は、どうすすめられるのか? ここで、エンジニアリング会社が得意とする、石油や化学といったプロセス産業でのやり方を、参考までにご紹介しよう。それはこんな風に進む:
(0) まず、工場要件の概要から出発する。ここは前回紹介したディスクリート型工場とほぼ同様である。ただ海外企業の場合、ここに「デザイン・フィロソフィー」文書が加わることが多い
(1) 次に、プロセス設計部門のエンジニアが、工場全体の『プロセスシステム』の基本設計を行う
プロセスシステムの基本設計を担当する専門職を、「プロセス・エンジニア」とよぶ。この業界では世界共通の用語であり、わたしの勤務先にも100人単位で技術者がいる。このプロセスシステム設計は、もう少し詳しく言うと、二段階からなっている
(1-1) 工場内を流れる物質の流量バランス(物質収支)と熱エネルギー収支の最適化
(1-2) 制御方式の設計(測定点の決定と制御ロジックの決定)
さて、このようにシステム全体の機能と流れが確定すると、次にシステムの構成要素の設計に進む。
(2) 機械設計部門が、要素機器の詳細設計を進める
システムの機能構成と要素が決まったら、そのつながりにしたがって空間的配置を設計しなければならない。そこはさらに二段階に分かれる:
(3) 配管・建築・シビル設計の各部門が、空間設計を順に協力して進める(通常、3D-CADを利用する)
(3-1) まず、機械エンジニアが配管レイアウトの最適化を行う
(3-2) ついで、架構・建築・基礎設計などの構造設計が上物→基礎の順に行われる
そして、設計から具体的なものづくり段階へと進んでいく。
(4) 調達部門・工事管理部門が、資機材の調達と建設・試運転 を行う(時間的にはこの段階が一番長い)
おわかりだろうか。(0)?(4)まで、仕事は「要件→システム→構成要素→空間配置→調達→建設→試運転」という風に、一本の線として順に進む。そして、こうした全体の流れに齟齬がないよう、リサイクル・ワークが発生しないように管制塔の役割を果たす存在がいる。
(5) プロジェクト・マネジメント部門のプロマネとそのスタッフからなるチームが、全体の流れを統括する
管制塔機能とはすなわち、指揮者であり、インテグレーションの仕事である。プロマネ配下でプロジェクト・マネジメントに専門的に関わるチームを、Project
Management Team = PMTとよぶ。小さな工場案件では、プロマネが一人で面倒を見るケースもあるが、大規模案件では複数人が必要になるからだ。
前回紹介した工場づくりのワークフローとの最大の違いは、工場全体が「システム」であるという概念が存在すること、そして「プロジェクト・マネジメント」という管制塔機能が存在することである。
まあ、上で示した流れは、実際には1,000以上のWBSアクティビティからなる流れをかなり簡略化したもので、現実にはもっと複雑だし、リサイクル・ワークも発生しがちだ。だが、全体の流れを統括して、妙な手戻りは極力無くそうと最初から努力はしている。そのためにPMTのメンバーは、設計上しばしば発生する小さな変更が、他の設計・調達・建設を通じて、どのような影響を及ぼし、コスト・スケジュールでどれほどインパクトを生じるかを、つねに予測しながら判断を行う。
そして、このような流れは、わたしの勤務先だけではなく、世界的なプロセス産業全体での共通理解になっている。発注者側も、これを求めるし、これを実現するために、エンジニアリング会社という業種が存在する。そして、そこにはプロセス・エンジニアや、プロジェクト・マネジメントの専門家が多数いる。こうした人材を、工場のオーナー企業が雇っても、数年に一度しかないプラントの新設・拡張だけに従事させるのでは非効率だから、アウトソースするのだ。
もちろん、こういう仕組みだから、すべてのプロジェクトがうまくいく、などと言うつもりはない。我々も正直、手痛い失敗をいくつも経験している。ただ、プロジェクトにとって最大の失敗は、コスト超過でもスケジュール遅延でもない。使い物になる成果物が生み出せないことである。そして、少なくともプロセス産業では、「非効率で使い物にならない工場ができあがった」という失敗はない。全体システムの最適設計を最初に行うからだ。
こういう手順を踏むため、プロセスプラント系の工場の作り方は、必然的にウォーターフォール型になる。最初にとにかく、全体像を決める。今回は反応系、次は回収系、という風に、部分部分を計画しては継ぎ足していくようなやり方はできないのだ。プラント系のプロジェクトにアジャイル型が不向きなのは、決して実物の工事があるためではない。プラントが単なる機械装置の集合体ではなく、インテグレーションされた密結合のシステムだからだ。
わたしがこのところ、ずっと「仕組み」だとか「システムズ・アプローチ」だとかにしつこくこだわっているのも、結局のところ、わたしのキャリアの出発点がプロセス・エンジニアだったことに由来しているのかもしれない。わたしの入社した頃の仕事は、石油リファイナリーの工場全体を、線形計画法を使って最適化設計し、経済性評価する仕事だった。その後いろいろなキャリアの紆余曲折はあったが、どの分野の仕事でも「システムの全体像」にこだわり続けているのは、その影響なのだろう。
ただ、そうだとしても、これまでずっと専門分野を深掘りしてきた中堅エンジニアが、「全体像を見る」ためには、どうしたら良いだろうか? いまさら畑違いのプロセスシステム工学など、学んでいる暇もあるまい。
わたしがおすすめするのは、二種類の『見方の練習』である。最初の練習はまず、「上司の上司の立場になって仕事のあり方を考えてみる」ことである。自分の上司の立場を想像することは、それほど難しくない。居酒屋談義でサラリーマンが「俺が課長だったら・・」みたいなセリフを吐くシーンは、珍しくあるまいし、ある程度は正鵠を得ているものだ。だが上司の上司となると、難しい。あなたが主任だったら、課長ではなく、部長になったつもりで、仕事をどう変えるべきか、考えてみる。あなたが課長だったら、本部長の立場で、どう仕事の仕組みをつくるか、考える。これは簡単ではない。かなり視点を背伸びして、高い位置から関連する仕事の全体を見なければならないからだ。
そしてもう一つの練習は、「顧客の顧客の要求を考えてみる」である。自分の目の前の顧客の要求は、毎日接しているし、闘ったりもしているので、良く知っている(つもりになりやすい)。ところが、その顧客だって、じつはさらに顧客がいるのだ。そして彼らだって、顧客の要求に悩まされている。たとえばあなたが部品メーカーで、顧客はセットメーカーだとしよう。顧客はあなたに、つねに無理なコストダウンやJIT納品を要求してくる。
だが、その顧客だって、じつは流通側のチェーンストアや量販店から、めまぐるしい需要変動への対応を要求されているのかもしれない。だから、あなたは「顧客が要求して言ってくること」の背後に、顧客自身が悩んでいる「隠れたペイン」を見通すべきなのである。それはいいかえると、「サプライチェーンの中で、自社の位置を理解する」ことにも通じる。そういう視点を獲得できれば、あなたが日々直面している問題に対しても、別の見方、別の解決策が見えてくるかもしれない。たとえ見えてこなくても、感情的なフラストレーションは、少しは薄まるはずだ。相手を、同じ手足のついた人間として見ることが、相互リスペクトの第一歩ではないか。
こうした二種類の見方を、折に触れて練習してみること。これが「全体を見る」能力を育てるための方法だと、わたしは信じている。そうした能力は、今すぐには無用に見えても、長いキャリアの中では、きっと役立つときが来るはずなのだ。