2026-03-02T18:42:50+09:00 Tomoichi_Sato タイム・マネジメントとSCM専門家のエッセー・批評・考察集 Excite Blog http://brevis.exblog.jp/33898145/ 2026-02-22T21:57:00+09:00 2026-03-02T18:42:50+09:00 2026-02-22T21:57:12+09:00 Tomoichi_Sato E2 設計のマネジメント

ご存じの通りプロジェクトとは一回限りの、ユニークな仕事（＝他に同一なものが無い仕事）を指します。PMBOK Guide(R)の、「独自のプロダクト、サービス、所産を創造するために実施される有期的な業務」という有名な（そして難解な）定義もまさに、『独自の』『有期的な』という言葉（原語はuniqueとtemporary）で、それを表現しています。


考えてみると設計という仕事は、まさにそのようなプロジェクト的性質を最初から持っています。それは製造業の他の業務と比べると分かります。工場の製造現場では、技能員が全くおなじ部品を繰り返し繰り返し、作っています。しかし技術者が、全くおなじ設計図面を何枚も何枚も作ることは、あり得ません。設計のアウトプットは、必ず（少しであれ）従来のものとは違っていて、つまりユニークです。そして設計業務は基本的に、出図すれば終わりとなる、一過性の業務です。だとすると設計業務は、すべてプロジェクトだと言えるでしょう。


では、設計業務をプロジェクト・マネジメントの視点から動かそうと考える企業は、どれだけいるのでしょうか？　実はこの3月の講演に先立って、KEACの研究会員に簡単なアンケートをしてもらいました。会員メンバーの多くは製造業の設計部門の技術者です（ちなみに、名称には「関西」とありますが、関西以外からの参加者も、それなりにおられるとのこと）。そこから、興味深い事実が見えてきました。


たとえば会社に公式な役職として「プロジェクト・マネージャー」がいるかどうか。皆さんは、どれくらいの比率だと思われますか？　研究会にとっていただいたアンケート結果をここで勝手に公開できないので、数字は当日お話ししますが、かなり少ないのです。プロジェクト的業務なのに、プロマネがいない。その結果、何が起きるでしょうか？


ちなみに、日揮のようなプラント・エンジニアリング業界では、必ず『エンジニアリング・マネージャー』という職種の人たちがいます。プラント系プロジェクトは、大まかに言うと設計（エンジニアリング）のフェーズ、調達フェーズ、建設フェーズに分かれます。その設計フェーズのプロジェクト業務をとりまとめる責任者が、エンジニアリング・マネージャー（略称EM）です。この職種はある意味、プロマネの右腕であり、EM職はプロマネへの登竜門とも言われます。


このエンジニアリング・マネージャーの養成教育について、少し前に調べたことがあるのですが、米国にはちゃんとEM教育のためのコースを持つ大学が存在します。しかし、日本には調べた限り皆無でした。（まあプロマネ教育の専攻コースだって、国内の大学には皆無ですから、推して知るべしですが）


音楽にたとえてみるならば、日本にはヴァイオリンやチェロや金管といった、各種専門分野の教育は存在するけれど（これらが工学部で言う電気とか機械とか土木に相当します）、指揮者を養成教育するコースだけが存在しない訳です。


なぜか？　それは、不要だと思われてきたからでしょう。実際、西洋のオーケストラには指揮者がいますが、日本の雅楽とか能楽の演奏団には、指揮者なんていませんしね。横目でちらと見て、阿吽の呼吸であわせる、と。それで済んできたのです。


しかしそれは小規模で、ゆったりした曲調の場合の話です。曲が複雑・大規模化してスピード感を求められたら、やはり誰かタクトを振るう役割が必要になります。設計もおなじでしょう。複雑化し大規模化し、スピードを求められたら、やはり専門のマネジメントが必要になるのです。日本の製造業の多くは、この変化にまだついて来られずにいるのではないか、と危惧します。じっさい、PLMソフトウェアのベンダーからは、単なる図面管理をこえた、設計進捗管理やBOM展開などの機能を、使いこなせているユーザはまだ少ないと聞いています。


では、設計のプロジェクト・マネジメントとは具体的にどんな仕事なのか。どういう技量が必要なのか。それについて、限られた時間ではありますが、ご説明しようというのが今回の講演です。昨年夏に引き続き、講演にお呼びいただいた関西設計管理研究会（KEAC）さんに、あらためて感謝いたします。




＜記＞


講演タイトル(仮)：「エンジニアリング・マネジメントの役割と価値　〜　プロジェクトの視点から設計をとらえ直す」


日時：2026年3月27日(金) 13:15 ～ 17:00
（わたしの講演は13:40 ～ 15:10の予定です）


開催方法：ハイブリッド開催（リアル70名＋オンライン70名）、研究会員限定

　【リアル会場】京都経済センター 　 ６階　６－C 会議室


主催団体：関西設計管理研究会（KEAC）


開催案内はこちらのページです（注：3月2日に更新されました）
https://keac.jp/archives/event/regular-meeting527　




このテーマに関心のある方のご来聴をお待ちしております。




佐藤知一＠横浜


]]> http://brevis.exblog.jp/33841279/ 2025-12-04T17:54:00+09:00 2025-12-31T11:07:36+09:00 2025-12-04T17:54:23+09:00 Tomoichi_Sato E2 設計のマネジメント

エレベーターに乗っていたら、急に声をかけられた。「今、あの本を読んでます。とっても面白いです。本にしていただいて、ありがたいですよ」。勤務先でのことで、他部署の人だった。あの本、とはもちろん、新著「攻めの工場づくり」のことに違いない。本の中身は100%わたしのオリジナルではなく、会社の多くの同僚との共著だ。それでもまとめた人間としては、単純にうれしい。たとえ職場で、先輩格のわたしへのご挨拶半分だとしても、だ。


でも、なぜ彼は「まとめてくれて、ありがたい」とまで言ったのか？　それは、この本に書いた工場エンジニアリングに関するほとんどの事柄が、社内の暗黙知か、さもなければ部内知識だったからだろう。部内知識とは、その部の書庫かデータベースのどこかには書かれているが、他の部門の人間には検索もできないし、アクセスもしにくいという意味である。


エンジニアリング会社というのは、技術の総合デパートみたいな存在だ。今どきのデパートなら、在庫マスタはどの売り場からでも参照できるだろう。だが社内の知識在庫を参照できる知識在庫マスタは、今のところない（知識在庫の半分以上は、たぶん個人の脳の中にあるし）。そもそも知識って、SQLで値を参照するようには取り出せない。RAGはどうかって？　設計技術は正確性が大事なので、生成AIの中途半端なハルシネーション回答では迷惑だ（そのうち推測確度74%とか、表示されるようになるのだろうか?）。


ともあれ職場では、部門間のインタフェースが一応、Functional WBSを基準にして、業務標準で決まっている。インプットとアウトプットは明確だ。だから他部門の知識の中身まで知らなくても、普通の仕事は回る。それでも部門横断的な知識を総合化した本がありがたいのは、なぜだろうか。単純な知識欲？　それも少しはあるかもしれないが、もう少し別の理由があろう。一般に、三つくらいの動機が、考えられる。




プロジェクト・マネジメントは、広く薄い知識の上に成り立つ


第一の動機は、プロジェクト・マネジメントのためだろう。エンジ会社のプロマネ職は、設計部門のシニアや、販売部門のやり手営業マンの仕事ではなく、独立した専門的職種である。そして独立したキャリアパスがある。とはいえ工場づくりやプラントづくりは、設計→資機材の調達→建設管理、という順番がある。とくに設計には時間と工数がかかり、その品質と出来映えが資機材や工事に直結する。


だから良いプロマネを目指したければ、設計を理解し、その計画立案と予算化ができるようになる必要がある。とくにプロジェクトを構成する様々なアクティビティについて、その時間軸上の前後関係や矛盾を理解し、ボトルネック工程を見極められるかどうかが、大事だ。


たとえば建屋や屋外プラントなどの構築物は、ふつう上物から設計して、それから土台・基礎の設計へと進む。ところが工事は基礎から始めて下から上にしか、進めない。だから、基礎コンクリートの設計・施工がボトルネック工程になりやすい。こうした事を理解するためには、機械・配管・建築・土木など様々な設計について、広く薄く知っておく必要がある。


そして、プロジェクト途上の問題解決をファシリテーションするのも、プロマネの大事な仕事だ。プロマネは全分野の専門家ではないから、すべて自分で問題解決はできない。各専門担当者をつなげて、問題解決をファシリテーションしなければならない。それには、問題事象とその文脈や影響範囲について、広い知識と見通しがいる。




経営企画と投資判断も、広く薄い知識を必要とする


もう一つの動機は、経営企画の仕事のためだ。わたし自身、もう10年以上も経営企画畑で働いてきたので知っているが、この種の仕事は（会社によってバラエティはあれども）自社内の仕事について、広く薄い知識を必要とする。


日本企業の経営企画部門の大きな仕事は、中期経営計画の策定とモニタリングである。すなわち企業経営視点から見た、大きな課題・ニーズの把握と、リソース体制を見通す事、そしてそれを数字に落とし込むのが仕事である。だからどの部署でどんな仕事を何人がかりでやっているのか、理解しなければならない。


もう一つ重要な仕事が、投資判断のサポートである（判断自体は経営層の仕事だが、経営企画部門は事務局的な準備と調整作業を担う）。投資にはいろいろな種類がある。産拠点や営業拠点の新設、設備投資、IT投資、研究開発投資、技術提携からM&Aまで。それら各種案件が生み出すビジネス価値と、必要なコスト・時間が評価できることが大切だ。


企業内のには常に複数の投資案件の候補が動いているから、優先順位を決める必要がある。また進行中の案件リスクを見極め、必要なら中止させることもある。こうした仕事を進めるには、ファイナンスの尺度さえ知っていれば良い訳ではない。社内業務について、広く浅い、しかし構造化された知識が必要なのだ。




設計者が、より良い作り方を知っているとは限らない


だがPMも経営企画も、エレベーターで声を掛けてくれた人のケースには当てはまらないかもしれない。むしろ単純に、良い設計を実現するために、他の部門の知識を知りたいという事だった可能性が高い。だが、なぜ設計に、他の部門の知識が有用なのか。オーケストラでヴァイオリン奏者が、隣のヴィオラ奏者の楽譜をのぞき込むだろうか？　空軍のパイロットが、駆逐艦の操舵を知りたいと思うだろうか？


実はそこが、設計と他の仕事との違いなのだ。設計技術者は、器楽奏者というより作曲家の立場だ。作曲家は、すべての楽器は演奏できないだろうが、楽器と奏法の基本的な特性は知らなければ、オーケストラ曲はかけない。作戦の立案者は、輸送機や駆逐艦の能力や限界について、基本を知らなければ仕事ができない。つまり、実装の基本的なやり方を知らずに、良い設計はできないということだ。


また逆に、実装しやすい設計を目指すことの意義も大きい。もちろん設計の良さには複数の尺度があり、作りやすさだけで良し悪しが決まる訳ではない。それでも工場で加工しやすく組立てやすい製品を設計すれば、コスト・品質・納期では有利である。普通は、設計→製造という風に情報は流れる。しかし設計←製造というフィードバック情報があり、双方向につながることで、より良いものを作る可能性が高まる。


これがアメリカの企業だったら、良い仕事には他分野の知識など邪魔だ、と思われるだろう。専門化と分業化の追求が是とされる文化だからだ。英米企業との仕事の経験からいうと、彼らの情報の流れは完全にウォーターフォール型であり、設計は調達や実装はお構いなし、作りやすいかどうかは関係なく、出図さえすれば問答無用で設計完了となる。日本企業は、程度の差はあれど、もう少し「下流側に優しい」。下流に優しいとは、設計技術者一人ひとりが、実装の苦労を少しは気遣いながら、仕事をするという意味だ。


もっとも、英米企業はその代わり、マネジメントの計画力が高い。個人の優しさではなく、トップダウンの仕組みで実装側の効率性を確保していく（たとえば手待ちを減らす、など）。




双方向の統合のために


やや話がそれたので戻すが、設計と実装では分担の区切りが異なる。設計は機械・電気・制御・・みたいに機能別・工学別なのに、製造は加工・組立・検査みたいな作業種・工程別になる。だから実装を知ってちゃんと理解しようとすると、結局、隣接する設計領域のことも、少しは知らなくてはならなくなる。かくして、良き設計者は、広く薄い知識を得たいという気持ちを持つようになるのだ。


設計とは、Whatを決める仕事だ。それを実装するのは、Howに関わる仕事である。そして情報の双方向のつながりは、組織の統合（もっと言えば「スマートさ」）の尺度である。わたしが危惧するのは、仕事のサイロ化が進んでいる多くの日本企業で、WhatとHowがバラバラになっていく現象だ。


幸いにも拙著「攻めの工場づくり」は、出版直後にAmazonの「コンサルティング」ジャンルでランキング上位にはいった。工場に関する広く薄い知識を提供する本書が、多少なりとも好評を得ている事は、サイロを再統合したいというニーズの表れかもしれない。多少なりとも、この本がお役に立てるなら望外の喜びである。
（なお、紙のペーパーバック版は、順調にいけば12月10日頃から販売開始できる予定です）


＜関連エントリ＞
「新著『攻めの工場づくり』出版のお知らせ」 (2025/11/17)

]]> http://brevis.exblog.jp/33779098/ 2025-09-15T22:18:00+09:00 2025-12-31T11:07:36+09:00 2025-09-15T22:18:32+09:00 Tomoichi_Sato E2 設計のマネジメント


先日行った「PMシンポジウム2025」での講演「PMから見た『設計』論の課題」に 関連して、もう一つだけ考えてみたいことがある。それは設計という仕事の目標、位置づけだ。


わたしは 総合エンジニアリング会社をじにんする勤務先に長年勤めている。社員の8割は技術系で、半分以上が設計の仕事に携わっている。わたし自身も、 キャリアは設計専門部から出発した。プラント・エンジニアリング会社は技術のデパートみたいなもので、多数の専門分野の設計技術者たちが、協力しあって仕事をしている。


設計業務の一番の目的は、新しい設計図面や仕様書を考えて、作成することだ。 そのアウトプットを外部の協力企業や建設部門に渡して、実装してもらう。実装の途上で必要なアドバイスや設計判断をしたり、外部企業の品質レビューを行ったり問題解決をして、出来上がったものがきちんと機能することを検証する（あるいは品質部門に確認してもらう）。では、その目標とは？


設計業務の最大の特徴は、毎回新しいものを作ることだ。ここが製造業務との最大の違いである。工場の製造ラインでは、同一の部品や製品を繰り返し作る。だが、設計では全く同じ図面を繰り返し作る事は決してない。


繰返し性が乏しいから、設計業務はKPI化しにくい。にもかかわらず、現在の多くの企業は目標管理制度を取り入れており、何らかのKPI指標を設定して、個人や部門がその値を達成するよう動機付けしている。そして設計分野で多く用いられるのは、生産性、品質、納期などの指標だ。




詳細設計は一流、しかし基本設計は？



だが、よく考えてみて欲しい。毎回違うものを考えて作るのに、その「生産性」をどうやって定義するのか？　図面1枚あたりの作成に必要だった工数を比べるのか。極端な例を出そう。ゴッホやピカソが、毎回新しいキャンバスに全く違う作品を描くとき、作品ごとに必要だった時間を比べて、どういう意味があるのか。りんごとオレンジを比較するようなものではないか。逆に言うと、KPIを定義できるのは、似たようなものばかり繰り返し作る業務なのである。


ここで仮に、設計業務を基本設計と詳細設計に区分することにする。多くの企業で行われている考え方だ。その線引きをどこにするかは色々と議論があるが、ここでは深入りしない。読書諸賢はおのおの、ご自分の職場で行われている線引きをイメージして考えていただきたい。


こうした区分に従うと、詳細設計は繰返し性がそれなりに高いと言うことができよう。 もちろん、だからといって別に、詳細設計が簡単な仕事だ、などと言うつもりはない。 ただそれは、多数の図面や仕様書やリスト類をデベロップし、プロダクションする仕事だ、と位置づけるだけだ。


そして世界のいろいろな国々でそれなりの年月、仕事をしてきた自分の実感から言うと、日本企業の詳細設計のレベルは第1級である。細かいところまで目配りし、品質を保ち、かつ顧客要求や面倒な基準規制類に合致するよう、プロダクトを作り上げる。工数あたりの生産性も比較的高い。 幸か不幸か、円安と長年の給与抑制策もあって、コスト競争力さえも、今や高いと言えよう。では、基本設計のレベルはどうなのか。




設計の質と位置づけについて（アンケート）



KPIを定義しにくいとしたら、仕事の「質」それ自体を判断するしかあるまい。いいかえれば、会社の中で設計業務が目指すべき役割を、どう位置づけているかだ。そこでPMシンポジウムの講演の中で、あえて「アンケート」のスライドを入れた。以下がその内容である。



