タイム・コンサルタントの日誌から

冬ごもり読書のための、お薦め3冊：「ファスト＆スロー」「わたしの名は紅」「ウィトゲンシュタインのウィーン」

クリスマスと年末年始のシーズンを迎えたが、現下の情勢からGo Toキャンペーンも中止となり、「冬ごもり」休暇を過ごそうと考えている方も多いと思う。そんな方のために、静かな季節にふさわしく読みごたえのある、かつ、ちょっと知的でペダンティックな（笑）3冊をご紹介したい。冬の夜に書を紐解き、思索を楽しむ時間を持つのも、たまには悪くない経験かもしれない。

「ファスト＆スロー」　ダニエル・カーネマン著

「ファスト＆スロー（上）」 (Amazon)

「ファスト＆スロー（下）」 (Amazon)

何年か前、プライベートでフランスに旅行し、昔つかえていたボスに再会した（ほんの短い期間だが、仏企業に駐在して働いていたことがあるのだ）。その時、彼が、最近読んでいて面白い本、と紹介してくれたのが、この”Thinking, Fast and Slow”の原書だった。仏訳も出ていたのだろうが、彼は英語のまま読んでいた。日本に帰って、わたしも早速、翻訳を買い求めた。ただ例によって「積ん読」にしたままだったので、読み終えたのはずっと後になったが。

著者のダニエル・カーネマンは、心理学者だ。だが、彼は2002年にノーベル経済学賞を受賞する。対象の業績は、「プロスペクト理論」を中心とした、人間の意思決定に関する実験的研究で、いわゆる『行動経済学』を確立した立役者の一人である。

本書はそのカーネマンが、はじめて一般読者向けに書いた入門書である。「ファスト」と「スロー」とは、人間が思考する際に示す、二つのモードを表している。彼はこれを『システム１』（速い思考）と『システム２』（遅い思考）と呼ぶ。システム１は直感的・反射的で、単純な連想に従って動く。システム２はより論理的だが、起動にはメンタルなコストがかかり、怠け者である。

この二つのシステムがどのように発動し、どのように絡み合って、人間の思考や感情を支配するか、というテーマだけでも興味深い。本書には、それを調べるための、巧妙な心理学的実験がたくさん紹介されている。わたしはこの本を読んで、はじめて心理学者という人種の方法論や関心事が、少し分かったような気がした。

しかし著者カーネマンが、早く亡くなった共同研究者エイモス・トベルスキーとともに探求したのは、この二つの思考のシステムが、「リスク」や「財貨」や「不確実な環境」においてどう意思決定に影響するかであった。ここから、心理学は経済学とドラマチックに交錯して行く。新古典派経済学では、人間は経済合理的にふるまう、という前提から出発する。だが本当に人間の判断は「合理的」なのか？

たとえば、ワイン好きの経済学者R教授は、$35以上のワインはめったに買わなかった。逆に売ってくれと言われたときは、$100以上だったら渋々売った。しかし、あるワインが教授にとって$50の価値あるのなら、$60で売ってくれと頼まれたら売るべきだし、$40で売っていたら買うべきだ。R教授にとって、$35のワインは、自分が保有すると$100以上の価値になるらしい。これを「保有効果」と呼ぶ（下巻第27章）。

もう一例。「ある女性が$80の芝居のチケットを2枚買いました。ところが劇場についてバッグを開けるとチケットがありません。この女性はチケットを買い直すでしょうか？」（下巻第34章）

経済学における埋没原価の原理からいえば、買い直すのが正しい答えだ。だが、多くの人が、答えに迷う。ちなみにカーネマンは、「もし同額の現金をなくしたのだとしたら、あなたはチケットを買い直しますか？」との質問と比較する。後者の場合、大抵の人が「買い直すべき」と答える。だったら、最初の問にもYesと答えるべきなのだ。

「プロスペクト理論」では、人間の利得と損失に対する心理的な評価は非対称で、現状から何かを得る可能性よりも、失う可能性のほうが大きく感じられる、という事を実験的に証明している。そしてシステム2は、確率的・統計的な判断がじつは苦手なのだ。ところが、現代のビジネス上の意思決定は、多くがリスク確率や期待値などをベースに行われる（とくに金融の世界では）。それがいかに危険なことか、わかるだろう。

しかし本書の良いところは、問題提起だけでなく、２つのシステムの弱点や意思決定バイアスの罠を避けるための、実際的な方法についても、いろいろとアドバイスに満ちていることだ。だから、ビジネスとリスクと意思決定に関わる人は、本書を是非勉強すべきなのである。村井章子氏による翻訳も読みやすい。

　　

「わたしの名は紅」　オルハン・パムク著

「わたしの名は紅〔新訳版〕 上 」 (Amazon)

「わたしの名は紅〔新訳版〕 下 」 (Amazon)

現代最高の小説家の一人（と、あえて断言してしまおう）、オルハン・パムクの代表作。最盛期を過ぎつつある16世紀オスマン・トルコの首都イスタンブール（と語尾を伸ばすのは英語風の発音で、現地ではイスタンブルと短く言う）を舞台に、イスラム細密画家たちの間で起きる謎の連続殺人事件を追う、一種の長編歴史ミステリである。

本書の冒頭は、「いまや死体だ、わたしは。」から始まる。井戸の中の冷たい死体となった被害者が、話者となって、四日前に起きた自分自身の殺人事件について、一人称で語り始める。次の章は、12年ぶりに故郷イスタンブルに帰ってきた、カラという名前の男性が語り手だ。そして、各章が異なる話者によって一人称で交代交代に語られる。だから目次は、こんな風になる：

「第１章　わたしは屍

　第２章　わたしの名はカラ

　第３章　わたしは犬

　・・・

　第31章　わたしの名は紅」

犬も、殺人犯も、馬の絵も、そして色彩さえが、語り手の地位を得る。つまり、この物語には明確な主人公がいないのだ。もちろん、カラと、彼が恋する寡婦シェキュレとのロマンスが、この物語の重要な縦糸になるから、読者はふつう二人を主人公に擬して、感情移入しながら読むことになる。そして、「ぼくはオルハン」という幼い少年は、明らかに著者の分身である。だが全編を貫くのは、絵画という仕事をめぐる、絵師たちの願望と苦悩である。

「イスラム教が弾圧を加えた最たるものは、女性達に対してですが、もう一つは、世界や人間をあるがままに見て、それを描いたり、眺め楽しむことに対してでした」と、著者は序文『日本の読者へ』で書く。実際、偶像崇拝を厳格に禁ずるイスラム世界では、絵画は常に微妙な位置にあった。インドから中東にかけて長い伝統を誇る細密画の絵師たちも、16世紀のオスマン・トルコでは、方やイスラム原理主義（なんとこの時代からあったのだ）の脅迫、そしてルネサンスを経験した西欧美術からの影響との桎梏に、もがいていた。

イスタンブールは、誰もが知る通り、東西文明の交錯する都市である。かつては東ローマ帝国の首都で、ギリシャ風ビザンチン文化の中心地であり、またその後は長らくオスマン・トルコ帝国の首都でもあった。帝国とは諸国を包含する存在であり、帝国の首都とは、世界の中心である。だからこの街は、ヨーロッパとアジアという異なる二つの楕円の、共通の焦点なのだ。

その中にあって、東西の文化と、宗教の天地の間で、引き裂かれる芸術家たちの魂の悲劇を、著者は共感を込めつつ緻密に描く。パムク自身、小説を書き始めるまでは画家を志望していたらしい。それにしても作家の想像力とはここまでの拡がりを持ちうるのか。トルコの枠を超えて、まさに現代文学の最先端である。

オルハン・パムクは多彩な芸域の人らしく、現代トルコを舞台にした政治スリラー『雪』は、スピード感を持って読者をぐいぐい引っ張っていく傑作だった。しかし本書はミステリー仕立てながら、むしろじっくりと物語が展開していく。

なお、わたし自身は藤原書店版「わたしの名は紅」 (Amazon)で読んだので、上の引用もすべてここちらからとっている。藤原書店版の訳者・和久井路子氏はトルコの大学の先生で、原文の倒置法をそのまま日本語に移すなど、かなり苦心しているが、必ずしもこなれた訳とは言えなかった。その点、ハヤカワ文庫版のほうが読みやすいとの評判である。ただ、このような優れた小説を、著者がノーベル賞を受賞するよりも前に訳出し、上梓した藤原書店には、あらためて敬意を評したい。

「ウィトゲンシュタインのウィーン」　S・トゥールミン, A・S・ジャニク著

「ウィトゲンシュタインのウィーン」 (Amazon)

ITに関わる人は、西洋哲学を勉強するべきだ。なぜなら、ITは西洋哲学の非嫡子なのだから、と以前からこのサイトでは何度か書いている。では、具体的にどの哲学書を手にとって読めばいいのか？　そうたずねられたら、「何でもいいのだけれど、理工系のエンジニアなら、まずはウィトゲンシュタイン『論理哲学論考』を読め」、と答えるだろう。

『論理哲学論考』は比較的薄くて手に取りやすいし、ウィトゲンシュタイン自身が工学者としての教育を受けた人なので、理系的なアプローチの思考に親しみやすい。そして、20世紀の現代西洋哲学に、巨大な影響を与えた。さらに、アウトライン・プロセッサで書いたような、階層的なスタイルで書かれている点も興味深い。たとえば、こんな風だ：

「1　世界は成立していることがらの総体である。

　1.1　世界は事実の総体であり、ものの総体ではない。

　1.11　世界は諸事実によって、そしてそれが事実のすべてであることによって、規定されている。

　1.12　なぜなら、諸事実の総体は、何が成立しているのかを規定すると同時に、何が成立していないのかをも規定するからである。

　1.13　論理空間の中にある諸事実、それが世界である。

　・・・・・」（野矢茂樹訳・岩波文庫版 P.13より引用）

ちなみに、英語をいとわないなら、Project Gutenbergで無料版を（ちゃんとバートランド・ラッセルによる初版への序文付きで）読むこともできる。そして上記の和訳で受ける印象とは、ずいぶん違うことも分かるだろう。

第二次大戦直後、29歳でこれを書いたウィトゲンシュタインの問題意識は、（ITエンジニアに分かりやすい表現をすると）「モデリング・ツールとしての言語の限界を、内在的に分析できるか」であった。つまり、これはモデリング論なのである。

だが、なぜ彼はこのような問題を立てたのか？　それは、彼の師匠だった論理学者のラッセルとか、その後の英米分析哲学だけを見ていても分からない。むしろ、ウィトゲンシュタインが育った中欧・ウィーンの知的伝統と混沌を背景として理解すべきだ、というのが、「ウィトゲンシュタインのウィーン」のテーマである。そして、その背景画は、それ自体がとても魅惑的なのである。

著者のS・トゥールミンは英国人で、ウィトゲンシュタインに若い頃学んだ人だ。A・S・ジャニクは米国人で、二人共、大学の先生である。彼らは広範な文献調査に加え、繊細な想像力を持って、世紀末ウィーンの知的世界を描き出す。ハプスブルグ朝のウィーンは、オーストリア帝国の首都だった。そこから、いわゆる「ウィーン学団」の論理実証主義も、フロイトの精神分析も生まれてくる訳だ。だが、彼らに大きな影響を与えたのは作家のカール・クラウスであり、物理学者のエルンスト・マッハであった。

マッハの経験論的哲学に対して、若くして亡くなった物理学者ヘルツは、一種のモデリング論を立てる。論理的無矛盾性、データとの整合、そして説明変数の単純性を、3つの基準としたヘルツの議論は、現代のAI（機械学習）のモデル論に対しても、十分通用する優れたものだった。そしてウィトゲンシュタインの『論考』は、ある意味でその議論を、「モデリング・ツール（世界記述のツール）としての言語」にまで、拡張しようとする試みだった。だから『論考』は6.4節以降で、急にスタイルを変え、これまでの哲学や神学・倫理学が、いかに無意味なことをやってきたかを、活き活きとした筆致で批判するようになる。

本書はもちろん、『論考』以後のウィトゲンシュタインの歩みも忘れない。事実、彼は後年になって『論考』の内容には否定的な立場を取るようになり、日常言語学派と呼ばれる新しい動きを生み出した。ずっと英国に住んだ彼だが、その倫理的で誠実な生き方は、むしろウィーンの良き文化を体現するものであった。

藤村龍雄氏の訳は、決して読みやすいものとは言えない。原書も一部見たことがあるが、それほど衒学的な文体ではなかったから、英語に堪能な人はそちらにトライするのもいいだろう。しかし、こういう書物は、数多くの固有名詞に関する、詳細な訳注が、情報源として有用なので、わたしはあえて日本語訳をおすすめする次第である。

