人気ブログランキング |

<   2020年 01月 ( 4 )   > この月の画像一覧

エンジニアリング・チェーンのマネジメントと、生産技術というボトルネック


エンジニアリングという仕事は基本的に、毎回毎回のプロダクトがすべてユニークであり、個別的な一過性の仕事です。それが創造的であればあるほど、「標準化とカイゼン」からなるPDCAアプローチが、とりにくくなります。そういう個別的な仕事をマネージするとは、業務を「予見(計画)可能にし」、「再利用可能(繰返し可能)にする」、の2つの事から成り立ちます。以下、具体的にご説明しましょう。

(1) まず、業務の全体像を予見できるようにすること

個別的な業務を予見可能にするとは、どういう意味でしょうか。『個別性の罠』にとらわれないためには、ユニークな業務であっても、その行き先をある程度、予測できるようにすることが必要です。かつ、望ましい形に進むよう、計らう必要があります。

それは端的に、その業務がいつぐらいまでかかり、どれくらいの費用を要し、どんな工数を必要とするのかを、つかむことです。そのためには、業務のボリュームや作業の構成を考え、全体の工期・工数・コストなどを、見積もる能力をつける訳です。そして、それに応じた体制や予算、人のアサインなどを決めていきます。つまり、計画していくということです。業務を「計画可能にする」といってもいいでしょう。これによって、いわば野放しの「野獣」を、通常の仕事の体制や予算の中に、取り込めるようにしていきます。

(2) 次に、その業務を繰り返し可能にすること

次にすべきは、個別性・一過性の業務の結果を、繰り返し(再利用)可能にすることです。仕事の成果物を出し終えたら、ほっとして一息つき、それから一件書類をどこかの机かサーバのフォルダにしまって、あとは忘れてしまう。次に似たような仕事が来たら、「えーと、前にやったあの仕事はどうだっけ」とファイルをひっくり返して探す・・こういう状態では、再利用可能とは言えません。

とくに設計に関わる仕事の場合、結果としての仕様書や図面だけでは再現するのに不十分です。「なぜこういう形になったのか」が分かるよう、検討の方針や前提条件、そして途中の計算書なども、合わせて保存される方が望ましいことは、皆さんご承知のとおりです。ですが、この部分がしばしば、ないがしろにされがちです。

もちろんできるなら、ちゃんと一件書類としての保存のフォーマットと必要なコンテンツのリストを決め、インデックスをつけて、マスターファイルに保存すべきでしょう。設計の成果物だけでなく、どれくらいの期間と工数がかかったのか、体制や担当者は誰だったのかといった、業務のパフォーマンス面でのデータも必要です。

このようなところまで持ち込めば、標準化に繋げられるようになります。いったん業務を標準化できれば、PDCAとカイゼン文化に接続できるのです。つまり、野獣だったものを「家畜」にできる訳です。

エンジニアリング・チェーンのマネジメントと、生産技術というボトルネック_e0058447_18404412.jpg

ところで、初めてチャレンジする一過性の仕事なんて、本当に「計画」できるのか、という疑問があるかもしれません。当たって砕けろ、まずは走り始めてみて、それから必要に応じて考えたらいいじゃないか。それが現場力というものだ、という考えもけっこう、強いと思います。

製造業は中期経営計画があり、年間や半期の予算計画があり、月度の生産計画やら販売計画やらがあって、という風に「計画づくし」ですが、こうした計画類はある種、サイクリックなルーチンワークです。ルーチンにはまらないものが出てくると、突然、計画立案の手を止めてしまう。あるいは思考停止になる。そして、現場力という名の「出たとこ勝負」に走ってしまう。

これは計画という仕事のプロセスや手順を、よく知らないから起きるのです。一過性の仕事の計画立案というは、次のような6つのステップを踏んで進めるべきものです。


0 何をなすべき仕事なのかを明確にする。ゴールは何か。目的・目標は何か。そして制約条件は何か。これを言葉にします。

1 次に、それを実現するために必要な要素作業(Activity)をすべて洗い出し、構造化・リスト化します。重複も、洩れもないように。

2 それぞれの要素作業(Activity)を誰がやるべきかを考え、体制図を決めます。

3 要素作業(Activity)の順序と、必要な期間を考え、タイムテーブルをつくります。

4 必要な期間と作業量から費用を求め、収支の予算を作ります。

5 リスク・アセスメントを行い、必要な事前対策を講じます(つまり、必要ならば1〜5に戻って計画を修正するということです)。

