「対象の理解」にどれだけの時間が割かれているのか

筆者はソフトウェア・エンジニアではないが、マーケティングとしてコンピュータ・システムやCORBA処理系の開発のすぐ傍らでプロジェクトの帰趨を一喜一憂しながら過ごしたことがある。以下の話は、その経験からくる傍目八目的な部分がかなりに含まれているはずだ。それ故の舌足らずさがあれば、ご容赦願いたい。

さて、組込みソフトウェア開発プロセスの話である。

コンピュータ言語系(とりあえず言語仕様やコンパイラなどを含むものとして考える)の文法的な厳密性が極めて高いレベルで実現されたとしても、それだけでは、作品であるシステムの「質」の高さや機能安全性の高さが実現できるものとは言えないはずだ。記述されるべき対象の理解が、どう考えてもみても欠かせないだろう。それも、対象そのものと、対象が置かれるべき環境とか文脈とかについての理解だろう。

情報システム系ならば、要件定義を行う過程でソフトウェア・エンジニアが対象とそれが意味付けられるコンテキストの理解を得られる機会が普通だと思うが、組込みシステム系の場合は、突然、仕様が降ってくる事も多いようだ。システムの品質を確保したいならば、組込みソフトウェアの開発プロセスに「対象の理解」を行う段階を明示しておくべきだろう。マネージメントにとっては簡単なことのはずだ。要件定義とアーキテクチャ設計にソフトウェア部門あるいはソフトウェア・エンジニアを定常的に参加させる、と宣言すれば第一歩は踏み出せるはずだ。ただし、組込みソフトウェアの場合、理解するべき対象に、言語系そのものも含まれることを理解しておくべきだろう。情報システム系よりも負担が大きいのである。筆者は、日本語と英語で厳密な論文を書くことなどまずできない。それに近いことをやってのける彼らは、それ相応に遇されるべきだとつくづく思っている。