米国人たちと机を並べてプロジェクトで働いて、最初に学んだこと

はじめてアメリカ人たちと机を並べて仕事をしたのは、もう20年以上前のことだ。当時わたしは、国際プロジェクト本部という部署にうつったばかりで、職種はプロジェクト・エンジニア（の見習いのようなもの）だった。プロジェクト・エンジニアとは、プロマネの配下で、様々な連絡調整業務を行う役割である。わたし達の業界では、プロジェクト・マネージャーになりたかったら、必ずプロジェクト・エンジニアとしての経験を積む必要がある。プロマネへのキャリア・パスの一部であるととともに、一種の下働きであり、わたしはさらにその見習いだったという訳だ。

わたし達は中東における、ある大型プラントの入札見積業務を進めていた。自社が単独で応札するにはリスクが大きすぎるため、米国の同業であるX社との共同プロジェクトの体制をつくって、仕事に臨んだのだ。我々の業界では、大型案件の入札見積となると、それ自体が6ヶ月〜1年近くの期間を要し、費用も（人件費を含めると）かるく数億円単位がかかる。つまり、入札自体がそれなりの規模のプロジェクトである。

さらに、見積設計業務の一部は、英国にある関連会社に依頼していたので、プロジェクトは日米欧の三極体制になった。中心オフィスは、横浜にあるわたしの勤務先（当時はまだ郊外の上大岡という場所にあった）に決まり、遂行チームは『アマルガム』スタイルとなった。アマルガムとは合金という意味だが、つまり複数の会社のメンバーが、区別なく机を並べて、ワンチームとして働くやり方である。プロマネはアメリカ人、副プロマネは日本人で、二人は文字通り横に並んで窓際に座っていた。仕事の言語は、すべて英語であった。

同じ業界で同じ案件の仕事に携わりながら、働き方から仕事の進め方まで、日米でこうも違うのか、と印象に残ることが沢山あった。アメリカ人たちは、朝が早い。7時台にはオフィスに来て働き始め、そのかわり5時をすぎるとさっさと帰ってしまう。長時間残業はしない。だが、なぜか能率が高いので、仕事はちゃんと進んでいく。

それでも見積業務の追い込み期に入ると、米国人のプロマネは厳かに「No Saturday」を宣言した。つまり土曜日も全員出勤して、仕事をしろという訳だ。10数名いた米国人のスタッフは、文句も言わず従った。もちろん我々日本人だって、同じく土曜日返上である。

いまでもよく覚えているのは、見積書提出の直前の土日だった。当時はまだ見積書は紙で提出し、しかも客先要求に応じて10部近くのコピーを収めなければならなかた（客先はそれを社内の関係各部門に配布してレビューするのだ）。複写された紙は、ダンボール箱に何箱にもなる。仕分けは外注先の複写会社がやってくれているが、万が一にも落丁・乱丁があってはならない（なにせ1千億円級の受注がかかっているのだ）。

わたし達は椅子を並べて車座になり、全員がコピーを手にして、一人の読み上げる掛け声にしたがって、章ごとのページ数があっているか、白紙が挟まっていないかを、全ページめくりながら確認した。米国人のプロマネから庶務の日本人女性まで、同じ輪に座って、一緒に紙をめくっていく。OKならば、そのファイルは完成品の段ボール箱にしまう。バカみたいに単純な、雑用作業だ。だが、プロマネ自身、文句も言わず当然の事のように皆を手伝って、淡々とこなしていく。

わたしはその姿を見て、なんとなく、「プロジェクト・マネジメント」という仕事の本質の一部を、垣間見たような気分になった。プロジェクト・エンジニアの仕事とは、ある意味では雑用の集合体なのである。自分で設計図を引くわけでもなく、自分で資機材を運ぶわけでもない。そういう仕事はすべて、社内や社外に専門職がいて、彼らが引き受ける。プロマネと、その配下のスタッフ（プロジェクト・マネジメント・チーム、略してPMTと呼ぶ）は、ただ計画をして、その手配と連絡調整などの情報の交通整理をし、そして問題解決をしていく役目なのだ。

ただ、そうしたいわば『雑用』の進め方において、アメリカ人と我々とでは、明らかに違う点があった。1つ目は、いろいろな細部が、かなりシステム化（定型化）されていることだ。2つ目に、彼らは必ず最初に「計画を立てる」ことだ。

ある日、顧客からFAXが入って（そう、当時のコミュニケーション手段はFAXが主体だった）、面倒な追加要求が来た。我々の見積作業スケジュールに、いろいろな部分でインパクトがありそうだ。FAXはまず、プロマネの机の上のIn Boxに届けられる。かれはその内容を見て、左上の角に小さな付箋紙を貼り、机上のOut Boxに置く。

その付箋紙には、プロジェクトに関わる各部署・各専門家の略号が、表形式にリストアップされている。プロマネは、FAXの内容に応じて、配布すべき先に、AやIなどの文字を書き込む。「A」はActionの略で、要アクションを意味する。「I」はInformの略で、情報として承知しておくべきことを意味していた。上記のような面倒な要求のときは、もう少し具体的なアクション内容を、手短に付記する。

庶務の人は定期的に、プロマネの机のOut Boxをあけて、その付箋紙の指定した通りに複写をとって、チーム員や関係部署に送付する。オリジナルの紙は、プロジェクト・チームの部屋のキャビネットに「センター・ファイル」する。入ってきたFAXは、送信元ごとに連番がふられており、センター・ファイルする際に、インデックスの表に、連番・受信日時・タイトル等を書き込む。返信するときには、その「連番・受信日時・タイトル」を書くことによって、どの連絡に関する事項だか、明確になるようにする。

こういうやり方が、「システマティック」という事なのかと、はじめて納得がいった。プロマネの仕事の半分以上は、情報の判断と交通整理である。それがムダなく、能率的に、かつ誰にとっても明確になるように行われる仕組みになっている。どこの部署にいつ、どの情報が届けられたか、すなわち『情報のトレーサビリティ』が、客観的に追えるようになっている。

21世紀の今は、顧客とも社内外の連絡も、すべて紙ではなく電子化されている。だが、紙ベースで上記のような仕組みが確立されていたからこそ、それをスムーズにITシステムに移行できたのだ。いいかえると、紙でちゃんとした業務のプロセスが構築されていなかったら、コンピュータを持ち込んだって、急に「デジタル化」などできないのだ。

ところで、上記のような厄介な要求が来た場合、プロマネは、PMTのスタッフの一人である『プロジェクト・コントロール・マネージャー』に、「A」（要アクション）の記号を書き、さらに右横に”DEVELOP PLAN”と付記した。わたしはなぜか今でも、その角ばった手書きの字体を覚えている。つまり「計画を立てろ」と指示したのだ。

この「プロジェクト・コントロール・マネージャー」というのは、計画立案と進捗管理の専門家である。このときは、同じく米国人がこの役職だった。でも、このプロジェクト・コントロール・マネージャーという役割がまた、日本人にはわかりにくい。日本語ではマネジメントもコントロールも「管理」だから、日本語訳すると「プロジェクト管理管理者」になってしまう。何それ？

英語的には、コントロールは、マネジメントの下位概念と理解するほうがいい。マネージという動詞には、どこか「暴れ馬を乗りこなす」ような語感がある。ところが、コントロールという動詞は、もっと精密な、飛行機や自動車を乗りこなす、つまり「制御」に近いニュアンスなのである。プロマネを船長にたとえるならば、コントロール・マネージャーは「一等航海士」というところだろうか。海図に航海の線を引き（＝計画立案）、操舵して予定通り船を動かす。だが、航路の判断など重要なところは、船長の指示に従う。

コントロールにおいては、数量をもとにした、メトリクスを用いたやり方が、ほぼ必ず選ばれる。それが技術提案書の作成の進捗状況であれ、見積コストの積算状況であれ、最初にリストや表を作り、カバーすべきアクションや対象をリストアップする。そして、その中でどこまでが完了したか、比率や％ではかっていく。必要ならば重み付けするが、重み付けが難しい場合は、単純な項目数だけでもいいから、カウントする。

だが、日本人にこれをやらせると、「適当な重み付けができませんから」といって、数値化それ自体を放棄する事が多い（なので結局、毎回進捗を聞いて回らなければ状況が把握できなくなる）。正確でなければ数値化に意味はない、と考えるのは技術者らしい、といえば言える。だが、その裏には、なぜか仕事のマネジメントにおける数値化への警戒感のようなものが潜んでいたりする。その点、米国人は、数字は状況判断の目安だと割り切っているように見える。

もっとも、今うっかり「日本人は」と書いたが、これは習慣化すれば、別に日本人だって普通にできるようになる。なにも文化や国籍の問題ではないのだ。仕事をどうシステマティックに進めたいか、という思考習慣、いわば『OS』の違いなのである。

ただ、このようなOSをちゃんと組織全体で作り上げているかどうかが、結局はITシステム導入だとか、業務の「デジタル化」における差を生み出すのである。たとえば、あなたの職場では、「センター・ファイル」は昔から行われていただろうか？　インデックスはきちんと作られていただろうか？

米国流の、あるいはもう少し広くいって欧米流の仕事のやり方は、役割分担と専門分化をベースにした分業体制が基本にある。組織を作り、仕事を部分部分に分割して、それぞれ専門担当者に割り当てる。ただ、そのままだと足並みが揃わないから、全体を指揮するリーダーが必要になる。まるでオーケストラのようなものだ。

オーケストラなので、皆を動かすためには楽譜（＝計画）がいる。それを全員に、正しく配らなくてはならない。そういうところから、彼らは仕事における情報（Information）と伝達（Communication）を重んじるようになる。コミュニケーションを効率よく、正確に進めるためには、定型化された番号や記号や数字を使うのがいい。かくて、彼らは自然と「データ」を仕事の中に織り込んでいく。

これに対して、「あ・うん」の呼吸で互いの間合いを見計らって、多少出たとこ勝負の即興的に進めていく日本の組織のあり方は、お能の囃子みたいだ、と言えなくはない。楽譜はあってもメモ程度で、お互いの目配せや顔の表情と、受けての側の「察し」が、主な情報伝達である。こういう組織に、定型化されたデータは発生しようがない。小規模な組織だから、必要性も小さい。仕事の成果は、各人の個人的力量に依存する。

・・こう書いていくと、なんだか米国流を礼賛し、日本式を批判しているように見えるだろう。だが、そういう意図ではない。どちらのやり方にも、長所短所があることを、わたしもいろいろな仕事を通じて知っている。ただ、思考習慣として、英米企業は最初から大規模志向で、システム化の方向を向いているが、日本企業はそういうマインドが薄い、ということを言いたいだけだ。

だが、そういう違いを無視して、欧米風の考え方を直輸入しがちな傾向が、わたし達の社会の特徴でもある。その結果として、「なかなかデジタル化が進みません」みたいな話題が、あちらでもこちらでも出てくることになる。

最近、わたしの所属する中小企業診断士の研究会である「生産革新フォーラム」（略称MIF研究会）が、製造業のDXをめぐって、座談会を開いた。その内容が、「日経ものづくり」誌に掲載され、また「日経XTech（クロステック）」にも転載されたので、URLを下記にご紹介しておこう。

製造業DX担当者会（前） https://xtech.nikkei.com/atcl/nxt/column/18/00001/04877/

製造業DX担当者会（後） https://xtech.nikkei.com/atcl/nxt/column/18/00001/04879/

この記事は、いろいろと具体的な差し障りのある生々しい話題のため、匿名座談会の形式になっている。佐藤がこの話者の中にいるかどうか、当てていただくのも一興かもしれぬ（笑）。ともあれ、デジタル化問題の基本にあるのは、仕事の進め方に関する思考と行動の習慣、つまりOSなのである。OSの問題を無視したまま、ただ応用として「データ・ドリブンな経営」などを望んでも、それはかなわぬ夢というものだ。

＜関連エントリ＞

　→「新任リーダー学・超入門(4)　測れないものはマネジメントできない」 (2011-08-26)

海外企業との共同プロジェクトにおけるフォーメーション・デザインは、どうあるべきか

前回の記事の末尾にも書いたが、「マネジメント・テクノロジー」という言葉を発案して、わたしに教えてくれたのは、今秋惜しくも亡くなられた勤務先の同僚、故・秋山聡氏である。秋山さんは、この語を《マネテク》と縮めて、『まねてくニュース』なるメールマガジンとデータベースを、社内に発信し続け、多くの愛読者を持っておられた。