ここで大事なことは、作業(『要素作業』=Activity)を思考の中心に置くことです。製造の世界はモノを中心に考えがちです。そしてモノの構成と物量は、成果物の部品表(BOM)に従う、ということになります。しかしエンジニアリング・チェーンの仕事においては、まだ肝心の成果物の設計ができておらず、部品表(BOM)だって固まっていないのです。

ただし、エンジニアリングという仕事の特徴は、成果物が異なっても、作業のプロセスと構造はかなり共通している点にあります。必ず商品企画から始まり、製品基本設計→製品詳細設計→工程・設備設計→ライン設置→生産準備、という流れで動きます。この順序が逆になることは普通、ありえません。ここが計画化のカギになります。

各作業はさらに、サブ作業からなり、その内部の順番もあるでしょう。たとえば設備設計は機械設計・制御設計・電気設計・構造設計といったサブ作業からなり、機械の制御方式が決まらなければ電気は決まらないし、機械の重量や応力が決まらなければ指示構造設計もできません。

こうした要素作業の構成と順序関係は、設計の対象物が異なっても、変わりません。個別に変わるのは、作業量(工数)です。

そこで、上のステップ1で要素作業(Activity)を洗い出す際に、その作業の工数を左右する代表的なメトリクスを、あわせて推測します。構成機器数だとか、制御のI/O点数だとかいったものです。もちろん初期の段階ですから、ラフカットな推測に過ぎませんが、工数がわかれば、あとは投入するリソース(人員数)と生産性から、期間が分かり、費用も推算できます。これが計画のベースになるのです。

そしてステップ1から5まで進めることで、個別業務について、成果物一覧・作業リスト・体制図・スケジュール(工程表)・コスト集計表・リスク登録簿などが整備されることになります。

ステップ1のベースとなるのは、設計対象の構成と数量に関する、ざっくりとした推定です。代表的なアイテムについてのメトリクスがある程度、の精度のものです。これを「計画用BOM」と呼ぶこともあります。そしてステップ1の結果として得られる作業リストとは、すなわちエンジニアリングの「BOP = Bill of Processes」に他なりません。

そして、ここあげた計画の手順は、まさにプロジェクト・マネジメント計画書をつくる手順そのものです。プロジェクトの定義とは、「ゴールのある、個別的・一過性の仕事で、かつ失敗のリスクを伴うもの」ですから、エンジニアリング・チェーンの中の業務とは、プロジェクトそのものなのです。

ただし、以前も指摘したとおり、現在のPM標準には、調達論や品質論があるのに、肝心の設計論がありません。設計論のないPM標準では、エンジニアリング・チェーンをつなぐマネジメントは、うまくハンドリングできない点が問題だと感じています。

ところで、多くの企業がエンジニアリング・チェーンのマネジメントに悩む、もう一つの理由について、述べておきたいと思います。それは、人の問題です。

チェーンは鎖であり、鎖の強さとは、一番弱い輪で決まる、とはよく言われることです。それでは、今日の日本の製造業における、一番弱い輪とは、どこでしょうか? 

それは、生産技術の部分にある、とわたしは考えています。製造業の生産技術部門が、どこも人材的に弱体化しているのです。10年前に比べて、半分以下になっている、という指摘をする人さえあります。生産技術部門は、工程・設備設計から生産準備までを担う部門です。そして製造部品表(M-BOM)のお守り役でもあります。そこが弱体化し、エンジニアリング・チェーンのボトルネックになっている。

証拠もあります。これはやや古い調査ですが、日本機械工業連合会による「グローバルに対応する生産技術者の確保・育成に関する調査研究」(2012/03)から引用した図です。それによると、生産技術者が「不足している・どちらかというと不足している」と答えた企業は、合計で

・質的な面:    92%
・人員の量的な面: 83%

となっています。つまり、人数的にも、そして能力的にも、生産技術者が全く足りていない、という事実を示しています。
エンジニアリング・チェーンのマネジメントと、生産技術というボトルネック_e0058447_18464818.jpg
なぜこのような事態になったのでしょうか? 以下は推測ですが、やはり2008年のリーマン・ショックが一つのきっかけだったのではないかと考えます。この時、企業はかなり人減らしを行いました。ただ人員削減といっても、直接ライン部門を動かしている、製造や生産管理はなかなか切れません。また、新製品の開発を行う製品設計の部門は、優秀な人材を温存しておきたかった。

そこで、スタッフ的な業務が中心となる生産技術者を切っていくことになった、と想像しています。事実、わたしはその頃、国内メーカーでの職を失い、しかたなくアジアの新興国に行き、そこの企業で新しい製造ラインづくりや工場づくりに携わっているベテラン技術者の人を、何人も知っています。

