01 / OVERVIEW
案件の概要
3次元モデルの差分から、業務判断に使える量を算出できるか。算出できたとして、その結果を利用者が確認し、次の対応を決められる業務フローに落とし込めるか。
PL・SEとして技術検証を主導し、検証担当1名のタスク設計と成果物レビューを担当しました。PoCだけで終わらせず、結果を業務フロー、画面イメージ、機能一覧へ展開し、顧客との要件整理までつなげました。
PoCによって技術的な実現性を確認し、契約判断に必要な成果物を整備しました。検証結果が案件の受注につながり、次の開発段階へ進める状態をつくりました。
社会インフラ設備の状態評価を、3次元データによって効率化・定量化するDX案件です。構想段階では、必要な処理が技術的に成立するか、どのデータと手法を使うべきかが定まっていませんでした。
- MY ROLE
- PL / SE
- TEAM
- 関係者を含む8名規模。検証担当1名のタスク・成果物レビューを担当
- SCOPE
- 技術検証から、業務フロー・画面イメージ・機能一覧を含む要件整理まで
02 / CHALLENGE
課題と制約
中心となった問い
3次元モデルの差分から、業務判断に使える量を算出できるか。算出できたとして、その結果を利用者が確認し、次の対応を決められる業務フローに落とし込めるか。
制約
- 完成仕様を決める前に、複数技術の成立性を確認する必要があった
- PoCの結果を、技術者以外も判断できる資料へ翻訳する必要があった
- 検証と並行して、顧客との仕様調整と契約判断に必要な整理を進める必要があった
03 / MY ROLE
私の役割
PL・SEとして技術検証を主導し、検証担当1名のタスク設計と成果物レビューを担当しました。PoCだけで終わらせず、結果を業務フロー、画面イメージ、機能一覧へ展開し、顧客との要件整理までつなげました。
04 / DECISION
判断と工夫
初めからシステム全体を設計せず、最も不確実性の高い3次元モデルの演算を先に切り出しました。複数のライブラリやツールを比較し、ブーリアン演算による差分算出をPoCの中心に据えました。
05 / PROCESS
進め方
- 業務上必要な判断と、検証すべき技術課題を分けて整理
- Open3D、Blender、Python APIなどを用いて処理方式を比較
- 3次元モデルの差分算出PoCを実施し、結果と限界を記録
- 検証結果を顧客と確認し、仕様と前提を調整
- 業務フロー、画面イメージ、機能一覧として要件定義へ反映
06 / OUTCOME
結果と学び
結果
PoCによって技術的な実現性を確認し、契約判断に必要な成果物を整備しました。検証結果が案件の受注につながり、次の開発段階へ進める状態をつくりました。
学び
この経験から、PoCの価値は「動くものを見せること」だけではなく、不確実性を減らし、関係者が次の判断をできる材料へ変えることにあると学びました。
このページは実際の職務経験をもとに匿名化・一般化しています。顧客名、設備情報、データ、構成図、ソースコード、内部費用、画面、運用環境の詳細は公開していません。
NEXT / CASE STUDY 02未知のCMSを選定し、運用できる基盤までつくる →