tomoyuki ishii

大手自動車メーカーの工場設備データ収集案件のうち、産業IoTプラットフォーム導入検証プロジェクトのリーダーを担当しています。マネージメント対象は、プライムSIerを介した三者体制（エンドユーザー/プライムSIer/自社）における技術検証のスコープ・スケジュール・成果物と、製品ベンダーを含む関係者間の論点調整です。あわせて、主担当だった自社SaaSの事業譲渡に伴う技術資産の移管も推進しました。

技術検証では「この構成で本当に動くのか」という問いに、顧客が投資判断できる粒度で答えを出す責務がありました。工場のPLCからクラウド（Databricks）までのデータ収集構成が実現可能か、どの製品構成とサイジングが必要か、どこにリスクが残るかを、根拠付きで示すことです。 事業譲渡では、譲渡先のエンジニアが当社に問い合わせずに日常運用と障害対応を回せる状態にすることが責務でした。ソースコード・AWS環境・稼働中デバイス・ドキュメントのすべてを、期限内に、サービスを止めずに引き継げる状態にする必要がありました。

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