本当はリアルタイムに投票と集計ができれば面白かったのだが、それはむりだったので、会場の聴衆に挙手をしてもらった。結果は、基本設計はほとんどが「3」に集中した。詳細設計の方は「2」も少しはあったが、大半は「3」だった。なお参加者の方々の業種は不明である。




なぜ優れた設計が生まれないのか



基本設計に期待される、一番の役割とは何か。それは「新たなカテゴリーの製品を生み出す」ことにある。それにより「顧客が指名して買いに来る」、つまり自社の前に客の行列を作り、単なる価格競争から抜け出すことである。英Dyson社の扇風機が、良い例だ。他社よりずっと高価で、しかも売れている。このような製品を生み出すことが、基本設計の目指すべき姿であるはずだ。


しかし、そのレベルを目指している企業は、決して多くないと思われる。そもそも、そういう風に言語化して、設計業務を位置づけていない。設計とは毎回ユニークな行為であるはずなのに、それを他社との競争の土俵でしか見ていない。競争できるということは、比較可能、つまりたいしてユニーク性がないという意味だ。


詳細設計は一流だが、基本設計は一流とは言えない。これが多くの日本の製造業の現実ではないか。だとしたらまず、設計業務、とくに基本設計の位置づけを正さない限り、製造業の復活などあり得ないはずだ。


では、なぜ日本企業は基本設計力が弱いのか。それはかならずしも、業務の位置づけやKPIの設定だけの理由ではあるまい。一つには人材の問題があろうと思われる。開発・設計部門には優秀な人材を配置する企業が多い。しかしその「優秀」とは、有名大学を良い成績で出たという程度の意味だ。だが日本の受験教育とは、「与えられた枠組みの中で効率的に問題を解く能力」ばかりを要求し、「自分で枠組みを作り出す」ことは、ろくに教えない。それでは、白いキャンバスに新しい絵を描くような創造性は身につくまい。


そしてもう一つ、起用の問題がある。すなわち、本当に有能で創造性の高い設計人材を見いだして抜擢し、設計の自由度や権限を与える体制になっているか、という問題だ。ピラミッド型の序列組織の中で、大勢の守旧的なレビュアーの目を通さないと、案が通らないような仕組みの企業も多い。リスク回避傾向の強い組織で、斬新な基本設計者が頭角を現すのは困難だ。そしてこれはもう、技術の問題ではなく経営の問題である。


適材適所ができるかどうか、職位や経験年数だけでなく真の能力を見いだして任せられるか。それができない組織で、設計の質だけ上げようとしても、それは技術者達に無用なプレッシャーをかけるだけで終わるような気がしてならない。




＜関連エントリ＞
「設計の能力と、設計マネジメントの能力はまったく別物である」 (2025-09-07)
「英国史上、最も偉大な技術リーダーに学ぶべきこと」 (2016-08-28)
]]> http://brevis.exblog.jp/33772495/ 2025-09-07T16:12:00+09:00 2025-12-31T11:07:36+09:00 2025-09-07T16:12:04+09:00 Tomoichi_Sato E2 設計のマネジメント


先日の記事でもお知らせしたように、9月5日に行われた「PMシンポジウム2025」（日本プロジェクトマネジメント協会）で、「PMから見た『設計』論の課題」という講演をさせていただいた。ちょうど台風が関東に近づき天気の良くない中、会場までおいで下さった聴衆の皆さん、またオンラインで参加された皆さんにお礼を申し上げたい（講演自体はまだオンデマンド配信でも視聴可能）。


ちなみに、日本におけるPM業界の事情に詳しくない読者のために、念のためご説明しておくと、今回のシンポジウムを主催したのは、PMAJと略される団体である。'90年代に経産省の肝いりで、（財）エンジニアリング協会のバックアップのもと設立された日本発の団体だ。このほかに、（社）PMI日本支部という大きな団体もあり、こちらはPMIJと略されたりもする。 米国発の世界的な団体であるPMI(Project Management Institute)の日本支部として設立された。


世界的に有名なPM標準であるPMBOK Guide(R)は、後者のPMIが'90年代はじめに米国で制定したもので、PMP資格試験とともに、世界中に広まった。最新版は第7版で、今年中にも第8版が出ると言われている。一方、日本のPMAJの方は、 プログラム・マネジメントを包括した「P2M(Program & Project Management) 標準ガイドブック」を2001年に制定し、昨年第4版を公開した。わたし自身は、第3版の執筆に協力し、第4版はレビュアーとして参画している。


にもかかわらず、今回はあえて、“モダンPMにおけるミッシング・ピースを考える”との副題を付けて、P2MにもPMBOK Guideにも欠けていると思われる、『設計論』をとりあげてお話しさせていただいた。




設計論の課題とは



皆さんにお話ししたかったポイントは、大きく3つある。


(1)成果物の設計は、WBSを通じてプロジェクトの組織や遂行戦略に影響する、ということ。
(2)設計のうち最も価値が高い仕事は、機能を満たすよう形状・構造と制御機構を合成する『逆問題』であって、 それはサイエンスとアートの両面を持つこと。
(3) 設計のマネジメントは、優れた設計を行うこととは別の仕事であって、その中心には設計変更のコントロールがあること。


具体的な内容については、ここでは繰り返さない。講演資料をダウンロードし読んでいただくことも可能だし、本サイトでも折りに触れて記事にしてきた。いい足りない部分は今後も書いていくだろう。


さて、講演の後で何人かの方から、「なぜPM標準には設計が欠けているのでしょう？」という質問をいただいた。わたし自身もPM標準の創世期に直接関わったわけでは無いから、想像でお答えするしかないが、こんなふうに申し上げた：




なぜPM標準には設計が欠けているのか



初期のPMBOKは、建設・エンジニアリング業界や防衛宇宙業界など、受注産業の人々が中心になって作り上げたと聞いている。米国は契約社会で、受注契約時にはかなり明確にスコープを規定する。つまり基本設計や標準仕様や規定類がかなり固まった状態で、契約する訳である。


特に一般建築分野では、英米は明確に設計施工分離の原則で動いており、設計は建築事務所が行う。建設会社には設計部門が存在しない（この点は、設計施工一貫の商習慣も強い日本のゼネコン業界とはだいぶん違っている）。このように設計と施工（広い意味での実装）がフェーズ的に分離しており、企業業種も異なっている。


このような文化の中では、「設計者は自立した知的プロフェッショナル」「実装は力仕事をやるだけ」という風潮も生まれやすい。初期のPM標準を作った人たちは、「バカにするな。実装をきちんと納期通り予算内に仕上げるマネジメントは、大変知的で高度な仕事だぞ」という気概を持って取り組んだ。だから資格名称にも、わざわざProject Management Professionalという語を選んだのだろう。


彼らがPMBOKの主要なマネジメント領域を決めた時（今は10個あるが初期は9個だった）、そこに「調達」があっても「設計」を入れなかったのは、そんな理由からではないか。




設計のマネジメントは、設計分野によって全く異なるのか



こんなふうにご説明したところ、ある方から、「設計と一口に言っても、土木とITシステムでは異なるし、同じくITといっても、業務系と基盤系では全く違う。PM標準は業界に依存しない原則だから、設計については書きようがなかったのではないか」とご指摘いただいた。


もっともなご意見にも思うが、わたしの考えは少し違った。「設計の仕事それ自体は、その通りです。しかし、ここで論じたいのは、プロジェクト・マネジメントにおける設計のあり方、すなわち設計マネジメントです。『マネジメント』の中核は、人に仕事をしてもらう事で、その中身は講演のスライドにも挙げたような項目からなっています。」


設計業務のWBS（作業項目タスクリスト）を作成する
設計のアクティビティに、それぞれの特性に適した担当者をアサインする
設計チームを組織し、基準・ルール等をインプットする
設計対象のボリュームを推算し、工数とスケジュールを見積もる
設計の進捗をモニタリングする
設計の品質をレビューする
設計に関わるインフォメーションと文書・図面類をコントロールする
設計変更をコントロールする
トラブルの問題解決を行い、教訓（LL）をまとめる・・・等々



「設計を一人で完結できるような規模の仕事、たとえば個人の住宅建築とか中小企業の業務システムとかだったら、設計のマネジメントなんて別に要りません。しかし大人数で設計にとりからなければならない規模の仕事では、分担もあるし、期限や予算もあるし、品質も不揃いで変更も起きるし、取りまとめ役が必要です。


講演では大規模プロジェクトのプロマネを、オーケストラの指揮者にたとえましたが、作曲家（＝設計者）と指揮者は別の職能です。作曲者がタクトを振るのがいつでも最善、とは限りません。設計の能力と、設計マネジメントの能力はまったく別物だからです。



もちろん、設計のことを何も知らない人間が、設計マネジメントを完璧にできるとは思っていません。トラブルの問題解決にも、品質れビューにも、作業ボリュームの推算にも、それなりの分野知識と経験が必要です。ですが、設計能力と設計マネジメントの能力の重なりは、仕事の規模が大きくなるほど少なくなります。


わたしの勤務先のプラント・エンジニアリングでは、機械、土木、建築、電気、制御・・と1ダース以上の分野の設計領域が関わってきます。それを取りまとめるのが「エンジニアリング・マネージャー」職種ですが、一人で全部の領域の設計ができるスーパーマンなんて、いません。それでも、相手の用語がわかり、話が通じる程度には知っている。それが、設計マネジメントの仕事です。」


・・とまあ、こんな風なお答えをした。しながら、こう思った。土木プロジェクトとITプロジェクトは全く違う。確かに違うが、だとしたら業界を横断したPM標準など、作りようがないではないか。ただ、そこには共通したマネジメントのスキルと技術がある、とPM界の先人たちは信じた。


マネジメントとは「技術に秀でた者が、人の上に立つ事だ」という、日本社会の信憑も、そろそろ書き換えても良い頃なのではないだろうか？



]]> http://brevis.exblog.jp/33755390/ 2025-08-17T09:15:00+09:00 2025-12-31T11:07:36+09:00 2025-08-17T09:15:42+09:00 Tomoichi_Sato E2 設計のマネジメント

なぜ、PMシンポで『設計論』の話なのか。それは、現代のモダンPMにおいて『設計』に関する記述がまったく欠けているからです。日本プロジェクトマネジメント協会（PMAJ）が昨年刊行した「P2M プログラム＆プロジェクトマネジメント標準ガイドブック」第4版にも「設計」を論じたセクションはありません（それどころか索引にすら「設計」の項はないのです）。米国PMIのPMBOK Guide第7版にもない。欧州IPMAのIndividual Compitence Baseline (ICB) ver. 4にもない。不思議だと思いませんか？　


皆さんの内、設計業務が全くないプロジェクトに従事している方は、どれくらいいらっしゃるでしょうか。図面も全く作らず、仕様書も設計書も全く書かない。ただひたすら構築・製造ないし実装するだけ、という類いのプロジェクトです。作るべきモノに関する記述はすべて、プロジェクトのスタート時点で、完璧にそろっていて渡される。成果物（What）は決まっていて、プロマネは実現方法（How）だけに集中する。そんなプロジェクトです。


少なくとも、わたしはありません。わたしは40年以上にわたり様々なプロジェクトに関わってきましたが、成果物をどうするのか考える必要の無いケースは、一つとしてありませんでした。大筋が決まっている場合でも、細部はいろいろと悩む必要がある。そして細部の決定といえども、プロジェクトのスコープやスケジュールと複雑に関わってくる。設計変更もある。それが普通ではないでしょうか？


成果物の構成と、それが何と何を含むのかの記述を、「成果物スコープ」と呼びます。そして、アウトプットとしての成果物（およびその構成要素）を作り上げるために必要なアクティビティが何と何からなっていて、どれほどのボリュームなのかを記述したものが「プロジェクト・スコープ」です。WBSとはプロジェクト・スコープの構造を示すものですから、設計とプロジェクトWBSは、成果物を通じて、まっすぐつながり合っている訳です。


だとしたらプロジェクトのミッションから、成果物の具体像を作り出す設計業務もまた、モダンPMの重要な要素であるはずです。ここが欠落しているのは奇妙ではありませんか？


ちなみに一般建築の分野では「設計施工分離」原則というものがあります。主に英国で発達し、世界中に影響を与え、日本でも官公庁の建築プロジェクトはこの原則に従うことが義務づけられています。設計は主管の官公庁自身、ないしは設計事務所が行い、建設工事は別契約として入札が行われる、という決まりです。しかし日本のゼネコン業界は多くが、内部に詳細設計機能を抱えています。そうでないと仕事にならないからです。


ITプロジェクトの分野では、「要件定義」と「実現」で契約フェーズを分けることが普通になっており、ちょっとだけ建築分野の設計施工分離を思わせます。では、実現段階で設計は不要か？　もちろん、そんなことはありません。要件定義さえしっかり完成できれば、あとは力仕事・・と思っている人がいたら、ITプロジェクトの現実を知らない人だ、というべきでしょう。


そしてこの設計という行為、何をインプットとし、何をアウトプットして、その間のプロセスはどうなっているのでしょうか？　電気・機械・建築・IT・・と設計分野は様々なのに、共通して論じられることなどあるのでしょうか？　そして優れた設計とはどういうことか、プロジェクトにおける設計マネジメントのポイントは、といった問題を、限られた時間ながら、皆さんと一緒に考えてみたいと思っています。


（ちょっとだけ内容のイメージがわくように、講演用の図を1枚だけサンプルとしてここに紹介しておきます）

日本プロジェクトマネジメント協会（PMAJ）から講演依頼を受けたのは久しぶりです。P2M標準ガイドブックは第3版も第4版も協力してきましたが、今回は自分の話したいテーマを選んで良い、とのオファーでしたので、あえて今のガイドブックで盲点になっている『設計論』を選ばしていただきました。あまのじゃくだって？　どうもすみません。


でもわたしは、今の世の中のPM標準が完成しているとは思っていません。こう主張する論者が日本ではほとんどいないのが残念ですが、モダンPMにはいくつか欠けている大事な要素があり、その一つが設計論だ、というのが今回のテーマです。設計をどうマネジメントすべきか、問題意識をお持ちの方にぜひ、ご参加いただきたいと思います。


＜記＞


「PMシンポジウム 2025　次世代の日本を共に描く」


佐藤知一講演「プロジェクト・マネジメントから見た「設計論」の課題」(SP-23)


日時：2025年9月4日(木) ・5日(金) 9:30 ～ 17:30
（わたしの講演は9月5日(金) 14:00 ～ 15:00 です）


主催団体：日本プロジェクトマネジメント協会（PMAJ）
開催方法：ハイブリッド開催、オンデマンド配信のみの申込も可能

【リアル会場】タワーホール船堀
費用：有料（一般参加可能・会員割引付き）



開催案内と参加申込みはこちらのページからお願いします：

https://www.pmaj.or.jp/sympo/2025/index.html


大勢の方のご来聴をお待ちしております。



佐藤知一＠日揮ホールディングス（株）
]]> http://brevis.exblog.jp/33748384/ 2025-08-08T15:39:00+09:00 2025-12-31T11:07:36+09:00 2025-08-08T15:39:26+09:00 Tomoichi_Sato E2 設計のマネジメント

「基本設計はできるだけ少人数で、やるべきだ」と言う意見がある。私も基本的にはそう思う。「いや理想的には、1人だけでやるのがいい」とおっしゃる方さえいる。理由はシンプルだ。その方が基本設計の整合性が高くなり、一体成形の鋳物のように堅牢になるからだ。これを大人数でバラバラにやると、あちこちに隙間やら歪みが生じやすい。設計思想に一貫性が欠けてくる。


とは言え、大規模な構築物の設計となると、すべてを1人でやるのは現実的ではない。期限の制約もあって、複数人で分担せざるを得なくなる。つまり、平行作業である。プラモデルを手足や胴体や頭の部分に分けて、それぞれ作り上げてから、最後につなぎ合わせるようなことになる。


