本記事の概要
ハードウェア（HW）とソフトウェア（SW）が密結合するIoT開発において、「HW側の試作遅延」や「基板改修による実機検証のストップ」は避けて通れない不確実性です。実機が手元に来るのを「待つ」だけの開発姿勢では、簡単にプロジェクトの納期は崩壊します。
ましてや、スタートアップという戦場で早く製品を世に出すためにHWとSWを並行して開発することもあります。HWが出来上がらないとユーザーも満足に使用感がわからなかったりして仕様変更が実装後期に入ることもありました。
不確実性が極めて高い開発現場において、SWチームの開発ラインを止めず、かつチーム間の接続リスクを最小限に抑え込むために私が実践したことを下記項目に分けて記載しています。
- 責任分界の徹底
- スタブの活用
- IF疎通検証の切り出し
「HWとSWが密結合するIoTシステム」の開発に基づいています。
このシステムは、センサーが取得した生データ（物理量）をバックエンド等で高度に加工・分析し、ユーザーに意味のあるデータとしてWebUI（Next.js）上の時系列グラフに可視化・制御する構造を持っています。
1人目のSWエンジニア兼PMとして、この不確実性の高い開発をコントロールした知恵を共有しています。
依存関係を切り離してSWに閉じた機能を優先開発
HWが不在の状況で最初に着手したのは、システムの「責務の徹底的な分離」です。
システム全体の機能を分解し、HWの仕様変更や遅延の影響を全く受けない「SWに閉じた機能（画面UIの構築、バックエンドでのデータ加工ロジック、認証周りなど）」を明確に定義しました。依存関係のないクリーンな領域から優先的に開発を進めることで、HWの到着を待つ無駄な「手空き時間」をゼロにしました。
スタブ化による「不具合調査効率」の先回り
HWに直接影響を受ける通信部や制御処理については、あらかじめ動作を模擬する「スタブ（ダミーのドライバー）」を作成して開発を進めました。
「HWが結合するまではこの領域はブラックボックスである」と割り切り、SW単体でスタブを用いたテストを完璧に通しておくことが目的です。こうしてSW側の正当性を証明しておくことで、後に実機と結合して不具合が発生した際、「少なくともSW単体テストを通過している箇所には問題がない」と一瞬で切り分けることができ、トラブルシューティングの調査効率が劇的に向上しました。
また、SWにおいてもいくつかのコンポーネントに分かれており、そのコンポーネント間でもデータ送受信が発生します。HWとの結合前にSW間での通信処理を優先的に評価することでさらい障害個所を限定的にするように努めました。
HWチームへの交渉：IF疎通検証の最優先化
ただSW側でリスクを低減する策を講じても限界があります。さらにプロジェクト全体のリスクを下げるため、HWチームに対しても「インターフェース（通信IF）の疎通部分を最優先で検証・開通させる」ための交渉を行いました。
全体機能の完成を待つのではなく、まず最低限のデータ疎通（IF）だけを優先的に確立してもらうことで、双方の結合部における認識ズレや通信バグを初期段階で潰すことに成功しました。これにより、本結合時の予期せぬ大きな手戻りを未然に防ぐことができました。
振り返り
成果
開発におけるリスクマネジメントとは、いかにしてリスクを想定し、そのリスクを低減できるかが非常に重要です。人を増やしましょう、期間を長く設けましょう、といった策もありますがリスク低減の対応を行わない限りいくらリソースを投入しても足りません。
不確定要素を構造的に切り離してSW側で先手を打つこと（スタブ化）、そしてHW側に対しても通信IFの先行検証を交渉・打診すること、これらはリスク低減の一部です。様々な対応が考えられますが共通しているのは受動的に待つのではなく、他チームも含めて主導権を持って先回りの環境を作ることと考えています。
慣れないHWと並行した開発でしたが、能動的に他担当者とも解決案の話ができたためリスクを最小限にして開発を進められたのだと感じています。
振り返り
- ソースコードの構造化は可読性や保守性の他、責任分界の明確化にも役に立つ
- HWはSWと異なり不具合が発生すると改修に時間がかかることが多く、その特性も踏まえたリスクマネジメントが必要
- HWとSWの並行開発の際はあらかじめ疎通試験の目標を決めておく、そうすることでHW側の実装に考慮を促す