HTHAYATE
TAKEDA
← CASE STUDY ARCHIVE

CASE STUDY 01 / SOCIAL INFRASTRUCTURE

3次元データの技術検証を、提案と受注判断につなげる

実現性が見えない段階からPoCを組み立て、検証結果を業務要件へ翻訳し、次の判断ができる状態まで進めたケースです。

ROLE: PL / SEPHASE: POC → REQUIREMENTSTECH: PYTHON / 3D

01 / OVERVIEW

案件の概要

THE QUESTION

3次元モデルの差分から、業務判断に使える量を算出できるか。算出できたとして、その結果を利用者が確認し、次の対応を決められる業務フローに落とし込めるか。

MY RESPONSIBILITY

PL・SEとして技術検証を主導し、検証担当1名のタスク設計と成果物レビューを担当しました。PoCだけで終わらせず、結果を業務フロー、画面イメージ、機能一覧へ展開し、顧客との要件整理までつなげました。

THE RESULT

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

進め方

  1. 業務上必要な判断と、検証すべき技術課題を分けて整理
  2. Open3D、Blender、Python APIなどを用いて処理方式を比較
  3. 3次元モデルの差分算出PoCを実施し、結果と限界を記録
  4. 検証結果を顧客と確認し、仕様と前提を調整
  5. 業務フロー、画面イメージ、機能一覧として要件定義へ反映

06 / OUTCOME

結果と学び

結果

PoCによって技術的な実現性を確認し、契約判断に必要な成果物を整備しました。検証結果が案件の受注につながり、次の開発段階へ進める状態をつくりました。

学び

この経験から、PoCの価値は「動くものを見せること」だけではなく、不確実性を減らし、関係者が次の判断をできる材料へ変えることにあると学びました。

このページは実際の職務経験をもとに匿名化・一般化しています。顧客名、設備情報、データ、構成図、ソースコード、内部費用、画面、運用環境の詳細は公開していません。

NEXT / CASE STUDY 02未知のCMSを選定し、運用できる基盤までつくる