秋山さんは高専を卒業後、大学の工学部に編入して修士号を得た、バリバリの理系教育を受けた人だった。日揮に入社後、海外プロジェクト・マネジメント部門で活躍されたが、ある時期より、ライン業務から一切手を引き、PM業務の標準化を中心としたスタッフ的役割に専念するようになった。プロマネ経験者こそが最大の出世コース、と思われているエンジニアリング業界にあって、これは随分と勇気のある処世だったと思う。

日揮においては「プロジェクト・マネジメント技術部」という部門が、一種のPMO的な機能を担ってきた。秋山さんはそこの重鎮として、社内の各種検討活動に参加され、言葉は穏やかながら鋭い発想で議論をリードされた。わたしも同じ部に何年か所属しており、その縁もあって、東大大学院の「プロジェクトマネジメント特論」の講義を引き受けた際、一学期・全15コマのうち3回分を、秋山さんに分担講義していただいた。

その秋山さんとわたしは、2007年に、『海外企業との共同プロジェクト遂行におけるリスク要因』と題する論文を、「プロジェクトマネジメント学会誌」に原著論文として発表した（Vol.9, No.1）。これはエンジニアリング業界の経験をもとに、海外企業との協力におけるフォーメーション・デザインの問題に、初めて正面から切り込んだ研究であった。フォーメーション・デザインとは、プロジェクトの組織と役務分担の決め方のことを指している。単一企業のプロジェクトと異なり、複数企業で同じプロジェクトに取り組む際には、このデザインは簡単ではない。

秋山さんがこのテーマを選んだのは、日本企業と海外企業との共同事業に、どのようなフォーメーションで取り組むべきかが、その成否を決める大事なポイントだ、と考えたからだ。だが、あいにくわたし達が論文を発表して以来、あまり同様の問題意識による研究を見かけない。では、皆が海外企業との共同プロジェクト事業を、問題なく計画し進めているのかというと、必ずしもそうではあるまい。そこで、我々の論文の問題意識をおさらいしつつ、あらためて、良いフォーメーションとはどのようなものか、考えてみよう。

日本企業が海外に事業展開する場合、いきなり日本人社員が現地にいって出店を開いて、すぐ商売になるケースはほとんどない。ふつうは、当該国の事情に通暁した現地企業と、なんらかの協力関係を取り結ぶ必要がある。もちろん、商社や銀行など、先行して現地に地盤を築いている日本企業があって、最初はその道案内を頼りにすることも、あるだろう。だとしても、ビジネスを広げていくには、どうしても日系企業向け以外との、付き合いを増やすことになる。それも、いきなり共同で定常業務を立ち上げることはできないので、どうしても最初は初めての取り組み、いいかえれば共同プロジェクトを実施することになる。

海外企業との共同プロジェクト事業といっても、大きく分類すると、日本企業が商売の売り手の場合と、買い手の場合がある。さらに、その事業が、自発型のプロジェクトの場合と、受注型プロジェクトの場合との、4類型がある。これについては、以前「海外プロジェクトの質的変化と、成功体験の罠」 (2018-09-29)にも書いたとおりだ。この中で特に難しいのは、自分が弱い立場、すなわち受注型プロジェクトの売り手の場合である。そこで、このケースを例にとって、分析してみよう。

プロジェクトは、ものづくり型、サービス提供型、イベント型などに分けることができる。ものづくり型は、文字通り、物的な何らかの成果物を作って、顧客に引き渡すタイプである。たとえば橋を架けるとか、航空機を輸出するとか、水道を建設するとかいった仕事だ。「インフラ・システム輸出」はこのタイプと思っていい。サービス提供型は、たとえばソフトウェア開発とか、コンサルティングとかが該当する（日本企業は、国のスポンサーが付くODA案件以外では、不得意分野かもしれない）。イベント型は、文字通りイベントを開催するような種類のプロジェクトである。

こうしたプロジェクトでは、どれも最初は、何らかの成果物のデザインや設計の役務からスタートする。ついで、その設計をより詳細化して展開したり、原材料や機械・ツール類を手配する仕事が続く。そして、最終的には、製造や構築など、実装フェーズがくる。つまり、いってみれば序破急の3つのフェーズが最低でもあるのだ。

役務分担を考える際には、プロジェクトの仕事の全体を、ある程度の要素に分解する必要がある。プロジェクトのスコープを要素分解して構造化したものを、WBS(Work breakdown structure)と呼ぶ。つまり、フォーメーション・デザインにおいては、WBSをどのように切り分けて構成するかが問われることになる。上に述べた、「設計・調達・実装」のように、仕事の進むプロセスに応じた業務の分解のことを、Functional-WBS (略称F-WBS)という。

これに対して、もう一つの分解の方法がある。それは、成果物の構成単位に切り分ける方法である。たとえば航空機ならば、胴体・主翼部・エンジン・尾翼部、など。ITシステムなら、機能モジュール単位のサブシステム群や共通ルーチン、といった切り分けだ。プラント・工場だったら、製造ライン（ユニット）、ユーティリティ、タンク群、入出荷設備などのエリアを、それぞれ作る仕事という、切り分けになるだろう。このような仕事の分解のやり方を、Product-WBS(P-WBS)と呼ぶ。

ある程度以上の規模のプロジェクトの場合、F-WBSだけでもP-WBSだけでも不十分で、両者を縦横にしたマトリクスで、仕事の分解を考える必要がある（興味のある方は、拙著『世界を動かすプロジェクトマネジメントの教科書』 第2章を参照されたい）。

ここでは、プラント系の例を取り、簡略化のため、F-WBSは「設計・調達・建設」の3段階、そしてP-WBSも３つのエリアで考えよう。下図は、その3つの類型を図式化したものだ。

（佐藤知一・秋山聡『海外企業との共同プロジェクト遂行におけるリスク要因』 プロジェクトマネジメント学会誌. Vol.9, No.1, 2007より引用）

一番左の「垂直分業型」は、それをA社・B社・C社の三者が、F-WBS単位で、「設計・調達・建設」のフェーズごとを分担するタイプである。それぞれ技術に特化して強みのある会社、廉価で競争力のある製造業を抱える会社、そして現地の建設工事に強い会社が分担する、といったタイプだ。

ちょっと考えると、それぞれの強みを活かした分担のように思える。だが、落ち着いてみると、プロジェクト・マネジメントは結構、難しくなりそうである。まず、会社間で受け渡すインタフェースが非常に多い。A社からはすべての設計情報を、B社が受け取らなければ、調達はできない。B社からすべての資機材を受け取らなければ、C社は建設工事ができない。どこかに遅れが生じたり、品質問題でやり直しが出たら、誰が調整して責任を取るのか？　

真ん中の「水平分業型」は、逆に、P-WBSを軸に分担するタイプだ。こちらは、それぞれが担当するエリアの設計・調達・建設を、それぞれ遂行する。これもまた、製造ユニットとかタンク群とか、それぞれ得意不得意に応じて、分担を決めることになる。うまく得意分野が噛み合えば、効率よく進められそうだ。

ところが、このやり方にも問題がある。たとえば、工場・プラントの基本設計という仕事は、要するに全体の生産システムを決める業務からスタートするので、必然的に3社の間でインタフェースが生じる。かりにそこはうまく進められたとしても、建設工事の最後に、工場全体のスタートアップという仕事が来る。これまた、全部のエリアが関係する。ユーティリティの電力が来なければ、製造ユニットは動かせない。だが燃料タンクができていなければ、発電用ボイラーが起動できない、といった調子だ。

このように水平分業型では、最初と最後に、インタフェース問題が集中する傾向がある。だが、それでも途中は互いに独立に進められるので、まだしも「垂直分業型」より、エンジニアリング業界では好まれているように見受けられる。

ただ、ここに調達の問題が関わってくると、やっかいになる。たとえば、法規制によって現地国における調達比率を上げることが求められたりする。あるいは、共通の資機材（配管材料や鉄骨など）は、プロジェクト全体でまとめて買うほうが、安くなる、といった要請もあろう。さらにECAによる貿易保証枠や、決済通貨の比率、そして各社の売上額など、商務上の制約がからんでくると、単純に「垂直分業型」だけではすまなくなってくる。

で、結局、図の右のような「混成型」に、なりがちなのである。どうみたって、プロジェクト・マネジメント的には、一番複雑である。リスクは、異なる会社間のインタフェースに潜む可能性が高い。

各社が、共同プロジェクトで自社に損失になりそうなリスクを察知したら、どうするか？　本来は、互いに競技して問題解決を図るべきであろう。だが、相手は初めて組んだ、異国の会社だったりする。自分だけを守る行動にでないとも、限らないだろう。

このような協業に対する離反行動には、いくつかのパターンがある。ここでは詳しく述べないが、興味があれば前述の論文を参照されたい。

ともあれ、互いの離反行動を抑えるような方策も、最初に講じておく必要がある。その代表的な例が、「Profit & loss share」による協業の仕組みである。これは、プロジェクト全体で一つの財布を持ち、利益が出たら、予め決めた分担比率で、それを分け合い、逆に損失が出た場合も、損失を負担し合う、という取り決めだ。ふつうこれは、協業のための契約書に明記しておく。

このようにすると、各社が全体の利益のために、個社の利害を超えて調整しようというモチベーションが働きやすい。

では、各社が別々の財布を管理し続けるような協業の形態を、選びたいときはどうするか？　その場合でも、たとえば「互いのミスによる損失は求償しない」といった約束を、契約に入れておくことがある。ミスは完全に防ぐことは不可能だ。だが、互いのミスで責め合っていたら、チームとしての結束にヒビが入りかねない。

海外企業との共同プロジェクトにおけるフォーメーション・デザインとは、以上のような観点を入れて、考えるべき問題である。そもそも、海外プロジェクトは難しい。おまけに、はじめての相手との共同プロジェクトもまた、難しい。難易度が高い仕事なのだから、仕事のデザインは、熟慮が必要なのだ。

ただ、論文にも書いたことだが、我々の業界では、海外企業との共同プロジェクトでリスクを検討する際に，カルチャー・ギャップが主要な議題になることは、あまり無い。

「理由の一つは，基本的な言語・生活習慣等の差異を，過去の類似プロジェクト経験により各社がかなり学習済みな点にある．しかしそれ以上に，『文化』という定義の漠然とした言葉によって，ステークホルダーの行動の潜在的問題を説明してみても，リスク分析は深まらないとの認識があるためである．

プロジェクトは企業同士の組織的行動であり，リスク要因の中心となるのは，個人レベルの生活習慣の違いよりも，会社レベルでの行動ベクトルの違いや，各社の仕事の進め方等の違いである．そうした差異の多くは，じつは経済合理性によって説明が可能であると筆者らは考えている」

（上記論文より引用、下線と強調は筆者）

簡単にいって、企業の行動というのは、各国の文化特性の差よりも、利益追求という共通性の方が、ずっと影響力が大きいということだ。だからこそ、異なる様々な国における、フォーメーション・デザインについて、共通した知恵が形成できるのだ。

秋山さんがずっと探求しておられたのは、プロジェクトにおけるリスクの問題だった。受注型のプロジェクト・ビジネスに於いては、契約と交渉がリスク・マネジメントの鍵になることが多い。その点を重視した秋山さんは、理系だったにもかかわらず、独学で法律を勉強し、司法書士の資格までとられた。東大大学院の講義でも、契約や交渉について、実技演習を交えてユニークな授業を行われた。

あの温和な口調と、独特のユーモアにもう接することができないと思うと、残念でならない。秋山聡氏から教えていただいた様々な事柄にあらためて深く感謝するとともに、故人の魂の平安を、今はただ祈るばかりである。

＜関連エントリ＞

　→「海外プロジェクトの質的変化と、成功体験の罠」 (2018-09-29)

　→「そうか、製造業のデジタル化って、そういう意味なのか」 (2020-11-15)

お知らせ：TOCシンポジウムでプロジェクト・マネジメントに関する基調講演を行います（11月30日 13:00-14:00）

またまた、お知らせです(^^)

TOC（Theory of Constraint）という考え方について、聞いたことのある方も少なくないと思います。イスラエルの科学者・故ゴールドラット博士が提唱したマネジメントに関する理論で、『制約理論』とも訳されますが、最近はTOCと略称で呼ぶ方が一般的でしょう。

TOCはサプライチェーン・マネジメント、プロジェクト・マネジメント、スループット会計、思考プロセスなど、幅広い分野に対する手法を提供しています。とくに90年代に、サプライチェーン・マネジメント分野に与えた影響は大きく、『全体最適』の思想や、生産スケジューリングのアルゴリズムなどにも、そのインパクトを見ることができます。

