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

「プロジェクト＆プログラム・アナリシス研究部会」（2月20日）開催のお知らせ

各位、

来る2月20日（木）に、2020年の「プロジェクト＆プログラム・アナリシス研究部会」第1回会合を開催します。今回は、PM教育のためのゲームを開発された、日立ドキュメントソリューションズの岡田様にご講演いただきます。

プロジェクト・マネージャーの人材不足にはどこも頭を痛めており、優れたプロマネの育成研修は焦眉の急です。しかし、プロマネに必要とされる知識とスキルの幅はけっこう広く、身に付けるのは簡単ではありません。

当研究部会でも3年ほど前から「PM教育分科会」を組織して、独自の研修カリキュラムを開発してきました。ただし限られた時間内に、PMのソフトスキルとハードスキルの両面を伝えるのは、至難の技です。

日立さんのアプローチのユニークな点は、モノポリー的なカードゲームを元に、主にソフトスキルにフォーカスした問題解決力の教育を組み込まれた点です。教育における「ゲーミフィケーション」の効果は、最近つとに指摘されていますが、短時間に集中して考える取組みとして興味深いものです。またファシリテーターによる丁寧な指導も、実践的な価値を高める工夫のようです。

プロマネの育成について悩んでいる多くの方に、役立つ内容になると期待しております。開催日の直前のご案内になってしまい恐縮ですが、ぜひご来聴ください。

＜記＞

■日時：2020年2月20日（木）　18：30～20：30

■場所：田町キャンパスイノベーションセンター　

　5F スペース：509AB

　（JR田町駅の芝浦口から右方向の階段をおりて、50mほど先の右手の建物です）

　　http://www.cictokyo.jp/access.html

■講演タイトル：

「ゲーミフィケーションを用いたビジネス人間力養成の取り組み」

■概要：

プロジェクトの現場において、プロジェクトマネージャは発生する問題やリスクに対して限られたリソースの中でその都度適切な意思決定を行うスキルが求められる。これらのスキルは実践訓練などを通して習得できるものであるが、習得には多くの体験を経る必要があり時間を要す。そこで、ゲームを通してチームでプロジェクトを模擬体験する実践訓練手法を開発した。ここで得られるスキルは、プロジェクトマネジメント分野に限らず、ビジネス全般に必要なソフトスキルであると考える。講演では、プロジェクトマネジメント分野以外への展開可能性や、ゲーム中の振る舞いによるプロジェクトマネージャの特性評価の取り組み、ゲームの臨場感向上のためのデジタル化/ゲーム空間の開発に関する取り組みを紹介する。

●YouTube：プロジェクトマネージャの”感性”を磨くボードゲーム「プロ・トレZ」プロモーション映像リンク先

https://www.youtube.com/channel/UC8-Y7nlzYe9ycy1pV88fbVw

* ダイジェスト版 ・・・・2分

* フル版 ・・・・21分

■講師：岡田　久子

　株式会社日立ドキュメントソリューションズ　EPCプロジェクト本部　本部長

■講師略歴：

1998年日立製作所に入社。大規模発電所等の建設管理、および建設管理システムの運用・高度化業務を経て、

2014年より日立ドキュメントソリューションズへ移り、プロジェクトマネジメント支援業務の取り纏めに従事。

■参加費用：無料。

　ちなみに本研究部会員がスケジューリング学会に新たに参加される場合、学会の入会金（¥1,000）は免除されます。

　参加を希望される方は、確認のため、できましたら前日までに三好副幹事までご連絡ください。

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

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

進捗率を何で測るか？ −−情報処理技術者試験の問題より

仕事の進捗（しんちょく＝進み具合）を何で測り、どう数値化するか。これはいつも悩ましい問題である。

「プラント・エンジニアリング会社のように、物理的に目に見えるモノを作っている分野は、数量が測りやすいからいい。ソフトのように目に見えない成果物を作る仕事は、進捗管理がとても難しい。」

・・こういう意味のことを、IT業界の方から何度か言われたこともある。いえいえ、どういたしまして。プラント・エンジニアリングのプロジェクトでは、設計業務だけで18ヶ月〜24ヶ月もかかる。この間、膨大な図面や仕様書が生成されるが、プラント予定地では１年後にやっと、基礎工事のための穴掘りが始まる程度だ。設計作業の進捗をどう捉えるかは、同じように悩ましい。

もちろん、具体的なものづくりに携わっている企業だって、進捗をタイムリーに正確につかむのは難しい。同時並行に進む作業が多いし、その負荷の大小だって、様々だからだ。

ところで、情報処理技術者試験に「プロジェクトマネージャ」という種目がある。IPAの試験制度の中でも、いわゆる「高度」に分類される資格の一つだ（一応、わたしも持っている）。さて、今を去る2004年秋のことだが、この試験に、進捗率に関して、次のような問題が出たことがある（一部佐藤が改編して引用）：

* １０本のプログラムからなるシステムを完成させるプロジェクトがある。

* １本のプログラムを完成させるには１人月の工数がかかると見積もられた。

* 各プログラムの開発作業は、設計（20%）→コーディング（50%）→テスト（30%）のプロセスからなると推定された。

* 作業開始から15日たった時点で進捗状況を調べたら下記のとおりだった：

* 現時点での進捗率を求めよ

・・という問題である。

どうやらこのシステム、ほぼまったく同一規模のサブシステム・プログラム10本からなっていて、なおかつ、その間のインタフェースも結合テストもいらないらしい。随分とありそうにない、不自然なシステムだが、まあ試験問題だから文句を言っても仕方がない。

とにかく10個のタスク（アクティビティ）があり、それぞれが設計・コーディング・テストの3段階からなるから、全部で30個のサブタスク（サブ・アクティビティ）から構成されたプロジェクトだ、ということになる。

進捗率を問われている訳だから、なにか基準となるモノサシが必要だ。では、一番単純に考えて、「完成したプログラムの本数」を基準にしてはどうか？　全部で10本のプログラムを作らねばならない。15日たった現時点で、できあがったのは3本だけだ。だったら、3 / 10 = 30%ではないか。

これはこれで、シンプルで分かりやすい尺度である。これをかりに『完成数基準』と呼ぶことにしよう。

ところで、別の考え方もありうる。プログラムが完成まで至っていなくても、設計やコーディングがそれぞれ終わっているのなら、一定の進捗があったと言えるはずだ。で、その進捗率は、どう測るのか。それは、工数によるウェイトがいいと思う。

15日たった現時点で、設計は10本とも完了している。設計の工数はそれぞれ0.2人月と見積もられている。またコーディングは6本完了だ。1本あたり0.5人月だから、3人月分の仕事が終わっている。そしてテスト。これは3本×0.3人月で、0.9人月分。だから合計、5.9人月分の仕事までは進んだ訳だ。だから、全体工数の10人月で割ると、5.9 / 10 = 59%となる。この考え方を、『見積基準』と呼ぼう。

いやいや、よく考えてみよう。工数の見積なんて、いつでも大した精度がなく、あてにならないものだ。ウェイトをつけるなら、実際に掛かった工数を重みにすべきではないか。表によれば、設計には合計2.5人月、コーディングには4.0人月かかり、テストにも1.5人月使っている。合計7.0人月だ。だとするならば、進捗率＝70%が妥当ではないか。この考えを、『実績基準』と呼ぶことにする。

結局、この問題は、次の三つのどれかを選べ、という問いになる：

３／１０＝３０％？　（完成数基準）

５．９／１０＝５９％？　（見積基準）

７．０／１０＝７０％？　（実績基準）

さて、あなたなら、どれを選ぶだろうか？

上の３つの計算例でも分かる通り、進捗には、さまざまな定義が可能である。いわば決め事の問題であって、その点で原価管理にも似ている。原価にも、様々な計算手法がありえる。その中から、どれを選ぶかは、企業のマネジメント方針次第なのである。