また、仮にリストラにはあわなかったとしても、本社から海外に赴任して帰ってこない、という人も多いと思われます。海外工場展開を盛んに行っている企業では、新工場の立ち上げに生産技術者を派遣しいます。しかし、熟練工を集めにくい海外では、新工場はなかなか簡単に立ち上がりません。かくて2〜3ヶ月のつもりで出かけ、いつのまにか半年から1年2年も帰ってこられなくなる例が、多かったのではないでしょうか。

そうした中、突如、AI/IoTブームが来て、「我が社もなにかスマート工場化の取り組みをしたい」と急に経営層が思いついても、(あるいは人手不足が深刻化して「我が社もロボットを入れて自動化をしたい」と考えても、という場合もあると思いますが)、生産ラインを増強できる肝心の生産技術者が足りない、という事態が出現します。

この問題を解決するにはどうしたら良いでしょうか。首にした人々を呼び戻す? あいにく、話はそう簡単ではないと思います。また、いったん人数が半分以下になり弱体化した部門を、元の姿まで強化するのは、そう手早くできる事ではありますまい。

わたしは、生産技術部門の仕事、とくに生産設備設計から導入までの、ボリュームの大きな業務(かつ、時期的には波の大きな業務)を、自前主義からアウトソーシングに変えていくべきだと考えています。そして、アウトソースの受け皿となる業界、すなわち『工場エンジニアリング業界』(ないしラインビルダー業界)を育てるべきだと考えています。そして、ベテラン技術者の人たちが日本で再活躍できる場を提供するのです。

わたしが勤務先の業務のかたわら、(財)エンジニアリング協会で「次世代スマート工場のエンジニアリング研究会」なる活動を進めているのも、このような問題意識を持ってのことです。

エンジニアリング・チェーンをマネージする事は、地味な上に、なかなか単純ではありません。しかし、日本の製造業が再び力を得て羽ばたくために、少しでも皆さんと知恵を共有したいと考えて、こうしたお話をさせていただいている次第です。

(なお、講演におけるBOMやPLM関連の話題の部分は割愛しています。それについては、別の機会にまたご紹介できればと思います)


<関連エントリ>
 →「PMにはなぜ設計論がないのか?」 (2019-11-21)
 →「エンジニアリング・チェーンをゆるがす『個別性の罠』とは」 (2020-01-19)




by Tomoichi_Sato | 2020-01-26 22:36 | ビジネス | Comments(0)

エンジニアリング・チェーンをゆるがす『個別性の罠』とは

前回の記事「エンジニアリングとは統合力(インテグレーション能力)である」(2020-01-12)では、エンジニアリングが複数の設計技術要素を束ねるすり合わせ型の仕事であり、そこでは設計変更(チェンジ・コントロール)が重要な機能となる、と書いた。では、もう少し具体的に、それはどのような仕事で、そういう課題があるのか。

これについて、昨年11月に、わたしは名古屋でダッソー・システムズエスツーアイ社共催のセミナーで、「BOM/部品表とエンジニアリング・チェーンのマネジメント」という講演をした。名古屋を中心とする東海地方は、日本の製造業のメッカである。そこから大手・中小の来聴者がおいでになり、一応好評だったと伺っている。そこで今回は、その講演の中から、とくにエンジニアリング・チェーンに関係するトピックの部分を取り出して、紙上講演録の形で(多少アレンジしつつも)再現し、お届けしようかと思う。

***

皆さん、こんにちは。ただ今ご紹介にあずかりました、日揮ホールディングス(株)の佐藤知一です。

本日は「BOM/部品表とエンジニアリング・チェーンのマネジメント」というタイトルでお話をする訳ですが、エンジニアリング・チェーンとは、製造業における、設計業務を中心とした業務連鎖を指す言葉です。商品企画から始まり、製品設計、工程・設備設計、ライン設置、生産準備を経て、生産までをつなぐ、技術系の縦軸を指します。

製造業で設計技術に関わるエンジニアは、多くの方が、このチェーン(業務連鎖)に関わっていると言っていいでしょう。ものづくりに携わるエンジニアの、仕事の価値も悩みも、このチェーンがきちんとつながって、機能的に動いているかどうかに、かかっています。きちんと業務同士がつながり、かみあっていれば、設計の仕事も生産性高く進みますし、その価値も認められやすいでしょう。逆に鎖の輪がバラバラで、からんでいたり切れたりしていたら、仕事はやり直しと徒労が多くなり、その能力も正当に評価されない、という事態が生じかねません。

