プロジェクト計画書・進捗管理から続く、プロジェクトマネジメントのプロ3人の対談企画3回目は「課題管理」です。これは進捗管理と同様に、多くのプロジェクトチームが抱えている問題でもあります。気づいたときには目の前には課題の山......といったことが起こらないようにするにはどうすればいいのでしょうか？
課題管理でよくある失敗例を紹介しながら、ミスを防ぎ成功させるための方法を解説します。
早川：解決すべき課題の優先順位がつけられないままプロジェクトが進行してしまい、結局何も解決ないまま進んでしまうという事例は多いですよね。ただ最近、私はもっと気にすべきは劣後順位だと思っていて。つまり解決しなくてもいい課題という順位付けをして、下位の課題は捨てていくことが時には大切なんじゃないかと考えています。
課題ってどんどん積み上げられていくものなので、普通にしていると「やらないとやばい！」と思って深く考えないまま手をつけ始めがちなんですけど、「本当にそれやる必要あるの？」って部分を突き詰めて考えて、勇気を持って捨てる課題を決めることが大事なんじゃないでしょうか。
杉本：早川さんの意見はその通りだと思う一方で、切り捨てられない課題を無理にぶった切ってしまってうまくいかないという事例もよく見ます。
課題が膨大な量になってくると、本来1つずつ因数分解して精査する必要があるんですが、それができなくなるんですね。すると、意思決定者としてはとても全部は見ていられないから、「ここからここまで」というスコープを決めて、その範囲から外れる課題については切ってしまうんです。でも課題をあげた側からしてみれば「そうは言われても切れないんだけどな......」となるじゃないですか。それにSoW（請負業務範囲）がはっきりしていなかったりもして、うやむやのまま課題が足されていくことがよくあります。
だから言葉にすると当然ですが、優先順位を決めるにしても、ちゃんと課題を洗い出した上でチームで議論し、順位付けを行うことが大切ですよね。進捗管理の話とも共通しますが「言える」環境作り、「心理的安全性」というのはここでも大事なポイントになってくると思います。
小宮：そもそもの話ばかりしていますが（笑）、そもそも課題って何の部分をわかっていない人が多いんですよ。それが課題管理がうまくいかない根本的な原因です。そもそものところがわからないと適切に報告できないし、PMも課題を把握できません。課題とは何かをものすごくシンプルにというと「進捗を阻害するもの」です。まずはそこの定義付けをしましょうというところがスタートです。
そして実際に課題を上げてもらうんですけど、ここで起こる問題が「課題をうまく説明できない」です。あるあるですが、報告を受ける側としては「これの何が課題なの？」となってしまう。
たとえば、
「〇〇を来週までにやらなければならない」と課題管理でこのような報告が上がってきたらどう思いますか？
「じゃあ来週までにやりましょう」としか言いようがないですよね。
課題とは「進捗を阻害するもの」という前提がちゃんと理解されていれば、課題管理における報告は次のようなものになるはずです。
「〇〇を来週までにならなければならない。しかし△△が原因でできない」
この△△の部分が課題なわけです。△△の部分を把握してどう解決するかを探ることが課題管理の基本ですが、ここがあまり理解されていないケースが多いんです。この「しかし△△が原因でできない」の部分を聞き出すまでに、何度もやりとりが発生してしまって、全然前に進めないということが起こりがちです。
小宮：そしてようやく課題がわかったとしましょう。ここで発生するのが「言ったもん負け」問題です。課題を上げたら当然「じゃあどうやってその課題を解決する？」と次のステップに進むわけですけど、このとき「じゃあなんとか解決しておいて」という話で終わってしまうことが本当によくあって、報告した側としては「それができないからか課題として報告したのに......」ってなるんですよ。
プロジェクトではこういったことが至るところで起こるので、先ほど早川さんが言ったように本来決めるべき優先順位や劣後順位が決められないんです。
早川：確かにそうですよね。そもそも課題を課題として把握するまでに時間がかかりすぎることが多いですし、言ったもん負けだから言いたくないと...。
小宮：そうなんです。それに加えて、人間心理としてはきたものからやるというよりも、楽しいものや自分が得意なこと、やりやすいことから手をつけるじゃないですか。だからこそ課題を明確化して、優先順位をオフィシャルに決めていくことが大切ですし、「この課題を解決するのはしんどそうだけど重要だよね」となれば、ちゃんと役割を決めてチーム全体でやり切れるように導いていくとか、心理に左右されない仕組みを作っていく必要があります。
早川：やはりQCD（品質／コスト／納期）ですよね。
小宮：いっぱいあります（笑）
例えば、AとBとCのシステムを作っているシステム構築のプロジェクトの話です。支援に入って調査をしていると、「実はABCを動かすためにはDというシステムが必要だった」みたいな話が判明することがよくあります。「え、Dないとやばいじゃん」と。
それで現場の方々の話を聞いていくと「Dを作れ」っていうことは初期の段階から進言していましたとおっしゃるんですね。それをPMに報告すると「寝耳に水だ。何が起こっているかよくわからないから調べてきて」と言われて、また現場の人に話聞きにいくんと「いや報告していますし、DがないとやばいっていうのはPMも当たり前に認識しているものだと思ってました」と。
早川：「思ってました」は本当によく聞くフレーズですね。
小宮：現場の方が「報告書にも書いてますよ」って言うんで改めて読んでみるんですが、書いてあることの意味がわからないんです。それで「Dが必要ということを然るべきところで上長に伝えて、指示を仰いだりしたんですか？」って聞くと「いや、それはしてないです」と。
これは適切に報告ができていないケースですが、他には「Dを作る必要がある」という最も大事な課題を他の情報とごちゃ混ぜにして報告してしまうケースもよくあります。こうなると、重要度が全然違うのに他の瑣末なもの一緒に扱われてしまい、それがそのまま放置されて全てが少しずつおかしくなっていく。
小宮：最初のプロジェクト計画書の話と同じになりますが、「今回のプロジェクトはABCおよびDをスコープにしたプロジェクトです」ということをオフィシャルに宣言すればいいんです。それだけで変わります。そこが曖昧になっていることが大問題なんですが、ではなぜ曖昧になってしまうかというと「はっきり言えない空気」や「報告を上げるルールや仕組みが構築できていない」といったことが理由です。
とはいえ、メンバー間には日々の関係性とかがどうしてもあるので、言えない構造がいやでもできてしまうことも理解しています。そういったときのために我々のような第三者がいるというのも、やや宣伝ぽくはなりますが、事実としてありますよね。
杉本：やっぱり目的の部分、その課題を解決することでどうなるのか？という部分が可視化され、チームで共有されていることに尽きるのではないでしょうか。トンネルの出口が見えている状態といいますか、それが望ましいですよね。
それは課題を上げる側もそうですし、上げられた課題に対して解決の筋道を提示する立場の人もそうですが、トンネルの出口はこれだよ、トンネルを抜けた後の景色はこうだよっていうのをちゃんと共有できるかが大きなポイントになると思います。
「言わなくてもわかるだろう」
「とりあえず頑張ってやってみてよ」
微妙なコミュニケーションのズレが課題管理がうまくいかない大きな原因であることがわかりました。このズレが重なっていくと解決すべき課題が埋もれ、気づいた時には手遅れに......というのがよくあるケースです。まずは「課題とは進捗を阻害するものだ」という共通認識を持ち、上がってきた課題をチーム全体で解決する仕組みを作ることが重要なポイントです。無駄なやり取りを減らしつつ、プロジェクトを前進させるためのクリティカルなコミュニケーションが取れれば、課題が未解決のまま置き去りにされるという事態を避けることができるでしょう。
（撮影／音孝典 取材・文・編集／福井寿和、白戸翔）