パーキンソンの法則に打ち勝つ方策
ここまでパーキンソンの法則について駆け足で見てきたが、私たちにとってより重要なのは、この法則とは何かを知ることではなく、法則に打ち勝つ方策を知り、行動に移すことである。要するに、午前9時から働いているにもかかわらず、夜の11時になっても仕事が終わらないような状況を回避する方法を学ぶことが大切なのである。
とはいえ、パーキンソンの法則に打ち勝つのはそう簡単なことではない。とりわけ、大規模なプロジェクトに携わるチームは、与えられた時間に合わせてスコープを無駄に押し広げたり、仕事を先延ばしにしたりしがちになる。
チームがこのような状況に陥るのを防ぐ良策は、プロジェクトの早い段階でキックオフ会議を開催し、次に示す事柄を実行に移すことである。
1. プロジェクトの「ビジョン」と「ドライバー」を明確にする
仮に、あなたが上司から大量のファイルの束をいきなり手渡され「アルファベット順に並び替えて欲しい」と頼まれたとしよう。また、あなたには、それらのファイルが「そもそも何なのか」「組織にとって重要なものなのか」「なぜアルファベット順に並び替える必要があるのか」といったことが一切わからなかったとする。
このような場合、その仕事に取り組む意欲は持てないはずである。
その逆に、自分たちの仕事が組織全体にとってどのような意味を持ち、どういった位置づけあるかを理解しているチームは、効果的な仕事をし、創造性と弾力性にも富んでいるとの調査結果がある。したがって、プロジェクトの開始時には以下の2点を明確にしておくことが必須となる。
- ビジョン：そのプロジェクトの価値とは何か
- ドライバー：そのプロジェクトは、自分たちにとってどのような意味があるのか
この2点を明確にすることで、プロジェクトチームのメンバーは自分の仕事がもたらす効果を理解し、仕事に取り組む意欲を高めて、与えられた仕事やマイルストーンに対してオーナーシップ（ないしは、当事者意識）を持てるようになるのである。
2. 役割と責任を明確にする
どのようなプロジェクトであっても、多数のチームと人員が携わる大規模プロジェクトでは、メンバー全員の役割と責任を明確化することがきわめて重要となる。その作業を行う際に便利に使えるのが「DACIフレームワーク」だ。この「DACI」とは、以下の頭文字をとった言葉である。
- Driver（ドライバー）：プロジェクトのステークホルダーを集めて必要な情報を集約し、合意した期限までに意思決定を得る責任者。この人がプロジェクトのオーナーである場合もある。
- Approver（承認者）：意思決定する人
- Contributor （貢献者）：意思決定に影響を与える可能性のある知識・専門性を持った人。意思決定に対する発言権はあるが、意思決定の権限は持たない
- Informed（情報の受け手）：最終決定について知らされる人たち
こうしたフレームワークを使い、メンバー各人の役割と責任を明確にすることで、プロジェクトにおける責任転嫁やソーシャルローフを回避することが可能になる。
役割と責任の明確化には、プロジェクトにおけるコミュニケーションやフィードバックに関するメンバーの期待値を理にかなったものへと調整する効果もある。さらに、DACIフレームワークを使用してプロジェクトにおける最終的な意思決定権者を決めることは、プロジェクトの無駄な拡大や長期化を招く「無意味な修正・提案」を低減させることにもつながる。
3. プロジェクトの範囲を定義する
プロジェクトがパーキンソンの法則にとらわれないようにするうえでは、キックオフ会議でプロジェクトの範囲に関する合意を形成しておくことも重要だ。
こうして対応範囲のガイドラインをしっかりと定めることで、パーキンソンの法則が発動する可能性を低減させることができる。言い換えれば、プロジェクトのスタート後に、チームが範囲を無駄に拡大させて、自分たちの作業を増やし、複雑化させてしまう事態を回避することが可能になるのである。
なお、プロジェクトの範囲を定義するステップは、プロジェクトを収納する「箱」を作る作業と言える。その箱のサイズは、変数の定義によって決定づけられる。これにより、作業の増大に対して、スケジュールを変更することなく柔軟に対処することができるようになる。
4. トレードオフの対象を決める
いまは不確実性の時代である。プロジェクトのキックオフ会議で対応範囲やスケジュールをしっかりと定めたとしても、プロジェクト始動後に予期せぬ事態が発生し、プロジェクト全体のスコープやスケジュールの大幅な変更を余儀なくされるリスクがある。
そこで重要になるのが「プロジェクトにおいて何を優先させるのか」「何らかの事象が発生したときに、何を切り捨て、何を生かすのか」など、「トレードオフ」の対象を明確にしておくことだ。これにより、不測の事態の発生によって土壇場での調整が必要になったときにも、余裕をもって適切に対処・対応することが可能になる。
例えば、プロジェクトの「タイミング（スケジュール）」「範囲」「予算」は、プロジェクトにおける重要な要素である。ゆえに、キックオフ会議の際にそれぞれの優先順位づけをはっきりとさせておくことが必要とされる。
ここで、あなたのチームが、自社のユーザーカンファレンスの開催に合わせて新しいプロダクトをリリースしようとしているとする。この場合、範囲や予算よりも、タイミングが重要な要素となる。そのため、プロダクト開発の進捗が滞ったときには、リリースのタイミングをカンファレンスの開催に間に合わせるために、範囲を狭めたり、予算（開発コスト）を膨らませたりするといったトレードオフの判断が求められることになる。
このようなトレードオフの対象をプロジェクトのスタート時点で決めるのは、あまり心地の良いことではない。ただし、トレードオフの対象を事前に決めておくことは、想定外の局面を迎えたときに間違いなく役に立つのだ。
ちなみに、プロジェクトのスケジュールを守るために対応範囲を狭めるというトレードオフは、与えられた時間に合わせて範囲を拡大させてしまうパーキンソンの法則的な行動とは真逆の行動と言える。
5. タイムラインを設定する
プロジェクトではよく、タイムライン（スケジュール）を決めたうえで対応範囲をはじめとする諸々の事柄が決められる。そのため、プロジェクトのキックオフ会議を催すにしても、会議の最後の議題としてスケジュールの検討が行われることはあまりない。ただし本来的には、プロジェクトのスケジュールは最後に決めるべき事柄と言える。
例えば、あなたが自宅を建設する場面を想像していただきたい。その際、建築事業者に対して「このサイズで、この見本とまったく同じ外観の家を、この日までに建ててください」といったかたちで仕事を依頼することはまずないはずだ。その代わりに、あなたと事業者との間で、あなたの希望と、希望をかなえるために必要な作業に関する話し合いがもたれ、そこで決められた内容に沿って工期に関して協議し、合意を形成するのが通常である。
こうしたスケジュールの決め方は、すべてのプロジェクトに適合するものだ。要するに、どのようなプロジェクトであれ、そのスケジュールは、少なくとも、すべてのメンバーが対応範囲に関して合意したのちに決定すべき事柄なのである。
また、スケジュールを作成する際には、プロジェクトにおけるマイルストーンやその期限を詳細に設定する必要もある。さらに、前出のウィグナル氏は「グループが定めたプロジェクトの目標や期限をサブグループと共有する際には、すべての物事を慎重に進める必要がある」と指摘している。
いずれにせよ、プロジェクト全体の期限が迫っていなくても、個々のメンバーやチームの作業の締め切りは常に目前にある。そして、メンバーやチームがスケジュールどおりに作業をこなし、小さな成功を積み上げていくことでプロジェクト全体の勢いは増し、メンバー全員のモチベーションも高まっていくのである。
TIPS
プロジェクトのスケジュールは週単位、ないしは月単位ではなく、日単位で設定するのが理想である。ある研究によれば、スケジュールを細かく設定することで、仕事の緊急性を高める心理的な変化を人にもたらすという。
