組込み技術者はなぜ「使える」モデル図が描けないのか？～業界特有の苦悩とその打開策

読者への挑戦！

　突然ですが、クレーンゲームのモデル図を描いてみてください。ボタンでクレーン位置を操作して景品をキャッチするあのゲームです。時間は5分。気楽に描いてみてください。

　いかがですか？ ちょっとここで手を休めてあるモデル図を見てみましょう。

　実はこれ、モデリング初心者の山田さんが描いたモデルなのですが、彼の先輩から見ると改善の余地があるのだとか。皆さん、どこが問題なのかわかりますか？回答は後ほど。

組込みソフトウェアは一般のソフトウェアよりもモデリングが難しい

　組込みソフトウェアの開発者であれば、程度の差はあれ誰もが同意できる夢があると思います。ハードウェア構成や制御方式の変更に振り回されないようにしたい。もっと楽に追加や変更を行うことができて、しかも障害が発生しにくい開発体制を確立したい。

　その夢を叶えるためのツールとしてモデリングはとても有効です。複雑な現実を整理し、多くの人が理解できる形で共有し、その知見を再利用するという考え方が、組込みソフトウェア開発でも正しく定着すれば、厳しい開発現場の改善が実現できるはずです。

　ただし、現実にはそれが十分に達成されているとは言えません。その理由はいくつか考えられますが、端的に言えば抽象的・概念的な設計よりも目の前で実際に動く実装の方が尊重されるからでしょう。とはいえ、そうせざるを得ない理由があることも事実です。

　一般的なソフトウェアと違って組込みソフトウェアは自然現象に大きく影響される傾向があります。例えば、自動車のブレーキを制御するABSは、運転手がペダルを踏む強さだけでなく、路面の滑りやすさや凸凹などの情報を総合的に勘案して、ディスクの油圧を調整しています。このような自然現象は机上の設計で十分に想定しつくすことが困難です。

　そこへ来てコストの問題もあります。例えば、ABSの設計者は路面状況を検知するためのセンサーを望むでしょうが、そうやって必要なリソースを逐一積んでいくと車の価格が跳ね上がってしまう。製品の構成要素として設計される組込みソフトウェアは、コストなどとの兼ね合いから利用可能なリソースが常に限定されています。ABSの場合も、車輪の回転速度を測るセンサーの情報を基に路面状況などを推量します。

　「予測困難な自然現象」を「限られたリソース」で制御する組込みソフトウェアの世界では、教科書に書かれた理論どおりに設計しても目的は達成されませんし、必要なデータを直接的に取得できない場合が多い。だから、「係数を調整したら挙動が安定した」「この機器の値を使えばセンサーの代わりになりそうだ」など、現場レベルで試行錯誤を重ね、その過程で得られた実践ノウハウを取り込むことが必要不可欠なのです。「理論的に正しい設計」よりも「実際に動くもの」が尊重されることはやむを得ないことでしょう。

　結果として、組込みソフトウェアにおけるモデル図は単純に実装を引き写しただけのものになりがちですが、それらを見てもどのように機能が実現されているかという理屈はわかりません。「ただ単にそうなっている」という現状追認の図では、ハードウェアに縛られず、追加や変更を容易に行なうという“夢”の実現もまた難しいと言わざるを得ません。そして、まさにこれこそが、組込みソフトウェアをモデリングする難しさと言えます。

組み込み開発者が犯しがちな「動かすだけのモデル」3タイプ

　前述したように、組込みソフトウェアのモデル化にあたっては、「動かすだけ」のモデルになりがちという問題があります。ここからは、組込みソフトウェア開発者が描いてしまいがちな「動かすだけのモデル」を具体的に紹介していきましょう。大きく3つのタイプがあります。

　自動販売機をテーマに1つずつ見てみましょう。まずは、「機能（手続き）で分解したモデル」の例です（図3）。

　構造化手法で行う機能分担でモデリングするとこのような図になりがちです。「システムデータ」部分にグローバルな情報が押し込まれていて、要求に変更があると全面的な見直しが必要になります。C言語で長年開発を行ってきたエンジニアが、こういうモデルを作りがちです。

　「物理構成で分解したモデル」もよく見られるパターンです（図4）。

　

