PJの基本動作を押さえる～課題リストのお作法～

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

プロジェクトを始める前に、広く現場から課題を集めることもあるだろう。
プロジェクトが始まってから解決しないといけない問題を課題としてトラックしておくこともある。
ところがその書き方、お作法はあまり共有化されていない。各自が思い思いの書きっぷりで書くのが常だ。

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

お作法を無視した課題リスト

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

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

これらは全部、課題リストのお作法から外れている。だからこれを1000個集めても、わりとあっさりゴミと化してしまう。
（この時点で何が悪いのか指摘できるなら、この続きは読まなくてもいい。指摘できないなら読んでおいて損はないと思う）
経験上、世の中の課題リストの大半がこんな感じで表現されている・・・。

では課題リストのお作法とは何なのか？
課題リストで重要なことは、「どんな状況で」「何にどう困っているのか」が表現されていることなのだ。

これが表現されないと、この後のアクションに繋げられない。

お作法１「状況」を書く

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

もしかしたら、
「請求書の金額が間違って表示されることがあるため、印刷してから全件チェックしている。だから印刷前にプレビューできる機能がほしい」のかもしれない。
もしそうだとすると、プレビュー機能を作るのではなく、そもそも「金額間違い」を是正しなくてはならい。金額間違いがなくなれば「プレビュー機能」などいらないし、他の問題も連鎖的に解決する可能性がある。
こんな風に、「状況」が書かれていないと、根本原因を見つけにいけなくなる。

お作法２「困っている事」を書く

例えば、「AシステムとBシステムが連動していない」は単なる状況だ。
前述の通り状況を書くこと自体はとても大事なのだが、状況だけでは足りない。「AシステムとBシステムが連動していない」ことで、「何にどう困っているのか」を書いて欲しい。

システムが連動していないので・・・
・システム間を人が手で繋いでおり、手間が掛かっている、のか、
・システム間のデータ不整合が発生し、顧客サービスに悪影響が出ている、のか、
・システム横断でのデータ分析が出来ずに、営業機会を逃している可能性がある、のか
・株主要望である決算早期化が実現できずにいる、のか・・・・

「システム間の連携ができてない」という状況ひとつ取っても、「困っている事」は無数に考え得る。
同じ状況でも、部署や担当者によって困っていることは違うかもしれない。

「AシステムとBシステムが連動してない」
とだけ言われて、「じゃあ、システムをつなぎましょう」となったとしよう。システムを一つに統合しましたと。
でも、困っていることは「システム横断でのデータ分析が出来ずに、営業機会を逃している可能性がある」だった。となると、システム間をつなぐだけではダメで、適切な粒度で分析して営業につなげる機能を作る必要があるはずだ。そもそも、適切な粒度でデータを保持できるように業務の流れも見直さなくてはならないかもしれない。そこまで考えないと、結局「困りごと」は解消されないことになる。

困りごとをハッキリさせることで、打つべき施策の過不足が分かるようになるのである。

お作法３「要望」は書いても良いが、あくまで"参考"

正直、現場から「要望」を広く集めると、すごい玉石混交具合になる。そして95％は石だ。よほど全体を見ている視点の高い人でない限り、表面的な改善・対処の案を挙げるのが精一杯。
僕らプロでも、現状と困り事を確認し、真因の分析をして、ようやく効果的な施策を導き出せる。思いつきの改善案を数百個集めても使えるのは数個と思った方がいい。

それよりも、「状況」と「困りごと」をしっかり教えて貰うことが重要なのだ。「状況」と「困りごと」が根っこの課題を見つけ、最も効果的な施策を考える元データになるのである。

ちなみに、この例は「業務上の課題」をまとめる課題一覧を例に取っているが、「プロジェクト運営上の課題」の場合も同じ考え方になる。
例えば
・経理部と資産計上のタイミングについて合意できていない
・外部システム連携の仕様が詰まっていない
といった類のものだ。これも、どんな状況で、何に困っているのか書くのが原則。

・経理部と資産計上のタイミングについて合意できていない。プロジェクトとしての案はできているのだが、経理部への説明が滞っている。10月までに合意できないと、xxに影響がでる。

という感じの書き方になると、課題の状況も重要度も一発で分かるようになるはずだ。

まとめ

「課題リスト」には、「状況」と「困っていること」をセットで書くこと。

「①今こういう状況で」＋「②こんな風に困っている」＋「③だからこうして欲しい」という構造で書くのが基本的なお作法になる。③は書いても書かなくてもいい。

例えば、
①システム間の連携が無く、人が手加工してデータ連携しているため、
②入力ミスが多くて補正に時間がかかっている
③だから自動連携して欲しい

例えば
①車両管理がシステム化されておらず、個々にExcel管理しているため
②会社全体で集中購買ができず、コスト高になっている可能性がある
③だから、車両管理を全社横断でやりたい

という感じだ。
③はあっても無くても良い。
①②があれば問題を深掘り原因を見つけ、最適な打ち手を打てるようになる。
①②はどちらが欠けてもダメだ。セットで必要。

課題リストと名が付くものを見たら、書きっぷりを見てみてもらいたい。
①だけ、③だけ・・・となっているんじゃないかな。