プロジェクトを停滞させる「ダメ課題リスト」の改善法： 榊巻亮の『ブレイクスルー備忘録』（1/2 ページ）

プロジェクトを始める前に課題を集める「課題リスト」は、プロジェクトの方向性や成否を決める重要なツール。正しく的を射た課題リストを書くためのポイントを解説する。

[榊巻亮，ITmedia]

この記事は榊巻亮氏のブログ「榊巻亮の『ブレイクスルー備忘録』」より転載、編集しています。

「課題リスト」にも“お作法”がある

　プロジェクトに携わるなら、「課題リスト」は必ず必要になる。

　プロジェクトを始める前に、広く現場から課題を集めることもあるだろう。プロジェクトが始まってから、解決しなければならない問題を課題としてトラックしておくこともある。

　ところが、その書き方はあまり共有化されておらず、各自が思い思いに書くのが常だ。

　ただ、お茶や武道の世界に“お作法”があるように、プロジェクトの世界にも一定のお作法がある。慣れてくれば型を破っても構わないが、基本のお作法は知っておかなければならない。

課題リストで重要なこととは？

　業務上の課題をまとめる課題リストを例に、まず、ダメな例を挙げてみよう。

　例えば、「現在のシステムの問題、改善点を挙げてください。情報システム部で課題リストとして取りまとめます」というような話はしょっちゅうある。僕らがプロジェクトを手伝い始める前に、社内でこうした意見収集をしていることもよくある。

　これを“お作法を意識せずに”やると、こんな内容のものが集まる。

• システムの使い勝手が悪い
• AシステムとBシステムが連動してない
• 車両管理システムがない
• 自動でxx帳票が出るようにしてほしい
• 請求書の印刷時にプレビュー機能がほしい
• 請求書の作成に手間が掛かっている
• ハンディでの在庫管理が必要

　これらは全部、課題リストのお作法から外れている。こういったものは1000個集めても、結局、ごみと化してしまう。経験上、残念なことに、世の中の課題リストの大半がこんな感じで表現されている。

　では、課題リストのお作法とは何なのか？

　課題リストで重要なことは、「どんな状況で」「何にどう困っているのか」が表現されていることなのだ。これが表現されないと、その後のアクションにつなげられない。

お作法1：「状況」を書く

　例えば、「請求書の印刷時にプレビュー機能がほしい」というのは単なる要求である。

　要求だけ書かれても、状況（今何が起こっているのか）が書かれていないと、単純に「プレビュー機能を作っておしまい」という解釈になる。これだけでは、本当にプレビュー機能が必要なのかも疑わしい。状況をひもとき、根っこの問題に手を打たなければ、上っ面の対策をするだけになってしまう。

　もしかしたら、「請求書の金額が間違って表示されることがあるため、印刷してから全件チェックしている。だから印刷前にプレビューできる機能がほしい」のかもしれない。

　もしそうだとすると、プレビュー機能を作るのではなく、そもそも「金額間違い」を是正しなくてはならない。金額間違いがなくなれば「プレビュー機能」など必要ないし、他の問題も連鎖的に解決する可能性がある。

　こんなふうに、「状況」が書かれていないと、根本原因を見つけるのが難しくなる。