<   2017年 04月 ( 3 )   > この月の画像一覧

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

わたしの働くプラント・エンジニアリングの業界には、通称「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)