まず原理や原則に立ち返る
世間には「ソフトウエア工学」が学問として存在する。先に述べた原理や原則が存在しているはずだという前提に立ち，誰でも同じ答えが出るようにすることを目指すものである。こうした学問の成果として各種の規格やモデルが完成した。例えばプロジェクト管理手法の基本体系である「PMBOK」注1），ソフトウエア開発体制の成熟度を測るモデルである「CMM」注2）などがある。
注1）
PMBOK（project management body of knowledge）は，米PMI（Project Management Institute）がまとめたプロジェクト管理の知識体系。「A Guide to the Project Management Body of Knowledge」として書籍化されている。
注2）
CMM（capability maturity model）は，ソフトウエア開発の進捗やその成果が文書などを用いてどのくらい目に見える形で管理されているかを5段階の水準で表現するためのモデルで，米Carnegie Mellon UniversityのSEI（Software Engineering Institute）が定めた。
この記事は，「日経エレクトロニクス」と「日経バイト」が刊行した別冊『組み込みソフトウエア2006---品質管理と開発技法の実践的改革A to Z』の掲載記事を抜粋したものです。別冊の詳細はこちらをご覧下さい。
これらは，エンタープライズ系のソフトウエア開発における原理・原則を議論し尽くした上で確立したものである。当時，組み込みソフトウエアの世界はこうした原理・原則を追求する水準に至っていなかった。今から考えると，懸命に議論していた場を共有できなかったのは，組み込みソフトウエアの技術者にとって非常に残念なことだったといえる。その代わりに，今後はPMBOKやCMMといった一般的な規格やモデルから原理や原則を推測し，それを組み込みソフトウエアの開発手法や開発プロセスに展開することが必要だろう。ここでは，プロジェクト管理，構成管理，不具合管理という3つの管理技術について詳しくみていく。
プロジェクトのリスクを分散
「なぜプロジェクト管理が必要なのか」--。組み込みソフトウエアの世界では，こうした声が至る所から聞こえる。日本版のプロジェクト管理体系である「P2M」は，プロジェクトの基本属性として「個別性」「有期性」「不確実性」の3つを挙げている。
プロジェクトの目的は個々に異なり，それぞれに始まりと終わりがある。そして，できるかできないか分からないという不確実性を持つ，という意味だ。プロジェクト管理の知識体系として最も有名なPMBOKも個別性と有期性を同様に挙げているほか，不確実性を「progressive elaboration（段階的な詳細化）」と表している。この不確実性があるからこそ，プロジェクト管理が必要になる。目的と期限を定めたプロジェクトを確実に遂行するための手段なのである。
プロジェクト管理の根底にあるのは，「リスクは分散すべき」という考え方である。プロジェクトを1つの塊としてとらえてしまうと，リスクが大きくなりすぎる。考えなければならない問題を複数に分けることによって，それぞれの問題に集中して解決しやすくするのである。
ソフトウエア開発においてリスクを分散するための手段の1つが，工程の分割である。ウオーターフォール・モデルの考え方は，ここから来ているといえよう。システムに関するリスクはシステム設計の工程で必ず解消することとし，そのリスクが解消されない限りは次の工程には移らないという考え方である。
工程の分散だけでは，リスクはなかなか小さくならない。そこで，製品を小分けにすることでリスクを小さくすることを狙うのが，プロジェクト管理でいう「WBS（work breakdown structure）」注3）である。WBSは，結果的にはプロジェクト全体の作業を細かく分解したものとなるが，本来の狙いは製品を複数の部品に分割することである。
注3）
WBS（work breakdown structure）は，プロジェクトの成果物を階層構造で分解することによってプロジェクト全体を細かい作業に分割する手法，またはそれによって作成した構成図のこと。プロジェクト管理で計画の立案に使う。
工程の分割と製品の分割により，部品と工程ごとの成果物が決まる。この成果物を考えたときに「これなら人間の頭で理解できるし，リスクも抑えられそうだ」と感じる状態まで分解できると，初めてプロジェクトの計画が成り立つようになる。経験からいえば，ソース・コードで1万～2万行程度の水準まで小さくしなければ，「管理できる」とは言い切れない。
ハードとの結合が最大の難関
組み込みソフトウエア開発の場合，システム設計が終わった段階でソフトウエアの開発とハードウエアの開発が分離する。その後，開発の後半に控える機能テストなどで，別々に開発を進めていたハードウエアとソフトウエアを結合することになる。複数のプロジェクトを分析したところ，この結合の段階にリスクのほとんどが集中していることが分かった。仕様の変更やインタフェースの変更，機能設計や構造設計のやり直しなどが起こっている。プログラミング作業も当然あり，それらとテストを並行して進めている。こうした状況では，とても「リスクを分散した」とはいえない。ハードウエアとソフトウエアの結合に伴うリスクを分散させて，それを管理していく必要がある。
まず，ハードウエアと結合する前に，少なくともソフトウエアに関するリスクをなくしておくことが重要だろう。単体テストまでの段階でソフトウエアの問題を完全に洗い出して，修正しておく。さらに，ハードウエアとのインタフェース仕様の変更を，ソフトウエアに確実に反映しておく。
それでも結合にリスクは伴う。そこで，段階的にハードウエアと結合させていくべきだ。例えば，最初にモジュールAとハードウエアを結合させ，それを確認する。問題がないことを確認できたら初めてモジュールBを結合する，といった手順である（図2）。
図2 ハードウエアとの結合時に問題が起こる
結合テストの後半や機能テストの前半などに行うハードウエアとの結合時に，不具合が見つかることが多い。結合する前にソフトウエア単体の問題は確実につぶしておくことや，結合時のリスクを軽減するために段階的に結合していくことなどが必要になる。
こうした手順は，プロジェクトを計画する段階で考えなければいけない。後から考えようとしても，もともとのモジュール分割の仕方に左右されるため，実現は難しい。ハードウエアとの結合手順を十分に検討し，それを実現できるWBSに分解しておくべきだ。WBSを作業の分割ではなく製品の分割で考えることが，ハードウエアとソフトウエアの段階的な結合にも役立つのである。