しかし、『進捗率』を数字で計算する以上、合理的かつ整合的な算定方法として、皆が合意できることが条件になる。

その観点から、完成数基準の計算：

　３／１０＝３０％

を見ると、どうなるだろうか？

15日目の現時点で進捗率30％ならば、100%完成まで、15 / 30 * 100 = 50だから、あと50日かかる計算になる。じゃあ、このプロジェクトは、あと35日必要だと言えるだろうか？

進捗管理の目的は、きれいな進捗レポートを作ることではない。進捗率を測る最大の目的は、完了日を予測するためにある。完成数基準は分かりやすく単純だが、この目的のために有用だろうか？

考えてみてほしい。横軸にプロジェクト開始からの日数を取り、縦軸に進捗率をとって、グラフにプロットするとする。もしこのプロジェクトが理想的に進めば（＝つまり、各プログラムが予定通り並列に開発されると）、29日目までは完成数＝ゼロである。30日目に、10本のプログラムが全部、同時に完成する。

進捗率のグラフは、ずっと0%のまま29日目までx軸にはりついていて、30日目にいきなり100%になる。このグラフを見て、完了日の予測ができるだろうか？　理想的にプロジェクトが進むと、完了時点が予測できなくなるような基準は、役に立つだろうか。

では逆に、実績基準の計算：

　７．０／１０＝７０％

は、どうか？

いま仮に、現在までにトータルで9人月かかったとすると、90%進捗、ということになる。もし12人月かかっていたら、120%進捗、という計算にならないだろうか？　これは明らかに不合理である。

予算消化率で進捗率は測れない。これまで、どれだけ頑張ったか、どれだけ工数や予算を使ったか、で進捗を測ってはいけないのだ。この点はよく覚えておいてほしい。世間の人は、ここを誤解しているケースが非常に多いからだ。

進捗率は、今までどれだけ頑張ったか、ではなく、あとどれくらい仕事が残っているかで測るべきなのだ。

では、あとどれくらい仕事が残っているのか。それは、未完了の仕事（コーディング4本とテスト7本分）を見る必要がある。その仕事量は、4 * 0.5 + 7 * 0.3 = 4.1人月だと見積もられている。全体が10人月分の仕事量だったのだから、41%残っている。となると、進捗した分は、差し引き100 - 41 = 59%となる。

したがって、見積基準の計算：

　５．９／１０＝５９％

が正解らしい、とわかる。

実を言うと、この当時、経産省主導の資格試験は、正解を公表していなかった（もっと後には公表するようになったが）。だから、上に述べたのは、あくまでも佐藤の推測した回答である。しかし、これが正解だろうと思う。なぜなら、この見積基準の進捗率とは、EVMS (Earned Value Management System)の標準的な手法だからだ。

EVMSは、モダンPMの技法の三本柱の一つだ。EVMSでは、進捗率を次のような方法で定義する。

1. 各Activityに見積った工数を、ProjectにおけるそのActivityの価値とする

2. 全Activityの価値の合計は、Project全体の価値に等しい

3. 完了したActivityの価値の合計を、「出来高」（アーンドバリュー）と呼ぶ

4. 出来高をProject全体の価値で割ったものを進捗率と定義する

この問題では、完了したサブ・アクティビティの価値（見積もられた工数）の合計は5.9人月だった。だから、5.9 / 10 = 59%になるのである。いいかえると、EVMSの進捗率計算は、見積基準なのだ。

さきほど、完成数基準で進捗率のグラフをプロットすると、値がずっとゼロのままで、使い物にならなと書いた。逆に言うと、進捗率計算の主目的が完成日予測にあるのならば、理想的な進捗の指標とは、グラフがちょうど直線で進んでいくような形だろう。これならば予測は、かなりやりやすい。

これに対してEVMSの進捗カーブの形は、通常、もう少しS字カーブ型になる。プロジェクトの最初はゆっくりと立ち上がり、やがては活況に入ってぐんぐんと進捗があるが、最後の方になるとまたカーブが寝て、ゆっくりとした収束になる。だからプロジェクトの一番初期と、一番最後の頃は、EVMSの進捗率から完了日予測を正確にするのは難しい。しかし両端の時期を除けば、まあまあ予測には使える。こういうこともあって、EVMSの進捗率計算は広く使われている（少なくとも欧米では）。

ただし、EVMSの進捗率によるコントロールは、万能ではない。この点についてはすでに何度か記事も書いたので、ここでは繰り返さない。だが、舶来の手法で、試験問題にも繰り返し出されると、なんだかそれが『正解』だと思い込み、暗記してそのまま従うような風潮が、わたし達の社会には無い訳でもない。

繰り返すが、進捗率計算というのは、いろいろな定義が可能なのである。少なくともそれが合理的で整合的である限りは、各社がいろいろと工夫して使っていい。ただ一つ言えることは、「過去こんなに頑張りました」という事をベースにして計算してはいけない、という点だけだ。

これまでの努力を言いたい気持ちは、もちろんわかる。それをきちんと、ステークホルダー達に説明する必要もある。だが、それは過去に属することだ。言ってみれば、タクシーメーターの料金なのである。ここまで、これだけ走り、料金換算でこれだけかかりました。だが、タクシーメーターをいくら懸命に見つめても、この先いつになったら目的地に到着できるかは、分からない。つまり、進捗の指標にはならないということだ。

進捗コントロールというのは、もっと未来志向の行為なのである。

＜関連エントリ＞

　→(2010-02-17)

　→ (2019-05-26)

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

（前回記事「エンジニアリング・チェーンをゆるがす『個別性の罠』とは」から続く）

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

・質的な面：　　　　92%

・人員の量的な面：　83%

となっています。つまり、人数的にも、そして能力的にも、生産技術者が全く足りていない、という事実を示しています。

なぜこのような事態になったのでしょうか？　以下は推測ですが、やはり2008年のリーマン・ショックが一つのきっかけだったのではないかと考えます。この時、企業はかなり人減らしを行いました。ただ人員削減といっても、直接ライン部門を動かしている、製造や生産管理はなかなか切れません。また、新製品の開発を行う製品設計の部門は、優秀な人材を温存しておきたかった。

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

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

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

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

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

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

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

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

＜関連エントリ＞

　→「PMにはなぜ設計論がないのか？」 （2019-11-21）

　→「モチベーション重視という名の危険思想」 （2019-07-13）

　→「エンジニアリング・チェーンをゆるがす『個別性の罠』とは」 （2020-01-19）

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

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

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

＊＊＊

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

ということは、設計に携わるエンジニアの仕事の多くの部分は、

(1) 古い図面を探す

(2) コピペする

(3) その一部を修正する（そして他の部分との整合性をチェックする）

という『コピペ作業』に費やされている、ということになりませんか？

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

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

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

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

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

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

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

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

（この項続く）

＜関連エントリ＞

　→「エンジニアリングとは統合力（インテグレーション能力）である」 （2020-01-12）

　→「お知らせ：BOM/部品表に関する2件のセミナー講演を行います（11月28日・名古屋、12月17日・東京）」 （2019-10-28）

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

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

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

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

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

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

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

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

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

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

＊＊＊

＜ある日の、機械設計部門にて＞

「大変です。例のリアクター機器ですが、発注先のメーカーから、外形サイズが大きくなるって連絡が来ました。」

「どれくらい？」

「全体で、xxくらい増えるらしい、と。」

「いまさら勘弁してよ。もう配管設計部門に、ノズルの位置情報を渡して、設計をはじめてもらっているぜ。手戻りになるじゃないか！」

「そうですね。」

「それだけじゃなくて、機器の近くのパイプラック自体にも、位置的に影響するかもしれないな。ぎりぎりのレイアウトだから。なんでそんなにサイズが変わったの？」

