組み込み開発の現場では、製品の高度化に伴ってコーディング量の増大や納期短縮といった厳しい現実にさらされている。ソフトウェア開発に新しい手法を導入しなければ、今後の組み込み開発は行き詰まってしまうだろう。本連載では、組み込み開発の従来手法で何が問題なのかを洗い出し、次なる一歩を踏み出す前提条件を明らかにする。

» 2005年09月28日 00時00分公開

[宮崎裕明　横河ディジタルコンピュータ，＠IT MONOist]

良くも悪くも、職人が支えてきた組み込み開発

　読者の多くは、組み込みソフトウェアの開発にかかわっていると思いますが、ご存じのとおり、今日の開発現場はさまざまな問題に直面しています。市場のニーズが急速に複雑化、多様化したことが大きな要因です。デジタル家電に代表されるように、開発案件数の急激な伸びに対して開発効率が追い付いていないというのが現状でしょう。その結果、いままで当たり前だった開発手法では立ち行かない状況になっています。

　当たり前だったことの1つが、「職人的」開発手法です。

　日本の製造業を支えてきたのは、日本文化ともいえる職人気質でした。日本のお家芸といわれる組み込みソフトウェア開発も、「職人技」が大きな役割を担ってきました。現場主義。たたき上げ。勘と経験。「良い仕事をしたい」という気質。これらには、日本製品の品質を支えてきたプラス面もありましたが、一方で開発ノウハウが属人的となり、職人技をチームで共有できないというデメリットもあります。現在は「その人にしか分からない」という属人性が、市場の変化に対応できない原因の1つとなっています。

　どんな現象が起こっているのか、いくつかのエピソードを紹介しましょう。

進ちょく管理のだまし絵

　プロジェクトの進ちょく確認は欠かさないという某社のソフトウェア開発部隊。過去の痛い経験の反省から、情報共有と進ちょくの把握は重要だとの考えに至り、プロジェクトごとの進ちょく会議を習慣化することにしました。リーダーから報告を受けるのは、部門長です。

部門長　「始めはいいんですよ。進ちょく率が10％、20％と順調に上がっていく。それが……」

90％に達した途端、そこで止まってしまい、それより上に進みません。

部門長　「実際にどうなのかと担当者に直接聞いてみると、『進んでいる、あと10％で終わる』というんですよ。『ただ、ちょっと難航しているだけだ』とか何とか」

しかし、計画書を確認してみると、実際とは懸け離れています。計画の変更は計画書には特に書かれていないし、最新の計画を確認できるものもありません。そもそも、計画は最初に立てるだけで、変更は計画書に反映していないようです。それなら、あの「90％」って、何？

部門長　「何をベースに90％といっているのか、根拠がありませんでした。皮膚感覚みたいなものでしょう」

恐れていたとおり、実際には大幅に遅れていることが発覚。結局、体力勝負で乗り切ったとか。

部門長　「でも、そのリーダーを責めるつもりはありませんよ。そういうやり方でやってきた、という事実ですから」

　プロジェクトの最初に計画は立てるが、その後の変更は計画書に反映していないという、よくあるケースです。計画に対して現時点でどれだけ進ちょくしているかが分からないのは、もちろん非常に危険なことです。それでも遅延が起こらなければよいのですが、ソフトウェア開発でまったく遅れがないということは、まずないといっていいでしょう。計画もあいまい、進ちょくの判断も個人任せ、これでは「綱渡り」のようなものです。

ノウハウは担当者の退職とともに消滅

　ソフトウェア要件が、以前に行ったプロジェクトと似ていることがあります。某家電メーカーの3人のプロジェクト。初めて新規プロジェクトを任された若手のリーダーは、過去のプロジェクトと類似していることに気が付きました。しかも、メンバーの1人は、半年前のそのプロジェクトにかかわっていたとか。リーダーは本人を呼び出して、聞いてみました。

スタッフ　「ああ、これだったら同じやり方でいけるはず。あのときの設計をベースにして、変更すればいいのではないかと思いますよ」

ところが調べていくうちに、リーダーの胸の内に「同じやり方」に対する疑問がわいてきました。設計書とソースコードが一致しないのです。最初の設計書は確かにありますが、どうやらプロジェクトの途中で発生した修正については、設計書が残っていないようです。

リーダー　「仕方がない、最初の設計をベースにするか」

しかし、それだけでは解決しませんでした。ソースコードは、最新のものしか残っていないというのです。

スタッフ　「納期が迫っていて、設計書を修正している時間もなかったし……、あれじゃ無理ですよ」

無理なのもごもっとも。あのときと「同じやり方」というリーダーのもくろみは、もろくも崩れ去りました。

スタッフ　「当時のリーダーに聞いてみたらどうですか。あ、彼、辞めたんですか」

　ちょっとした設計変更なら設計書の修正は後回しというのも、よくあることです。時間もないし、手を動かした方が早い場合も多いですから。それに開発メンバーなら設計は頭の中に入っているし、どこを修正すればいいのか予測がつきます。しかし、この場当たり的対応のツケは、後になって回ってきます。

　まず、このエピソードのように同じような要件があっても、前のプロジェクトを活用できないため、一向に効率が上がりません。加えて、履歴が残っていなければ、どこがうまくいったのか、どこが予想外だったのかも分からず、自らの成功や失敗を次のプロジェクトに生かすこともできません。とはいっても、変更履歴を残すための時間的余裕がないのも事実ですが。

　「○○さんに聞いてみて」というのは、開発現場ではよく聞くフレーズですが、その人が辞めてしまったら、過去の開発ノウハウは「闇の中」です。

　　　　　　 1|2|3 次のページへ