ところで、設計業務はプラモデル作りとは違って、最初から作るべきものの青写真が決まっているわけではない。むしろその青写真を作るのが仕事なのである(「青写真」なんて言っても死語だよなぁ…今どき実物を見たことのあるエンジニアは、ほとんどいないに違いない）。


ただし、わたしは複数人での基本設計が、良くない面ばかりだ、とは必ずしも思っていない。異なる視点から、多面的に設計を検討できるからだ。わたし達はスーパーマンではない。どうしても一人の視点はある程度、固定されてしまう。だからこそ設計レビューには第三者も呼ぶのだし、レビュー前の作り込みの段階から複眼的な見方ができれば、大きなメリットになる。




データ共有は必要条件だが、十分条件ではない


まして、基本設計と詳細設計の全体をカバーするとなると、やはりチームでの取組みになるのは必然だ（基本設計と詳細設計の区別の問題は、今は深入りせずにおく）。もちろん、同じ設計といっても、土木の鉄骨を設計するのと、ITプログラムを設計するのでは、全くその内容が異なる。とは言え、どんな設計業務にも共通する要素がある。それはアウトプットとして、何らかの設計書、図面類、設計データ、などを生み出す点だ。


土木・機械・電気設計などはいずれも分野固有の図面をつくるし、IT設計だってE-R図やCRUD図などをつくるだろう。工学系ならば3D Modelといったデータ（のセット）も、しばしばつくる。そして図面やモデルだけでは不十分なので、ナラティブな文章による仕様書やテスト計画書なども必要になる。こうした図面・書類・データ類をまとめて、（あまり適切な呼び名ではないが）「設計情報」と呼ぶことにする。


チームで設計する時には、こうした設計情報を共有するツールが必要である。その最も単純なあり方は、ファイルサーバだとか、BOX.comなどのクラウドサービスだ。そこに、作成した設計情報のファイルを保存し共有する。


しかし、やってみると分かるが、これだけではあまり便利ではない。一つは、ファイル名と作成者だけを頼りに、内容を推測するのが難しいことだ。ファイル名の命名ルールなどを設定しても、それなりに限界がある。


このため、「このファイルは、どんな設計情報を記述しているのか」を別途、何らかの形で登録・検索できるようにする機能が望ましくなる。具体的には、タイトルや、図面種別・作成者・作成部署・作成日・・などである。これらを「データに関するデータ」という意味で、『メタデータ』と呼ぶ。共同設計のためのツールには、メタデータの管理機能が必要なのだ。そして、設計情報は「メタデータ」と「実体ファイル」の二本立てになっていく。




共同設計ツールに必要な機能と、運用のためのルール


さて、設計情報は改訂がつきものである。ファイルサーバ上の、同じ名前のファイルが、中身だけ急に最新版に変わったりすると、他の設計者は驚いてしまう。前はどうだったのか、参照したくなるときもある。かくして、バージョンと履歴の機能も欲しくなる。もっといえば、変更箇所の表示もあるとうれしい。


それも、たとえば設計情報の作成者がそのファイルを改訂中の時には、周囲の人間には旧版だけが見えて、改訂を完了したら新版が見えるようになると、うれしい。これを「チェックイン・チェックアウト機能」という。


さらに言うと、ファイル共有サービスはふつう、同一のファイルを複数人で同時に追記・更新できる。これは一元化したリストを共同で登録保守したりするには便利だ。だが、逆に問題となるのは、他人が勝手に設計情報の内容を書き換えたりできることだ。だから共同設計ツールには当然ながら、排他的アクセス・コントロールの機能も必要だ。


とはいえ、設計にはレビューや承認という行為も伴う。だから内容は書き換えないが、「コメントを付ける」機能だけは使えるとうれしい（WordやExcelなどの標準コメント機能では実現は難しい）。承認ワークフロー機能なども、あったら便利だろう。だが同時に、アクセス権や承認に関する、運用ルールも整備が必要になってくる。




設計業務には必ず変更とループが生じる


それでも、ここまでは最近のPDM/PLMツールなどでも、多くは実現できている機能かもしれない。そこでもう少しだけ、設計マネジメントの領域に踏み込んでみよう。チームで取組む設計で、ある程度の規模の仕事では、必ず設計変更の問題が生じる。上流側（基本設計）で作成した設計情報をもとに、下流側（詳細設計）で利用して設計を続けている間に、上流側に変更が起きると、それに対応して下流側も再設計し、変更しなければならない。これをどうコントロールするか。


この設計変更は、もちろん外部要因（顧客の仕様変更要望）でも起こるし、内部要因（上流側の設計ミス発覚）でも起きる。しかしやっかいなのは、設計業務に内在するループで起きる可能性があることだ。内在するループとは何か。それは「全体制約のチェック」である。


設計は部分部分で分担して進めるが、にもかかわらず、設計対象物全体にかかる制約条件がふつう存在する。それは物理的実体なら、たとえば接地面の総荷重かもしれない。必要電力の総量かもしれない。ITシステムなら、たとえばレスポンスタイムかもしれない。こうした重要な負荷量ないし性能値は、全体がそろって初めて計算・チェック可能になる。だからこそ、ここで制約条件を満たせないと、部分に立ち返って設計を見直さざるを得なくなるのだ。


設計変更をコントロールするためには、少なくとも、設計変更の通知発信機能と、そのトラッキング機能が必要だ。関連する全てのメンバー・部署に通知が届いたのか。それも形式的な開封確認ではダメだ。開いてちゃんと内容を理解したことの確認がいる。そして、その変更のインパクト（作業工数やコストやスケジュール影響）の評価、変更作業のステータス、などのトラッキングがいる。


しかも、プロジェクトが変更通知の洪水にならないよう、通知をある程度、制御する（言いかえれば「ためておく」）ことも、時には必要になる。どれくらい、ためるのか。ためれば、遅れる。だが逐次流すと、煩雑になる。それを、重要な負荷量や性能値のトレンドを予測しながら、さばかなければならない。これこそが、設計マネジメントの重要な判断だ。


そして共同設計ツールとは、この設計マネジメントの判断をこそ、サポートできなければならないのである。わたしの知る限り、CADをはじめとする設計用システムベンダーの多くは、設計という業務が、ウォーターフォールのように、きれいに順に流れていくように思っているらしい。いえいえ、とんでもない。「総合エンジニアリング」を標榜する会社に長年勤めているが、設計マネジメントの本質は、変更とループの濁流を、なんとか清流にしようともがき続ける営為なのである。




＜関連エントリ＞
「エンジニアリングとは統合力（インテグレーション能力）である」 (2020-01-12)
]]> http://brevis.exblog.jp/30145307/ 2022-10-15T12:27:00+09:00 2025-12-31T11:07:36+09:00 2022-10-15T12:27:40+09:00 Tomoichi_Sato E2 設計のマネジメント

ところで『エンジニアリング』という言葉には、狭義と広義の二つの意味合いがある。狭義はもちろん「設計業務」の意味だ。だが広義には、プラントなどの対象物の「全体を実現する」意味にも使われる。その場合は、設計のみならず、調達・建設・PMなどの機能も含んでいる。だからこそ、「エンジニアリング会社」と呼ばれるのだ（この用法は、少なくともプラント・エンジニアリング分野では欧米など世界共通である）。


さて、新入社員のわたしは、設計部門、それも最上流の基本設計部門に配属された訳だが、数ヶ月も経たぬうちに、がっかりすることを知った。少なくとも石油精製プラントの世界では、中核となる反応等の製造設備の基本設計は、「ライセンサー」と呼ばれる欧米の技術開発型企業が、先に行ってしまうのだ。


じゃあエンジニアリング会社は何をするのか。その基本設計をデベロップする、あるいは中核設備を支える周辺的な設備を設計する。そして設計に基づいて資機材を調達し、工事会社に建設させる。全体プロジェクトをマネージする。これはこれで、重要な価値ある仕事だ。そう説明された。でも、うーん。基本設計は欧米がやるのかあ。わたしはちょっぴり、落胆した。（ちなみにこの事情は、対象分野によっていろいろ異なる。ただわたしの配属された部署は石油系がメインだった）


職業は何ですかと聞かれたら、「エンジニアです」と今でも答える。だが、わたしが次第にプラント設計の仕事から脱落(?)して、スケジューリングだとかプロジェクト・マネジメントだとかの仕事にシフトしていった最初のきっかけは、そこにあったのかもしれない。


設計部門は重要であると、たいていの製造業は考えている。新卒の最優秀な人材は設計部門に配属する企業も多い。ところで、その最優秀な若手にきくと、設計の仕事は案外つまらない、という感想がかえってきたりする。なぜか。たいていの企業では、すでに過去の多数の設計資産があるからだ。新規の仕事は、その流用設計である可能性が多くなる。あるいは発注先の仕事のチェックとデータの転記入力であるとか。


設計者の醍醐味とは、自分の知恵と創造力を発揮して、新しい製品の仕組みを構想するところにある。もちろん、それが可能になるためには、それなりの分野知識と経験が必要だ。新人が急にできる仕事ではない。だが、そういうキャリアパスが必ずしも見えないのが、多くの若手の悩みではないのか。それはとくに、基本技術を海外から導入した企業ほど、強いかも知れない。


ところで設計部門と製造部門との力関係は、企業や業界によって違う。設計部門が強くて、役員に上がっていくのは設計部門出身者ばかり、というところもある。逆に製造部門が強くて、下手な設計図を出したらボコボコにされる会社もある。


ちなみに欧米のエンジ会社は設計が強く、建設部門（＝製造業の製造部門に相当する）は、出された図面と材料で働くだけ、という感じが強い。逆に日本のエンジ会社は、建設から逆算して、作りやすい設計を、必要なタイミングに出図する習慣が強い。後者の方が、プロジェクト全体としてはまとまりが良く、納期もコストも圧縮できる。


ただしそのかわり、複数部分の設計作業を並行して進めたりするので、上手にやらないと設計変更だらけになって、調達も建設も混乱し、全体が破綻する。錯綜した設計活動をまとめる業務を、「エンジニアリング・マネジメント」と呼ぶ。エンジ業界にはそのプロである「エンジニアリング・マネージャー」職種が存在する。


そういう眼から、製造業の情報化構造を規定した国際標準「ISA-95」を見ると、非常に奇妙なことに気づく。ISA-95には製造にまつわる様々な業務機能が定義され、その関係が規定されているのだが、その中に設計がないのだ。しいていえば、「製品開発」の中に含まれるといえるが、じゃあ工作機械や半導体装置メーカーや造船業が、注文を受ける度に設計する作業は、何なのか？　あれを製品開発と呼ぶのだろうか。

ISA-95はERPとMESの界面を定めているが、設計はそのどちら側に位置するのか？　そしてエンジニアリング・マネジメントの位置づけは？　まことに不思議ではある。



国際標準ISA-95は米国生まれなので、おそらくその背後には、米国流の製造業観があるのだろう。それは何かというと、「エンジニアリング・チェーンとサプライチェーンは独立している」、という考え方である。製品企画から始まって、設計、量産準備、生産、そして改廃までの、製品のライフサイクルをつなぐエンジニアリング・チェーンと、受注から調達、生産を経て保守までのサプライチェーンは、独立した業務サイクルで動いており、両者は生産の一点でクロスする、という発想だ。



このような発想は、iPhoneだとか電気自動車だとかコーラだとか、米国の得意とするB2C製造業の分野では、正しい。だが日本の得意とする工作機械・産業用ロボット・半導体製造装置・制御システムだとかいったB2B分野では、当てはまらない。


サプライチェーン全体を統制する基幹業務システムはERPである。その中で、製造業務の実行段階を担うITシステムがMESである（ISA-95の用語ではMOM）。エンジニアリングチェーンを統括するのはPLM(Product Lifecycle Management)と呼ばれる、設計系のツールである。部品表BOMは、ここから出てくる。


米国流の発想ならば、調達や生産の前に設計はもう終わっているから、ERPとMESだけが同期して連携すれば良い。BOMは事前にERPがPLMから受け取っている（だからISA-95では明示されない）。しかし、日本型のビジネスでは、受注後に個別に設計が関わるケースが多い。そしてその設計が、（たとえ流用設計だらけであったとしても）競争力のベースとなるのだ。だとしたら、エンジニアリングチェーンとサプライチェーンの統合、架け橋は、どのような姿であるべきか？


・・というような問題意識を持ちつつ、今年の6月にドイツのErlangenという街にあるSIEMENS社の工場を訪問した。SIEMENSはご存じの通り幅広い製品ラインを持つ重工メーカーだが、この工場ではまさに問題となる制御システム装置を作っていた。SIEMENSは、PLMソフトウェアも自社で持っている。MESも自社で売っている。ERPはもたないが、SAP社と提携し導入している。


そして彼らも、同じ悩みを持って、製造現場でこの問題に取り組んでいることを知った。なのでエンジニアリング協会で9月に開催したMESに関するシンポジウムでは、オンラインでドイツとつなぎ、その一端を紹介してもいただいた。ということで、そのお返しに(?)、SIEMENS社のオンライン・セミナーで講演させていただくことになった。いや、なりました（ここから急に「ですます調」になります、はい(^^)）。


＜記＞


シーメンス　【サムライDX】Webinar 第4弾
　『次世代スマート工場を実現するために　〜　MESとエンジニアリングチェーンの重要性』


　日時：2022年10月26日（水） 15:00-16:10
　費用：無料
　申込先：シーメンス社セミナー申込みサイト


いつものように、直前のお知らせになり申し訳ありません。
ただ、製造業における個別設計と生産の関わりについて、そしてまた製造のデジタル化について問題意識を持っておられる方に、ぜひ聞いていただきたい内容とするつもりです。シーメンス社のセミナーですが、わたし自身が同社のプロダクトを説明する訳ではありません（できませんし）。お伝えしたいのは、この問題の内包する難しさと、悩みつつも解決に前向きに取り組んでいる会社が、洋の東西にいるという心強い事実です。



関心ある大勢の方のご来聴をお待ちしております。




佐藤知一@日揮ホールディングス（株）
]]> http://brevis.exblog.jp/30020153/ 2022-07-09T12:31:00+09:00 2025-12-31T11:07:36+09:00 2022-07-09T12:31:37+09:00 Tomoichi_Sato E2 設計のマネジメント

次のスライドは、わたしが社内のエンジニア教育用に作った資料の一部である。質問は5問からなっており、いずれも3択問題だ。さて、皆さんなら何と答えるだろうか？




エンジニアで、客先への対応に悩む人は数多い。要求が曖昧模糊としている、気難しい、あるいはすぐ気がが変わる、いや、それどころか、技術をよく知りもしないのに無茶な要求をしてくる・・。


「そういう難しい顧客への対応は、営業の仕事さ」と言い切れる会社や、営業が身を呈して技術を守ってくれる会社に働くエンジニアは、幸せだろうな、と思う。だが大抵の場合、技術的なことに関しては、技術屋がいって説得しなければならない。それどころか、技術リッチな業種では、そもそも売り込み段階からエンジニアが営業に同行して、あれこれと説明したり提案したりするのが普通である。


さて、上記の問いにあげた５つの文章は、いずれもシチュエーションが共通している。いうまでもなく、「お客様に何かを説明しようとしている」文章だ、ということだ。つまり、一種の説得ないし売り込みの状況なのだ。お客様に何かを選んでいただく、決めていただく際に、仕様・特徴・ソリューションの3種類を、意識して使い分けられているかを、上の問題は問うている。


もちろん、この問題に答えるためには、「仕様説明」「特徴説明」「ソリューション説明」が、それぞれ何を意味するかを知らなければならない。仕様も特徴もソリューションも、わたしたちエンジニアが日常的に使う言葉だ。とうぜん皆、知っているつもりであろう。でも、その違いを説明しろと言われて、きちんと答えられるだろうか？


仕様とは、基本的にニュートラルなものだ。それは対象の製品なりサービスなりが、具現化すべき属性を規定している。横幅は50mm以下だとか、素材はステンレスSUS-316Lにしろ、とか、実効通信速度は30 Mbps以上あるべし、といった類いだ。


もちろんステンレス鋼は炭素鋼より値段が高いし腐食に強いから、高級な材料と言ってもいい。だが高級だとか高価だとかは、仕様が問題にすべきことではない。製品・サービスが性能を果たすために必要な条件を規定するのが、仕様だ。データ量から見て、通信速度が10 Mbpsで十分なら、30 Mbpsなどとムダに増量しない。そういう意味で、価値判断からニュートラルなのが、仕様だ。


ちなみに仕様は、形状・素材・構造など「つくり」に関わる条件と、性能・安定性・耐久性など「はたらき」に関わる条件の、2種類に分けることができる。「50mm以内」は、形状すなわち「つくり」に関する仕様で、「30 Mbps以上」は「はたらき」についての仕様だ。


そして設計とは、「はたらき」（＝機能・性能）を実現するために、「つくり」（＝形状・構造）を決める仕事である。だから品質機能展開に見られるように、はたらき系の仕様を先にきめて、それを、つくり系の仕様にブレークダウンしていくことになる。


そしてユーザの立場から見れば、本当は「はたらき」だけを約束してくれれば十分なのだ。だが、性能とか安定性・耐久性といった尺度は、実は非常に多元的なもので、ユーザや作り手があまり想定しないような使用シチュエーションもありうる。そうした際にも、製品が有用となり、害をなさないように、「つくり」に注文をつけておくことが、しばしば起きるのである。


では、特徴とは何か？　特徴とは、いうまでもなく、「他との際だった違い」を表す属性だ。つまり何か他に比べるべき製品・サービスがあり、それとの違い、それも優位な違いを示すのが、特徴である。世の中の普通や、比較する相手がなければ、特徴はいえない。もしも「50 mm以内」が競合製品に比べて優位に小さいなら、それは特徴と言って良い。


