日本の組込みソフトウェア開発はこうすればよい

あるセミナーで、アメリカの有名企業が採用するような学生は、学生時代に『実践ソフトウェアエンジニアリング-ソフトウェアプロフェッショナルのための基本知識』を教科書として学んでいるという話を聞いた。『実践ソフトウェアエンジニアリング-ソフトウェアプロフェッショナルのための基本知識』は650ページの分厚い本で日本語版は7980円である。

セミナーの講師曰く、学生もこの本をすべて頭の中にたたき込んでいるのではなく、どこに何が書いてあるのかを知っており、必要なときに参照するのだそうだ。

そういえば、ソフトウェア系の海外規格を見ているとソフトウェアの開発計画を立てる際に、どんな方法論(Methodology)を使うのか書く欄があったりする。日本の組込みソフトウェア開発を始める前に、どんな方法論を使うのか？と聞かれて即答できるプロジェクトはいくつあるのだろうか。

欧米の企業がソフトウェアを開発する際にソフトウェア工学の知識・スキルを持ったものを採用し、基本的なソフトウェア開発の方法論を知っているという前提なら、ソフトウェア開発計画を立てる際にどんな方法論を使うのかという質問をするのは理解できる。以前書いた「インドのソフト会社」のときも同じように、ソフトウェアの開発者は基本的なソフトウェア工学の知識を身につけているというようなことを言っていた。

日本でもソフトウェアを開発する技術者は『実践ソフトウェアエンジニアリング-ソフトウェアプロフェッショナルのための基本知識』を熟読しろとは言わないが、ソフトウェア工学にはどんな方法論があるのかくらいは知っておいた方がよいのだろう。

でも、今回の記事のテーマは日本のすべてのソフトウェアエンジニアがソフトウェア工学の知識を身につける必要があるという主張を否定するところから始まる。

アメリカの一流企業では学生時代からソフトウェア工学の知識を見つけているという話を聞いたときに、欧米のソフトウェアエンジニアはソフトウェア工学の基礎知識くらいは誰もが身につけている、日本の技術者は不勉強で、その不勉強さがソフトウェア品質の問題を引き起こしていると言われているように感じた。

確かにそういう面もあるだろう。しかし、そこで疑問に思ったのは、「それでは、なぜ、日本の組込み機器のソフトウェア品質は平均的にどれも高いのか？」という点だ。欧米の組込み機器を使う機会はそれほど多くないが、一般的な評価として日本の組込みソフトの品質は高く、欧米や他のアジア諸国で作られた組込みソフトの品質には当たり外れがあるということをよく聞く。

このことについて、自分は何年も「なぜだろう」と考え続けている。何となく確信が膨らんでいるのは、そこには国民性や技術者の気質が関係しており、そこに差がある以上、欧米で効果を上げているソフトウェア工学の方法論を日本にそのまま適用しても同じような効果が得られるとは限らないと考えている。

欧米と日本で何が違うのか、どんな気質の違いがあるのか、何をどうテーラリングすれば欧米で成功したといわれるソフトウェア工学が日本の組込みソフトウェア開発にも役に立つのか？

ここにひとつの仮説がある。日本のエンジニアは自分の失敗、ミスを恥と感じる。だから、自分が作ったソフトウェアに問題があると分かると、それを恥と感じすぐに直す。これは、個人だけの話ではなく、仲間が起こした問題であってもそれをプロジェクトの問題であると感じ、プロジェクトや製品の信頼を回復するために寝食を忘れて問題の解決にあたる。

また、日本の消費者は非常に品質にうるさい。品質が悪い状態を決して許さない。食品の原材料の表記の順番が間違っていただけで自主回収する。消費者が製品の品質に対して敏感であり、問題が発覚するとその問題を自分やプロジェクトの恥と考え、自分の都合は横に置いてユーザーの信頼を回復しようとする。

この性質は日本特有のものであり、欧米や他のアジア諸国にはないと仮定する。すると、この性質が組込みソフトの品質を高めるケースと、逆に品質を低下させるケースが見えてくる。

－日本に特有の条件が組込みソフトの品質を高めるケース－

ソフトウェアの規模が小さい（10万行以下）の場合。ソフトウェア工学や方法論を使わずに試行錯誤で作ったとしても、問題が発覚した後の修正のスピードが速く、すべてのエンジニアがどんなに残業しても何とか納期と品質を守ろうとするため、リリースしたソフトウェアの品質が高い。また、フィールドで問題が起こってもすぐに修正し対応を終えるため、リリースしてから時間が経過するほど安定性が増す。

