キックオフMTGチェックリスト・合意事項

HackⅡ 開発委託 — 委託先との確認・合意テンプレート

作成日: 2026-05-25 | バージョン: 1.0
このドキュメントはキックオフMTG当日に委託先と一緒に確認し、双方が署名・承認すること。

1. 事前共有資料の確認

MTG前に委託先が読んでいることを確認するドキュメント一覧：

ドキュメント 読了確認 質問事項
docs/00_master/BRD.md（ビジネス要件定義書） □  
docs/00_master/architecture.md（アーキテクチャ図） □  
docs/00_master/stakeholders.md（関係者・ユースケース） □  
docs/00_master/non_functional_req.md（非機能要件） □  
docs/00_master/legal_compliance.md（法規制） □  
docs/01_features/feature_01_hackall/requirements.md □  
docs/01_features/feature_01_hackall/api_log_spec.md □  

2. 「仕様変更はどう扱うか」の合意

仕様変更は開発中に必ず発生します。事前に決めておくことで紛争を防ぎます。

2-1. 変更管理フロー

仕様変更の要望発生（クライアント or エンジニア）
    ↓
[GitHub Issue で変更要望を起票]
  - タイトル: [変更] 〇〇機能の△△を修正したい
  - 現状の仕様（スクリーンショットや仕様書引用）
  - 変更後の仕様（具体的に）
  - 変更理由
    ↓
[エンジニアが影響範囲・工数を見積もり]（3営業日以内）
    ↓
[クライアントが承認/却下を決定]（3営業日以内）
    ↓
[承認された場合] スプリントに組み込み → 実装
[却下された場合] Issueをクローズ

2-2. 変更の種別と扱い

種別 定義 対応
軽微な変更 UIのコピー変更・バグ修正・小規模な表示調整 当初契約内で対応
中規模な変更 既存機能の仕様変更・新規APIエンドポイント追加 追加工数として別途見積もり・承認後実施
大規模な変更 設計思想の変更・DBスキーマの大幅変更 追加契約として協議

合意:
□ クライアント確認済み
□ 委託先確認済み

3. 「テスト・品質」についての合意

項目 合意内容 確認
ユニットテストカバレッジ 80%以上 を納品条件とする □
E2Eテスト 主要ユーザーフロー（B-1〜B-6）を全網羅 □
パフォーマンステスト p95レスポンスタイムが仕様値以内であることをリリース前に確認 □
セキュリティテスト OWASP ZAP スキャンをCI/CDに組み込む □
テストコードの所有権 テストコードもソースコードと同等の成果物として納品する □

合意:
□ クライアント確認済み
□ 委託先確認済み

4. 「技術的負債」についての合意

4-1. Regalisの方針

HackⅡは 長期運用（5年以上） を想定したプロダクトです。

✅ 優先する価値:
  - 6ヶ月後に自分以外のエンジニアが読めるコード
  - テストが充実していて変更を怖くない設計
  - 機能追加が容易なモジュール設計

❌ 避けること:
  - 「とりあえず動く」ハードコーディング
  - テストなしの実装
  - ビジネスロジックをUIコンポーネントに混在させる設計

4-2. コードレビューの合意

項目 ルール
PRのサイズ 1PRは最大500行の差分を目安（大きくなる場合は事前相談）
レビュータイム PR作成から2営業日以内にレビュー完了
レビュアー 委託先チーム内で1名以上のレビュー後にクライアントへPR送付
マージ権限 mainブランチへのマージはクライアントの承認後のみ

合意:
□ クライアント確認済み
□ 委託先確認済み

5. 「秘密保持・知的財産」についての合意

項目 内容 確認
NDA締結 委託先エンジニア全員（個人含む）がNDAに署名済みであること □
AICS™アルゴリズム 特許出願中技術のため外部公開禁止。論文・ブログ・SNSへの掲載も不可 □
ソースコードの帰属 本開発で作成したコードはすべてRegalis Japan Groupに帰属 □
開発者クレジット 委託先が成果物をポートフォリオに載せる場合は事前承認が必要 □
退職後の義務 契約終了後も秘密保持義務は継続（期間: 5年） □

合意:
□ クライアント確認済み
□ 委託先確認済み

6. 開発フロー・コミュニケーションの合意

6-1. 定例MTG

MTG 頻度 参加者 目的
スプリントレビュー 2週間毎 Regalis + 委託先リード デモ・フィードバック
テクニカルMTG 週次 委託先エンジニア 技術的な疑問解消
障害報告MTG 随時 Regalis + 委託先リード インシデント対応

6-2. コミュニケーションツール

用途 ツール
日常的なやり取り Slack（専用チャンネル）
バグ・タスク管理 GitHub Issues / Projects
ドキュメント管理 GitHub（このリポジトリ）
緊急連絡 電話 / Slack DM

6-3. 報告義務

状況 報告タイミング 報告先
重大バグ発見 発見から2時間以内 Slack DM → 電話
個人情報漏洩の可能性 発見から即時 電話
納期遅延の可能性 予定日の1週間前 Slack + 書面
仕様の不明点 実装前（実装後の修正は工数が大きい） GitHub Issue

7. 納品・検収の合意

7-1. 納品物一覧

成果物 形式 確認
ソースコード GitHubプライベートリポジトリ □
ユニットテストコード 同上 □
E2Eテストコード 同上 □
APIドキュメント（OpenAPI 3.0） Swagger UI + YAMLファイル □
インフラ構成（Terraform） GitHubリポジトリ □
デプロイ手順書 Markdown（READMEまたは独立ドキュメント） □
操作マニュアル（顧客向け） PDF or Notion □

7-2. 検収フロー

委託先が「納品完了」を宣言
    ↓
Regalisが以下を確認（10営業日以内）:
  ① 機能仕様を満たしているか（受け入れ条件チェックリスト）
  ② テストカバレッジ80%以上
  ③ 非機能要件（パフォーマンス・セキュリティ）
    ↓
[問題なし] → 検収完了 → 支払い
[問題あり] → 修正依頼（修正期間: 10営業日）→ 再検収

8. キックオフ当日の確認事項

8-1. 委託先エンジニアへの質問リスト

MTG当日にRegalisから委託先へ確認する事項：

  1. チーム構成を教えてください。 フロント・バックエンド・インフラの担当者は誰ですか？
  2. 使用予定の技術スタックを確認させてください。 仕様書指定のスタックから変更する場合はその理由を教えてください。
  3. 過去にAI/LLM関連のシステム開発経験はありますか？ あれば事例を教えてください。
  4. テストはどのフレームワークで書きますか？ カバレッジ計測ツールは何ですか？
  5. セキュリティレビューの担当は誰ですか？ OWASP Top 10 対策の経験はありますか？
  6. AICS™スコアリングアルゴリズムの秘密保持について、チーム全員が理解していますか？

8-2. MTG終了時の確認

9. 緊急連絡先

役割 担当者 連絡先
Regalis クライアント窓口 井上幹太（代表） 別途共有
委託先 技術リード （キックオフ時に記入）  
委託先 PM （キックオフ時に記入）  

本ドキュメントの合意をもって、HackⅡ開発委託プロジェクトを正式に開始します。

  署名 日付
Regalis Japan Group株式会社 代表   2026- -
委託先 代表者   2026- -