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

書評：「理解とは何か」 佐伯胖・編

「理解とは何か」 佐伯胖・編（認知科学選書 4　東京大学出版会） (Amazon)

「『理解』という事について研究ができる。なんというすばらしいことだろうか。」

本書の中心にあたる、編者・佐伯胖の書く第5章「『理解』はどう研究されてきたか」は、このような一見ふしぎな言葉から始まる。そして、次のように続く。

「心理学の長い歴史を振り返ってみると、それは『理解』を研究したいという人々の熱い思いが、何度も何度もくりかえし裏切られ、『理解』とは似ていて非なるものばかりを押し付けられ、枠をはめられ、偽物であることを承知の上で無理やりに背負い込まされてきたものであることがわかる。」（P.127）

心理学の素人からすると、「理解する」というのは、人間にとって当たり前の心の働きに思える。だが、それを論じ研究することは、長らく心理学分野のタブーであったらしい。ちょっと驚きである。

だが、なぜ、そのような状態が、日本でも米国でも続いていたのか？（なみに本書は1985年の発刊だ）

佐伯胖は、自分が66〜67年に米国ワシントン大学に留学した際の、当時の米国心理学会の雰囲気をいきいきと描写しながら、その理由を説明する。それは、米国の心理学を1930年代以来ずっと支配してきた行動主義の影響らしい。行動主義とは、「科学としての心理学は、対象を客観的に観察可能な行動に限定すべき」という立場で、意識とか内観といった概念を排除していく。

佐伯胖によると、66年当時の主流派心理学者が認める、科学的研究の方法は次のような4項目であったという（P.136より要約して引用）。

(1) 実験データによる仮説の検証という手続きに基づく

(2) 観測される反応、すなわち行動を説明することが全てである

(3) 理論仮説は、データを説明するための必要かつ十分なものに限ること

(4) 説明は機能主義的説明で足りる。生体の内部構造には立ち入らず、ブラックボックスとしたまあ、その働きを正しく予測できるかどうかを問う

このようなパラダイムの中で研究を行う限り、たしかに「理解」それ自体のメカニズムを論じることは、いたって困難になる。

そうしたアメリカ心理学の強固な枠に対し、揺さぶりをかける動きも、たしかに一部は存在した。たとえば、スイスのピアジェによる発達心理学の業績である。またこれ以外に、フェスティンガーらの社会心理学、サイモンやハントらの情報処理アプローチがあるし、ボールズ、ロカードらの動物習性学・行動進化学の研究もあった。

これらを背景に、アメリカ心理学では67年ごろから「認知革命」と呼ぶべき動きが出てきたらしい。そして、上記の4項目に、さらに2項目を慎重に付け加えていった（P.136）。

(5) 内部機能に関するモデルの想定も許される（ただし実験的に検証が必要）

(6) 生物は外界の刺激に支配され、反応してるに過ぎない、と考える必要はない

わたし達のようなシステム・アナリスト（モデラー）から考えると、まあ当然のような6項目に見える。しかし、こうした変化がごくゆっくりしか起きないのは、それだけ学問研究の「パラダイム」の強さを示している。

佐伯よると、70年代は認知心理学が登場し、「知識」と「スキーマ」が研究の中心になる。72年には、ウィノグラードによる人工知能（自然言語による対話処理システムSHRDLU）が発表される。SHRDLUは積み木ブロックの世界について、人間と自然言語で対話しながら、積み木を運んだり積み上げたり、といった操作を行う。ウィノグラードはこれを心理学研究の一環として進めていた。

また、こうした動きと並行して出てきた、チョムスキー理論の心理学への影響は計り知れない、という（P.146）。チョムスキーはまず、行動主義心理学への批判を行い、さらに生得的な認知能力の仮説を立てる。そして認知過程に関する、生成変形文法という構造主義的アプローチを強める。

かくして心理学は「理解」をめぐって、認知→知識・スキーマ→自然言語、という風に主題を進めてきた。この流れは結局80年代に入り、「認知科学」に合流していく。本書自体が『認知科学選書』（東京大学出版会）の第4巻として発刊されている事が、事情をよく表していると言えるだろう。

ちなみに佐伯胖氏自身は、81〜83年に「LISPで学ぶ認知心理学」全3巻を出しているが、このタイトル自体が、ある種の時代を感じさせる。認知科学は90年代に入って、LISPの得意とする記号的人工知能から、神経回路網モデルをベースにした、コネクショニズム的なAI研究にうつっていく。それが今日のAIブームの基礎となる訳だ。