ですから、このエンジニアリング・チェーンの構造と機能をきちんと理解し、的確にマネジメントしてくれる管理職がいるかどうかで、設計技術者の働きがいも、大きく変わると言っていいでしょう。

ちなみに今、エンジニアリング・チェーンを「技術系の縦軸」といったのは、製造業には『サプライチェーン』(供給連鎖)という名の、大きな横軸があるからです。サプライチェーンとはいうまでもなく、最上流の原材料からはじまって、素材メーカー、サプライヤーからの調達、そして自社内での生産・物流、さらに流通業者を経て最終顧客におさめるまでの、業務の連鎖をこう呼びます。

サプライチェーンは自社を中心として、上流側と下流側に分かれます。APICS/SCORの用語・概念にしたがえば、上流側をマネージする仕事をSource、自社の生産をMake、そして下流側をマネージする仕事をDeliverと呼ぶことになっています。あるいは、上流側を「インバウンド・サプライチェーン」、下流側を「アウトバウンド・サプライチェーン」と呼ぶことも行われます。

サプライチェーンは、モノの動きの連鎖でもあります。ですから、これが切れると、製造業の売上と利益が止まってしまいます。いわばライン業務の中心です。なので、これが一日たりとも、切れたり止まったりしないよう、どの企業も細心の注意を払っています。

エンジニアリング・チェーンという概念は、これに対して、一種のスタッフ的業務の連鎖と呼ぶこともできます。これは、新しい製品の生産や、既存の製品・工程の改良に伴う仕事だからです。とくに、繰返し生産の業種では、注文が途絶えない限り、エンジニアリング・チェーンが一日、いや一月止まっても、あまり利益に影響は出ません。大手から図面をもらって加工するだけの、下請けの中小製造業には、エンジニアリング・チェーンが存在しない会社すら多いのが現実でしょう。
エンジニアリング・チェーンをゆるがす『個別性の罠』とは_e0058447_14011082.jpg

ついでの話ですが、「エンジニアリング・チェーン」という用語は、和製英語ではないかと最近疑っております。たとえば、ガートナー社の用語集にもAPICS Dictionaryにも、英語版Wikipediaにも、そのままの形では出てこないのです(ためしにネットを英語のみに限って検索すると、いろいろと別のものが引っかかってきて、それはそれで面白いですが)。欧州系のITベンダーの資料にはときおり出てくるのですが、肝心の米国では、少なくともあまりポピュラーな用語ではないようです。

代わりに、海外では、PLM(Product Lifecycle Management)という領域が、製品設計の流れをカバーしていると考えられています。もっともPLMは、生産後の保守・廃棄までをカバーする、かなり広い領域の概念ですが。

ともあれ、製造業において、エンジニアリング・チェーン(設計系の業務連鎖)のマネジメントが、サプライチェーン・マネジメントと並んで重要であることに、変わりはありません。では、どちらがより難しいのでしょうか。

サプライチェーンのマネジメントの特徴は、基本的に複数企業にまたがっていることにあります。また、サプライチェーンはモノの流れが中心にあるため、それを構成する各機能(調達・生産・物流など)の連鎖が、モノの「在庫」で分断されがちになります。その結果、下流側の変動が上流側で増幅される「ブルウィップ現象」(→Wikipedia)などが生じ、全体のマネジメントが働きにくくなる問題があります。

他方、エンジニアリング・チェーンを構成する鎖の要素は、原則的にすべて、自社内の機能です。また、情報のやり取りが中心であって、「在庫」による分断は、基本的にないはずですね。だからサプライチェーンよりはずっと、マネージしやすいはずでしょう。

・・にもかかわらず、現実には、エンジニアリング・チェーンのマネジメントに悩む企業が多いようです。そこには大きく、2つの理由が関わっていると考えられます。

まず第一に、設計業務は個別性が高い、という事をあげましょう。

設計とは、つねに個別の、一度限りの行為です。エンジニアは、全く同じ設計図面を、繰り返し2枚も3枚も作成したりはしませんね。全く同じなら、設計し直す必要がないからです。必ず違う部分があるから、図面を作り直す訳です。作るのが図面ではなく、仕様書でも、プログラムのソースコードだろうと、同じです。全く同じなら再利用すればいいので、作り直すはずがありません。

逆に言うと、前と少しでも違えば、設計図面や仕様書を作り直す必要がある訳です。かりに、違っている箇所がほんのわずかだったとしたら、他の部分は古い設計図書からのコピー&ペーストになります。そして、エンジニアリングにおいて、まるっきり新規の設計というのは、そんなに多くないのが事実です。