ただ、特徴を説明する時は、その違いを強調するようなニュアンスが必要だ。だから「この装置にはオプションが12種類あります」では、ただのニュートラルな仕様説明になってしまう。せめて、「この装置には12種類ものオプションがあります」と言わないと、特徴を訴えることにはならない。


では、ソリューションとは何なのか。この言葉は、昔はIT業界専用の用語だったが、今はずいぶん広い範囲で使われている。「お客様への最適なソリューションを提供します」「わが社はソリューション・プロバイダーとして・・」などなど。ただ元々の意味は、『解決』である。すなわちソリューションとは、問題解決に役立つものでなければならない。誰の問題？　もちろん相手（客先）の、である。


問題というのは、「本来あるはずの姿」と思っている事と、現実のとの間にギャップがある状態を指す。ちゃんと製品を納品した。ところが顧客は「品質不良だ」と突き返してきた。たしかに、これは問題だ。


ただし問題とは、当事者がそう意識していなければ、問題にはならない。電車が5分遅れた、問題だ、と感じるのは、電車が時刻表通りに来るのが当然だ、という社会にいるからだ。あなたが中東や南米で生まれ育ったら、5分遅れは上出来じゃないか、と感じるかもしれない。


「弊社の設計部門は、お客様のご要望でしたら何でも承ります」は、ソリューションの説明だろうか？　それは、顧客が「近頃の業者は設計への要望を、こころよく聞いてくれない」という問題意識を持っていることが明白な場合だけ、ソリューション説明になる。あるいはせめて、「同業他社は設計への注文をあまり聞かないのが普通だ」という業界認識があるなら、特徴説明になろう。もし、どちらも不確かならば、それは単なる仕様説明でしかない。


そして、ここまでの説明を読んでこられた読者ならば、すでにご賢察のことと思うが、他人に何かを提案し、説得し、選んでもらうためには、「ソリューション説明」でなければならないのだ。繰り返すが、仕様説明はニュートラルなものである。また特徴説明は、他との違いをいいはするが、それが相手のニーズ・問題意識にマッチするとは、限らない。人が何かを選び、何かを買うのは、自分のニーズを満たし、自分の問題を解決してくれるとの希望を持てる場合に限る。


ここまでにあげた仕様・特徴・ソリューションは、よくマーケティングの分野で言われるFAB、すなわち「フィーチャー」「アドバンテージ」「ベネフィット」の概念に、ほぼ相当する（なお、これに「エビデンス」を加えて、FABEと呼ぶケースもある）。


ちなみに、マーケティング分野では、顧客にはまずベネフィットから説明しろ（Start with Why）、それからアドバンテージ（How）・フィーチャー（What）を補足しろ、とアドバイスする。なぜなら顧客は忙しく、辛抱強くこちらの言葉に最後まで耳を傾けてくれるとは限らないからだ。だから一番訴えかける、大事なことを先にいえ、と。


そして、このアドバイスは、顧客に提案するとき以外にも通用する。たとえば、上司を説得するとき。予算の追加や人の配員を求めるのには、まず上司の説得が必要だろう。また、社内に新しいことを提起するときもある。仕事のシステムを変えたり、取組への協力を求める際も、やはり「抵抗勢力」を説得しなければならない。


こう考えてみると、エンジニアの仕事では、単なる顧客への対応を超えて、いろいろな場面で「アイデアの売り込み・説得」、すなわちマーケティングのためのコミュニケーション・スキルが重要になるのだ。


最後に、ちょっとだけ頭の体操をしてみよう。
「他のみんなも使っています」
「競合他社も皆やっています」
という文章は、仕様だろうか、特徴だろうか、はたまたソリューションだろうか？　この言葉は、現実にはけっこう有効な、セールスの殺し文句であったりする。


たとえば例を考えてみてほしい。誰もが持っているもの、あって当然だと感じるもの、たとえばスマホでもいい、車のカーナビでも良い。あるいは企業にとってのERPでもいい。どれも昔はなかった。


だが、「今ではみんな使っています」は、単純な仕様でも、特徴の説明でも、ソリューションでもなさそうな気がする。どれでもなかったなら、いったい何なのか？　そして、なぜ、それがマーケティングの切り札になりえるのだろうか。霞ヶ関の人の話では、「同じ施策を中国でもやり始めています。このままでは追い抜かれます」が、今や予算獲得の一番のセールスポイントなのだそうだ（苦笑）。もしもこれがソリューション説明だとすると、わたし達の抱える「問題」とは何なのか。


問題とは、「当然あるはずの姿」と、現実とのギャップのことだった。わたし達の『当然』とは何で、それは言語化されているのかどうか、たまには立ち止まって考えてみるのも、有益ではないだろうか。


＜関連エントリ＞
　 (2021-06-19)


]]> http://brevis.exblog.jp/29886038/ 2022-04-02T17:41:00+09:00 2025-12-31T11:07:36+09:00 2022-04-02T17:41:09+09:00 Tomoichi_Sato E2 設計のマネジメント



エンジニアリング会社で、それなりに長い間、働いてきた。昨日、4月1日は入社式の日だ。自分のときもそうだった。考えてみるとずいぶん昔のことだが、なんだか、ついこの間のようにも感じる。


率直に言うと、同じ会社でこんなに長く働くとは思っていなかった。エンジニアリング会社は受注産業だ。仕事が取れなくなれば、すぐに倒産する。入社したときに、「この会社は3年もつだろうか」と思ったことを記憶している。


長く働く間に、わたしも人並みに「よそに転職しようか」と思わなかった訳ではない。だが、製造業にも建設業にも、コンサルティング会社にもIT企業にも転じなかったのは、やはり「エンジニアリング」という仕事に、それなりにこだわりをもっていたからである。


幸いわたしの選んだ勤務先は、3年以内に倒産することもなく、しぶとく生き延びている。1928年が創業だから、あと6年で創業100周年を迎える計算だ。ずいぶん長寿とも言えよう。


とはいえ、プラント・エンジニアリング業界は、今や大きな曲がり角に来ている。本当に、さらに次の100年を越せるだろうか。


いや、組織の存続は大事だが、それ自体が目的（「パーパス」）ではない。存続自体が会社の自己目的化してはいけない。ただ、『エンジニアリング』という仕事が、次の100年間、どうなるのか・どうなるべきかを考えるのは、頭の体操としてムダではあるまい。わたしは一介の会社員だが、あえて今、もしもエンジニアリング会社をゼロから作るなら、どういう設計をするか思考実験してみよう。


そもそも、現在のエンジニアリング会社とはどういうビジネスなのか？


「エンジニアリング会社とは、工場づくり・プラントづくりのプロフェッショナル集団です」ーー自分の会社を紹介するときに、わたしはよくこういう言い方をする。


ただし、自社では工場を持たないし、建設労働者も抱えていない。工場のための資機材は、すべて外部のメーカーから調達する。建設工事も実際の作業は地域の工事業者に頼み、自社では建設工事管理をやっている。


社内にいるのは純粋に、ホワイトカラー層だけである。オフィスを見学してもらっても、机と椅子が並んでいるのみだ。自社でやる仕事は、主に設計とプロジェクト・マネジメント。これで金を稼いでいる。


設計（Engineering）と、調達（Procurement）・建設（Construction）がメインなので、通称、EPCビジネスとも呼ばれる。でも、実はE・P・Cをつなげる機能として、プロジェクト・マネジメント（PM）がつねに重要な役割をもつ。


ちなみに正確に言うと、作るものは、工場・プラントとは限らない。研究所の建物などもよく作っているし、わたし自身、病院づくりに携わったこともある。鉄道や空港・新交通システムなども、ターゲットの内だ。


これらに共通するのは、ある程度の規模があり、かつ技術的に複雑だと言う点である。それも、機械・電気・土木・建築・化学・制御など、複数領域の技術が関わるような複雑さだ。そうした技術リッチで複雑なものを作りたいときに、エンジニアリング会社が呼ばれる。


裏を返せば、複数領域の幅広いエンジニアを抱えている点が、「総合エンジニアリング」企業の特徴である。ほとんど大学の工学部の全学科が集まっているような感じだ。




エンジニアリング会社の系譜

今、「総合エンジニアリング会社」という言葉を使ったが、世の中には「エンジニアリング」を標榜する企業は数多い。


実はわたしの義理の弟も、少し前に「エンジニアリング」を名前に含む、小さな会社を立ち上げた（義弟は雑誌「トランジスタ技術」の編集長だったが、その前は電子技術者だった）。仕事の内容は、電子回路の設計、並びに関連する研修セミナーなどのビジネスである。こうした会社を、仮に「専門エンジニアリング企業」と呼ぶことにしよう。電子回路の設計は、もちろん立派なエンジニアリングである。ただ、技術メニューは、電子工学という特化した1つの領域にある。


これに対し、総合エンジニアリング企業は、非常に幅広い技術分野のポートフォリオを持っている。それはもともと、石油・化学プラントが、それだけ様々な技術の組合せを必要とするからだ。


日本には、通称「プラント御三家」と呼ばれる総合エンジニアリング企業が3社ある。千代田化工建設と、東洋エンジニアリングと、わたしの勤務先・日揮だ。この3社とも、プラント・ビジネスを中心にして成長してきた。


もともと、千代田化工建設は三菱石油のプラント工務部門が独立してできた会社であった。また東洋エンジニアリングは、「東洋高圧」という化学会社のプラント工務部門が母体である（東洋高圧はその後、三井系と合併して「三井東圧」となり、現在は「三井化学」に吸収されている）。


工務部門とは、製造業の生産技術部門の一部である。生産技術部門は、製造業において、ものづくりのプロセスや技術を考案し、製造設備や装置を設計し、発注・据付け・工事管理・試運転立ち上げなどを行う部署だ。工務はとくに、製造現場における業務に携わり、様々な発注先や業者のマネジメントなどを行う。


つまり総合エンジニアリング会社とは、製造業の生産技術部門が独立して、他社の仕事も受け入れるようになり、アウトソース先として独立した業態となったものを指すのである。


もちろん千代田化工建設も東洋エンジニアリングも、母体であった三菱系や三井系に限らず、どこの顧客の仕事も受け入れて行っている（しかも、いずれの会社も今や、海外の仕事の比率が8割以上なので、そもそも日本の財閥系などと限ってはいられない）。


3社の中で、日揮だけは少し系譜が異なっている。日揮は設立時の社名を「日本揮発油」と言った。揮発油とはガソリンのことである。もともと創業者は、自動車の増大を見越して、ガソリンを製造販売する会社を作ろうと思い立ったのだ。そのために米国の大手石油会社から、ガソリン製造プラントのライセンス技術を導入した。


ところがその後、いろいろな経緯からガソリン製造プラントを自社で持てないまま、ライセンス技術に従ってプラントを設計し顧客におさめるビジネスになっていった。こうなると名前が実態と合わなくなってきたので、70年代の中頃に略称の「日揮」に社名を変更したのである。


3社とも、戦後の高度成長期に、重化学工業の拡大とともに業容を拡大してきた。その後、オイルショックなどで国内投資が鈍化すると、各社とも生き残りをかけて海外に進出した。もちろんその道のりは平坦でなかったが、幸い各社とも成功して、今では世界的なプレイヤーとなっている。


石油会社や化学会社の生産技術・工務部門が子会社化し、独立したエンジニアリング企業となっているところは、他にも多数ある。ただし、その多くは親会社向けのビジネスに依存しており、他の企業や海外から仕事を受注し自立している会社は、必ずしも多くない。


なお別の系譜で、製鉄メーカーの工務・保全部門がエンジニアリング会社として独立しているケースもある。JFEエンジニアリングや日鉄エンジニアリングがその代表格である。製鉄プラントとプロセスプラントでは、基本となる技術が相当に異なるが、大規模で複雑な点は共通している。


さらに言うと、重工メーカー、造船業、そして大手ゼネコンの一部なども、エンジニアリング・ビジネスを提供しており、上記のエンジニアリング会社と競合する部分もある。




エンジニアリングのビジネスモデル

エンジニアリング企業は、多くの場合、二通りのビジネスで収益を得ている。 1つ目は、プラントや生産設備など、ハードウェアを顧客に納品して代金を得るものだ。成果物契約といってもいい。 2つ目は、エンジニアリングをプロフェッショナル・サービスとして顧客に提供するもので、こちらは人件費を主体とした実費償還型契約である。


いずれの場合も、仕事は普通プロジェクト単位になる。プロジェクトとは、時限的・一過性の、ユニーク（個別的）な仕事である。エンジニアリングには、同一品種大量生産がない。これは設計と言う仕事の中身を考えてみればわかるだろう。設計においては、全く同一の図面を繰り返し何枚も作成する事はありえない。作成する図面は、すべて個別であり他とは違っている。工場のように同じ製品をいくつも繰り返し作るビジネスとは、根本的に異なっている。


このためエンジニアリング・ビジネスでは、プロジェクト・マネジメント能力が必須の要素となる。


もともと、わたしがエンジニアリング企業に入ったのは、自分の専門が化学プラントの設計論である化学工学科だったこともあるが、プロジェクトをやりたかったからだ。大学のサークルでやった、イベント的なプロジェクトの成功が、自分の原体験にある。人間が1人でできる事は限られている。だが人と協力できれば、その枠は大きく伸ばすことができる。それがプロジェクトだ。そのことを学んだわたしは、社会でも、プロジェクトに関わりたいと思った。


そしてそれ以来、何十年もの間、ずっとプロジェクトに関わり続けている。プロジェクト・マネジメントをテーマに、学位も取った。


別にプロジェクトを遂行する業種はエンジニアリングに限らないが、その規模と複雑性では、やはり右に出るものは少ないだろう。それくらい難しいが、面白いテーマでもあるのだ。




もしもエンジニアリング会社をゼロから作るなら

さて、今、エンジニアリングと言うビジネスを再設計するなら、どんな風な構想を持つべきか。


まず、わたしなら、設計するだけのデザインハウスは作らない。世の中は、「ファブレス企業」やアウトソーシングが大流行りだ。ある種の高付加価値な専門機能に特化して、それ以外の部分は、外部に発注し、安いところに競わせる。それが現代風の経営思想だと言われている。だが、わたしはこのような発想には反対だ。


どんな設計も、完全ではない。これがわたしの長年の実感だ。その不完全な部分は、実装の段階に入って初めて気がつくことが多い。また実装段階の品質が、基本設計の良し悪しに大きく依存するのもしばしば経験することだ。だから、製造や据付工事といった、実装段階の業務から、設計に対するこまめなフィードバックループをきかせることが、設計能力向上の必須の条件だと考えている。


これは英国流の、設計と施工を分離し、設計業者に施工を監視させる発想とは随分異なっている。この裏には、「施工業者性悪説」のような感覚が潜んでいるように思われる。日本でも、頭脳労働を尊び、手を汚す現場の力仕事を蔑視する風潮が、どこかにある。エリート大学出の戦略コンサルタントたちが、しばしば「ファブレス」を賞賛する背景には、こうした感覚もあるのではないか。


それはともかく、エンジニアリングと言う仕事の中核には、インテグレーションの能力がある。ここで言うインテグレーションには、成果物を構成する複数のサブシステム同士をつないだり、異なる技術領域をつないだりすることに加えて、設計・製造・施工・運転の異なるフェーズをつなぐ意味も込めている。


そうした観点から、エンジニアリングを支える一番根底の技術として、「システムズ・エンジニアリング」（Systems Engineering＝システム工学） を掲げたい。これからのエンジニアリング企業とは、基本的にすべて、システムズ・エンジニアリング会社たるべきなのである。


なお、ここでいうシステムズ・エンジニアリングとは、航空宇宙産業などの分野の概念で、複雑な機能と構造を持つ人工物を作り上げる仕事を指す。もちろん人工衛星のみならず、プロセス・プラントも「システム」の一種である。決してIT業界のSEの仕事の意味ではないことに留意されたい。


そしてわたしの見解では、このシステムズ・エンジニアリングはまだまだ未完成である。その事は、MITの分厚い教科書の1ページ目を見てがっかりした経験、にはじまる記事でも書いた通りである。だから未来のエンジニアリング企業の重要なミッションは、この未成熟な技術体系を発展整備していくことにある。


なお設計業務それ自体は、今後のデジタル技術の進展とともに、より自動化が進んでいくだろう。自動設計への道は決して平坦ではないし、現在の機械学習を中心としたAIは、まだパターン認識が中心で、設計を自動化するには非力である。だが強化学習と量子コンピューターの組み合わせは、いずれ設計領域を、かなり機械化していくと思われる。


ではそうなったときに、人間に残される仕事は何なのか。それは2つある。設計成果物を評価する価値判断と、リスクへの感覚である。


設計成果物の評価は本質的に多元的であり、設計とは多目的最適化に他ならない。この時、どれを優先しどれを劣後させるのかの判断は、やはり人間に委ねられる。