かくいうわたし自身も、1998年に出版した共著『サプライチェーンマネジメントがわかる本』（SCM研究会・編）の中で、ゴールドラット博士のTOCを、思考プロセスも含めて簡単に紹介しました。これは、まだ邦訳書のなかった当時としては、かなり早い紹介文だったと思っています。

ゴールドラット博士にはどこか教祖的な魅力があるらしく、TOCを実践に移す人たちのコミュニティは、日本でも着実に成長し、博士の没後も続いています。今年の「TOCシンポジウム」はコロナ禍の影響を受けてオンライン開催形式ですが、それなりに大勢の方が参加されると思います。

たまたまお声がけいただき、わたしも今年は基調講演をさせていただくことになりました。ただ、わたし自身はTOCについては素人ですので、得意の知ったかぶりは避けて（笑）、自分自身が考え出したプロジェクト・マネジメントに関する理論について、あえてお話するつもりです。そのエッセンスは、2010年に東大に提出した学位論文に書いている内容ですが（「リスク確率に基づくプロジェクト・マネジメントに関する研究」静岡大学出版・参照のこと）、今回はその後10年間の発展も含めて、できる限り分かりやすい形でご説明するつもりです。

最近は直前のご案内が多くて恐縮ですが、多くの方のご来聴をお待ちしております。

＜記＞

「TOCシンポジウム＆TOCインダストリーフォーラム 2020」

講演タイトル「リスク確率に基づく価値評価とプロジェクト・マネジメントの提案」

日時：　2020年11月30日(月) 13:00〜14:00

主催：　日本TOC推進協議会 他

講演概要：

　プロジェクト・マネジメントの目的は、「プロジェクトの価値を最大化すること」にあります。また、プロジェクト・マネージャーの仕事の中核には、つねに「決断」があって、複数の選択肢の中から、プロジェクトの価値が最も大きくなるものを選び取っていく必要があります。

　それでは、あなたの関わっているプロジェクトは、現在、具体的にいくらの価値があるのでしょうか？　そして、プロジェクトを構成する各アクティビティは、全体の価値に対し、いくらずつ貢献しているか、ご存知ですか？　典型的なトレードオフ状況、たとえば、値段が高いが品質の良い外注先Aと、安いけれど品質に問題含みの外注先Bから、どちらかを選ぶ時、判断基準はありますか？

　本講演では、リスク確率に基づくプロジェクトの価値評価と、そのマネジメントについて解説します。さらにサプライチェーンの中での中間製品の価額決定や、生産部門と販売部門の貢献度の比較、そしてフロート日数を1日消費することは、いくらのコスト増に相当するのかといった問題を、全く新しい視点から解決します。

申込み：　下記をご参照ください

http://www.j-toc.jp/event/symposium2020.html

以上、よろしくお願いいたします。

佐藤知一＠日揮ホールディングス（株）

そうか、製造業のデジタル化って、そういう意味なのか

（前回までのあらまし）工場で『製造IT担当』として働くあなたは、ある日、「全社DXチーム」の一員に任命され、会議のため本社に呼び出される。事務局を務める情報システム部次長のもと、経営企画・営業・設計・生産技術・品管など、社内各部の若手中堅が集められていた。何をすべきなのか皆で議論するが、甲論乙駁、なかなか方向性が定まらない。あなたは、社内の各種ITシステムがバラバラで、かつ情報が一方向にしか流れない状態を何とかすべきと訴える。と、そこに突然、DX活動の責任者である専務から電話が入る。指示を受けた情シス次長は、こう宣言した。

情シス次長「諸君、専務からだ。方針変更だよ。」

全員「ええ！？」

情シス次長「社用車の中からだったので聞こえにくかったけど、戦略コンサルの方々と接待の店に向かう途中で、さらにいろいろと話されたらしい。それで専務がおっしゃるには、ものづくりの中心は設計だから、DXは設計を変えなきゃいかん。すなわち、製品のアーキテクチャを改革しろ、と。」

設計「そ、そんな・・！　過去の設計資産はどうするんですか。全部捨てることになりますよ！」

情シス次長「でも、設計畑出身の専務兼CTOの、おっしゃる事だからねえ。それで、モジュール型アーキテクチャに変革すべきだ、と。なんでも、オランダのAD・・なんとかって半導体製造装置メーカーの話に、感銘を受けたらしい」

生産技術「今のウチの中核技術は、昔、専務がイギリスから導入したものですよね。今度はオランダですか。つくづく、欧米の輸入とモノマネがお好きらしい」

情シス次長「こら、余計なことは言いなさんな。ともかく、オープンな製品アーキテクチャにして、協力企業を呼び込み、エコシステムを形成しろ、とおっしゃってる。設計は全部3Dでデジタル化する。また技術開発も、オープン・イノベーションに切り替えて、ベンチャー企業を発掘投資する、という事です。すでにその方向で、コンサルとも話を始めたらしい。」

財務「コンサル費用のほうが、ベンチャーへの出資金よりもかかりそうで、心配ですね・・」

設計「・・自分は方針に納得できません。あとで専務に直接談判してみます」

情シス次長「ああ、君は専務の大学の後輩だったね。やってみたら？　でも専務もプライドの高い方だからね、いったん口にしたことは、なかなか引っ込めないんじゃないかな。」

――じゃあ、工場側のシステムはどうするんですか？

情シス次長「設計が変われば、製造は自然とあとからついてくる、と。」

――・・・。

情シス次長「専務は工場の子会社化や海外移転を積極的に進められた方だし、製造現場の業務はあまり眼中にはないのかもね。」

――でも、さっきの僕らの話と、なんとか折り合いはつかないんでしょうか？　デジタル技術で単調な工場労働を機械に任せる、とか、エンド・ツー・エンドのシステム統合って方向で、みんな一応納得していたと思うんですが。全部忘れるしかないのかな。

（その時、それまでずっと黙っていた標準化部門のベテランが、はじめて口を開いた。こわもてな顔つきだが、口調は優しい）

標準化「別にそれはそれで、両立するんじゃない？」

――どういう意味ですか？

標準化「文字通りの意味だよ。システムの統合と、現場の自動化・データ化と、製品の設計思想の改革と、三つ全部やるべきだろうね。むしろ、どれかを捨てたら、他も効果が出なくなる。」

――もう少し詳しくおっしゃってください。

標準化「さっき品管さんが言ったように、デジタル化はそれ自体が目的じゃない。手段のはずでしょ。で、戦略コンサルの今日の講演によると、流通サービス業や金融業のデジタル化ってのは、ビジネスモデルの変革が目的だって事だ。つまり『売り方の変革』だね。」

――はあ。

標準化「だとしたら、ぼくら製造業にとってのデジタル化のねらいは、『作り方の変革』になると思わない？」

経営企画「それって、現場にロボットとかを並べて作る、って意味ですか」

標準化「いや、いや。ウチの今の製品を、今の材料から、今の作り方していたら、たとえ人手を全部ロボットに変えたって、効率化がちょっと進む程度だよ。ぼくも昔、製造にいたから知ってる。もし製造を根本的に改良したかったら、製品の設計から直さなけりゃ無理です。」

設計「しかしモジュール型アーキテクチャへの転換で、製造の非効率が万事解決するとは思えません。」

標準化「いや、ポイントはそこじゃない。デジタル技術の製造業への一番のインパクトは、新素材の開発にあるんじゃないかって、ぼくは考えている。すでにこの何年か、CFRPやらナノファイバーやら、いろんな新素材が出ていて、我々のお客さんの業界にも、少しずつ広まっている。で、こういう新素材の開発って、AIとかシミュレーション技術で、そうとう加速しているらしい」

設計「MI、つまりマテリアル・インフォマティクス技術ですね。それで？」

標準化「結局ね、ものづくりでは、素材の革新が一番大きいと思う。技術の歴史を考えると、設計上の大きな変化は必ず、材料の進歩か、動力の発達によって起きている。自動車業界がEV化で今、あれだけ大騒ぎしているのも、内燃機関から電動への、動力の変化だ。」

――僕らの製品は、昔から電動ですけれど。

標準化「だから、大きく変化するなら素材の方だろう。今の材料は金属が中心だけど、金属加工って結局、鋳物にするか、削るか、折り曲げるか、叩くしかないよね。重いし、うるさいし、煙は出るしで、3K職場になる。でも新素材は全く別の作り方になるんじゃないかなあ」

生産技術「ウチの工場の機械で、扱えますかね？」

設計「新素材なんて、高くてダメですよ。」

――あの、もし性能が5倍や10倍になるんなら、今よりずっと高く売ってもいいんじゃないですか？

営業「ま、そんなに性能が変わるんだったらね。」

経営企画「その新素材を、ウチが開発するってことですか？」

標準化「さあて、ウチができれば最高だけれど、たぶん素材分野の企業さんの仕事だろうね。専務の言うように、ベンチャーかもしれない。でも、新素材を利用した製品設計と、それを加工する技術は、製造業各社のノウハウになるはずです」

設計「くどいですが、過去の設計資産はどうするんですか。全部捨てることになりますよ」

標準化「中核部分に革新的な素材が出てきたら、どうせ設計は全部見直すことになるんだよ。今のウチの技術標準なんかも、全部パー。だったら今のうちから、新素材の出現を予測しながら、設計思想の根本的な見直しを始める方が、賢くない？　欧米のライバルとだって、この点では同じゼロからの競争だからさ」

生産技術「そういっても、新素材の実用化までは、何年もかかるでしょ？　それまではどうしますか」

標準化「専務のおっしゃるモジュール型アーキテクチャへの転換だって、試作や製造ラインの準備を入れたら、最低でも2年はかかるはずだよ。今の素材のままでもね。でも、デジタル化の成果がそれまで何も出ないじゃ、ぼくらも専務も、メンツが立たない。」

経営企画「そうですよ、DXにはクイックウィンが必須です！」

標準化「だからこそ、製造現場の自動化から手を付けるべきでしょう。こっちは目に見えやすい。それに専務はお忘れみたいだけど、ウチを含めて今の製造業の最大の問題は、若い人材が離れていくことです。エンジニアも技能員も、工場勤務と聞いただけで敬遠する。」

人事「本社からだって、やる気のある優秀な人財がボロボロ抜けています」

標準化「仕事の中身が変わらないからだよ。だから経験値のある、ぼくらオッサン世代がでかい顔をしてる。仕事の中身が大きく変わって、先がどうなるか誰も読めないときは、若手だって発言権が出るもの。それに、品管さんみたいに、とにかく単調な労働を減らさなきゃ、外国人だって働いてくれなっちゃうよ。仕事は、やって面白くしなけりゃあ、いい製品だって生まれない。」

人事「従業員のエンゲージメントって事ですね」

標準化「ただ、現場作業の自動化を進めたら、今度は当然、製造IT担当くんが指摘したような、バラバラ・システムの問題が表面化する。でも、幸い専務は、設計を全面的にデジタルにしろ、とおっしゃってる。だったら今度こそ本当に、設計部門は出図して終わり、じゃなく、部品表やCAMや生産スケジューラまでつながった、トータル・システムのフロントエンド役になればいい。」

情シス次長「でもそれも、長い道のりですよ。どっから手を付けるといいのかな。」

標準化「やっぱりね、真っ先に手を付けるべきなのは、最上流だよね。つまり営業と設計の界面です。お客さんの個別要求がすごく増えているでしょ？　それをメールで設計部門が受け取って、毎回個別にチェックしては図面起こす、ってやってるから、設計の仕事量も増えるし、行き違いやミスが出やすい。そのしわ寄せは結局、製造と修理サービスに来るんです。」

品管「たしかに、そうですね。」

設計「詳細設計はなるべく、ベトナムの子会社にさせて、コストダウンと負荷分散しています」

標準化「でも設計を外注化したら、相手は新図面を作る事自体が仕事の目的になるでしょ？　そうじゃなく、新図はなるべく、起こさない。できる限り標準図面で、まかなうようにしなけりゃ。営業所で直接端末に仕様データをインプットしたら、システムが機能型番を選定して部品表まで自動展開し、追加設計の必要箇所だけ設計部門に回すようにかえるべきです。そうすれば設計の仕事量も減る上に、ミスもなくなるし。」

営業「台湾のライバル会社はそんな風だって聞いたなあ。そうしてくれると助かるんだが」

情シス次長「たぶんそれ、コンフィギュレータって種類のソフトの応用じゃないかな」

経営企画「・・ちょ、ちょっと待ってください。頭がこんぐらがってきた。整理させてください。