ということは、設計に携わるエンジニアの仕事の多くの部分は、
(1) 古い図面を探す
(2) コピペする
(3) その一部を修正する(そして他の部分との整合性をチェックする)
という『コピペ作業』に費やされている、ということになりませんか?

そうした「コピペ・エンジニアリング」の作業は、その企業が以前からの設計情報の蓄積をもっていればいるほど、比率が増えていきます。まっさらの新規企業なら、以前の設計図面なんかないから、毎回が「新鮮なチャレンジ」になるのです(もちろん、その分、設計ミスのリスクも大きい訳ですが)。

「コピペ・エンジニアリング」の煩雑な、生産性の低い作業をどうするかは、それ自体、重要な問題です。しかし、その話は後回しにし、ここでは、設計という仕事は全て個別性の中にある、という点を注視したいと思っています。

個別性の高い業務をマネジメントするとは、具体的にどういう意味なのか。ここが実は、よく理解されていない点に、日本の製造業の抱える問題が隠されているのではないか。わたしはこれを、『個別性の罠』という言葉で呼んでみたいと思います。

製造業の方に、「マネジメントとはどういう仕事ですか?」とたずねると、「マネジメントとはPDCAサイクルを回すことだ」という答えが、よくかえってきます。継続的改善こそ、マネジメント・システムの中核にある、と。これはかなり広く共有された認識のようです。そして「標準なければカイゼンなし」の標語が示すように、標準の存在が前提となっています。

だとすると、個別性の高い、一度限りの仕事は、どのようにPDCAサイクルに乗せるのでしょうか? なるほど、既存の設計の98%を受け継ぎ、2%だけを改良するような仕事ばかりなら、たしかに見通しはつけやすく、PDCAも論じられるでしょう。しかし、技術進化の激しいこの時代にあって、そういう繰返し的設計だけしていたら、あっという間に競争から取り残されてしまうはずです。

ゼロベースからの設計のように、個別性の高い仕事。それをどう、業務の中に位置づけ、マネジメントするか。そこがよく認識されていないことが、問題の本質にありそうです。

たとえていえば、個別性の高い仕事は、農耕民にとっての野獣・害獣のようなものかもしれません。時どき襲ってきて、秩序ある畑を荒らす。取り押さえられれば、貴重な栄養源になるけれど、野放しになりがちである、と。

では、個別性・一過性の業務をマネージするとは、どういう意味なのか。それは、2つのことから成り立っています。業務を「予見(計画)可能にする」という事と、「再利用可能(繰返し可能)にする」という事の2つです。

(この項続く)


<関連エントリ>


by Tomoichi_Sato | 2020-01-19 22:48 | ビジネス | Comments(0)

エンジニアリングとは統合力(インテグレーション能力)である

「エンジニアリング」という言葉を聞くと、読者諸賢はどのような仕事を想起されるだろうか。都会的なオフィスで遂行する、理知的な設計とデザインの仕事? それとも製図板と作業着とノギスをともなう、泥臭い仕事? あるいは企画と要求仕様だけを与えて、どこか海の外でやってもらう設計の力仕事?

エンジニアリング会社』と呼ばれる職場で、もう30年以上も働いている。会社には、机と椅子とPCと、あとは人が並んでいるだけだ。自社の工場は持っていない。建設現場はあるが、建設労働者を雇っているわけでもない。資機材は世界中の製造業の会社に頼んで作ってもらい、物流業の会社に頼んで現場まで運んでもらう。据付け組立工事は、現地の工事業者にお願いしてやってもらう。

じゃ自分たちは何をやっているかというと、設計図や仕様書を書いて、あとはプロジェクト全体をマネジメントしている。だから従業員は全員がホワイトカラーで、それも8割以上がエンジニア職種だ。

わたしの属するエンジニアリング業界には、国内で「専業」と呼ばれる大手が3社あるが、どこもほぼ同じような業態である。もっとも、国内には「エンジニアリング」と名前のつく企業が、大小様々に存在するし、分野もいろいろだ。わたしの勤務先は、「プラント・エンジニアリング」と呼ばれることも多い。ただしプラントばかりを作っているわけではなく、各種工場から病院まで、いろいろな施設を作っているので、『総合エンジニアリング』を自称している(が、たしかに売上の8割はプラント系である)。

こうした(プラント)エンジニアリング会社は、顧客にプラントや工場を作っておさめるのが仕事だ。なお日本では「プラント」と「工場」は別のものを指す(と思われている)が、英語で工場長はPlant Manangerであり、自動車工場はCar manufacturing plantである。だから両者を無理に区別する意義は、あまりない。