ただ、この動きはいささか、偏りすぎてきた観もある。記号による手続き的知識と、行列計算によるパターン認識的知識との間に、見えない壁がある現状は、どこかで再度パラダイム変化が必要なのではないか。

ともあれ、本書全体でいうと、マイケル・コール（UCSD教授）による第4章「リテラシー（読み書き能力）の文化的起源」も面白いが、第3章「理解におけるインターラクションとは何か」（三宅なほみ）が興味深い。これは二人以上の人が相手とやりとりしながら、建設的な問題解決をするプロセスを追った研究だ。

インターラクションの例に出すのは、「ミシンはどうして縫えるのか？」という議論だ。ミシンがなぜ布を縫えるのか。これはよく考えてみると、案外難問だ。これを二人で議論していくとき、「課題遂行係」と「モニター係」に作業分担するほうが進みやすい、など面白い知見がたくさん出てくる。

本書の1〜4章は一種のシンポジウムの講演録で、質疑応答も丁寧に収録されているため、とても読みやすい。そして第5章が編者による、まとめと展望だ。ただ時代のせいか、全体をよんでも、「理解」の心理学が、全体としてどのような戦略を持ち、どこを攻めようとしているのか、まだ作戦マップが描けるほどには概観できていないように感じた。

わたしが編者である佐伯胖氏の名前を知ったのは、「『きめ方』の論理　〜社会的決定理論への招待」（1980）をよんだ時だった。これは今でも、画期的な本だと思う。彼自身はその後、「決める」から「分かる」へ、そして「学ぶ」へと、研究分野をうつしていく。それは経営工学から出発して、心理学、さらに教育学へと進んでいく道のりだった。本書はちょうど、その分水嶺に当たる1985年、46歳のときの宣言的な業績である。だから勢いがあって、とても面白いのだ。

