要件定義フェーズでは、利用部門のユーザーへのヒアリングを通して要件を明らかにしていく。その過程では必ずといっていいほど、解決すべき課題が出てくる。これらの課題は、システムの要件を固めていく基となる。そのためPM（プロジェクトマネジャー）にとって、現場で出てくる課題の管理は重要な業務になる。

　この課題の管理状況は、利用部門のユーザーを交えた定例会議で、プロジェクトの進捗状況と合わせて報告することが多い。この課題管理状況の報告は、プロジェクトの現状を正確に伝えるという意味で、大事な取り組みだ。ただしこのときPMは、利用部門のユーザーに「課題数が多いことは悪いことだ」と思わせてはいけない。もしそう思わせてしまうと、ユーザーは過度な不安を抱き、プロジェクトが進まない状況に陥ってしまう。

ERPパッケージの会計モジュールが専門のEさんのケース

　Eさんは大手ERPパッケージベンダーに所属して10年の中堅エンジニアだ。会計モジュールを専門にし、モジュールリーダーとして数多くのプロジェクトを経験してきた。そのEさんは、大手製薬会社K社のERP導入プロジェクトに参画することが決まった。難易度が高いビッグプロジェクトで、Eさんは会計モジュールリーダーを担当することになった。Eさんは「この大プロジェクトでステップアップしよう」と心に誓い、プロジェクトをスタートさせた。

　プロジェクトは、現状業務プロセスの洗い出しと業務課題の抽出から始まった。Eさんが会計パッケージ導入のポイントを押さえていたこともあり、プロセスの洗い出しと課題の抽出は順調に進んだ。もちろん課題は抽出されてもすぐに解決できるとは限らない。ERPパッケージのモジュールによっては、課題に対応した要件をすぐに固めることが難しいものがあるのだ。

　その一例が、Eさんのプロジェクトで取り扱う、会計モジュールだ。販売や購買といった他のモジュールの場合は、それぞれ担当する部門長を中心に、課題検討を進めることができていた。しかし、会計モジュールの場合はそうはいかなかった。会計関連部門長の判断だけではなく、会計情報に基づいて経営判断を下している経営トップにも確認しなければならない。しかも、「財務会計の制度に反した処理になっていないか」「管理会計上に問題がないか」といった確認内容が多く、課題対応の方針すら決まらないことが多い。

　そのため、Eさんのプロジェクトでも会計モジュールに関する課題がどんどん増えていった。会計モジュールの導入に慣れているEさんは、「会計モジュールの課題管理は増えがちになるものだ」と思っていた。むしろ、「この早いタイミングで課題がこれだけ抽出して、課題の対応方法を検討することができているのだから順調といえる」と考えていた。

　そんな中、隔週で実施されていた定例進捗会を迎えた。利用部門のユーザーも参加するこの定例進捗会では、モジュールごとにタスクの進捗度や課題数を報告することになっていた。それを踏まえて、プロジェクト全体で課題の対応策などを討議する。

　会計モジュールに関する進捗報告が行われていたとき、Eさんは「さまざまな観点で多くの課題が洗い出されているので順調といえる。自信を持ってプロジェクト責任者に伝えられる報告内容だ」と思っていた。ところが、プロジェクト責任者であるH本部長から思わぬ指摘を受けた。「会計モジュールは、他のモジュールに比べて課題数が多いですね。しかも課題対応の完了件数は増えない一方で、週を追うごとに課題数は増えていますよ。ちゃんと課題検討を行っているのですか？」。

　Eさんは「会計モジュールは課題解決に時間がかかるものなのです」とH本部長に説明した。しかしいくら説明しても、「他のモジュールと比べて突出して件数が多いのは問題だ」と、H本部長は納得しない。これが基で、プロジェクトの定例会議は紛糾。EさんとH本部長が会計モジュールの課題についての議論に多くの時間を費やしたことで、他のモジュールについての課題解決の方針が決定できない状況になり、プロジェクトは停滞してしまった。