そして、いかなる設計も完全ではない。設計の入力条件も、不確実性を伴う。環境も、プロジェクトの途中で変化する。そしてプロジェクトは個別性が高く、繰り返し性に乏しい。したがって、この先どのようなリスクが潜んでいるかについての感覚も、経験のある人間の直感に頼ることになる。


リスクはさらに、技術的リスクと遂行上のリスクに分けることができる。技術リスクとは文字通り、技術的理由で設計目的が達せられない可能性である。遂行リスクとは、技術面がOKでも、コストが守れなかったり納期に遅れたりする可能性である。


ところでビジネスの利益とは、ある意味リスクの上手な処し方によって生み出されるというのが、わたしの考え方である（「リスク確率に基づくプロジェクト・マネジメントの研究」参照のこと）。他社がリスクが高いと感じる業務領域を、自社だけが低リスクで実行できるなら、そこに価値が生まれる。


こう考えると、将来のエンジニアリング産業は、技術リスクに強い企業と、遂行リスクに強い企業に分化している可能性がある。前者を支えるのは、固有技術とシステムズ・エンジニアリング能力である。後者を支えるのはプロジェクト・マネジメント能力である。前者は技術サービス提供型ビジネスを営み、後者はプロジェクト・マネジメントサービスを提供したり、成果物契約によって報酬を得るスタイルになっているであろう。


ただし、誤解しないでいただきたい。後者のようなプロジェクト・マネジメントサービスを提供するためには、優秀なプロジェクト・マネージャーがいるだけでは不十分である。異なる技術機能を受け持つ複数部署が、強調して動きながら、最後に矛盾が噴出しないためには、それぞれの機能を受け持つエンジニアたちが、互いにリスペクトしながら仕事を進める必要がある。


例えば、「ここでこういう設計にしておくと、下流部門がこういう苦労をするかもしれないので、少し余裕を持った設計をしておこう」といった配慮ができることが、プロジェクトでは大事なのである。つまりプロジェクト・マネジメント能力とは、組織全体の能力なのだ。そして、それを支えるのは相互評価と信頼である。


デジタル化が進んだ将来、ギグワーカーを集めて、プラットフォームを経由して、ワークパッケージを発注しつないでいけば、エンジニアを抱えないエンジニアリング会社が成立するかもしれない、といった予測がある。いや、きっと中国あたりでは、すでにそんな企業が出てきているに違いない。だが、わたしがあまりそうした可能性に怯えていないのは、エンジニアリングの根底に、人間同士の相互信頼が必要だと信じているからだ。


それはちょうど、オーケストラのようなものである。オーケストラのパフォーマンスは、指揮者1人で決まるわけではない。全員が一糸乱れなく、協調して動くことができる。このオーケストラの能力がなければ、どんな指揮者も実力を発揮することができない。


日本人技術者は、このような面では、比較的優れた能力を発揮できる。それは日本文化の特徴なのだろう。世界を見渡してみると、日本以外に、イタリア・フランス・スペインなどラテン文化圏に、プロジェクト・マネジメント能力の卓越したエンジニアリング企業が存在しているが、これも文化的なものなのかもしれない。欧米企業は卓越した設計能力を持っているが、協調して動くと言う面は、いささか薄いと感じられる。


このような協調性の高い組織を、文化を超えて運営するには、どのような制度設計と評価制度をとるべきかも、重要で興味深い問題だ。だが、ずいぶん長くなってしまったので、これについては省略しよう。


将来、いわゆる化石燃料型のプラント需要が衰退していても、高度なインテグレーションを要する技術的な仕組みを構築する仕事は、相変わらず残るだろう。システムズ・エンジニアリングも現在より、はるかに発展しているはずである。そこでの収益向上やビジネスのあり方は、現在とは随分違っているかもしれない。だがエンジニアリングという仕事は100年後も残っているだろう。また、残していかなければならない。そのために、何ができるだろうか。


桜咲く遊歩道の新入社員たちを見ながら、わたしはまだ、考え続けている。




＜関連エントリ＞
　 (2022-02-19)
]]> http://brevis.exblog.jp/29192203/ 2020-09-24T18:18:00+09:00 2025-12-31T11:07:36+09:00 2020-09-24T12:51:48+09:00 Tomoichi_Sato E2 設計のマネジメント

「プロジェクト＆プログラム・アナリシス研究部会」の2020年第3回会合を開催いたします。COVID-19感染症問題がなかなか落ち着きを見せないため、研究会日程が定まらず、前回からまた間が空いてしまいました。今回もオンライン開催といたしますので、ご了承ください。


現在のモダンPM論は、設計のマネジメントという重要な仕事について、ほとんど何も語っていません。この問題は、以前から指摘してきたとおりです。エンジニアなら誰でも知っている通り、設計は構築・実装のあり方の大勢を決めます。ですから、きちんとプロジェクトを進めたければ、まず良い設計をすることが先決です。ダメな設計を受け取って、「あとはよろしく」と言われたって、プロマネとしてできることは限られているからです。


しかし、この自明の理に正面から向き合って、プロジェクト・マネジメントを論じる人はわずかです。PMBOK Guide(R) の規定している10のマネジメント知識エリアにも、『設計のマネジメント』は含まれていません。PMBOKの次期・第7版は、従来の構成を根底から変え、プロセスベースから原則（Principle）ベースに転換すると言われています（10の「知識エリア」は、なくなる見込みです）。しかし、現時点では、プロジェクト・デリバリーの原則の中にも、設計論は見当たらないようです。


プロジェクトの成果物が価値あるアウトカムを生み出すためには、その設計が重要です。しかし現実のエンジニアは、過去の事例のコピー＆ペーストや、外注先との折衝・チェックといった仕事に忙殺されているようです。設計の業務プロセス自体が、個別化・属人化している事の現れかもしれません。まして、肝心の設計ロジックの構築や、その伝承理解に使える時間は限られています。


今回は、自動車メーカーの設計部門を経験した後、大手ITベンダーでPLM等のコンサルティングに従事してこられた西本明弘様に、設計プロセスの分析・最適化技法である「Design Structure Matrix (DSM)」手法についてご講演いただきます。
昨年12月の梓澤様のご講演に続いて、「設計論シリーズ」の第2弾となる企画です。どうぞ、ぜひご期待ください。




＜記＞


■日時：2020年10月8日（木）　19:00～20:15


■講演タイトル：
「Design Structure Matrix（以下DSM）の概要と応用～テレワーク時代のプロジェクト管理手法～」


■概要：
設計・開発プロセスは暗黙的かつ多職種連携で、手戻り要因も判りづらい。また、テレワーク時代で細かなコミュニケーションもとりづらく、プロジェクト運営のリスクは増している。
そこで、設計工学手法DSMを応用し、設計プロセス全体を俯瞰してプロジェクトを最適計画＆省力運営（PMの負担軽減）する方法について解説する。


■講師：プロセス設計塾　代表　西本 明弘
　
■講師略歴：
三菱自動車にて小型トラック・バスのシャシーフレーム設計。　　　
IBMにて金融・POSプリンター、自動改頁機構、漢字OCRスキャナーなどの開発。 　　　
IBMにてPLMコンサルタントの後、プロセス設計塾を開業。
２００３年より研究しているDSMを用いて、複雑な業務プロセスの改善を支援中。


■シスコシステムズさんのご厚意により、WebExを用いた、オンライン開催となります。
　研究会への参加は、下記のURLからご登録ください。
　https://cisco.webex.com/cisco-jp/onstage/g.php?MTID=e443dbddae5b20e52710ba4d88867c30a
　はじめてWebexに参加される方は、下記の説明資料も御覧ください（Dropboxへのサインインは不要です）。
　https://www.dropbox.com/s/w7sggz1jbkw1iu6/PPA_HowToRegsiter4WebexEvent.pdf?dl=0


　なお、オンライン形式のため、リアルの研究会よりも講演時間は少し短縮しています。ただし、講演とQ&A終了後、希望者だけで別途、オンライン懇親会を行う予定です。


■参加費用：無料。
　ちなみに本研究部会員がスケジューリング学会に新たに参加される場合、学会の入会金（¥1,000）は免除されます。
　
　以上、よろしくお願いいたします。




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


]]> http://brevis.exblog.jp/29167392/ 2020-09-05T15:00:00+09:00 2025-12-31T11:07:36+09:00 2020-09-05T14:44:49+09:00 Tomoichi_Sato E2 設計のマネジメント

製品のコストと品質の殆どを決める設計段階でこそ、知恵を出すことが重要である。一般消費者向けのB2Cビジネスでは、製品・サービスの評価や売れ筋から、設計の良し悪しが、すぐ分かる。良い設計はビジネスの結果にダイレクトにつながって現れる。


だがB2Bビジネス、たとえばSI業界の分野などでは、顧客要求をもとに設計をした後、その基本設計書からRFPを作って複数社に引合いを行うのが通例だ。たとえ良い設計をしても、それは価格競争というレース場への、入場券にしかならない。結局は安い単価で実装をオファーできるところが勝って、利益を得る構図になる。SI以外の業界でも、受注産業のB2Bでは、似たような事例を見かけることが少なくない。


だとしたら、誰が好き好んで設計の技を磨こうとするだろうか。良い設計が、利益という形で自分たちのビジネスの評価につながらないなら、誰がエンジニアなどという職種を目指すだろうか？　日本の産業の技術力が下がっていく一因は、ここにある。


とはいえ、このような問題は、必ずしも日本だけで起きるわけではない（日本社会の固有の特殊性については、後で触れる）。設計段階と実装段階が分離され、途中に価格競争のプロセスが挟まるような慣習のある分野では、どこでも生じがちである。わたしの働いているエンジニアリング業界だって、そうだ。


プラント・エンジニアリングの業界の仕事の流れは、ある意味、SI業界とよく似ている。図を見てほしい。エンジ業界におけるプラントの基本設計は、FEED (Front-end engineering design)と略称されるが、IT業界における「要件定義」段階にほぼ、相当する。顧客はどんな製品を年産何万トンほしいか、程度のイメージしかなく、どのようなプラントの機能構成で、どう実現するかは、この基本設計=FEEDの段階で決まる。

FEEDの作業が終わり、基本設計書が出来上がると、それをもとに投資額を見積もる。これは通常、複数のエンジニアリング会社をよんで、競争入札の形で行う。その上で、（普通は最安値をオファーした企業の価格をもとに）投資判断であるFID (Final Investment Decision)を行う。これは、SI分野で、FRPを元に複数SIerから提案価格を受け取り、その中から1社を選んで、投資判断するのと同じである。


そして、次に実装の段階が来る。プラントの場合は、詳細設計・調達・建設の仕事になる。Engineering, Procurement & Constructionの略をとって、EPCと呼ぶ。SIでいう開発段階、すなわち設計・実装・テストの各段階に相当する。この段階は、一括請負契約で行われるケースが通例だ（例外もあるが）。


プラントの場合、建設を終え、溶接などの品質検査と機能テストを終えると、このEPCの構築段階は終了になる。これをMechanical Completion = MCと呼ぶ。ちょうどITシステムの結合テスト・総合テストの完了にほぼ相当する。ここでプラントは顧客に引き渡され、立上げ（Start-up）段階に入る。そして実際の原料をプラントに導入し、操業の人員を配置して、100%稼働になるまで立ち上げていく。パフォーマンス・テストなどもここで行われる。


いわゆるエンジニアリング会社が活躍するのは、基本設計(FEED)段階と、詳細設計・調達・建設(EPC)段階である。ただ、前者は設計なのでほとんどが人件費なのに対し、後者は資機材を買って現地で工事するので、報酬の対価はかなり大きくなる。したがって、ビジネス的な利益は、EPC段階の方が魅力的に見える（赤字リスクだって大きいが）。


前者のFEED=設計段階で仕事を得るポイントは、もちろん設計能力である。他方、後者のEPC段階で仕事を勝ち取る主な要因は、価格競争力とプロジェクト・マネジメント能力だ。そして設計段階で、いかに良い設計アイデアを出しても、その成果は入札書類の形で、ライバルを含む入札企業全員に共有されてしまう。もちろん、価格競争に勝てなければ、どんなに良い設計をしても、EPC構築段階は受注できない。


このような慣習が続いた結果、何が起きたか。プラント業界の仕組みを見ると、いかにも「設計能力に秀でた企業に基本設計をやらせ、コスト・マネジメントに強い企業に構築段階を任せるのだから、ベストな設計のプラントを一番安く手に入れられる」ように見えるだろう。


だが、現実には、違う結果が生み出されるようになっていった。実際にしばしば起きたのは、品質の低下とスケジュールの遅延だった。なぜか？


まず起きたのは、エンジ会社の専門分化（すみ分け）だった。欧米系のエンジ企業は、設計には秀でているが、人件費が高いので、コスト競争力が弱い。彼らの中には、FEED段階の仕事のみに特化するものが増えてきた。他方、韓国を含むアジアのエンジ会社などは、技術的差別化よりも価格競争に強みを見出して、EPC段階をもっぱら狙うようになった。


その結果、構築段階での経験が、基本設計に反映されにくくなった。当たり前だが、本当は「建設しやすい設計」「立上げ・運転しやすい設計」こそが、真の意味でコストダウンにつながる。だから建設や試運転部門から、いろいろ文句をつけられてはじめて、設計技術者も育っていくのだ。


だが自分で実装・構築しない会社が、設計だけやるようになると、そのフィードバックループが切れてしまう。設計図面が「絵に描いた餅」になりやすい。こうした危険性は、実装を知らないアナリストが作る要件定義書の危なっかしさ、という点でIT業界の人にも理解できると思う。


かくして、基本設計に隠れた品質問題を抱えながら、熾烈な価格競争でEPC構築段階の契約を勝ち取ったエンジ会社は、どうなるか。もちろん、途中でどんどん設計変更問題が生じる。人も足りなくなる。だが、全体は一括請負契約になっている。追加交渉だって時間がかかる。かくして、赤字と納期遅延がしばしば生じるようになった。


こうした状況の遠因は、基本設計と構築実装の分業化にある。基本設計でいくら知恵を出しても、それが構築ビジネスにつながらず、直接の利益にもならない。誰が苦労して、良い知恵を出そうとするだろうか？


ところで、（ようやく本題に入るが）プラント・エンジニアリング業界で近年行われている『競争的基本設計』（Competitive FEED）という方式は、この壁に風穴を開けるものだった。


『競争的基本設計』では、まずエンジ会社を2〜3社選び出し、彼らに並行して基本設計（FEED）を行わせる。無論、ライバル同士がどのような設計をしているかは、お互いに知りえない。基本設計がおわったら、各社に、自分たちの設計をベースにしたコスト見積を行わせる。そして、技術面およびコスト面で優れた方を選び、そこにEPC構築を任せるのである。敗退した方にも、基本設計の費用は支払う。


この方式のメリットは明らかだろう。設計で良いアイデアを出した企業が、構築段階の仕事を受注できる。構築をよく知らないと、プラントを要求性能通り、しかし安価に作る設計はできない。しかも自分の基本設計を自分が実装するのだから、ヘマな設計をしたら自らの首を絞めるだけだ。また、コスト競争と言っても、単なる単価の安値だけではなく、設計能力を含めた総合力が問われるのである。


ちなみに、こういうやり方をすると、調達・建設コストダウンを追求するあまり、実際の運転段階にはいってからの操業コストや保全コストがかえって高くつくような設計が、生まれる可能性がある。そこで顧客は、投資額（Capital expenditure = CAPEX）と、運転コスト (Operational expenditure = OPEX)の両方を見積らせ、総合的に勘案して比較を行うのが通例だ。


なお、『競争的基本設計』が行われる背景として、プラントの基本的な技術（プロセス・ライセンス）を比較選定したい、というニーズも強い。たとえば液化天然ガス(LNG)分野では、APCIとかPhilipsとかLindeといったライセンサーがいて、競い合っている。IT業界でいうと、SAPやOracleなどパッケージ・ソフトウェアの選定に相当する。そこで、ぞれぞれを得意とするエンジ企業を1社ずつ選んで、競争的基本設計を行わせるのである。


こう書くと、いい事ずくめのように聞こえるかもしれない。だが、このやり方にも限界があることは、指摘しておこう。


一番の問題は、発注する顧客側の手間がかかることである。基本設計を二重・三重に進めるのだから、当然である。基本設計をするためには、顧客側の技術者がかなり、はりついてインプットを与え、適時レビューし、注文をつけなければならない。それを公平に、かつ同時に進めるのだ。


そして基本設計費用だって、2倍ないし3倍かかるわけである（大型プラントの場合、基本設計だけで数億から十数億かかる）。良い知恵を得るため、とはいえ、構築段階のコスト競争で差があまり出なかったら、何を得したのか分からなくなってしまう。


また、ある程度分業化の進んでしまったエンジ業界において、このような『競争的基本設計』を発注できる相手もまた、限られてくる。日本のエンジ会社は比較的、設計も構築も両方できるが、世界を見渡すと、そういうプレイヤーばかりではない。基本設計はあまり得意でないが、価格競争では非常に突っ込んでくる新興国のエンジ企業を、うまく使って安く仕上げたい、と考える購買責任者だって、発注側には、いるだろう。


