ハード待ちを作らない並行開発

「並行開発」のはずが、ソフトがハードを待つ現場の実感

組み込み開発の一般的な説明では、ハードとソフトは並行して開発が進むとされています。基板の設計と実装が進む一方で、ソフト側は仕様に基づいてコードを書き進めるという役割分担です。実際に多くの解説記事でも、この並行開発という前提は短く紹介されるにとどまっています。並行して進めれば開発期間を短縮できるという発想自体は、決して間違っていません。

しかし開発現場の実感は異なります。組み込みソフトはパソコン上だけで動く汎用ソフトと違い、実際のハード上で動かしてはじめて正しく検証できるという性質を持ちます（「組み込みソフトと汎用ソフトの違い」参照）。そのため試作基板や部品が手元に届かない限り、コードは書けても検証までは進められません。結果として、並行開発のはずが「ソフトがハードの完成を待つ」構図が生まれやすくなっています。

この待ちの構図は、多くの現場で共通して経験されているにもかかわらず、具体的な対処法として整理されている情報は多くありません。ハードが完成してからソフトの検証を始めれば済むという前提のまま計画が組まれ、待ちの時間そのものを短縮する工夫が後回しにされがちです。開発リーダーやマネージャーにとっては、待ちを前提にした計画づくりではなく、待ちそのものを減らす計画づくりが求められています。

待ちが発生する典型的な場面

組み込み開発における待ちは、単一の原因ではなく複数の場面で繰り返し発生します。代表的な場面を整理すると、次の五つに分類できます。

• 試作基板の完成待ち：基板の設計や実装、検査工程が終わるまで、ソフト側は実機での動作確認に着手できません。基板の不具合が見つかれば、修正のためさらに待ち時間が延びます。
• 部品調達待ち：半導体や電子部品の入手に時間がかかり、基板そのものが組み上がらないケースです（「組み込み開発における制約事項」参照）。代替部品への切り換えが必要になれば、仕様検討からやり直しになることもあります。
• ハード仕様の確定待ち：ピン配置やレジスタの仕様、通信インターフェースの詳細が固まらないうちは、下位のドライバ層を実装できません。仕様検討が長引く製品ほど、この待ちは深刻になります。
• 実機の台数不足による取り合い：試作機が少数しかないと、複数の開発者やチームが使用の順番待ちをすることになり、一人あたりの実機占有時間が細切れになります。
• 他チームによる実機の占有：ハード側の検証や品質評価、量産準備の確認作業のために実機が長期間拘束され、ソフト側が使えない期間が生じます。使用予定を事前に共有していないと、この占有は突発的に発生します。

• テスト支援システムの商品情報はこちら
• PDFで詳しく見る

待ち時間が生む四つの損失

待ちが発生しても、開発全体の納期はそのまま動かないことがほとんどです。そのため待ちの期間は、そのままスケジュールを圧迫する損失に変わります。損失は単に日数が延びるだけではなく、開発の質そのものにも影響します。特にリーダーやマネージャーの立場では、この損失が積み重なった結果として後工程にしわ寄せが集中する事態を、早い段階で見越しておく必要があります。

• スケジュールの後ろ倒し：実機待ちの期間がそのまま工程全体を圧迫し、後続のすべての作業が遅れて始まります。
• テスト期間の圧縮：開発期間全体が変わらない以上、しわ寄せは検証やテストの工程に真っ先に及びます（「V字モデルで学ぶテスト工程と品質保証」参照）。
• 終盤への負荷集中：実機がそろってから作業が一気に集中し、開発終盤に人員と時間の負荷が跳ね上がります。
• 手戻りの発覚が遅れる：設計段階の誤りが実機検証の時点まで見つからず、発覚した時点ではすでに関連するコードが積み上がっているため、修正コストが大きくなります。

ソフトを先行させる手段 - 仕様の先行固定と層の分離

ここまでの損失を防ぐには、ハードの完成を待たずにソフトを先行させる工夫が欠かせません。以下では、その具体的な手段を五段階に分けて整理します。

ハード待ちを減らす第一の手段は、インターフェース仕様を早期に固定することです。通信プロトコルやレジスタマップ、信号のタイミングなど、ハードとソフトの境界を定義する仕様を先に合意しておけば、ハードの実装が完了していなくても、ソフト側は仕様に沿ったコードを書き進められます。仕様書のうち、変更の可能性が低い部分と、まだ流動的な部分を区別して共有しておくことも有効です。全項目が固まるのを待つのではなく、確定した部分から段階的に着手する判断が求められます。

第二の手段は、ソフトの層を分離することです。ハードに直接依存する処理を薄いレイヤに閉じ込め、その上位にあるロジックは、ハードから独立した形で先に作り込みます（「組み込みソフトを動かす基板」参照）。この下位のレイヤは一般にハードウェア抽象化層と呼ばれ、ハードごとの仕様の違いを吸収し、共通の方法で扱えるようにする役割を持ちます。

