システムズ・エンジニアのための共通言語が存在する

わたしの働くプラント・エンジニアリングの業界には、通称「P&ID」と呼ばれる図面がある。正式にはPiping & Instrumentation Diagram。日本語に訳せば『配管計装図』だが、そう日本語で呼ぶ人はおらず、普通は「ピーアイ」と略す。いわゆる化学プラントの基本設計を表す図面であり、そこに構造も要素も制御もすべて書かれている。きちんと描かれたP&IDがあれば、どんな機器構成からなり、どんな働きをするのか、ほとんど全て見て取れてしまう。プラントがほぼ作れてしまうと言ってもいい。だからどこの会社でも機密扱いになっている。P&IDがどんなものか、サンプルをお見せできればいいのだが、そういう訳でわたしも勝手に開示できないので、せめてたとえば以下のサイトを見て雰囲気をご覧いただきたい。

 Diagrams for Understanding Chemical Processes http://www.informit.com/articles/article.aspx?p=1915161&seqNum=3
 Piping & Instrumentation Diagram, P&ID http://processflowsystems.com/piping-instrumentation-diagram-pid/

このP&IDという図面は、いわばプラントの分野における『回路図』のようなものだ。電気における電気回路図と同じで、世界中、ほぼ同じ記法で書かれている(多少の方言はあるが)。だから専門の者が見れば、他社のプラントであっても完全に理解できる。P&IDはプラント業界の共通言語だと言ってもいい。そして、それゆえ、化学や石油業界の顧客にかわって、プラント工場の設計と製造を請け負う『エンジニアリング会社』という商売が成り立つのだ。もしP&IDという図面が存在していなかったら、あるいは記法が各社バラバラだったら、誰も工場づくりをアウトソースできず、われわれもビジネスをやっていけない。共通言語があるから、はじめて業界が機能分化し、専門会社ができて技術を集中・発達させることができるのだ。

そしてたぶん、電気業界だって、事情は同じことだろう。電気回路図が国ごと、会社ごとにバラバラだったら、電子部品業界など成り立つまい。他国でメンテナンスできず、輸出もできない。電子立国日本、などと’90年代は呼ばれたが、輸出で経済を支えられたのは、回路図という共通言語がすでにあったからなのだ。

ちなみにエンジ業界でP&IDを作成する設計職種を、プロセスシステム・エンジニアと呼ぶ。長いのでプロセス・エンジニアと呼ぶことも多い。職種名からお分かりの通り、一種のシステムズ・エンジニアである。わたしもキャリアの最初は、この職種だった(が、へそ曲がりの性格のためか、だんだん横道にそれてしまったのだ^^;)。P&IDは化学プロセスのシステムとしての表現であり、主な設計成果物である。そして化学プラントはシステムである。それは文系・理系を問わず、この業界にいる全員の常識だ。

そういう世界に育ったせいか、他の分野に関わったとたん、システムという意識の薄さ、システム設計における共通言語の不在に驚くのである。わたしの目から見れば、自動車だって、月ロケットだって、水道インフラだって、計算機だって、工場だって、みんなシステムである。まあ発達した業種には、それなりに共通する図面類はあり、だから業界が成り立つのだろう。だが、少しでも業界を横断して、他の分野に学ぼうとしたとき、あるいは共通の知恵を育てようとしたとき、共通言語がなかったら、どうしたらいいのか。

え? ITの分野にはC++とかjavaとか世界共通の言語があるって? それは実装のための道具だ。ちょうど電子部品のようなものだ。わたしが問題にしているのは、「システム設計のレベルにおける言語・表現図」である。たとえばユーザ機能要求はどう表記されるのか。システムと要素間の関係はどう図式化されるのか。変更はどう記載されるのか。そういった面である。E-R図とかDFDがあることぐらいは、わたしも一応知っている。そして実際には記法の流儀や方言が多いことも。嗚呼、先輩の「背中を見て」育つ世界。

