DX(デジタルトランスフォーメーション)推進コンサルティング 株式会社アイ・ティ・イノベーション

ご訪問ありがとうございます！　　　　　　　　　　＜　前回　｜　目次　｜　次回　＞

2013年4月にスタートした当ブログ「新感覚！プロジェクトマネジメント」も、おかげさまで4年目に突入です！引き続きご愛顧のほどよろしくお願いします。

今回は、今でもプロジェクトの現場でそれぞれの扱い方の違いがすっきりしない、問題・課題、Todo、リスクの管理方法について考察します。

【　問題・課題とTodoとリスクの違い　】

～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～
当ブログの　【第３回】問題とは何か？　では、「問題とは、目標（あるべき姿）と現状とのギャップである」という定義をご紹介し、【第１２回】プロジェクト・リスクとは何か？　では、PMBOK第５版のリスクの定義を引用し、成果物出来高と時間の二軸による「プロジェクト・モデル」を使って、問題とリスクを対比させる形で説明しました。

あるべき姿と現状のギャップの現在進行形が問題であり、未来形がリスクであるととらえれば、問題とリスクの違いは理解しやすいと思います。実際のプロジェクトでは、問題に関しては「問題一覧」ではなく、「問題・課題一覧」とか課題という言葉がつくフォームが使われることが多いと思います。

一般的には、あるべき姿と現状のギャップの状態や事象が問題であり、そのギャップを埋めるために実施すべきことが課題とされるようです。プロジェクトにおいては、ギャップの状態や事象だけを捉えても仕方ないので、それを埋めるために実施すべき課題を管理すべきという意味で、「問題・課題一覧」というフォームが使われると解釈できます。問題と課題の違いについては、いろいろな情報がネット上に公開されていますので、そちらを参照して頂ければと思います。

さて、「問題・課題一覧」によく似た「TodoList」というフォームを使うプロジェクトもあります。「TodoList」はプロジェクトの現場だけではなく、単にやるべきことをリスト化するという目的で広く使われているものです。

―――　ここで質問です。プロジェクトにおける問題・課題とTodoの違いは何でしょう？

＜新人Ｐ子さん＞　：　「そうねえ。問題や課題はどちらも、あるべき姿と現状との間のギャップに関係するものだけど、Todoは必ずしもギャップが無いっていう違いですか？でも、プロジェクトでやるべき作業はWBSに定義されているはずだし、「TodoList」の使い方がよくわからないわ。」

＜ベテランＰＭのＭ男氏＞　：　「ふん、近頃の連中ときたら、なんでもかんでも資料化すれば良いと思っとるからかなわん！「TodoList」なんて、そんな余計な資料作るから、管理工数がかかって、PMOなんて無駄な職種が増えるんじゃ！WBSにないタスクなんか、やんなくったって大勢に影響無いんじゃ。客からフォローされたときだけ適当に対応しときゃ良いんじゃ！」

・・・　おやおや、Ｐ子さんもＭ男氏も、どうやら「TodoList」には懐疑的なようです。確かにPMBOKの索引を見ても、「問題・課題一覧」に該当しそうな「課題ログ(IssueLog)」というものはありますが、「TodoList」は「アクティビティ・リスト(ActivityList)」とも違うようだし、これといったものが見当たりません。皆様のプロジェクトでは「TodoList」をどんな風に使っているでしょうか？（※１）

【　「TodoList」の使い方　】

～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～
ここで私のこれまでの経験から、「TodoList」をどう使ってきたかをご紹介します。

１．WBSにのせるまでも無い備忘的なタスクの管理

一般的な「TodoList」の使い方としてはこれが多いのではないでしょうか？WBSにのせるまでも無いというのは、たとえばステアリングコミッティなどで宿題事項が指示され、それがシステム開発の他のタスクには直接影響しないような内容であった場合などです。

２．WBS化前の整理中タスクのリスト化

理想的には全てのタスクがWBS化された状態でプロジェクトを進める必要がありますが、現実のプロジェクトでは最初は不確実性が強い状態からプロジェクトの進行に伴いタスクを詳細化する段階的詳細化のアプローチをとります。（※２）

まだ十分に詳細化されていないが、実施すべきタスクを忘れないように「TodoList」にのせておくということがあります。なんらかの理由でWBS化が遅れている場合にも、実施すべきタスクの準備や着手が遅れないようにするために「TodoList」化します。

３．問題・課題やリスクかもしれない気になる事項のリスト化

本来、プロジェクトメンバ全員がアンテナを張って問題意識を持って、プロジェクトのどこかで起きている問題・課題やリスクを検知して「問題・課題一覧」や「リスク管理表」にのせてコントロールするのが健全なマネジメントです。（※３）

しかし、現実のプロジェクトでは「問題・課題一覧」や「リスク管理表」の運営がガチガチになっていて、簡単にはエントリーできないことがあります。そんな風通しの悪いプロジェクトでは、問題・課題やリスクへの対応が後手に回り、プロジェクト終盤で問題が噴出することが目に見えています。そこで、問題・課題やリスクかもしれない気になる事項を「TodoList」に記載して、対応漏れの防止を図ります。

このように「TodoList」は、WBSや「問題・課題一覧」、「リスク管理表」など、正規のプロジェクトマネジメント成果物からこぼれそうなものを拾う受け皿として使うことが多いと思います。不確実性のあるプロジェクトでは、こういったグレーゾーンを拾って露払いするような仕掛けを準備しておく必要があるのです。