ひるがえって、日本のSI業界で、この競争的基本設計の方式を取れるかと言うと、なかなか微妙だと思える。要件定義を二重、あるいは三重に、進められるだけの発注側企業が、どれだけいるだろうか。また基本設計費用をダブルで・あるいはトリプルで払う案を、経営者はのめるだろうか。そして、何よりも、出てきた基本設計書と見積書を、きちんと適切に比較できるだろうか？　いずれも可能性はあるが、ハードルは高い。


こうして書いていくと、＜設計の知恵を、リアルな価値に変える＞ための、真の障害がどこにあるか、分かってくる。それは、実は発注者側の技術的能力にあるのだ。発注者側の能力が高く、設計にもちゃんと口を出せ、コストや納期を決める技術要因も熟知し、かつ、きちんと構築・実装段階のプロジェクトを、発注側としてうまくマネージできる能力があれば、たしかに、望ましい結果を得られるだろう。たとえ競争的基本設計方式をとらずとも、技術の目利きがあるのだから、良い設計にはきちんと評価とビジネス的なリワード（継続的な発注と育成など）を工夫できるはずだ。


だが、発注者側に技術能力が欠けていて、自分が何を望んでいるのかもよく分からず、提案の技術評価もうまくできないまま、業者選定に入るようだったら、どうなるか。技術の目利きの不足の代わりに、購買のコストダウン交渉が上手ならいい、と経営が考えている場合、どういう結果が生じやすいか。読者諸賢ならば想像がつくだろう。


設計の価値というのは、対象が単純で、結果が目の前にできあがっており、かつ自分が使い方に熟知しているものほど、分かりやすい。設計の良し悪しが、B2Cの消費財やサービスで、すぐ結果に出るのはこのためだ。


逆にいうと、対象が複雑なシステムであり、かつまだ設計書の段階で、しかも機能や使い方が広範囲でイメージしにくいものほど、設計の良否を評価するのは難しくなる。B2Bでは基本要件は顧客から与えられるから、設計の自由度もおのずから絞られる。では、これを正しく評価できるのは、どんな人間か？


当たり前だが、設計の価値が一番良く分かるのは、優れた技術者なのである。優れた、というのは、それがどう作られ、どう使われるかも熟知した技術者、という意味である。発注者の側に、そうした技術者がいることが、実は業界全体の技術レベルを上げるためには、死活的に重要なのだ。


良い技術者をを育てるには時間がかかる。職場環境という土壌を整え、仕事という水をやり、報酬という肥料を与えても、技術の花が咲き、知恵の実がなるまでは年月がかかる。それを惜しんで、「技術がほしければ、世界中の良い技術をカネで買ってきて使えばいいじゃないか」とする気短な発想だけでは、自国の社会の中から技術がしぼんでいくのだ。ちょうど肥沃な耕適地を耕さずに、海外から安価な商品作物だけ輸入すればいい、と考えている国のようだ。


技術とは自らの能力を増強するイネーブラーである。もし産業界がそれを必須と考えるならば、技術の価値をビジネス上の報いに直結させる仕組みを、ぜひとも工夫すべきであろう。そして、そうした知恵を出すことこそ、経済団体や官界の仕事ではないだろうか？




＜関連エントリ＞
　→「設計の価値」(2006-01-01)
　→「設計の知恵を、リアルな価値に変えるために 〜 問題の所在」 (2020-08-22)


]]> http://brevis.exblog.jp/29149025/ 2020-08-22T20:18:00+09:00 2025-12-31T11:07:36+09:00 2020-08-22T19:29:38+09:00 Tomoichi_Sato E2 設計のマネジメント


評価という言葉には、いろいろな意味がある。同僚や周囲からリスペクトされるのも、評価だ。新しい重要な仕事のリーダー格に取り立てられたり、昇進するのも、評価だ。もちろん、給料やボーナスに反映されるのも、評価だ。ともあれ、優れた知恵を出したら、尊敬され、リーダー役に抜擢され、ちゃんと経済的にも報われるべきだ。つまり、良い設計の知恵は、リアルな価値に、ちゃんと具現化されてほしい。


だが、そうあってほしいと感じる人が多いのだとしたら、それは逆に、世の中はそうなっていない、という事の証拠であろう。自分の身の回りを見る限り、あんまりそうなっていないな、なんとも世の中アンフェアだ。それが多くのエンジニアの実感ではないか？


*** *** ***


「SIer」という業態は、本当に将来性があるのか、という質問を、SI業界の人に会うたびに、何年も前からするようになっている。説明の要はないと思うが、SIとはシステム・インテグレーションSystems Integratrionの略で、ITシステムの受託開発ビジネスを指す。そしてSIer（エスアイヤーと読む）は、それを業としている会社のことだ。将来性があるのかという質問は、もう少し今風に表現するなら、『サステイナブルなビジネス』なのか、ということだ。


こういう質問をすると、SI業界の人はたいてい、苦笑いしたような表情になって、「そうですねえ・・」と言葉を探す。「もちろんですよ！」という希望と自信にあふれた答えがかえってくることは、まずない。「正直、将来性は無いんじゃないでしょうか」と、ぼそっとつぶやかれることもある（もちろん会社の会議室ではなく、懇親会の席上であったりはするが）。そういう状況だから、優秀な若手人材も、なかなか集めにくいという問題が生じる。


ITとかデジタル技術とかいうのは、時代の先端をゆく技術分野である。そして知恵のカタマリであるはずのシステムを作っている。なのに、なぜ、将来性があるかという質問に、前向きな答えが来ないのか。なぜ有能な若手にそっぽを向かれるのか？　それは、受注型プロジェクトで金を稼ぐ、この業界の構造ないし行動習慣に問題があると、多くの人が認識しているからだ。


日本のIT業界の特徴は、ITエンジニアの大半（約7割）が、ITベンダー側に属していて、ユーザ企業側にはそれほどいない事である。これについては、元日経コンピュータ編集長の谷島宣之氏が『ソフトを他人に作らせる日本、自分で作る米国』 という興味深い本を著して以来、広く知られるようになった。つまり、企業内の業務システムの殆どは、自社内で作るのではなく、外部のIT企業に作らせるのである。そこで、ITシステム開発（システム・インテグレーション）は、受注型プロジェクトとして遂行されることになる。


別に内製ではなく外注でもいいじゃないか、大規模なシステム開発プロジェクトなんて、普通は何年に一回しか無い。その時のために、ITエンジニアを大勢、社内に抱えておくのはもったいない。――そういう意見だって、もちろんあるだろう。


ついでにいうと、上述の谷島宣之氏の著書によると、米国では日本と逆に、ITエンジニアの7割がユーザ企業にいて、自社のシステム開発プロジェクトに携わっていると書かれている。それはそのとおりだが、米国では企業間の転職が多く、プロマネ職種の人達も、渡り鳥のように案件単位であの会社からこの会社へと、わたっていくことが少なくない。ある意味、彼らだって「外の人」なのである。


だから、日本のSI分野の問題は、内製か外注かにあるのではない。実は、「設計で知恵を出しても、ビジネスとして評価されにくい」点に、根本原因があるのだ。エンジニア個人の評価が、最終的にはポジションや給料で決まるように、企業の評価は、利益を出したり、継続的に良い条件で仕事をもらえるか、という点で測られる。つまり、ビジネスとしてのサステナビリティである。


今日のITシステムの開発は、ふつう「要件定義」段階と、「実装」段階とで、契約フェーズを分けて、進められる。これは、たとえば製造業やエンジニアリング産業における、「基本設計」と「製造・構築」に相当すると思えばいい。当然ながら、要件定義（＝基本設計）段階は、全体に占める割合は小さい。そして実装（＝製造・構築）段階は、はるかに金額が大きくなる。まあ、一桁くらい違っても不思議ではない。


ちなみに、現在の業務系システム開発の多くは、まるきりゼロからプログラムコードを書く、いわゆる「スクラッチ開発」をするケースは多くない。しばしばパッケージ・ソフト、ないし開発フレームワークがあって、それをベースにFit & Gap分析などをしながら、要件定義を進め、コンフィギュレーションやアドオンで実装をする、というスタイルだ。


「要件定義書」が出来上がり、それを核とした提案依頼書（RFP=Request for Proposal）がワンセット揃ったら、複数のSIerに競争見積を出す、というのが今の主流のスタイルだ。


要件定義段階は、いわゆる「準委任契約」で進められる（これは製造・エンジニアリング産業における「実費償還契約 Reimbursable contract」とほぼ同じだが、日本のIT業界はなぜか、準委任という民法用語を好んで使う）。だから受注側に赤字リスクは小さいが、金額も小さいので、旨味が少ない。


ビジネス的に売上が大きくなり、かつ、うまくやれば利益も大きくなるのは、実装段階の一括請負契約である。だからSI業界では、要件定義はある意味、「海老で鯛を釣る」ためのエビであって、本当の狙いは、実装というタイを釣り上げることにある。


SI業界は「人月商売」、と揶揄されることもある。人月（man-month）とは、作業量の単位だ。これに単価をかければ、すなわち売上額になる。だから、なるべく受託側としては要件定義段階で、開発に要する規模＝人月を大きくした上で、実装の仕事を一括請負型プロジェクトで受託し、そこで売上と利益を確保したい、という思考習慣が強い。


もちろん発注側としては、それではたまらないので、同じスコープ（役務範囲≒作業量）ならば、なるべく単価の安いところに発注しようと考える。だから複数のSIerに引合いを出し、価格競争に持ち込もうとする。そして受託側は、単価を下げるために、たとえばオフショア開発などの比率を上げて価格競争力確保にいそしむ、ということに相成る。


以上のプロセスの、どこに「知恵を価値に変える」部分があるだろうか。要件定義段階で良い基本設計をして、少ない労力で開発できたり、運用保守のコストが低減できたりしたとして、それはどこで誰が評価してくれるのだろうか？


図を見てほしい。これは経産省の『ものづくり白書』2020年版の、第1部第1章3節に掲げられた図だ（ちなみに、今年の「ものづくり白書」は例年以上に、面白い）。

出展: 経済産業省『ものづくり白書』2020年版　図132-1


これは製造業におけるものづくりのプロセスを例に取っているため、横軸は「企画→製品設計→工程設計→製造」となっている。読者諸賢は、SIその他、ご自分のよく知っている分野に置き換えてみてほしい。


ともあれ、仕事のプロセスの進展とともに、設計の自由度は減っていき、逆に出来上がるアウトプットの品質・コストはどんどんと確定度が上がっていく。そして、設計段階で品質・コストの8割が決まる。設計の終わりをどこに置くのか、8割という数字が妥当かどうかは議論の余地があろうが、この傾向自体に反論する技術者は少ないだろう。


だから、製品のコストと品質の殆どを決める設計段階で、知恵を出すことが重要なのだ。そして、そこで出した知恵こそが、利益や、リカレントな受注という、ビジネス上のリアルな価値に直結してほしい。それが、エンジニアの共通の願いである。


ここまで、SI業界を俎上に上げて、人月ボリューム志向のビジネス慣習が、いかに設計の価値を阻害し、最終的には優秀な人材の離反を招いているか、論じてきた。SI業界の読者の中には、不快に思った方もいるだろう。じゃあ、お前のいるエンジ業界はどうなんだ。あるいは、製造業や、他の業界はどうなんだ、と。


実は、その問題構造は通底している、というのがわたしの認識である。プラント・エンジニアリング業界のプロジェクトのあり方は、意外なほど、SI業界のあり方に似ている。だから、わたし達も実は、よく似た悩みを抱えている。


そして製造業、とくに日本が得意とする部品・素材業界も、やはり設計の知恵をリアルなビジネス価値に結びつける点で、悪戦苦闘しているように思える。部品・素材業界は、多くは受注ビジネスだ。顧客である自動車会社や電機会社の要望する特性・品質の材料部品を、個別の要求に応じて設計し、毎月の注文に応じて生産している。つまり、同じようにB2Bビジネスをしている訳だ。


そして、製品の企画・設計段階から、ユーザ企業に呼ばれて、いろいろ要望を出され、対応するために知恵を絞って、部品材料を設計提案する。もちろん試作もする。でもって、めでたく採用かと思った段階で、購買部門が出てきて、他社との価格競争に巻き込まれるのだ。設計の知恵は、ようするに価格競争というレース場への、入場券でしかない。こういう事例を、ときおり耳にする。


このような状態が、あちらの業界でもこちらの業界でも生じているのだとしたら、誰が喜んでエンジニアなどという職種になりたがるだろうか？　知恵を出しても、会社の利益にもならず、当然、自分の評価にもつながらない。


経済団体やら識者らが、ときおり、日本の技術力の低下について、嘆くことがある。まあ、世のおじさん達の頭の中では、未だに日本は「技術一流、政治三流」みたいな信仰が残っているらしいが、技術の現場で走り回っている若手中堅の実感とは、相当に開きがあるだろう。今、日本のIT技術が、世界で超一流と思っているITエンジニアって、どれだけいるだろうか？


本来、経済団体などは、そういう業界構造やビジネス慣習を改革するためのイニシアチブを取るべき立場にあるはずだ。だが、どうやら、日本の技術をめぐる、根本問題の所在に気づいていないらしい。


では、問題の在り処を理解したとして、具体的には、どうすべきか。


システム開発の外注をやめて、全部内製化し、それもアジャイル開発でMVP(Minimal viable product)を短期間にローンチし、UI/UXを磨いてユーザをひきつけ、新しいビジネスを切り開けばいい、というのが、現在出回っている回答の一つだ。いわゆるデジタル・トランスフォーメーション（DX）戦略である。


なるほど、確かに、設計や実装におけるアイデアを、すぐにビジネス価値につなげられる方法である。ただし、このやり方、万能ではない。まず、すべての業務システムがアジャイル開発に向いている訳ではない。また、とくに、B2B業界でのカスタマーとの関係のあり方を考えると（←まさにこの点が、上述した問題の根本原因なのだ）、カッコいいUXだけでビジネスを引きつけられる訳でもない。


では、どうしたら良いのか。他に何か、良い知恵はないのか。長くなってきたので、わたしの業界における一つの取組み、『競争的基本設計』（Competitive FEED）について紹介した上で、この問題の出口について考えてみることにしよう。


（この項続く）




＜関連エントリ＞
　→「サービス経済から、ふたたび実物経済の時代へ」 (2020-04-23)


]]> http://brevis.exblog.jp/29020929/ 2020-05-24T23:12:00+09:00 2025-12-31T11:07:36+09:00 2020-05-24T22:47:03+09:00 Tomoichi_Sato E2 設計のマネジメント

――おやおや。何かご相談があるという話でしたが、いきなり難しい質問ですね。どうしてそんなことを考えておられるのですか。


「自分はこのところずっと技術部門で、いわゆるPLMと呼ばれるような設計用のITツールに関わる仕事をしています。ただ、単に設計図面や部品表を共有するだけではなく、もっと画期的に設計の生産性を向上するには、AIの力が必要だろうと思って調べはじめたんです。そうしたら佐藤さんの会社の、『ITグランドプラン2030』構想が検索に引っかかりました。その中に『AI設計』という活動があって、興味を持ったんです。」
日揮ホールディングスHPより引用（https://www.jgc.com/jp/news/assets/pdf/20181218_1.pdf）



――なるほど。ただ、我々のようなプラント・エンジニアリング会社と御社では、設計業務も随分違うと思います。御社では、なぜAIに自動設計させたいのですか？　狙いはなんでしょう。


「それは…ですから、設計生産性の画期的な向上です。」


――と言うと?　御社では設計の生産性がこまるほど低いのですか?


「いえ、そう言うと語弊がありますが…ただ設計のミスとかは、案外多いですね。出図の後の、変更のフォローも悩みの種です。」


――つまり、省力化と正確性の向上を図りたいから、AIに設計をやらせたいと。そういうことですか?


「佐藤さんの会社では、違う狙いがあるんですか？」


――正確性の向上も、目的の1つにはありますよ。でもそれは部分に過ぎません。他に、例えば大量で単調な設計作業を肩代わりさせたいから、ということもあります。プラントの世界では、追いかけなければならない設計対象品目の数が、半端なく多いですからね。でも、一番最終的な狙いは、これまでの人間では発想できなかった設計を得たいから、です。


「そこなんです！ 自分が言いたかったことも。今まで思いつかなかったような形状の製品を設計する。これができれば凄いじゃないですか。佐藤さんの会社が発表されているロードマップを見ると、『革新的なプロセス機器の自動設計』が最終ゴールに描かれています。これがそういう意味ですよね?」




――その通りです。非常にクリティカルな操作条件の反応器や熱交換器などを、まったく新しい形状で設計できるようになることを、目指してます。でもそのためには、3D Printerや新素材の開発も同時に必要でしょうがね。それも同じロードマップに入っています。


