組込みソフト開発失敗の見分け方

大規模組込みソフト開発で開発が失敗する可能性が高いかどうかを見分ける方法を見つけた。

このブログでは何度となく、日本の組込みソフト開発は試行錯誤的だと書いてきたが、試行錯誤的なアプローチが必ず開発の失敗に結びつくわけではない。

要素技術の検討や、小規模なソフトウェアの開発では試行錯誤的なアプローチは必要だ。試行錯誤的アプローチが失敗するのは10万行を超える中規模以上のソフトウェア開発の場合だ。そして、ソフトウェア開発が失敗しそうかどうかを見分けるには、ソフトウェアプロジェクトリーダーかソフトウェアアーキテクトに相当するエンジニアにその製品に求められている要求は何か？と聞いて、さらっと答えられるかどうかで判断する。

試行錯誤的なアプローチで付け足し付け足しを重ねて組込みソフトを作っていくと、ソフトウェアの Specification は答えられても、Requirements は答えられなくなる。

ソフトウェアが巨大になればなるほど、ユーザーにとってはっきりいってどうでもいい機能、いや、すべてのユーザーがその商品に求める根源的な機能以外の機能がどんどん入ってくる。機能を付け足し続けていると、だんだん、ソフトウェアエンジニアは機能や性能にプライオリティを付けられなくなってくる。

この状態に陥ると、声の大きな一部のユーザやステークホルダや、独裁的なプロジェクトリーダに「重要だ」と言われた機能や性能の優先度が上がり、彼らの意見がころころ変わると、それに呼応するようにソフトウェアプロジェクトは右往左往する。

日本の組込みソフトエンジニアは、ソフトウェア開発の上流工程で仕様（Specification）は定義できても、要求（Requirements）を定義するのが下手だ。

規模の小さいソフトウェアでは 仕様（Specification）は要求（Requirements）とイコールになることが多いが規模が大きくなってくると、 仕様（Specification）と要求（Requirements）は必ずしもイコールではなくなってくる。

仕様（Specification）は開発者サイドの視点で決まるものだが、要求（Requirements）はユーザーサイドの視点で分析するものだ。大規模ソフトウェアには必ずしも強いユーザー要求（Requirements）ではない 仕様（Specification）が少なからず紛れ込んでくる。

大規模組込みソフトを完璧なまでに検証するには無限に時間がかかる。だから、ソフトウェアの検証、妥当性確認のステージでは、ユーザー要求（Requirements）が満たされているかどうかを最優先で確認するべきだ。 仕様（Specification）を満たしているかどうかを検証しているといくら時間があっても足りないが、ユーザー要求（Requirements）が満たされているかどうかを確認する時間は有限なはずだ。

仕様（Specification）と要求（Requirements）を区別できていない組込みソフトウェア開発プロジェクトは失敗する確率が高いと考えるのはそういった理由からだ。いまある組込みソフトの仕様をそぎ落としていって最後に残るもの（=Requirements）は何かと聞いてみて答えられないようなら、製品開発の途上であってもその製品に求められる要求は何かを今一度分析してみることをお勧めする。