（ホワイトボードに駆け寄って）コンサルの方が言っていた、流通サービス業とか金融業のDXって、まずMVPのアプリ作って、魅力的なUXと、AI分析機能で、顧客、つまり買い手のエンゲージメントを獲得する訳です。これがSTEP-1。」

情シス次長「うんうん。」

経営企画「それから、アジャイル開発を高速に回して深掘りし、ニーズの変化に即応できる仕組みを作ります。これがSTEP-2です。STEP-3では、リカレントなビジネスモデルに変革する。これが最終ゴールです。これって、今やろうとしていることと、全然違いますね！」

――そうでもないかもしれませんよ。だって、最初にやるのは、製造現場の自動化・情報化ですけど、それは効率よりも、まず働き手のエンゲージメントを上げる取り組みでしょう？

品管「次は、営業からサービスまで、双方向に情報がフィードバックできるような、統合的なシステムです。これは、ウォーターフォール型から脱して、アジャイルな即応力を作るんだって、さっきご自分でおっしゃってました」

経営企画「・・言われてみればそうですね。すると最終ゴールは？」

設計「製品アーキテクチャからの設計の変革です。」

標準化「つまり、『作り方の変革』ね。」

経営企画「えと、リカレントなビジネスモデルは？」

――そこまでシステム化できれば、海外工場に展開する時に、製造ノウハウの90%は、ブラックボックス化して持っていけませんか。10%だけ移転するなら、今みたいに立ち上げに苦労はいらなくなります。提携の相手方だって、僕らから離れにくくなるでしょう。

財務「そこまで製造がスケーラブルになれば、資本のレバレッジを効かせたビジネス戦略も考えやすくなりますね」

情シス次長「３つのSTEPとも全部、ぴったり符合しているじゃないか。」

経営企画「ホントだ。そうか、製造業のデジタル化って、そういう意味なのか」

情シス次長「それにしてもあなたは、こういうマンガを描かせると上手いなあ」

経営企画「それって、ほめてくれてるんですよね（笑）。でもなんだか、腹落ちしました」

設計「でもこれは、一般解じゃなくて、我が社の状況という境界条件を入れた特殊解ですね。」

営業「またあんたは、難しいことを言う。でもさあ、さっきの客先仕様を入れると自動展開するソフトの話だけれど、あなたとしては、どう思うの？」

設計「・・考えてみると、これは仕様から機能セル単位への展開ですね。だとすると、たしかに専務のモジュール型アーキテクチャ構想につながりそうだ・・うーん。面白い、ぜひやってみましょう。」

情シス次長「お、さっきは凹んで、専務に直談判に行くとか言ってたけど、立ち直りが速いね（笑）」

設計「自分が前から考えてたアイデアがあったんです。でも、今のままじゃ使えないと諦めていました。これだったら、生きるかもしれません。」

標準化「どうせ無理だと、この会社の人はみんな諦めてるんですよ。それでますます、何事も無理になっちまう。あんた一人だけでも、このループから抜け出したら？」

設計「はい。ありがとうございます」

情シス次長「なあに、君一人じゃない。ぼくらも応援するから。」

経営企画「でもどうして、アーキテクチャ改革だけでなく、三つが全部必要なんですか？」

標準化「経営企画さん、たまには、人の話ばかり聞いていないで、自分でも考えてみなよ。」

生産技術「でもさあ、何だか全体、お金がかかりそうだなあ。大丈夫なの？」

情シス次長「財務さん、減収減益でボーナスはカットされたけど、実はうちは無借金経営だよな」

財務「・・まあ、その通りです。内部留保を戦略的な成長投資に使わないのなら、配当に回せと、投資家からはいつも責められています」

営業「じゃまあ、俺たちが上手に使って、財務さんの苦労を少し減らしてあげますよ（笑）」

財務「でも、こういうデジタル化の費用対効果を、トップにうまく説明できますか？」

標準化「ぼくが運転免許を取った若い頃はさあ、全部マニュアル車だったんだよね。ギヤシフトとか、坂道発進とかを練習させられたもんだ。当時、オートマの車は値段が高いだの、燃費が悪いだの、カーマニアからは散々言われてた。」

財務「？？」

標準化「でも今じゃ、街中を探したって、マニュアル車なんかほとんど走ってないでしょ？　カーナビもそう。出たときは、そんなもの装備したって、運転が上手になる訳でも、ハンドルさばきのキレが良くなるわけでもないって、みんな言ってたよね。でも今じゃ、カーナビはあって当たり前です」

財務「オートマチック車は現場の自動化に、カーナビはITシステムに相当する、ていうことですか？」

――うーん、確かにそうですね。それなのに僕らの工場では、車にたとえると、今でもマニュアル運転で、毎朝みんなで紙の地図を見ながら、道を探している状態です。海外のライバルなんか、もう自動運転への道を歩んでいると言うのに。

標準化「そいつを称して、『第4次産業革命』とか言うんじゃないのかな。」

情シス次長「・・どうも、ありがとうございます。おかげで議論の方向性がまとまってきました。でも先輩は、どうしてそんなにいろんな物事が見えてるんですか?」

標準化「標準化部門は仕事の傍流だからね、ライン業務の流れに何か無理があると、かえってわかるのさ。それにウチの技術屋は、それなりにみんな優秀だ。機械も、材料も、電気も、制御も、ITもね。だからぼくは、どこの大学でも教えていないけど、みんなが必要とする技術について、ずっと考え続けてきた。」

――教えてないけど、みなが必要とする技術って、いったい何ですか？

「管理のための技術だ。マネジメント・テクノロジーだよ。」

（完）

＜このささやかな対話編を、職場の同僚にして畏友、故・秋山聡氏の霊前に捧げます。氏は「マネジメント・テクノロジー」という言葉を作ってわたしに教えてくれたばかりでなく、その普及のために粉骨砕身、尽力されながら、志半ばで亡くなられました。秋山聡氏のご冥福をお祈りいたします。

なお、この対話はフィクションです。特定のモデルはありません＞

＜関連エントリ＞

(1)　「いや、そもそもデジタル化って、どういう意味なのさ？」 (2020-10-24)

(2)　「製造業のデータって、ほんとはDXに向いていないのかもしれないね」 (2020-11-01)

(3)　「ふーん、デジタル時代には双方向のインテグレーションが必要って事？」 (2020-11-08)

(0)　「製造業のデジタル化に必要な、情報とデータの基本的流れを理解しよう」 (2012-10-12)

お知らせ：BOM/部品表のマネジメントに関するオンライン・セミナーを開催します（11月19日・25日）

えー、ここでまた恒例のお知らせです(^^)

BOM＝部品表に関するセミナーを、今月の後半に２つ、行います。一つは無償のウェビナー、もう一つは有償のオンライン・セミナー（一日コース）です。

「製造業のデジタル化に関する問題は、ITシステムが足りないことではない、むしろシステムが多すぎることだ」――これは最近、ある大手製造業のキーマンの方から聞いた言葉です。その方によると、自社のある事業部を調べたところ、なんとシステムは大小合わせて千以上もあったが、その多くがExcelで書かれ、互いにデータがちゃんとつながっていない状態であった、と・・。

相互につながっていない多数のシステムを抱え、その間のつなぎを、人間が手作業で行っている組織に、アジリティ（俊敏性）など求めようもないことは、言うまでもありません。

製造業におけるシステム・インテグレーションの中核部分には、基準情報としてのBOM（部品表）データがあります。製造業なら、どの企業も必ず、BOMを持っています（そうでなければ材料も購入できません）。しかし、BOMデータをきちんとマネジメントできている会社は、決して多くないようです。BOMには、受注・製品設計・工程設計・購買・生産管理・製造・品管・物流・保全・サービス・会計と、数多くの部門が、いろいろなフェーズとタイミングで関わるからです。

この問題を多面的に理解するために、2004年に「BOM/部品表入門」を山崎誠氏と共著で出版しました。以来、15年以上が経ちましたが、本書はいまだに現役で、累計1万2千部以上が売れ、中国語版も好評です。それだけ、この問題に悩む企業が多い証拠なのでしょう。

じつは、本書は最初、ERPパッケージの生産管理部分を担当するITエンジニアに対して、その設定方法の基本を教えるための本として、構想しました。BOM構築に悩む企業に、前著「革新的生産スケジューリング入門」の主人公である矢口先生がレクチャーに行き、各部門と対話を行っていく、というスタイルの設定です。

ちなみに、わたしの著書は、前述書をはじめ、「時間管理術」や「世界を動かすプロジェクトマネジメントの教科書」など、なぜかみな、登場人物たちの対話による構成になっています。もしかしたら前世は、売れない劇作家だったのかもしれません(;_;)

ところが書き進めていくうちに、BOMに関する全く違った主張の本に、変わっていきました。BOMは製造業におけるインテグレーションの中核データであり、維持と保守を、特定の外部パッケージソフトに依存するのではなく、自社でBOMプロセッサを構築すべきだ、というのが、本書のたどりついた結論です。

では、具体的にはどうすべきか。もちろん、その企業の生産方式やBOMの特性、そして現状システムのあり方に応じて、答えは千差万別です。ただ、共通の基本概念を理解し、BOM特有の各種テクニックを飲み込んだ上で取り組まなければ、あまりにも非効率でしょう。さらに近年では、BOP（Bill of Process＝工程表）概念の普及や、海外を中心としたPLM（Product Lifecycle Management）ソフトウェアの発達など、この分野で紹介すべき進展もあります。こうした事柄を理解しながら、自社のBOMデータのあるべき姿について、考えるきっかけにしていただければと願う次第です。

BOM/部品表マネジメントに関心のある方のご来聴を、心よりお待ちしております。

＜記＞

(1) 「製造業デジタル化のボトルネックを考える　〜　BOM/部品表のマネジメント入門」

日時：　2020年11月19日(木) 15:00〜16:30

主催：　（株）三菱総合研究所

セミナー：「DX戦略の実現に向けたデータマネジメント　〜　BOM／部品表のマネジメント」

内容：

・製造業デジタル化のボトルネックを考える　〜BOM／部品表のマネジメント入門

　　日揮ホールディングス株式会社　佐藤知一

・サプライチェーンをまたいだデータマネジメントに貢献するSImount（シマント）

　　株式会社シマント　代表取締役　和田 怜

　　株式会社シマント　CTO　渡邉繁樹

　（SImountというユニークなnon-SQLデータベース技術を持つベンチャー企業さんです）

・DX戦略策定と実装

　　株式会社三菱総合研究所　企業DX本部　DX戦略グループリーダ　中西祥介

セミナー申込み：　下記をご参照ください

　https://www.mri.co.jp/seminar/20201119.html

(2) 「BOM／部品表の基礎とBOM構築の成功ポイント」

日時：　2020年11月25日(水) 10:30〜17:30

主催：　日本テクノセンター

本セミナーでは、BOMの基本概念の再整理からはじめて、マテリアル・マスタの統一、BOMの応用テクニック、そしてBOM構築プロジェクトの進め方について、演習をとりまぜつつ、平易に解説します。特に、BOM構築の３つの難所について重点的に説明し、E-BOM/M-BOMの乖離問題などについても、詳しく述べます。一日セミナーですので、じっくりと学ぶには最適です。

なお、量産型製造業だけでなく、拙著「BOM／部品表入門」で触れられなかった個別受注生産でのBOMの取扱いなどにも光を当てて、「自分で考え身につく」セミナーを目指します。

セミナー申込み：　下記をご参照ください（有償です）

https://www.j-techno.co.jp/seminar/seminar-39463/

なお、PC環境等の制限によりオンライン視聴が難しい方は、日本テクノセンター研修室でも受講が可能です。

以上、よろしくお願いします。

　　　　　　　　　　　　　　　（佐藤知一）

＜関連エントリ＞

　→「ふーん、デジタル時代には双方向のインテグレーションが必要って事？」 (2020-11-08)

ふーん、デジタル時代には双方向のインテグレーションが必要って事？

（前回からつづく）

――ええと、今日このDXチームで議論しているうちに、やっと自分の言いたいことがわかってきました。たしかにウチの社内の各システムの間には、インターフェイスはあります。でも、全体がつながるって、別のことだと思うんです。

情シス次長「意味がまだよく分からないけど。」

――つながるって、1方向だけじゃダメだと思うんです。両方向のループになっていないと。最近のデジタル技術、例えばロボットとか、3Dプリンタとか考えてみてください。プログラムが命令をして、ハンドやノズルを動かすんですが、でも対象物の種類や状態を見て、自分の側の動きも調整できるでしょう?

生産技術「フィードバック制御をかける、っていうこと?」

