DX(デジタルトランスフォーメーション)推進コンサルティング 株式会社アイ・ティ・イノベーション

ご訪問ありがとうございます！　　　　　　　　　　＜　前回　｜　目次　｜　次回　＞

夏の甲子園では、各地方大会を勝ち抜いた代表校による熱い戦いが繰り広げられています。残念ながら甲子園出場を逃したチームは、地方大会を勝ち上がれなかった原因を分析し、課題解決に向けた活動を開始していることと思います。

甲子園出場と言う目標達成に向けて、克服すべき課題を漏れなく洗い出し、限られた期間の中でそれらの課題を解消するためのアクションプランをたて、その進捗状況を管理する必要があります。。。（※１）

【　課題解消のアクションプランとしてのプロジェクトを進捗管理する　】

～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～
さっそくですが、プロジェクトマネジメント研修を受けてきたばかりの、新人Ｐ子さんが何か悩んでいるようです。

＜新人Ｐ子さん＞　：　「うーん、甲子園出場のための課題を洗い出して、課題解消のプランを進捗管理するって、意味はわかるんだけど、研修で勉強した課題管理と進捗管理の関係となんか違うような感じがするわ。」

＜ベテランＰＭのＭ男氏＞　：　「まったく、くだらんことで悩んでないで、早く明日の定例に出す進捗報告書の作成と問題・課題一覧の更新をすすめるんじゃ！」

＜新人Ｐ子さん＞　：　（Ｍ男の言うことなんて聞いてらんないわ！）「えーと、甲子園出場がプロジェクト目標で、甲子園出場に向けた課題解決のアクションプランがプロジェクト計画で、アクションプランが予定通り進んでいるかを進捗管理して、進捗が遅延したら課題として管理して、、、あれ、課題って言葉が２回出てきちゃったわ？？？」

―――　Ｐ子さんは、課題という言葉の使い方に少し混乱しているようです。確かに「甲子園出場に向けた課題」というときの「課題」と、「進捗が遅延したら課題として管理」というときの「課題」は、少し違う意味で使われていますね。

「甲子園出場に向けた課題」は、そもそもの甲子園への道プロジェクトを立ち上げるきっかけとなった課題であり、プロジェクトの目的と言ってもいいものです。一方「進捗が遅延したら課題として管理」と言う場合の「課題」は、たとえば投手力の強化を図ろうと計画していたのに、期待していた投手が怪我で出遅れてしまったというような不測の事態による計画と現状とのギャップを指します。

これをシステム開発のプロジェクトに置き換えて考えてみると次のようになります。

まず業務・システムのあるべき姿（ＴｏＢｅ）の達成に向けた課題を設定し、その課題解決のためのアクションプランとしてシステム開発プロジェクトを企画・実行することになります。

そして、そのシステム開発プロジェクトを実行する中で発生する計画と現状のギャップをプロジェクトの課題として、問題・課題一覧にあげて課題解決のアクションプランを行うという図式です。

同じ「課題」という言葉でも、どの「あるべき姿」に対するギャップを指しているのかを意識して使い分けることで、Ｐ子さんのように混乱することは避けられます。そして、課題解決のアクションプランとしてプロジェクトを立ち上げるという関係がわかれば、「課題解消のプランを進捗管理する」という表現も特に違和感が無く受け入れられるはずです。

【　プロジェクトの課題発生・解消状況を進捗管理する　】

～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～
当ブログの　【第２回】プロジェクトマネジメントは問題解決だ！　では、「プロジェクトにおける問題が全て無くなれば、プロジェクトは成功したと言える」という先輩たちからの教えについて検証しました。確かに、問題・課題が無くなるということは、プロジェクト計画と現状とのギャップが無いということなので、プロジェクトは成功することは確かです。

しかし、プロジェクトには独自性があり、さまざまな制約の中で実施することから、問題・課題が発生しないことはありません。そもそも、プロジェクト実行中に発生する問題・課題をいかにさばいていくかがプロジェクトマネジメントの本質であるという意味で、「プロジェクトマネジメントは問題解決だ！」と言い切ったのです。問題発生を未然に防止するためのリスク管理に重点を置けば、「プロジェクトマネジメントはリスクマネジメントだ！」と言っても通用するはずです。