おそらく日本の組込みソフトはほとんどがこのパターンだったのだと思う。問題が発生してもすぐに直すので問題は大きくならず、対応を早くすることでエンドユーザーの信頼も上がる。

このような10万行以下のソフトウェア規模の場合、冒頭で紹介した『実践ソフトウェアエンジニアリング-ソフトウェアプロフェッショナルのための基本知識』を読まなくても、何か起こったらすぐ直せば問題を解決できるのだ。ただ、「修正が別の不具合を生む」危険性はある。問題が起こるとすぐに直してしまうので、別の不具合を引き起こしてしまう可能性が高い。

だから、日本の組込みソフト開発では、ソフトウェア構成管理や変更管理、レグレッションテストがソフトウェア品質の劣化防止に役立つ。これらの方法論はもちろん、基本的なソフトウェア工学の教科書に載っているが、ソフトウェア設計の方法論を使わなくてもソフトウェア品質が保つには、問題が発生したときの対応のスピードが早くして、かつ、修正が他の問題を起こさないことに注力を注ぐとよい。

でも、こんなソフトウェアの作り方はソフトウェア工学の基礎を学んできた人にとっては、理解しがたいと思う。試行錯誤で作って問題が発生したらさっさと直す。こんなのソフトウェアエンジニアリングじゃないといわれれば「その通り」というしかない。でも、できあがった組込みソフト製品の品質を見れば、そんな作り方したソフトウェア製品の方が、機能や性能が最適化され品質もよかったりする。

－日本に特有の条件が組込みソフトの品質を低下させるケース－

ソフトウェアプロジェクトやソフトウェア自体の規模が30人、30万行を越えてくると、発生した不具合が複数の人間のサブシステム、モジュールにまたがることが多くなる。一人のエンジニアでは問題の解決を帰結できなくなる。こうなるととたんに日本特有のエンジニア気質はソフトウェア品質の劣化防止に対して機能しなくなる。自分のパートの不具合はすぐに直すが、他人のパートの不具合かもしれない場合、積極的にその指摘をしない。たとえ、他人のパートの不具合であることという確信があっても、その技術者に「恥をかかせるかもしれない」という心理がはたらくからだ。

また、ソフトウェアも30万行を越えてくると、ソフトウェアシステムの設計図がないとさすがに一人のアーキテクトではシステム全体を把握しきれない。問題を起こったときにどこを調べればよいのか分からないこともある。

30人、30万行を超えるソフトウェアプロジェクト、ソフトウェアシステムでは、問題が起こったらすぐに直すというアプローチだけでは、ソフトウェアの品質を保つことができない。もし、かろうじてソフトウェア品質を保てているのなら、それは何かあったらすぐ直すというアプローチを徹夜してでも繰り返して納期に間に間に合わせているだけだ。単純な修正アプローチを時間をかけ繰り返すことで、力ずくで収束させようとしている。

ちなみに、この作り方はソフトウェアを付け足し続ける、ソフトウェアを修正し続けるため、機能ばかりたくさんあってコンセプトが不明確な商品になることが多い。最初からソフトウェアシステムのコンセプトを明確にして着手していないのだから、ソフトウェアの付け足しでシステムの規模が大きくなれば、商品コンセプトがぼけてくるのは当たり前といえば当たり前だ。

－じゃあ、どうすればいい？－

今後、日本の組込みソフトウェア開発は30人、30万行を超えるプロジェクトが多くなるだろう。日本人のエンジニア全員が品質に対する意識が高く、問題が起こったときに素早く対応しする特長を活かしながら、ソフトウェアの大規模、複雑化に対応するにはどうすればいいか、ここでアイディアを提言しておこうと思う。

【日本の組込みソフトウェア開発はこうすればよい】

まず、ソフトウェア開発のプロジェクトをグループ分けし、ひとつのグループが10万行以下になるようにする。そして、それぞれのグループの開発ソフトウェアの責務を明確にする。

そのこころは、問題が発覚したときの修正のスピードが早いことが日本のエンジニアの特長なら、問題が発覚したときにどのサブシステムの問題か一発で分かるような機能分割をしておき、そのサブシステムを作ったグループをすぐに特定して問題の解決に当たらせるためだ。少人数のグループで他のサブシステムにまたがった不具合でなければ修正のスピードは速いはずだ。

