プロジェクトを進めるにあたって、必要な情報や決め事が全て決まっていることは少ないと思います。
最低限押さえておきたいプロジェクトキックオフのアジェンダを整理します。

本記事の項目は、プロジェクトキックオフのアジェンダの叩き台を想定しています。

プロジェクトキックオフのアジェンダ

目次

全体の外観がつかめるようにする。

はじめに

本計画は、hogehogeのhogehoge対応におけるhogehogeプロジェクトである。
プロジェクト完遂までは定期的な再計画を行い、メンテナンスする。

目的

hogehogeのhogehogeに伴うhogehogeを完了させる。

コミュニケーション

コミュニケーションが発生するシーンを想定し、そのコミュニケーション手段などを書く。

• コミュニケーションが発生するシーン
  • オンライン（インターネット上で実施するケース）
  • オフライン(リアルな環境で実施するケース)

コミュニケーションの同期・非同期を決めておくと良い。

管理方針

課題管理

課題管理にはhogehogeを利用する
※ツールを利用する場合には明示する

運用フロー

可能な限りフローチャートで図示する。

基本ルール（例えばBacklog）

• ステータスの定義
  • 未対応：新規課題を作成した状態
  • 処理中：課題に着手した状態
  • 処理済み：作業者が課題を完了した状態
  • 完了：チェック者が課題の完了を承認した状態
• 完了理由
  • 原則利用しない
• 件名
  • 〜が、〜を、〜する というように、主語/修飾語/述語を明確に記載する
    • 課題の目的が件名で理解できること
• 詳細/コメント
  • 5W1Hを意識し、具体的な課題内容を記述すること
  • 必ず課題/コメントに関する背景を記述すること
  • 課題を完了する基準となるゴール/成果物を記述すること

課題テンプレートの例

### 背景(なぜこの課題に取り組むのか)

### 目的(課題を取り組んだ結果、どうしたいのか)

### TODOs(何をするのか)

• 種別
  • タスク：具体的な作業が決まっている場合に設定する
  • 要望：他者に何かをしてほしいときに設定する
  • 問題：顕在化している事象に設定する
  • 質問：他者に回答を求めたいときに設定する
  • リスク：プロジェクトを進める際に懸念がある場合に設定する
    • 潜在的なリスクに気づく機会を増やすため、重要度の度合いに関わらず起票されることを期待
• カテゴリー
  • 計画：スケジュールに関わる課題に設定する
  • 環境：環境に関わる課題に設定する
  • 要件定義：要件に関わる課題に設定する
  • 開発：設計/実装/試験に関わる課題に設定する
  • リリース：リリース作業に関わる課題に設定する
• 発生バージョン/マイルストーン
  • プロジェクト立ち上げ時に決まっているロードマップを示す
• 優先度
  • 高：期限厳守の課題
  • 中：スケジュールの調整が可能な課題
  • 低：手の空いたときに対処する課題
• 担当者
  • 必ず担当者を設定し、課題の保有者を明確にすること
    • 例外として、どうしても担当者が割り当てられない場合は、未設定とし、課題が漏れないように配慮する
  • 課題が処理中のときに質疑が発生する場合は、担当者を変更することを忘れないこと
• 予定時間/実績時間
  • 課題の種別がタスクの場合に必ず設定すること
• お知らせ
  • 不特定多数をむやみにお知らせに追加しないこと
  • 明確な通知先がある場合はメンションすること

文書管理

Wiki

Wikiをいつ、誰が、どのタイミングで更新するのか決める

ファイル

どこにどんなファイルを保存するのか予め構成を決める

構成管理

構成管理にはhogehogeを使う

Git

• gitflowに従う
• pullRequestのテンプレートを定義する

# 概要

# 変更点

* 何を変更したか
* 変更した理由

# 残作業
残作業がわかってればレビュアーの為に書いておく

# 関連項目
関連するIssueとか書く

# 心配事、不安点など
〜が不安なので、重点的にレビューしてほしいとか

進捗管理

（ざっくり）定常的な進捗管理方法を定義する
※日報とか

ステークホルダー

体制

可能な限り体制図で図示した上で、詳細な情報を記載する。

拠点	担当者	連絡先
東京	作業者A	メールアドレスとか
東京/札幌	自分	電話番号とか
東京	顧客A	連絡のルールとか

役割

凡例にしたがって、役割を明確にする。
未定の場合は、可能な限りプロジェクトキックオフの場で決める。
どうしても決まらない場合は、いつまでに誰が決めるのか、プロジェクトキックオフの場で決める。

担当者	管理	計画	見積もり	調査	設計	開発	検証	環境	リリース
作業者A	▲	▲	▲	✕	✕	✕	✕	▲	▲
顧客A	◎	◎	◎	▲	▲	▲	▲	◎	◎
自分	◯	◯	◯	◎	◎	◎	◎	✕	✕

凡例
◎：実行責任者　◯：説明責任者　△：サポート　▲：報告先

スコープ

前提条件

プロジェクトの前提条件を箇条書きで列挙する。
ステークホルダーで認識共有を行う。

優先順位

全部大事という曖昧な設定は避ける。

スコープ	1	2	3	4	5
Quality（品質）	→	→	→	→	→
Cost（コスト）	→	→
Delivery（納期）	→	→	→

成果物

で作成される成果物など

計画

• プロジェクト計画書
• 予算管理表

設計

• システム概要図
• サーバ構成図
• ユースケース図
• シーケンス図

開発

• ソースコード
• レビュー記録

検証

• 試験計画
• 試験手順書
• エビデンス

環境

• 環境構築手順

リリース

• リリース計画

スケジュール

WBS

WBSにはhogehogeを利用する

スプリント

定期的なイベントなど

リリース

リリース（ローンチ）日

コスト

想定される予算など
メンバーが流動的な場合、リソース計画も書いておく

最後に

一般的な指標として、PMBOKがあるが、全てを教科書どおりにまとめると、堅苦しく分かりづらい内容になりがち。
キックオフの参加メンバーが理解しにくい状態にならないように配慮する。