◆ 解決策
成功体験が重荷となる製品開発プロセス（その１：現状の課題）では、スマートフォンで起きていることを例にして、従来の組み込みソフト開発が抱える問題について解説しました。オープンソフトなのか買い入れソフトなのかはありますが、組み込みソフト開発の現場も、ソフトウェアの外部調達は増加傾向にあります。これは、外部依存度が高くなっていることであり、次のような問題を引き起こしているということをお伝えしました。
・段階的品質積み上げの破綻
・設計重視の破綻
・工程ごとの品質確認の破綻
・設計重視の破綻
・工程ごとの品質確認の破綻
今回は、解決策について解説します。
1. 基本は実機ベースの動作確認
従来は、上流重視、設計重視が基本的な考え方で、テスト工程までに高い設計完成度を確保することを重視していました。そのために、設計書を充実させ、レビュー（DR）を徹底させてきました。
しかし、外部依存度が高くなっているという状況下、しかも、外部調達のソフトも並行して開発が進むという状況下では、それらを含めた設計書ベースの機能検証は困難です。外部調達ソフトは設計書がない、インタフェースも含めてプログラムが変わる、という状況が当たり前であり、全体で整合のとれた設計確認は困難だからです。
また、外部調達ソフトも開発中という場合は、頻繁にパッチやバージョンアップが発生し、組み込むたびに、動作が確認できていた機能が動かなくなることもしばしばです。
このような状況下で完成度や品質を確認するには、動作させて確認するのがもっとも効果的です。開発初期段階から何がどこまで動いているのかを繰り返して、完成度や品質を確認する仕組みに変えるということです。
スマートフォンなどの開発期間が短い製品の場合に顕著ですが、開発が本格化するのは、ハードウェアでは試作ができてから、ソフトウェアでは結合テストがはじまってからと言っても良いと思います。実機ベースで課題や不具合を確認できてから急速に開発のペースが上がるからです。ただ、開発期間の後半から開発ペースが上がるのでは遅い。開発初期から開発ペースを上げないと間に合いません。
2. ショートサイクルによる段階的開発
組み込みソフトウェアが目指すべき開発プロセスは、従来のウォーターフォール型の設計から評価までのサイクル（期間）を短くして、そのサイクルを何度も繰り返しながら完成度を高めていくというものだと考えます。
実現のためには、ハードウェアとソフトウェアの両方を合わせて開発プロセスを見直す必要がありますが、ハードウェア開発プロセスについての説明は次回以降にしたいと思います。ポイントは、開発体制のモジュール化とレファレンス・プラットフォーム試作です。
ショートサイクルによる段階的開発は、アジャイル的開発スタイルと考えることもできますが、アジャイル導入が目標になると負担が大きくなる傾向があります。大切なことは段階的に実機で完成度を確認するということです。間接的にですが、欧州のクルマメーカーもハードウェアも合わせたショートサイクルの段階的開発という取り組みをしているということも聞いています。自社に合わせた取り組みをはじめるときではないでしょうか。
3. ユースケース・マトリクス
組み込みソフト開発においてショートサイクルによる段階的開発を実現するためには、ユースケース・マトリクスを作成することがポイントになります。どの機能がどこまで動いているのかを常に確認するためです。
ユースケース・マトリクスとは、プロダクトやモジュールが提供しているユースケース（機能やサービス）を縦軸に並べ、内部構造（モジュールやユニット）を横軸に並べて、両者の関係を一覧できるようにしたものです。これにより、何がどこまで動いているのかという完成度はユースケース軸で確認します。
重要なのは、外部依存度が高い、すなわち、ブラックボックスとなっている部分が多い状況下で、縦軸のユースケースを抽出する手順と、横軸の内部構造を明らかにする方法です。オープンソース（OSS）はソースコード参照可能ですが、全体を理解するのは非常に大変ですから、ほぼブラックボックスだと考えた方がよいと思います。
4. 構造化ユースケース設計
自社開発中心の場合は、内部構造やその振る舞いがわかっているため、設計は詳細設計、内部設計重視になりがちですが、外部依存度が高くなっている状態では内部を把握することが困難な部分が増えているため、利用方法や外部仕様を重視する設計方法にシフトする必要があります。
ここで重要なのは、設計対象を独立したプロダクトと考え、どういうユーザー（人とは限らない）がいて、どのような使われ方をして、どのような価値（機能）を提供しているのかを明確にすることです。
このような考え方をベースに、ユースケース・マトリクスを作成する方法を「構造化ユースケース設計」としてまとめたのですが、ここでは、Wi-Fi 機能を例にとって、いくつかポイントを紹介したいと思います。例とした Wi-Fi 機能は、機能の進化が早く、デバイスドライバーとともにデバイスを外部から購入することが多いため、外部依存度が高いモジュールのひとつです。
5. ドメインモデリング＆ビヘイビアモデリング
ドメインモデリングとは、対象がかかわっているモジュールやユーザー、イベントを洗い出し、どのような動作をするのかの全体像を把握することです。Wi-Fi 機能の場合は、OS（カーネル）、通信チャネル、設定アプリといったモジュールとの関係を整理します。
ビヘイビアモデリングとは、対象がどのような振る舞いをするのかを把握することです。状態遷移図などで表現するのが一般的だと思いますが、Wi-Fi 機能のように外部購入が一般的な場合は、カタログ仕様に頼ってしまい、作成していない場合が多いようです。そのために、全体としてどのような振る舞いをするのかを理解しないままに開発を進めることになっています。
Wi-Fi の場合、次のような状態遷移図でビヘイビアモデルとすることができます。
このモデルからは、振る舞いの大枠が「ON」「OFF」「スキャン」「接続」「接続維持」「切断」「通信開始」「通信終了」「サスペンド」「レジューム」という遷移で分類でき、その遷移に関連した機能をサブモジュールと考えることが可能です。これが、Wi-Fi 機能におけるユースケース・マトリクスの横軸の大分類となります。
6. 要求・要件マッピング
対象に求められている要求を整理し、その要求に応えるために必要となる要件を洗い出します。たとえば、「接続性を高める」という要求に対して、「5GHz の周波数帯に対応する」という要件を割り当てることが考えられます。接続性を高めるのが目的ですから、STAモードだけが対象になるなど、要求ベースに要件に関する条件判断も行います。
さらに、その要件を実現するために、対象がどのように動作する必要があるのか、カギとなる処理の流れ（ワークフロー）は何かを分析します。たとえば、5...
GHz 対応であれば次のような流れになります。
1. 国コードを取得する
2. AP（アクセスポイント）をスキャンする
3. AP情報を取得する
4. 周波数を特定する
5. 接続する
このワークフロー分析により、提供された Wi-Fi デバイスドライバーでは、国コードの取得方法や周波数の特定方法に問題があることなど、ブラックボックスとなっている部分について確認すべき事項を整理することが可能です。
7. 動的解析の環境整備
さらに、整理したユースケースごとに実際の内部動作を確認して、関係する内部モジュールとの関係を整理します。自社開発の部分は設計段階で関係する内部モジュールはわかりますが、外部依存となっている部分は動作させて確認するのがもっとも効果的です。そのため、動作ログ（トレースログ）をとって内部の振る舞いを分析するなどの方法や環境を整えておくことが大切です。
開発現場では、動作ログ（トレースログ）は、不具合解析の際に技術者が個人作業として取ることが多いのですが、ショートサイクルで動作確認をすると同時に動作ログをとって設計のためのインプットとすることを仕組み化すると良いと考えます。