「保温のためのジャケットの条件に変更が出たんです。顧客の要望で、上流側のプロセス設計部門から連絡がありました。それをメーカーに伝えたら、サイズに影響が出ますと返事が来たんです。」

「まずいな。それだと費用の追加請求も言ってくるぞ。納期にも影響が出るかもしれない。配管設計部門と調達部門と、一緒に相談したほうがいい。」

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

「これだけサイズが増えると、機器周りの配管ルートをかなり変える必要がありますね。配管長も増えるし、コストアップになります。ラックとの距離を元のままにして、機器全体の位置をずらせないんですか？」

「逆側のメンテナンス用アクセスにも制限があって、もう壁からギリギリなんです。」

「調達の立場から言うと、このメーカーとの過去の経験から見て、確実に追加を言って来るね。まあウチが変更指示を出したんだから仕方ないけど。」

「納期は？」

「そっちの方が心配です。メーカーの側に余分な材料の在庫がなくて、サブオーダー（注：発注先の機械メーカーから、資材メーカーに手配をかけること）を出すとなると、２〜３ヶ月かかる可能性ありかも。」

「そんなに遅れたら、建設の機器搬入スケジュールに間に合わなくなるな。」

「納期もありますが、もう一つ。これ、機器全体の重量も増えますよね。そうすると、基礎にも影響するかもしれません。」

「げげ。建設現場ではもう、コンクリート基礎の工事が始まっちゃているぜ。どうしようか？」

「対案は２，３考えられますが、影響範囲が広いから、ぼくらだけでは決められません。エンジニアリング・マネージャーを呼びましょう。」

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

「・・皆さん忙しい中、緊急に集まってもらってすまない。例のリアクター機器No. KK-ZZZのサイズ変更への対応を、すぐに決めたい。まず、現状の位置のままサイズが増えた場合のインパクトを、各部から言ってほしい。下流側から行こうか。まず建設と調達から。」

「3ヶ月も納期が延びたら、建設の搬入据付けスケジュールがひっくり返ります。あの機器を据え付けないと着手できない後続工事がみんな遅れます。プロジェクト全体の納期に影響がありえます。」

「調達として心配なのはコストアップですね。あのメーカーはこういうチャンスに、必ず余計に上乗せして要求してきますから。」

「じゃあ設計側にいって、配管の影響は？」

「サブパイプラックが近くにあるので、干渉を避けるためには配管ルートを迂回する必要があります。」

「そうなると調節弁の位置も変わるね。計装のケーブルルートも見直さなけりゃ。」

「重量増による構造設計へのインパクトは？」

「今の程度の重量増なら、コンクリート基礎への影響は限定的です。幸い余裕は見ていました。」

「助かった。さすが。」

「ただ搬入のためのスペースが増えるので、架構の柱スパンに引っかかります。工事がそこだけ遅れます。」

「うーむ、そうか。とにかく、影響度合いは分った。対案は3つ。今の機器位置のままでいくか、場所を強引にずらすか、それとも入口の上流側の温度条件を変えて、リアクターのジャケットサイズがあまり増えないようにするか。」

「どれも簡単じゃないですが。」

「うん。でも、とにかく各案のPros/Consを表にまとめて書き出そう。その上で、コストと納期に一番インパクトが少なそうなものを選んで、決めることにする。」

＊＊＊

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

(1) エンジニアリングには複数の専門技術分野がかかわっている

(2) エンジニアリング・マネージャーという職種がいて、設計分野間の調整と意思決定をする

(3) エンジニアリングには基本設計→詳細設計という流れがあり、その一部は外部組織（発注先のメーカーなど）が担っている

(4) エンジニアリングの意思決定は、設計の品質や効率や整合性だけでなく、調達から実装までの全体を見て判断すべきである

(5) エンジニアリングにおいては、外部からの変更・変動への対応が、不可避である

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

そしてエンジニアリングという業務の中心にあるのは、統合＝インテグレーションである。

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

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

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

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

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

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

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

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

＜関連エントリ＞

（2017-04-09）

（2019-11-21）

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

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

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

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

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

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

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

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

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

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

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

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

日時：1月23日（木）10:00〜12:00

場所：一般財団法人エンジニアリング協会　会議室

