前書では「課題のインパクト」と題して、課題にかかる時間と他のタスクとの関係性によるインパクト、そしてその対処法について述べました。今回はさらに踏み込んで、課題の発生時期と課題分類との関係、そしてそれらの傾向によってプロジェクトの健康状態を読み解く方法をお伝えします。
ERP導入プロジェクトにおいて、課題は初期に行うキックオフや業務および現行システムの調査では、あまり起票されません。始まるのは、ERPの製品トレーニングあたりからでしょう。そして、次のビジネスプロセス検証（主に実機を用いた検証）で増え始めます。
課題の分類で見ていくと、初期は、「戦略的・組織的課題」、「プロジェクト管理課題」や「人的資源・トレーニング課題」といった、人に関することが多く、実機検証に入ると「ビジネスプロセス課題」の課題分類が増えてきます。
後半は「技術」に関することが多く起票される様になります。「技術」は「システム連携課題」、「データ課題」、「パフォーマンス課題」、「セキュリティ課題」に分けて管理するのですが、この順番で発生する傾向にあります。
ここで大事なことは、二つです。
一つ目は、課題の発生と消化速度、要は発散状況なのか収束状況なのか、それをプロジェクトの時期と照らし合わせて見ることでおおよその健康状態を判断できます。もし、プロジェクト終盤のフェーズ4（移行）でもまだ課題が発散状態にあれば、一度立ち止まる必要があるでしょう。
二つ目は、課題分類と発生時期の関係です。
先に述べた例で説明すると、フェーズ4（移行）でも発散している状況であり、その課題分類が「プロセス」なのであれば、システム統合テストのやり直しか、少なくとも実データを使ったウォークスルー検証をやるべきです。
プロセスに関する課題は、プロセスの変更によってデータ定義を変更する恐れがあるため、プロセスを決定しないとデータ定義やデータ移行に大きく影響します。
この様に、課題は件数的な側面で評価するだけてはなく、発生の傾向とフェーズとの関係、そして、それらを課題分類ごとに見ることが大事なのです。
こういったことを理解した上で、このユーザーストーリーに沿って課題管理のダッシュボードを作成します。そうすることで、プロジェクト管理者は、プロジェクトの傾向をいち早く捉え、適切なアクションへ移ることができる様になるでしょう。