キックオフ前に決めておくべきこと

はじめに

本記事では、システム開発プロジェクトにおいてキックオフ前に最低限決めておくべきことを整理します。

目的と背景

目的

• プロジェクト開始後の認識齟齬・手戻り・無駄な調整コストを減らす
• 関係者全員が「何を・誰が・いつまでに」やるのかを理解する

背景

• キックオフは実施したが、実は何も決まっていなかった
• 暗黙知や「普通こうでしょ」に依存してトラブルになる
• 忙しさを理由に、重要事項が後回しになる

こうした事態を防ぐため、事前合意が重要です。

スコープ

決めるべきこと

• 対象範囲（In Scope）
  • 開発対象のシステム・機能
  • 対応フェーズ（要件定義／設計／開発／テスト／リリースなど）
• 対象外（Out of Scope）
  • 今回はやらないこと
  • 将来検討事項

👉 「やること」よりも「やらないこと」を明確にするのがポイントです。

体制図

明確にすべき役割

• プロジェクトオーナー（最終意思決定者）
• プロジェクトマネージャー
• 開発リーダー
• メンバー（担当範囲）
• 外部ベンダー／協力会社

ポイント

• 意思決定者は誰か
• 承認が必要な粒度
• 不在時の代理

体制図は1枚の図にして共有すると効果的です。

---

問い合わせ窓口

決めておくこと

• 問い合わせ先（誰に聞くか）
• 問い合わせ方法（Slack／Teams／メールなど）
• 対応時間・SLA（即時？1営業日？）

よくある失敗

• 「とりあえず全員にCC」
• 窓口不明で対応が遅れる

窓口一本化は小さなようで大きな効果があります。

スケジュール

事前に合意すべき内容

• 全体スケジュール
• 各フェーズの開始・終了日
• 休日・繁忙期の考慮

注意点

• 理想論ではなく現実的な日程
• バッファの有無とその理由

「なぜこの日程なのか」を説明できることが重要です。

マイルストーン

設定例

• 要件定義完了
• 基本設計レビュー完了
• 開発完了
• 総合テスト完了
• リリース判定

ポイント

• マイルストーンごとに成果物と完了条件を明確に
• 「何をもって完了とするか」を言語化する

納品物

具体例

• 要件定義書
• 設計書（基本／詳細）
• ソースコード
• テスト仕様書・結果
• 手順書・運用資料

確認すべき点

• フォーマット
• レビュー有無
• 納品タイミング

「ドキュメントは作るが、どこまで書くか」は必ず合意しましょう。

リスク

事前に洗い出すべきリスク

• 要件未確定
• キーパーソン不在
• 他プロジェクトとのリソース競合
• 技術的な不確実性

対応方針

• 発生確率と影響度
• 回避策・軽減策
• 誰が管理するか

リスクは「出すこと」自体に価値があります。

その他

決めておくと楽になること

• コミュニケーションルール
• 会議体（定例MTGの頻度・参加者）
• ドキュメント管理場所
• 課題管理方法（Jira／Backlogなど）