エンジニアリング会社とは、実は製造業やエネルギー産業の、生産技術部門(とくに工務部門)が独立してアウトソーシング先となった業態である。生産技術とは、製品設計と製造をつなぐ、「工程設計」「生産設備設置」を担う仕事だ。

こういう職務は、仕事量に波がある。増産と新工場設置のときは忙しく、定常運転に入ると暇になる。だから社内に抱えるより、アウトソーシング先として独立したほうが、お互い便利である。わたしの勤務先はたまたま、最初から独立したエンジ会社だったが、ライバル企業たちは、石油会社や化学会社の工務を担う子会社として出発した。

この業界では、工場づくりのプロジェクトを「EPC」と略称することが多い。EPCはエンジニアリング(Engineering)・調達(Procurement)・建設(Construction)の頭文字である。だが、先ほど書いたように、PとCの実作業は、外部の企業に発注するのが原則だ。自分で手を動かしてやっているのはE(エンジニアリング)のみである。だからまあ、「エンジニアリング会社」と呼ぶのかもしれぬ。

で、そのエンジニアリングというのは、冒頭に書いたようにカッコいい仕事なのか、泥臭い仕事なのか? 実は、エンジニアリングの日常というのは、次のような事の起きる日々である・・

***

<ある日の、機械設計部門にて>

「大変です。例のリアクター機器ですが、発注先のメーカーから、外形サイズが大きくなるって連絡が来ました。」
「どれくらい?」
「全体で、xxくらい増えるらしい、と。」
「いまさら勘弁してよ。もう配管設計部門に、ノズルの位置情報を渡して、設計をはじめてもらっているぜ。手戻りになるじゃないか!」
「そうですね。」
「それだけじゃなくて、機器の近くのパイプラック自体にも、位置的に影響するかもしれないな。ぎりぎりのレイアウトだから。なんでそんなにサイズが変わったの?」
「保温のためのジャケットの条件に変更が出たんです。顧客の要望で、上流側のプロセス設計部門から連絡がありました。それをメーカーに伝えたら、サイズに影響が出ますと返事が来たんです。」
「まずいな。それだと費用の追加請求も言ってくるぞ。納期にも影響が出るかもしれない。配管設計部門と調達部門と、一緒に相談したほうがいい。」

<その日の午後、配管設計部門の会議卓コーナーで>

「これだけサイズが増えると、機器周りの配管ルートをかなり変える必要がありますね。配管長も増えるし、コストアップになります。ラックとの距離を元のままにして、機器全体の位置をずらせないんですか?」
「逆側のメンテナンス用アクセスにも制限があって、もう壁からギリギリなんです。」
「調達の立場から言うと、このメーカーとの過去の経験から見て、確実に追加を言って来るね。まあウチが変更指示を出したんだから仕方ないけど。」
「納期は?」
「そっちの方が心配です。メーカーの側に余分な材料の在庫がなくて、サブオーダー(注:発注先の機械メーカーから、資材メーカーに手配をかけること)を出すとなると、2〜3ヶ月かかる可能性ありかも。」
「そんなに遅れたら、建設の機器搬入スケジュールに間に合わなくなるな。」
「納期もありますが、もう一つ。これ、機器全体の重量も増えますよね。そうすると、基礎にも影響するかもしれません。」
「げげ。建設現場ではもう、コンクリート基礎の工事が始まっちゃているぜ。どうしようか?」
「対案は2,3考えられますが、影響範囲が広いから、ぼくらだけでは決められません。エンジニアリング・マネージャーを呼びましょう。」

<翌朝、プロジェクト・ルームの会議室にて>

「・・皆さん忙しい中、緊急に集まってもらってすまない。例のリアクター機器No. KK-ZZZのサイズ変更への対応を、すぐに決めたい。まず、現状の位置のままサイズが増えた場合のインパクトを、各部から言ってほしい。下流側から行こうか。まず建設と調達から。」
「3ヶ月も納期が延びたら、建設の搬入据付けスケジュールがひっくり返ります。あの機器を据え付けないと着手できない後続工事がみんな遅れます。プロジェクト全体の納期に影響がありえます。」
「調達として心配なのはコストアップですね。あのメーカーはこういうチャンスに、必ず余計に上乗せして要求してきますから。」
「じゃあ設計側にいって、配管の影響は?」
「サブパイプラックが近くにあるので、干渉を避けるためには配管ルートを迂回する必要があります。」
「そうなると調節弁の位置も変わるね。計装のケーブルルートも見直さなけりゃ。」
「重量増による構造設計へのインパクトは?」
「今の程度の重量増なら、コンクリート基礎への影響は限定的です。幸い余裕は見ていました。」
「助かった。さすが。」
「ただ搬入のためのスペースが増えるので、架構の柱スパンに引っかかります。工事がそこだけ遅れます。」
「うーむ、そうか。とにかく、影響度合いは分った。対案は3つ。今の機器位置のままでいくか、場所を強引にずらすか、それとも入口の上流側の温度条件を変えて、リアクターのジャケットサイズがあまり増えないようにするか。」
「どれも簡単じゃないですが。」
「うん。でも、とにかく各案のPros/Consを表にまとめて書き出そう。その上で、コストと納期に一番インパクトが少なそうなものを選んで、決めることにする。」