さて、当ブログの　【第４回】プロジェクトにおける問題とは何か？　では、「プロジェクトにおける問題とは、プロジェクト計画と現状とのギャプである！」と定義しました。プロジェクトの課題が発生しているということは、課題対応という計画外のタスクが追加されたということになります。

課題の数が少なければ、課題対応のために必要とされるスケジュールやコストは当初計画内の暗黙のバッファで吸収可能ですが、課題の数が多くなると、バッファ内での吸収ができず、プロジェクト全体のスケジュールやコストに大きな影響を与えます。そうなると、課題対応についても、きっちりと進捗管理をする必要が生じてきます。

課題対応の進捗管理方法としては、正論から言えば課題対応は追加タスクになるので、プロジェクトのWBSに追記して進捗管理を行えばよいことになります。しかし、何せ計画外のタスクなのでひとつひとつの課題対応のスケジュールやコストを正確に見積もることは難しく、さらにプロジェクトの進行とともにシャボン玉のように浮かんでは消える課題の山を整然と進捗管理するのは至難の業です。

そこで、プロジェクトのＷＢＳとは別の形で、たとえば図２に示すようなグラフを用いて課題の解消状況を進捗管理します。このようなグラフを用いて定量的に管理することで、今後の課題発生や課題解消件数の推移などもある程度予測できるようになり、課題対応に必要なリソースやコストなどの見通しもある程度管理することが可能になるはずです。

「プロジェクトの課題は追加タスクであることを認識し、定量的な進捗管理を心がけよう！」

【　課題発生・解消件数でプロジェクトの進捗を管理する？　】

～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～
ここまでの考察で、課題管理と進捗管理は密接に関連することを確認できたと思います。システム企画や要件定義の超上流工程がしっかりできていれば、「甲子園出場に向けた課題」にあたる部分の課題は明確に定義され、その課題解消に向けたタスクも明確化しやすく、しっかりした計画がたてられることと思います。

しかし、超上流工程での検討が甘くなると、プロジェクトを通じて解消すべき課題が不明確のままとなり、その状態で立てたプロジェクト計画にはタスクの抜け漏れが多くなり、その結果プロジェクト実行段階で課題が多発するという結果を招きます。要件定義や外部設計などの設計段階で、検討すべき事項（すなわち課題）が次々に発生する状況では、課題が収束しないとどんなシステムになるか想像もできなくなります。

そうなると、たとえ当初計画したタスクを進めたとしても、課題の解消結果によっては大幅な手戻りが発生するリスクも高くなるため非効率となり、もちろん設計品質も劣化することが目に見えています。当初計画の設計作業を整然と進めることができなくなり、課題の抽出と解消を延々と続けることが主たるタスクになってしまうのです。

このような状況のプロジェクトでは、当初計画したWBSに基づく進捗管理はできないため、先ほどの図２で示したような課題発生・解消曲線がプロジェクトの進捗報告に置き換わってしまうことになります。

そもそも、プロジェクトの問題・課題はプロジェクト計画と現状とのギャップであるという定義を考えると、課題の抽出と解消がプロジェクトの主要なタスクとなるということは本末転倒のように感じます。プロジェクトの課題が発生し続けるのは、プロジェクトの目的やスコープがあいまいなことが原因である可能性が高いのです。

もし、プロジェクトがこんな状況に陥った場合には、勇気を出してプロジェクトを一時中断し、課題の解消を集中的に実施する期間を設ける必要があります。そして、あらためてプロジェクトの目的を確認した上で、その目的達成に必要な課題を明確化し、それらの課題を解消するためのアクションプランをたて、その進捗状況を管理する必要があるのです。。。ん？振り出しに戻っちゃったようですね。。。

それでは次回もお楽しみに！　　　　　　　　　　＜　前回　｜　目次　｜　次回　＞

工藤武久

～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～
応援してくださる方は、クリックよろしくお願いします！
◆　人気ブログランキング
◆　にほんブログ村
～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～

※１　当ブログの　【第７３回】問題・課題、Todo、リスクの『「超」整理法』　において言及している通り、一般的には、あるべき姿と現状のギャップの状態や事象が問題であり、そのギャップを埋めるために実施すべきことが課題とされるようです。当ブログにおいては、問題と課題を厳密に使い分けしていないことにご留意ください。