――そうですね、フィードバックです。動く主体と、働きかける対象との間がループになって、対象のデータが戻ってくる点が大切なのです。それによって、次のアクションを変化させます。そうしないと、物理世界とうまく関われないのです。現実社会は変動が大きいですから。それも、速いスピードでフィードバックが戻ってこないと、役に立ちません。

設計「何を言いたいんだね。」

――例えば製造原価の大半は、設計で決まります。設計部門からは、図面と仕様書の形で、情報が工場に渡ってきます。でも設計者の所には、実際の製造原価のデータが戻っていないでしょう?

設計「だから、早く製造原価管理システムを入れるべきだと、さっき言ったばっかりじゃないか」

――はい。だからこれって、片つながりで、フィードバックループになっていないんです。納期についても同じことがいえます。営業さんが受注伝票を起こして、納期を工場に連絡します。でも現実の納期はさっき言ったような状態で、ちゃんと営業さんに返せていません。

営業「それやってくれると、すごく助かるんだけどな」

――品質も同じです。品質の大半は、工程設計で決まります。でも製造記録と品質データがつながっていないので、生産技術に毎回の品質実績を戻すことができません。サービス部門も同様です。保守の指示は工場から出ますが、お客さんの実際の使用状況は、工場にも設計部門にもすぐには戻ってきません。人事採用だって、同じでしょう。

人事「つまり・・」

――つまり全然スピード感がない、ダイナミックじゃない、ってことです。現実の動きに対応して、いろんな部署がつながりあって協力し、即応できるような能力を作るのが、製造業のデジタル化の目的じゃないんですか。デジタルは伝票や月報や喋り言葉よりも、はるかに速いですし、広く伝わりますから。

品管「たしかに、今の仕組みって、受注から始まって、最後の出荷納品まで、いろんな部署のシステムの間を案件の情報が流れていきますけど、バケツリレーっていうか、水が河を流れていくみたいな、一方通行ですね。」

経営企画「そっか！　会社全体がウォーターフォール型なんだ。それをアジャイル型に変えようってこと？　たしかにアジリティって素早さのことですよね。ふんふん、それがさっきのコンサルの人の言っていた、企業のダイナミック・ケイパビリティってことか！」

――かもしれません。中でもとくに、ループが切れていて、データのつながっていないのが、工場の生産管理と製造現場の間なんです。本社の受注オーダーから現場の製造指図につなぐ、生産スケジュールもExcelですし、製造日報と品管日報から製造実績を集計するのもExcelです。

生産技術「ついでに言えば、設計部品表から製造部品表への展開も手作業、製造仕様書からNC加工や搬送ロボットのプログラムも手修正だな」

情シス次長「まあたしかにそれじゃ、アジリティからは全然遠いね。ふーん、デジタル時代には、受注から製造現場、製造現場から顧客サービスの現場まで、双方向でエンド・ツー・エンドのインテグレーションが必要、って事かい。顧客の要求仕様をインプットしたら、工作機械のプログラムや検査器械のセットアップまで、してくれると。そうなりゃカッコいいけど、お金のかかりそうな話だ。」

――でも、すでに海外のライバル会社は、そっちに向かっているような気がします。

営業「それどころか、お客様も最近じゃあ、製品だけじゃなく3D-CADのデータも収めてくれ、なんて言い出しているところがあるよ。今は平身低頭、2次元のCAD図面で勘弁してもらっているけどね」

――あるサプライヤーさんによると、実際、ウチの韓国の競争相手からは、図面のFAXではなく、属性付き3D-CADデータで注文が来るのだそうです。なので、そこから製作図をすぐに展開・作成しているようです。

営業「どうします、設計さん？　既存のCAD図面に手書きでマークアップして、関連部門やサプライヤーに流す時代じゃない、ってさ。最終納品時までに図面をCAD化するんじゃ、時代のスピードに遅れるみたいですよ。」

設計「3D-CAD化は粛々と進めています。しかし、属性まで入力するなんて、技術部の仕事でしょうか。なんでもCADに入力すればいい、というものではないですよ。少なくとも今の人員と出図納期では、とうてい無理です。もし必要なら工場側で入力してほしいです」

生産技術「いや、そもそもCADってのは、図面清書用の道具じゃなくて、CAMとBOM展開のためのフロントエンドとして位置づけてほしいなあ。そうすれば設計納期の考え方も、がらりと変わるもの。」

設計「いや、過去の膨大な設計資産があるのだから、それを活かすことが省力化の道です」

情シス次長「どうやらエンジニアリング・チェーンを製造現場に結びつけるまでには、まだハードルが高そうだね。他に、どこから手を付けたらいいんだろ。」

財務「だから、製造原価管理システムからじゃないですか？」

――やはりそっちの話になってしまうんですね。でも現場の作業時間の実績を取るのが、また難問です・・

品管「あのぉ、質問なんですが、セットアップ時間のコストって、原価はどこにつくんですか？」

生産技術「セットアップって、機械の段取り替えとか、例の画像検査装置の設定替えの作業のこと？　だとしたら、次に作る製品の原価だろうな。」

財務「その製造ロットの原価に計上するのが決まりです」

品管「でもそれって、不思議じゃないですか？　だって、こないだも工場では、午前中にAラインである製品を作って、終わったと思ったら、夕方Cラインで同じ製品を流し始めたんですよ。連続して作れば、セットアップなんて不要なのに」

――客先からの急な飛び込み変更で、生産スケジュールがたまたま、そうなっちゃったんだと思います。なにせウチは多品種ですから。今、部品加工マスタだけで3万点近くあるんです。

品管「それって、作る製品のためのコストなんでしょうか？　セットアップ作業って、工場ではすごく多いんです。それを減らすのも、コストセンターとしての工場の責任範囲なんでしょうか。」

生産技術「もう少し、内作加工で作る部品のバラエティを減らしてもらえると助かるんだけどな。」

設計「設計側としては、個別の客先ニーズに合わせて、部品を1mmでも小さく、1gでも軽くしていくのがミッションです。それが原価低減になるはずじゃないですか。」

――でも確かに、バリエーションが増えると、製造で目に見えないコストがかかるんです。

生産技術「1mm違ったって、NC工作機械のプログラムは書き直さなきゃいけないし、セットアップも変えなきゃならない。コーディングと実作業と教育の手間が増えるよね。」

設計「NCプログラムに、長さのパラメータだけその都度、渡してやるようにできないのか」

生産技術「あのねえ、そもそもNCプログラムってのは、工作機械メーカーによって少しっつ違うんですよ。ウチは昭和時代からの各種機械を大切に使ってるからね。その部品をどの機械にかけるかによって、直す箇所も変わる。どの機械にかけるかは、生産スケジュール次第です。」

設計「だったら、NCプログラムを標準化しておいて、機械ごとに自動コンバータを作ればいいじゃないか。頭を使ってください。」

生産技術「それより、設計で部品をもっと標準化していただけませんか、って言ってるんだけど。」

――そうですね、そうしていただければ、流用設計の手間も減るはずですし。既存の部品を使うほうが、トータルでは安いってことになりませんか。

設計「広い範囲で部品を共通化するのは、今の製品アーキテクチャじゃ無理ですね。設計思想を根本から変えれば別だけれど、そうしたら、過去の設計資産が全部ムダになってしまうから、部門としては絶対に飲めません。それに、そんな事がDXですか」

情シス次長「まあ、多品種化は、製造業の宿命なんじゃないの。」

人事「・・なんだか議論がデッドロックですね。品管さんが去年導入して、コスト低減で社員表彰までもらった画像検査装置なんかは、画像認識でいわばAIの一種なんだから、あれを軸にしてDX展開を考えられませんか？」

品管「DXの目的って、DXをすることなんでしょうか。・・あの、生意気いってすみません。でも、あの装置を入れたのは、コストダウンがねらいじゃないんです。ホントは、あの全品目視検査っていう工程を、なくしたかったからなんです。」

人事「どういう事ですか」

品管「私、工場に配属になって最初にショックを受けたのが、あの検査工程を見たときだったんです。部屋の中に机をぎっしり並べて、大勢の人、それもほぼ女の人ばかりが、一つ一つ部品をチェックしていました。なんだか息が詰まるような気がして。」

生産技術「まあ、あの手の仕事は、忍耐力のある女性向きだからな」

品管「でも、来る日も来る日もずっと、ただ検査用ルーペで部品を全品にらんで、ひたすら欠陥を探すだけの単調な仕事なんです。それって、皆さんは、自分の妹や弟にやらせたい仕事ですか？」

設計「だったらそういう仕事は、中国かベトナムに出せばいいじゃないか」

人事「まあ待ってください。中国人やベトナム人だって人の子ですよ。他に職がなければどんな仕事だってやるでしょうけど、単調でやりがいのない労働って、お金だけが目的になるから、諍いや退職が多くて、労務管理がすごく大変になるんです。」

品管「それで、以来ずっと何年も、あの仕事をなくせないかと考えていました。やっと去年頃から、どうやら何とかウチも手の届く値段で、実用的な精度の機械がでてきたので、誤認識の問題とかいろいろありましたけど、とにかく使えるようにしたんです。」

――それで、精度も上がり、コストも下がったんですよね。

品管「でも、それよりも、単調でつらい仕事を、世の中から一つ減らした、って事のほうが、ホントは自分にとって大切でした。デジタル化って、よく分からないですけど、機械的な労働から人を解放できる、っていう意味なんじゃないでしょうか？」

財務「それがコストに見合えば、ですね」

品管「もちろんそうです。ここは会社ですから。でも工場の中には、目視検査の他にも、人間らしくない仕事がいっぱいあるんです」

経営企画「そういうのって、なんで全部ロボット化できないんですか？　単純にコストの問題？」

――そうでもないと思います。結局、ロボットって、石頭で融通がきかないんです。位置精度も妙に要求が高いし。画像認識もそうですね。それに比べて、人間て器用で臨機応変です。ものを見て、それが何だか判別して、不定形な品物でも適度に手で持って運んでくれますし、位置が少しずれていたって分かります。

生産技術「ロボットって、バリエーションや例外に弱いんだよ。画像認識とか、3Dプリンタとかだって同じ。デジタル化したきゃ、もっと標準化を進めなけりゃ。」

――結局人間がありがたいのは、その場で判断してくれるからです。判断といっても、別に高度なことじゃありません。リンゴかみかんか、皮にキズはあるのか、腐ってたら捨てるべきなのか、たとえて言えばそんな事なんです。

設計「人間の判断には、判別と、決断の2つの面がある。そのうち、判別の方は、AIがだんだんやってくれるようになるから、不要になる。デジタル化で、人間の決断だけが残る、と言うことですか」

品管「決断だって、ルールが決まっていて定量化されていれば、機械に任せられる分はかなり多いと思います」

――そうやって引き算していけば、残るのは、人間が決めるべき大事な決断だけになるでしょうね。データ化とルール化と、自動機械化を進めていけば、人の仕事からきつくて単調な部分が減って、もっと働きやすい職場になるはずです。

人事「デジタル技術は、さっきおっしゃていたように、物理的な世界と直接関わるように進化してきた訳ですから、データ化と自動化によって、人の仕事から、ロボット的な部分を取り除くことになるんですね。それが製造業のデジタル化だと。それって、働くことが楽しい工場・職場を作るんだから、良い話じゃないですか。」

情シス次長「ふーん、そっちの方が近そうだねえ。DXで現場作業のデジタル化かあ。

（そのとき突然、携帯電話が鳴り出す）

はい・・あ、専務！　いえ、まだ打合せの途中で・・え？　はい、それはもう・・。

（後ろを向いてしばらく小声で話してから、急に皆の方を振り返る）

諸君、専務からだ。方針変更だよ。」

全員「ええ！？」

（次回完結）

＜関連エントリ＞

　 (2020-10-24)

　 (2020-11-01)

お知らせ：プラントのレイアウト（Plot Plan）最適設計手法に関するウェビナーを開催します（11月13日11:00〜）

えー、続き物の記事の途中ですが、ここでまたスポンサーからお知らせです（笑）

以前の記事で、設計行為には4つのレベルがある、と書きました。

1.　選択問題（選択的決定）：設計の選択肢からどれかを選ぶ（いわゆるカタログ・エンジニア）

2.　求解問題（演繹的決定）：科学技術計算で、主要な設計変数を逐次導出する

3.　最適問題（最適化決定）：評価関数を最大化する設計変数の組を探索する

4.　システム合成問題　　　：多軸的な評価関数をバランスよく満たすような構造と機構を合成する

この順で、設計は難しくなります。と同時に腕の見せ所でもあり、エンジニアにとって、やりがいが大きくなる訳です。とくに4番目のシステム合成問題は、複数の評価関数をバランスよく満たす必要があり、多目的最適化の考え方が必要になります。

