Webディレクター解体アドベントカレンダー15日目の記事です。今日はプロジェクトマネジメントについて書きます。
市場の状況やユーザーの動向が刻々と変化していくWebサービス開発においては、如何に柔軟に不確実性と付き合っていくかが求められます。その不確実な状況に日々柔軟に対応していくためのプロジェクトマネジメント手法として、最近はアジャイル開発やスクラムというフレームワークが浸透していて、複数人がチームを組んでWebサービスを開発する時の方法論が確立されています。アジャイルやスクラムに関する書籍も多数出版されており、Web開発の現場でも当たり前のように導入されていると思います。
かつてのWebディレクターが企画から進行管理まで1人でやっていた時代から、専門職としてのプロジェクトマネージャー（PjM）が求められるようになってきました。スクラムの文脈でもプロダクトオーナーとスクラムマスターは兼任すべきではないとされており、それぞれの専門職が担当するのが理想です。
私もこれまでディレクターという肩書きでプロダクトマネジメントとプロジェクトマネジメントを兼任することも多かったのですが、肌感としてもう限界が来ていると感じます。求められる専門性も、使う頭も全く違うからです。もうWebディレクターという職種として、両方を担当していく時代は終わりかけている。そう感じたことも「Webディレクター解体アドベントカレンダー」とかいう仰々しい名前を付けた理由の1つです。ロックは死んだと言ったジョン・ライドンやヒップホップは死んだと言ったNasみたいで偉そうですが。
それでも企画やプロダクトマネジメントを行う立場の人が、プロジェクトマネジメントを兼任することもあるでしょう。いつもいつも理想的な開発チームが組めてその道の達人が揃うわけでもない。もちろんそれが理想だし組織がそうなっていないのなら体制を構築し直した方がいいけど、目の前にある現実に向き合わないといけない時もあります。
そんな時のために、企画やプロダクトマネジメントを中心にやってきた人に向けて、プロジェクトマネジメントの一番基本であり日々の業務に直結する進行管理について書いてみます。アジャイルやスクラムの詳細は各種書籍に詳しいので、何のためにやるのかという部分です。
何のために進捗を確認するのか
スクラムについて書かれた本を読んでいると、専門用語が沢山でてきます。プロダクトバックログを作って、スプリントごとにスプリントレビューとスプリントレトロスペクティブとスプリントプランニングをやってスプリントバックログを作り、日々デイリースクラムをやりましょうと。それぞれに意味があり、本にはそれぞれの意味とやり方について詳しく書かれています。それぞれ教科書に書かれた通りにやることが推奨されていて、実際その通りにやると良いと思います。
でも、根底に何のためにやるのかを本当に意識できていないと、ただ表層をなぞるだけになってしまう。ただスクラム本に書かれた手法をそのままなぞっているだけの状態、テンプレートをただ埋めているだけの状態。あくまで手法でありツールであるスクラムを使いこなすには、目的が必要です。なぜ進捗を確認して可視化するのか。なぜわざわざ開発の手を止めて開発チーム全員を集めてスプリント会をやったりデイリースクラムをやるのか。
その目的に自覚的であることと、スクラムやアジャイル開発といったフレームワークを目的のためにどう使うのか、そのイメージを持つところが、プロジェクトマネジメントの始まりだと思っています。
手を打つため
進捗を確認するのは、進捗に応じて手を打つためです。スクラムなら毎日行うデイリースクラムや、スプリントごとに行うレビューが主に進捗確認の場になると思います。それぞれ扱う期間のスコープが違い、日々の微調整を行うのか、思い切った手を打って予定を変更するのか判断していく必要があります。例えばこんな風に。
- デイリースクラム：進捗確認して微調整する場
- そろそろ終わりそうだから、次のタスクを用意しておこう
- そろそろ終わりそうだから、リリースに向けた告知文の用意などを進めておこう
- 予定より遅れてそうだから、この人には差し込みのタスクを振らないようにしよう
- 予定より遅れてそうだから、待っている間デザイナーに他のタスクを振ろう
- スプリントレビュー：進捗確認して方向変換する場
- 予定よりも順調だから、早めにリリースしよう
- 予定よりも順調だから、優先度Shouldにしていたタスクの要件を固めておこう
- 予定よりも遅れているけど、まだバッファの範囲内だから静観しよう
- このままだと間に合わないから、この要件を削ろう
- このままだと間に合わないから、他のメンバーをヘルプで加えよう
- このままだと間に合わないから、リリースを遅らせるためにステークホルダーと調整しよう
ただ開発メンバーや各プロジェクトの進捗を聞き流すのではなく、次の一手を常に考えておく必要があります。それぞれの進捗報告を聞きながら、何か手を打つ必要があるかどうか、そこに意識を持っていくのが進行管理の第一歩です。
手元に手札を用意しておく
状況に応じて手を打つためには、手元に手札を用意しておく必要があります。手札がないと、ただあたふたして終わってしまう。それでは進捗を確認する意味がありません。あらかじめどれだけ手札を用意しておけるか。それはプロジェクトが始まる時点である程度決まってきます。
プロジェクトが始まる時にインセプションデッキを作るのも、この手札を用意するためという側面も強いです。インセプションデッキの一項目にトレードオフスライダーというものがあります。
トレードオフスライダーとは「品質」「コスト」「期間」「スコープ」の4つの項目の内、何をどれくらい優先するのか決めておくことです。期限が決まっているプロジェクトの場合はリリースを遅らせるという手札は切れないし、かけられるコストが予算で決まっている場合は人員の追加が難しくなり、スコープが決まっている場合は機能を削ろうとしても限界が出てきます。もちろん全てがきっちりと計画通りに行けばいいですが、何かを優先すると何かが犠牲になるのが世の常でまさにトレードオフの関係にあります。
だからあらかじめ、どの手札は使えてどの手札は使えないか確認しておくのです。そして可能なら、最初にプロジェクトを始める時に手札になりそうなバッファを予め仕込んでおきます。よく推奨されるのは、期間と機能の両方のバッファを積んでおくことです。特に期間が決まっている場合は要注意。手元に持てるだけの手札を用意して挑む必要があるでしょう。
進行管理とは、開発メンバーの進捗を監視して遅れが出てきたら鞭を振るうことではありません。その時々の状況に応じて、適切な手札を切って軌道修正したり、ステークホルダーと調整したり、先回りして必要な準備を進めたり、とにかく手を打ち続けるためにやることです。適切なタイミングで適切な手を打つために、状況を確認しつづける。それが進行管理を行う理由です。
