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

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

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

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

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

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

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

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

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

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

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

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

組込みソフトウェアに求められる安全対策

翔泳社さんが「組込みZine 」という情報サイトを立ち上げた。そちらに、『組込みソフトウェアに求められる安全対策』という記事を書いたので今回はそれを読んでいただきたい。この記事は第一回から第四回に分かれており、第一回目は「組込みソフトウェアに求められる安全対策」というテーマになっている。

さて、先日 ET2007の特別講演で、工学院大学 グローバルエンジニアリング学部 教授 畑村 洋太郎 氏の「危険学のすすめ」の講演を聴いた。

畑村先生はシンドラーのエレベータの事故の状況を現地までいって調べたそうで、その話を聞いてシンドラーのエレベータの事故でソフトウェアは関係していないかもしれないことが分かった。

事故現場のエレベータのブレーキは車のブレーキのように動いているものを止めるのではなく、止まっているときのその状態をホールドする役割だったらしい。そして、エレベータはかごと釣り合いをとるために釣り合い重りがつり下がっている。この重りの重さはエレベータの最大乗員の重量の1/2である。そうするとエレベータが静止しているときにホールドするブレーキが摩耗して抑えられないときに、乗員が一人しかいないと釣り合い重りの方が重いためにゆっくりとかごが上昇する。当時、事故にあった高校生は自転車に乗ったままだったため、自転車が半分エレベータから出たところでかごが上に上がってしまい釣り合い重りの重みで体が長時間圧迫されてしまったというのだ。

こうなると、ソフトウェアは内部ではかごが止まっていると認識しているので為す術がない。畑村先生の話が事実ならば、ブレーキの摩耗はエレベータシステムにとって非常に大きいリスクとなる。点検が十分でなければどのエレベータも危ないということになってしまう。

このリスクに対する安全対策はいろいろあるが、ソフトウェアでなんとかしようと思ったら「目」となるセンサーがいる。エレベータが物理的に動いているかどうかを検出するセンサを持っていれば、CPUが認識するかごの状態と実際のかごの状態に差異がないかどうか判定できる。

なにはともあれ、エレベータのブレーキの摩耗という一次故障でかごが動いてしまうという事故を起こしてしまうのは、システムとしての安全性が低いと言わざるを得ないだろう。実際にはそんなに簡単な原因ではなく複合要因で起きた事故なのかもしれないが、事故が起きた原因を調査した結果をオープンにしてもらわなければ事故の再発防止は進まない。

このことはソフトウェアの不具合についても同じことが言える。お客さんに迷惑をかけるような事故を起こしたら、それが起きた原因を追及して再発防止の対策を立てることが重要だ。ソフトウェアの場合、たったひとこと「バグ」とか個人のミスといった原因にされやすいが、そうではなく、開発工程のどこでどんな施策をとれば同じような問題を防止できるのかといった目で見ることが大切である。
　

「理想なき現実」と「現実なき理想」・・・どちらも役に立たない

「理想なき現実」と「現実なき理想」・・・どちらも役に立たない。このことばは、最近メールを交換させてもらっている、ジョイント・ノア の国広卓生さんのことばだ。まだ、実際にお会いしたことはないのだが、組込みソフト開発での苦労と実績をたっぷり積まれているとあってことばの意味が深い。

【国広卓生さんの文章から引用】

・理想なき現実・・・つまり、ソフトウエアとは「工学」である、と言う観点を全く無視してひたすら「納期」「コスト」「ビジネス」と現実路線を突っ走る考え方。

「ものづくり」に対して理念も思想もなく、単に政治的な力学だけでプロジェクトを駆動させる世界。この世界が末期的局面を迎えると、バグは「見つけるもの」ではなく「隠すもの」になります。

・現実なき理想・・・・どこかの本の受け売りや、海外から仕入れた新しい技術、あるいは教条主義的なルールの遵守で、理想だけを追いかける考え方。

　実務をしない人間が、プロセスを構築すると必ず、このタイプになります。UMLとか、アジャイル開発と言った名前をまるで呪文のように唱える人々。その結果、訳の分からぬ仕様書を作ってみたり、本業よりも報告書作成の時間が長かったり、テストの中味よりも、テスト成績表の紙の厚さが問題となったり・・・
　
本来、プロセスや手法は「手段」ですが、これが目的化してしまう現象。肝心の成果物（製品）の品質が上がるどころか、もっとひどくなります。「決めたことを守る」のは大切ですが、「守れないことを決めている」ことに歯止めがない世界

【引用終わり 】

ひたすら「納期」「コスト」「ビジネス」と現実路線を突っ走る「理想なき現実」は、当事者達は夢中なので分からないかもしれないが、外側から客観的に見る、もしくは、嵐が去った後に冷静に振り返るとむなしいものだ。「理想なき現実」路線で時を過ごしてしまうと残るものがない。ただ忙しかった日々が残る。キャリアパスとしてのステップにならないから、技術リーダーにもプロジェクトマネージャにもなれない。

あえて言えば、業務ドメインの知識だけが蓄積されるのだが、「理想なき現実」からは効率化やカイゼンは生み出されないので、何回も何回も非効率な試行錯誤のアプローチを繰り返すことになる。業務ドメインの知識が豊富というだけで、プロジェクトマネージャやプロダクトマネージャになった管理者は自らの力で効率化やカイゼンを成し遂げることは難しい。だから、理想を掲げて現実に実行しようとする者をじゃましないでくれればまだいい。そのような行動が自分の成功体験の辞書にはないという理由だけで否定しまうことも少なくないので、「理想なき現実」のアプローチしか経験していないものが管理職になってしまうと問題は残る。

また、「現実なき理想」は別な意味で問題がある。国広さんが言うように「守れないことを決めている」ことに歯止めがない。別な言い方をすれば実現できないこと、実施しようとしてもメリットがないことを洗脳されたかのようにヤレと繰り返す。

では、我々はどうすればいいのか？　答えはひとつ、理想を理解した上で、何とか現実に展開する努力をするしかない。

ただ、理想を理解するというのはそんなに簡単なことではない。現実を繰り返す間に、問題点を分析しどうすればこの問題は解決できるのかを考える習慣がないと、理想はそう簡単には理解できない。それは、おそらく理想となるソフトウェア工学を体系化した先人が現実に問題にぶち当たりながら解決方法を構築していったからだろう。問題に正面から当たることもなく、すでに体系化されてしまった理想だけを理解しようとするのは難しいものだ。

別な言い方をすれば失敗の体験、失敗の引き出しと、解決の体験、解決の引き出しをいっぱい持っている技術者は、理想も理解できるし、理想を現実に展開することもできる。

失敗と解決の引き出しを増やすためには、何しろ「考える」ことが必要だ。今日作ったプログラムは本当にこれでいいのか、もっとエレガントにすることはできないか「考える」くせを付けることが大切だ。若い技術者は引き出しが増えるまでは、寝ても覚めても、もっともっとよいソフトウェアにするにはどうすればよいのか「考える」必要がある。

これと真逆の行為は、答えを探して見つかったと感じた時点で考えることをやめてしまうことだ。

時間はかかってもいいから、もっと一つのテーマに対して考えることが大事なのに、学生時代に決められた時間内に答えを見つけることばっかり訓練してきた若者は時間をかけて「考える」ことが苦手なように見える。

若いエンジニアには「理想なき現実」や「現実なき理想」にならないように、失敗と解決の引き出しを増やすべく今抱えている問題について時間をかけて深く考える習慣をつけて欲しいと思う。