設計していますか？

簡単な要求仕様を与えられて「さぁ，設計図を書いてみましょう」と言われたら，みなさんは何を書きますか？ いきなり手が止まる人も多いと思います。そしてフローチャートのような設計図を書く人を多く見かけます。

しかし，それでは設計を表現できたとはいえません。たとえばソースコードが10万行の組込み機器があるとします。10万行のソースコードをA4サイズの用紙に印刷すると約1,500ページになります。もちろん，その情報だけでは設計の意図は見えてきません（図A⁠）⁠。

またフローチャートは処理の流れを表現するものであり，ソースコードとほぼ同等の内容を図的に表現しているに過ぎないことから，同じく1,500ページを超える資料となってしまいます。フローチャートからも設計意図は見えてこないでしょう。

設計とは「複雑なものを，管理可能な単位に分割し，それを構造的に表現する」こと。すなわち分割統治です。組込みソフトウェアの設計とは，関数単位や責務単位などに分解して表現することです。関数単位に分割する方法が構造化手法で，責務単位に分割する方法がオブジェクト指向です。構造化手法では，モジュールの構造を表現するモジュール構造図を描くことになりますが，こちらはA4サイズで約50ページとなります。オブジェクト指向では責務をクラスで表現しますが，A4で約10ページとなります（いずれも単純計算⁠）⁠。

いかがでしょうか，1,500ページのソースコードが50ページあるいは10ページで表現できることになります。1,500ページでは担当者はその量に圧倒されてしまいますし，管理者は内部を見ようともしないでしょう。しかし，50ページ程度であれば，それを管理して，戦略的な開発に結びつけることも可能となります。今日のようにソースコードが100万行を越えるものも珍しくない状況下では，このような，設計を抽象化し図的表現する表記法が必須です。その図的表現の世界標準となるものがUMLです。これからのソフトウェアエンジニアは，UMLを駆使し，設計を行うことが重要になります。そして場合によっては，世界中のエンジニアとのコラボレーションを実現することが求められます。それらの経験を積むことでソフトウェアアーキテクトとして活躍する世界が開けるはずです。

エンジニアリングしていますか？

組込みソフトウェアエンジニアは，日夜，自分の作ったソフトウェアと格闘しているのではないでしょうか。仕様変更に振り回されたり，障害対応で忙殺されたりしている姿が目に浮かんでしまいます。しかし，それらの作業に追われてしまって，学習する時間を失っていませんか？ また，それらの作業の理論的な裏づけを理解していますか？ ということが気になります。

実践と理論を結びつけることも大切です。理論なき実践では，何度繰り返しても，実力アップは見込めないでしょう。そして，理論的な知識不足が，さらに多忙な作業を作り出してしまう，という悪循環に陥ってしまいます。

組込みソフトウェアエンジニアに今求められることは，「⁠エンジニアリング」をすることです。たとえば，モジュール分割のよし悪しの尺度である「コヒージョン」（⁠注A）を知っていることが大切です。セミナーなどで，コヒージョンを知っている人に挙手をしてもらうと，1割程度しか手が上がりません。

そして，リアルタイム＆組込みの分野でのリアルタイム性の保障やスケジューリング，そして，パフォーマンスの最適化なども，今までの経験則を理論と結びつけることが大切です。コヒージョンというモジュール分割の尺度，レートモノトニックというスケジューリング理論などを理解することで，現状のソフトウェアに筋を通すことができます。そして，次の開発では，それらの理論を活かして，より速く，よりよいものを設計することが可能となるでしょう。

設計すること，エンジニアリングの理論に基づくこと，ほかの分野では当たり前のことが，今の組込みソフトウェア開発の分野では欠如しています。設計図がないエンジニアリングという特殊な世界は，ソフトウェアだけなのかもしれません。これを解決することで，より健全で楽しい産業になるはずです。日本の国際競争優位性は，組込み機器分野であると叫ばれている今こそエンジニアにとって必要な技術なのです。

そのような労働集約的な労働スタイルから脱却し，知的で高度なソフトウェアエンジニアやソフトウェアアーキテクトを目指す基礎となる知識が「OCRES」です。