RAID ログ作成の重要なポイント

計画どおりに進めばプロジェクト管理は簡単です。しかし想定外の問題が発生することもあります。プロジェクトで予定外のトラブルが生じてしまった場合は、変更を記録しておくことが重要です。こうすることでチームは変更を把握でき、問題から教訓を得られます。さらにこの情報を次回のプロジェクトに活かすことができるメリットもあります。

この記事では RAID ログの概要と、なぜ RAID ログがプロジェクト管理を行ううえで有効なのかについて説明していきます。

RAID ログとは？

RAID ログはプロジェクト期間中に発生した課題や問題を記録するためのプロジェクト管理ツールです。このツールはプロジェクトの計画段階で作成し、プロジェクトサイクルの全体をとおしてリスクやアクション、仮説、課題、決定事項、依存関係を記録するために継続して使用します。RAID ログを利用することで変更の追跡が楽になり、一目で情報を把握できるようになります。またポストモーテム会議で使用することで今後のプロジェクトにおいて同様の課題や問題を予防できます。

RAID は次の単語の頭文字からとって生まれた用語です。

Risk (リスク)

リスクはプロジェクトに悪影響をおよぼす可能性のある潜在的な問題を指します。プロジェクトを開始する前にプロジェクトリスクを事前に特定しておくことが大切です。こうすることで実際に問題として発生する前にリスクの解決策を特定し、プロジェクトリスクに遭遇した場合の対策をチームに落とし込むことができます。プロジェクトリスク管理を事前に実行するとプロジェクトの進行に合わせて問題が大きくなる事態を避けられます。

RAID ログのこのセクションはリスク登録簿に似ており、先を見越してリスクの特定、分析、解決を行う役目を担います。積極的にリスク登録簿を利用するチームなら RAID ログの「R」でこのツールを導入するとよいでしょう。積極的なリスク管理のほかにも、想定外のリスクが発生したら RAID ログのリスクのセクションを使用して記録できます。リスクを特定したら、プロジェクト期間中に発生したケースを想定して対応する担当者を決めておきましょう。

Action (アクション) または Assumption (仮説)

RAID ログの設定によって RAID の「A」は Action (アクション) または Assumption (仮説) のいずれかが該当します。RAID ログでは両方使用することも、どちらかを選択することもできます。どちらがチームにとってベストなのか悩んでいるなら、以下の原則に従って判断するとよいでしょう。

• アクション 頻繁に変更が行われるプロジェクトの場合

• 仮説 事前に充分な計画が必要な長期にわたるプロジェクトの場合

アクション (アクションアイテム) とはプロジェクト期間中に実行する必要のあるすべての作業や活動を指します。アクションアイテムには明確に担当者を割り当て、チームメンバー全員が各アイテムの実行責任者を把握できるようにしましょう。1 つのアクションアイテムに数名の担当者が存在する場合は、誰がどの成果物を担当するのかをはっきりと決めておく必要があります。プロジェクトマネージャーは定期的に実行中のタスクやアクションアイテムをチェックしてプロジェクトの進行状況を確認したいところです。

仮説は計画段階中にチームが予想するプロジェクトの道筋を示します。プロジェクト管理において、チームが予め確実視している大事な要素が該当します。経験や専門知識をもとに仮説が立てられます。たとえば、機械の重要な部品が安全に予定の時間に届くと推測することが仮説に該当します。

プロジェクトでは、なにもかも計画できるわけではないため、チームメンバーはプロジェクト進行中に仮説を立てる必要があります。立てた仮説を主要な場所に記録しておくことが重要です。こうすることで想定外の障害や予期していなかったプロジェクトリスクが発生しても即座に仮説の一覧を参照できるようになります。リスクや障害につながる仮説を立てた場合は、仮説が正しいかどうかを積極的に調べて問題の原因をすぐに特定できます。

Issue (問題)

問題はプロジェクト期間中に発生する想定外の事象を指します。予期していなかった事象であるためリスクとは異なります。Risk (リスク) は発生を予期している潜在的な問題ですが、Issue (問題) は突然発生します。問題が発生したら記録し、チームが問題の解決方法を参照できるようにしましょう。初期段階でこの問題に起因する別の問題が発生した場合は、記録を残しておくことで問題の原因を特定しやすくなります。 

Decision (決定事項) または Dependency (依存関係)

RAID の「A」と同様に「D」には Decisioin (決定事項) と Dependancy (依存関係) の 2 つの単語の頭文字が該当します。柔軟性の高いプロジェクトの場合、解決策にいたった決定事項を明示しておくべきです。一方、複雑なタスクで構成され、タスク同士が相互に関わっている場合は依存関係を選択するほうが理に適っています。

Decision (決定事項) はプロジェクト期間中のすべての具体的な選択を指します。つまりプロジェクトを完了に導く最終的な考えやアイデアです。どんな決定だったのか、誰が決定を下したのか、なぜその決定にいたったのかを記録する必要があります。チームがカイゼンのような反復プロセスを採用しているなら、今後のプロジェクトで向上を目指すうえでこの記録が役に立つ可能性があります。

プロジェクト管理における依存関係とは、別のタスクの完了に依存しているタスクのことです。プロジェクトの進行を妨げる可能性のある大きな依存関係が存在する場合は、RAID チャートに入力しておきましょう。依存関係を視覚化することで次のステップに進む前に完了しなければならないタスクを理解しやすくなります。ガントチャートを使って依存関係を整理することもあります。

いつ RAID ログを使うべきか

RAID ログはプロジェクトの計画段階での使用に向いています。またプロジェクトの進行中に継続して使用し、確認が必要な重要なアクションアイテムや決定事項、発生した大きな問題を記録することで最大の効力を発揮します。

