03 / O-HIVE
空間の取得は、
始まりにすぎない。
デジタルツインは、チームの判断に使えてこそ価値があります。取得した空間、確認作業、課題の担当、報告をつなぐプロダクトの仕事を率いました。
事業機会
目を引く空間データの、その先へ。
空間の取得とAI分析は、通常の点検写真以上の情報を示せました。ただし技術のデモだけでは、現場チームの実務上の問いには答えられていませんでした。何に注意が必要か、誰が担当するか、指摘事項は解決したのか、という問いです。
私は、一連の確認作業が完結することに焦点を絞りました。分析機能を広げる前に、最初のリリースで、根拠から対応までを確実につなぐ必要がありました。
実務を進められるプロダクト
ひとつの指摘から、解決までの道筋を。
ビューアー、議論、タスク割り当て、報告に共通するモデルを定義しました。指摘事項が工程を進んでも、位置、取得時の状況、会話、責任者が引き継がれます。
この判断で、顧客にとって確認作業の流れが一貫し、エンジニアも共通のデータと状態を基に実装できるようになりました。デスクトップとモバイルで画面が変わっても、責任の所在は変わりません。
設備シャフト周辺のクリアランス
取得した画像、正確な位置、確認に必要な状況をひとつに。
ひとつの指摘事項を、順に追ってみる。
プロダクトとエンジニアリング
難しい判断こそ、実装の近くで。
顧客の業務フローを要件に落とし込み、複数拠点のエンジニアリング・AIチームと優先順位を決めました。体験の流れとともに、権限、確認の状態、不確かな検出、報告書に含める内容を詰めていきました。
AIの検出結果は、人が確認する提案として扱いました。指摘事項を承認し、次の対応を決める責任は、人に残しました。誤分類が問題につながる場面でも、使えるプロダクトであるための判断です。
範囲を絞った初期リリース
つながりのない技術機能を増やすより、最初から最後まで完結する確認の流れを優先します。
人が判断し、責任を持つ
機械の検出結果と、承認済みの指摘事項を区別し、確認者の判断を残します。
チームをまたぐ開発進行
共通の受け入れ基準と明確な公開順序を用い、空間技術、AI、アプリケーションの開発を調整します。
オフィスから現場へ
場所が変わっても、仕事をつなぐ。
デスクトップで始めた確認作業を、現場で実際の場所を確かめる人が引き継ぐこともあります。モバイルをメインビューアーの縮小版にせず、プロジェクトのファイル、課題の背景、タスクの状態を共通のプロダクトモデルにまとめました。
報告画面では、承認した指摘事項と未完了の対応をまとめました。確認結果を、スクリーンショットの寄せ集めではなく、実務の引き継ぎに使えるものにしました。
端末をまたいでも途切れない
文脈を保ち、
画面を変える。
モデルを確認する人から実作業の責任者へ渡っても、指摘の内容が伝わる必要があります。
変わったこと
見るためだけでなく、
確認し、対応するプロダクトへ。
一連の確認ワークフローを備えて、一般公開に至りました。取得した指摘事項が、担当者のいる、報告可能な対応へ変わることを示す。この方向性が、企業向けの試験導入に向けた明確な土台になりました。
- 指摘事項、会話、責任者をつなぐ共通モデル。
- アプリケーション、空間技術、AIチームをつなぐ、実行可能な公開順序。
- 業務上の判断を中心に据えたプロダクトの説明。