　このモデルでは、自動販売機というひとつのクラスにすべての処理が詰め込まれ、その周囲に、デバイスやメカ機構など物理的な実体を表すクラスが登場します。わざわざモデリングという手法を使うのは、自動販売機の機能を可視化したいからなのですが、それがひとつのクラスに詰め込まれてしまっては意味がありません。オブジェクト指向では「モノ」に着目するよう教えられますが、それを十分消化しきれていない経験の浅いエンジニアがやってしまいがちなミスです。

　最後は、「制御動作で分解した」モデルを紹介しましょう（図5）。

　こちらは、制御という観点で整理されていますが、動かすノウハウそのものは各クラスの中に埋没してしまっています。つまり、制御の単位や方法が変われば、すべて作り直しになってしまうわけです。ハードウェアの“おまけ”的な位置づけでソフトウェアを開発してきたエンジニアがこのようなモデルを描いてしまいがちです。

対象を変わらない目的でとらえるそれが「使えるモデル」への第一歩

　それでは、組込みの分野で「使えるモデル図」を描くにはどうしたらいいでしょうか。まずは、制御装置があろうがなかろうが「変わらない目的」を捉えることが重要です。そして、その目的を徐々に手段レベルに落としていく階層化を行いましょう。

　例えば、自動販売機なら「商品販売」が目的です。プロセスは「お金をもらってその金額に見合った商品を渡す」と言い表すことができます。よく考えてみると、これはかつて駄菓子屋のおばちゃんが行っていた業務ですよね。今でこそ自動販売機がその実行主体となっていますが、プロセス自体は本質的に変化していないわけです。

　このように、具体的な実装形態にとらわれずに「変わらない目的」に着目すると、あとあと長く使えるモデルを作成できます。これは、製品ファミリーの多様化や派生化が進んで、その寿命が延びつつある組込みソフトウェアの分野では非常に重要なことです。

クレーンゲームをどうモデリングするか？

　お待たせしました。ここで冒頭の問題に戻りましょう。このようなクレーンゲームをモデル化するのでした。

　UMLモデリング技能認定試験 L3モデリング問題に出たサンプル問題ですから、ご記憶の方もあるかもしれません。この問題で新人の山田さんは以下のようなクラス図を描きました。このクラス図に難点があるとしたらそれはどこでしょうか。

　そう、もうお分かりですね。このモデルは、先ほど説明した「物理構成で分解したモデル」になっています。よくコンサルタントの間では“定規のようなクラスを見たら要注意”といっていますが、クレーンゲーム機のクラスはまさにそれです。使えるモデルにするためには、もう少しクレーンゲーム機クラスの中身を掘り下げていく必要がありそうです。

　一方、山田さんの先輩は図7のようなクラス図を作成しました。図2に比べて変わったところはどこでしょう？

　そうですね。クレーンゲーム機クラスが小さくなり、代わりに「●●機構」という名称のクラスが増えました。山田君のものよりもずっとわかりやすくなっている気がします。では、このクラス図を見れば、クレーンゲームの本質がわかるでしょうか？ まだ不十分な気もしますね。そこでこんなモデルを考えてみました。

　クレーンゲームの動きを目的ベースで整理すると、「行って、取って、戻って、放す」。それを目的レベルと手段レベルで整理したものが右上の図です。気をつけていただきたいのは、ゲームとしての言葉と制御のための言葉は違うということ。デバイスとルールを混在させないことがポイントです。

モデルをたくさん描いて問題を分けて整理する習慣を身につける

　ここまで、組込みソフトウェアにおけるモデリングについてお話してきましたが、使えるモデルを描くためのポイントをまとめると以下のようになるでしょう。

　もちろん、一朝一夕にできることではありません。これらを実践するためにはモデルをたくさん描いて慣れることが一番です。いきなり複雑なものに手を出すと混乱するので、小さく簡単なものから始めると良いでしょう。自動制御のない旧式の洗濯機や扇風機、黒電話などのモデル図を描いてみましょう。洗濯板やうちわ、糸電話でも構いません。

　ただし、モデル図を作成する際にはUML表記に従うことをお勧めします。きちんとした表現は、共有・再利用という点でも重要なことですからね。考えを整理するスキルはすぐには身につきませんが、千里の道も一歩から。今日からすぐに始め、根気よく続けていきましょう！