[ゼロから始めるプロジェクトマネジメント] すべてのやることに締切を書いて、優先度順に並べよう
情報システム室の進地@日比谷です。
前回で「すべての依頼、タスク、ストーリーを一箇所」に集めてもらいました。今回はこの続きです。一箇所に集めたやることのリスト。これをどうするのかについて書いていきます。
すべてのやることに締切を書く
目の前にはすべてのやることを集めたリストがあります。やることのリストは100や200、下手をすれば1,000を超える数があるかもしれません。圧倒されますが、「これも現実」と受け入れて気合を入れましょう。
さて、ここからまず行うのは各々のやることに締切を書いていくことです。締切を書いていくときのポイントは次の通りです。
- 誰かと約束済みの締切はそのまま記入する。
可能なら赤字で記入するなど目立つように記入する。 - 誰ともまだ約束していないなら
- かかりそうな時間や希望などを勘案しつつイメージで締切を決めていく
- 締切がないやることに対しても可能な限り締切を設定する
- 定期的なやること(定常タスク)には締切は設定しない
重要なことは誰かと約束した締切
と誰とも約束していない締切
をはっきりと区別することです。その意味で最初の1だけでも必ずやってください。
やることを優先度順に並べる
締切を設定したら、次はやることを優先度順に並べます。ここで大切なのは締切が近い=優先度が高いではない
ということです。もちろん、大体において締切が近いものは優先度も高くなりがちなのですが、必ずしもそうはならないことを頭に入れておいてください。
例えば、
- 今日の午後14時までに資料をお客様に届ける
- 基本コンポーネントのアーキテクチャ案を今週中にまとめる
という二つの極端なやることがあったとして、前者は明らかに急ぎの要件ですが、後者の方が優先度が高いという判断はありえます。プロジェクトの目的により資するのは後者である可能性は十分にあります。それに前者は誰かに頼めるかもしれません。届けるだけならバイク便などプロの力を借りることもできます。
つまり、優先度を考えるときは方法や実現容易性はいったん傍に置いて、プロジェクトの目的に照らして重要かどうかで判断
してください1。従って、誰が担当するか?といったこともこの時点では考えないようにしましょう。
ところで、紙とペンでやることを書き出した場合、優先度順に並べるってどうするの?と思ったかもしれません。簡単です。やること毎にハサミで切り分けて、並べ替えればOKです。付箋がより便利かもしれませんね。
定常タスクと締切のない低優先度のやることの扱い
この時点で締切がないのは
- 定常タスク
- 低優先度のやること
の二つがほとんどだと思います。
まず、前者の定常タスクですが、別の一覧に切り出してください。そして、後者の低優先度のやることは記録だけ残して削除
しましょう。紙で行っているなら上から別の紙で覆ってしまい見えなくするのも良いです。
それじゃ困る!どうしてもこれはやりたいんだ!
そのようなやることがありましたか?であれば、締切をちゃんと設定して優先度順に並び替えましょう。
やること一覧をメンテナンスし続けるのがPMの仕事
締切が書かれて、優先度順に並べられたやることリストと定常タスクリストができたら、プロジェクトメンバー、ステークホルダ全員の目に触れる場所に掲示しましょう!
このやることリストがプロジェクトの羅針盤
になります。上から順番に優先度の高いものから攻略していくのです。具体的にどう攻略していくのかはプロジェクトメンバーの力を借り、頼りましょう。PMである貴方の仕事は、最優先が何かを常に示し続けることとその締切を明示することです。羅針盤を使って船が遭難しないようにすることです。
やることリストをメンテナンスし続けること
がプロジェクトを通してPMの最も大切な仕事になります。
プロジェクトは外部要因、内部要因、様々な影響を受けて変化していきます。船が様々な状況(波、風、船員の健康状態など)に対応しなければいけないように。
要注意なのは、このやることリストを不動不変のモノ
として、プロジェクト関係者に守らせることがPMの仕事ではないということです。
そうではなくて、状況に合わせて柔軟にクイックにやることリストをアップデートし続けること
がPMの仕事です。ですから、締切も優先度も変わりゆくモノであるし、変わって良いし、変わっていかなくてはいけないモノであるという認識を忘れないようにしてください。
ただし、誰かと約束した締切
。これは重要視してください。これですら変えてはいけないものではありません。ありませんが、変える時は約束した相手への十分な説明と同意を得る必要があることを認識してください。当然ながら軽々に変えて良いものではありません。
- プロジェクトの目的が曖昧なプロジェクトがトラブルになりやすいのは、やることの優先度が決められないからなのです。 ↩