◆ 現状の課題
スマートフォンの開発マネジメント支援を行った経験から、従来の製品開発のやり方を踏襲した改善では問題の根本解決は難しいと強く感じました。スマートフォンは、ビジネス形態、市場、競合、部品などの製品開発を取り巻く環境が激変した特別な製品と思えるかもしれませんが、ここで起こっていることはいずれも、多くのセットメーカーが直面する課題だと思います。今回は組み込みソフトウェアを中心に、スマートフォン開発で起こったことを事例として解説します。
1. これまでの組み込みソフト開発
多くの組み込みソフトの開発現場では、品質最優先の方針のもとで開発プロセスの整備と運用に力を入れてきました。QCやISOの影響と思われますが、開発プロセスは各社個別であるにもかかわらず、共通している特徴があります。たとえば、次のようなことです。
(1) 設計重視／設計書重視
開発上流での品質確保が重要なため設計書作成を徹底させる。
(2) レビュー重視
設計段階からレビューを徹底させることで上流からの品質を確保する。
(3) 工程ごとの品質ゲート重視
第三者が工程ごとの作業の正当性を確認して次の工程に移行する。
実際、これらの考え方や仕組みは、組み込みソフトの品質を高めてきました。いわゆる成功体験、成功事例ということができるでしょう。
2. 組み込みソフト開発を取り巻く新しい状況
スマートフォンでは、Android などのオープンソース・ソフトウェア（以下、OSS）の採用、Wi-Fi や NFC などの通信機能の高度化、各種機能部品の複雑化、そして、開発期間の大幅な短縮など様々な変化が起きています。とくにネットワーク機能は、携帯電話に限らず今後も様々な機器で重要になり、高度化、多様化していくのは避けられないと考えられます。さらに、その技術進展はとどまることなくよりスピードを増していくことでしょう。
一方、このようなネットワーク機能は開発現場にとっては大きな重荷であり、その負担を軽減するために Android などの外部ソフトを採用せざるを得なくなります。次の記事は、ネットワーク機能のように進化が早い技術に対してはOSSが有利であることを述べています。
【主役交代 ～ ITの未来はOSSが決める】
この記事自体は組み込みソフトの話ではありませんが、このようなネットワーク機能は組み込み製品にも徐々に採用されていくと思われます。また、OSS に限らず様々なデバイスドライバーや、他社ソフトを組み込みは増加する一方です。つまり、組み込みソフト開発は外部依存度が大幅に高くなっており、それがもっとも進んでいるのがスマートフォンだと言えます。
【高い外部依存度が引き起こす組み込みソフト開発の課題】
他社からの購入ソフトの採用は従来から行われていることで、課題も従来からの延長と考えることもできますが、次の2つは新しい課題ととらえて対応を考える必要があると思います。
(1) As-Isの幻想
Androidがスマートフォンに採用された当時は、Androidはそのまま使うことができるので（As-Isで大丈夫なので）、ソフト開発はとても楽なものになると判断し、そのような開発体制や開発計画を組んでいたメーカーは少なくありませんでした。しかし、他社との差別化や採用するデバイスの都合などの理由により、As-Isでは製品として成り立たず、Androidの内部まで手をつけることになってしまいました。その結果、予定していたようには開発は軽減できず、大幅な計画変更を余儀なくされました。さすがに、今のスマートフォンはAndroidを採用して数世代経っているので、As-Is幻想はなくなっていますが、これから新たに Androidを採用する計画がある場合には十分な検討が必要です。
(2) 開発プロセスの破綻
いまだ十分な対応ができていない、いや、問題を十分に把握できていないと思うのが開発プロセスの課題です。「これまでの組み込みソフト開発」で述べた従来の強みを活かすことができないのです。
早い技術進化に対応するのが OSS であり、Android 採用の大きなメリットのひとつはそこなのですが、反面、最新の Android は品質や完成度が安定するのが遅くなります。通常、リリース直後の最新バージョンの Android を採用することになると思いますが、製品開発の間は Android の品質や機能は安定せず、その間、大規模なバージョンアップが行われたり、頻繁にパッチが発行されたりして、製品開発チームはそのたびに、新しいものを組み込むことになります。また、バージョンアップにしてもパッチにしても、どこが変わったのかという詳しく正確な情報はありません。
他社からの購入ソフトについても、並行して開発が進んでいるものを購入するケースが多く、やはり、新しいバージョンやパッチがリリースされて対応せざるをえないことになっています。
そして、このような状況は次のような問題が引き起こしています。
【段階的品質積み上げの破綻】
単体テスト、結合テスト、システムテストと段階的に品質を積み上げていってもバージョンアップやパッチのたびに動かなくなり（デグレが起き）、品質は振り出しに戻る。
【設計重視の破綻】
Android はソースコードで提供されるとはいえ、その内部構 造や動作を把握することは困難で、実質ブ...
ラックボックスとして扱わざるを得ない。そのため、机上での設計やレビューを徹底しても設計検証にはヌケ・モレを生じる。
【工程ごとの品質確認の破綻】
頻繁なパッチに対応するために何度も同じテストを実施する必要がある。回帰テストの実施も従来以上に重要になる。そのため、工程ごとの作業や成果物確認では製品全体の品質確保は難しい。
このような問題は、小手先、あるいは、現場任せで対応できるものではなく、開発プロセスや開発マネジメントを根本的に変える必要があると考えます。さらに、頻繁なバージョンアップやパッチは Android に限らず OSS や外部購入ソフトに一般的な傾向なため、対応は加速度的に複雑になります。
以上、外部依存度が上がっていることを前提とした新しい開発プロセスを構築する必要があると考えていますが、いかがでしょうか、対策については次回、解説します。