上位ロジックがこの層越しにハードとやり取りする構造にしておけば、ハード側の仕様変更があっても、影響範囲を下位レイヤに限定できます。アルゴリズムや状態遷移といった、製品の価値を左右する上位ロジックほど、実機を待たずに先行して作り込む効果が大きくなります。

• テスト支援システムの商品情報はこちら
• PDFで詳しく見る

ソフトを先行させる手段 - 代替手段とその限界

第三の手段は、スタブやモックによる代替です。スタブとは、上位モジュールから呼び出される下位モジュールに成り代わる、中身を持たないテスト専用のソフトウェア部品です。上位モジュールが下位モジュールを正しく呼び出せているかを確認するために使われ、実機が届く前でも、上位ロジックの呼び出し処理を検証できます。呼び出された回数や引数の内容まで検証したい場合は、モックを使い分けます。

ただしスタブやモックには限界があります。自作したスタブは、あくまで開発者が想定した応答を返すだけで、実物のハードとまったく同じ挙動をする保証はありません。信号の遅延や電源投入時の電気的な振る舞いといった、実機に特有の性質は再現できません。

さらに、ハードの仕様が変わるたびにスタブ自体を直す必要があり、スタブの保守そのものが新たな作業負担になる点にも注意が必要です。スタブで検証済みという事実は、あくまで上位ロジックの呼び出し関係が正しいことの裏付けにすぎず、実機での検証を省略できる理由にはなりません。スタブはハード待ちを完全になくす手段ではなく、待ちの期間を有効に使うための手段だと捉えておくことが大切です。

第四の手段は、評価ボードや既存機種を代用することです。評価ボードとは、半導体製品を試用・評価するためにメーカが提供する基板であり、対象のチップに加えて電源回路や通信インターフェースなどの周辺回路が実装されています。

メーカによって動作が保証されているため、自社の試作基板がそろうまでのあいだ、評価ボードや前機種の実機を仮の検証環境として使えば、ソフトのデバッグに早期から着手できます。対象のチップやインターフェースが同じであれば、ドライバ層の大部分は自社基板でもそのまま流用できます。既存機種を流用する場合も同様に、共通する周辺回路の範囲を見極めることが鍵になります。

第五の手段は、接続機器や入出力信号をエミュレーションし、実機相当の環境を先に用意することです。センサやアクチュエータなど周辺機器の信号を模擬的に生成する仕組みを使えば、実物の周辺機器がそろっていなくても、ソフト側は入出力を伴う一連の処理を通しで検証できます（「エミュレータ/シミュレータ/実機の使い分け」参照）。

スタブが呼び出し関係を模擬するだけであるのに対し、この手段は電気信号に近いレベルで実機相当の入出力を再現できる点が異なります。異常値や通信エラーといった、実機ではめったに再現できない条件を意図的に作り出せる点も、この手段ならではの利点です。

体制づくりがソフト先行開発を支える

ここまでの手段は、いずれもハード担当とソフト担当のあいだで密な情報連携があってはじめて機能します。インターフェース仕様を先に固定するには、双方が仕様の確定版と暫定版を区別し、変更が生じた際に速やかに伝達する仕組みが必要です。定例の打ち合わせだけに頼らず、仕様変更が起きた時点で即座に共有できる連絡経路を用意しておくと効果的です。口頭での申し送りだけに頼ると、伝達漏れが起きやすく、後になって仕様の解釈違いが表面化します。

部品の変更が生じた場合も同様です。使用する部品が変わると、レジスタの仕様やタイミングが変わることがあり、下位レイヤやスタブに影響が及びます。変更の影響範囲をハード担当とソフト担当が共同で確認する体制を整えておけば、手戻りの発覚を早め、開発終盤の負荷集中を避けられます。実機の使用予定をハードとソフトの双方が見える形で共有しておくことも、実機の取り合いを防ぐ地道な対策になります。

こうした体制は、開発の進め方がウォーターフォールであってもアジャイルであっても、共通して必要です。体制と手段の両方を組み合わせてはじめて、ソフトを先行させる取り組みは実効性を持ちます。

• テスト支援システムの商品情報はこちら
• PDFで詳しく見る

まとめ

組み込み開発ではハードとソフトの並行開発が前提とされますが、実際にはソフトがハードを待つ構図が生じやすいのが実情です。インターフェース仕様の先行固定や層の分離、評価ボードの活用、信号のエミュレーションといった手段を段階的に組み合わせ、ハード担当との情報連携を欠かさないことが、待ち時間を減らし終盤の負荷集中を防ぐ鍵になります。