　　　〒105-0001 東京都港区虎ノ門3-18-19 (虎ノ門マリンビル10階）

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

　　　https://www.enaa.or.jp/seminar/41795

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

Chief Strategic Analyst　佐藤知一

クリスマス・メッセージ：名前を持つ存在として

Merry Christmas!

少し前のことだが、ある打合せで、システム利用者のマスタをどう設計するか、の議論になった。個人を特定するために、まず各人にユニークなキーとなるIDを振る。それから主要な属性を定義していく訳だ。当然最初に来るのは、『氏名』だろう。

ところで、氏名という属性を格納するために、最初出てきた案は、たしか「名字」と「名前」の２つのフィールドを用意し、それぞれに読み仮名のフィールドを付け加える、というものだった。まあ、普通の日本人が考えると、こうなるだろう。

しかし、ユーザの中には結構な数の外国人もいた。そこで、「ミドルネーム」のフィールドもいるんじゃないか、というコメントが出た。加えて、結婚したけれど旧姓表記のまま仕事を続けている女性もいるから、そうした人はミドルネームに旧姓を入れれば便利だろう。そうなると、ミドルネームにも、読み仮名のフィールドが別に必要かもしれない・・

議論がそういう流れになっていったので、わたしは反対した。

「ミドルネームのフィールドなんか、いらない。姓と名を分けるのもやめて、『個人名』だけでたった一つのフィールドにすべきだ。その中に、その人の好きな表記を書いてもらう方が良い。」

妙なことを言うやつだ、という顔をしたメンバーがいたので、わたしは説明した。

「外国人の中には、苗字と名前というセットではなくて、名前しか持っていない人たちが、それなりにいるはずだ。また、自分の氏名のどこまでが名字で、どこからが名前なのか、分からない人だっている。人の名前ってのは、世界では案外多様なので、海外までユーザの枠を広げる前提で考えるなら、日本的な苗字＋名前の枠組みにこだわらないほうが、最終的には安くつく。」

知っての通り、日本人が全員、苗字を持つようになったのは、明治維新後だ。それまでは、士農工商の中で苗字を持てたのは、原則として支配階級である武士だけだった。人口の9割を占める農民町民のたぐいは、皆、「権兵衛」「お富」といった名前しか持っていなかった。

わたしの父は、生前、「佐藤家なんて、3代さかのぼれば新潟の水呑み百姓さ」といっていた。新潟は糸魚川のあたりにいたわたし達の先祖が、「佐藤」という姓を、どこから拾ってきた、いや失礼、貰い受けてきたかは不明だが、ともかく維新後に「佐藤さん」になったのは、ほぼ確実である。

自分の姓を持てることになって、皆が嬉しかったかどうか、そこはよく分からない。ともあれ以来、日本人は誰もが姓と名を持つ、という常識がしっかりと根を下ろした。

ところが、海外に目を向けてみると、実はまだ「名前だけ」という国々が、案外広く残っている。アジアでは例えば、モンゴルがそうだ。またインドネシアもそうだ。独立後の初代大統領スカルノは、「スカルノ」がフルネームである。

それと、ミャンマーもそうだ。アジア人で発の国連事務総長になった「ウ・タント」という人がいたが、「ウ」というのは男性につける尊称（「ミスター」みたいなもの）で、また最後の「t」は発音しないため、「タン」さんが正式名である。また「アウン・サン・スー・チー」という女性政治家もいるが、ほんとは分かち書きをするわけではなく、「アウンサンスーチー」が名前だ。彼女は、ビルマ建国の父・アウンサン将軍の娘だが、別にアウンサンという名字がある訳ではない。

もう少し西に、目を転じようか。アラブ世界にも基本的に、名字に当たるものがない。預言者の名前を戴いたムハンマドさんは、ポピュラーな名前なので、どこにも大勢いる。そこで、区別したいときには、後ろに父親の名前をつけて、ムハンマド・アリーといった風に呼ぶ。それでも区別がつきにくいときは、さらにその後ろに祖父の名前をつける。おかげで電話帳には、「ムハンマド・ムハンマド・ムハンマド」氏が何人も並ぶという（「やわらかなアラブ学」田中四郎・著、P.186）

そんなバカな、こないだ会ったアラブ人はちゃんと姓名があったぞ、とお思いの方もおられるかもしれない。たしかにビジネス上で名刺をやり取りするような階層の人は、そういう氏名表記をしている。でも、それは彼らが西洋流儀に合わせているらしいのだ。たとえば、苗字と名前の間にビンbinがはさまる時があるが、これは父親ないし一族の名前を示している。後ろに出身地を持ってくる場合もあるらしい。

ちなみに、かつてのイラクの独裁者は、「サダム・フセイン」といい、日本の新聞は彼を「フセイン大統領」と呼んだ。しかし彼の本当の名前は「サダム」一語であり、「フセイン」は区別のためにつけた父親の名前であった。だから本来ならば「サダム大統領」というべきだったのだ。実際、湾岸戦争の時、ブッシュ大統領（父）は演説で彼を、「サダーム」と名指しで繰り返し呼んだが、それは正しかったのだ（ブッシュ家は石油業界と深いつながりがあり、アラブ圏ともかなり交流があった）。

トルコも昔は名字がなくて、建国の父ムスタファ・ケマル・アタチュルクも、本来はただのムスタファさんだった。ケマルは士官学校時代につき、アタチュルク（＝「トルコの父」）は後に議会から贈られた称号である・・

いや、もういいだろう。とにかく、わたし達が単純に、「人の氏名＝名字＋名前」だと思っている方程式は、海をひとまたぎ超えると、もう通用しにくくなるのである。

そんな苗字のない状態で、どうやって一族の結束を保てるのか？　そう思う人もいるかもしれない。だが、それはまさに、わたし達の3〜4代前の父祖にたずねてみるべきだろう。その時代の人達よりも、今のほうが、祖先を大切にしていると言い切る自信は、わたしにはない。

ついでにいうと、中村日吉丸から木下藤吉郎を経て、豊臣秀吉になった人の例を見れば分かる通り、昔の日本人は生涯に何度も姓名を変える例が、少なくなかった。それでも、この小柄な武将は、自分のアイデンティティを失うことはなかったはずだ。

自分の名前は確かに自分の大事な一部だが、すべてではない。愛着のある人も多いだろうから、他人が変えることを強制するのはどうかと思う。だが、出世魚のように社会的な場面を切り開くごとに、自分でつけ直せたら面白いんじゃないかと感じることもある。実際、SNSなどの匿名コミュニティごとに、違ったIDを使い、違った自分を演出する人だって多いではないか。そこまでいかずとも、筆名・雅号などは昔からあったことだ。

わたし自身は、匿名のネット・コミュニティというのはあまり好きではない。だから、会社員であるにもかかわらず、本サイトは自分の実名で運営しているし、コメント欄にも、原則として実名かそれに準ずる名前で書き込んだ人にしか、答えないことにしている。何か議論する場合は、本当はフェース・ツー・フェースで話し合うべきであり、せめて文字だけでやり合う場合も、自分の社会的アイデンティティを表に出して、自分の発言の結果を引き受けるのが礼儀ではないかと思うからだ。

名前とは、社会的なアイデンティティに対するトレーサビリティの標識のようなものである。「イチロー」のようにたった一語でもいいし、「柳生但馬守宗矩」のように職名（＝変数名）がはさまってもいいが、その人の具体的な身体や所属や係累、来歴が立体的にとらえられることが、人と人がつながるためには大事なのだ。匿名コミュニティが好きになれないのは、そうした「つながり」の価値を軽視しているように感じるからだ。スパイ組織ではあるまいし、コードネームだけでどうやって、相手を信頼できるというのか。

そういえば、「イエス・キリスト」も、イエスが名前でキリストが苗字だ、と思っている人をたまに見かける。言うまでもなく、『キリスト』は救世主という意味のギリシャ語であって、要するに「救世主イエス」という称号である。もちろん、本人がそう名乗っていた訳でもない。あとからついた呼称である。

今から2千年ほど前に生まれたこの人は、イェシューという名前を持っているだけだった（イェシューは「ヨシュア」という名前のガリラヤ地方風の発音）。他の人と区別するために、出身地をつけて「ナザレのイェシュー」とも呼ばれた。ちなみにナザレの地元の村では、「マリアの息子のイェシュー」と呼ばれていたようだが、普通は父親の名前をつけて呼ぶべきところだから、もしかすると父親のヨゼフ氏は、彼が社会的に活躍するずっと前に亡くなっていたのかもしれない。

彼が生まれた当時、ユダヤは全体としてローマ帝国の辺境に位置する属国であり、間接的な植民地支配下に置かれていた。一応、王もおり、大祭司もいて、民族宗教の最高の象徴であるエルサレム神殿もある。だが、ほんとうの意味の主権はユダヤ人にはなかった。軍事も司法も納税も、ローマ帝国におさえられていたのだ。そうした時代が長く続き、抑圧された民衆は次第に、救世主の到来を強く待ち望むようになる。

ただしこの人は平民の出身だった。当時の観念では、高貴な血筋の出身や大金持ちなど恵まれた境遇の人ほど、神に近いはずだった。それなのに、「貧しい人々は幸いだ、神の国は彼らのものだ」などと物騒なことを説教して回る。「仲間の中で最も小さい者に対して、あなたがすることは、このわたしに対してするのと同じことだ」ともいった。

この人の中心的なメッセージの一つは、「人とのつながりを大切にすること」、すなわち、通常は『隣人愛』などと訳されている行いである。それは、抽象概念としては美しいが、実際に実行するのはとても大変な業である。だって知っての通り、わたし達はみな、凸凹のある、長所もあるが欠点も多い存在だからだ。

それでも、人と人とが対等につながることを、そして支え合うことを、とても大事だと教えた。些末な律法を全部暗記して、従うよりもずっと重要だ、とも（こういうことを主張するので、結局この人は地上の権力からも宗教界からも迫害されることになる）。

つながりというのは、信頼がなくては保てない。信頼というのはつまり、お互いを裏切らないこと、不確かな未来への期待に応えられること、を意味する。それは対等な間柄で、自由意志によって結ぶものであろう。

もちろん、家族や、仕事上の職位の序列だって、人のつながりの一種ではある。ただ、それは短期的に、自分の意志で選んだり変えたりすることはできないものだ。そしてしばしば上下関係を伴う。植民地支配下に置かれ、支配者と貧しい民衆に二極化した当時のユダヤ社会では、そうした息苦しい関係性の網目がくまなく覆っていたに違いない。

そんな社会を蘇生させ、より良い希望の便りをもたらすのは、人と人との間の自由で対等なつながりである、という意味のことを彼は説いた。少なくとも、彼はそれを短い生涯の中で実践してみせた。

クリスマスChristmasという言葉は、キリストのミサ（Christ + Mass）から来ている。今はキリスト教徒でなくても、キリスト教国でなくても、日本をはじめ多くの国で、人々はクリスマスを祝っている。もちろん商業主義の後押しもあるだろうが、それでも冬至の、陽の光が一番短い時期に、なにか新しい誕生が予感できるのは喜ばしいからだろう。その誕生劇は、厩の中で、いちばん貧しい階層から生まれるのだ。

そして何より、そのお祝いは、名前も顔も持つリアルな人と人の間で共有される。祝祭は何より身体的で、感情的なものだからだ。わたし達が、社会の中の単なる記号やIDから、アイデンティティを持つ生身の人間に戻る時、そこにようやく祝典のつながりが生まれるのだ。

＜関連エントリ＞

　→「クリスマス・メッセージ：幸せな人」 （2014/12/23）

書評：「彼女は頭が悪いから」 姫野カオルコ・著

「彼女は頭が悪いから」姫野カオルコ　（Amazon）

ちょうど1年前の12月、東大で開かれたシンポジウムを聞きに行った。東大生5人による強制わいせつ事件に想を得た話題の新著、『彼女は頭が悪いから』の著者・姫野カオルコ氏を招いてのブックトークである。姫野さんの外に、スピーカーとして、文藝春秋の編集者と女性活動家、そして東大の教官数名が登壇した。イベントは駒場キャンパスの銀杏並木角にある地下ホールで、平日の夜に行われた。

今思い出しても、このシンポジウムはまことに東大的だった。ひどく真面目なのに、全体としてひどくバカげている。どうしてこんなシンポになってしまうのか。疑問を感じながら家路についた。

シンポジウムではなぜか、この小説にリアリティがない、ということに批判が集中した。その理由として、三鷹寮だとか入試問題だとか女子学生の比率などが、事実と違っている、という論拠が揚げられた。しかしどうやら、この小説に描かれている東大生たちは屈折がなさすぎて、自分たちと違いすぎる、感情移入して読めない、ということに皆が引っかかっているらしかった。だとしても、そのことに、なぜあんなに怒っている参加者が多かったのか。

「彼女は頭が悪いから」は、小説＝フィクションである。ちょうどマンガの「巨人の星」がフィクションであるように。

「巨人の星」には、長嶋茂雄をはじめ、実在の人物がたくさん出てくる。だが、実際にあったことをマンガにしたものではない。読売巨人の「中の人」が、あのマンガを読んで、「実際の読売ジャイアンツとはいろいろと違ってる」といってみても、それは批評にはならない。あそこでは、世間の人が、巨人軍について持つイメージを元にした物語が、描かれているのだから。

姫野さんもシンポの冒頭で、「この小説は、東大の人に向けて書いたものではない」と、わざわざ説明している。だが、なぜ東大の人たちは、教員も学生も口をそろえて、『彼女は頭が悪いから』にリアリティが欠けていると著者を批判するのか。人が些細なことに対して、妙に激しく怒るときは、そこに何か見えない心理的機制が働いていると疑ってしかるべきだろう。

わたしは一応、東大の大学院で毎週講義を持ち、それを足かけ8年にも渡って続けてきた人間だ。だから世間の平均的な人よりは、東大生という人種を多少は知っているといっても、バチは当たらないと思う。そして上記の問題は、西村肇・東大名誉教授の次のような発言に、ヒントがあるのではと感じるのだ：

「私は東大をやめてから、初めて東大の卒業生の性格がよく見えてきました。初めて、東大以外の卒業生と深くつきあうようになったからです。その結果、いままで気づかなかった東大卒業生の性格のいやな所、問題のある所が、とてもよくみえてくるようになりました。

私が痛感している点は、三点です。

まず第一は、劣等感の強いことです。これはちょっと意外かもしれませんが、本当です。○○天才などと呼ばれていたものが、東大に入ると、とてもかなわない奴がいることを知って、自信が根本的に崩れてしまうのです。しかしそれを認める余裕がなく、隠そうとします。ですから、東大卒業生は批判されることを嫌い、本当に批判されると壊れてしまいます。ガラスの器のようです。」

（西村肇「日本破産を生き残ろう」 日本評論社・刊、P.152）

東大の卒業生は劣等感が強い。しかし、それは無意識の下に隠されていて、自分でも気づかずにいる。このことは、東大出の人たちと付き合う必要のある人間は、覚えておいた方がいい。彼らは傷つきやすく、本気で批判されることに弱い。だからそういう失敗のリスクのある場は、無意識に避けようとする。Stupid（バカ）なことはしない、というのが東大卒のポリシーなのだ。

ただし、それは自分一人の時である。周囲に誰か同じことをする人間がいて、自分に言い訳が立つ、と判断できたら、彼らもバカな事に興じたりする。この小説の事件が、単独犯ではなく5人の連行犯だったのは、そういう事情を示しているかもしれない。

ところで、本書に登場する東大生たち、副主人公格である竹内つばさをはじめ、和久田悟・國枝幸児・石井照之（エノキ）・三浦譲治ら、いわゆる「星座研究会」の5人はいずれも、あまり劣等感なり屈託がないキャラ作りになっている。わりと素直に育ち、かつ周囲の人間に対する無条件の優越感を持っている。少なくとも、世間の人たちは、東大生とはそういうものだ、と信じている。

この点が、現実の東大生たちの気に障るのだろう。シンポでは、自分たちも挫折を経験している、というような発言が繰り返し出た。だからどうだというのか？　基本的にこの小説は、「中の人」向けに書かれたものではないのだ。もちろん、竹内つばさに感情移入できる読者は、世間でも決して多くあるまい。少なくとも、わたしにはとても難しい。

ついでにいうと、シンポでは、ある教官が、「このような事件が起きた背景には、東大の女子学生の数が、男子学生に比べて圧倒的に少ない、という非対称性がある」という意味の発言をした。

だが、ちょっと考えてみてほしい。もしこのような言明が正しければ、男子学生の比率がもっと高かった昔は、同種の事件がさらに多数起こっていたはずだろう。東大が女子学生を受け入れ始めたのは昭和27年からで、それ以前の東大は男子校だった。かりに時代の変化があって単純に比較できないとしても、じゃあ現代における同種の事件と、各大学の男女比率をもとに、証拠立てるべきだった。

この論者は、自分の主張を事実に照らして検証しよう、という姿勢に欠いている。読者諸賢よ、安心されたい。東大の知性なんて、この程度のものなのだ。

だが、東大以外の世間の人達の方は、ある意味、もっと訳わからない。事件が報道され明らかになってから、被害者である神立美咲の家に電話をかけてきて、いきなり「勘違い女の家？」「バカ女、聞いてるか？」などと怒鳴ってくる人間の大半は、おそらく東大卒ではあるまい。この小説はフィクションだが、この部分は相当に、現実起きた事に近いと思われる。

女性が性的な暴行を受けた後で、周囲から逆に非難されて傷つくような現象を「セカンド・レイプ」と呼ぶらしい。主人公の美咲を襲ったのは、そして摂食障害にまで追い詰めたのは、まさに世間の人間達によるセカンド・レイプだった。

しかも念のために書くと、美咲はレイプされた訳ではない。「5人の男たちが一人の女を輪姦しようとしたかのように伝わっているのはまちがいである」と、作者はプロローグの第1頁に書いているほどだ。たしかに竹内つばさ達5人が、美咲に対して行った事は、「強制わいせつ」に相当する、非道い行為である。だが世間の人間が、報道テロップから単純に連想するような犯罪ではなかった。

にもかかわらず、そのような「いやらしい犯罪」の被害にあったのは、被害者の美咲が「勘違い女」で、悲劇の原因は「彼女の頭が悪いから」だという、ひどく逆立ちした理由付けが、ネットを中心に広まった。一体何を、勘違いしたというのか？　その疑問こそが、この小説全体のテーマである。

そして、その答えは、はっきり言語化した形では、小説内には書かれていない。作者も、読者も、その疑問を未解決なまま共有し続けるように、この小説はできている。無論、モラリストで心優しい作者のことだから、被害者の美咲をどん底に突き放したままで終わるような書き方はしないが。

ところで姫野カオルコの小説の中でも、本書は登場人物が多い。しかも複数のエピソードが時代を渡り錯綜して描かれるので、わたしは途中で登場人物表を作って、最初に戻って読み直したほどだ。おまけに、「グレーパーカ」の彼氏のように、結構重要な人物なのに、名無しのままのキャラも数名出てくる。プロの小説家だからまさかとは思うが、途中でキャラに命名するのに疲れたのだろうか？

命名ということでいうと、美咲の通う「水谷女子大学」が仮名なのは当然としても、本書に出てくる学校名には、「東大」「慶応」「理科大」など実在のものと、「横浜教育大」のように仮名のものが混じっている。著者がどのような意図で、この使い分けをしたのか、考えてみると面白い。実名で出てくるのは、「日本女子大付属中」「日大芸術学部」を含め、歴史ある名門と言われる学校だけで、仮名は「その他大勢」でしかないのだ。

また、つばさが大学初年で足を怪我し、微妙にパドルテニスを楽しめなくなった、というあたりの伏線は、いかにも小説的に巧妙だと思う。ちなみに本書は、発刊後1年近く経ってから、あらためて「柴田錬三郎賞」を受賞している。受賞が遅くなったのはむしろ、マスコミ的な興味とは別の、小説的な価値を認められた証左だろう。

とはいえ、この小説は、悲劇的な結末に向かうことが分かっているだけに、読み続けるのがなかなかつらい。とくに主人公の美咲が、東大生で主犯格のつばさと、綱島で2回目のデートをするあたりが、一番悲しい。

それにしても、この小説で描かれている一つの事実がある。それは、

　「頭の良い人間は、頭の悪い人間に対して、どんなことをしても良い」、

という恐ろしい思想を抱いてる人間が、この社会には一定数いる、という事だ。

あるいは、「勝ち組は負け組に対して、どんなひどいことをしても正当化される」と信じている連中が、今の世にはそれなりに存在するということだ。少しはまともだったはずの、わたし達の社会は、もうそこまで落ちぶれてしまったことを、この思想は示している。

18歳の冬のある数日間、たまたまペーパーテストのパフォーマンスが良かったからといって、その人間が一生優秀である保証などないし、一生優越的な立場にある社会は、明らかに間違っている。人はむしろ、大学を卒業後、どれだけ考えどれだけ学ぶかで、賢さが決まる。生まれつきの知能の良し悪しには多少の差があっても、また家の経済的境遇には差があっても、この点で人は互いに対等だ。このまっとうな道理が、通らない世の中になりつつある。

だとしたら確かに、わたし達は皆、頭が悪いのだと言えよう。

＜関連エントリ＞

　→「試験は誰の責任か　－　人材のサプライチェーンマネジメント再考」 （2011-03-05）

　　（東大生の非行に対するわたしの基本的な考え方は、 この記事に記したとおりだ。）

工場コックピットで、何を見たいか？

上層部へのプレゼンは、呆気ないほど短い時間に終わった。あなたが懸命に準備して訴えた、「工場コックピット・システム」の提案は、事業部長からそっけなく拒絶されたのだ。あなたはIoT技術の進展、ライバル会社や欧米企業がスマート工場に向けて着実に動いていること、AIによる故障予知や熟練工スキルのデジタル化などのメリット、工場内で起きている事象をリアルタイムに可視化することの意義を訴えたが、通じなかった。

あなたの脳裏には、2年半前に欧州の展示会で見たエス社のシステムのイメージがあった。エス社が満を持して発表した、M…と言うソフトウェアは、工場内のあらゆる機械やデバイスから信号を受けとり、IoT技術によってクラウドにあげる。ユーザはあらかじめ定義された様々な部品を、グラフィックに組み合わせることで、自社の複数の工場にまたがる、様々な機械や人の動きを、リアルタイムに画面表示できる。

それは工場の通信ネットワークから、産業機械類、それらをコントロールするPLC、さらに上位系のソフトウェアまでを、幅広く持っているエス社ならではのシステムだった。工場に並ぶ工作機械は、ほとんどPlug & Playの状態でM…システムに接続でき、その制御パラメータ等も、上位から変更することができる。あなたはその技術の先進性と、インダストリー4.0に向かって邁進するドイツ産業界のスピード感に、舌を巻いた。

そうはいっても、日本の自社工場内では、様々な状況が異なる。機械もPLCもメーカーはバラバラで、互いに接続できるような通信系統もない。制御盤を持たない古い汎用機も、数多く存在する。あなたはそれでも、様々なセンサーと通信を組み合わせることによって、なんとか主要な機械の稼働状況をモニタリングできる仕組みを考案した。自動倉庫の制御システムWMSとも接続し、在庫状況もリアルタイムに表示できるようになる。セキュリティの懸念からクラウドは断念し、エッジサーバ上に構築しようと決めた。

あなたはこれを「工場ダッシュボード」と呼んだが、副工場長の助言に従って「工場コックピット」といい直すことにした。ダッシュボードでは自動車の運転席みたいだが、コックピットは戦闘機の操縦席である。「うちの会社は今、生き残りをかけた戦闘中だからな」と副工場長は言った。

だが、営業畑出身の事業部長の反応は、ニベもなかった。「うちの工場が、高コスト体質にあるのはよく知ってるはずだろ。このシステムは、下手をすれば億を超える金がかかるそうじゃないか。そんな投資は論外だ。」 賛同してくれると思った工場長も、意外に否定的だった。「うちの工場は、現場改善が命だ。デジタル化やAI技術では、現場主導のPDCAが回らなくなる。」

「こんなものに頼らないと、君は工場を経営できないのか?」事業部長が皮肉を込めて、工場長に尋ねる。「もちろん今でもちゃんとやっております。」当然ながら工場長はそう答えた。 あなたは懸命になって、「ですが、このシステムは一緒のカーナビのようなものです。現在の位置を正確につかみ、より効率的な経路を見つける手助けをしてくれます」とフォローしたが、工場長には響かないようだった。

意外だったのは、頼みにしていた長老の技術顧問も「リアルタイムの可視化だけでは得るところが少ない」と消極的なコメントをしたことだった。あなたは、ゴルフ焼けした事業部長の顔を見つめながら、それ以上反論することを断念した。

席に戻ったあなたは、自分の会社への気持ちが急速にしぼんでいくのを感じた。翌月、あなたは思うところあって、会社に辞表を提出する。政治の世界に転身することを決めたのだ。このままでは社会全体がダメになってしまう。何とか根本から変えなければいけない。

数年後、あなたはいくつかの幸運や、有力者のバックアップなども得て、党代表の地位に上り詰めた。さらにその半年後、総選挙で政権党がスキャンダルのため総崩れとなり、あなたの党が第一党となった。おめでとう。あなたは首相の座を手にしたのだ。

あなたは首相執務室の横に、かねてからの願いであった「首相コックピット」を設置することにした。日本社会全体の状況をリアルタイムに表示し、それを見ながら、あなたは次のうち手を考え、命令を下す。

では、その「首相コックピット」の画面には、何を表示すべきだろうか？

何よりも急務なのは、経済の立て直しだ。25年以上の長い不況を、終わりにしなければならない。だから第一に、GDPと、成長率の表示が必要だ。それも国全体だけではなく、都道府県別の数字が見たい。

政策の基本として、人口データの表示も必要だ。高齢化と人口減少が、多くの人を悩ませている。この流れを食い止めなければならない。もちろん就労人口と失業率も、経済指標として大切だ。

ところでGDPとは、企業セクターの稼ぐ粗付加価値額の、総合計である。したがって、各県別のGDPを、その県の就労人口で割ったものは、そこの付加価値労働生産性を示すことになる。これが地域によって案外バラバラなことを、あなたは肌で感じている。

例えば最近では、名古屋都市圏の経済規模は、大阪を抜いたと言われている。だとすれば限りある国の資金も、大阪から引き抜いて名古屋に投入した方が、有効活用されるはずだろう。

有効に活用されてない資源を引き抜き、より活用されているカ所に振り向ける。これこそ政策ではないか。首相たるあなたはそう考える。そういえば会社員だった時、ERPと言う言葉を聞いたことがあったな。ERPとは、Enterprise resource planningの略称であった。すなわち企業全体の経営資源の、最適な再配置をするための道具。だとしたら、自分がやっているのは、National resource planning = NRPシステムの構築だな。

である以上、交通や都市インフラへの、財政投融資の状況も見る必要がある。また、医療費や福祉介護への費用、教育費用等についても見たい。食料自給率の観点から、農業データへの目配りも大切だ。

これを実現するためには、全省庁と自治体をまたいだ、データ収集基盤のようなものが必要になる。時系列で非定形なデータもあるだろうから、巨大なデータレイクといったところだろうか。有能なデータサイエンティストを何人か連れてきて分析させれば、得られる発見も大きいだろう。

いかん、大事なことを忘れていた、とあなたは気がつく。防衛である。国土を守る防衛システムにも接続して、状況を見えるようにする必要がある。国家存亡の危機事態には、この官邸こそが、まさにその司令塔＝コックピットになるはずではないか。

よし。これで万全だ、とあなたは思う。これで、某仮想敵国が北海道に攻め込んでこようと、別の某仮想敵国が南西部の島嶼を襲撃しようと、さらに別の隣国がミサイル（最近マスコミは妙に遠慮して「飛翔体」と呼んでいるが）を打ち上げてこようと、すぐに出撃対応できる。さすがに例のT大統領が、思いつきで何か難癖をつけてくるのだけは、防ぎようがないが。

かくて、巨額の費用をかけて、「首相コックピット」は完成した。これであなたは、日本をうまくマネージできるだろうか?

あなたは経済政策こそが第一優先だ、と考えた。だが、経済活動は企業が主役である。あなたは法律や税制を通じて、企業経営者に間接的に働きかけることができるだけだ。計画経済ではないのだから、これを作れ、あれを売れ、と自分で指示することは不可能だ。つまりコックピットに座るあなたの操縦桿は、じつはエンジン出力や翼の方向を直接、変えることができないのだった。

人口動態や保健医療についても同様だ。出世や結婚は各個人の行うこと。命令はできない。保健医療も、国や自治体が担うのはその一部でしかない。後は、民間の事業者に任せて効率化を図ってきたはずなのだ。

そもそも経済対策といっても、あなたに切れる札は、金融政策と、財政出動しかない。では金利を0.1%上げさせたとき、あるいは一兆円の公共事業投資を行った時、経済はどのように反応して動くのだろうか?　もしマクロ経済学に確とした予測方法があるのなら結構だが、そうでないからこそ、この国はこんな状況に陥っていたのではなかったか。

あなたは付加価値生産性や失業率を、重要な経済指標と考えた。だが、では、その数値がどの範囲だったら正常で、どこを超えたら変調を示すのか、決めることができない。せいぜい海外や過去のトレンドと比べるだけだ。あとは、あなたのカンによる気付きに頼るしかない。異常が検知できないモニタリング・システムとは、どのような意義があるのか？

もう一つ。コックピットの前に座る人が、陥りやすい罠がある。それは「選択と集中」による資源の再配置、という思考方法だ。大阪から名古屋に資金や資源を再配置すれば、経済効率が上がるだろう、とあなたは考えた。それは、大阪と名古屋がまったく独立した経済圏ならば、正しいかもしれない。しかし両者の間には、様々なインタラクションがあり、相互依存性があるのだ。ある地域の効率低下が、別の地域の経済の足を引っ張る可能性もある。

それは産業間の資源再配置でも同じだ。各産業が全く独立しているなら、有力な産業に集中する意義もあろう。しかし産業間の連関や労働力のとりあいを考えれば、経済システムというのは単なる要素の足し算ではないことが分かる。

すべての結果は要素の掛け算と足し算で計算できる、という思考を、工学の世界では、「線形的」思考と呼ぶ。人間系が絡む大規模システムの最大の特徴は、線形ではないことだ。それは工場や、一般の企業組織も同じである。そうした要素間の有機的な関係が、コックピットで見えるように表示されていないと、間違った方針設定をしてしまうリスクが高くなるだろう。

結局のところ、「首相コックピット」は、起きている事態のモニタリングはできるが、リアルタイムに現場に指示やガイダンスを出すこともできず、標準値に基づくフィードバック・コントロールもかけられず、異常な変調にも対応できず、要素間の連関性も見えず、打ち手の結果予測すらできない。これでどうやってあなたは、日本国家全体をマネージするのか？

ふりかえって、あなたが会社員時代に作ろうとした「工場コックピット」は、これと本質的にどこが違うのだろうか。

もちろん、国の経済社会システムと、一企業の工場では、いろいろな点が異なる。工場は生産という目的が明確で、利益を目指して動く。製造工程もはっきりしている。一国の社会ははるかに多目的、ないし「存続自体が主要目的」であって、経済合理性だけでは動かない。それでも、より良くマネージするためには、単なる状況の可視化以上の工夫が重要であろう。

誤解しないでほしいのだが、わたしは工場ダッシュボードや経営コックピットといった、可視化の仕組みそれ自体の意義は、十分評価している。ただ、少なくともそこには、現場に対するインストラクションやガイダンスを直接下せる方法と、変調（標準値・目標値からの逸脱）をわかりやすく表示する仕組みが必須だと考えているのである。ユーザの気づきを促すような表示の工夫が大切で、データサイエンティストを連れてこないと状態がわからぬようでは、話にならぬ。

また現場側が、このシステムを通じて、単に「監視されている」と感じるだけではなく、問題が起きたときに、すぐに上が対応し、支援し助けてくれる、という感覚を醸成することも、この仕組みが機能する必須の条件である。

その上で、望むらくは、何らかの予測とシミュレーションの機能が欲しい。あなたが事業所部長に、「これはカーナビです」と言った時、それは半分正しかったのだ。カーナビは少なくとも、最短経路を選んで、到着時間を予測してくれる。

ただしカーナビは、自分の位置を測定するGPSを積んでいる。工場では、どの機械や人が動いているかを知るだけでは、状態把握としては十分ではない。それがどの品目を加工していて、どこまで進んでおり、どのオーダーに紐付いていてるか、までリアルタイムに分からないと「現在位置」の役に立たないのだ。そして、その実現は、決して簡単ではない。

それでも、それは向かうに値する目標である。それは、工場全体レベルでの賢さ（「スマートさ」）を持つためには必須なのだ。賢さとは、答えを出す頭の回転の速さ、の別名ではない。全体を見通し、自分で気づき、事実から学ぶ能力を言うのだから。

＜関連エントリ＞

　→「『スマート工場』はスマートか？」 （2018-05-26）

　→「IoT時代のMESをもう一度考え直す 〜 (3) MESの未来像とは」 （2017-09-04）

PMにはなぜ設計論がないのか？

前回の記事（「プロジェクト＆プログラム・アナリシス研究部会」（12月2日）開催のお知らせ）でも少しふれたが、なぜPMBOK Guide(R)には「設計論」がないのか、不思議に思われている方も多いと思う。米PMI (Project Management Institute)が'90年代に作成し、現在は改定第６版になっているPM界の標準ガイドブックは、10個のマネジメント領域を定義している（最初は9個だったが、途中からStakeholder Engagementが加わって、10個になった）。その10のエリアには、「調達」や「品質」があるのに、肝心の設計マネジメントがない。

プロジェクトにおいて、もしも設計がまずかったら、実装段階でどんなに頑張っても、良いプロダクトは生まれない。つまりプロジェクトの価値は上がらない訳だ。プロジェクト・マネージャーの任務は、プロジェクトの価値を最大化することのはずである。だとしたら、なぜ、設計論が欠落しているのか？

どうやら、初期のPMBOK Guideを作った人たちの頭の中には、設計（Design）の重要性の概念がなかった、としか思えない。その結果、今頃になって、やはりプロジェクトの成功には、良い基本設計が欠かせない、と気づいた。だからPMIはビジネス・アナリシスの標準プラクティスを制定しようとしたりしている。

ちなみに、設計と実装が一つのプロジェクトの中で一貫して行われるか、それとも別の企業に担われるかについては、業界および国の慣習によって、まちまちである。

たとえば、ビルや橋などをたてる、いわゆる一般建築や土木建設の分野についていうと、日米でバターンが異なる。基本的に、米国の建設会社には、設計機能がない。この点は日本のゼネコンと大きく異なっている。日本のゼネコンは（とくに大手は）かなりレベルの高い設計部門を抱えていて、独立した建築設計事務所と張り合っている。そしてしばしば、「設計施工一貫」という方式でプロジェクトを受注する。

しかし米国や英国は違う。建築設計は、設計事務所にいるアーキテクト（建築家）たちの専任事項である。アーキテクトがデザインした図面と仕様書をもとに、建設会社が工事をする。工事が図面通り適正に行われているかを、建築事務所がチェックする。この仕事を日本語では設計監理とよぶ（同じ音の「管理」と区別するため、「さらかん」といったりする。監の漢字の下にお皿があるからである）。設計と施工を分業するので、「設計施工分離」方式と呼ぶ。

このような分業と相互チェックの体制になっているため、英米の建設会社では一般に、設計機能を持たないのである。そして彼らは、工事のプロジェクト・マネジメント能力をもっぱら売り物にする。

ちなみに日本の官公庁のかかわる一般建築は、制度を英国に見習ったためだろう、同じように設計施工分離の方式がベースになっている。そして原則として、設計の後、工事は入札が行われる。だがふつうの民間工事では、しばしば同一のゼネコンが設計も施工も行う。理由の一つには、途中で工事入札をはさむよりも、全体期間が短くなるためである。

一般建築の他にも、発注者である官庁側が基本仕様の定義や基本設計までを行い、受注者が詳細設計と実装（製造）を担う、という業界はまだいろいろと存在する。米軍と軍需産業の関係なども、わたしは詳しくは知らないが、実はそうなっているのではないか。だから初期のプロジェクト・マネジメント概念を育てた米国の航空宇宙産業だって、似たような感覚があったのもしれない。

ちなみに、わたしが働いているプラント・エンジニアリングの業界は、両方のパターンが存在する。原則として、基本設計（業界でFEED = Front-End Engineering Designと呼ばれる）と、詳細設計・調達・建設（EPC = Engineering, Procurement & Construction）とは、別フェーズで遂行されるのだが、どちらも担うのは同じエンジニアリング業界の企業であり、プレイヤーが一般建築のように分業化していない。

おまけに、FEEDとEPCを一貫して遂行するプロジェクトも、ときどき存在する（とくに入札による透明性よりも工期短縮を重視する私企業が発注者の場合）。だから、エンジニアリング業界では、PM能力の重要な要素として、『エンジニアリング・マネジメント』が入ってくるのだ。

話を戻すが、設計と施工（実装）を受け持つ会社が別々になっていて、前者はデザイン能力を、後者は実装のプロジェクト・マネジメント能力を売り物にする、という業界にいる人達は、PMの技術の中に設計論がなくても、不思議はないだろう。

ただし、設計と実装が会社（業界）として分離していると、まずいこともある。

一番大きな問題は、実装段階における技術やノウハウが、設計段階にフィードバックされにくい点だ。たとえば、ビル建築の世界で、新しい建設工法が開発されたとしよう（たとえばジャッキアップ工法など）。当然ながら、その工法を活かせるような設計が必要である。しかし建設工法の開発はゼネコンが行っていて、そのノウハウは建築設計事務所にはすぐに共有されない。

製造の分野でも似たような事情はあるはずだ。新しい加工方法（たとえば3D printerによる金属積層造形など）が開発されたとしても、設計はデザインハウスが行い、製造は受託製造企業EMSが行う、というような分業が進んでいると、製造技術の進歩がすぐに設計に取り入れにくくなってしまう。

つまり、設計と実装が分離した形でプロジェクトを進められるのは、実装技術の進歩がゆっくりしている分野のみだ、とも言えよう。

もちろん、設計段階はスコープが柔らかく、実装段階に入ると、スコープはかなり固まるのが常だ。だから、発注者と受注者がフェアなリスク分担をはかるために、あえて設計と実装のフェーズを分けて、設計段階は実費償還型契約（日本のIT業界の言い方でいえば準委任契約）で行い、実装段階は一括請負型契約で行う、というのはもちろんあり得る。ただ、これはプロジェクトのフェージング技法であって、だからプロジェクト全体における設計マネジメントの重要性が減る、というわけではない。

あるいは、アジャイル開発のケースを考えてもいい。アジャイル開発はソフトウェア分野特有の方法論だが、設計と実装を細かな単位のサイクルで回し、機能を順に付加していく。アジャイル開発活動の主要なモチベーションは、それまで設計の下請け状態に置かれていた実装の仕事を、設計と同格の位置に持ち上げたい、というプログラマたちの悲願にあった。だからあえて、設計と実装が渾然一体となったグループ組織で進めるのだ。

下請け。そう、IT業界では長らく、SI系の受託開発プロジェクトを、大手計算機メーカーが「ゼネコン」として元請け受注し、実装部分を子会社や関係会社に下請けに出す、という業務形態がとられてきた。設計と実装の分業は、建築分野のような業界単位の棲み分けではなく、「企業の順位」を基準に行われてきた。何やら江戸時代みたいな「身分差」で決まる、とさえ言いたくなる実態があった。

そのくせ、元請けの大企業が担うから、設計品質や設計マネジメントはちゃんとしていた、と言えるかは、けっこう疑問なのである。システム設計とは、どういう仕事なのか。設計の品質（「前向き品質」）はどう、とらえるべきか。いわゆる「システムズ・エンジニアリング」の手法は、ITシステムの設計に応用可能なのかどうか・・とった設計に関する本質的な議論を、あまり聞いたことがない。聞こえてくるのは、開発方法論と、ソフトウェア工学の手法論がせいぜいだ。

もしも日本の大手IT企業が、本当に設計に大きな価値を認めているならば、SIビジネスの利益構造は別の形になっているべきだった。すなわち、「設計段階」で大きな報酬を得て、「実装段階」では、かつかつの利幅で受ける、という風になるはずである。だって良い設計のほうが、正しい実装よりも、ずっと顧客にとって価値が高いのだから。そしてエンジニアという人種は、何より、優れた知恵をお金に変えたいと願う存在だ。

しかし、現実にはそうならなかった。SIビジネスは、なんといっても実装部分で、全体工数の人月に比例して売上と利益を得る構造になっていた。このようなビジネス慣習の元で、設計の重要性がハイライトされるだろうか？　

米国PMIが'90年代にPMBOK Guideを作成するにあたって、設計論のエリアを省略してしまったのは、彼らの国の事情があったのだと想像する。日本が（とくにIT業界が）それを広く受け入れたのは、2000年代に入ってからだ。だが、爾来10数年間、誰もあまり設計マネジメントの欠落を、問題に思ってこなかった。それはとりもなおさず、設計という仕事を、価値の源泉ではなく、単なるコストの一部だととらえてきた結果に思えるのである。

＜関連エントリ＞

　→「システムズ・エンジニアリングとは何か」https://brevis.exblog.jp/25682507/（2017-04-09）

　→「設計の価値」 https://brevis.exblog.jp/2408181/ （2006-01-01）