とはいうものの，筆者らの開発対象で使用するCPUは16ビットのCISCだし，そのような組み込み向けのCPUでオブジェクト指向による開発に耐えられるようなコンパイラやデバッガ，ICEなどはまだまだ少ない．場合によっては，オブジェクト指向に対応したコンパイラが存在せず，非オブジェクト指向言語を使って実装するという考え方も現れている．

　では，そのような貧弱な環境の中で，苦労して組み込み型のソフトウェアをオブジェクト指向で開発する目的は何なのか？　筆者らの場合，開発担当者からボトムアップによる提案を行うことで，オブジェクト指向による開発を実施してきた．その原動力になったのは，現状の開発現場の状況を何とか改善しなければ，今後の開発に携わるすべてのプロジェクトがいわゆる“デス・マーチ・プロジェクト”^1） になる，つまり完了しないまま失敗してしまうような不安に襲われたためである．

　開発現場では，ハードウェア開発とソフトウェア開発のライフサイクルの不一致によるソフトウェア開発へのしわ寄せが増すばかりである．

　そのうえ，コスト要求からハードウェアでできることでもソフトウェアで実装する，要求される機能自体の量が増す，要求される機能自体の複雑度が増す，機能を達成するための新規技術が加わる，ビジネスチャンスを逃さないために開発期間がどんどん短くなる，36協定（労働基準法36条）などの労働規約により開発にかけられる工数に限りがある，不景気の影響で開発に対する投資が抑えられるなど，さまざまな問題が起こってくる．「このままでは，われわれ組み込み型ソフトウェア開発担当者の寿命が縮まってしまう」という危機感が積もってきていた．

　また，職場にいる時間が今の生活の何パーセントになるのかを考慮し，「同じ働くなら楽しく働きたい」という前向きな気持ちや，良いソフトウェアを開発するための技術に関する興味がなくなっている開発現場の意欲を高めるためのきっかけにならないだろうかという漠然とした欲求も持ち合わせていた．

　こういった危機感に対する自衛手段として出した答えは，「ソフトウェアの開発効率（生産性）を抜本的に改善し，今後の機能開発に耐えられるようにする」ということ以外に手がないのではなかろうかということだった（図2）．

〔図2〕 ソフトウェア開発の生産性を上げるしかない

　しかも，ソフトウェア構造は比較的単純で，再利用による対応が楽にできるような工夫をしてきた．その工夫があってこその再利用であり，少ない工数で同時に進行する多くのプロダクトに対応することができていた．

　それに対し，今日の状況はどうだろうか．機能が増えてきたこと，それにともない開発担当者が増えてきたことで担当者の能力の多様化が起こり，ソフトウェアの再利用性が損なわれるとともに，複数の担当者によるミスコミュニケーションが起こり，その結果は最終成果物である実行ファイルの欠陥を増大させてくれることになる．

　なんと，人的投資をしているにも関わらずソフトウェア品質の維持すらできなくなってしまったのである．

Copyright 2001 杉浦 英樹