「なるほど。ただ、そこに至る道筋とステップが、よく分かりません。なんだか一本道ではなくて2つの線が合流した形になってますよね。これはどういう意味ですか？」


――それを説明するには、まずこのロードマップ図の見方を説明しなければなりません。ロードマップの横軸は、図中のそれぞれのテーマの狙いを示しています。図の左側に位置するのは、短期的な狙いです。ここではキャパシティーアップと書いていますが、これは私たちの組織の生産性を上げると言う意味です。」


「生産性。まさに私たちの課題と同じです。」


――図の真ん中へんに位置するのは、品質向上・リスク低減です。すなわちプロジェクトをより可視化して、突然問題が吹き出すことを防ぐのが目的です。そして1番右側にするのは、新しいデザインや価値を、顧客に提供することです。つまり左側にあるのは短期的な課題、真ん中が中期的で、一番右はより長期的な狙いになります。


「AI設計は、比較的左側に寄っていますね。」


――その通りです。そして縦軸は、それぞれの取り組みの難易度を表しています。上に行けば行くほど、難しい。ですから、このロードマップの全体配置で言うと、左下のほうにある取り組みは、短期的な狙いで、かつ、難易度も低いですから、すぐ着手べき、となります。逆に右上のほうにあるテーマは、長期的な狙いで、難しいですから、当然将来の取り組みになります。ですから、全体としては、左下から右上に向かって、我々のいわば「デジタルジャーニー」の道筋があるわけです。


「なるほど、図の構造はよくわかりました。」


――それで、AI設計に話を戻します。出発点になるのが1番左下の、単純作業の自動化です。先程言ったように、私たちの設計業務には、多量で単調な作業がかなり含まれています。チェック作業とか、ツールや図面間の転記作業とか。そこでRPAなどを使って自動化し、エンジニアをつまらない作業から解放する。


「RPAはAIとは言えないですが。」


――もちろんです。ただ、こうやって設計作業を棚卸しし、最初に整理しておく必要があります。その上でAIの応用を考えねばならない。ところで、AIのエンジンと言うのは、買ってくれば、そのままポンと使える道具ではありません。そこには設計の知識やルールの埋め込みが必要になります。そのためには、ベテランのエンジニアが持っている暗黙知を、形式知化して、AIのエンジンが理解できる形に埋め込んでやらなければいけません。


「それが左上にある、『シニア技術の形式知化・ルール化』なんですね。ただ、どうしてこれは、こんな外れた場所にあるんでしょうか?」


――われわれはこのテーマに、昔から何度も取り組んできたんです。ところが、なかなかうまくいきませんでした。難易度が高いので、図の左上にあるのです。


「実は、うちの会社でも、同じような問題に突き当たっています。なぜこれって難しいのでしょうね？」


――理由はいくつかあると思います。単純に、シニアが忙しすぎて、時間を捻出できない、から始まって、センスや感覚論で説明してしまう傾向があるとか、いろいろです。でも1つの問題は、設計プロセスを形式化するための、方法論なり技術が、曖昧だったことにあります。そこで我々は、DSMという手法を導入して取り組むことにしました。


「DSMって、なんですか?」


――Design Structure Matrixの略で、米国のD. V. Stewardが1981年に、設計プロセスのモデル化のために提案した技法です。設計変数（設計諸元）をマトリクスの縦横に取って、設計における依存関係を表現します。Bという設計変数を導出するのに、設計変数Aが必要だったら、マトリクスのB行のA列に1を記入します。記法は単純ですが、複雑な設計プロセスを形式知化し、設計上の問題を抽出することができます。

「というと？」


――通常の順次導出関係は、対角線よりも左下にある”1"で示されます。逆に、対角線よりも右上に1があったら、それは設計の後工程から前工程へのフィードバック（つまり手戻り）を示すのです。そこで設計変数の順序入れ替えやグルーピングを行って、マトリクスを整理し、プロセスを改善するのです。もちろん、1のマス目で表される、それぞれの設計変数間の導出関係の後ろには、計算ロジックがある訳です。


「なるほど」


――わたし達は、シニア技術の形式知化から、メインのAI設計の流れに合流する点を、「AIローディング・ポイント」とよんでいます。これをちゃんとやらないと、設計へのAIの活用は成り立ちません。


「その次にある『プロットプラン自動設計』というのは何ですか?」


――プロットプランとはプラントの配置計画のことで、空間設計の基礎になるものです。化学プラントの設計では、最初にプロセスシステム、つまり全体の機能的な設計をします。電気工学で言う回路設計だと思ってください。それから、システムを構成する個々の要素、つまり機器や配管などの空間的な配置を決めます。これがプロットプランです。プロットプランは全体コストに大きな影響を及ぼすので、エンジニアリング会社の競争力の源泉ですが、考慮すべき要素も多く、現在はベテランにかなりを頼っています。


「そこでAIの登場ですね」


――うーん、そうなんですが、話はそう単純じゃありません。プロットプランはコストを左右する、といいましたが、じゃあ単に、敷地面積や配管の物量だけを最小化すればいいかというと、そうではないんです。施工性であるとか、地下埋設物の存在とか、操業時のアクセス性とか、かなりいろいろな要素が関わります。つまり、評価尺度が複数あって、しかもあちらを立てればこちらが立たず、というトレードオフ関係が生じやすいのです。


「そうなると、最適化問題という訳ですか」


――そうです。それも多目的最適化問題になります。多目的最適化ではパレート・フロンティアとか、いろんな概念とテクニックが登場しますが、要するに答えは一つとは限らないのです。しかも、配管長とかケーブル長とか敷地面積などは、明示的に計算できますから、最適化エンジンの中に組み込めますが、施工性とか操作性は、ある意味とても定量化しにくいものです。だから、エンジンには組み込めない。


「じゃあ、どうするんですか？」


――出てきた答えを、人間が評価するしか無いのですよ。多目的最適化エンジンに、制約条件と目標値を与えて、複数のケースを計算させてみる。その結果を、エンジニアが評価して、部分的には修正して、またエンジンを動かす。こういった、一種のマン・マシン・ループの生じる仕事になります。


「それは、あまりうれしくないですね」


――そうでしょうか。でも、現在はすべてのプロットプラン設計作業を、ベテラン技術者がやっていますから、限られた納期の中では1ケースのプランを作るのが精一杯です。それが、複数ケースを比較評価して、ベターなものを選べるのだったら、十分うれしいと思います。


「なるほど、省力化は図れるのですね」


――いや、省力化よりも大事なことがあります。それは、技術者が『評価』という、価値ある仕事に集中できることです。さまざまな観点・尺度から、設計成果物を評価し、必要に応じて改善する。この部分は、AIにはできません。計算機には価値観も思想もありませんからね。人間の大事な仕事なんです。従来は設計のバルキーな計算や作図作業にほとんどの時間を取られ、せいぜい設計結果のチェック＆レビューくらいしかできませんでした。評価尺度についても、十分意識化してこなかった。そこは大きな前進になります。


「ふーん。そうなると、AIの出番はどうなるのですか？」


――まあGartner社などは、最適化もAIの領域内に含めていますが、技術的には以前からあったものです。それで、現在、世の中でAIと呼ばれているものは、ほぼ機械学習、それも深層学習です。その中心機能は、パターン認識、つまり類似性の判別と判定にあります。具体的には、画像認識による個人の顔の特定や、音声認識などのアプリケーションですね。もちろん、故障の予知保全なんかも応用分野の一つです。


「そこは弊社でも注目しているところです」


――そうですか。ところで、パターン認識技術って、設計に応用できると思いますか？


「できるんじゃないでしょうか。過去の設計事例から類似パターンを引っ張り出して、サジェスチョンしてくれるとか、でるといいなと思っています。」


――たしかに、サジェスト機能くらいなら、ありえるでしょう。保証はないけど、おおよその答えを言うだけですから。でもね、いやしくも科学法則に縛られた理工学領域の設計では、ベストの類似パターンを探し出してきたって、その計算結果が制約条件を満たさなければ、アウトですよ。設計の世界では、yesかnoかは白黒はっきりしています。耐荷重が100kgの条件なのに、出てきた答えが98kgしかなかったら、アウトプットには使えないのです。そこは、SFじゃないけど「冷たい方程式」が支配する領域なんです。


「だったら、シミュレーション機能と統合して、条件を満たす順に類似結果を表示したらどうですか。PLMの中に過去の設計図面をすべて登録し、PLM得意のシミュレーションI/Fを使って計算すればいいでしょう。そこから人間が、いいものを選ぶ」


――はい。だから、機械学習は、わたしのいう「選択的設計問題」だったら使いやすいと思うのです。もちろん、過去の設計成果物が、きちんとデジタル化され、かつ、設計変数や制約条件などのメタデータも、標準形式化され登録されている前提ですが。


「まあ、そこはちょっとハードルが高いですけれど、頑張れば可能ですね」


――ですね。で、そのとき課題になるが、設計ルールや、設計変数間の関係、つまり設計知識の扱いなんです。過去の図面は、頑張ればデジタル化できるでしょう。ただ、メタデータやルールや知識を、扱いやすい形式にする部分がポイントです。今の深層学習系AIソフトと、一世代前のルール型AIや知識ベースの両方が、じつは設計の自動化には必要なのです。


「ふーむ。でもIBM Watsonなんかは、何でも知っているという話ですが」


――クイズ番組に出るような知識ならね（笑）。ただ、御社の設計作業に関する知識は、知らないんじゃないですか。それをインプットするのは、御社の仕事のはずです。


「たしかに。」


――しかも、今のAIが活用できるのは、選択型問題や、演繹的決定による設計問題に限られます。先ほど説明したプロットプランのような最適化問題は、パターン認識ではアプローチできません。ましてや、形状や構造を設計する、システム合成問題は、なお難しいでしょう。


「じゃあ、AIでの設計は不可能、と思われるのですか？」


――そうは言いません。今の深層学習とパターン認識によるアプローチの最大の問題は、過去の設計データの蓄積に依存している点です。深層学習は、万の単位の教師データを必要とします。しかし、設計という行為は、つねに一回限りです。製造では全く同じ製品を繰返し作ります。だからパターン認識による欠陥検出や故障予知などがきくのです。他方、設計は、全く同じ図面を再生産することはしません。毎回、必ず何かが違うのです。エンジニアリングには「個別性の罠」があるのです。


「ますます、不可能に思えてきましたが」


――それは、過去の設計結果に頼ろうとするからです。そうではなくて、計算機が、自分で設計結果を生み出していけば良いのです。少しずつ、設計パラメータを変えて、結果を計算する。そして、評価関数を与えてやって、良いものを選んでいく。計算機は飽くことなく、いくらでもランダムな組合せで設計をジェネレートします。そこから、よりベターなパラメータ群を選んでいく。


「それって、強化学習ですね」


――そうです。AIで設計を自動化したかったら、強化学習しかないのですよ。このように、計算機が自分でベターな設計を生成していく手法を、Generative Designといいますが、その代表例が、「トポロジー最適化」の技術です。これは、機械部品などの形状について、人間がある初期値を与えてやり、そこから自動的に肉付けを変えていって、もっとも重量が少なく強度の高い結果を求めていくような手法です。すでに商用のソフトウェアも存在します。


「やっと、トンネルの向こうに光が見えてきたような気がします」


――そうですか。ただね、強化学習では、設計をジェネレートするたびに、その評価をしなければならないのです。単純な構造部品なら、重量と強度の計算程度ですみます。しかし、たとえば熱交換器程度でも、ちゃんと評価しようとすると、毎回、熱伝導計算と計算機流体力学の両方を解かなければなりません。かなりマシンパワーを食う計算です。


「でも、マシンパワーはクラウドと並列化技術のおかげで指数関数的に進化し続けています。そういう意味では、強化学習による設計も、楽観視して良さそうですね。」


――まあ、そうだといいですね。ただ、ちょっと気になる点もあります。現在のAIコミュニティを見ていると、強化学習の分野は倒立振子問題から始まって、ロボットアームの制御みたいな、連続変数の制御問題の枠組みばかりを注視しているように感じられます。トポロジー最適化のような、形状の連続的変形の問題は、それでもいい。連続変数の最適化制御問題は、非線形性が強くても、最後は偏微分方程式を力づくで解く方向に進めます。


「はあ。」


――ところが、形状の設計ではなくシステム構造の設計となると、問題は離散的な設計変数の組になります。離散系の最適化問題は、連続系とは全く異なる難しさがあるんです。詳しい話は省きますが、NP完全になりやすいので、経験的なヒューリスティックが必要になる。そのことを、ORの分野の人はよく知っていますが、まだAI系の人は無頓着に思えます。


「というと、結局、AIは設計をどこまで自動化できるんでしょうか？」


――将来に渡って、設計エンジニアは不要にはならない、ということです。要求を分析し問題構造を理解する、設計の知識ベースを入力・更新する、複数の目的関数を設定する、でてきた結果を評価する、必要に応じてそれを修正する、そして設計のツール自体を進化させる。こうした仕事は、相変わらず人間に残ります。もしAIが将来、設計技術者を不要にすると思うなら、それは無用な心配です。むしろ今のAIは、設計に活用しようとすると、ずいぶん寸法が足りない。一寸法師のようなものです。
　一寸法師だって、大勢を上手に使えば、エンジニアの退屈な仕事はそれなりに手助けしてくれます。ただ、それを上手に進化させられるかは、わたし達にかかっているのです。




＜関連エントリ＞
　（2020-05-07）
　 (2020-05-15)




]]> http://brevis.exblog.jp/29006534/ 2020-05-15T12:18:00+09:00 2025-12-31T11:07:36+09:00 2020-05-15T08:30:25+09:00 Tomoichi_Sato E2 設計のマネジメント

設計者に、スキルの高低とかセンスの良しあしがあることを、否定するエンジニアは少ないだろう。毎回、画一的な答えを出すだけなら、ロボットでも代替できる。だが、設計者はロボットではないはずだ。では、設計者という人間のスキルやセンスとは、何を指すのか。


当たり前だが、それは、「良い設計」を作れる能力を意味している。誰が見ても、「うーむ、良い設計だ」と感心する出来栄えのアウトプットを、ある程度コンスタントに生み出せる能力。そういう人は、スキルが高い、センスが良い、と言えよう。


では、「良い設計」とは、何なのか？　


良しあしを言うからには、そこに、何らかの評価尺度と基準があるはずである。前回の記事では、機能・構造・制御の3要素に関連して、3つの評価項目を取り上げた。


(1) 有用性：有用でないモノは、作るに値しない。有用性とは「機能」が生み出すもので、設計対象の性質やふるまいのうち、使用者の期待に合致する（あるいは他の機能を助ける）部分を指す。若干ニュアンスはかわるが、「機能性」と呼んでも良い。


(2) 存続性：ちゃんと存続しないモノ（作っても瞬時に壊れるような物）は、使えない。存続性は、「構造・形状」（と材質）が、保証する。力学的安定性ともいう。ただしソフトウェアのような無体物は、構造的単純性（スパゲッティ状態でないこと）で置き換えて、解釈すべきだろう。


(3) 操作性：使用者の意思に沿って動かないモノは、使えない。操作性は、「制御」の機構が実現するもので、制御性といっても良い。普通はそのために、ユーザ・インタフェースが必要になる。


言いかえると、ユーザの期待を上回るような機能・性能があり、形状や構造は単純ながら堅牢安定で、かつユーザの意のままに動かせるようなモノを作れたら、良い設計だという事になる。


しかし、評価基準はこれだけか？　そんなことはない。


まず、真っ先に設計者の脳裏に浮かぶのは、『コスト』であろう。コストが優先、コストは安いほうが良い。これは多くのエンジニアに刻み込まれた価値観だ（とくに日本では）。もちろん、正確に言うと、「同じ性能や品質が実現できるならば、コストは安いほうが良い」である。コストダウンで性能や品質が犠牲になっては、本末転倒だ（だが、しばしば設計者が、「コストダウン優先」という『転倒』を、要求されたりするのが見受けられるが）。


その「コスト」はさらに、設計作業それ自体の人件費、材料部品の購入費、そして製造や検査の労務費、機械設備の減価償却費や光熱費、などから構成される。このうち、最後の製造間接費は普通、企業の製造部門が固定費として担うので、設計部門の責任範囲外だ。しかし設計人件費・材料費・労務費のどこまでが、設計部門の「コスト」の対象になるかは、その企業の組織ポリシー次第でかわる。


だから、ある者は、たとえ材料費が少し増えても、製造の手間が下がれば、全体コストが下がるから「良い設計」と思い、別の者は、材料費さえ下がれば、製造が面倒になっても「良い設計」だと考える（労務費は設計者の責任範囲外の場合）、といった現象がおきる。もちろん、設計作業の人件費しか見ない者もあるだろう（製造を外部企業に委託している場合など）。このように、何が良い設計なのかは、その会社の経営のモノサシにかなり依存するのだ。


