大手メーカーで進めたIoTサービスの開発初期に直面した混乱と、その振り返りから導いた再発防止策をまとめました。
はじめに
社内プロジェクトで IoTサービス（以下、サービス）を立ち上げる際の「開発初期（PoC〜量産企画移行期）」を経験しました。 その過程で多くの手戻りが発生し、関係者の混乱を招いたため、なぜ失敗したのか／次にどうすれば良いか をメモとして残しておきます。
製造業やIoT領域で似た立場の方の参考になれば幸いです。
1. プロジェクトの前提
| 区分 | 概要 |
|---|---|
| 体制（当初） | 企画 数名・マーケ 数名・設計 数名 |
| 主な開発対象 | 制御装置・計測装置／制御ボード（市販品）／ローカル機材構成／閉域網通信／バックエンドサーバ／管理・ユーザUI |
| 外部ベンダー | SIer 数社（ハード／サーバ／UI 各領域委託） |
| 進め方の特徴 | PoC成果物をベースに大部分をそのまま量産フェーズへ横滑り |
2. 開発初期で露呈した問題点
2.1 体制・役割の曖昧さ
- 「サービス設計責任者」が不在
企画は構想のみ、実ユーザや運用部門との接点がなく、仕様が常にグレー。 - ベンダー責任区分がグレー
契約条項・窓口・成果物管理があやふやで、追加工数が頻発。 - ガバナンス不足
技術面を牽引するキーパーソンに依存し、レビュー／承認フローが形骸化。
2.2 プロセス＆ドキュメント管理
- PoCの一時しのぎ構成を流用 → 運用・保守要件を無視したアーキテクチャ。
- Git／チケット／設計書の共通ルールなし。各社が独自管理。
- デバイス⇔サーバ通信仕様がPoC踏襲のまま拡張性考慮が不足
2.3 変更対応の硬直化
- 社内規程が重く、設計以外の考慮に膨大な時間を費やす
- ハード構成大幅変更時の影響分析が甘く、結合テスト前に不整合が噴出。
3. 「こうしておけば…」と痛感した10の打ち手
| # | 打ち手 | ポイント |
|---|---|---|
| 1 | サービス設計責任者の明確化 | 運用シナリオ・価値提案を握る専門チームを立てる |
| 2 | RACI＋PMOで責任区分を可視化 | 窓口・決裁ラインを一本化し変更管理を徹底 |
| 3 | PoCと製品化を切り分け | 再設計フェーズを必ず挟み、運用・保守観点を反映 |
| 4 | 共通開発ルール策定 | Git／チケット／設計書を一元管理し最新版を共有 |
| 5 | 技術リードの属人化排除 | コードレビューフロー＋外部レビューでブラックボックスを潰す |
| 6 | アジャイル型契約の検討 | スプリント単位で成果物を確定し、変更コストを最小化 |
| 7 | 実効性あるゲートレビュー | ドキュメント承認＋モック／デモでの合意を必須化 |
| 8 | 構成変更時の影響分析徹底 | ハード変更→通信／DBまで追跡しテスト計画に反映 |
| 9 | 横断アーキテクチャ図の整備 | 全体像・連携点を1枚に可視化し情報伝達を高速化 |
| 10 | 段階的結合テスト | スタブ・エミュレータで早期疎通、手戻りを前倒しで潰す |
4. まとめ
- 最大の教訓は「サービス全体像を握る責任者を立てること」。運用フローとユーザ価値が曖昧なまま機能開発を進めると、PoCの資産がそのまま負債化する。
- 役割と連携ルールを仕組みで縛る（RACI／PMO／共通リポジトリ）は、人数が増えるほど必須。
- 組み込み×サーバの歩調を合わせた段階的結合テストを敷くことで、最後の「デスマーチ」を防げる。
- 不確実性が高いIoT新規事業では、仮説→実証→学習サイクルを前提としたアジャイルな契約と開発ファネルを意識すべき。
「最初に完璧を目指さず、間違えてもすぐ直せる仕組みを先に作る」
— これに尽きる気がします。
次の一手
同じ轍を踏まないために、まずは 「サービス設計責任者」と「PMO」 の設置を最優先で提案中。動きがあれば追ってレポートします。