RAID ログは時間をかけずに利用できる便利なプロジェクト管理ツールですが、このツールのみに依存するべきではありません。RAID ログをプロジェクトのインシデント管理として扱い、プロジェクトで大きなイベントが発生したら RAID ログに記録するとよいでしょう。チームの作業やタスク、計画を漏れなく記録できる、より強固なプロジェクト管理システムと RAID ログを併用するべきです。 

RAID ログを使用する利点

RAID ログはプロジェクト管理ツールの 1 つとして押さえておきたい有効なツールです。その理由を説明します。

すばやく情報をまとめられる

1 つの主要な場所ですばやく重要な情報を整理して表示できる点は、RAID ログを使用する大きなメリットの 1 つです。問題が発生した時点で、または決定を下した時点でプロジェクトマネージャーは RAID ログの該当する場所に手早くアクションを記録します。

今後の変更のための記録を残せる

チームはプロジェクト進行中に実施したプロセスと決定を記録する必要があります。こうすることで現在のプロジェクトで実行した変更をもとに、今後のプロジェクトで決定を下せるようになります。RAID ログを使うことで有益な情報を得られるほか、経験を今後の問題に活かすことができるのです。

テンプレート化が簡単

チームのニーズに合う RAID ログのテンプレートを簡単に作成できます。新しいプロジェクトマネージャーが加わった際や、またはチームの重要なプロセスの研修を実施する際に RAID ログのシンプルなコンセプトが強みを発揮します。RAID ログは繰り返し使用することを意図した手法です。チームのニーズに合うテンプレートを作成し、同じテンプレートをすべてのプロジェクトで利用するアプローチが最も簡単にこの目標を達成できます。

すべての決定事項を 1 つの場所で記録できる

RAID ログではプロジェクトに関連する情報を 1 つの主要な場所に集めることができます。チームメンバーが問題について適切な関係者と話し合う必要がある場合、RAID ログを見れば担当者を見つけられます。 

RAID ログは誰が何を担当しているのかがわかるだけでなく、プロジェクトのプロセスの大まかな概要としての役割も果たします。チームメンバーは進行中のアクションや最近行われた決定を一目で把握できます。各セクションはわかりやすく分類されており、最も関係のある情報を探すことができるのです。

RAID ログを使用するデメリット

RAID ログは有効なツールですが、デメリットもいくつかあります。

RAID ログだけでは不十分

プロジェクト管理の情報源は RAID ログだけでは不十分です。主要な問題や重要な依存関係、プロジェクト期間中に発生した問題を記録するツールとしては便利ですが、プロジェクトの具体的なアイテムに関してより詳しい情報を求めているなら、プロジェクト計画などのツールのほうがニーズに合っているかもしれません。 

RAID ログだけでなく、すべての情報を閲覧できる一元管理ツールを必ず利用しましょう。こうすることで部署や役割にかかわらず、チームメンバー全員が必要なプロジェクトの情報にアクセスできる環境を作れます。そして、この理想を実現するうえで最適なのがワークマネジメントツールです。 

RAID ログは定期的に更新しなければならない

RAID ログはプロジェクトマネージャーが更新しないかぎり最新の情報を保てません。新しい情報をリアルタイムで継続的に追加していない場合は、最新の情報を得られなくなってしまいます。したがってプロジェクトマネージャーが継続してログを更新できない場合は困難が予想されます。関係者が過去の情報を参照して混乱してしまう事態が生じる可能性があるため、あらゆるコミュニケーションの手段を介して継続的に情報を伝達することが大切です。

情報が多過ぎると見にくくなる

RAID ログに細かい選択まですべて記録していくと、情報にまとまりがなくなり、必要な情報をすぐに見つけにくくなる恐れがあります。RAID ログを管理するためにチーム内で取り上げる条件を予め決めておくことが重要です。RAID ログを作成する前にログに盛り込む必要がある決定事項や問題の基準をチームが明確に理解しておく必要があります。

情報が乱雑に記載されることを防ぐため、RAID ログに記録する重要な情報が何なのかを具体的にチームで決める必要があります。すると特に重要な情報がログに残り、プロジェクトの関係者は必要とする情報を簡単に参照できるようになります。

RAID ログの使い方

RAID ログはとてもシンプルです。紙に縦横の線を引いて 4 等分し、それぞれのエリアに RAID のうちのいずれかを割り当てるだけでも完成します。ただしチームメンバー全員が同じ場所で情報にアクセスできる環境があってこそ RAID ログは最大の威力を発揮します。

以下の 4 つの手順に従って RAID ログを作りましょう。

1. RAID ログを提示する最良の方法を特定する。先ほど説明したとおり、RAID ログは紙を 4 つのセクションに分割するだけで完成します。ただしこれではチームは効率的に情報にアクセスすることはできません。そこでこのログをデジタル文書に記載するのか、スプレッドシートに残すのか、あるいは別のタイプのソフトウェアを使用するのかをチームで決めましょう。

2. 予めリスクと仮説、依存関係について話し合う。事前に話し合うことで潜在的な問題および、この問題を予防する方法をチームメンバー全員が把握できます。

3. 定期的にログを更新する。RAID ログは定期的に更新しないかぎり適切な情報を保てません。プロジェクトの進行中にログを使用し、適切に更新していきましょう。

4. プロジェクト終了後に見直す。プロジェクト終了後にポストモーテム会議を行う場合は、今後のプロジェクトの改善策を話し合うため、RAID ログを活用しましょう。

ソフトウェアで RAID ログを管理する

Asana をはじめとするワークマネジメントソフトウェアを使って RAID ログを作成すると、すべてのログのアイテムを常に整理できます。明確に期限や関係者、アクションアイテムを決めることで、チームは作業の完了に向けて集中できるようになるのです。