さて、同じ性能や品質が実現できるなら、コストは安いほうが良い、と上に書いたが、では「性能」や「品質」は、どんな評価尺度なのか？　とくに設計が実現すべき『品質』とは何なのか。まさか、製造品質のことではあるまい（さすがに普通それは製造部門の責任だ）。では、設計図や仕様書に誤りがないこと？　誤字や転記ミスがなければ、「良い設計」になるのか？　それって最低限、守るべきことではないか。


設計における品質の問題とは、ユーザの要件や無意識的期待への合致、で測られるべきであることを思い出そう。そこで、よくITの分野で行うように、「機能要件」と「非機能要件」という角度からとらえなおすほうが、分かりやすい。


　性能＝機能要件に属する特性
　品質＝非機能要件で決まる特性


たとえば自動車でいえば、『移動』という主要な機能目的に直接付随する特性、つまり走行距離、最高速度、可載重量、馬力、加速性、燃費、回転半径などが、性能の範囲だ。逆に、高速安定性だとか剛性だとか衝突安全性、そして空間の広さや居住性、運転のしやすさといった非機能要件が、品質と関係する。良い設計というのは、機能要求を満たしつつ、非機能要件も適度に満足させるバランス感にある。


つまり、設計とは、与えられた制約条件の中で、複数の評価尺度を、なるべく最大化するような設計変数の組を見つける作業である、ととらえることができる。ORの分野の用語でいいかえると、設計とは多目的最適化問題なのである。


そして、複数の評価尺度の間には、しばしば、「あちらを立てればこちらが立たず」というトレードオフの関係が生じる。自動車の例を続けると、走行距離を伸ばすには燃料タンクを大きくすることになる。だが、そうすると車体重量がまして、燃費や加速性が犠牲になる。加速性を上げるためにエンジンの馬力を上げると、今度は燃費が下がる、じゃあ車体を軽量化しようとすると、高速安定性が損なわれるし材料コストが上がる、といった具合だ。


AI（機械学習）の分野には、「ノー・フリー・ランチ定理」と呼ばれる定理がある。すべての最適化問題に対して、最強の性能となるようなアルゴリズムは存在しない、という定理だ。魔法の「銀の弾丸」はない、といってもいい。設計で突き当たるトレードオフの問題は、この定理を思い出させる。どこかを強めると、どこかが弱くなるのだ。


そこで、評価尺度の間にトレードオフが生じるとき、どの項目を優先して、どこは犠牲にすべきかを決める、より高いレベルの指針が必要になる。これを『設計思想』Design phylosophyと呼ぶ。良い設計とは、すなわち設計思想の明確な仕事である。ジョブズの生みだしたiPhoneは、たしかに設計思想の明確な製品だった。逆に設計思想の薄弱な、八方美人的な製品は、個性が薄く人を引きつける力が弱くなる。


もっとも、自動車や携帯電話のような複雑なシステム製品の設計となると、それ自体が設計変数の多い大規模な問題で（部品点数だけでも相当になる）、評価尺度の項目も多く、非常に難しい。これに比べて、前回取り上げた、椅子の設計だったら、形状も構造もずっと単純だ。設計変数も、ずっと少ない。座面の高さや耐荷重量、脚の本数などの主要な設計パラメータは、たぶん所与で決まっているだろう。


そのような場合、主に問題となるのは、形状と材質を与えたとき、所定の力学的強度を満たすかどうか、のチェックであろう。これなら単純なシミュレーション計算（場合によっては手計算）で確認することができる。さらにキャスターなどの制御機構を考え、総重量を求め、部品表とコストを計算し・・という具合に、設計作業は順次、進んでいく。こういう仕事ならば、手順書を作って、スキルの低い設計者や外部に委託することも可能になる。


いや、もっと単純な設計作業だって、無いわけではない。それは、あらかじめ決まっている選択肢の中から、要求仕様に基づいて、条件に合致する物を選ぶような作業である。わたしの職場では、よくこうした仕事を「カタログ・エンジニア」とよんだりする。分厚いカタログの中から、適切な製品や部品を選んで、その特性を仕様書に転記するだけの作業だからだ。


このように考えると、設計という仕事には、カタログから選ぶだけの単純な作業から、複雑なシステム製品の内部構造と制御機構を実現する仕事まで、大きく4つくらいのレベルがあることが分かる。それは、考えるべき設計変数の数と、評価尺度の複雑性に応じて、図のようにマッピングすることができよう。

つまり、設計行為には4つのレベルがあると考えられる



1. 選択的決定：いわゆるカタログ・エンジニア
2. 演繹的決定：設計計算で主要な設計変数を逐次導出する

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

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



当然ながら、この順番で設計は難しくなる。ただ、４の「システム合成」の高度な大仕事も、その中のプロセスを細かく分解してみると、部分的機能モジュールの最適化決定や演繹的決定、あるいは単純な部品の選択的決定、などが含まれているのが分かるだろう。そして設計チームの中で、スキルに応じて、そうした作業が振り分けられていくはずである。


このように考えると、AIで設計を自動化できるか、という問いに、さらに一歩近づいた訳である。その答えについては、次回の記事で考えてみよう。




＜関連エントリ＞
　→「設計とはどういう行為か、AIで設計を自動化できるか？」 (2020-05-07)
　→
(2019-09-22)





]]> http://brevis.exblog.jp/28975247/ 2020-05-07T20:07:00+09:00 2025-12-31T11:07:36+09:00 2020-05-07T20:07:55+09:00 Tomoichi_Sato E2 設計のマネジメント

設計とは何か、という問題について、最近あれこれの角度から考えてみている。わたし自身はエンジニアリング会社でずっと働いており、とくに駆け出しの頃は、設計部門でキャリアを積んだ。今は設計の現場から離れてしまったが、今でも設計の良し悪しこそ、その後の仕事の質や利益を、大きく左右すると信じている。そして、プロジェクト・マネジメントの分野に設計論が欠けていることが問題だ、とは以前も書いたとおりだ。


では、ひるがえって、設計とはどういう行為なのか、設計の質とは何が決めるのか、そして昨今皆が注目しているAI（人工知能）という道具は、設計において役立つのかどうか。こうした議論は、あまり十分されていないように感じる。そこで、上記の講演の内容を一部再録する形で、読者諸賢の検討の俎上に差し出そうという次第である。


ちなみに委員会の名称にある「プロセスシステム工学」とは、簡単に言うと化学プラントの全体設計及び制御に関する工学、というほどの意味である。プラントというのは、外観を見た方はご存知の通り、装置や機器を多数の配管が網の目のように縦横無尽につないだ形をしている。あれ自体が、非常に複雑なハードウェア・システムなのである（もちろん制御ソフトウェアもその上で動く）。だから、わたしの講演タイトルにある『システム設計』は、ITソフトウェアの設計というよりも、もっと広い意味でとらえていただきたい。


さて。そもそも、設計とはどういう行為なのか。設計という仕事を、真っ向から研究対象としてとらえた学問は存在するのか。すなわち、『設計論』の系譜とは、どうなっているのか？


不思議なことに、ここがまず、出発点として曖昧なのである。読者の中には理工学系の教育を受けた方も少なくないと思う。では、一般的に設計とはなにか、どういう原理で考え、どう進めるものなのか、教わった方は多いだろうか？　わたし自身の記憶は、あいまいだ。工学部では、それぞれの専門領域の手法論は細かに教わる。だが、分野を横断した、一般的な設計論というのを、あまり聞いた覚えがない。


じつは早くも1960年代に、この点を問題視した人がいた。後に東大総長となる故・向坊隆である。彼は応用化学系の研究者だったが、戦後日本における工学教育の見直しの必要を説き、エンジニアが共通に学ぶべき『基礎工学』の21の科目を提案した。その第10科目が「設計論」で、第21科目は「システム工学」だった。


設計論を担当した渡辺茂は、後に著書「設計論」(岩波書店、1975)をまとめる。彼の「設計の定義」は、こうだ：


「設計とは思いついた“あるもの”に具体的な形を与え、その着想の正しさを確認することであって、次の三つの行動からなりたっている。
1. “あるもの”を作りたいときめる
2. それに形を与え、使用する素材をきめる　　
3. その作り方をきめる」

・・感心しましたか？


率直に言うと、「何それ？」というのが、読んだ時のわたしの感想だ。渡辺茂は機械工学の人だった。だから形と素材に、主要な関心がある。しかし、電子回路の設計や、プラントの制御方式に悩んでいる設計者にとって、＜形を与え、素材を決める＞と言われて、心に響くとは、とても思えない。ソフトウェア設計者には、いうに及ばずだろう。


もう少し時代が下って、1979年。東大の精密機械工学科の吉川弘之は、設計についての公理的理論として『一般設計学』を提案する。一般設計学では、基本的な概念として「実体」，「実体概念」，「属性概念」が定義され、位相空間論の方法が用いられる。たとえば、「公理1(認識公理)：実体は属性(あるいは機能，形態などの抽象概念)によって認識あるいは記述することが可能である」、といった具合だ。


わたしはここで、その内容を詳しく解説するつもりはない。あまりに抽象的で難解だからだ。もしご興味があれば、たとえば、下記の講義録などを参照されたい。
吉川弘之(2011): 一般設計学.　東京大学工学部精密工学特別講義


また、後に角田譲は、位相空間論ではなく「チャンネル理論」の数学的枠組みを用いて、「抽象設計論」を提案する（2001年）。その内容については、以下の文献も参考になる。
菊地誠(2003): 一般設計学と抽象設計論に関する考察.　京都大学数理解析研究所講究録 1318, 136-148,


ただ、エンジニアとして正直に言うと、上記のような公理論的な枠組みをいただいても、実際の設計の仕事にどう活かしたらいいか、さっぱり分かりません、との感想になってしまう。


という訳で、いつものことながら、自分で納得できる答えを自分で考えるしかない、という事になった。
設計とは、どういう行為か？　わたしの答えは、こうである。



設計とは、『機能を形状・構造に落としこむ』作業である。
設計対象に可動部分があったり、対象が入力を出力に変換する仕組み（システム）である場合は、その構造に、制御機構を与える作業が続く。


これだと分かりにくいだろうから、具体的な例をあげてみよう。たとえば、椅子を設計することを考える。


椅子は、人がその上に一時的に腰掛けるためのものだ。すなわち、一定の高さに座面を提供することが、その機能である。そこで、座面の高さ、かかる体重（外力）などが、主要な設計パラメータになる。設計パラメータというのは、問題固有の特徴的な設計変数のことだ。

野良の切り株だって、座る役には立つ。だから、考えている椅子が、もし「切り株」のように、単一の材料からなる場合、形と材質だけを決めれば、事足りる（構造の概念は不要だ）。


だが、もちろん異なる形状と材質からなる、座面と、それを支持する脚部からなる「構造」を考えてもよい。そして普通の椅子は、そうなっている。この場合、座面の広さ・材質、座面を支える脚の形状と本数、地面との接し方、などの設計変数を決める。


その上で、手で持ち上げられる重さにおさめたい、とか、耐荷重は最大100kgとか、回転できるようにしたいとか、背もたれも必要だとか、さまざまな要求仕様や、製造上の制約条件を加味して、考えを進める必要がある。


最終的には、製造する人にとって必要な、製作図面と、部品表（BOM）と、製造仕様書とを設計のアウトプットとして出さなければならない。もし売り物にするならば、さらに「使用説明書」（ユーザマニュアル）もいるだろう。


ところで、椅子の設計において、形状や構造はたしかに分かる。だが、椅子の「制御」とは何だろうか？　そんなものは必要なのか？　どこかにマイコンをつけて、モータをサーボ制御するのか？


そう思うのは、制御ということを、現代制御理論の枠組みで捉えすぎるからである。制御の原義とは、「設計対象のふるまい方を、ユーザの意思や動きに合致させる仕組み」なのだ。それはユーザとの入出力操作により、性能（有用性）や安定性を変えるメカニズムである。


椅子の場合はどうか？　たとえば、キャスターつきの脚部は、ある意味、椅子の位置を「制御」しやすくするための仕組みだ。また、そのキャスターにストッパーがついていたら、それは移動性のみならず、安定度を確保するための制御の仕組みでもある。また、座面の高さや、背もたれの角度の調節メカニズムだって、立派な制御機構である。


ちなみに、上に述べた「機能」と「構造」の概念についても、きちんと記しておいたほうがいいだろう。


機能とは、設計対象のふるまいや、対象がもたらす変化のうち、ユーザの期待に合致して（あるいは他の機能とつながって）有用なところを意味する。すなわち、製品の生み出すアウトプット（物・運動・情報）や、あるいは働きを「機能」と呼ぶのだ。椅子ならば、座面を提供して人の体重を支えることが、主たる機能である。ちなみに、アウトプットや変化を生むだけでなく、自然な変化を防ぐ事も、「働き」の一種である。だから、塗装は鉄のサビを防ぐ「機能」を持っている、という。


構造とは、モノとして存続性（安定性）があり、そのふるまいにおいて機能（有用性）がもたらされるような、要素の形と材質の組合せをいう。なお、これは設計対象が、物理的な実体を持つような場合の話である。ソフトウェアとか、あるいは「企業組織を設計する」際のように、実体がない設計対象の場合は、「構造」とは、要素的な機能のかたまり（モジュール）と、その連携関係のことを示す。


余談だが、宮崎駿の映画「風立ちぬ」で、主人公の堀越二郎が、食堂で出てきた魚の骨をつまみあげて、「なんて見事な形なんだ」と賛嘆するシーンがあった。堀越は航空機工学のエンジニアだから、部品の形状に、非常に興味がある。


機械・土木・建築など、物理的な形状に近い設計の分野では、『形状』は機能と、構造（力学的構造）を橋渡しする、重要な要素である。だから最初の定義に、『機能を形状・構造に落としこむ』と書いたのだ。ちなみに電子回路の設計や、化学プラントのプロセスシステム設計（＝プラントの回路設計）では、機能的な要素の結合関係が重要であって、物理的な距離は、まあ副次的な役割にとどまる。そして無体物の設計では、形状は問題にならない。


少し長くなってきたので、これまでのところを簡単にまとめよう。


１．設計とは、『機能を形状・構造に落としこむ』作業である。必要な場合は、さらに制御機構を与える作業が続く。


２．機能とは、設計対象のふるまいや変化のうち、ユーザの期待に合致する（あるいは他の機能とつながる）ところを意味する。つまり「有用性」が評価基準となる（無用なものは設計する価値がない）


３．構造とは、設計対象を構成する要素の形と、つながり・組合せを意味する。機能として期待するふるまいをし、かつモノとしての「存続性」（力学的安定性）が評価基準となる


４．制御とは、設計対象のふるまい方を、ユーザの意思や動きに合致させる仕組みであり、ユーザとの入出力操作により、性能や方向性・安定性を変える。つまり「操作性」が評価基準となる


さて、わたし達が工学部で習うような実験手法とか、あるいは利用可能な計算ソフトなどがやってくれる仕事は、基本的に「形状・構造が与えられたときに、その性能・ふるまいを計測・予測する」道具である。有限要素法による構造力学計算も、空洞実験やCFDの流体力学計算も、電子回路シミュレータも、分子軌道法による計算化学も、そうした手法論である。


だが、設計という仕事において必要とされるのは、ちょうどその逆の動きだ。つまり、
「形状・構造　→　機能・性質」
ではななく、
「機能・性質　→　形状・構造」
を考えなければならない。


形状・構造から出発して、機能や性質を導出するプロセスは、手順は複雑かもしれないが、答えは一意に決まる。しかし機能から、それを実現する構造・形状を求める作業は、一意に決まるとは限らない。おそらく非常に広い可能性の領域から、適切な形状や組み合わせを求める必要がある。


つまり、設計とは典型的な逆問題なのである。『逆問題』とは、アウトプットからインプットを推測する（あるいはインプットの変換プロセスを推定する）タイプの問題だ。そして、逆問題の答は、一意に決まらない場合が多い。でも、設計においては、何か答えを出さなくてはならない。だから、ここに設計者の経験値や「センス」が介在する余地が生まれるのだ。


設計という仕事には、サイエンスだけでなく、アートの部分がある。「良い設計」と「ダメな設計」が分かれるのは、このためだ。答えが一つしかないなら、設計に良し悪しなど生じるはずがない。だが、現実には設計者のスキルが、重要な役割を果たすのだ。


こう考えてくると、「AIで設計を自動化できるか？」という問題も、アプローチの方向が見てくる。長くなってきたので、この続きは項を改めて、また書こう。




＜関連エントリ＞
　→「PMにはなぜ設計論がないのか？」 (2019-11-21)
　→「PMBOK Guideに欠けている、３つの重要事項」 (2019-04-06)


]]> https://www.excite.co.jp/ https://www.exblog.jp/ https://ssl2.excite.co.jp/