発生した問題

 総合電機メーカのC社では,情報家電機器に搭載するSoC(system on a chip)向けソフトウエア開発工数が大幅に超過してしまいました。ソフトウエア開発リーダーのA君は,てんてこまいです。

 開発工数が超過した主な理由は次の2つでした。

(1)デバッグが際限なく続きました。例えば,データ・タイプやデータ構造(配列やポインタ型など)が大幅に食い違っていました。各種デバイスを制御するSoC上の入出力ポートなども,なかなか決定されず,決まっても不完全でした。
(2)最初のエンジニアリンク・サンプル(ファーストES)が出来上がったときに,計画なら電子回路設計者が評価すべき制御仕様を,その設計者が忙しいという理由で,ソフトウエア技術者が担当することになりました。あとで分かったのですが,購入デバイスの制御手順と断片的に記載されたハードウエア制御仕様手順が違っているなど,一貫性のある制御仕様ではありませんでした。

 2回修正したサードESが出来上がった時点で,SoC開発費も製品開発スケジュールも限界に達しました。そのため,ハードウエアのタイミングや制御順序に関する問題,性能不足についてもソフトウエアで解決することになりました。

原因と対策

 (1)の原因は,組み込みソフトウエアを何世代も流用するうちに,基本設計書や詳細設計書,変更記録,欠陥修正記録がなくなったことです。ソフトウエア単体では新しい機種でも動かせましたが,関数やモジュールの目的,制約事項などが詳しく分かりませんでした。このため,組み込み機器のハードウエアとの現物合わせでしか,プログラム・コードをデバッグできませんでした。そもそも基本設計を行っておらず,詳細設計もずさんでした。

 (2)の原因は,全体の統括責任者がいなかったことです。SoCチップのエンジニアリング・サンプルの評価用ソフトウエアを開発するリーダーは,電子回路設計の経験がなかったソフトウエア技術者でした。ベテランの電子回路設計者は,SoCの契約書をまとめるだけで,一貫性のある妥当な要求仕様書もその内部構成を示すアーキテクチャ設計書も作成していませんでした。部下に任せっきりだったのです。その上,SoC半導体ベンダーとのデザイン・レビューも形式的に実施しただけでした。不完全で食い違いの散在しているメモのような制御仕様をもとに,SoCのESの評価用ソフトウエアをバラバラにコーディングしてチップ上で評価する――こんなずさんなもので,品質の高いチップができるはずはありません。

 A君は,先輩のプログラムを分析して文書化しなかったことを後悔しました。しかし,A君の責任ばかりではありません。つまりプログラムの基になるシステム要求仕様書がなく,組み込みソフトウエアの対象となるSoCチップの外部仕様すら不完全なのに,上司がその問題に気付いていないのです。ハードウエアとソフトウエアの両方を統括するM部長は,職務を果たしていませんでした。システム全体のプロジェクト計画書を作成して,プロジェクトのキックオフを行うべきでしたが,それも実施していませんでした。

 そこで事業部長は,Q氏を火消しに呼びました。Q氏は,まずは当面の問題を解決するために,応急措置として既存機種のプログラムのリバース・エンジニアリング(解析)とシステム要求仕様書の暫定版作成を自ら行いました。これは,最大のバグ検出対策でした。すなわち,既存機種の主要な機能と,今回の新機種に関する要求仕様,その実現方法が明確になったからです。

 さらに欠陥を効果的に摘出して,修正する基準にもなりました。ユーザーが頻繁に使用する操作手順というようなシステム要求事項に対する欠陥を見つけると,それに関連する入出力デバイスの選択・切り替え,リモコン操作コマンド処理などの欠陥を一網打尽に検出できるようになったからです。この企業は,暫定的ではありますが,SoCの標準プロセスを確立することにしました(図12-1)。

技術者必修の基本

 実は図12-1は完全ではありません。本来は,システム要求仕様を明確にして,システム方式設計(アーキテクチャ設計)をきっちり行うことが重要です。そうすれば(1)や(2)のようなトラブルはなくなります。

 ただ,重要と分かっていても,従来の慣習や部門間の壁といった管理上あるいは組織上の理由により,システム方式設計ができないこともよくあります。担当者だけでは解決できないことが多く,今回のようなトラブルが起こってしまいます。事業責任者が,ソフトウエアとハードウエアの開発リーダーと全体のマネジャーの役割,責務,範囲,協働作業などを明確にした組織を確立して,全体のプロジェクト計画を立てることも必要です。そうすればトラブルを防ぐことができます。

 単にソフトウエアとハードウエアの開発リーダー同士が相談したり,統括責任者に上申する今までのやり方では無理が出てきます。現場だけでは解決しないことを,身にしみて感じている読者の方も多いでしょう。つまり,技術者一人で悩まずに,着実に仕事をこなしていく体制と手順が重要であることを知っておくべきです。

 また,今回の例でも分かるように,ハードウエアとソフトウエア技術者は,それぞれお互いの仕事を理解することが大切です。例えば,(a)その製品がユーザーにとってどのように活用されるのかというシステムの視点の共通認識,(b)ソフトウエア技術者はハードウエアの概略,ハードウエア技術者はソフトウエアの概略を知って,自分の設計したものがどのように稼働するのかを理解するといったことです。こうなれば,品質が悪く,納期が遅れて,コストが超過することを,人のせいにすることはなくなります。