tomoyuki ishii

大手自動車メーカーの工場IoT案件で、自社側の技術担当として、メンバー2名への作業の割り振りと、顧客、プライムSIer、海外の製品ベンダーとの技術要件の調整を担当しています。あわせて、共同起案した自社SaaSの事業譲渡に伴う技術移管を担当しました。

技術検証では、工場のPLCからクラウドの分析環境までの構成が成立するか、どの製品構成が必要か、どこにリスクが残るかを、顧客が投資判断できる粒度で根拠付きで示す責務がありました。 事業譲渡では、譲渡先が自立して日常運用と障害対応を回せる状態にすることが責務でした。AWS環境、稼働中の端末、ソースコード、運用文書を、サービスを止めずに期限内に引き継げる状態にする必要がありました。

## 基本的な考え方 多階層の体制や引き継ぎの場面で失敗するのは、技術的な難しさよりも、関係者の認識がずれたまま進むことが原因だと考えています。そのため、構成を図にして共通認識を作ること、決まっていない論点を洗い出すこと、認識のずれを都度確認することに時間をかけています。 ## 工場IoT案件（自社側の技術担当） ### 進め方 - AWS構成図の作成: 検証構成の通信経路とコンポーネント配置を図にして、関係者が同じものを見て話せる状態を整えました。構成変更に追従できるよう、図はスクリプトから生成しています - 論点の整理: 検証項目、必要な事前作業、確認待ちの論点を整理し、次に何を決める必要があるかを明確にしながら進めています - メンバーへの割り振り: 製品のキッティングと現場作業をメンバー2名へ割り振り、AWS環境とConfluent Cloudの構築を担当しています - 認識合わせ: 顧客、プライムSIer、自社、製品ベンダーの間で、作業の前提や範囲の認識を都度確認しています。ここがずれるとそのまま手戻りになるためです ### 問題1: 工場ネットワークの制約が後から出てくるリスク 工場のネットワークには通信制限があり、通信頻度にも制約があります。この種の制約は、検証が終わって導入直前に発覚すると構成をやり直すことになります。そこで検証を始める前に、高頻度で通信している処理の有無、頻度を制御できる設定の有無、プロキシ非対応の通信の有無を、製品ベンダーへの確認事項として先に出しました。詰まるとやり直しになる部分を先に潰す判断です。 ### 問題2: 製品が海外ベンダー製で、公式ドキュメントだけでは判断できなかった クラウド側の連携（マネージドKafkaでの動作実績、対応バージョン、分析基盤への出力経路、コンテナ基盤でのサポート状況と推奨サイジング）は、判断を間違えると構成全体に影響します。検証環境を構築して確かめられる部分は構築して確認し、ベンダーに聞かないと分からない部分は質問リストとして体系化して照会しました。 ### 問題3: 提示された構成では成立しない箇所があった SIerから提示されたポート一覧を精査したところ、2系統でポートが重複していました。L4のロードバランサはポート単位でしか振り分けられないため、単一構成では成立しないと判断し、2セット構成とVPC分割を提案しました。この方式で構成が確定しています。机上で結論が出なかった論点はAWS上に構成を再現して実測し、方式選定の判断材料にしました。 ### 工夫している点 設計と実装を担当したまま調整役を務めることを意識しています。実現可能性の判断とスケジュールの見立てを、人から借りた情報で示すと、外れたときに責任を持てません。MQTT送信アプリとアンドン表示アプリは担当した実装なので、動作する箇所と検証が必要な箇所を根拠付きで説明できます。 ## 自社SaaSの事業譲渡に伴う技術移管 譲渡先が自立できる状態を作ることがゴールでしたが、運用の多くが社内の暗黙知で回っていました。AWSリソースにもIaC管理外の手動作成分があり、この差分を残したまま引き渡すと譲渡先でのデプロイが失敗し続ける状態でした。 そこで手動作成リソースの棚卸しとIaCへの集約を最優先タスクに置きました。文書を何冊書いても、コードとインフラの実態がずれていれば意味がないと判断したためです。その上で、散在していた手順を日常運用手順書、障害対応手順書、デプロイ手順書、オンボーディング資料として一箇所に集約し、コード側のハードコードや暗黙知前提の実装も改修しました。 AWSアカウントの移管方式は、アカウントごと渡す方式と譲渡先で新規構築してデータ移行する方式で必要な作業が変わるため、両方式を比較して決定し、本番前に模擬アカウントで移管リハーサルを実施しました。個人情報を含むデータについても、移転する範囲と削除する範囲を先に整理して合意を取っています。稼働中の端末を止めずに管理権限を移し、譲渡先エンジニア向けの技術説明会とQ&A対応まで担当しました。 ## この経験から学んだこと 進捗を管理することよりも、まだ決まっていないことを早く可視化することが効くと考えています。技術検証でも引き継ぎでも、後から出てくる制約や暗黙の前提が最も大きなコストになります。