リードタイム20%短縮に向けた開発環境への投資配分
組込みソフト開発部門40名（5グループ）を抱える事業部。製品は3つのツールチェーン（A社MCU純正、GCC系、旧社内ツール）でビルドされ、CIはJenkins 1台で運用している。フルビルドは45分、単体テスト込みで70分。開発者は夜間にビルドを仕込み、朝に結果を見る運用で、ローカルでは通るがCIで落ちることも多く、CIの信頼性は低いと見られている。静的解析は3年前に導入したが警告が約10,000件あり、「新規警告ゼロ」も守られていない。実機HILは3台を共有し、予約はホワイトボード管理。自動テストは全体の20%程度。リリース判定は手作業のチェックリストで、過去1年に2回、テスト未実施の機能が市場に出た（重大度はいずれも中）。ツールチェーンのライセンスはフローティング5席を40名で共有し、ビルド時に取得待ちが発生する。各グループは独自スクリプトを育てており、同じ製品でもグループによってビルド手順が異なる。経営層の指示は「開発リードタイムを20%短縮せよ」の一言で、予算は年間2,000万円である。
1. 2,000万円の予算で、どの改善をどの順に実施すべきか。ボトルネックの特定方法と投資対効果の算定を示せ。
Read the worked answer
まず計測（2週間、コストほぼゼロ）: リードタイムを価値流れで分解する。典型的な待ちは「ビルド待ち」「HIL予約待ち」「CI失敗の原因調査」「リリース判定待ち」である。現状データ（ビルド45分・テスト70分、HIL予約待ちが何日か、CI失敗率、手戻り工数）を集めてから投資先を決める。感覚でCI高速化から始めると、ボトルネックがテスト待ちだった場合に効果が出ない。
投資配分の例
| 施策 | 概算 | 期待効果 |
|---|---|---|
| CI高速化（キャッシュ、増分ビルド、分散） | 300〜500万 | フルビルド45分→15分。夜間バッチからPRごと実行へ |
| HIL増設（3台→6台）＋予約自動化 | 600〜800万 | 予約待ちの解消、夜間自動実行 |
| SIL環境とテスト自動化基盤 | 400万 | 自動化率20%→60%、回帰の再現性 |
| 静的解析のベースライン化とゲート運用 | 100万 | 新規警告ゼロの維持 |
| ツールチェーン統合（3→2）とライセンス増 | 200万 | 取得待ちの解消、手順の統一 |
順序: 計測 → 静的解析運用（安く効く）→ ツールチェーン統合とライセンス → CI高速化 → HIL/自動化。アムダールの法則で、各改善が全体時間にどれだけ寄与するかを試算してから着手する。
判断の軸: 40名の待ち時間は工数換算で経営層に説明できる。ビルド待ちが1日1回30分×40名なら月約87人時であり、CI投資の回収根拠になる。
2. 静的解析の警告10,000件を、形骸化させずに運用へ落とす方法を述べよ。
Read the worked answer
10,000件は「多すぎて読めない」状態であり、ツールの問題ではなく運用の問題である。
- ベースラインの固定: 現行コードの警告10,000件を既知としてベースラインに記録し、PRでは「新規警告ゼロ」だけを判定する。これで初めてゲートが機能する。
- トリアージ: 「バグ直結（未初期化、NULL参照、配列外参照、リソースリーク）」「マルチタスク競合（共有変数の保護漏れ）」「スタイル・可読性」に分類する。組込みでは競合と未初期化を最優先。MISRA準拠は製品の安全要求に照らして適用範囲を決め、全ルール一律適用はしない。
- ゲート化: CIで新規警告が出たらマージ不可。既存警告は「触ったファイルだけ返済する（ボーイスカウトルール）」とし、新規開発コードは最初から警告ゼロで入れる。
- 抑制の統制: 誤検知は抑制コメントと理由を必須にし、レビューで確認する。理由なしの抑制を禁止する。
- 効果測定: 返済件数の推移と、静的解析で検出された不具合件数を四半期ごとに報告し、投資継続の根拠にする。
落とし穴: 10,000件を一括返済しようとするとレビュー負荷で必ず形骸化する。「新規ゼロ＋触ったファイルの返済」が現実的で、3年かけて減らす計画にする。
3. HILの不足をどう解消するか。SIL・仮想化との使い分けと投資判断の順序を示せ。
Read the worked answer
使い分けの原則: HILは実機でしか確認できないものに限定する。具体的には電気的特性（電圧・電流・ノイズ）、実時間性（割込み応答、通信タイムアウト）、故障注入（断線、電圧降下）、最終製品のシステム結合。それ以外の機能テスト・回帰テストはSIL（シミュレータ、プロセッサエミュレーション）で回す。
進め方
- 現行の手動テストを棚卸しし、「HIL必須」「SILで代替可能」「自動化可能」に分類する。機能テストの多くはSILで代替できる。
- SIL環境を整備し、回帰スイートの大半をSILへ移す。HILはスモークテストとシステム結合に絞る。
- HILは予約の自動化（Web予約、ジョブキュー）で稼働率を上げる。3台でも夜間に自動で回せば実効能力は数倍になる。
- 増設は、自動化後の稼働率を測ってから判断する。2,000万円の予算では、SIL整備＋予約自動化＋夜間自動実行のほうが費用対効果が高い可能性が高い。
削らない領域: 故障注入はHILの価値が最も高い領域である。組込みの市場不具合は異常系で出ることが多く、過去1年にテスト未実施機能が市場流出した2件も、この領域の手薄さが原因である可能性がある。ここを削って台数だけ増やしても再発は防げない。