【　Todo化しただけで問題・課題やリスクが解消される？　】

～・～・～・～・～・～・～・～・～・～・～・～～・～・～・～・～・～・～・～
たまに問題・課題を解決するためのアクションを「TodoList」に追加しただけで、問題・課題をクローズするような運営方法を見かけます。本当に問題・課題解決のアクションを明確化しただけで、問題・課題をクローズしても良いのでしょうか？

私の答えはＮＯです！

なぜなら問題・課題は、あるべき姿と現状とのギャップです。問題・課題が解消されるということは、そのギャップが無くなるということです。問題・課題へのアクションが明確になったからと言ってギャップが無くなったわけではなく、アクションが功を奏してギャップが無くなってからクローズするべきなのです。

そのことは、リスク予防策について考えてみればより明確です。「リスク管理表」にあげたリスクに対して予防対策を計画したからといって、リスクが無くなったとみなせるでしょうか？もちろん答えはＮＯです。リスクが顕在化して生じたギャップである問題・課題も、ギャップ解消のためのアクションを計画しただけでは、問題・課題が解消されたとはみなせません。

たとえばスケジュール遅延という問題が発生したとして、リスケジュールすることでオンスケに見せかけただけでは、問題解決を先送りしているという最悪のパターンに陥ってしまいます。問題・課題のクローズ条件は、ギャップの解消であるということを肝に銘じましょう！

【　問題・課題、Todo、リスクの『「超」整理法』？　】

～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～
ここまで見てきたように、問題・課題、Todo、リスクは、それぞれ違うものであり、管理方法も違うはずです。図１~図３で示すように「問題・課題一覧」、「TodoList」、「リスク管理表」に記載する内容も異なり、別々に管理することが理にかなっています。

もし、問題・課題、Todoとリスクを同じ一覧表で管理した場合には、たとえば以下のようなデメリットが考えられます。

＜　問題・課題、Todo、リスクを同じ一覧で管理した場合のデメリット　例　＞

１．「問題・課題一覧」にリスクも記載した場合、予防対策、発生時対策、トリガーポイントなどを記載する欄が無いため、効果的なリスク対策ができない可能性がある。

２．「問題・課題一覧」にリスクやTodoも記載した場合、大量のTodoの中に埋もれてしまった重大な問題・課題やリスクへの対応が後手に回ってしまう可能性がある。

３．問題・課題とリスクを同じ一覧に混在させると、既に顕在化している問題・課題に気を取られて、リスクへの対応がますます形骸化してしまう可能性がある。

さあどうでしょう？

ここまでデメリットをあげれば、問題・課題、Todo、リスクはきちんと別々に管理した方が良いに決まっていますよね！私もプロジェクトマネジメントのご支援をする際には、別々に管理することをお薦めすることがほとんどです。

しかし、ここではあえて別の可能性をさぐってみたいと思います。固定観念にとらわれていてはイノベーションを起こせませんから。そのヒントは、野口悠紀雄氏のベストセラー、『「超」整理法』の「押し出しファイリング」です。私もこの書籍を読んで刺激を受け、それまで机の上に平積みしていた書類の束を、使い古しの封筒ではなく100円ショップで購入したクリアファイルにはさんで机の上に立てるようにしていました。（※４）

『「超」整理法』の「押し出しファイリング」のポイントは、資料を分類せずに時系列に左から右に並べていくだけの単純な手順にしたことです。これと同じように、問題・課題、Todo、リスクを分類せずに、同じ一覧に登録するというやり方も成り立つかもしれないということです。

実は、当ブログの　【第３９回】トリアージでデスマーチを脱却せよ！　では、問題・課題、リスクやレビュー指摘対応残、障害対応残、仕様変更対応残、それに、顧客や社内への状況説明など想定される重たいマネジメントタスクまでも全部ひっくるめて優先順位づけするように提案しています。これはまさに問題・課題、Todo、リスクの『「超」整理法』だと言えるかもしれません！

デスマーチと言う特殊な状況とはいえ、このようなマネジメント方法もあるということは、問題・課題、Todo、リスクを同じ一覧で管理して効率化を図ることのメリットと先に上げたデメリットを、個別プロジェクトの事情に応じて天秤にかけ、ケース・バイ・ケースで使い分けすることも一考に値するのではないかと、あらためて考えさせられた次第です。

「問題・課題、Todo、リスクの違いを意識し、プロジェクトに合う効率的な方法で管理しよう！」

それでは次回もお楽しみに！　　　　　　　　　　＜　前回　｜　目次　｜　次回　＞

工藤武久

～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～
応援してくださる方は、クリックよろしくお願いします！
◆　人気ブログランキング
◆　にほんブログ村
～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～

※１　Project Management Institute, Inc.(2013)『プロジェクトマネジメント知識体系ガイド（PMBOK®ガイド）』（第5版）Project Management Institute, Inc.

※２　段階的詳細化については、当ブログの以下の回参照。
・【第２３回】プロジェクト計画書の段階的詳細化とは？

※３　プロジェクトにおける問題へのアンテナについては、当ブログの以下の回参照。
・【第２回】プロジェクトマネジメントは問題解決だ！

※４　野口 悠紀雄(1993)『「超」整理法―情報検索と発想の新システム』中公新書