2017年 04月 19日 ( 1 )

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

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