**********************************************************************
セッションs1d 分科会・パネル
テーマ:MBSE/MBD導入の勘どころ
講師:兼平靖夫
日時:2019/9/5(木) 21:00?22:30
参加人数:約20人
**********************************************************************
■概要
・自己紹介
ダッソーシステムズ株式会社 システムズ・エンジニアリング・プリンシパル、
横浜国立大学 成長戦略研究センター 産官学連携研究員
■MBSEの定義
・システムズエンジニアリングとは、IPAの定義ではシステムの開発を成功させるために、複数の分野に
渡るアプローチのこと。
ここでシステムとはINCOSEの定義によるとお互いに関連があり、相互作用するようなものをいう。
・なぜシステムズエンジニアリングなのかというと、日本は複雑ものを複雑なままで
開発するのが得意、これは東大モノづくり経営研究所の藤本先生の言葉、すなわち、すりあわせがうまい。しかし、この方法は限界が来る
だろう。
実際、ロケット開発や自動運転の分野などではMBSEが導入されている。
・MBSE標準はISO15288からきている。ここに書かれていることは別に難しいことではなく、
日本でもやっていること。
しかし、見える形になっていなかったり体系立てていなかったりする。
過去の経験(NASAなど)からやらなきゃいけないではなく、やっていて良かったとが
書かれている。どうやってやりなさいとは書いていない。
そのため、ツールを買っただけで製品が良くなるわけではなく、メソッドを頭に入れて
やらなければいけない。
・NASA JPLのEstefan氏はシステムズエンジニアリングをPMTE(process methods tools environment)という関係で整理した。、どうしてもベンダーが説明するときや開発者が行う時にはTechnology中心となりPeopleが
軽視されがち。多くのセミナーでは人のモデル化について説明できていない
・標準(汎用)メソッドがあるのかという論争。
服と人のようにオーダーメイドではないのだから、全てに合うメソッドというものは
当然ない。あくまで標準メソッドは過去にこういう考え方でうまくいったというのと
同じである。
・メソッドの例のとして、MagicGrid、CESAMES 9 views、MMS(Modeling Methodology for System)を紹介
例のようにメソッドも色々あり、どのメソッドを使えばいいかを考えなければいけない。
標準メソッドは、服と同じように自分にピッタリ合うというものはなかなかないので、
少し修正して使っていくべき。
【質問】社会で誰がそれをやるのか。
【回答】社会ではコンサルを入れてやるが、会社に合ったメソッドを提供するのは
コンサルには難しいのが現状
■MBSEの事例(組織の話)
・PSAという自動車業界の組織を例に話す。
PSAの組織はエンジン作る部門、ドアを作る部分などと分かれていた。
それぞれの部門で良いものができたが、それらをを合わせるとだめだった。
トップダウンでこれではだめだと考え、コンポーネントベースからサービスベースに
変更した。
【質問】PSAのこの例はトップダウンなのですか?
【回答】ミドルマネジメントという形が正しいかもしれない
・コンポーネントからサービスにすると抜けがある。
それを防ぐために、ミドルに動いてもらう必要がある。
PSAが成功したのはPSAが潰れかけだったからミドルが言うことを聞いたのではないか。
この例に関しても成功例の一つでしかないので、他の組織でもうまくいくとは限らない。
メソッドを理解し自分の血肉に変える必要がある。
■ディスカッション
【議題】スライドの表を見て、ピラー(pillar)って何?ビュー(view)とは違うのか。
・利害関係者の階層というビューがあって、それが縦に並んでいたものをピラーという
【議題】スライドの表を見て、パラメトリックに違和感があるのですが
・SysMLの作成者がそういうのがいいと思ってパラメトリックにしたのだろう。やってて
よかったことの例なので深堀りしても意味がない。
・このように整理しているのがすごい、日本人はこのように整理するのが難しい。
・パラメトリックに違和感があるならそれこそ自分でうまく解釈し、違うものにすれば
よい。あくまでうまくいった例。
【議題】パラメトリックっていうのはクラスに対するインスタンスか。
・可変なもので、うまく範囲が決められたらいい。インスタンスではない。
・バリエーションやバリアントではないのか。
・SysMLは一品物(アポロなど)が多いのでヴァリアントではなく固定。
・パラメトリックは固定的ではなく、例えばロケットの場合、宇宙のどこを飛んでいるか
によって変わる。
・第一弾ロケット、第二弾ロケットなどに分けられて、前者と後者で要件がうまく
分けられている。
・空気の薄さなど連続量として存在するものを意識しなければならないのがパラメトリックが
表現したいことだと思った。
・そこまでできているかはわからないが、理想的にはそうだろう
・一品物のロケット、そうではない標準的なものでは違う。
これを信じればいいという物ではない。組織的にどうすればいいいかを考えなければ
ならない。
【議題】モデルの扱い
・システムエンジニアリングでどういう階層でモデルをそもそも使っているかを抑える、
対象として扱っているモデルに人間系が入っているのにそれを作っている側の位置づけが
おかしい。
対象のモデルにあるものをなぜ作る側だけ違う扱いで議論するのか。
例えば、自動車の場合運転手や歩行者は人間というモデルであり、作る側の組織を議論
するときの人間のモデルと同じモデルではないといけない。
同じモデルじゃないと大量にモデルを作ることになってしまうため、システム
エンジニアリングにならない。
・違う観点なのだから別のモデルでいいのではないか。
・むしろ同じ観点で使わなければならない。モデル自体は同じ振る舞いが変わるかも
しれない。
・それをモデル駆動開発というと破綻するのではないか。
モデルに表してないものまで全部やらなきゃいけないとなると理解できる人はいなくなり、
ソフトウェアの実装に役に立たないのではないか。
・そういうモデルが実際にあり、新たに作る必要はない。
・どこの組織体でもすぐに変えられるものではないので、変えられないものとして対処した
ほうがいい。直近の製品を作るのにそうせざる負えない
【議題】MBSEを導入する価値について
・すりあわせじゃだめなのか。→ すりあわせできるなら組織は変える必要がない。
しかし、どこかで限界が来る。それをいまから手当するのか、いつするのか。
・年齢や重力といった我々が当たり前だと思っているパラメータだけでなく、意識して
いないパラメータが存在するかもしれないという話ではないか。
・複雑なものが出たときに分割統治する必要がある。組織についてそれがまだ不十分である。
【議題】ヘビーウェイトプロジェクトマネージャーについて
・日本ではヘビーウェイトプロジェクトマネージャーがいて日本の主たる製品を作って
いる。今はそれでいいがいなくなったらどうするのか、日本以外でもその人は活躍する
ことができるのだろうか。
・ヘビーウェイトプロジェクトマネージャーを増やすことはできるのか。
・そもそも増やす必要がない。次の世代が出るのかっていう管理体制を取る必要がある。
某有名会社だからといって入ったといった人が集まっていてはだめ。
【議題】組織の維持について
・組織の維持と社会の発展・貢献の関係が難しい。
今までうまくいっていたものを大きく変えるというのはリスク・リターンが見合って
いない。そこの部分の担保が難しい。
・某カーメーカーの方針は、外に投資する、外に関連会社を作ってそこでやらせる。
それが成功するかは分からない。
【議題】人と組織の違い
・人と人のDNAは99%同じ。人とチンパンジーは96%同じ。人とバナナでさえ60%同じ。
そのため、薬は大体の人に効く。
しかし、会社はいろいろな過去からできていて、会社に関しては先の薬の例でいうと臓器がない場合がある。
臓器がなかったら当然その薬は効かない。
・人と会社では確率分布が違うため同じ確率分布で考えてはいけない。
【議題】誰がどのメソッドを使うか考えるのか
・メソッドは100%過去の例と一致するというのは難しいのでそこの差異を考えなければ
いけない。
・それは誰が考えるのか、ヘビーウェイトプロジェクトマネージャーが考えるのか。
・ヘビーウェイトプロジェクトマネージャーはすりあわせの世界で指揮する人。
・MBSEでも同じことをしなければならないではないか。
全体構造を見てどういうピラーがほしいのかが分かり、ツールも使えてヘビーウェイト
プロジェクトマネージャーもできてなんて人をどうやって育てればいいのか。
・育てるのではなく自分がなればいい。
・そういう人は目的がしっかり意識できている人でなければならない。
PSAの例では、最高のドアを作るのではなく、最高の車を作るという目的を意識する
必要がある。
最高の車を作りたい上の人が最高のドアをつくれと指示を出すのだが、その間を
コントロールする中間層(ミドル)が大事である。
【議題】日本人がボトムアップになる理由
・日本人は下の人もそれなりに知識があり、ここはこうした方がいいのかとボトムアップ
している。ボトムアップの文化ができた結果、組織的には下の人が動きにくいと嫌だと
感じるかもしれない。結果として下の人が大変になってはいるが。
実際にものを作るとなると、飛行機とか作るとなると、MBDをしっかりやって、上流設計の
ところでできるだけ叩いていく必要がある。
・MBDをしっかりやっているところでは、トランスミッションの設計は構造がものすごい
複雑である。シミュレーション(モデル)で作らないとテストできない。つまり、MBD
するかどうかはモデルベースは設計の複雑さに依存する。
【議題】日本でのMBSE
・欧米がMBSEは良いって言ってるからじゃなくて、日本はボトムアップの文化があり、
その良さをなくさない和風のMBSEが良いのではないか。
例えば、ピザとか本場とは違う日本に合ったものにしている。MBSEもそのようにしたい。
・和風のMBSEのイメージ、こういうものというのはあるのか。
・日本のMBSEの共通点を見つけて、そこからさらに個別に追加していくのがいいとだろう。
そういうのができたらいい。
【まとめ】
MBSEはそれをやったらスーパーマンになれるというわけではないので、あくまで過去のプロジェクトの成功要因、もしくは失敗から学んだ知見なので自分で理解して
いいとこ取りをしていくのが大事。