その典型が、工場・プラントの3次元レイアウト設計問題でしょう。工場の全体レイアウト（プラントの場合はプロットプラン=Plot Planと呼びます）を決める仕事は、考慮すべき項目の多い、難しい仕事であり、ふつうはかなりのベテランが取り組みます。

基本的には、工場やプラントの製造工程を構成する機械・装置群を、ムダなく配置し、かつ、モノの流れや人の動線が短く、合理的となるよう設計すれば良いのです。ただし実際には、ある流れを優先すると、別の流れの邪魔をしたり、敷地効率を追求して詰め込みすぎると、機械のメンテに支障をきたしたり、といった問題が発生します。つまり、「あちらを立てればこちらが立たず」＝『トレードオフ現象』が生じるのです。

このような複雑なレイアウト設計問題に対し、コンピュータの力を借りて、最適化問題としてアプローチしようという考えは、以前からありました。しかし、ちょっと調べれば分かりますが、「計算爆発」「次元の呪い」「NP完全問題」など、恐ろしそうな言葉が並ぶ分野です。最適化どころか、実行可能解を一つ求めるだけでも大変という世界でした。

さらに、評価関数が複数あるので、それらの線形荷重和を最小化する、というアプローチが多くとられてきました。でも、それは結局、多目的なモデルの評価を、単一目的の最適化で解いている訳ですから、問題の全体構造を俯瞰して、トレードオフを考たりするのは難しいのです。しかも、配置問題においては、定量化できる評価軸ばかりとは限りません。むしろ、定性的な評価項目も結構多く存在します。

という訳で、やはりレイアウト設計はベテランの経験と勘に頼る、という時代が長く続いてきました。そして人手でやる仕事ですから、案は一つか、せいぜい少し変えた2案を比較する程度が限界でした。

この限界を打ち破りたい、と考えたわたし達は、あらためて問題を根本から考え直してみました。最適化問題は、モデリングが命です。対象の系を、どのような要素に分解するか。それをどう組合せるか。そして制約条件をも、目的関数化できるか。これがポイントです。そして、トレードオフ状況の中で、ユーザが対話的に、もっとも満足できるバランスを探すような仕組みを作りたいと、技術開発を続けてきました。

今回、ようやく、その成果を公開できる段階に達しましたので、一緒に開発してきた同僚・仲間と、ウェビナーを開催することになりました。題して、

【プロットプラン自動設計システム「Auto Plot PATHFINDER」】

〜　プロットプランを最適設計する新しい方法　〜

このセミナーでは、良いプロットプランの条件とは何なのかについて考え、日揮が開発した、最適なプロットプランを設計する新しいシステム「Auto Plot PATHFINDER」について、ご紹介します。またゲストとして、当分野の権威である香川大学教授 荒川雅生氏から「多目的最適化の最新の技法」についての解説もいただきます。

日時：2020年11月13日　11:00 - 12:00 AM

（事前登録制、参加無料です）

講演者：崎山弘道（日揮グローバル）、佐藤知一（日揮ホールディングス）

ゲスト：香川大学教授　荒川雅夫氏

ウェビナー登録サイト

https://us02web.zoom.us/webinar/register/WN_6X-Duk35QmioSt98HMp0Ig

LinkedIn ウェビナー案内

https://www.linkedin.com/posts/jgc_efvegfegkehi-ltihda-it-activity-6725226186445869056-1qE_

なお、内容の概略については、以下の短い動画でのご覧になることができます。

YouTube :

https://youtu.be/SHT_mVu889Y

LinkedIn :

https://www.linkedin.com/posts/jgc_it-iot-itgrandplan-activity-6728908428519067648-_pam

工場・プラントのレイアウト問題に対する、次世代の新しい設計手法にご興味のある皆様の、幅広いご参加をお待ちしております。

日揮ホールディングス（株）　

チーフ・エンジニア（Business Analyst）　佐藤 知一

＜関連エントリ＞

　 (2020-05-07)

　 (2020-05-15)

　 (2020-05-20)

製造業のデータって、ほんとはDXに向いていないのかもしれないね

（前回のあらすじ）あなたは、ある製造業の工場に勤める若手のエンジニアだ。案外パソコンに詳しい、などとおだてられて手製のツールなどを作っているうちに、いつのまにか工場長から『製造IT担当』なる係にされてしまった。なんだか技術者というよりも便利屋みたいだな、などと思いながら、それでも製造ラインのデータを取得するIoTなどの仕組みを工夫したり、生産管理システムの改修要件をとりまとめたりしてきた。

そんなある日、本社から突然、「全社DXチーム」のメンバーに任命されたから会議に来い、と命じられる。専務が委員長で、情報システム部の次長が事務局長だ。社内の主な部署から、若手中堅メンバーが集められている。だが、参加してみたものの、皆、何をすればいいのか思案顔であった。最近のデジタル技術は、従来のサーバとPCの中のITより、現実世界とインタラクションが強い、だからそれを利用すればいい、という意見もでた。だが、あなたは何かまだ「つながりが足りない」と感じて、思わずそう発言した・・

生産技術「つながりが足りない？　よく分からないな。」

――さっき、ウチの現場は生産管理システムで回っていると言いましたが、それは正確じゃありません。実際には、生産管理システムの個別納期を元に、工程担当者がExcelの工程表を毎日作って、現場の職長に配布しているんです。

設計「そんな事してるのか。」

――はい。現場はその表をもとに作業順序を決めますが、都合によっては必ずしもその通り着手しないし、その通り完成できないこともあります。

品管「検査ではねられて、作り直しも結構ありますよね。」

――だから、実際のところは、どのオーダーがどこまで進んで、最終出荷日がいつになるのか、納期に間に合うのか、現場に聞いて回らないとよくわからないのです。

営業「だよな。だからいつもこっちはお客に責められて、こまっちまう、」

――ええ。そこで工程係には「追いかけマン」がいて、進捗確認をして回っています。

経営企画「だったらそれ、現場にカメラつけて進捗データの収集やりません？　AIの画像処理で、追いかけマンに知らせるんです。すごくDXですよ」

――いや、そもそもExcelと進捗の「追いかけマン」は、なんとかやめたいと思ってるんです。ていうより、問題なのは、上位の生産計画と、現場のスケジューリングがスムースにつながっていない事です。ドローンとか3Dプリンタとかいったデジタル技術って、情報処理と物理的な世界が、スムースにつながっているでしょう？　でも、ウチの製造現場はそうなっていないんです。

品管「たしかに製造記録と品質データも、つながっていません。あとでロットをトレースするのが、いつも大変です」

生産技術「設計図とNCのプログラムだって、つながってないぜ。そもそも設計部品表と製造部品表だって、俺達がいちいち、手で変換してるんだからな。勘弁してほしいぜ」

設計「設計部品表は、ちゃんとデータ形式で渡しているはずです。なんで自動変換しないんだ？」

――工場と本社で、部品の品番が合っていないんです。それだけじゃありません。営業の月次販売予測と、工場の生産計画も、合っていません。営業が多めにサバを読むからって、工場側で減らしています。

営業「おいおい、聞き捨てならない事を言ってくれるじゃないか。サバを読んでるだとぉ？」

人事「まあ皆さん、ちょっと落ち着いてください。たしかに、あちこちギャップがあるのは分かりました。でも一応、人が介在するにしても、なんとか仕事は回っている訳ですよね。注文を受けたものが出荷できない、といった事は起きていないんですから。これをもっとつなげるのが、製造IT担当さんのいう、デジタル化なんですか？」

――すみません、ぼくはただ、情報系と物理的な世界が、スムースにつながっていない、という事を言いたかっただけなんですが。

（その時、会議室に情報システム部の次長が、汗をふきふき入ってくる）

情シス次長「いやー、ごめんごめん。廊下で、今度来た常務につかまっちゃってさあ。君、ちょっと一言、とかいわれて、部屋でしぼられちゃって。」

人事「常務って、あの銀行から来られた方ですか？」

情シス次長「そうそう。それで、DXチームを集めて活動をはじめましたと言ったら、SAPの話をされるんだよね。『SAPも十分使いこなせないようだから、日本企業は世界に勝てないんですよ』とか言われてさあ。もう、大汗かいたよ」

財務「SAPだったら、ちゃんと使いこなしてますけれど？」

情シス次長「そりゃ会計と販売は、一応ね。だが、肝心の生産系から購買がつながっていない。だからきちんとした原価管理ができていないんだ、個別の受注が儲かっているのかどうかも分からないで、なにがERPだ、って言われてね。いま全社DXで検討してますからって、やっと逃げてきたよ。いやはや、まいった。」

財務「そんな事、安請合いしないでいただきたいですね。たしかに製造の個別原価管理は、大きい課題だと思っています。ですが、同業他社だって、SAPをそこまで生産系に使い込んでいる会社はないです。」

設計「なぜなんですか。ウチの業界だけが製造業で特殊だとは言えないでしょう。キチンと使いこなせないのは、工場側に問題があるとぼくは思います。」

――でもSAPって、細かな生産スケジュールの変更に弱いって聞いたことがあるんですが。

設計「それは、機械がしょっちゅう故障して止まったり、サプライヤーの納品がしょっちゅう遅れたりするからじゃないのか。工場の管理の問題に思える。」

――それは確かにありますが、仕様変更や急な納期の変更など、工場では抑え切れない原因もあるんです。客先の先行内示と、実需がかなりばらつく問題もあります。

営業「それは、ウチだけじゃ抑え切れないな。お客様の都合だから。」

経営企画「でも、新しいビジネスモデルを創造するために、DXを進めるのが僕らのミッションでしょう？ そのために顧客接点のデータを蓄積して、AIとアジャイルで高速に回すのが、DXの方程式ですよ。せめて製造原価くらいは分析できるんじゃないですか。SAPの受注データと、生産管理システムのデータを組み合わせて、AIで分析すれば。」

人事「そうですね。社内にはすでに、かなりの過去データが溜まっているはずです。ビックデータ解析できるんじゃないですか」

情シス次長「同じことを、さっき常務さんにも言われたよ。でもね、障害が2つあるんだ。1つは、生産管理システムと財務の過去データが、ちゃんとつながっていないこと。ウチの生産管理システムときたら、20年以上前に稼働したレガシーだけれど、SAPは3年前にやっと稼働したからねえ。それ以前の財務データなんて費目コードやフォーマットが違うし。」

経営企画「フォーマット変換とかできないんですか?」

情シス次長「できなくはないが、 別の問題もある。皆さんが思うほど、ウチのデータはビッグじゃないんだよ。」

経営企画「どういうことですか」

情シス次長「ウチみたいな製造業は、データの全体量は多いけど、言って見れば狭くて深いデータなんだよね。受注一件ごとに見れば、受注・設計・購買・生産・検査・出荷… と、つながりは深いけれど、件数が少ない。年間のオーダー数、つまり製番の数は数千の下の方だ。 IT用語で言うと、テーブル数が多くリレーションが深いが、トランザクション数が少ない。たとえてみれば、井戸か洞窟みたいなもんだ。」

経営企画「はあ?」

情シス次長「 AIのいわゆる機械学習は、広くて浅いデータに向いているんだね。つまりデータ項目数は多くても良いが、複雑につながっていないシンプルでフラットなデータが、たくさんある状態に向いているんだ。プールみたいなもんだね。それでも、教師なしデータの学習には、一声、十万件が必要だと言われちゃう。10年分でも、全然足りない」

品管「最近では、GANとかいう、少ないデータでも学習できる技術が出たって、読みましたけど。」

情シス次長「さすがにあなたは、よく勉強しているね。画像処理の分野では、確かに進歩してるらしい。でも、お金や納期の分析の分野では、どうかな。ウチみたいな製造業のデータって、ほんとはDXに向いていないのかもしれないね。もしウチがもっと超大企業なら、件数も多いだろうけど」」

設計「何とかならないんですか?」

情シス次長「教師あり学習なら、もう少し少なくても済むらしいんだ。でも、今度は過去のデータに、僕らが一つ一つ手でラベリングしなければならない。君はそんなこと、やりたくないでしょ? 」

設計「それは技術部の仕事じゃありません」

情シス次長「DXなんて、どこの部の仕事でもないさ。そういえば今朝、家内が、僕の予定表にDXチームって書いてあるのを見て、『このデラックスチームって、何のこと？』って聞いてきたっけ、あっはっは。」

（一同、つまらぬ冗談にしらけつつ、しぶしぶ笑う)

営業「どうするね、製造IT担当さん。つながりが足りないってご説だったけど、むしろつながりが多すぎるってさ。」