では、システム設計=『システムズ・エンジニアリング』という広大な共通領域に対して、欧米ではどう取り組んでいるのか。その一つの動きが、前回紹介したINCOSE(国際システム工学協議会)であり、MIT(マサチューセッツ工科大学)やPMIとの連携である。もう一つ、同じMITの取り組みを見てみよう。MITがNASA(米航空宇宙局)・ボーイング社と提携して提供をはじめた、技術者育成コースがある。タイトルを、
"Architecture and Systems Engineering: Models and Methods to Manage Complex Systems"
という。訳せば、「システムのアーキテクチャとエンジニアリング:複雑なシステムをマネージするためのモデルと手法」であろうか。サイト(https://sysengonline.mit.edu)に2分程度の短い広報ビデオがある。これを眺めると、英語が不得意でも対象者や雰囲気は少し分かる。

この育成コースでは、"Model-Based Systems Engineering”を柱とした教育を行うことになっている。対象物のモデルを元に、予測・検証・評価を行って設計する手法だ。ここで対象とするのは人工衛星や電気自動車といった、複雑なシステムである。コース概要を読むと、そこで用いる、「回路図」に相当する共通言語として、
SysML (System Modeling Language)
OPM (Object Process Methodology)
の二つを学ぶことになっている。

わたしはどちらもちゃんと学んだことがないので、聞きかじりで書くことになるが、SysMLの方は言語といっても、図表を中心としたモデリング技法だ。SysMLのシステムモデル表現には、大別して、構造・要求・振る舞い・パラメトリック制約の4種があり、さらに以下のようなダイアグラムを使う。

構造:ブロック定義図、パラメトリック図、内部ブロック図、パッケージ図
要求:要求図
振る舞い:ユースケース図、シーケンス図、アクティビティ図、状態機械図
パラメトリック制約:(これは数式表現、運動方程式、パラメータによる性能評価などになる)

SysMLに関しては、この分野の第一人者である慶応大学SDM学科の西村教授による入門的解説「システムズモデリング言語SysML の活用」(http://www.mstc.or.jp/iaf/event/2014w/05nishimura.pdf)があるので、興味がある方は読まれるといい。上にあげたリストも、ここからの引用である。

もう一つのOPM (Object Process Methodology)は、ある意味、もっと面白い。この手法には図表限もあるのだが、同時に、いわゆる言語として文字列でも表現できるようになっている。OPMでは対象を「Thing」とよぶのだが、これはObjectとProcessに区分される。つまり日本語で言う「モノ」と「コト」である。そして、それら要素間の関係を様々な形で表記していく。なおOPMのモデルはSysML形式にも展開可能である。

ところで、SysMLは10年ほど前に国内に紹介されたものの、どうやらあまり普及しなかったようだ。OPMにいたっては、日本には紹介もされなかったらしい。日本語版Wikipediaはエントリーさえ無い。OPMはすでに国際標準として認定されて、ISO 19450:2015になっているのに! まあこれが、「システム」設計という仕事に対する、わたし達の社会の知的態度なのかな、とも思う。

もっとも、こういう言い方には疑問を呈する方もおられよう。SysMLがあれば、良いシステムが設計できるというのか? ましてSysMLが、「統一モデリング言語(UML)のサブセットにUMLのプロファイル機構を使って拡張したものと定義できる」(日本語版Wikipediaより引用)ことを知れば、IT業界の方にはなおさらかもしれない。UMLか! あれってほんとに便利なの?

当たり前だが、
・SysMLを使えば良いシステムの設計ができる
・SysMLを使わなければ、良いシステム設計はできない
のいずれの命題も、別に正しくない。じゃあ、なんでSysMLだのOPMだのにこだわるのか? 結果として、いいシステムが設計できれば、使い慣れたどんな道具でやったって、いいじゃないか。

答えは、「仕事をシステム化するために必要だから」である。システム設計と構築という仕事自体を、システム化するために、標準的な、共通化された道具立てと手法が必要なのだ。誰がやっても、その個人のスキルや資質に過度に依存せずに、ある程度の設計品質が保てること。そして、巨大なシステムをつくる場合に、仕事の仕組み自体をスケールアップ(IT業界風に言えばスケールアウト)できること。そのために、必要なのだ。

ほんの2〜3人で、数ヶ月でできてしまう仕事は、設計を担当する個人の力量に、結果が大きく依存する。だが200〜300人がかりで数年かかるような仕事は、そういう事ではこまる。様々なサブシステムが、それなりに均質で予見可能な形でできあがってこないと、最後に統合する際にバラバラになってしまう。だから、大きなスケールの仕事ができるように、仕事のプロセスをシステム化すべきなのだ。これが、少なくとも欧米人に共通な発想である。これに気づけない人は、じつはシステムズ・アプローチということをよく分かっていない、と見た方が良い。

設計に使う道具について、専用化を志向するか汎用化・標準化を志向するかは、つねに議論になる問題だ。SysMLとかUMLとかは、汎用化志向だ。だが汎用を目指すほど、個別問題には余計なオーバーヘッドが生じて、重たくなる。だったら個別分野に向いた、使いなれたツールを使う方が効率が高い。そう考えるのはよく分かる。ただ、その傾向を徹底すれば、どうなるか。部分最適を追求した結果、最後は「オレ流」になるのは目に見えている。俺流でずっと仕事を回していけるなら、それでいい。だが組織や業界がそういう流儀から脱皮したいなら、何らかの共通言語が必要なのだ。

実は、最初にあげたP&IDや回路図といった図面が早くから生まれたのは、理由がある。化学プラントや、電気回路などのシステムでは、要素間をつなぐ線が、物理的に存在して目に見えるのだ。プラントでは配管が、回路では配線が、それにあたる。だから、こうした線を図に表記するのが、自然に思えた。しかし月ロケットや電気自動車では、そうではない。電気配線はあるが、それはほんの一部に過ぎない。主要な部分(機能モジュール)間の関係、インタフェースは、目に見えない。だからこうした分野では、システム図の発明が遅れたのだ。でも今や、それは生まれた。そして育ちつつある。少なくともわたし達の国の外では。

目に見える物理的なモノだけでなく、目に見えぬ関係やプロセスを、システムの要素として認識すること。いや、むしろモノとプロセスの主従を逆転して、作業を中心にモノを見ること。そして仕事の仕組み全体をシステムとして理解すること。こういう能力が、システムズ・アプローチの勘所なのである。先に挙げたMITの育成コースは、edXを使ったオンライン教育中心で、4ヶ月間かかる。公式な資格を発行してくれるが、$2,200かかる(けっこう高い)。それで、何が得られるのか? システムズ・エンジニアリングにおける共通言語と共通スキルである。そういう技術者が、海の向こうでは求められているのだ。だからせめてわたし達も、システムズ・アプローチを学べる場を手作りで生み出そうと、ささやかながら我が研究部会で試みているのである。


<関連エントリ>
 →「システムズ・エンジニアリングとは何か」 http://brevis.exblog.jp/25682507/ (2017-04-09)
 →「工程表と部品表 - 個別受注生産における主従の逆転」 http://brevis.exblog.jp/25660188/ (2017-03-22)

# by Tomoichi_Sato | 2017-04-19 12:16 | ビジネス | Comments(0)

書評:「ケセン語訳 新約聖書 【マタイによる福音書】」 山浦玄嗣・訳

ケセン語訳新約聖書 〔1〕マタイによる福音書 (Amazon)

これは、岩手県大船渡市に居を構える医師・山浦玄嗣氏による、ケセン語訳新約聖書の第1巻である。「ケセン語」とは、山浦氏が住む東北・気仙地方の言葉を指す。いわゆる東北弁であり、普通なら気仙方言、あるいは“ズーズー弁”などとしばしば蔑まれる自分たちの言葉を、氏はあえて標準日本語(明治以降に成立した)と対峙する一つの言語として宣言する。それだけではない。彼はケセン語の表記のための独特の変形仮名を創案し、1996年にケセン語文法書を上梓、さらに2000年には「ケセン語大辞典」まで編んだ。

それもこれも、生涯の夢である「故郷の言葉ケセン語で聖書を作る」ための準備であった。そして2002年に、まずこの「マタイ福音書」が出版される。もっとも、これは日本語訳のタイトルであり、ケセン語の正式タイトルは「マッテァがたより」である。福音書という語は、もとのギリシャ語では、良い知らせという意味であり、だからケセン語の語彙にこだわって、「たより」と訳した。マタイと普通呼ばれる著者の名前も、ケセン語の音韻規則に従って変形し、マッテァとなる(その後の「が」は所有格を示す)。

新約聖書の4福音書は、マタイ・マルコ・ルカ・ヨハネの順に並べられているが、執筆年代は違う。短いマルコが一番古く、ついでマタイ、長いルカときて、独特なヨハネが最後である。ちなみにわたしは山浦氏のケセン語訳シリーズを、「マルコ」「ルカ」「ヨハネ」と何年間かにわたって読み継いできて、とうとう最後に「マタイ」を読み終えた。氏はさらに震災の後の2011年秋に、日本語訳新約聖書四福音書「ガリラヤのイェシュー」を上梓している。これも非常にユニークな翻訳で、読み終えたらまた紹介したい。

本書のシリーズは、いずれも書籍とオーディオCDがセットの箱入りになっている。CDの中には、山浦氏が自分で朗読した音声が収録されているのだが、これが実に良い。自分で劇団を立ち上げたというだけあって、声もいいし、情感がこもっている。ケセン語訳は漢字かな交じりではあるが、読むには慣れが必要だ。だから、本を眺めながら、朗読を聞くというスタイルが一番いいだろう。そして、それでこそ、土地に密着した言葉の力が直接、心に届くのである。心に訴えかけることこそ、こうした宗教書の一番大切な役割なのだから。

たとえば、有名なイエスの『山上の垂訓』冒頭は、ケセン語訳では、こうなる(ただしケセン仮名はネットで表示できないので普通の仮名で代用する):

「頼りなぐ、望みなぐ、心細い人ァ幸せだ。
 神様の懐に抱がさんのァその人達(ひだつ)だ。
 泣く人ァ幸せだ。
 その人達ァ慰めらィる。
 意気地(ずぐ)なしの甲斐性(けァしょ)なしァ幸せだ。
 その人達ァ神様の遺産(あとすぎ)ィ受げる。
 施しにあだづぎそごねで、腹ァ減って、咽ァ渇ァでる人ァ幸せだ。
 満腹(くっち)ぐなるまで食ァせらィる。
 情げ深(ぶげ)ァ人ァ幸せだ。
 その人達ァ情げ掛げらィる。
 心根(こごろね)の美(うづぐ)すい人ァ幸せだ。
 その人達ァ神様ァどごォ見申す。
 お取り仕切りの喜びに誘う人ァ幸せだ。
 その人達ァ神様の子だって語らィる。
 施すィ呉(け)ろ、呉ろって攻めらィる人ァ幸せだ。
 神様の懐に抱がさんのァその人達だ。」(p.47-49)

もう25年以上も前のある時、山浦氏が教会でこの山上の垂訓のケセン語版を朗読披露した際、聞いていたサクノさんという老婦人がかけよって、「いがったよ! おら、こうして長年教会さ通(あり)ってね、イエスさまのことばもさまざま聞き申してたどもね、今日ぐれァイエスさまの気持ちァわかったことァなかったよ!」と、目に涙を浮かべてよろこんでくれた、という。これが、ケセン語訳新約聖書を作りたい、という気持ちの原点になったそうだ。

ところで上の1行目は普通、「心の貧しい人は幸いだ。」と日本語に訳される。しかし、これではケセン語の話者にとって意味が分からない。「心の貧しい」は、想像力が乏しく気高い心が欠如している、思いやりのない人を指すからだ。山浦氏の巻末解説によると(p.238)、もとのギリシャ語は「プネウマにおいてプトーッソーしている人々」である。プネウマは息・魂で、プトーッソーは貧弱な・乏しいを意味する。そこであえて、『頼りなぐ、望みなぐ、心細い』と内容を訳すことにした、という。

これでは意訳しすぎだ、超訳だ、という批判は(方言の使用云々以前に)あるだろう。そんなことは山浦氏は承知している。そして意訳した箇所は必ず、巻末解説で理由と解釈を説明している。これが実に面白いのだ。彼独自の解釈、いわば『山浦神学』の面目躍如である。

そもそも、翻訳という行為は解釈そのものである。現代は機械翻訳が発達してきたため、かえってこの本質を見失っている人が多い。単に誠実に逐語訳的に単語を置き換えれば、それが中立客観的な翻訳になるはずだ、と信じている。だが、原語に対応する訳語が複数ある時、どの訳語を選ぶか決める時点で、すでに翻訳者の価値観や美学が入るのだ。

その一つの例が「」である。キリスト教は愛の宗教だ、とか、神は愛なり、といった言い方をするクリスチャンが多い。だが山浦氏が指摘しているように、もともと日本語の『愛』という字は、慈愛という言葉で分かるように、上位者から下位者に抱く感情を指す。ペットを愛玩し、蒐集物を愛蔵し、家臣を寵愛し、顧客が店を愛顧する。ギリシャ語の『アガペー』を明治時代の先賢が、愛という言葉で訳してしまったが故に、「人間が神を愛する」という倒立が生じてしまった。

ところで昔のキリシタンは「お大切にする」という言い方をしたという。これはアガペーの本質を見事に表した言葉である。「汝の敵をも愛せ」より、「憎い敵であっても、その人間を大切にしろ」という方がずっと伝わってくるし、また立派なことにも思える。そこでケセン語訳では「大事(でァず)にする」となっている。

似たような、しかしもっと違和感のあるキリスト教特有の言葉に、「主(しゅ)」がある。「主なる神」といった風に使う。神は人間の主(あるじ)だ、というのはユダヤ教の旧約時代からの概念・感覚である。だが現代日本で「主」といって意味の分かる人が、どれだけいるだろうか。まして、イエスが布教に行った先の村で、はじめて出会った婦人が、(まだクリスチャンでもないのに)イエスに向かって「主よ」と呼びかけるのは明らかに奇妙ではないか。

この「主」は、スペイン語ならセニョール、ドイツ語ならヘールで、どちらも普通の男性への呼びかけだ。だからケセン語訳では「旦那(だな)様ァ」という呼びかけになる。この方がずっと、わたし達の腑に落ちよう。

むろん、「こんな翻訳は冒涜行為だ」との批判をかなり受けただろうことは、容易に想像できる。その底流には、東北方言に対するいわれなき偏見も、しばしば沈潜していたに違いない。しかし誰も両親を選べないように、母語も選べないのだ。である以上、自分の言葉に誇りを持ちたい、心に響く言葉を使いたい、という感情も当然ではないか。それに、そもそもイエスだってガリラヤ出身で、なまっていたのだ。一番弟子のペトロが、イエスの審問の行われている大祭司邸に忍び込んだとき、「お前もあの男の仲間ではないか、その訛りで分かる」と言われたのが、何よりの証拠である。

本書の冒頭に、カトリック仙台司教区の溝部教区長が跋辞を寄せており、その中で、キリスト教の『土着化』のことが論じられている。これは初代教会の時代からの問題で、1998年のアジアの司教会議でも、“土着化されないといけない”という抽象的結論は出たものの、具体的にそれが何を指すのか誰にも分からず、試行錯誤が続いている、という。だが山浦氏の労作はそれを具体化しようと実践している。だから「日本司教協議会は本書を試行錯誤の過程にあるものと理解して、出版を励ましております」(p.3)と書かれている。

そういうわけで、わたしもこのケセン語訳のシリーズを非常に面白く読み、また大いに考えさせられた。キリスト教はヨーロッパで発達してから近代日本に再輸入されたため、どうもひどくバタ臭いところがある。それは一部の人には魅力になっただろうが、多くの人はむしろ敬遠する理由になったのではないか。そういった違和感を超えるべくなされた努力には、敬服である。キリスト教という宗教に多少興味のある人だけでなく、言語とは何か、翻訳とはどういう行為か、を考えたい全ての人にお勧めできる良書である。そして、このような困難な書籍の印刷発刊を行い、じつに美しい装丁で提供してくれた版元のイー・ピックス社にも敬意を捧げたい。


(追記)
 なお本書セット(書籍とCDの箱入り)自体はすでに絶版状態だが、書籍はオンデマンド出版で、また音声はダウンロードで、それぞれ版元のイー・ピックス社から入手可能である。




# by Tomoichi_Sato | 2017-04-15 10:21 | 書評 | Comments(0)

システムズ・エンジニアリングとは何か

日本にはあまり知られていないが、欧米では確立され重視されている技術の分野がある。それは「システムズ・エンジニアリング」=システム工学である。

・・と書けば、“何を馬鹿な”と思われる方が大半であろう。日本にはシステム・エンジニア(SE)と呼ばれる職種の技術者が、少なく見積もっても十万人単位で存在する。それに、大学でもそれなりに教えているではないか。「システム工学」と名のつく学科だって、数十は存在する。それなのに、「あまり知られていない」などとは何ごとか!

そう憤慨される読者諸賢に、それでは、一つご質問したい。貴方が学校で学ばれた「システム工学」の、代表的な教科書をあげていただきたい。これ一つ読めば、システム工学の基礎が大体分かる、読んでいない奴はモグリだ、というような定番の教科書である。システムとは何を指すのか、システムはどのように設計すべきか、設計手法は何があるのか、システムの分析や評価はどう行うのか、システム工学研究の最新の課題は何なのか、すっぱり分かる教科書である。経済学におけるサムエルソンの本みたいなやつだ。1冊ではなくシリーズでもいい。確立した工学分野なら、そういう教科書が必ずあるはずではないか。

え? 思い当たらない? そんなら、最近流行の「知識体系」を書いた標準書かハンドブックでもかまわぬ。プロジェクト・マネジメント分野におけるPMBOK Guide (R)みたいなやつだ。一流のプロを目指す人間なら、誰でも座右において、でも実際には滅多にめくって見たりはしないアレである。え? それも存在しないって。だとすると、世の中のシステム・エンジニアはどうやって勉強してきたのか。まさか習うより慣れろ、先輩の背中を見て育て、だろうか。また学術研究は、どう進められているか。今、念のためにちらりと調べてみたが、「日本システム工学会」のような組織も無さそうだが・・?

そうなのだ。日本には、「システム工学」一般を扱う学会も、それを教える大学も、存在しない。たとえば「日本の大学」というサイトで調べると(http://www.gakkou.net/daigaku/src/?srcmode=gkm&gkm=04011)、76件の学科が出てくる。だが、機械システム工学、情報システム工学、制御システム学、化学システム工学など、何か特定の修飾がつく学科ばかりだ(かつては神戸大学と静岡大学に「システム工学科」が存在していたが、どちらも今はもう無い)。学会で言えば「システム制御情報学会」https://www.iscie.or.jp が存在する(わたしも以前、学会誌に一度寄稿したことがある)が、これも元は自動制御論の学会である。さて、世の中のSEの皆さんで、ラプラス変換や伝達関数を毎日仕事で使いこなしている方はどれくらいいるだろうか?

率直に言って、わたし達の社会には、「システム」という概念に対して、奇妙な歪み、ないし偏向がある。システムとは「目的を成し遂げるために、相互に作用する要素(element)を組み合わせたものであり、これにはハードウェア、ソフトウェア、ファームウェア、人、情報、技術、設備、サービスおよび他の支援要素が含まれる」と定義される。システムというのは非常に一般的な概念だ。そこには機械的なシステム、たとえば自動車だとかカメラだとか人工衛星だとかも含まれるし、工場やプラントみたいなものもシステムだし、人間系を含んだ仕組み、たとえば企業の経営組織だってシステムの一種である。少なくとも、学術の世界ではそう認識されていて、(学会は専門分化する方向が強いので)個別に「○○システム学科」が生まれていく。

ところが、一歩大学の外に出ると、なぜだか突然、「システムとはコンピュータのこと」という『常識』が世間を覆っていることに気づく。そして、SEと呼ばれる人たちは、もっぱら計算機のハードウェアだとかソフトウェアだとかを設計・実装するITエンジニアばかりなのである。『システム』という言葉自体、外来語で、日本語に該当するもののない、わかりにくい抽象概念だった。だから<システム=計算機>という目に見えるものにマッピングして理解されることが起きたのかもしれない。

しかし、このような偏向ないし偏在は、いろいろなところで問題や見えない非効率を生み出している。たとえば少なからぬメーカーにおける製品は、複数要素から成り立っており、システムである可能性が高い。だが、そこにコンピュータ要素がないと、『システム』として認知されない。すると、システム工学が得ている知見や常識が活かされず、その製品設計プロセスにも、システム工学で常識となっているモデル(後述する)が適用されないケースが多いと思われる。あるいは、生産管理などの仕組みも、一種のシステムである(現にトヨタは「トヨタ生産システム」と呼んでいる)。だが、そこにもシステム工学で常識となっている事柄が十分活かされず、ただ個人の頑張りや浪花節的調整や「気合い」やらで組み上げられたりする。欧米ライバル会社では、そこが理知的に設計されスケーラブルになっている可能性が高いのに、である。

ところで、二つ上の段落に書いた「目的を成し遂げるために・・要素が含まれる」という定義は、じつはINCOSE(The International Council on Systems Engineering http://www.incose.org )という団体による定義を引用したものだ。INCOSEは文字通り、システム工学に関する国際的団体である。事務局は現在、米国サンディエゴにあるが、理事のメンバーを見ればわかるとおり、欧米にまたがっている。大学人あり、航空宇宙業界ありソフトウェア業界ありエンジニアリング業界ありで、かなり広汎だ。そして(例によって)日本人は一人もいない。

このINCOSEという団体は、"INCOSE Systems Engineering Handbook: A Guide for System Life Cycle Processes and Activities"というハンドブックを出版している。現在第4版で、Amazonなどからも手に入る。これを眺めると、現在のシステム工学というものが、何を問題にし、どういう方法論で挑もうとしているのかが少し見えてくる。

たとえば、同書の中には、システム開発の「V字モデル」の図が出てくる。こういう図だ。


e0058447_17303679.jpg


これに似た図は、ITエンジニアの人たちなら、見たことが多いのではないだろうか。日本でも、大手ITメーカーの社内標準や開発プロセス定義に取り入れられている。INCOSEのハンドブックの説明によると、このV字モデルの概念は1990年頃に萌芽が生まれたが、このような形で提案されたのは、Forsberg, Mooz & Cottermanの"Visualizing Project Management”(3rd edition, John Wiley and Sons, 2005)がオリジナルであるという。

念のために説明しておくと、システムは通常、その中にサブシステムを持っており、サブシステムはさらに下位の要素などから階層的に構成される。上位システムは何らかの要件を持っており、エンジニアはその機能を満たすために内部構造を考える。つまり、下位のサブシステムが満たすべき要件と、その要素間の関係を規定する訳だ。設計とはそもそも、満たすべき要件と制約条件の中で、利用可能な材料から、機能・構造・制御機構を持つ案を考え、その中で価値が高いものを選ぶ行為である。そして下位のサブシステムについては、その要件を満たすべく、さらに下位の要素の組み合わせで設計する。

こうして、設計段階は、上から下におりていく。ところが、それを実現する(製造・実装)段階では、まず要素を作り、その要素レベルでの機能検証を行った上で、上位のサブシステムを構成し、サブシステム・レベルでの検証をすませてから、全体システムへと進む。そこで、各段階の設計において、あらかじめ検証のための方法を計画しておかなければならない。

これは、今日のITエンジニアにはほとんど常識であろう。事実、ISO12207 「ソフトウェアライフサイクルモデル」などにも、この概念は取り入れられていて、テストは単体→結合→総合、という風に下から上に上がってくるのである。これを逆にはできないし、すべきでもない。ただ、こうした概念がIT分野で常識化してきたのは、この10年くらいのことかもしれない。そして、IT以外の分野では、まだあまり常識ではない。たとえば、IT系の会社で組織体制を決めるとき(これは立派なシステム設計行為だ)、上から順に機能定義を展開し、下から順にそれを検証しているだろうか? そうしていないとしたら、それは何故なのか?

それは、「システム」という概念がコンピュータ回りに偏向しているからだろう。上に述べたINCOSEのシステム定義が、要素としてちゃんと「人間」を含んでいる点に注意してほしい。人は、システムの重要な要素なのだ。まあ、わたしは実務家であって、必ずしも抽象的一般理論の信奉者ではない。だが、必要に応じて、抽象レベルを上げて考える能力は、技術リーダーに必須のスキルだと信じている。そして、それをシステムという観点から行うのが、『システムズ・アプローチ』なのである。

ちなみに、INCOSEは数年前に、プロジェクト・マネジメントの本家団体であるPMIと、戦略的提携関係を結んだ。さらに、MIT(マサチューセッツ工科大学)とも協力して、プログラム・マネジメントについて新たに共同開発を行っている。これは、わたしにとって驚きのニュースであった(もっとも、こういうニュースがこの国ではちっとも驚きを持って広まらないのだが・・)。そして、共同で新しく本を編纂するというので、日本プロジェクトマネジメント協会PMAJの光藤理事長が寄稿された。出版は少し遅れているようだが、近々刊行されると思う。

ともあれ、わたしの知る限り、今日の日本において、IT以外の分野で「システム・エンジニア」という職種が認知されているのは、JAXAに代表される航空宇宙業界、一部の物流設備業界、そしてプラント業界くらいだ(化学プラントの世界では「プロセスシステム」という概念が確立していて、これを専門に設計する職種がいる。ただしプロセス・エンジニアと呼ぶことが多い)。でも、もっと多くの分野で、システム工学の考え方を知り、また独自に技法を案出できるといいと思う。

こうしたシステム工学の考え方に興味を持たれた方に、ちょっとだけ耳寄りな情報(笑)をお教えしよう。上記のINOCSEの英語版ハンドブックを読むのは、なかなか大変だ。そういう方は、JAXA(宇宙航空研究開発機構)が、

JAXA (2007)「システムズエンジニアリングの基本的な考え方」

という解説記事をネットで公開されている。こちらをまず、勉強されることをおすすめしたい。わたし自身、INCOSEのハンドブックに書かれている方法論だけでは、工学としてまだ物足りない部分があるとも考えている。とくに、System ArchitectureやSynthesis、つまりシステム合成のための設計指針が、もっとほしいと感じる。だが、そのギャップを埋めるには、大勢の叡智を集める必要があろう。そして、より多くの人が、こういうシステム工学の存在を知ってほしいと思うのである。


# by Tomoichi_Sato | 2017-04-09 17:36 | ビジネス | Comments(0)

工程表と部品表 - 個別受注生産における主従の逆転


若い頃、『システム・モデラー』という職種を目指したい、と言ったら、上司から「そんな職種はない」と言われたという話は、以前書いた。(「システムとはいったい何を指すのか」 http://brevis.exblog.jp/20878001/ 2013-08-01)。それで、その後わたしは「プロジェクト・アナリスト」を名乗るようになり、今では名刺に、勤務先の「チーフ戦略アナリスト」である、と書いている。

だが、今でもわたしはモデリングの仕事が好きだ。データ・モデリングとは、世界の概念的スケッチである。言葉と簡単な図を使って、世界のあり方を切り取って分析する仕事は、何より楽しい、と思う。モデリングという仕事は、技術とアートの中間地点にある、とも言われる。科学的論理性だけでは、良いモデルを作るには足りない。モデルとは近似であり、見切りだからだ。モデルは必ずしも事物の厳密・正確な再現ではない。英語で、"Models are all wrong. But, they are useful.”という言葉をきいたことがあるが、金言だと思う。モデルはすべて、正しくない。だが、有用なのだ。

さて、前回(http://brevis.exblog.jp/25634844/)は『部品表』と『工程表』という概念について、簡単なイントロ的解説を書いた。ところで、前回の記述は、じつは繰返し性の高い生産形態での話だった。つまり、見込生産(MTS)とか繰返し受注生産(MTO)の場合なのだ。

(なお、若干話がずれるが、生産形態の分類を表す用語については、日本語の慣用句よりも英語の用語の方が本質を突いているので好きである。見込生産は英語でMake to Stock = MTSとなる。「在庫してストックするために作る」形態なのである。繰返し受注生産はMake to Order = MTOで、これは「注文に応じて作る」やり方だ。このように、何に対して製造するか・製造の結果が何になるか、が英語での表現では、より明快だ)

さて今回は、ETOの場合について書いてみたい。ETOとは、Engineer to Orderの略だ。Engineerという単語は、ここでは「技術者」という名詞ではなく、「設計すること」という動詞で使っている(ちょうど”Engineering”という動名詞の言葉があるように)。ETOは日本語では、「個別受注生産」あるいは「一品受注生産」「受注設計生産」などとも呼ぶ。

ETOという生産形態の本質は、製造の前に設計作業が必須となることだ。このような生産形態は、意外と多い。たとえば造船。航空機。大型の産業機械(たとえば圧縮機や工作機械など)。あるいは金型。いろいろある。わたし達プラント・エンジニアリング会社が購入する資機材の大部分も、ETOの形態で生産される。そしてIT業界でSIerが行う受託型のシステム開発も、受注後に設計が必要になる点では、ETOの一種だと見ることもできる。

わたしの見るところ、日本の製造業には、このETO形態をとっている企業がかなり多い。好むと好まざるとに関わらず、いや、それが企業自身で自覚して選んだ結果なのかどうかも分からないが、とにかく、広く見受けられる。統計的根拠までは示せないが、英米や中国などより、ずっと比率が高いのではないかと思う。

その理由は、日本における顧客(買い手)側のあり方に起因している、というのがわたしの推測だ。日本の顧客(B2Bで、顧客が企業の場合)は、なぜかメーカー標準品を買うことを潔しとせず、必ず自分好みの個別仕様を付け加えたがる傾向がある。たとえば生産財を買う場合、それが自社の生産ラインにぴったり最適化され、面倒が少ないようにしたい。そのため、いろいろ個別で特殊な注文がつく訳だ。そういう風に細かな注文をつけること自体が、エンジニアとしてのプライド、ないし存在意義とさえ思っているらしい(実際にはその分、標準品よりコストが上がっている可能性が高いのだが、会計部門への説明能力の高いこともエンジニアの能力の一部である^^;)。顧客から個別注文を受け取った企業の技術者は、自分のサプライヤーに振り向いて、同じように個別仕様を要求する。かくして、日本ではETOに対応しない企業は生き残れなくなっていく。

ところで、いろいろな生産形態のうちで、生産管理の一番難しいものが、このETOなのである。だから日本の製造業は、全体として、わざわざ一番難しい生産形態を、みんなして選んで、お互いに生産性の低さに苦しんでいるとも言える。

ETOは、なぜ難しいのか? ETOの特徴は、受注時点で部品表(BOM)が固まっていないことにある。まあ受注時点でも、たいていの場合、大きな骨格くらいは見えている。そうでなければ、そもそも金額さえ見積れないからだ。

しかし、細部は設計してみないと決まらない。当然、設計後に、部材を注文することになる。注文してはじめて、部材は工場に入ってくる。部材がなければ、製造はできない。当たり前だろうって? その通りだ。だが、製造のスケジュールという観点から見ると、ETOとそれ以外では、大きな違いがあるのだ。

前回の図を思い出してほしい。複数の子部品が組み合わさって、一つの製品ないし親部品ができあがる。それを作るために、工順がある。いいかえると、部品の親子関係に対応して、一つの工順がある(厳密には『代替工順』というものも存在しうるが、今その話には深入りしない)。工順は複数の作業からなっていて、それぞれの作業に、製造資源(人や機械)が結びつく。こういう構造だ。

ここで、ちょっと図を見てほしい。ここに掲げたのは、渡辺幸三氏が「CONCEPTWARE/生産管理」の名前で公開している、生産管理システムのデータモデル図の一部だ(http://dbc.in.coocan.jp)。渡辺氏は、今日のIT業界のレベルアップと生産性向上をめざして、あえてこうした本格的で実線的な業務系システムのデータモデルを公開しておられる。
e0058447_22074045.jpg
E-R図を見慣れた方ならば、これを見るだけでわたしの言いたいことはお分かりいただけると思うが、念のために説明しておこう。なお渡辺氏の用語はわたしのとは少し違っているため、対応関係を示しておく。左が渡辺氏のモデル上の用語で、右がわたしの用語である。

(1) 工程→工順、 (2) 作業場→作業区(ワークセンター)、 (3) 製造品工程明細→作業、 (4) 製造品材料明細→部品表、 (5) 品目→マテリアル(品目)

この図を見ると、(5)「品目」レコードに対して、複数の(4)「製造品材料明細」レコードがぶら下がっている(渡辺氏の図法では、「∈」は1:Nの関係を示す)。これは、一つの親部品が、複数の子部品から組立・加工されて作られる「親子関係」を示している。そして、(5)「品目」レコードに対し、(3)製造工程明細が、やはり複数ぶらさがっている。つまりここでは、品目が主であり、工順・作業が従であることが表されているのだ。(細部に興味がある方はダウンロードして、全体をご覧になることをおすすめする。非常に勉強になると思う)

そして製造リードタイム(渡辺氏の図ではLead Timeの頭文字をとってLTと略されている)は、個別の作業に結びついており、作業を積み上げて、工順の、そして全体の生産スケジュールができあがるのだ。

言いかえるなら、設計が完了して、すべてのマテリアルと部品表が決まらない限り、製造コストやスケジュールが確定しない、ということになる。コスト(原価)については、もはや受注時点ですでに販売価格が決まっているのだから、今さら泣いても笑ってもどうにもならない。だがスケジュールは問題だ。工場では複数の品目や注文が流れており、スケジュールの相互調整によっては、他の品目の納期に影響してしまう。

MTS(見込生産)やETO(繰返し受注生産)ならば、事前にBOMが確定しているから、「標準納期」とか「標準リードタイム」といったものを設定することができる。だがETOは、受注時点で全体のスケジュールが見えないのだ。ということは、受注時点で、本当に納期を確約できるかどうかも、分からない訳だ。おまけに、現場の人や機械の事前手配も、難しいと言うことになってしまう。

それがどうした。ものづくり現場は、部品と図面がなければ動けないのだ。だったら設計が全部終わった時点で、製造のスケジュール計画を立てればいいではないか、と思う人もいるかもしれない。だが、そうはいかないのだ。競争環境下では、そんなにのんびりした納期を顧客は与えてくれない。だから、部品表が確定した部分から、順次作り始めなければ、ふつう間に合わなくなるのだ。かくして、設計作業と、部品調達と、製造作業が、並行して進むことになる。本来は順番に進むはずの仕事が、入れ子になったり逆転したりして進むのだ。設計部品表(E-BOM)と製造部品表(M-BOM)が別々に管理されている企業の場合、話はさらに混乱してくる。

米国生まれの生産管理手法であるMRPが、日本でなかなか受け入れられ普及しなかった理由の一つが、ここにある。MRPは、大量繰返し生産マインドの強い米国で、'60年代に生まれた手法である。MRPでは、計画時点に、製品のBOMデータが存在していることを前提している。だが個別仕様が好きで短納期を要求したがる顧客だらけのわが国では、なかなか使い物にならない。

では、どうしたらいいのか?

ここで実は、発想の転換が必要となる。それは、「品目」→「作業」という主従関係の逆転である。

「作業」と、その集合である「工順」を、視点の中心におく。そして工順のインプットとアウトプットとして、子部品・親部品をとらえる。前回の図を、もう一度見直してみてほしい。

今、ここで問題としたいのは、製造スケジュールである。つまり個別作業にかかる正味時間、工順に与えるべきリードタイムだ。そして、それは、同じような親部品を製造する作業では、子部品の細部が多少異なっても、ほぼ同じだと見ることができる。え? 六角の部品の加工と、円形の部品の加工では作業が違うだろうって? たしかに厳密には違う。だが、生産スケジュールはモデルであり、一種の近似であることを思いだしてほしい。何秒単位の厳密な数字を議論しても仕方ないし、そんな精度は必要ないのだ。現場が必要とするのは、現場が混乱しないですむようなざっくりした精度の、しかしある程度は信頼しうる予測なのだ。

個別作業の所要時間見積のために、ここで登場するのが「パラメトリック見積法」である。これは、作業対象が持つ、なんらかの代表的なパラメーターを用いて、作業時間(つまりコストを)推計する方法だ。そして、この仕事のために、BOQ = Bill of Quantityという概念が、BOMのかわりに登場する。Quantityはパラメーターの数字である。グラムとか、mmとか、リットルとか、何の単位でもよい。それが作業の量(Quantity)を適切に示してくれたら、それで良いのだ。あとは割り当てる製造資源と、その生産性指標とから、作業時間を推算することができる。製造コストも、推算できる。

詳細な設計作業が十分に完了していなくても、基本設計段階(ないし受注前の見積設計段階)で、製品を構成するサブ・モジュールや共通部品等のBOQを洗い出し、リスト化しておく。そうすれば、これを元に、製造スケジュールをあらかじめ立てられる。これが、プロジェクト的なETO=受注設計生産のやり方なのである。詳細のBOMは、設計のあとでできてくれば良い。

もともとBOQという用語・概念は、100年ほど前に英国の建設業界で生まれた概念だ。そして、エンジニアリング業界に流れ込んできた。わたし達の業界では、このBOQ(しばしばBQとも略す)が、プロジェクト・スケジューリングの中心的なデータになるのである。わたし達にとって、作業(プロジェクト用語ではActivity)が主であって、そのインプット・アウトプットとなる品目(マテリアル)は従である。作業が先にあり、品目は段階的詳細化の結果として、後から決まってくる。このような世界観で、エンジ会社はプロジェクト・マネジメントを行っている。

そしてエンジニアリング・プロジェクトは、まさに巨大な「受注設計生産」そのものなのである。基本設計の外部仕様を元に、詳細設計を起こし、資機材を世界中のサプライヤーから調達し、プラントの現場に運んで、据付組立作業(「建設」)を行う。我々もまた、組立加工産業なのだ。

そしてもう一度最初の話に戻ると、システム・モデリングの面白い点は、こうしたデータモデル上の主従の逆転、アクロバティックな視点の転換が、ときに必要となることにある。必要なだけではなく、とても有効でもある。もちろん、そのためには、ある種のスキルがいる。ものごとを俯瞰して見る、一種マネジメント的なスキルが。そういう訓練の場をエンジニアのために作ろうと、わたしはこのところずっと研究部会の仲間達と活動しているのである。どうか期待していてほしい。


<関連エントリ>
 →「システムとはいったい何を指すのか」 http://brevis.exblog.jp/20878001/(2013-08-01)
 →「部品表と工程表」 http://brevis.exblog.jp/25634844/ (2017-03-22)

# by Tomoichi_Sato | 2017-03-31 22:10 | サプライチェーン | Comments(0)

部品表と工程表

今年の初め頃だったが、ある集まりを手伝うことになった。中高校生くらいの若い子達が20人くらい集まるので、彼らに昼食を出す。わたしと連れ合いはその食事作りのお手伝い、という受け持ちになった。わたし以外は全員、年配の女性達だ。集会場所の横にはそれなりのキッチン設備があり、食器もそろっているので、そこに集合となった。前日までのメールでは、シチューを作ると聞いていたのだが、当日集まっていたら、なぜかメニューはカレーと野菜スープに変更になっていた。ともあれ、食材もそろって、さあ調理と言うことになった。

ところで、この調理の進め方がなかなか見物だった。わたしは男なので、食器洗いその他の力仕事に回り、実際の調理は女性達が受け持つ。皆、何十年と料理をしてこられた方ばかりだ。ただ、わたしも一応、料理の心得はあるので、どんなプロセスで進むかは理解している。まず材料を洗い、切り、大鍋に適時投入して、煮て味付けをする。そのかたわらご飯を炊いて、織機を用意する。それだけのことなのだが、現場は大騒ぎだった。

まず、この集団には、采配をふるうリーダーがいない。2、3人、それなりにリーダー格というか、まあ仕切り屋のタイプの人はいる。だが回りの人たちも黙っていない。みな、料理については一家言ある女性ばかりだ。だからどの材料をどれくらい使うか、どう切っていつ鍋に投入するか、味付けには何をどれくらい入れるか、まあ実に喧々がくがく、議論が続く。議論だけでなく、彼女たちはしゃべりながら実際に手が動き、勝手にやってしまう。もうどうなることやら、ホントに昼食時間までに間に合うのか、などハラハラして見ていたが、幸いというかカレーも野菜スープもなんとかそれなりに出来上がって、腹を空かせたティーンエイジャー達の胃袋にあっという間に飲み込まれた。

この集まりはまあ、ボランティア集団のようなものである。こういう集団では、会社のような上司・部下関係が無いし、指示=命令原理も働かない。誰か図抜けたリーダーがいればその人の判断と采配で、皆が一応動くだろう。だが、そういう人もいなかった。それでも何とかなったのは、女性達の調理のスキルもあるが、一つにはカレーとスープという料理が、材料にも味つけにもある程度幅があっても、まとまりやすい料理だったからだろう。

それにしても、同じこの仕事を、わたしの勤務先の同僚達がやったらどうなるだろう、と想像してみた。ボランティアの組織だ。賛同者が集まり、業務命令系統はとくにない。でも、きっと、自然にこうなるだろう:
(1) まず、料理は何を何人前作るか相談の上、決める。
(2) 必要な食材のリストを作る。食材の種類と、数量と。必要ならば、スペックつき(たとえば豚肉ならば「バラ肉」とか)で。
(3) 調理の手順のリストを作る。それに必要な調理器具もリスト化する。
(4) 食材調達の担当者を決めて、買い物を任せる。
(5) その間に、調理器具と食器の準備をする。必要な食器を集めて洗い、並べる。
(6) 食材が来たら、これも分担して洗い、カット、下ごしらえをする。
(7) 調理をする。この作業にはやはり、多少はスキルのある経験者をあてる。
(8) たぶん何人かで味見をして、OKとなれば盛りつけ、配膳作業をする。

たぶんこうしたことが、なかば自然に進むだろう。なぜなら、これはエンジ会社が普段やっている、エンジニアリングの仕事そのものだからだ。誰かがリーダー役を引き受けるだろう。あるいは長老が、誰か若手を指名してリーダー役にするかもしれない。皆、そのリーダーの采配と交通整理に従う。難しい問題が起きたら、皆で相談して解決する。それでも迷ったら、リーダーの責任で打ち手を決断する。これがたぶん、わたし達のスタイルだ。もちろん、調理の腕前は熟練の女性達にはかなうまい。でも、何とか必要なものを必要なタイミングに必要な量だけ、届けられると思う。

とくに大事なことは、最初に大まかな計画を立て、必要な材料や道具や手順のリストを作ること。これがないと、全体の仕事量も、作業の分担も、そして納期も見通せないからだ。

わたしの勤務先が特別だというつもりはない。たぶん大方の会社は、少なくとも製造業なら、こういう風に仕事を進めると思う。ものづくり企業に共通なDNAというのがあるとしたら、その一つは、最初にいろいろなリストを作ることにあるだろう。リストなんか作らなくても、あの女性達のように、ものは作れる。だが、仕事の見通しは、格段に落ちるだろう。

必要なリストは何だろうか? あるいは、もっと抽象化して問題を捉えるなら、生産という仕事に必須な基準情報は何なのか。

それは大きく、「もの」(=マテリアル)に関する情報と、「製造作業」に関する情報とに分かれる。「もの」に関する情報は、まず、どういう品目(材料・製品を含む)があって、それはどういった使用・属性を持つか、というリストになる。これは通常のIT用語で言うと『マテリアル・マスタ』(品目マスタ)と呼ばれる。ついで、ある製品は、どのような部品・材料から成っていて、どれだけの数量を要するのか、という製品構成に関する情報が必要だ。これが『部品表』(BOM = Bill of Material)データである。ただしBOMがマスタとしてITシステムの中に整備されているかどうかは、その企業・生産形態に依存する。

では、製造作業に関する情報はどうか。これはまず、製造に使う機械・設備の情報と、具体的な作業の情報に分かれる。前者は、機械リストとか、会社によっては作業区(ワークセンター)マスタと呼ばれる。もう少し進んだ形では設備構成マスタというデータ形式になる。設備構成マスタとなると、その中に階層構造が表現されて、たとえば作業区1の圧縮機Aには、補機として潤滑油ポンプA1がある、といった事情がわかるようになっている。つまり一種の、機械設備に関する部品表みたいなものである。かなり保守業務のレベルの高い企業では、こうしたマスタが必要とされる。

後者の、具体的な作業の情報については、特定の製品・品番ごとに、(通常は複数の)製造作業が生じる。つまり、各作業に必要な機械・設備は何で、その順序はどうで、各作業条件は何で、(もしあれば)マニュアルや作業標準はどれで、といった属性が並ぶ作業マスタがいる訳だ。これは基準情報である。ただし、個別の作業指示が出される場合は、それぞれの作業にIDをふり、これに着手・完了のタイミングを指定し、さらに必要な機械・設備などをアサインしたリストを作ることになる。これは、しばしば『工程表』と呼ばれる。英語でBOP(Bill of Process)と呼ぶこともある。

以上をまとめると、生産という仕事に関する基準情報は大きく4種類に分けられる:

マテリアルに関する情報
・マテリアルの属性情報 → マテリアル・マスタ(品目マスタ)
・マテリアルの構成情報 → 部品表(BOM)
製造方法に関する情報
・機械・設備の構成情報 → 作業区マスタ、ないし設備構成マスタ
・製造作業の属性情報  → 作業マスタ、あるいはその具体型としての工程表(BOP)

なお、ここで注意しておきたいことがある。それは「情報」と「データ」の区別だ。これについては以前、『ITって、何?』というシリーズで長々と述べたことがあるから詳しくは繰り返さないが、
・「情報」とは人間に意味をもたらすもので、基本的には不定形
・「データ」は定型化された記号の並びで、機械的処理に適する
という区別がある。今日はA社の業績ニュースが流れて株価が上がりました、が情報。各社の株価が定型化されて並んでいる株式欄が、データ。情報を定型化して機械で処理したり、データを読み取って人間に意味を提示するのが、IT(情報技術)である。上に述べた基準情報の例でいえば、人間は情報だけあればいい。ただ、量が増えたときには、紙に記録してリスト化したり、さらにコンピュータの中に収めてマスタ・データ化する方がベターだ。

もう一点。上の説明では、『工程』という言葉をあえて使わぬように説明した(「工程表」は別として)。これは、工程という用語が業種・会社によってかなりいろいろな意味に使われているためだ。大きく分けても、工程をプロセス=作業群の意味で使うケースと、ワークセンター=作業区の意味で使うケースがある。それらをごっちゃにしているケースだって、少なくない。工程表という用語だって、それなりにブレがある。

本当はこうした用語類は、わが国の生産管理の発展のためには、共通化した方が良い。しかし、抽象化・標準化への希求がかなり弱いわたし達の社会では、それぞれの業界や特定の大企業が勝手に作った方言を、グループや系列会社に押しつける例が、よく見受けられる。業界を横断して工場づくりの仕事をしている我々エンジニアリング会社にとっては、まことに不便な状況である。本来だったらアカデミアの学者が先導して、こうした状況を改善すべきなのだろうが、あいにくその動きも薄い。

そこでわたしは、せめてこのサイト内では整合性のある用語を使うように心がけており、とくに多義語である「工程」は極力使わないようにしている次第だ。かわりに、わたしは製造業務のプロセスを呼ぶときは『工順』(英語でRouting)と呼ぶようにしている。わたしの考える製造という仕事のプロセスの構造を、図に示すと次のようになる。
e0058447_12531915.jpg
図 製造という仕事のプロセスの構造

もっとも「工順」という言葉だって、作業の集合を指す場合と、単に一連作業の中の連番(数字)だけを指す場合があるから、曖昧性は残るのだが、「工程」よりは誤解が少ないだろうと考えて、こうしている。

なお、図の中には「リソース」(Resource=製造資源)という言葉が出てくる。これは、作業の間は占有するが、作業した後でも別の作業に再利用できるようなものを指す用語だ。具体的には、作業する人・機械設備・治工具・金型などが含まれる。つまり、機械とか作業者とかよりも、1レベル抽象度を上げた用語である。このリソースのリストのことを、「資源表」(BOR = Bill of Resource)と呼ぶこともある。

かくして、製造業には、大きく言っても4〜5種類の基準情報が必要であり、それをきちんと整備・保守していく仕事が生じることになる。こうした仕事は全て、「間接業務」=直接お金を生まない仕事である。だから、しばしば日陰の仕事、縁の下の力持ち的な業務とみなされ、不況の時は優先度が下げられたりもする。そして、そういう態度自体が、生産性の低下をもたらし、さらに不況を加速するというダウン・スパイラルが生じる。これは、企業の持つ思考と行動の習慣=OSがバグっている状態だ。

なぜ企業には基準情報が必要なのか? それは、情報・データを再利用可能な状態に保つためだ。さらにいえば、仕事を予見・計画可能な状態に保つために必要なのである。冒頭に紹介したように、たまに集まるおばさま達の集団なら、基準情報など無くても、なんとか料理はできる。いや、それこそ、「ちょっとカレーの味が薄いみたいだから、ここにある和風だしを入れちゃいましょ。」などという、臨機応変な小技(大技?)を繰り出すことだって、できたりする。だが、これを仕事にして食堂を開くなら、もう一歩上を目指す必要がある。きちんと計画できて、繰り返し可能な仕事の状態にするべきなのだ。部品表と工程表は、そのための武器なのである。


(本記事を書くきっかけとなったのは、OpenLearning(https://open.netlearning.co.jp)が提供する「応用情報学」講義シリーズの中の、京都情報大学院・上田治文教授による「企業経営の情報学」Wee 2・Lesson 3「工場のIT化の核 部品表のコンセプト」を見たことである。わたしの用語・見解とはいろいろ異なっているが、4種類のマスタの整理など、いろいろと学ぶべき良いヒントをいただいたことを記しておきたい)






# by Tomoichi_Sato | 2017-03-22 12:56 | サプライチェーン | Comments(0)

「理屈を言うな」という理屈

15歳の時の4月。高校の入学式を終えたわたし達・新入生は、各クラスでの挨拶と簡単な自己紹介のあと、体育館に集められた。「オリエンテーション」という行事があると言うことだった。どういう行事かの説明はなかった。

新入生ばかり400人あまりが集められた後、体育館の扉が閉められたが、中には先生達の姿はなかった。壇上には学ランを着た屈強な上級生達が十何人か立って、両手を後ろに組み、胸を反らして立って、わたし達新入生をにらみつけた。どうやら『応援団』という存在らしかった。その中の団長格とおぼしき人が壇上の中央に立って、上半身を腰から前にかがめ、わたし達に向かって、かすれた声で

「ウース」

という声を発した。いや、正確には文字化が難しいのだが、とにかく強引に文字にすると、そういう音声だ。何事か、と驚いてきょとんとしているわたし達に向かって、壇上の、そして左右通路の応援団員達が、わたし達に口々に「返事はどうした!」「声が出てない!!」と大声で怒鳴りつけはじめた。どうやら壇上の人は「押忍(オス)!」とわたし達に呼びかけているのであり、わたし達はそれに対し、同じく「オス!」と大声で答えなければいけないのだ、という理屈が飲み込めるまで、たぶん10分くらい混乱の時間があった。

わたし達がようやく「オス」と声を揃えて返事することができるようになると、今度は校歌斉唱を命じられた。何人か固まって座っているブロックが指名され、校歌の一節ずつを歌え、というのだ。伴奏は応援団の大太鼓だけ。校歌と言っても、わたし達には簡単な歌詞のプリントが、入学手続きのときに、手続き書類の束と一緒に、渡されていただけだった。当然誰も歌えないし、覚えてもいない。無体な要求である。

だが立たされたものの口もきけずに黙っている新入生達に対し、応援団員は怒鳴った。「オリエンテーションまでに覚えろと書いてあったはずだ!」 たしかに配られたその紙をもう一度よく見ると、「オリエンテーションで校歌斉唱の練習をするので、その時までに覚えてくるよう、諸君と約束しておく」と書いてある。だが志望校合格に浮かれている新入生で、そんなものをまともに受け取った者はほとんどいなかった。

応援団員は恩着せがましく、では、一節ずつ我々が歌って示すから、お前たちはそれを復唱して繰り返せ、と指示した。かくて順繰りに新入生達は立たせられ、数節ずつ歌わされた。声が小さかったり、歌詞を間違えたりすると大声で叱られ、良しとされるまで、何度も何度も繰り返させられた。その間、回りの生徒がよそ見をしたり上の空だったりすると、すぐに通路の団員がとんでくる。体育館の扉は閉められ、出口にも守りを固めるように団員が立っている。実際に暴力がふるわれた訳ではないが、ほとんど脅迫的な雰囲気である。このような拷問に近い時間を、あとどれくらい過ごさなければいけないのだろうと、わたし達は思った。

ところで、あるブロックにさしかかって、うまく歌えないといって叱られた中の一人が、勇敢にも壇上の応援団員に向かって、必死の声を上げた。「たしかにプリントには『諸君と約束しておく』と書いてありますけれど、僕たちはとくに約束した訳ではありません。」 こうした火に油を注ぐような口答えに、応援団はどう反応するだろうかと固唾をのんだ。はたして、壇上にいる団長格の人は怒って、

理屈を言うな!

と一喝した。全員がしんとなる。そのとき、横に立っていた、もっと小柄で温和そうな人が彼を手で制して、言った(後で知ったが、実はこの人が団長なのだった)。

「たしかに理屈だ。だが、入学したら校歌を覚えるのは当然ではないか。君たちには春休みの長い期間があったはずだ。そんなに大変なことを、君たちに要求した覚えはないし、君たちから『約束できません』と言われた覚えもない。」

こう言われると、誰も反論できない。結局、オリエンテーションは2時間ほど続き、わたし達は校歌の1番はなんとか全員で歌えるようになった。だが校歌は全部で3番まである。明日もまた放課後にオリエンテーションの続きがあるのだ。わたし達はくたくたの心と体を抱えて、家路についた。

それにしても、理屈を言うな、という世界があるのか・・。帰り道、わたしは思った。本サイトの読者はお分かりと思うが、わたしは理屈っぽい人間である。だがわたしの高校は男子校だった。進学校ではあるが、古い高校で、バンカラの気質も残っていた。男社会で、しかも上級生下級生のタテ型序列の強い世界では、理屈を言うな、というセリフが通ってしまうんだ。理が通っても、力でねじ曲げられてしまう場所があるのだ。15歳のわたしは、このとき大きな教訓を得たと思う。

前回、「設計の『なぜ』を考える」で、わたし達は「なぜ」を問いかけたり答えたりするのがヘタだ、と書いた。だが、そもそもわたし達は、議論という行為自体が下手だ。そして、それは文化に多少根ざしたものだと、わたしは思う。理屈を言うな、は普通のノーマルな日本語である。賛成するにせよしないにせよ、意味するとことは誰にも通じる。だが、このセリフを外国語で言えるだろうか? とても難しいと思う。英語なら、”Don’t tell me your reasoning."といった感じだろうか。だが、あまりしっくりこない。イタリア語やロシア語で、これに類する言い方は可能なのか。アラビア語で、あるいはヒンディー語ならどうか。もしかしたら中国語や韓国語なら、似た言い方はあるのかもしれないが。

もちろん、どこの国に行っても、無体な要求、非道な連中は存在する。ただ西洋や中洋のように文化の根底が理屈っぽい社会では、そういう連中でも、自分たちが道理を蹂躙している、という自意識はあるのではないか。意識してやるのと、無意識にやるのでは、大きな違いがある。

理屈を言うな、というセリフは、どんなときに発せられるのか。それは、自分たちが共有している意思や熱情や気分に、水を差すな、という時ではないかと、わたしは考える。場を壊すな、といいかえてもいい。というのは、理屈というのは、自分と対象とを引き離すはたらきがあるからだ。『客観化』と呼んでもいい。自分と対象、自分と相手がほとんど一体化しているときには、理屈は無用で、入り込むスキマはない。たとえば恋愛に理屈はない。あるいはスポーツや勝負事で皆が一丸となっているとき、その行為の中に理屈を持ち出すのはヤボだ。そしてもちろん、上下関係の中にも。

理屈、つまり道理というのは、誰に対しても通用する。つまり公平である。万人に公平に与えられているのが、論理だ。こういうものは、上下関係の中の対話には、いささか邪魔なのだ。たとえば男子校の運動部のような場所では。あるいは一般に、タテ社会の中では。わたし達の社会における運動部(体育会)というのは、ある種、軍隊の中の人間関係を再現、ないし予習するための場所である。そこでは論理より熱情が優先される。

そして身分や立場の上下がある間柄には、議論はふつう成立しない。議論は一応、「対等」な間で行うものだからだ。

では、そもそも「議論」とはどのようなものだろうか。わたし達エンジニアが仕事の上で議論するとき、それはどのようなプロセスをとっているか、考えたことがあるだろうか? わたしの理解では、(少なくとも西洋社会では)議論は以下のようなプロセスを経る:

(1) まず参加者の共通の前提や目的を確認する。
(2) 議論の対象となる事実について、客観的・多面的に検討する。
(3) 問題となっていることや対策に関し、相互の意見を出し合う。
(4) 互いの視点や意見を組み合わせて発展させる。
 (ここで揉めたら、(1)や(2)に立ち戻って考え直す)
(5) 合意点を見つける。

つまり議論というのは一種の共同作業であり、一緒になにか建物を建てるような仕事なのである。まず(1)で共通の地盤を固める(ここが無いとそもそも議論にならない)。ついで(2)で、議論という建物の土台をつくる。事実というのはたいてい多面的で、見る人の視点によって見え方が異なる。だからここの部分は念入りに進める必要がある。そして、どちら側も「この上に建てて大丈夫」という風な認識を得るべく、客観的にものごとを記述することをつとめる。そして、このステップには自分の熱情や思い込みを持ち込めない。この『客観化』こそが、対象と自分を切りはなすような、“水くさい”部分なのだ。

その先も一応、順番に意見を応酬し合う、一種の共同作業である。互いにブロックを積み上げ合うような行為だ。そして互いに合意できる結論にたどり着く。それは建物の最上階に見晴台を築くのに似ている。これが議論のプロセス、あり方である。

だから、こうした議論では、基本的に「勝ち負け」がない。対等な立場同士の、共同作業だからだ。また通常の個人間の議論のみならず、学問上の論証も、ビジネスの交渉も、いや刑事裁判でさえ、こうした枠組みの中の『議論』の一種である、というのが西洋風のとらえ方だ。

まあ、議論に勝った負けたはないと言っても、もちろん人間だから、それぞれ途中や結果に対して不満もあり得よう。優位に立った方が、勝ち誇るような態度をとることもある。だが、原則として、議論は勝負ではない(和解に至らぬ民事訴訟やディベートという一種のスポーツは別として)。そしてもちろん、議論とは、どちらが頭がいいかの優劣を決める場でもなければ、言葉による喧嘩や暴力(口げんか)でもない。

こういう認識が文化(OS)の中で共有されていないと、意味のある議論ができなくなる。とくに、議論は口げんかではない、ということは早くから子ども達に教える必要がある。また、自分の意見に意固地にこだわらず、議論を通じて、オープンに変えていけるような態度を身につけさせなければいけない。

そして、議論とは広い意味で「学び」の一部である。なぜなら、「学び」とは考え方や知識や意見の変更をもたらすものであり、議論とはまさにそうした結果を生むためにするものだからだ。議論がきちんとできない組織では、認識も深まらないし、学びも行われない。そうした組織では、きっと同じような思い込みが受け継がれ、同じようなミスが繰り返されるだろう。

人間集団はいろいろな形で、不可避的に「上下関係」「優劣の順位」を作りたがる。それは一種、本能の一部なのだろうし、組織に一定の規律や効率をもたらすといってもいい。ただ、上の意見が下に対して絶対で、「理屈を言うな」という言葉で上下間での対等な議論を抑制してしまうと、組織は硬直化していく。理屈を含む議論はその解毒剤なのだ。少なくともわたしは、そう信じている。

私の高校が今でもあんなオリエンテーションという行事をやっているのかは知らない。たぶん、あんな野蛮なやり方は、今の時勢に合わないだろう。だが、15歳の記憶力はたしかに絶大だった。同窓会で集まると、いい歳したおっさん達が声を揃えて、今でも「こーしゃの、いーしずえ、動きなき〜」と校歌を歌うことができる。それと同時に、わたしはあの「理屈を言うな」という一言を忘れていない。あの一言はわたしに、偉大な教訓を与えてくれた。それは逆説的な仕方でわたしに、道理というものが弱い立場の者をまもる武器にもなりうるのだと、教えてくれたのだ。


<関連エントリ>
 →「設計の『なぜ』を考える」http://brevis.exblog.jp/25540003/ (2017-03-07)


# by Tomoichi_Sato | 2017-03-13 22:16 | 考えるヒント | Comments(3)

設計の「なぜ」を考える

まだ駆け出しだった頃、工場改善コンサルタントの話を聞いたことがある。それなりに面白い話がいろいろあったが、1番よく覚えているのはヘアドライヤーの話だった。このコンサルタントは、製造業、とくに電気系メーカーの設計部門を訪れた際は、必ずヘアドライヤーの冷風スイッチについて、尋ねることにしていると言っていた。

「ヘアドライヤーには、温風のスイッチのほかに、必ず冷風のスイッチがありますよね。御社の製品にも、ついていると思います。ではこの冷風のスイッチは、何のためにあるんですか?」

皆を集めてこう質問すると、たいてい誰も答えない。日本の会社は、皆そうだ。でも繰り返して尋ねると、中には元気のいい若手社員が手を上げて、こう答えたりする。

「はい。それは、あの、夏なんかの暑いときは、冷風で頭を乾かしたほうが気持ちいいからです。」

するとコンサルタント氏は続けて聞き返すのだそうだ。「それは本当ですか? じゃぁ、夏に冷風で頭を乾かしている人、手を上げてください。」実際には、手をあげる人はほとんどいない。そこで彼はとどめの一言を放つ。

「アメリカのメーカーに行ったら、こういう答えが返ってくるんです。『髪の毛は熱風を当てると柔らかくなるが、冷やすと硬くなる性質があるので、スタイリングをするときには最初は温風を当て形を作り、最後に冷風スイッチを使って固めるのです。』・・ところが皆さんはそれを作っているのに、なぜそれがあるかを知らない。」

アメリカの技術や製品を日本に持ってきたときに、何も考えずに形だけ真似するから、こういうことになる。何のためにあるんだか理解しないまま、機能をつけてしまう。そのためムダに設計も検査もコストが上がる。・・コンサルタント氏は私たちに、そう教訓を述べた。

もう一つ彼は例をあげた。「どこの工場に行ってもスパナって言う工具がある。知ってるでしょう? ところでこのスパナって、なんだか妙に握りが太くて持ちにくいじゃないですか。だから職場によっては工夫して、わざわざ細い棒を持ち手側に縛り付けて、持ちやすくしている」(彼は黒板に図を描いた)。「でも、なんでこんなことしなくちゃいけないんです?」——無論、わたし達は答えられない。

「それはね、最初にスパナをアメリカから持ち込んできた人間が、そのままのサイズで複製したんですよ。だからアメリカ人のデカい手に合わせた握りになってる。考えないでただ真似したんじゃ、工夫にならない。」

このコンサルタントの言うことがどこまで正確なのか、私はよく知らない。でもその時の私の頭には、『直輸入技術』の弱さ、脆さが刻み込まれた。それは「技術導入は麻薬のようなものだ」といっていた大先輩の言葉を思い起こさせた。外国からの技術導入は、最初は楽だが、次第に自分で考え、開発する力をなくしてしまう。

わたしはエンジニアである。最近はもう自分で設計する事はほとんどなくなってしまったが、それでもエンジニアだと思っている。なにか設計したら、結果は図面や仕様書に落とし込む。その結果が下流側部門のインプットとなって、関連する設計や調達や製造に使われる。それがエンジニアの仕事だ。

だが、エンジニアとして先輩の仕事に学び、自分の成長の糧とするときには、それだけでは足りない。設計の結果だけではなく、考えと仮説を学ぶ必要がある。先のコンサルタント氏による、冷風スイッチのエピソードは、そのことを示している。「技術を伝える」とは、結果としての形だけを教えるのでは不十分なのだ。「なぜ」そうなのかが大切だ。ノウハウ(Know How)より、ノウホワイ(Know Why)が大事だと、わたしの勤務先のトップマネジメントも、よく口にしている。

だから設計をするときには、設計の理由を記した設計ノートやメモやコメントを、なるべく作って残すようにしましょう。

・・というだけでは、実は話はまだ終わらないのだ。

なぜなら、わたし達は「なぜ」を問うたり、「なぜ」と問われたりするのに、文化的に不慣れだからだ。そうでなければ、どうして、誰かが大勢に理由の問いかけをしたとき、皆、遠慮したかのように答えないのか。間違っていても、推理を述べればいいではないか。間違いだったら、そこで学べばいい。別に命を取られる訳でもない。それなのに、「間違った答えをいうと恥ずかしい」という気持ちが先に働くから、誰も人前では答えなくなる。あとで廊下で講師をつかまえて、小声で確かめたりする。それで知識を共有できるだろうか。知らないことの方がもっと恥ずかしいはずなのに、皆が知らなければ、怖くないのだ。

「なぜ」の問答に不慣れなわたし達が陥りやすい「なぜの罠」は、何種類か考えられる。

説明1 「そういう慣習だから、昔からそうだから」
 よくある答え方である。上の冷風スイッチと同じだ。これでは理由を説明していることにはならない。

説明2 「目的はこうだから、機能はこうだから」
 なぜ冷風スイッチがあるのですか? それは、冷風を送れるようにするためです・・これは、質問のたんなる言いかえに過ぎない。その機能の目的が、使用者にとってどんな時どのような意義や利便を提供するか、の答えになっていない。答えのはるか手前で止まっているのに、なんだか答えたような気になっているだけである。

説明3 「それはこういう仕組みなんです」「こういう経緯でそうしました」
 ここのボタンを押すと裏で自動的にこのモーターが作動して・・とか、その機能はもともと別の形で実装する予定だったんですが経緯があって・・とか、詳しい説明が続く。だが、それは単に詳細化して説明するだけで、WhyではなくWhat, Howを述べているだけだったりする。こういう答えもありがちである。

説明4 「顧客が(誰かが)決めたから」
 いやあ、お客さんが(あるいは先輩が、他部署が)そうしろと言ったんですよ・・こういう答え方は、WhyではなくWhoを述べている訳だ。言われたことは忠実にやる。しかし言われないと自分では意見やスタンスがない。これは、受注型ビジネスにたずさわるエンジニアに広く見られる傾向ではないか。すなわち、設計へのオーナーシップの喪失である。本当は、これがけっこう深刻な問題だという気がする。

説明5 「自分のセンスで決めました」
 この自信に満ちた答え方は、言い方を変えると「なんとなく決めました」と同じである。設計者のセンスはもちろん、大事だ。設計という仕事は一種のアート(技芸)としての側面があり、設計者の感性を磨くことは訓練の一部と言っていい。センスがあまりにもない人は、ちょっとその仕事に向いていないな、と判断される場合もある。
 だが、感性に頼りすぎる仕事ぶりは、他者にうまく説明できないし、理解もしてもらえない。エンジニアは感性と理性のバランスが大切なのだ。そして、スティーブ・ジョブズ級の感性の持ち主ならともかく、普通クラスの会社員に「俺の感性を信じろ」と言われても、当惑するだけだろう。
結局、こうした罠に陥りやすいのは、設計という仕事において、「なぜ」をあまり問わず、考えない習慣にあると言えないだろうか。

いや! そんなことはない。我々は「設計レビュー」を要所要所で実施していて、そこできちんとチェックしているのだ、とおっしゃる論者もあろう。なるほど。それは素晴らしい。きっとそうした組織では、設計レビューの基準が(それもレビューの方法・手順や体制ではなく、基準が)明確なのだろう。

だが、設計レビューという行為は、しばしば設計書の記述ルールや整合性チェックにとどまる場合が多くないだろうか? つまり、IT分野の例を出せば、設計の「なぜ」を問う代わりに、以下のような項目の確認に時間を費やすのである。
・ネーミングルール
・エンティティ(要素)の洗い出し
・要素間のリレーション
・記述法とフォーマット
・図面間の整合性
・入出力の検証可能性
これはこれで、結構だ。だがこうしたレビューをいくら重ねたって、「いらない機能」「非効率な構造」をあぶり出すのに役に立つだろうか?

かくして、『機能しないレビュー会議』という問題が生じるわけだ(その証拠に、ネットで検索するといろんな関連記事が出てくる)。設計レビューを本当に機能させたければ、きちんと「なぜ」を問いかけ、まともに「なぜ」を答える習慣づけの必要がある。

そもそも、設計のアウトプットが、単なる工学計算の結果ならば、わざわざ誰も「なぜ」を問うことはしない。「この熱交換器の伝熱面積はどう計算したの?」「HTRIの推算式を使いました」「あっそう。」それだけの話だ。そこにはHowはあるがWhyはない。Whyが登場するのは、「この流体は一部が熱で気化して混相になるはずなのに、なぜ液相の伝熱計算式を使ったの?」というような、『判断』が登場する場合だ。

そして、設計業務の一番の肝は、判断(design decision)にある。設計のdecisionとは、本質的にトレードオフ間の決断である。われわれがなにかの設計時に直面するのは、
・安定性と俊敏性
・冗長性と効率性(燃費)
・頑健性と軽量性
・複雑性と保守性
・オマケ機能と製作工数
・品質とコスト・・
といった、「あちらを立てるとこちらが立たず」風の状況下において、どのようなバランスをとるかという決断なのである。そして、決めるためには、なんらかの仮説や推測が要る。「なぜ」の問いは、まさに、設計者の仮説を言語化するためにあるのだ。

設計という行為の中核がこのようなトレードオフの判断である以上、わたしは人工知能(AI)が将来、自動設計をしてくれてエンジニアの職をどんどん駆逐する、などという想像には組みし得ない。AIどんなに発達しても、機械だけでは決して設計問題を自動的には決められないだろう。

なぜなら、それは仮説設定と価値判断だからである。

設計の結論だけでなく、思考のプロセスと判断基準を示すこと。それがエンジニアの仕事であり誇りであってほしいと、わたしは思う。このことは、以前紹介したように、人に説明するとき「なぜ」からはじめるべき(Start with Why)という金言とも一致している。だから、「なぜ」にもっと真剣に向き合おう。

<関連エントリ>
 →「『なぜ』からはじめよう - 仕事の目的を設定する」 http://brevis.exblog.jp/24334345/ (2016-04-18)

# by Tomoichi_Sato | 2017-03-07 22:01 | 考えるヒント | Comments(0)

プロジェクト&プログラム・アナリシス研究部会」(3月28日)開催のお知らせ: 満員になりました

(大変恐縮ですが、下記の研究部会は大勢の方から参加申込みがあり、満員となりました。なお、予約なしに当日の参加はできませんので、ご了承ください)


「プロジェクト&プログラム・アナリシス研究部会」2017年の第2回会合を、下記の要領にて開催いたします。

今回は、JAXA・宇宙航空研究開発機構のチーフエンジニア室長である岩田隆敬氏をお招きして、JAXAのプロジェクトマネジメントについてご講演いただきます。

ご承知の通りJAXAは日本の宇宙開発の中心団体です。「はやぶさ」の例を見れば分かるとおり、宇宙開発は技術的難易度の点でも、また天体条件その他の環境制約の厳しさの点でも、チャレンジングな仕事の極致といえるでしょう。その難しさを克服するため、米国のNASAは1960年代以降、アポロ計画という「プログラム」、その下の個別ロケット・ミッションの「プロジェクト」という概念の元、さまざまな管理技術を開発しました。宇宙開発分野は、いわばモダンPMの育ての親なのです。

日本版のNASAともいえるJAXAもまた、我が国のプロジェクト・マネジメントの頂点の姿を示すと言っても過言ではありません。トップクラスのプロジェクト遂行はどのようなものか、興味深い話が聞けると思います。年度末のお忙しい時期とは思いますが、ぜひご期待ください。


<記>
■日時:2017年3月28日(火) 18:30~20:30
■場所:研究室棟B会議室(研究室棟1階)※定員:36名
 ※キャンパスマップの【10】
  (いつもの建物とは別ですのでご注意ください)

■講演タイトル:「宇宙航空研究開発機構(JAXA)のプロジェクトマネジメント

■概要:
人工衛星やロケットのような宇宙システムは、大規模かつ複雑、高価で、新規開発要素が多い上に、極限環境を飛行することを特徴とする。世界の宇宙機関の事業の大部分は、こうした宇宙システムの開発を中心に据えたプロジェクトで構成されており、宇宙機関は、プロジェクトを確実に遂行するために、開発の段階的実施、フェーズ移行審査、文書によるベースラインの明確化等といった共通のマネジメントを取り入れている。本講演では、宇宙航空研究開発機構の例を取り上げて、プロジェクトマネジメント推進の背景や、体制・仕組み、開発プロセス、審査、進捗確認、計画変更、スコープ設定、人材要件・育成、知識蓄積・継承などについて、紹介する。

■講師: 宇宙航空研究開発機構(JAXA) チーフエンジニア室長 岩田隆敬様
■講師略歴:
岩田隆敬(いわたたかのり)
・東京大学航空学科宇宙工学コース卒業、同大学院航空学専攻工学修士
・米国Stanford大学大学院航空宇宙学科M.S.(Master of Science)、
  Ph.D.(Doctor of Philosophy、主専攻:航空宇宙工学、副専攻:電気工学)
・宇宙開発事業団(現、宇宙航空研究開発機構(JAXA))入社
 ・陸域観測技術衛星(ALOS、「だいち」)プロジェクト
   高精度な姿勢軌道制御系、恒星センサ、GPS受信機や、大型の太陽電池パドル
   系、及び、地上の高精度指向決定システムの開発から運用までを主担当
 ・研究開発本部誘導・制御グループ長
   誘導・制御技術の研究開発とプロジェクト連携を指揮
   恒星センサ、GPS受信機や、GCOM-W1、ALOS-2、SPICAの姿勢軌道制御系
   開発を担当
 ・統合追跡ネットワーク技術部参与・計画マネージャ
   衛星の追跡管制の統括、予算要求、将来計画を担当
 ・現在、チーフエンジニア室室長
   プロジェクトの独立評価、PM/SEの体制・ルール/標準の維持・推進、研究開発
   マネジメントの推進を担当
・専門: 航空宇宙工学(特に、航法・誘導・制御・ダイナミクス)
・PMP

■参加費用:無料。 ちなみに本研究部会員がスケジューリング学会に新たに参加される場合、学会の入会金\2,000が免除されます。

会場の人数に上限があるため、参加を希望される方は、できましたら前日までに三好副幹事までご連絡ください。


以上、よろしくお願いいたします。
佐藤知一@日揮(株)

# by Tomoichi_Sato | 2017-03-03 23:56 | プロジェクト・マネジメント | Comments(0)

書評:「スティル・ライフ」 池澤夏樹・著

スティル・ライフ」 池澤夏樹・著 中公文庫(Amazon)


「この世界がきみのために存在すると思ってはいけない。世界はきみを入れる容器ではない。
 世界ときみは、二本の木が並んで立つように、どちらも寄りかかることなく、それぞれまっすぐに立っている。」

この不思議な小説は、こんな風にはじまる。『スティル・ライフ』というタイトル、そして冒頭の文章の主語の選び方とセンテンスの結び方、抽象的な叙述の仕方などから、この作者はよけいな湿り気のない、透明度の高い文体で物語をつむごうとしていることを、読者はまず感じる。

続く最初のシーンでは、バーの高い椅子に座る「ぼく」と友人の、静かな対話が描かれる。その友人は、水のグラスをじっと見ている。何を見ているのかとたずねる「ぼく」に対して、彼は、ひょっとしてチェレンコフ光が見えないかと思って、と答える。宇宙から振ってくる微粒子が、グラスの水の原子核と衝突すると、かすかな光が出る。それを待って、というのだ(これはスーパーカミオカンデの観測原理だが、この小説発表当時はまだ存在していなかった)。

わたしは池澤夏樹という作家について、ほとんど何も知らぬままこの小説を買って読み始めたのだが、どうやら理科系的な資質の人らしいと、この辺で感じる。たしかに本の見返りの作者紹介には、北海道で生まれ、国立大学の物理学科を中退した、とある。もちろん、理系文系の区別など、便宜的なものでしかない。東工大を出た吉本隆明より、青山学院の英文を出た姫野カオルコの方が、よほど非情緒的でクラリティの高い文章を書く。でも、どうやらこの小説は理系読者に好ましい、何か不思議な魅力を持っている。

主人公の「ぼく」と、友人の佐々井は、ともに染色工場で働いていて知り合いになった。工場で働く主人公というのも、今どき珍しい。色番号を指定して糸を染める工場の工程を、作者は「ロットサイズ」などの言葉を使いながら淡々と、正確に記述する。その仕事で何がカギになるのか、何に人々は悩むのかを、手短な文章とエピソードから描いていく筆致は、なかなか達者だ。

「染色なんて、分子と分子が勝手にくっつくのに、人は少々手を貸しているだけなんだ。」——人には手の触れられない領域がある。人が全てをコントロールすることはできない。この小説には、分子とか星とか、他の小説には滅多に出てこないような単語がときおり登場して、主人公や読者たちの視線を、ふいに遙か遠い所へと誘う。『遠い視線』、これこそが池澤夏樹の小説の魅力だろう。

物語はその後、佐々井の提案によって意外な方向に展開していく。それは、ふつうなら欲望とスリルにあふれた、波乱含みのストーリーになるはずの話だ。だが、遠い視線から語るこの小説では、どこか淡々と、ひどく静かにことが運んでいく。そう、まるでタイトルの示す「静物」のように。

「大事なのは、山脈や、人や、染色工場や、セミ時雨などからなる外の世界と、きみの中にある広い世界との間に連絡をつけること、一歩の距離をおいて並び立つ二つの世界の呼応と調和をはかることだ。
 たとえば、星を見るとかして。」

冒頭の文章に続くこの段落こそ、透明な叙情性に満ちた本作品の方向性を決定づける道しるべ、記念碑なのだろう。その後、同じ作者のエッセイも少し読んでみたが、やや理屈っぽく生硬な部分があって、必ずしも読みやすいとは感じられなかった。だが、この作品は本当に素晴らしい。端正で静謐な、若い文学としての美しさに満ちている。本作品は1988年の中央公論新人賞と芥川賞を受賞した。



# by Tomoichi_Sato | 2017-02-25 16:56 | 書評 | Comments(0)

Pushで教育し、Pullで成長する

子どもがまだ小さかった頃、よく「きかんしゃトーマス」を一緒に見た。このイギリス製の人形劇は、どうやら英国社会を引き写しているらしく、階級制になっている。機関車はおおむね真面目で勤勉だが、彼らに引かれて走る客車はいつも適当な連中で、機会があればサボることを考え、しょっちゅう脱線事故などの面倒を引き起こす。つまり機関車(Engine)は、技術者(Engineer)のような中産階級を連想させ、客車はすぐにストやサボタージュをする労働者階級を思わせる、という具合だ。
あるとき主人公のトーマスが、例によって客車にトラブルを起こされ、手を焼いていた。すると、となりの線路をゴードンという機関車がちらとトーマスを横目で見て、「人生は勉強だな」といって通り過ぎるシーンがあった。きかんしゃゴードンは中年男を思わせる横柄なキャラなのだが、この台詞はなぜかぴったりと役にはまっており、見ていたわたしと連れ合いはその後しばしば、小さなトラブルに遭遇するたびに「人生は勉強だな」と言い合って笑ったりした。

人はいくつになっても成長できる。逆に言えば、人は一生、学び続けなければならない。ゴードンの名台詞はこのことを表している。ところで、英国のコンサルタントであるMarcus Buckinghamの説によると、人間の学習スタイルには、「分析型」、「行動型」、「観察型」の三つのタイプがあるのだそうだ。それによると、
・分析型は事前の学習時間を十分とる
・行動型は早く未経験の環境に置く
・観察型は手本になるベテランの傍らで、仕事を俯瞰的に見ながら模倣させる
というのが、それぞれOJTのやり方としてふさわしいらしい。このことは、稲山文孝氏の「アプリ開発チームのためのプロジェクトマネジメント」http://brevis.exblog.jp/24117407/ という本で読んだ。

なるほど、とは思ったものの、上記の3タイプはあくまで英米人の類型かな、とも感じる。わたし達の社会なら、このほかに「感情型」だとか「競争型」とかを付け加えたくなる。感情型は好きな人を手本にして感性や情に訴えて学ばせる、「競争型」は試験を課して成績で競わせる、と言う具合だ。

まあ人間の類型論は医学・心理学から社会学まで、いろいろなバリエーションがある。だが、学びという点で見ると、大きく「受動型」と「能動型」に二分できるのではないかと、よく感じる。というのは、この区分は、育成・訓練におけるマニュアル整備の是非の論議に、しばしば登場するからだ。マニュアル論議といういうのは、仕事について伝えるべき一切合切、なるべくすべてをマニュアル化すべきか、という論争である。いや、親切すぎると相手の「学び」が働かなくなるのでは、という疑念や、緊急時対応はどこまでマニュアル化できるか、といった疑問もこれに近い。マニュアルがないと対応能力が下がる。しかし、あまりすべてをマニュアル化すると、今度は「想定外」に対応できなくなるパラドックスが生じる。

こういう議論では、どうも意見に世代間ギャップがあるな、とわたしは感じている。おじさん世代(わたし自身を含む)にとって、知識は稀少資源だった。わたしが社会人になった頃は、パソコンというものすら存在していなかった(きっと日本昔話みたいに聞こえるだろうなあ)。知識はほぼ全て、紙の中にあった。そして、知識情報は自分の個人的資産として「囲い込む」(机の中にしまっておく)ものだった。人が知らないことを知っているのが、自分の優位性だ——そういう感覚が強かった。

その時代、「技術は盗むもの」と信じられていた。教えすぎてはいけない、と。教えなくても優秀な人は、自然に身につけるものだ。何より、生まれつきのセンスが一番大事で、あとは「やる気」、気持ちの問題だ。つまり、自分から知識を取りに行く(Pull型)の態度が主流だったのだ。

ところで、このような態度は時代とともにかわっていく。若い世代(定義は難しいがバブル時代以降か)にとって、知識は世界に氾濫しているものだ。知識はネットでふんだんに流通している。あとは自分で好きに探せばいい。知識は他者から与えられ(Push型)、選び取るものになった。情報整理とフィルタリングの感度が自分の優位性だ、と感じているのではないか。

このギャップは、世代間で知識情報を伝達する「教育研修」において、重大な影響を与える。シニア世代は、若手が取りに来るのを待っている。若手は逆に、シニアが教えてくれるのを待つ。つまり「教育のデッドロック現象」が起きているのだ。こうなると、組織的な「学び」が働きにくくなる。それは、同じような間違いやトラブルを繰り返す原因になるだろう。

このところPMの教育について、ずっと考えている。マネジメント能力の育成は、知識教育だけではまったく不十分だと、わたしは思う。そもそもマネージャーとは、教育すべきものなのか、それとも自己成長なのか? 「俺の背中を見て育て」というおじさん世代にとって、マネジメント能力は自分から取りに行く(盗む)のが当然という考え方が強い。おまけにその世代は、マネジメントの仕事を伝達可能な形で言語化していないことも多い。

もちろん、マネジメントの能力には、言語化できる部分とできない部分がある。つまり属人的なソフト・スキル(技能)の部分と、軽量化し伝達可能なマネジメント・テクノロジー(技術)の部分とがある。そして後者は、先ほど述べたマネジメントの「マニュアル化」の議論につながりがちだ。どこまでマニュアル化できるのか、またマニュアル化すべきなのか?

こうした育成をめぐるPushとPullの議論が混乱する理由は、いろんなレベルの知識情報をごっちゃに話していることにある。そこで知識のレベルを「基本」と「応用」に分けて考えてみよう。

(1) 基本レベル

仕事に必要な基本的知識は、伝える側=先輩が、受け手=後輩に教えこむべき(Push型伝達)ものだろう。そうでなければ、組織として効率がわるすぎる。基本レベルとはつまり、テクニカルで伝達可能な知識やハード・スキルである。そして、そのためには知識に関するPushのシステム(仕組み)を作り上げる必要がある。つまり、教科書化・マニュアル化する訳である。あるいは昨今ならば、 ITツール(e-Learning)も活用することになる。

システム(仕組み)である以上、教える側の体制も構築しなければいけない。なぜなら、「人に教える」こと自体が学びにもなるからだ。組織としては、それを評価褒賞にも組入れる必要がある。

(2) 応用レベル

これに対し、応用的な知識やスキル(主にソフト・スキル)は、受け手が自分から学びに行く(Pull型)べきものである。そうでなければ、能力として本当には身につくまい。そのためには、Pullの知識獲得のための態度・思考習慣(OS)を持つことが必要だ。また、応用レベルは一般にマニュアル化に向かない。範囲が広く例外事象が多いため、教科書・マニュアルでカバーするには効率がわるすぎるからだ。

そこで中心になるのは、学ぶ事自体の面白さだ。身につけば、仕事の幅を広げるのに役に立つ。いや、直接すぐに役に立たなくても、いつか役に立つ潜在的可能性があればいい。そして応用レベルの問題には、必ずしも正解はない。だから、自分の頭で考え、自分のスタンスや価値観を持つ態度が求められる。


以上の二つのレベルのあり方は、ちょうど、学校教育でも実現されている。小中学校の基本レベルは、義務教育であり、先生が生徒に知識をプッシュで教え込む。子どもの側は、なんでこんなことを覚えなけりゃならないのか、などと疑問を持つこともあるが、そこは問答無用ということになっている。これに対し、大学・大学院というところは、(本来は)応用レベルを学ぶ場所だ。そこではいちいち、手取り足取り、教えたりしない。自分の頭で考えて、レポートや卒論などにまとめることが要求される。

ただし、(1)の基本レベルと、(2)の応用レベルを結ぶために、大事なことがある。それは、基本レベルを教える過程の中で、同時に「自分で学びに行く態度」を育てなければならない、ということだ。これがあるからこそ、応用レベルで自ら成長していけるのだ。そのためには、教え手が見本(モデル)となって示す必要がある。質問されたら、誠実に答える姿。難しい問い(つまりよい質問)に対しては、必ずしも全知ではない姿。そして自分も新たに学んだ、学べて面白い、という姿を、見せること。これがあってはじめて、基本レベルの生徒にも「学ぶ態度」が少しずつ身についていくのだ。
e0058447_23012569.jpg
しかし現実を見ていると、どうやら「学ぶ態度を教える」ことが、ミッシング・リンクとなって 欠けていることがある。そうなると、基本レベルから応用レベルに壁を越えてジャンプできない。学校教育でも、高校から大学へはジャンプがある。これにつまづくと、昔なら五月病にかかった。今は、大学自体がPush型中心の、手取り足取りやたらと面倒見のいい(?)教育に、重心を移してきている。そうなると今度は、社会に出たときがジャンプになってしまう・・

そこで大切になるのが、知識のナビゲーター(水先案内人)を組織の中にたてることではないだろうか。まだ十分にPull型の「学ぶ力」が身についていない人を、知識のある場所や、よく知っている先達に適切に導く役柄だ。わたしのこの小さなサイトも、及ばずながらマネジメント・テクノロジーへの水先案内役をしているつもりだ。

もう一つ。これもわたしの仮説だが、Pull型を習慣化し身につけるのは、一人の意思だけでやるのはしんどい。そこで、上級レベルへと学ぶ人のためのコミュニティがいるのだ。その証拠に、だから大学はゼミ方式になっているではないか。

思うに、Push型の教育は、ビジネス化できる。世に沢山、予備校だとか塾だとか資格学校だとかがあるのを見れば明らかだ。ところが、Pull型の成長は、ビジネスになりにくい。「学びに行く態度」を教えるには、マンツーマンの部分が必要であり、マスプロ教育の大量生産に比べるといかにも効率がわるいからだ。

それと同じことで、今の世間のPM教育には「応用」への道筋が欠けているように感じられる。基本レベルは、たとえばPMBOK Guide(R)でカバーできる。そこには有用な知識情報がライブラリ化されている。そしてPMP資格のための教育プロバイダーも多い。だが、本当は「PMBOK以降」への準備が同時に必要なのではないか。PMPは出発点に過ぎない。PMBOK以降も自分で考え、学び続けるための方法と場所がいるはずだ。だからこそわたしは、研究部会の仲間とともに、PMを学ぶためのオルタナティブな仕組みを構想しているのである。

最近、職場の大先輩が語っていたのだが、仕事はあるところから面白くなる、という。最初のうちは覚えることも多いし、担えるのは小さな役割に過ぎない。しかし基本レベルをマスターして、うまく先に進めると、Pushで与えられた専門の枠を超えて、周囲も巻き込んで大きな仕事をつくれるようになる。そして複利計算的に、自分を拡大再生産できるようになる。学ぶ能力自体が資産になるのだ。この大先輩は、基本から応用にジャンプするための、Pullで学ぶ力を身につけたからだろう。

学ぶ力とは、潜在的な能力をみずから獲得するための力である。すなわち学ぶ力とは、能力を得るための能力だ。それを身につけることは、単なる「即戦力」などの教育よりも、ずっと大切なことなのだ。

「教育の目的は、自分たちが聡明ではないことを教えることである。」(アラン・ケイ)


<関連エントリ>
 →「学ぶ時間をどうつくるか」http://brevis.exblog.jp/24292367/ (2016-04-10)


# by Tomoichi_Sato | 2017-02-20 23:04 | プロジェクト・マネジメント | Comments(0)