日本の組込みソフトの作り方の特徴

今回は10万行以下で小中規模の日本の組込みソフトの作り方の特徴について考えてみたい。

【日本のすり合わせ開発の特徴】

－前提となる環境－

• 開発者の入れ替わりがほとんどない。
• 開発者が商品企画から保守にまで関わる。
• 同じ市場に同じような商品を投入し続ける。
  

日本の組込みソフトウェア開発では開発者の入れ替わりがほとんどない、同じ系列の商品開発をだいたい同じメンバーでシリーズに何機種も作る。そして開発の規模が小さいと商品企画や保守に対してももソフトウェア開発エンジニアが深く関わる。同じ市場に同じような商品を投入し続けるので、自然と顧客要求がどんなものか、過去にどんなクレームが来たのか、どんな技術を使うとより顧客満足を高めることができるのかが分かってくる。

ビジネス系のソフトウェア開発では要求分析の重要性がクローズアップされているが、組込みソフトの世界では、わざわざ要求分析をしなくても、エンジニアの頭の中に要求がすり込まれていくという特徴がある。

組込みソフトの世界ではエンドユーザーが不特定多数のコンシューマーであることが多く、ユーザーニーズを把握することが難しい場合がある。サプライヤーにとってはソフトウェアを委託してくるクライアントが直接の要求の発信者となるが、このクライアントがエンドユーザーの要求を正確に把握しているとは限らない。

組込みソフトでは、リリースした製品が市場で売れたのかどうか、どんなクレームが上がっているのか、他社がどんな機能や性能を取り入れているのかといった情報が、要求の把握につながる。そうなると、「開発者の入れ替わりがほとんどない」「開発者が商品企画から保守にまで関わる」「同じ市場に同じような商品を投入し続ける」といった環境は組込みソフトの開発には有利な点が多い。

－改善の手順－

• まず、最初に類似商品のスペックを参考にして製品を開発し市場に投入する
• ユーザークレームを吸い上げ、これまでの機能性能を落とさないようにしながら、クレームを克服する
• クレーム対応と同様に他社製品にあり、自社製品にはない機能を追加する
  

－このアプローチの結果（傾向）－

• 市場に最適化された組込みソフトウェアができあがる
• すべてのユーザーの要求を取り入れるため機能がどんどん増える

ここで気をつけたいのは、このような付け足し付け足しのアプローチで解決できるソフトウェアの開発規模はソースコードが10万行以下のソフトウェアであり、数十万行、数百万行の規模のソフトウェアでは通常ではムリということだ。数十万行、数百万行の規模のソフトウェアでこのようなアプローチをしている開発チームでは、誰かが泣きを見ている。多くの場合泣きを見るのは下請けが孫請けのソフトハウスの技術者だろう。

－このアプローチのデメリット（メーカーサイド）－

• ソフトウェアが複雑になる
• 実装済みの機能や性能が劣化していないことを確認するのが大変
• 全体を把握できる技術者でなければ機能追加はできないし、不具合が発生したときの対応もできない
• ほとんど使われないどうでもいい機能のメインテナンスに多大な工数がかかる
• アーキテクチャデザインとしての強み（保守性、再利用性、変更容易性など）が消える（見えなくなる）
• ソフトウェアの開発効率が下がる
• その商品の強みがなんだか分からなくなる
• 自社のコアコンピタンスが相対的に目立たなくなる
  

機能を付け足しまくって、自社のコアコンピタンス（他社がまねできない技術）が相対的に目立たなくなるというのが、日本の企業に特徴的な現象だと感じる。ソフトウェアで性能を落とさずに機能を追加することができれば、材料費はアップしない。単価の安いエンジニアをこき使って開発費を抑えることができればソフトウェアが魔法の杖になるという考え方だ。

そして、営業員に「自社の商品が売れないのは他社がこんな機能を持っているからだ」と言われると、たいした機能でもないのに入れてしまう。日本のソフトウェアエンジニアはそれが出来てしまうから不幸になるのだとも言える。

そして、言われるがままに機能を追加しまくって性能を落としてしまったり、もともとあった自社の強みを目立たなくしてしまう。なんともはや、よかれと思ってやったことが逆効果という悲しい結末だ。

マーケティングをきちんとしなくてもクレームの克服や他社製品との機能比較だけで、商品開発していくとこういう事態におちいる。

－このアプローチのデメリット（ユーザーサイド）－

• 使わない機能がいっぱい付いていて使いこなせない
• 自分にとっての基本機能の使い方がわからない
• 商品コンセプトがよく分からない
• 不具合が起こるとソフトウェアアップデートを強いられる　

機能いっぱいでユーザーにもメリットはありそうだが、実はユーザーは機能を使いこなすことができず、ちっともいいことはない。

－デメリットを克服する施策－

要求の分析

• 市場要求・ユーザー要求の分析結果を可視化する
• 過去に起こった事故・クレームの分析と対策を蓄積しこれも可視化する
• 5年後、10年後を見据えた商品群のロードマップを作成する（商品ラインナップ、技術ロードマップ、規制ロードマップなど）
  

制約条件の分析

• 自社のコアコンピタンスが何かを明確にする
• 制約条件やトレードオフする項目（コスト、時間、性能、ビジネス目標など）を明確にする
  

実現手段の設計

• 要求と制約条件のトレードオフについてあたりを付ける
• システムを実現するためのソフトウェアアーキテクチャを考え、可視化する

アーキテクチャの変更

• 市場環境の変化によりアーキテクチャの変更が必要になったら、上記の要求分析から見直しをする。（安易に機能を付け足さない）