分類・分析のための項目は必要か
例えば、発生原因分類の列を設けて「検討漏れ」「技術的要因」「環境要因」「コミュニケーション不足」などに分類します。
これによって、複数の課題を分類し、類似課題ごとに対応を考えたり、傾向を分析し、課題発生の根っこを探るということができます。
また、チーム列を複数用意するのは、情報共有やエスカレーションのためです。
「どのチームに関係する課題か」を明確にすることで、適切な担当者にスムーズに情報が届き、迅速な対応が可能になると考えられています。
管理項目を増やすことで、上記のように管理・分析がしやすくなるという利点があります。
データを構造化し、分析可能な状態にしておくことは、プロジェクトマネジメントの基本とも言えます。
べき論としてはその通りだと思います。
項目が増えることで生まれる問題
しかし このアプローチには見落とされがちな問題点があります。
第一に、起票の負担が増大する問題が起こります。
どの分類にしようか迷いが生じることで、「課題を登録する」という本来シンプルであるべき作業が、複雑な判断を伴う負担の大きい作業になってしまいます。
列が多いと、ルールが多く複雑になり、入力に悩むようになるのです。
第二に、本来同じ課題として扱うべきものが分断されるということも起こります。
本当に似た性質のものは同じ課題として束ねられるはずが、分類があるゆえに分けて管理してしまう。
これは課題解決の効率を下げる結果につながります。
第三に、結局使われなくなるという最も深刻な問題も起こります。
項目が多くなると、結局使われず入力されなくなる項目が生じ、その項目は最終的に意味のないものになります。
当たり前ですが、すべての課題でしっかり列が埋まっていないと、管理・分析の意味はなくなってしまいます。
結果として、まじめに入力している人がいても、その人は意味のない作業をしていることになってしまいます。
以前担当したプロジェクトでは、20以上の列を持つ課題管理台帳が用意されていましたが、実際に継続的に入力されていたのは半分に満たないほどでした。
残りの列は存在しているものの、誰も見ない、誰も更新しないという状態になっていたのです。
課題というのはそもそも紐解きが必要なもので、対応が困難であったり、対処法が明確でないものです。
例えば、発生原因については起票時点で整理できていないことも多いのです。
課題を紐解いていく作業を経て、徐々に明らかになっていくものです。
影響チームについても、課題が紐解かれて初めて入力できます。
さらに、課題が細かいタスクに落ちたら影響チームが増えるということもあり得ます。
つまり、課題というものの特性上、管理項目の値自体がとても流動的なものになるわけです。
そのため、こまめに管理項目の値をメンテナンスするコストと、管理項目を使った管理・分析作業の効果のバランスが取れるかどうかが、管理項目を設けるかどうかのポイントになると思います。
大規模案件では管理項目が必要になる
一方、超大規模（予算規模100億を超えるような）のマルチベンダープロジェクトであれば、管理項目をたくさん設けたりします。
これは、プロジェクトの体制上の上下や横のステークホルダーが多くなることで、コストをかけてでも、管理・分析をしやすくする必要があるからです。
プロジェクト全体の報告書を作るときに、どんな課題が何件あるか、を効率的にまとめるために、管理項目が必要になります。
本当に必要な項目だけに絞り込む
超大規模ではないプロジェクトにおいて、私が推奨するのは、本当に必要な項目だけに絞り込むという方針です。
課題管理台帳に絶対に入れたいのは、次の８項目です。
まず、基本情報として「件名」「課題内容」「検討経緯」です。
件名は課題の概要を端的に表現し、課題内容には状況や背景を詳しく記載します。
そして検討経緯には、その課題に対してどのような検討や対応を行ってきたかを時系列で記録します。
この3つがあれば、課題の全体像を把握することができます。
つづいて、責任の所在を明確にする「起票者」「担当者」です。
誰が課題を発見し、誰が解決の責任を持つのかを明確にすることで、課題が宙に浮くことを防ぎます。
最後に、時間管理のための「起票日」「完了期限」「ステータス」です。
いつ発見された課題で、いつまでに解決すべきか、現在どのような状態かを把握することは、進捗管理の基本です。
この方針のメリットは、起票と更新の負担が大幅に減ることです。
迷う項目が少なければ、課題を登録するハードルが下がり、チームメンバーが気軽に課題を共有できるようになります。
また、台帳がシンプルで見やすくなるため、会議での確認作業がスムーズになります。
項目が少ないことで、本当に重要な情報に注目が集まり、課題解決に向けた議論が活性化します。
一方で、よく見かけるものの不要と考えられるのは、次のような項目です。
「優先度」は相対的に変わることがあり、時間経過でも変わるため、高中低をメンテしていくのが大変になる割に使い道があまりありません。
本当に優先度が高い課題は、会議で自然に話題に上がりますし、必要であれば「緊急」が分かるような目印をつけられるようにするとよいです。
「発生工程」は起票日と内容でわかるため、別立てで管理する必要がありませんし、課題自体の解消には寄与しないものです。
「発生原因分類」は内容に書けばよいので、別出しは不要です。
前述の通り、起票時点で原因が整理できていないことも多く、課題を紐解いていく作業を経て「課題内容」項目に追記していく形で十分です。
シンプル台帳の運用を成功させるには
この方法を実践する上で、いくつか重要な注意点があります。
まず、「課題内容」と「検討経緯」には何を書くべきかを明確にすることです。
項目を絞り込んだ分、これらの自由記述欄に情報が集約されます。
そこに何を書くべきかを整理しておかないと、書いてほしい項目が漏れてしまいます。
例えば、「課題内容」には最低限以下を含めるというルールを設けます。
- 何が問題なのか（事象）
- なぜ問題なのか（影響）
- どうなれば解決なのか（ゴール）
また、「検討経緯」には以下のような情報を時系列で追記していくルールにします。
- いつ、誰が、どのような検討を行ったか
- どのような対応を実施したか、またはする予定か
- 判断の理由や背景
次に、記入例を添えて共有することです。
ルールを文章で説明するだけでは、実際に何を書けばよいか迷うメンバーが出てきます。
良い記入例を複数用意し、チームで共有することで、記入の質を一定に保つことができます。
最後に、定期的に台帳を見直すことです。
シンプルな項目設計であっても、運用していく中で「やはりこの項目は必要だ」という気づきが生まれることがあります。
その際は、チームで議論し、本当に必要かを吟味した上で追加することが大切です。
ただし、追加する際は同時に「削除できる項目はないか」も検討しましょう。
課題解決に集中できる台帳を目指す
課題管理台帳は、分類・分析のためのツールではなく、課題を一つ一つ確実に解決するためのツールであるべきです。
課題の本質は一つ一つ異なることが多く、「分類すれば効率化できる」というものでもありません。
また、項目を増やせば増やすほど、台帳の維持管理に手間がかかり、結果的に使いづらい・使えないものになってしまいます。
本当に必要な項目だけに絞り込むことで、起票と更新の負担が減り、チームが課題解決に集中できるようになります。
ただし、何でもかんでもシンプルにすればよいわけではありません。
「課題内容」「検討経緯」といった自由記述欄に必要な情報を確実に記入するためのルールと記入例を整備することが、シンプル台帳の運用を成功させる鍵です。
「分類のための分類」ではなく「解決のための記録」という姿勢こそが、課題管理台帳を本当に機能させるのに重要ではないでしょうか。
