1. KOIKOI
1.1. 佐々木さん1on1
1.1.1. 補助金申請 (もの補助／事業再構)
1.1.1.1. BizDevチーム
1.1.1.1.1. 開発PMも参画し重み付けはする
1.1.1.1.2. 採択出てからキックオフまでに時間がかかっている？
1.1.1.1.3. お金を準備するのに苦労？
1.1.2. アイディエーション (デザインスプリント)
1.1.2.1. Xxチーム 鶴田さん
1.1.3. 要求分析
1.1.3.1. 結城さん・秋山さん
1.1.3.1.1. 要求を減らしたものを納品する
1.1.3.1.2. 補助金申請書に記載のことは全部ガワとしては用意する必要あり
1.1.3.1.3. 申請書の記載はあまりキッチリ書きすぎない方がいい
1.1.4. 要件定義
1.1.4.1. 結城さん・秋山さん
1.1.4.1.1. スケジュールがタイトであるが故、ドキュメントをオフショアに渡せない
1.1.5. 基本設計 (DB含む)
1.1.5.1. 結城さん・秋山さん
1.1.6. 詳細設計→コーディング →ユニットテスト→結合テスト
1.1.6.1. オフショアチーム
1.1.7. UAT
1.1.7.1. 平尾さん
1.1.8. 顧客説明 初期設定
1.1.8.1. 平尾さん
1.1.9. 納品 (最終確認・報告)
1.1.9.1. 平尾さん
1.1.10. 保守
1.1.10.1. 契約外・・・
1.2. 詳細
1.2.1. 補助金計画書：アプリリリース10月予定
1.2.2. 採択：1,500万+400万？
1.2.3. キックオフ：10月末
1.2.3.1. この時点ではα版、ビデオチャットなし
1.2.3.2. サービスインしない
1.2.3.3. 補助金の完了報告はする
1.2.3.4. 出来なかった部分は別契約で進める
1.2.3.5. それっぽく動くものがあれば良い
1.2.4. 納品：3月
1.3. FB
1.3.1. ・起案時（補助金申請時） 開発と運用のコスト試算の妥当性が検証されているか。 開発PMの精査を入れたほうが良い。
1.3.2. ・予算管理 開発のキックオフ前後でプロジェクトの予算配分を検討し、PM以上のメンバーで精査。 要員計画（バイネーム不要）もこの段階でしておく。
1.3.3. ・開発ベンダーとの折衝 概算見積りと見積精緻化の2回実施したほうが安全。 要件定義書で概算見積もり、基本設計書で見積もり精緻化、のイメージ。 相見積もりの実施。相見積もりの相手は包括的NDA締結済？
1.3.4. ・開発～納品前後 まだ私はエンジニアプラスでは未経験なので、現状はよく把握していません。
2. Deepcom
2.1. 福田さん1on1
2.1.1. 補助金申請 (もの補助／事業再構)
2.1.1.1. BizDevチーム
2.1.2. アイディエーション (デザインスプリント)
2.1.2.1. Xxチーム 鶴田さん
2.1.3. 要求分析
2.1.3.1. 福田さん
2.1.3.1.1. 要件を絞るところからスタートしている
2.1.3.1.2. 幸いお客さんは理解がありトラブルにはなっていない
2.1.4. 要件定義
2.1.4.1. 福田さん・倉原さん
2.1.5. バックエンド
2.1.5.1. 基本設計 (DB含む)
2.1.5.1.1. 倉原さん
2.1.5.2. 詳細設計→コーディング →ユニットテスト→結合テスト
2.1.5.2.1. オフショアチーム
2.1.6. フロントエンド
2.1.6.1. ワイヤーフレーム 画面設計 パーツ定義
2.1.6.1.1. 澤野さん
2.1.6.2. 詳細設計
2.1.6.2.1. 秋山さん
2.1.6.3. 実装
2.1.6.3.1. オフショアチーム
2.1.7. UAT
2.1.7.1. 平尾さん
2.1.8. 顧客説明 初期設定
2.1.8.1. 平尾さん
2.1.9. 納品 (最終確認・報告)
2.1.9.1. 平尾さん
2.1.10. 保守
2.1.10.1. 契約外・・・
2.2. 詳細
2.2.1. 補助金計画書：アプリリリース10月予定
2.2.2. 採択：1,850万+200万？
2.2.3. キックオフ：10月
2.2.4. 納品：5月末
2.3. FB
2.3.1. 見積もりに記載している納品物が過不足ないか？
2.3.2. 納品物の粒度（VNに伝えるために詳細に書きたいが、日本側の体制・時間・予算が心許ない）
2.3.2.1. テンプレを作ろうとしている 福さん／福田さん
2.3.3. 瑕疵対象 VNとの契約と一致しているか？（彼らに対する瑕疵責任はあるのか？） 何を持って、瑕疵とするのかは顧客と握っておきたい（受入試験、総合試験をパスした機能が、動かない場合だけを瑕疵にしたい）
2.3.4. 開発スコープの合意 どの案件も要件が膨らみがち。 見積もり、開発スコープが正式にFixする前に、開発が始まることは危険（顧客との関係による） ブリッジSEの当たり外れで、日本側の工数がブレる 日本側：要員計画の精度が低い（「本業で忙しくなったから、タスクができてません」という事後報告が多すぎる）
3. 日の丸
3.1. 福さん1on1
3.1.1. 補助金申請 (もの補助／事業再構)
3.1.1.1. BizDevチーム
3.1.2. アイディエーション (デザインスプリント)
3.1.2.1. Xxチーム 鶴田さん
3.1.3. 要求分析
3.1.3.1. 福さん
3.1.3.1.1. やってないPJTもある
3.1.3.1.2. 要求仕様兼プロジェクト計画書を用意した
3.1.4. 要件定義
3.1.4.1. 福さん
3.1.5. 基本設計 (DB含む)
3.1.5.1. XXさん
3.1.6. 詳細設計→コーディング →ユニットテスト→結合テスト
3.1.6.1. オフショアチーム
3.1.6.1.1. ブリッジSEがひどい クロスリンクは日本語すら話せない
3.1.7. UAT
3.1.7.1. 平尾さん
3.1.8. 顧客説明 初期設定
3.1.8.1. 平尾さん
3.1.9. 納品 (最終確認・報告)
3.1.9.1. 平尾さん
3.1.10. 保守
3.1.10.1. 契約外・・・
3.2. 詳細
3.2.1. 補助金計画書：
3.2.2. 採択：
3.2.3. 納品：
3.2.4. キックオフ：
3.3. FB
3.3.1. 見積もりに記載している納品物が過不足ないか？
3.3.2. 納品物の粒度（VNに伝えるために詳細に書きたいが、日本側の体制・時間・予算が心許ない）
3.3.2.1. テンプレを作ろうとしている 福さん／福田さん
3.3.3. 瑕疵対象 VNとの契約と一致しているか？（彼らに対する瑕疵責任はあるのか？） 何を持って、瑕疵とするのかは顧客と握っておきたい（受入試験、総合試験をパスした機能が、動かない場合だけを瑕疵にしたい）
3.3.4. 開発スコープの合意 どの案件も要件が膨らみがち。 見積もり、開発スコープが正式にFixする前に、開発が始まることは危険（顧客との関係による） ブリッジSEの当たり外れで、日本側の工数がブレる 日本側：要員計画の精度が低い（「本業で忙しくなったから、タスクができてません」という事後報告が多すぎる）
4. クーリエ
4.1. 福さん
5. 目的
5.1. 現状理解の一致
5.2. 課題定義
5.3. 打ち手を考える
6. 課題を整理するに至った経緯
6.1. 背景
6.1.1. PJT予算を食いつぶし、持ち出しで火消しをする案件が少なくない
6.1.2. このままプロジェクトが乱立すると確実にカオスになる
6.2. 原因（想定）
6.2.1. 認識の違い
6.2.1.1. クライアント認識齟齬？
6.2.1.2. 要件定義が甘い？
6.2.1.3. オフショアの品質？
6.2.1.4. 各リーダーの認識が異なる？
6.2.2. 管理対象が不明確
6.2.2.1. ①予算の認識
6.2.2.1.1. A）予算構造
6.2.2.1.2. B）PJT予算の用途
7. ①予算の認識
7.1. A）予算構造
7.1.1. クライアント全体予算
7.1.1.1. 確認事項① 事業予算の構造は認識あっているか？
7.1.1.1.1. 補助金≠事業予算ではない
7.1.1.2. 事業予算
7.1.1.2.1. 補助金申請額
7.1.1.2.2. クライアント側持ち出し
7.2. B）予算の用途 （E-plus）
7.2.1. 利益
7.2.1.1. 役員報酬
7.2.1.2. 投資
7.2.1.3. 賞与
7.2.1.4. 予算が足りない場合、利益からPJTコストへ
7.2.2. PJT予算
7.2.2.1. 余剰
7.2.2.1.1. 発生した場合は利益
7.2.2.2. リスク費
7.2.2.2.1. 使用しない場合は利益
7.2.2.3. PJTコスト
7.2.2.3.1. プロジェクトチャージ (時給換算)
7.2.2.3.2. プロジェクト経費 (交通費、ツール費)
7.2.2.3.3. 外注費
8. 解決策：見積もり方法変更
8.1. 問題点
8.1.1. そもそも契約が無い 業務責任切り分けもない
8.1.1.1. 責任の所在を明確に定義する
8.1.1.1.1. VN・JPNの切り分けを明確にする
8.1.2. どこで乖離が発生？ 何が原因？
8.1.2.1. 精度の高い見積もり
8.1.2.1.1. 要求数
8.1.2.1.2. 開発難易度
8.1.2.1.3. 緊急度
8.1.2.1.4. 標準工数
8.2. E-Plus PJT予算構造
8.2.1. 責任の所在
8.2.1.1. 全体予算
8.2.1.1.1. 利益
8.2.1.1.2. PJT予算
8.2.2. 工数見積もり方法
8.2.2.1. 全体予算
8.2.2.1.1. 利益
8.2.2.1.2. PJT予算
9. 見積もりイメージ
9.1. 見積もりタイミング① 概算見積もり
9.1.1. 構想検討 補助金申請
9.1.1.1. ・事業計画書 ・補助金申請書？ ・サービス／システムイメージ ・ステークホルダー整理
9.1.1.1.1. ・どこまでの開発を補助金で賄うかの定義 ・有識者による見積もり妥当性レビュー
9.2. 見積もりタイミング② 詳細見積もり
9.2.1. 要求定義
9.2.1.1. 要求数 ・機能一覧 ・画面一覧 緊急度 ・ローンチスケジュール 開発難易度 ・ベースシステム流用有無 ・使用技術 ・ステークホルダー数 ・外部サービス連携有無
9.2.1.1.1. ・リスク共有、機能優先度、スモールスタートなどの期待値コントロール ・標準工数のブラッシュアップ ・システムタイプ別工数パターン作成