東海市3D都市モデルのプロダクト化検討に向けて
東海市3D都市モデル・交通シミュレーション研究開発において、関係者間での共通認識を構築し、手戻りのない製品化（MVP）を成立させるための開発標準プロセス・推進手順・役割分担についてのドキュメント。
1. 現状認識と今後のプロジェクト推進のポイント
プロジェクト現状のすり合わせ
- 現状：研究開発から具現化フェーズにあたり、関係者間で「ミニマムで何を作るか（MVP）」の共通言語化されていない状況です。
- 今後：かつ、全ての要求を満たすことは技術的にもリソース（ヒト、カネ）的にも困難であるので、NKUrbanが検討している構想を、システム開発側が確実に実装できるよう要件・画面仕様へ落とし込む作業が必要です。
- リスク：要求や開発スコープが合意できていない状態で進めると、最悪、11月や12月など手戻り不可のタイミングで想像と違うものが実装されるなどのリスクがあります。
- 対策：上述のようなリスクを避けるためにも、今回はプロダクト開発における一般的なプロセスを紹介しつつ、今後の進め方と役割について初手整理したい。
プロセス未整理のまま進めた場合のリスク
- 最終局面での認識ズレ：11月〜12月の開発終盤で「想定と機能や使い勝手が異なる」となり、再改修が必要になる懸念。
- 工数・リソースの圧迫：全データ網羅や多機能を同時に追うと、期間内での高品質な成立が難しくなるリスク。
- エンドユーザーとのズレ：自治体（東海市）職員にとってはメリット（支払い価値）の感じにくいプロダクトになる可能性。
2. 一般的なプロダクト開発プロセスと現在の整理状況
開発をスムーズに進行させるための標準的なステップと、現在のプロジェクトにおける整理状況を比較・確認します。
| 開発Step | 標準的な成果物 | メイン担当 | 現在の整理状況・推進ポイント |
|---|---|---|---|
| 1. 企画・価値定義 | UX定義、ターゲットペルソナ、QCD優先度 | NKUrban | 要すり合わせ 本プロダクトおける必達のユーザー体験とプロジェクト全体のQCD優先度について未整理です |
| 2. 要求・要件定義 | 要求仕様書、MVPスコープ、画面UIモック | 大﨑 / エイ(MKI) | 要すり合わせ 提示中の要求整理案（MVPフロー等）に対して、各種制約条件の中でどこまでスコープにするのか未整理です |
| 3. 設計・開発見積 | 基本設計書、API仕様、工数見積 | 設計 (エイ MKI) | 開発要件が定まっていないため、実装可否と開発スケジュールが見えていません |
| 4. 開発・実装 | ソースコード、Webアプリケーション | 開発者 (MKI) | 本プロダクトの必須機能のうち、どこまでが進捗しているのか定義できていません |
| 5. UAT（受入テスト） | テスト結果、フィードバック確認書 | NKUrban | プロダクトSLAや運用保守の方針・ルール、保守コストが整理できていません |
3. 今後の具体的な進め方（6つのStep）
迷いをなくし着実に前進するため、以下の順番でプロセスを進めることを提案します。
最低限機能の定義
自治体（東海市）職員へ担保させたい「コアな価値・機能」を企画者が定義。
開発優先度（QCD）の共通化
Quality（機能充実）、Cost（予算上限）、Delivery（11月納期）の優先順位を設定。
要求・要件定義の合意
提示済みの要求仕様書（MVPユーザーフロー等）の確認とスコープの決定。
開発見積もりと設計
合意された要件に基づき、MKIがWebアセット・Cesium連携・基本設計と工数を整理。
MVPアプリの実装・開発
Webフロントエンド（UI・操作パネル・チャート）とCesium 3Dモデルの組み上げ。
UAT（受入テスト）・東海市評価
東海市職員による実機操作、フィードバック収集および研究開発成果の取りまとめ。
改めて、本プロジェクトの進める上での役割について整理します。
プロジェクト全体の方針や各種仕様に関する意思決定/統括
要求仕様に関する実現性の判断、プロダクトの設計および実装推進
プロダクト化に向けた各種論点および要求・要件の整理
4. プロジェクト体制と明確な役割分担
適切な意思決定と円滑な開発推進のため、添付のツリー構造に基づき役割およびチーム別の責任境界を明確化します。
東海市提供価値・コスト決定
開発スコープ・機能要求整理
基本設計/Cesium・Web開発
UAT評価・実用性検証・検収
| 担当区分 / チーム | 担当者 | 主な業務範囲・責任内容 |
|---|---|---|
| ビジネス検討T | NKUrban | 自治体（東海市）への提供価値の整理、コストや仕様関連の意思決定・最終判断。 |
| 要求・要件T | 大﨑、エイ (MKI) | 開発スコープの策定および個別機能要求の整理と開発実現性/リスクの判断。 |
| 設計・実装 | エイ (MKI) | 要件に基づく基本設計・詳細設計および3Dモデル/Cesium連携・Web機能構造の設計。 |
| 評価（受け入れテスト） | NKUrban | 開発成果物の UAT（受け入れテスト）評価、東海市職員視点での実用性検証および最終検収。 |
5. 本日の最低限の確認・合意点（3つの基本方針）
個別の技術仕様を決める前段として、まずはプロジェクトの「進め方・マイルストーン・会議体」についてご合意をいただきたく存じます。
1 推進プロセスの合意
最優先確認「要求・要件定義→プロトタイプ開発→UAT」という段階的アプローチで進めてよいか？
2 主要マイルストーンの整理
スケジュール以下の重要な節目のスケジュール設定方針を合わせてよいか？
- 契約工期：※確認事項
- 最終リリースタイミング：自治体（東海市）への最終成果報告時期
- プレリリースタイミング：事前レクや発表会・展示会でのデモ展示時期
3 定例コミュニケーションの設置
会議体進捗の透明化と論点解消のため、定期的な進捗確認の場を設置してよいか？
頻度案：2週間に1回（Want）／ 最低でも1ヶ月に1回（Must）
短時間の定例で課題や判断事項をタイムリーに解消し、手戻りを防止します。
上記（3つの基本方針）合意後の Next Action
本日の打ち合わせで基本方針にご合意をいただけた場合、私（大﨑）にて直ちに以下の管理ドキュメントを作成し、次回定例にて提示いたします。
契約工期およびプレリリース・本リリースから逆算した工程別スケジュール（タスク分解・担当明記）の策定。
仕様・技術・ホスティング（車両データ元やCesium ion利用方針など）に関する順次判断が必要な論点をまとめるためのリストFMT。（記入は定例などで各自関係者が記入）
次回定例MTGをスムーズに進行するためのアジェンダおよび事前確認項目の整理。
各種プロジェクト推進のドキュメントはクラウド上で共同編集・管理ができるように保存します。（One Drive等を想定）