次に、システムをサブシステムに分割するときに、その商品の価値が凝縮されている部分をくくり出し、このサブシステムを開発、保守するメンバには優秀な技術者をアサインする。

この方法で注意しなければいけないのは、サブシステムとサブシステムのインタフェースの明確化と、サブシステム間のインタフェースは簡単に修正してはいけないという点だ。日本人の特長である、問題が発覚したらすぐに修正するという習性には、修正していいところと簡単に修正してはいけないところの明確な区別がない場合が多い。サブシステム間のインタフェースまで簡単に修正してしまったら、大規模システムを責務のあるサブシステムに分けた意味がない。サブシステム間のインタフェースの修正には、その修正の妥当性を確認する工程を設け、簡単には実施できないようにする必要がある。

また、システムをサブシステムに分割する役目は優秀なアーキテクトが行うとして、きれいにサブシステムが責務に分かれたとしても、インターフェースのオーバーヘッドが大きくなって製品に求められる性能要件が満たせなくなる危険性はある。

この問題の解決方法は、『組込みプレス vol.8 』の特集1 Part 2 の再利用資産の抽出法を読んでいただきたい。すでに、製品に求められている市場要求を分析し、すでに実現できているソフトウェアシステムの構造をマッピングして、製品の価値が凝縮されている重要なソフトウェア資産を抽出する方法を解説している。

「じゃあ、どうすればいい」のエッセンスをまとめると次のようになる。

1. 製品に求められる要求品質とすでに実現しているソフトウェアシステムの構造を分析して、ソフトウェア再利用資産を抽出しておく。
2. 抽出したソフトウェア再利用資産をベースに、システムをサブシステムに分割し、ひとつのサブシステムの規模が10万行以下になるようにする。
3. 10万行以下のサブシステムに対して、特定の技術者をアサインする。
4. サブシステムの重要度に応じて、優秀な技術者をアサインする。
5. システムのアーキテクチャとサブシステム間のインタフェースは簡単に変更してはいけないことを、プロジェクトメンバ全員に伝える。

上記のアプローチで欧米のソフトウェア開発のメソッドにない点は、すでにあるソフトウェアシステムのアーキテクチャを分析するというリバースエンジニアリングが先頭にある点と、サブシステムを分割するだけでなく、そのサブシステムを開発するエンジニアも固定すべしと主張している点だ。

このアプローチでは、ソフトウェア工学を熟知している必要があるのは、極端に言えばアーキテクトだけでよい。ただ、アーキテクトは一般的なソフトウェア工学だけでなく、市場要求の内容や製品に求められる機能要件と性能要件も熟知している必要がある。

したがって、今、日本に求められるのはその業務ドメイン、製品群を取り巻く環境、ハードソフト合わせた要求の実現手段を知っているアーキテクトを育て、そのアーキテクトにシステムのアーキテクチャとサブシステムの分割を行わせ、サブシステムを担当する技術者を特定してしまうことだ。

以前、トヨタのソフト戦略の記事を書いたときにECUの統合戦略が危ない方向に向かっているのではないかと思ったのは今思い返せば、統合すればするほどサブシステムと技術者がセットになって他のサブシステムと切れているという一体感が薄れることが、日本の技術者の気質に合っていないのではないかと感じたからだと思う。

P.S.

図らずも、一般のエンジニアはソフトウェア工学を学ばなくてもよいような論調になってしまったが、決してそう主張したいのではない。自分自身 SESSAMEやEEBOFに参加して2003年頃から相当ソフトウェア工学を勉強したつもりだ。でも、2003年以前15年以上に渡って、自分の業務ドメインに関する領域でどんなやり方が最もふさわしいか考え続けたことが、最適なソフトウェアアーキテクチャの構築に貢献したように思う。

この記事で言いたいのは、もしも、現在組込みソフトウェア開発の品質で大きな問題が発生しているのなら、日本の技術者の特性をよく考えて、いま上手くいっているところがどこなのかをおさえた上で、欧米で培われたソフトウェア工学の方法論を適用するべきだということである。日本の技術者の特性を考えれば、まずはボトムアップの視点で役に立ちそうなものに着目し、その一方で今回の記事に書いたようなトップダウンで改善すべき点を探るのが効果的だと思うということである。