「課題管理表をしっかりやりましょう」に潜む落とし穴　未解決課題が積み上がり、そのまま迎えるプロジェクトの終盤

アンチパターンその4　「技術課題満載の課題管理表」

西郷智史氏：時間もありますので、最後の4つ目にいきたいと思います。

4つ目は、技術課題満載の課題管理表についてです。直面した技術的な課題ばかりが取り上げられた課題管理表。ついついこれも無意識のうちにやってしまいがちになるアンチパターンの1つです。

チェックすべきポイントは、課題の内容を見ても技術者しかわからないものが多いことです。専門的なことが並べられていて、例えば進捗会には10人いるけれど、2人しか内容がわからない、ということです。

CとDにあまり触れずに、課題のほとんどが技術的なものや品質に関わるものが多いことが挙げられます。数ヶ月間放置されている課題が多数ある場合には、技術課題満載の管理表になってしまっている可能性があります。

IT業界でない人には少し馴染みが薄いかもしれませんが、プログラミングでは仕様を考えたりコードを書いたりする時に、クラスという考え方があります。「なんとかクラスのなんとかが使用されておらず、なんとかクラスを呼び出すことができない」、インフラでいうと「なんとか発生時のどこどこの機能が正常に終了しないよ」などと言います。要するに、チケット管理でやることが課題管理表にたくさん書かれていることがよくあるのです。

（スライドを示して）全部のスライドを出してしまいますが、なぜこれが起こってしまうかというと、課題の定義が曖昧になっているからです。課題は立場・役職・担当などいろいろな視点で捉えることができます。

何が課題なのかを決めていないと、なんでもかんでも課題管理表に載りがちになります。しかも、技術的な課題は特に目につきやすいので、次から次へと技術課題が課題管理表に積み上がってしまいます。課題管理表を管理することが目的になってしまうのです。「課題管理表をしっかりやりましょう」というルールだと、課題に対応するよりも、きちんと載せないといけない、きちんと網羅できているか、などの思考に陥りがちです。

課題がプロジェクト全体にどのような影響を与えるのかがわからない。確かに課題は書いてあるけれど、「それって本当に今やらないといけないの？」「どれぐらいこのプロジェクトに対して影響があるの？」ということがなかなかわからない。単なる「決め」の問題まで載っている。そういった状態になってしまうのです。

解決の状況を見える化して適切にエスカレーションする

別の視点として、「誰がいつまでにアクションを起こすかが不明確」というものもあります。とりあえず挙げたけど、誰が、いつ、何をするか、が明確になっておらず、その結果、課題が未解決のままプロジェクトの終盤を迎えてしまいます。

それを回避するために私たちが支援していることですが、まずは、取り上げるべき課題を定義します。例えば、チケット管理と課題の2つのことをやっているとしたら、チケット管理にはこのようなことを書いてね、特に技術的なことはチケットでやってねというようにします。課題管理表に書く時には挙げる項目をしっかり定義をしてあげないと、報告する側も迷ってしまうので、そこは定義しましょう。

あとは、解決の状況を見える化します。プロジェクトと同じで、その課題が今どれだけ溜まっているか、またはどれだけ進捗しているか、それをきちんと見える化していかないと、課題管理のための管理になってしまうので、そこは見える化しましょう、というのが2つ目です。

また、適切にエスカレーションすることも大切です。担当でも解決できることと解決できないことがあるし、プロジェクトマネージャーが解決できることと、課長や部長などの役職者でないとできないことがあるはずです。なので、その課題をしっかりとしかるべきところにエスカレーションすることが大事になってきます。

それぞれの課題を定義して自分たちの状況をモニタリングする

3つのポイントを案内しました。1つ目の課題の定義でいうと、PMが必ず取り上げるべき課題は、残日数報告にて優先度の高いタスクの期間が延びた時の支援に対する情報です。

優先度が低いタスクとは、先ほどのクリティカルチェーン以外の隙間があるものです。（スライドを示して）例えば、このAパーツは多少延びてもまだ影響はありません。ここがここまで延びても影響はないです。ただし、クリティカルチェーンのタスクは遅れるとすぐ納期に影響を与えてしまうので、ここで発生した課題とここで発生した課題は重さが違います。

したがって、PMでもPMでなくても、優先度の高いタスクの課題は絶対に書いておきましょう。ほかのタスクは絶対ではないということや、最長チェーンのタスクの期間が延びることが予測される時の支援に関する情報なども挙げておきます。

実際に課題が起きていなくても、「ここは誰々さんの負荷が高くなりそうだから、このタスクはきちんとできそうもありません」ということが予見される場合には、そこに対する支援をしっかりと書いておきましょう。課題の解決に時間がかかっている時の支援の情報も書きます。1ヶ月も2ヶ月も放置されてしまっている時に、その支援に対する情報をしっかり載せておきましょう。

別で取り扱ったほうがいい課題に、技術的な課題、顧客からの追加要望、遅延が発生した時に対する原因分析などがあります。先ほど話したチケット管理も含めて、これらは別枠で取り上げましょう。

必ずこのとおりにやってと言っているわけではありません。ここで言いたいのは、しっかり定義したほうがいいということです。定義をしておかないと、エスカレーション先を間違ってしまいます。定義をしっかりするべきで、（スライドを示して）この定義は一例にです。

あとは見える化です。これも必要に応じて私たちもよくやるのですが、（スライドを示して）課題が組織の中にどれぐらい滞留していて、解決スピードがどれぐらいあるのか、各項目が何を表しているのか、は枠で書いてあります。