情シス次長「つながりが足りないって？ これでも、社内システムのインタフェース構築には、苦労しているんだけどなあ。」

財務「でもかなり、ツギハギなのは事実です。」

品管「とくに工場の中がつながっていないんです。あちこち手作業があって・・どうしてなのかしら？」

――システムは各部の手作りですから。

設計「工場はコストセンターで、その使命はコストダウンじゃないか。なぜ原価管理だけでもまとめられないんだ。」

生産技術「お言葉ですけどねえ、先生。そのコストセンター政策で、3年前にぼくら工場は100％子会社化したじゃないですか。処遇は変わらないけれど、コストセンターなんだから、利益を上げちゃいけない、全部配当で召し上げる、って状態ですよ。どうやって再投資しろって言うんです？」

財務「必要性があれば、本社が投資を負担する決まりになっています。」

――その説明が、難しいんです。システム導入してもすぐ在庫が減る、コストが下がる、と言うような直接効果が見えないものも多いので。

品管「SAPは、入れたら在庫が下がるって話を聞きましたけど、実際はどうだったんですか?」

営業「実際には減っていないね。誰のせいだか知らないけど」

情シス次長「まあ、SAP導入はさあ、アメリカ帰りの管理部長の、鶴の一声で進められたものだからね。社長の息子さんには、誰も逆らえないじゃないか。ああでも言わないと、株主に説明がつかなかったんだよ。」

設計「そうやって、つぎはぎだらけのシステムを作っていくから、インターフェイスがやたらと増えるんです。当社における、長期的なITのグランドデザインが必要ですよ。」

情シス次長「耳の痛いお言葉だけどね。情報システム部も、コストセンター部門なんですよ。ユーザ側からの要求があって、初めてシステム投資ができる決まりです。自分で投資方針を決められないのに、グランドデザインを作るのは、まぁ難しいですね」

人事「なんだかまた、議論が堂々巡りになっていませんか。全体を考える人がいない。だからつぎはぎになっている。でも、つぎはぎでも一応仕事は回っている。だから全体を考える人がいない。」

――・・いや、やっと自分の言いたいことがわかってきました。たしかにインターフェイスはあるんです。でも、全体がつながるって、別のことだと思うんです。」

（もう一度つづく）

＜関連エントリ＞

　(2020-10-24)

　 (2020-10-12)

いや、そもそもデジタル化って、どういう意味なのさ？

――（あわてて会議室に入ってきて、まわりを見渡す） 遅くなって、どうもすみません。急な現場のトラブルで、電話で呼ばれちゃって。・・あれ、もうお客様は帰っちゃいました？

財務「うん、先ほど帰られたよ。」

――そうですか、せっかくの話を聞けなくて、残念です。それと、専務と、情シスの次長は？」

営業「専務はお客様と一緒に行かれた。たぶん今夜は会食するんじゃないかな。情シス次長は、エレベーターホールまでお見送りにいっただけのはずだけど、まだ戻らないね。みんな、待っているんだけどね」

――じゃあ、ぼくらDXチームの社内打合せは、まだ続けるんですね。少し遅れても、来てよかったです。コンサルタントの方々のお話って、どんなでした？

経営企画「いやあ、すごくカッコよかったですよ！　GAFAの戦略からはじまって、VUCAの時代にはイノベーションを起こさないと生き残れない、そのためにはデジタル技術をコアに、スモールスタートでいいから、アジャイルなチームをフェイルファーストで高速に回していく必要がある、魅力的なUXでユーザを巻き込んで、リカレントなビジネスモデルを作るのが『DXの勝利の方程式』だから、皆さんの活動こそ、これからの御社を救う道ですって言われて、僕は感激でした。製造IT担当さん、聞けなくて残念でしたね」

生産技術「うーん、そうかあ？　俺にはピンとこなかったけどねえ。なんだか遠い世界の話みたいで。」

設計「GEの、IoTを使ったデジタルツインの事例は、技術屋として興味深かったですよ。」

経営企画「コマツさんのKOMTRAXの事例も、面白くありませんでした？　製品を売った後まで、サービスとしてビジネスを組み立てられるんですから、すごい先見の明ある戦略ですよ。プラットフォームを制するものは、デジタル時代を制す。僕らもやっぱりプラットフォーマーを目指さなくちゃあ！」

財務「わたしはスペインのBBVA銀行の話は少し聞いていましたけど、詳しく知ったのははじめてです。」

営業「でもねえ。銀行と違って、ウチは消費者相手に物売ってないし。ウチが製品を納める相手はメーカーさんで、基本B2Bだからねえ。便利でカッコいいWebサイト作ったからって、注文はくれないよ。コスト勝負だもの。」

――じゃ、ぼくらはどうやって、DXってのをしたらいいんでしょう？　コンサルの人は何かヒントはくれなかったんですか。

営業「いや。答えを知りたければ、こっから先は有料で、ってことじゃないかな。」

品管「コンサルタントって一般に、答えを考えるのはお客様で、ただ答えをだすのを助けるだけ、って私以前ききましたけれど。」

生産技術「そうなの？　使えねえ奴らだなあ。」

財務「それはケース・バイ・ケースだと思いますが。」

品管「でも結局、考えるのは私達なんじゃないでしょうか。製品も作り方も売り先も、知っているのは私達ですから。」

経営企画「ぼくらが知ってるのは、現状のビジネスですよね。で、現状のままでは先行きがない。だからデジタル技術で変革しよう、というのがDXでしょ？」

――たしかにそうですね。でもなんか、議論が堂々めぐりしていませんか。

人事「今の業務プロセスを洗い直して、デジタル化すべきところを進めましょう、というのがキックオフミーティングでの合意でした。」

生産技術「いや、でも、そもそもデジタル化って、どういう意味なのさ？」

――自分もなんか混乱しているんです。いわゆるIT技術と、デジタル技術って、どこが違うんですか。

営業「さあ〜。情シスの次長さんが帰ってきたら、聞いてみようよ。おんなじだと思うけど。」

経営企画「違いますよ。デジタル技術ってのは、さっきのコンサルの人も話してたように、ディスラプティブ・テクノロジーなんです。つまり破壊的なイノベーションを起こすものです。AIとかクラウドとかドローンとか。AIはコンピュータが目を持つようになって、顔認証とか自動翻訳とか、人間の代わりができるようになってきてます。Uberも、スマホとGPSとクラウドを組み合わせて、タクシー業界を駆逐したでしょう？」

財務「そういえば、コンサルの人、ちょっとゾッとすることを言っていましたね。」

――どんなことですか？

財務「近年の日本では、いろんな業界が衰退したり消滅してますけど、それには順番があるんだそうです。それは、デジタル技術が入ってきた順だというのです。」

――へえ。たとえば、どんなですか？

財務「アナログのレコードは、CDが出てきて駆逐されました。でもCD屋は、音楽のデジタル配信が始まると、売れなくなりました。ビデオ屋も同じです。テープからDVDになり、今はNetflixやYouTubeでレンタルがダメになった、と。」

営業「言われてみると、街の書店もAmazonに駆逐されているし、新聞メディアも同じで、ネット時代は息も絶え絶えだ。」

――つまり情報を扱う産業は、そうなるっていうことですか。

営業「それだけじゃないと思うよ。サービス業もだ。タクシーとUberがいい例だし、ホテル業とAirbnbなんかもそうだね。旅行代理店もネットで比べて買う時代だし。」

――まあ、それもサービスの手配情報とか、価格情報ですからね。サービスそれ自体を、たとえば、マッサージを、全部ロボットがやってくれる訳ではないと思いますけど。まして、ウチは製造業じゃないですか。

財務「でも、そこがポイントなんです。なぜ日本の家電産業がおかしくなっていったか。それは、電子部品が次第にアナログからデジタルにかわっていって、組立や調整が、熟練工の感覚に頼らなくても製造できるようになってきたからだ、というんです。そうなると、製造の競争力は日本国内ではなく、中国やアジアの低賃金国にうつってしまう、と。これが衰退の原因だと説明してました。」

品管「たしかにブラウン管とか、ビデオデッキとか、すごく調整と品質管理が微妙でしょうね。」

財務「自動車産業がまだ日本に残っているのは、機械部品が中心で、多数を順序よく組み立てる部分がまだ、うまくデジタル化できないからだと言ってました。ところが電気自動車の時代になると、もっと部品点数が減って、組立工程もずっとシンプルになるから危ない、と」

生産技術「たしかに他人事じゃねえな。」

――うーん、それだけなんですかねえ。だったら英国のDysonとか米国のTeslaとか、なんで元気なんでしょう。

経営企画「Teslaは自動運転ですもん！　デジタル化の権化ですよ」

――でもDysonのヘアドライヤーは、自動で乾かしてはくれないですよ。掃除機だって、手で持って動かしてます。

設計「あれはまさに、製品設計の力だろうな。やはり製造業は、製品開発が命だから」

人事「そうなると、設計のデジタル化がポイント、ということでしょうか。」

設計「うちの部はそれを見越して、3D-CADへの転換を2年前から着々と進めています。」

生産技術「着々と、ね。だったら2D図面に手書きのマークアップで流してくるのは、いい加減やめてもらいたいもんだ。」

設計「あれは過去の流用設計だからです。設計部門の人員が限られているので、ベストのやり方をしているまでです。それがいやなら、生産側の出図締切をもっと遅らせてほしいですね。」

――まあまあ、ちょっと待ってください。デジタル技術って、従来のITと違うのか同じなのか、という議論をしていたところです。

生産技術「あんた自身はどう思うんだね、製造IT担当さん。誰がどう見たって、製造業DXの中心は、製造現場そのものじゃないか。」

――うーん。正直よく分からないんです。現場にロボットを並べることがデジタル化、とも思えないんです。今でも一応、生産管理システムで作業の指示は回っていますし、実績もとらえています。

生産技術「工作機械だって、ほとんどNC制御化しているし、な。」

――これ以上、どうするとデジタル化なんでしょう。まさか工場内にドローンを飛ばして、進捗管理する訳にも行きません。3Dプリンタだって、まだコスト的に引き合わないですし。

営業「工場内に5Gネットワークとか引けないの？」

――まだ5Gについては勉強不足ですが、そもそもそんな高速なネットワークが必要なほど、トラフィックがないと思っています。

品管「ちょっと待ってください。5G、ドローン、3Dプリンタ・・。えーとそれから、GPS、RFID、ビーコン、スマホ、クラウド、ロボット、自動運転、AIの画像認識ですか。そんなのが、最近、デジタル技術って言われているものですよね。」

経営企画「あと、Uberとか、Airbnbとか」

品管「それは実現したサービスの名前です。技術的な要素は、今挙げたようなものじゃないでしょうか？」

人事「何を言いたいの。」

品管「ええと・・これってみんな、PCの箱の外にあるものですよね。」

（一同）「はあ？？」

品管「あの、つまり、今までのITって、PCの箱の中にあって、動いていたと思うんです。でも、ドローンとか3Dプリンタとかって違うじゃないですか。つまり、私が言いたいのは・・」

――物理世界と直接、関わっている、と。そういう事ですか？　今までのITは、PCやサーバの箱の中にあって、端末画面や印刷帳票だけが、UIだった。でも最近のデジタル技術ってのは、物理世界と直結している。そこが違だ、と。なるほど。

品管「結局、こういう事じゃないでしょうか。今までのITは、インプットは端末で、データ処理して、アウトプットも端末か紙の帳票でした。でも、さっきのリストを整理してみると、こんな風に、インプットやアウトプットが現実世界と接する面が、広がってきています。」

設計「ドローンにしても、ロボットにしても、センサー系と機械系がつながっているのは確かだ。だけどクラウドは、サーバをどこか遠くのデータセンターに移しただけじゃないか。」

品管「・・そうなんですけど、それと5Gや4Gの無線通信のおかげで、データ処理機能を持つデバイスが、どこにでも置けるし、動けるようにもなったと思います。」

生産技術「ふーん。現実世界とインタラクションできるようになった、と。もしそれがデジタル技術の特徴なら、NC制御の工作機械なんて、30年前からあるけど、デジタルだった、ってことになるぜ。あなたが頑張って去年入れた、画像認識の表面検査機だって、デジタル化の先駆けなのかい？」

品管「別にそうは思っていませんでしたけれど・・」

生産技術「ウチの製造現場はそうすると、すごくデジタル化が進んでいたってことになるな。よし、これでこのDXプロジェクトは一件落着、チームは解散だ。飲みに行こうよ（笑）」

――いや、そうは行きません。デジタル化というにはまだ、足りない事があると思います。

生産技術「どういうこと？」

――つながりです。スムースなつながり。

（この項つづく）