プロセス、教育、体制づくりなど、組織的な取り組みが必要
河野氏も、ツールを使ったモデリングを開発プロセスに取り入れ、成果を挙げている。採用しているツールは、特に自動車業界で広く普及しているMATLAB/Simulinkだ。
「いわゆる“経験”と“勘”も確かに大事だが、リアルタイム性に対する要求が非常にシビアな部分などは、ツールを活用してしっかり検証しながら進めていくのが、手戻りを防ぐ上で有効なやり方だと思う」と、MDDツールの有用性を認識している一方で、河野氏は次のような問題点も指摘する。
「コンパイラにもバグがあるのと同様に、残念ながらMDDツールにもバグはある。MDDの実践にあたっては、モデル上の検証結果と生成されたソースの整合性をチェックする『MDDツールの検証プロセス』を組み入れたほうがよい」
また、ツール以前に重要なのが、それを使う人間のスキルである。SESSAME（組込みソフトウェア管理者・技術者育成研究会）でエンジニア教育なども行っている山田氏は、「最近は、『凝集度と設計度』のような設計の基本的概念を知らずに設計しようとしている人が多いように感じる。そもそも、自分できちんとした設計図を書けなければツールは使えないはず」と語り、エンジニア教育の重要性を強調。さらに、組織的に教育に取り組む上での有効な方法についても触れた。
「過去の成功体験があり、自分のやり方を確立している中堅社員たちは、MDDのような新しい取り組みに対して抵抗勢力になる場合もある。そこで有効なのが、まず若手を教育すること。新入社員の段階から、設計図の読み書きが当たり前の状況を作る。やがて若手がスキルをつけていくと中堅社員たちは焦り出し、自ら取り組むようになっていく。組織的な取り組みとしては、こうした工夫も必要だ」
教育のほか、MDDに取り組むための「体制づくり」も重要なポイントとなる。鈴木氏は、「Rational Rapsodyの導入を検討されているお客様には必ず、MDDの受け入れ体制ができているかどうかを確認する」という。
「実際に手を動かし、困難な状況があってもめげずに取り組んでくれる現場のリーダー、そして、予算面も含めて背中を押してくれるマネージャが社内にいなければ、成功させるのは難しい。また、社内・社外を問わず、MDDに精通したパートナーも必要。MDDはパラダイムシフトといえるが、そこに向かうことでどんな“良いこと”が待っているのかを知っている人がいないと、やはり前へ進みにくい」
モデルのレビューでMDDの「楽しさ」を伝える
MDDを現場に定着させるためには、こうしたさまざまな組織的な取り組み・工夫が不可欠といえる。たとえば島氏の場合は、社内でトレーニンググループを作り、グループ内でモデルのレビューを実施。そこで特に重視しているのが「ほめること」だそうだ。ソフトウェア開発で「ほめられる」という機会はそうそうあるものではなく、これはエンジニアとして純粋にうれしいはず。また、それ以上に「モデルのどこを見て、どうほめるか」を考え、理解させることが大きな意味を持つのだという。
鈴木氏も、MDDのメリットを実感させるには「レビュー」が有効であると考えている。
「コードレビューはつまらないと感じている人も多いと思うが、それがMDDのモデルレビューなら楽しいものに変わる。まず『動くもの』をレビューの場に持ってきて、みんなで画面を見ながらサッとイベントを投入、するとどう動くのかもその場ですぐに分かる。次々にいろいろなパターンを試すことができて、結果は一目瞭然。このレビューの楽しさは、MDDならではの大きなメリットといえる」
各パネラーの話を受け、最後に渡辺氏は「今までのモデリングは、理屈で『やらなければいけないからやる』という人が多かったようにも思える。しかし、実際に自分の目で見て、『楽しいから』『効率的だから』と実感して始めるような人が増えていかないと、なかなか本当の意味で現場に定着しない。本日の島さんのデモのように、『MDDならあれだけ動かせる！』ということが分かれば、もっともっと多くのエンジニアが引き寄せられるのではないかと感じた」とまとめ、パネルディスカッションを結んだ。