***

まあ、これはいくつかの事実をもとに作ったフィクションである。まるで1日で決着するように書いたが、現実はもっと時間が掛かるし、こんなにカッコよくはない(笑)。ただ、肝要なポイントはおさえたつもりだ:

(1) エンジニアリングには複数の専門技術分野がかかわっている
(2) エンジニアリング・マネージャーという職種がいて、設計分野間の調整と意思決定をする
(3) エンジニアリングには基本設計→詳細設計という流れがあり、その一部は外部組織(発注先のメーカーなど)が担っている
(4) エンジニアリングの意思決定は、設計の品質や効率や整合性だけでなく、調達から実装までの全体を見て判断すべきである
(5) エンジニアリングにおいては、外部からの変更・変動への対応が、不可避である

エンジニアリングとは、基本デザインから実装までをカバーする仕事である。広義のエンジニアリングは、基本設計や要件定義に始まり、資機材やツールの調達、実装・設置工事・建設、そして試運転といった領域までの業務を含む。つまり発明・アイデアを現実化するまでの、トータルな仕事をさす言葉として、使われる。もう少し狭義には、基本デザインをインプットとして、それを実装可能なレベルにまで詳細設計する仕事を指す。その場合にも、様々な分野の工学的な要素技術を組み合わせて使うことになる。

エンジニアリングとは統合力(インテグレーション能力)である_e0058447_15401504.jpg
そしてエンジニアリングという業務の中心にあるのは、統合=インテグレーションである。

複数の機能要素を組み合わせて、全体として有機的な働きを実現するような仕事を、インテグレーション(統合)と呼ぶ。『有機的』というのは、目的意識があって、要素間のつながりやシナジーがあり、かつ環境の変化に柔軟に対応できる、というほどの意味である。目的意識もなく、環境変化に対応もできないような、要素の単なる寄せ集めを見て、わたし達は「有機的」と考えたりはしない。

そして、設計における統合力を担う職務を、「エンジニアリング・マネジメント」と呼ぶ。それはオーケストラの指揮者のように、一種の専門職である。交響楽団には、弦楽器だとか管楽器だとか、様々な専門の演奏職種がある。それらをまとめて、作曲家の提示した楽譜(=基本デザイン)に従い、現実化する。

楽譜に指揮者の「解釈」の余地があるように、実装にはいろいろな自由度がある。加えて、実際には完璧なデザインはありえないし、実装段階でのヘマをリカバーしなければならない場合もあるし(汗)、何よりも演奏会場と違って、エンジニアリングの場は外部環境に対して開かれている。顧客要求も市場環境も法規制も変化する中で、適応していかなければならない。

したがって、エンジニアリングにおいては、チェンジ・コントロール(変更管理)が重要である。設計とは実は、チェンジの積み上げである。むしろチェンジこそ本質である、といってもいい。設計の全体性をなるべく保ったまま、環境変化・条件変化に対して『適応制御』することが、エンジニアリング・マネジメントであろう。

マネジメントであるからには、設計のジャッジも必要に応じて担うことになる。そのためには、先読みとリスクテーク、そして何が良い成果であるかについての評価の価値観を持たなければならない。それも、部分的尺度ではなく、全体を見通した判断が必要である。

それを可能にするのは、設計プロセスと成果物に対する、「システム」としての見方である。変更の範囲と因果関係の予測ができないと、良い判断はできない。また外部機能→内部構造という階層性の理解、そしてV字モデルに従った詳細化と検証テストのコントロールが要求される。

ただ上の例に示したように、それはエンジニアリング・マネージャーだけが、一人で頑張って実現できるものではない。むしろ、協調的な働き方ができる組織力が望まれる。互いに独立し並行して進んでいるが、共通の着地点を目指すような、「すりあわせ」的な働き方である。ちょうどオーケストラの楽団員のように。そして変化を予見しながら、最小限の余裕を見越して設計できるスキルが望まれる。

