初めてPMとして複数人でプロジェクトを回したのでそのときに何をやったか備忘録として残して置く
これまで1人プロジェクトがほとんどでチームで動く機会なんてなかったのでかなり新鮮な気持ちだった
なお前提知識として下記の本は読みました
アジャイルなのかウォーターフォールなのかはっきりしろという火の玉ストレートはご勘弁ください
また、SIerの方から見たときになんだコイツとなりそうなこと言ってそうですがそれも素人に毛が生えた程度なのでご勘弁くださいｗ
PJ全体の流れ・PMとしてやること
- PJキックオフ
- キックオフ資料の作成
- Todoの洗い出し
- リスクの洗い出し
- ステークホルダーの洗い出し
- ガントチャートの作成
- チームビルディング
- キックオフ資料の作成
- チーム作業
- Todoの洗い出し
- リスクの洗い出し
- ステークホルダーの洗い出し
- ガントチャートの修正
- 実行・スプリント
- 朝会
- スプリントレビュー
- バックログの作成および、整理、スケジュールの確認
- PJの振り返り
- その他・雑用
- タスク管理がしやすいようにボードのフィルタリング設定いじったり
- 定期的にSlackチャンネルに通知が飛ぶようにしたり
- 朝会
- スプリントレビュー
- チーム時間
PJキックオフ
- これからPJがスタートするよ！という会議がPJキックオフ
- この会議までにキックオフ資料の作成をPMで行います
- いわゆるプロジェクト憲章的なもの
- このタイミングでPMとして最低限抑えないといけないものは目的と目標です。目的がブレなければPJはなんとかなります。
- 目的：実現を目指すあるべき状態、未来への行動を方向付けるもの 概念が多め
- 目標：目的に達するために、目印になるもの 具体的に
- キックオフ資料の雛形は下記を参考に
キックオフ資料を作成するにあたって、いくつかの作業をまずはPM一人で行います。このあとチームで作業したりするのでこの時点ではそこまで完璧でなくて大丈夫です
- Todoの洗い出し
- いわゆるWBS分解図に近しい作業をしていきます
- 本来の作業は最終的な成果物から何をしなければいけないか洗い出して行く作業ですが自分の場合そういうのを作成する経験値が足りなかったのでホワイトボードを使いいい感じにやりました
- PJを達成するにはなにが必要なのかホワイトボードに書いていきます。このとき、大きな単語から適当に書き出して行くとドリルダウンしやすいです。例えば「資料作成」とか大きな枠で単語を書きます。そうすると、資料作成というのは「運用設計資料」なのか「稟議申請用資料」なのかいろいろと掘り下げることが可能です。コツはとにかく頭に浮かんだPJを達成するために必要なことを書き出して行くことです
- これ以上、掘り下げることができないとなったらTaskの洗い出しが完了です。このタイミングで各Taskに対して下記の項目をわかる範囲で書き込みます。
- Taskの目的
- Taskの達成基準
- Taskの達成方法
- いわゆるWBS分解図に近しい作業をしていきます
- ガントチャートの作成
- 何をやらなければいけないのか洗い出しができたのでそこに、「いつすべきか」「どのくらいかかるか」という時間の要素を加えてガントチャートの作成をしていきます
- ガントチャート作成にあたりまずそのTaskにどのくらい時間がかかるのか見積もりをします。このとき、見積もりの時間は1週間（7日間）または2週間（14日間）で見積もりをします。これは後述しますがこのPJの実行フェーズにおいてスクラムのスプリントの考えを取り入れているからです。また2週間以上そのTaskに時間がかかるなら、Taskの分解が不十分かもしれません。
- 各Taskにかかる見積が完成したら次に優先順位を決めていきます。このときに役に立つのがクリティカルパスの考えです。クリティカルパス上のTaskに優先的に資源を投下しておくことで必要時間を最適化していきます。
ガントチャートを引くときに「バッファは必要か」という問いがあると思いますが基本的にバッファは考えないようにします。バッファを長く取るとROIは低下します。
パーキンソンの法則に注意すると良きとのことです。我々は怠惰です
- リスクの洗い出し
- ステークホルダーの洗い出し
- 最後にキックオフ資料のステークホルダー・要求事項をまとめていきます。
- プロジェクトオーナーが自組織だった場合、そこまで大変ではないですが他部署だった場合ここでヒアリング等をしっかりと行わないと痛い目にあいます。
- 最低限PJスタート時点で権限「高」関心「高」のステークホルダーを巻き込む必要があります。自分はここを疎かにして失敗した経験があります。
これらの作業を行い、キックオフ資料を完成させます。
資料が完成したらメンバーを集めてキックオフ＆チームビルディングを行います。できればオフラインでワイワイしながらやると良きです。
キックオフの際はPJの目的・目標の説明、各メンバーの役割・期待することなどを伝えていきます。また、このタイミングで疑問点などあればヒアリングしておきます。
チームビルディングも合わせて行います。チームビルディングの内容については下記を参考に
チーム作業
キックオフ資料を作成する際にやった下記の作業を再度チームメンバーを巻き込んで行います。これはPM一人の能力にはどうしても限界があるためです。特に特定領域に特化した能力を持っているメンバーの意見には耳を傾けるとリスクを下げることが可能です。
- Todoの洗い出し
- リスクの洗い出し
- ステークホルダーの洗い出し
必要であれば合わせてガントチャートの修正も行います。
実行・スプリント
やることの作成、ガントチャート作成、ステークホルダー特定、リスクの洗い出しすべて終わりました！となったらいよいよPJの実行フェーズです。実際にガントチャートを引いたTaskに対して人をアサインして消化していきます。
どうPJを回して行こうかと考えたときにいくつかのスクラムの考え方を取り入れることにしました。
※これが正しいとは思っていませんし、PJが大きな規模になれば破綻するでしょう。ただ事業会社の中でPJを回す分にはなんとかなりました。
取り入れた考え方は以下になります。
- プロダクトバックログ
- 本来の意味は「機能や要求、要望、修正などプロダクトに必要なものを抽出し、順番に並べ替えたプロダクトバックログと呼ばれるリスト」
- 本PJにおいてバックログは「ガントチャートに並べたTaskの残り」になります。
- PMは「順序を常に見直す」「見積を最新にする」「ゴールを達成するうえで最適な順序になるように見直す」という考えを大事にしました。
- これはPMBOK的にはおそらくNG行動になるでしょう。変更それ自体がリスクなるので最小限にすべきなんでしょう。 【PMBOKワンポイント】デスマーチを防ぐための統合変更管理
- バックログの管理は基本的にPMが行いますが必要であればメンバーからPMに連絡をして追加・削除を行います
- スプリント
- 「スクラムでは最長一か月まで固定の期間に区切って、繰り返し開発を行います。この固定期間のことをスプリントと呼びます」とのことです。
- 本PJにおいてもスプリントを設けました。これは1週間で固定します。スプリントの良さは特定の期間で評価を繰り返すことです。これによってアサインしたTaskがうまくいっているのか、いってないのか確実にPMが判断することができます。
- 1週間で評価を繰り返すため、Taskにかかる時間の見積も基本的に1週間単位で切ります。
- デイリースクラム
- いわゆる朝会、最低限下記をチーム内で共有します。
- 昨日やったこと
- 今日やること
- 困っていること
- 人数にもよりますが基本的に15分で済ませます。デイリースクラムは問題解決の場ではないため、問題があった際は問題解決に必要な人を集めて別途会議をセットします
- デイリースクラムは進捗報告の場ではなく、問題発見の場
- いわゆる朝会、最低限下記をチーム内で共有します。
- スプリントレビュー
- スプリントの成果をレビューします
- スプリントレビューで話し合うことは下記
- スプリントの成果について
- スプリントで完成しなかったバックログの項目について説明する
- スプリントでうまくいかなったことや、直面した問題、解決した方法について議論する
- バックログについて追加すべき項目も有無について議論する
- 人のアサインもスプリントレビューで行います。
- スプリントレビューで使う資料は下記を参考に。
実行フェーズではスプリントを繰り返し行うことでPJを前に進めていきます。PMとしてはバックログの管理（ガントチャートの管理）が最重要事項になります。
PJの振り返り
PJが終了または定めた期日になった場合、PJの振り返りを実施をします。
キックオフが「PJがスタートするよー！」という合図なら振り返りが「PJの終了だよー！」の合図です。
PJの振り返りで使う資料は下記を参考にしてください。
めも・感想
- PJスタート時点でPJ達成に必要なスキルを持ったメンバーが1人もいないと詰む。また、１人でもだめ。なぜならその人がやめたら・体調不良になったらPJが止まるリスクを孕むから。理想をいうと特定の領域の知識を持った人が2人いるといいんでしょうが事業会社の情シスとなると難しいのか
- ステークホルダー管理重要。特に権限強めの人を抑えておかないと後でどんでん返しを食らう
- 目的さえブレなければあとPJはなんとかなりそう。
- PMBOOKもスクラムもあくまで目的を達成するためのフレームワーク・手段だから。
- PMとしては「どうしたら目的を達成することができるのか」に注力する。手段がブレるのはOK。
コメント