本記事の目的
プロジェクト規模の大小問わず必ず行う課題管理はタスク管理と並んで極めて重要な管理となりますが、どの様なプロジェクトであっても適合できる最適解というやり方を規定するのは難しいのではと思っています。
お客様の業種業態やご要件次第でステークホルダーは異なりますし、インフラ（オンプレ、クラウド）、スクラッチ開発、パッケージ利用といった要素だけでなく、システム或いは機能別に担当企業が異なる場合もありますので状況に合わせ工夫する必要があります。
本記事では、著者の経験則を中心に取り組み方について記載します。
1. そもそも課題管理ってなんでやるの？
取り組み方を考えるにあたり、敢えて根本的なところから考えてみます。
PMBOKでは「プロジェクト立ち上げ時に定義した品質・コスト（予算）・スケジュールなどを、計画通り達成する際の障害となる問題を把握し解消すること」と定義付けられていますが、そもそも論として"プロジェクト立ち上げ時に定義した品質"というもの自体が残念ながら明確になっていない事（お客様内で品質の基準が定まっていない、プロジェクト計画時点では品質規定が詳細化されていない等）があります。
これはプライムに立った（一次受け、プロジェクト統括の役割で受注した）企業がプロジェクトのキックオフまでの間にお客様とどの様な計画立案の調整を経ていたかで話が異なります。
が、その話は趣旨から外れる話なので割愛しますが、プロジェクト全体であるにしろ、サブシステム或いは機能（インフラ、フレームワークなど）を担当するチームであるにしろ、課題管理では概ね以下の項目を管理していきます。
- 課題番号
- 課題の概要
- 課題の詳細
- 担当者（担当社）
- 期限
- 優先度
- ステータス（未対応、対応中、保留、回答待ち、完了等）
- 対応内容
- 対応結果
体制的にPMOがいない場合はPMが主に管理しますが、メンバの方でもタスクとして課題の対応を担当する機会はあるので課題事項を見聞きする事は多いと思います。
プロジェクトの完了条件として「課題が全て解決済みであること」という条件があったりする事もあるので、課題管理はプロジェクトの成功に大きく関わります。
ステークホルダーが多ければ多い程、実装する技術や設計内容が複雑／難解である程に課題となる事項は多くなり、容易く解決できない状況が発生し易くなります。
PMBOKの定義付けにもありますが、課題管理を行う最大の理由は「プロジェクトまたはタスクの進捗を阻害する問題を解決するため」に行います。
2. 課題管理の考え方
著者の経験則として着目すべき点は、「如何に労力をかけずに管理し解決するか」だと考えています。
PMまたはPMOが複数のプロジェクトを担当していたり、規模の大きいプロジェクトでは多種多様な課題が多数出ることもあり、状況に応じて「管理し易く理解し易い方法」を採用する必要があります。
一般的には、項1に記載している各項目を課題管理表として書き出し管理していく方法となりますが、その他の管理上の視点で分類分けすると以下の様な分類が出来ます。
- プロジェクト全体に影響する課題
- 技術分野毎（インフラ、DB、UI、セキュリティなど）の課題
- 工程別の課題
- 自社担当分のタスクだけに特化した課題
課題事項が少ない場合には課題管理表は一つでも良いですが、課題となる項目数が多かったり状況的に長期の対応が必要となる課題事項や重要度の高い課題事項の場合には、課題項目をカテゴライズして課題管理表を分割したり、特定の課題項目だけをピックアップして管理するといった対応を行う事があります。
PMが管理する対象は多岐に渡りますが課題管理に労力を割く機会は多く、課題内容次第ではお客様へ報告書を提出する事もあるのでどの様な管理を行っていくか次第で業務量に大きな違いが出易い点です。
課題管理を行う上で著者の経験則として重要視する点は以下の要素となります。
- ステークホルダーへの影響度
- プロジェクトまたはタスクのターニングポイントとなる期限
- 担当者の業務負荷
- フォローアップのタイミング／頻度
上記の点で悩ましいのが「フォローアップのタイミング／頻度」です。
自社や自分が直接統括しているチームであれば融通は付け易いですが、お客様や他社といった業務状況が判り難いステークホルダーの場合、余り頻繁にフォローアップしても進展がなかったり、かと言ってフォローアップのタイミングや頻度を見誤るとタスクやプロジェクトの遅延に繋がる恐れがあります。
契約条件や役割分担（請負範囲）でも違いがありますが、課題管理はフォローアップのやり方も含めて各社、各チームの合意を取り合理的な規則を設け推進する事が重要であると考えています。