`

プロジェクトの生産性と着地点を測るには

2015年7月、東芝は過去7年間に渡って、「不適切会計」で1500億円以上も利益をかさ上げしてきた、という第三者調査委員会の報告を公開した。これに伴い、田中社長を始め、歴代3社長が退任。日本の産業史上最大の不正会計事件となった。

このときの不正に、実はプロジェクトの『進捗率』の計算が、深く関わっていた。というのも、会計操作の手法の一つが、「進行基準」の悪用だったからだ。

「ああ、会計の話なんか興味ないよ。技術屋としての俺の仕事には関係ないから」とお思いの方も、その手口については、少しだけ知っておいたほうがいい。というのも、これは進捗率をどう粉飾するか、という話だからである。しかも、先々のコスト増を無視していると、結果的に売上や進捗率を粉飾したことになってしまう事があるのだ。そして売上や原価は、エンジニアたちの尻を叩くモノサシでもある。妙な叩かれ方をしたくないならば、少しはその仕掛けについて学んでおくべきだ。

一般に受注型プロジェクトの会計には、完成基準と進行基準の二種類がある。そして、複数年次に渡る大規模なプロジェクトでは、進行基準が望まれる。進行基準では、プロジェクトの進捗に従って、毎期ごとに、収益（売上）が計上できる。これに対して、完成基準では、プロジェクトが完了しないと売上が立てられないからだ。普通の経営者にとっては、何よりも売上高が命であり、数年もの間「売上ゼロ」では、何も仕事していないのか、と言われてしまう。

進行基準は、「工事進行基準」とも呼ばれる。建設業会計の世界で発達した手法だからである。しかし作るものが無形のソフトウェアであろうと、工事を伴わぬ大型機械の製造だろうと、考え方は同じだ。

さて、当時の東芝は、次の計算式で工事収益を計上していた（「東芝不適切会計と工事進行基準」清和監査法人」による）：

当期の工事収益 = 工事収益総額 × 工事進捗度 - 過年度工事収益計上額

　ただし、工事進捗度 = 累計工事原価発生総額 ÷ 工事原価総額

この計算式自体は、ごく普通のものだ。建設業であれ、受託ITシステム開発のSIerであれ、進行基準に従う多くの企業は、こうして計算しているはずだ。

東芝の不正手口は、「工事原価総額」を少なめに見積もることで、「工事進捗度」をかさ上げする、というやり方だった。いや、少なめに見積もる、という表現は正確ではない。じつは、プロジェクトの途中で予想されたコスト増を、無視して繰り入れなかったのだ。これによって約500億円もの根拠なき売上が立った、と言われている。そして東芝の会計監査法人は、この問題点を見過ごしていた、としか思えない。

「進捗率」を水増しすれば、架空の売上が手に入る？　どうしてだろうか。

たとえば、今、受注金120億円のプロジェクトがあったとしよう。この案件は、開始から完成まで、たっぷり3年かかる。そして、プロジェクト原価は100億円、利益額は20億円と計算されていた。想定される年度別の計画は、次のようなものであった：

　　　　　発生原価　　累計原価　　進捗率　

１年目　　２０億円　　２０億円　　２０％

２年目　　３０億円　　５０億円　　５０％

３年目　　５０億円　１００億円　１００％

上の式で、進捗度 = 累計原価発生総額 ÷ 原価総額、とあるとおりだ。そして、各年度で、それぞれ計上できる売上と、その年度の発生原価から見た利益額を計算すると、次のようになる：

　　　　　発生原価　　累計原価　　進捗率　　計上売上　　年度利益　

１年目　　２０億円　　２０億円　　２０％　　２４億円　　　４億円

２年目　　３０億円　　５０億円　　５０％　　３６億円　　　６億円

３年目　　５０億円　１００億円　１００％　　６０億円　　１０億円

さて、このプロジェクトの１年目の終わり近くになって、問題が起こった。技術的なトラブルと、顧客側の無理難題が重なって、完成までにさらに４０億円もの追加費用がかかりそうだ、という状況が判明したのだ（２年目に１０億円、３年目に３０億円のコスト増）。まあ、「判明」というのは、経営者にとってであって、担当者レベルでは、最初の頃から「このプロジェクトはまずいな」と思っていたのかもしれないが。

ともあれ、このままでは受注総額１２０億円に対し、原価総額＝１４０億円になってしまい、赤字プロジェクトに転落である。かりにトラブルのスケジュールへの影響が小さく、なんとか３年以内に終わるとしても、正しくは次のような表になるはずだ。

　　　　　発生原価　　累計原価　　進捗率　　計上売上　　年度利益　

１年目　　２０億円　　２０億円　　１４％　　１７億円　　ー３億円

２年目　　４０億円　　６０億円　　４３％　　３４億円　　ー６億円

３年目　　８０億円　１４０億円　１００％　　６９億円　ー１１億円

１年目の進捗率が２０％→１４％に、２年目の進捗率が、５０％→４３％に、それぞれ下がった点に注意してほしい。これは、累計原価の総額が１００億から１４０億円に増えたためだ。そこで、

１年後の進捗率：　２０÷１４０＝１４％、

という計算になる。

だから計上できる売上も、

１年目の売上：　１２０×１４％ ＝ １７億円

に減ってしまうのである。結局、１７億の売上で、２０億円のコスト発生だから、マイナス３億円の赤字になる。２・３年目も同様の計算で、売上は３４億と６９億、原価は４０億と８０億で、都合、６億円と１１億円の赤字だ。

さて。この計算表を見て、不心得な経営者がこう考えたら、どうなるだろうか？

「トータル４０億円のコスト増だって？　そんなの、まだ確定していないじゃないか。少なくとも今期のコストはまだ増えていない。来期以降の増分は、最後に確定してから膿を出せばいいのだ」

かくて、現実を無視して累計原価の総額を２年目まで変更せず、最後に帳尻を合わようとすると、こうなる：

　　　　　発生原価　　累計原価　　進捗率　　計上売上　　年度利益　

１年目　　２０億円　　２０億円　　２０％　　２４億円　　　４億円

２年目　　４０億円　　５０億円　　５０％　　３６億円　　ー４億円

３年目　　８０億円　１００億円　１００％　　６０億円　ー２０億円

バンザイ！　かくて当年度の売上は１７億ではなく２４億に増え、収支も３億円の赤字から、４億円の利益になる。経営者にとって、赤字と黒字では天国と地獄ほど違う。

お分かりだろうか？　プロジェクトで今後発生しそうな（合理的に予見できる）コスト増を無視すると、進捗率も売上も、本来よりもカサ上げできるのだ。だが、結果的にそれは粉飾になる。現実の東芝で起きた事件は、米国の原子力子会社と孫会社を巻き込んでもっと複雑だが、本質だけを単純化すると、上の例のようなことになる。そして、赤字か黒字かは、各社員のボーナスの査定や昇進のみならず、事業部の存続までかかってくる問題なのである。

・・ところで、ここまで我慢して(?)読んでこられた真面目な技術者諸賢は、疑問を感じられたことだろう。「トータル４０億円のコスト増って、どうやって推算したんだ？　そんな事が、全部終わって金勘定を締める前に、わかるのだろうか？　そんな事が分かるくらいなら、誰も苦労しないじゃないか！」

もちろん、本当に「合理的に予見可能」な原価というからには、個別のワークパッケージ単位に、追加変更のコストを積上げ、その発生する蓋然性を評価しなければならない。大規模プロジェクトでは、そこまでプロジェクト・マネジメントを徹底することが求められる。でも、読者が知りたいのは、もう少し身近なプロジェクトの場合だろう。とくに、スコープ＝役務範囲の柔らかい（例えばIT系などの）、プロジェクトの場合に違いない。そんなの、本当に可能なのか、と。

ところが、将来のコスト増を、ある程度の精度を持って推算する方法があるのだ。そこにEVMSの技法が関わってくるのである。

前回の記事（「進捗率を何で測るか？　−−情報処理技術者試験の問題より」）で、わたしは、「進捗率は、今までどれだけ頑張ったかではなく、あとどれくらい仕事が残っているかで測るべき」と主張した。

では、「あとどれくらい仕事が残っているか」をどうやって推算するのか。答えは、CPI (Cost Performance Index)という、プロジェクト遂行の生産性を測る指標によるのだ。プロジェクトのCPIは、次式で定義される量である：

　CPI = EV / AC

つまり、その時点までの出来高(EV)を、その時点までの実績出費累計(AC)で割った数字である。出来高EVとは、完了したアクティビティの予算の合計であった。もしEVとACの両者がぴったり一致したら、計画通りに仕事が進んでいる訳で、CPIは1になる。EVが１よりも大きければ、当初計画したよりも実績コストは小さくすんでいることになる。逆に、思ったよりお金がかかっているなら、CPIは1以下になる。

さて、米国では国防総省を中心に、EVMSに関する膨大なデータの蓄積がある。それによると、プロジェクト全体のCPIの値は、良きにつけ悪しきにつけ、全体工期の２割を超えた時点から、±10%以内の精度で安定することが分かっている。良いなら良いなりに、まずいならまずいなりに、傾向が定まるのだ。

たとえば前回の出題の例では、EV = 5.9、AC = 7.0であった（単位は人月）。だから、

　CPI = EV / AC = 84%

である。簡単に言うと、100円使って、84円分の成果しか上がらないのだ。プロジェクトの生産性が84%と言い直しても良い。

では、このプロジェクトの累計原価発生総額（完成予定額 EAC = Estimate at Completion ともいう）は、どうなるか？　元の見積では、全部で10人月で終わるはずだった（これをBAC: Budget at Completionと呼ぶ）。一方、これまでに、AC=7.0人月使ってしまった。残っている仕事量は、10 - 5.9 = 4.1人月分になる（元の見積ベースでは）。だが、これも84%の生産性で補正しなければならない。つまり

　EAC = AC + (BAC - EV) / CPI = 7.0 + 4.1 / 84% = 11.9

結局、約12人月だろう、ということになる。つまり、2割ほどコスト増が予想されるのだ。

ちなみに、プロジェクト初期の段階では、CPIの値はかなりアバレるから、まだ推算には使えない。この例では、すでに進捗率=59%なのだから、プロジェクトも中盤に入っており、CPIの値は安定すると予想できる。

なお、プロジェクトを構成する各アクティビティは、それぞれ種類も違う固有の業務内容を持っているのに、CPI値が安定するのは奇妙に思えるかもしれない。しかし、独立した変動を持つ分布を足し合わせると、全体としては分散が小さくなる、というのが統計学の教えるところだ。では、そのような推算が成り立つためには、どれくらいの要素数が必要かと統計学者に聞くと、「中心極限定理から、30以上は必要だ」と答えるだろう。

全体の２割を過ぎた時点で、30個以上のアクティビティの実績データが必要だとしたら、EVMSで完成予想額を見るためには、プロジェクト全体では150個以上のアクティビティからなるWBSを持つことが、条件になる。EVMSというのは、それなりの規模のプロジェクト向けの手法なのである。だから例題のような、トータル10人月程度のプロジェクトにEVMSを持ち出すのは、いささか「牛刀をもって鶏を割く」きらいがある。

ここまではまあ、普通のPMの教科書に書いてあることだ。ところで、この話にまだ、少しだけ先がある。12人月で終わりそうだ、という着地点の推測は、本当はまださらに、補正が必要なのである。

実を言うと、EVMSから導出されるプロジェクトの生産性指標は、もう一つある。それがSPI (Schedule Performance Index)で、次式で定義される：

　SPI = EV / PV

ここでPVは、元の計画上での進捗率である。たとえば、本来70%終わっているはずの計画だったのに、実際の出来高基準では59%しか進んでいないなら、CPI = 59/70 = 91% という事になる（ちなみに問題文には計画上の15日時点の進捗率は書かれていないから、上記の91%というのは、単なる例である）。

SPIは、スケジュール面から見た、プロジェクトの効率性を表す。先に紹介したCPIも、このSPIも、分子にEVが来ている点を覚えておいてほしい。SPIもCPIも、値が高いほどよい。1よりも大きければ、計画より効率よく遂行できていることを示す。

そして、米国で蓄積した膨大なEVMSデータによると、プロジェクトの完成予定額EACは、次の式で計算するほうが、より現実のデータに合うというのだ：

　EAC = AC + (BAC - EV) / (CPI・SPI) = 7 + (10 - 5.9) / (0.84 * 0.91) = 12.4

つまり、先ほどの推算よりも約0.5人月分、さらにコスト増になるという計算だ。

この計算式は、Flemming & Koppelman: "Earned Value Project Management, 2nd Edition", PMI, pp.136-137, 2000.（邦訳「アーンド・バリューによるプロジェクトマネジメント」）に解説されてる。ただ、日本のPM関係の教科書参考書の類では、なぜかあまり書かれていない。日本語版Wikipediaにも、現時点ではのっていない。

それにしても、残っている仕事量（BAC - EV）を、なぜCPIとSPIの両方で割るのか？　明確な理論的説明がある訳ではない。ただ、コスト超過しているプロジェクトは、スケジュールも遅れているので、全体工期が延びる分だけ、さらに余計に費用がかかるようだ、という経験知を示している訳である。

以前の記事で、わたしは「進捗率は予算消化率では測れない」と書いた。実を言うと工事進行基準とは、「進捗率＝予算消化率」という定義になっている。ただ、そのかわり、「予算には、今後発生する合理的なコスト増を組み入れること」という形になっている。なので、コスト増が起きると、分母が増えて、進捗率がその分下がることになる。結果として、「残っている仕事量」が反映されるのである。

ソフトウェア開発の売上計上に工事進行基準が義務付けられるようになったのは、2009年からのことである（企業会計基準第15号「工事契約に関する会計基準」及び企業会計基準適用指針第18号「工事契約に関する会計基準の適用指針」）。その1〜2年前から、大手SIerの間で、「これからはもっと真面目に（定量的に）進捗管理をしなければならい」という議論がかわされていたのを、覚えている。

そして、さらに2021年4月以降は、ソフトウェア業界も、会計が「収益認識基準」に変更される。こちらは「もっともっと真面目に」役務項目別のコントロールが義務付けられる。これに各社は、準備対応できるのだろうか。

ちなみに上の説明で、「わずか10人月程度のプロジェクトにEVMSを適用するのは、大げさすぎる」という意味のことを書いた。しかし、そのような態度にも、一つ利点がある。社内で、大小様々なプロジェクトに関するデータが蓄積できることだ。

米国では国防総省が中心になって、EVMSの適用を進めてきた。また90年代以降、一定金額以上の公共事業にも、EVMSの適用が求められるようになった。彼らは、データを蓄積することの威力を、知っているのだ。上に述べた「工期の2割以上をすぎるとCPI値が安定する」といった知見も、そこから得られたものだ。

事実とデータに基づいて、マネジメントが予測と決断を下すこと。そうしなければ、強い軍隊や、勝てる組織などというものは、維持できないというのが、米国流の経営思想である。勇敢な兵士や鬼軍曹だけでは、戦えないのだ。正しいデータと分析が、重要だ。気合と根性だけでは、仕事はスケーラブルにならない。

EVMSという手法には限界もあって、万能ではない。しかし、その限界を知りつつ使ってデータを蓄積するのと、その手法を知らないために使いもせず、データも取らないのとでは、長い間には天と地ほどの差ができる。ITという仕事が、データから有用な情報を組み上げるためのものならば、わたし達自身の仕事についても、やはり数値化の努力をすべきだろう。

＜関連エントリ＞

　→「
」 (2020-02-08)

「プロジェクト＆プログラム・アナリシス研究部会」（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）

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