職人芸、あるいはブラックボックスの悲劇

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

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

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

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

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

進ちょく管理のだまし絵

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

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

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

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

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

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

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