例えば、課題の起票数がどんどん上がってきたり、解決数と滞留している数に乖離があったりすると、解決スピードが追いついていないといえます。自分たちの状態をしっかりモニタリングすることも非常に大事だと思います。

そして、もちろんアクションも大事です。課題だけでなく、誰が、いつ、どこまでやるかをしっかり書いておくことも必要だと思います。

4つのアンチパターンのまとめ

ここまでのアンチパターンをまとめます。まず、圧縮スケジュール。次に、細かすぎるリソース管理。そして、やったことの進捗報告会。最後に、技術課題満載の課題管理表。この4つをアンチパターンとして挙げました。

それぞれの回避策です。1つ目の圧縮スケジュールは、最も長いタスクのつながりを明確にして、必要な支援を要求します。言われたことをそのまま圧縮して提示するのではなく、粗くてもいいので、最も長いタスクのつながりを明確にします。そして、支援が必要だったらきちんと要求しましょう。

計画を立てる時は少し時間がかかると思います。圧縮スケジュールをざっと作るよりも、ヒアリングをしないといけないし、きちんと計画も立てないといけないので、時間がかかります。しかし、後々自分が割を食って、最後に炎上して、それをリカバリーする苦労と比べたら、ぜんぜん安いものですね。計画を立てられるのであればしっかり立てて、マイナスだったらしっかり支援を受ける、これが大事になってくると思います。

2つ目の細かすぎるリソース管理は、人や仕事を100パーセントフル稼働することが目的ではなく、プロジェクトの完了ペースを上げることを最優先としたリソース管理をしていきましょう、というものでした。

3つ目のやったことの報告会は、過去ではなくて未来に向けてしっかり議論できる報告会にすることがポイントでした。そのために、過去にやったことではなく、タスクは残日数で、つまり今日からどれぐらいかかるかという観点で報告してください。

4つ目の技術課題満載の課題管理表は、まず取り上げるべき課題を定義します。それによって、課題による停滞時間を削減できます。課題が放置されることで停滞すると、その分だけプロジェクトが止まっている期間も長くなってしまいます。その課題に対し、いつ、誰が、どうアクションを取るのか、取れないのであれば誰にエスカレーションするのか、それをしっかりマネジメントできるような環境を作っていきましょう。

アンチパターンに対する手法「クリティカルチェーンプロジェクトマネジメント」

実はこの要素はすべて、クリティカルチェーンプロジェクトマネジメントという手法の内容になっています。私たちが取り扱っているTOCという理論の中のCCPMです。CCPMは納期の遵守率を上げましょう、リードタイムを短縮しましょう、停滞時間を削減させましょう、などのアプローチを取るソリューションです。

コーディングや設計、組み立てなどの生産的な時間は今のままでいいのです。みなさんのお尻を引っぱたいて、生産的な時間中に2倍速で働けと言っているわけではありません。課題が停滞している、計画を立てなかったがゆえに後で大きなリカバリーが必要になって手戻りになっている、などの時間を削減しましょうというアプローチなのです。

そのために、リソースを役割単位で見ていって、負荷が高いところはずらせるのであればずらしましょう、最初の投入でちゃんとコントロールしてあげましょう、という考え方のパイプラインマネジメントをします。

また、準備万端にしてから始めましょうというフルキットの考え方や、計画と実行管理のバッファマネジメントなどの手法がCCPMの中にはあります。

一番大事なのは、そういったソリューションをマネジメントサイクルにきちんと落とし込むことです。部門長が計画段階や営業活動から入って、完了するまでにどのような役職の人がどのようなことをしないといけないのか、それを体制に入れ込むことです。そして、各段階において現場やマネージャーがしっかり判断して行動に移せるような指標を与えてあげることが、非常に大事になってくるかと思います。

詳細は割愛しますが、この4つの内容はCCPMの内容に入っています。弊社は「CCPMの基礎って何なの？」「バッファマネジメントやパイプラインマネジメント、フルキットってどういうことをやるの？」などのセミナーも定期的に開催しています。興味がある人は、そういったセミナーに参加してもらえればと思います。

もしくは、冒頭に紹介した書籍にもっと詳しく書いてあるので、興味がある人は書籍も見てもらえればと思います。本日のセミナーはいったんここで締めます。

株式会社ビーイングコンサルティングからのお知らせ

在原匠氏：もう一度弊社から少し案内します。弊社では、個別の面談や社内セミナーを承っています。詳しい話を聞きたい、社内でこういった考えを広めたい、などの要望がありましたら、アンケートを配りますので、そちらで回答してください。

お勧めの情報をいくつか案内します。過去実施したセミナーをいくつかオンデマンドで期間限定で配信しています。本日、西郷が話したCCPMの基礎的なものについての話もあります。

また、それを実践して実際にどうなったのかを取り上げた「マネジメント革新事例セミナー」は、弊社の後藤というシニアコンサルタントが、マツダさまを支援した時の事例について詳しく話しているものです。ご興味があればご覧ください。

また、隙間時間で見ることができる動画を「YouTube」に上げています。「プロジェクトマネジメントカフェ」というチャンネルですので、こちらもチェックしてみてください。

最後にもう1つ。先ほど西郷から紹介しましたが、書籍には実践的なノウハウなどを詳しく記載をしていますので、ぜひ、お手に取っていただければと思います。よろしくお願いします。