エンジニアリング・マネージャーという職種は、わたし達の業界では普通の存在だが、分野によっては違うかもしれない。「エンジニアリング」という言葉の指し示す内容について、念のため最近、ゼネコン業界、工作機械メーカー、電子業界、IT業界などの知人にたずねてみたが、たしかにかなりの幅がある。それでも共通していたのは、「複数の設計技術要素を束ねる仕事」だという点だった。やはりエンジニアリングでは、統合力が、問われるのである。


<関連エントリ>
(2017-04-09)


(2019-11-21)




by Tomoichi_Sato | 2020-01-12 15:48 | プロジェクト・マネジメント | Comments(0)

次世代スマート工場の市場可能性に関する調査報告会のお知らせ(1月23日)

明けましておめでとうございます。今年はじめての講演発表のお知らせです。

一昨年より、一般財団法人エンジニアリング協会の中で、「次世代スマート工場のエンジニアリング研究会」を組織し、活動をはじめました。今回はその研究会が中心となって、JETRO(日本貿易振興機構)から受託した調査事業の、成果報告会という形になっています。わたしも報告者の一員としてお話いたします。

ご承知の通り、現在の日本の製造業における工場スマート化の試みは数多くあります。しかし、全体が大きな動きとなって前に進んでいる、とまでは言えません。たしかに機械設備にセンサーを付けてIoTデータを収集したり、AIの機械学習ツールで分析・故障予知などをする取り組みは、あちこちで行われています。ですが、その多くは実証実験(PoC)止まりのようです。

スマート化により工場全体のレベルで劇的なパフォーマンス向上を達成したとか、新しい発想で管理の仕組み・レイアウト自体まで変えた工場を作ったという事例は、それほど聞きません。そもそも、「スマート工場」とは何か、という概念レベルでの共通認識も、えられていないのが現状です。

わたしたちの「次世代スマート工場のエンジニアリング」研究会は、この現状を打破するため、大きく3つの柱をたてて活動を進めています。1つ目は、事例調査を内外で広く行い、優れた取り組みについて学び共有すること。2番目は技術開発で、工場全体レベルでのスマート化(知能化)を実現するために必要な、「中央管制システム」の概念設計を進めること。3つ目は、スマート工場実現への最大のボトルネックとなっている、人材教育のためのプログラムを考えることです。そして全体をまとめるために、新しい『次世代スマート工場』の概念モデル確立を目指します。

この目的のために、慶応大学管理工学科の松川弘明教授(現・日本経営工学会長)を研究会の主査に迎え、日揮・平田機工・野村総研から幹事を出して、運営しています。

たまたま昨年夏、JETROからインフラシステム輸出に向けた現地調査・情報普及事業の公募がありました。当研究会では上記事例調査の一環として、(財)エンジニアリング協会を中心に、日揮・日立製作所・竹中工務店・横河電機・SUBARU・平田機工・野村総研といった企業メンバーが協力し、「新しい輸出産業としての次世代スマート工場エンジニアリングの現地調査他事業」のテーマで応募・受託することができました。

この調査事業では、日本企業が得意とする、すり合わせ型のインテグレーション技術をコアに、次世代スマート工場のエンジニアリングを、新しい輸出産業として育てる可能性を探ります。具体的な調査フィールドとしては、タイを選びました。タイは東南アジアの製造業の一大集積地であり、自動車産業を始め日本企業も多く進出しています。加えて、国家戦略として「タイランド4.0」をかかげ、労働集約型産業からの脱皮に取り組んでいます。

本調査ではさらに、日本の潜在的なライバルとしてのドイツにも目を向け、彼の地におけるIndustry 4.0の最新動向と工場づくりのプロセスについて、情報収集と分析を行いました。その結果、巷間で言われるイメージとは異なる実相も、分かってきました。

今回の報告会はJETRO受託事業の一環として、一般向けに無償で公開されるものです。調査の結果を受けてわたし達が立てた、次世代スマート工場の市場開拓のための仮説について、皆様の忌憚ないご意見をいただき、その議論を成果報告書に盛り込むつもりです。

報告会は下記の要領で開催します。スマート工場に関心のある大勢の方のご来聴をお待ちしております。


日時:1月23日(木)10:00〜12:00
場所:一般財団法人エンジニアリング協会 会議室
   〒105-0001 東京都港区虎ノ門3-18-19 (虎ノ門マリンビル10階)
参加申込:下記URLをご参照ください


日揮ホールディングス(株) 
Chief Strategic Analyst 佐藤知一


by Tomoichi_Sato | 2020-01-05 11:36 | 工場計画論 | Comments(0)