IT組織のためのプロジェクト状況の数値化

ビジネスITを担当しているIT組織では、組織全体としては10人の社員の規模であっても20以上のプロジェクトが進行していることがある。このような場合、社員一人一人が複数のプロジェクトを担当することもあり、現場の負担も大きいものと想定されるが、負荷がさらに大きくなるのはIT組織長である。IT組織長は各プロジェクトのQCD（Quality｟品質｠・Cost｟コスト｠・Delivery｟納期｠に関する最終責任者となっていることが多く、各プロジェクトの状況を把握するための責務を負っている。しかし、プロジェクトの数が多くなることから、一つ一つのプロジェクトへ割ける時間は限られたものとなり、すべてのプロジェクトで満足のいく状況把握をすることができないのが現実だと思われる。

このような状況だと、プロジェクトの運営はプロジェクトマネージャーに実質的に一任されることとなり、状況の報告もプロジェクトマネージャーからの報告のみに頼らざるを得ない。すべてのプロジェクトマネージャーの能力や経験がIT組織長の望むレベルを満たしていれば報告を全面的に信頼することが可能であるが、現実はそうではない。そうなると、プロジェクトマネージャーからの報告から得られる情報にはばらつきがあると考えることが妥当である。第三者からの報告を得るためにPMO（プロジェクト・マネジメント・オフィス）を配置して、PMOからの状況も把握することも考えられる。しかし、リソースとコストの観点から、すべてのプロジェクトに対してPMOを配置することは難しく、現実的にはプロジェクトマネージャーからの報告に頼らざるを得ないというのがIT組織長の置かれた状況であると考えられる。

このようにビジネスITを中心とするIT組織では、プロジェクト数の多さに起因したプロジェクト状況の把握が難しいという課題・リスクに直面していると考えられる。この課題・リスクはどのように顕在化するのであろうか。例えば、プロジェクトマネージャーからの報告は継続して「順調」であったにもかかわらず、急遽ビジネス部門からのクレームやアラートが発せられることが想定される。それを受けてIT組織長が問題となったプロジェクトの状況を詳細に確認してみると、以下のような点が判明することがある。

• 予定が見通せていないにもかかわらず、単なるタスク状況の報告となっている
• タスクの洗い出しができていないまま進めていたので、タスクが雪だるま式に増えていた
• リリース日を遵守するための次工程の開始日など重要マイルストンが設定されていなかった
• 設計内容をビジネス部門と合意しておらず、手戻りが多発していた

など

これらの事象は、一つ一つのプロジェクトに対して適切なタイミングで検知できていれば、顕在化させないための対応は難しくない事象と思われる。しかし、このようなIT組織ではこれらの事象を検知することができずに顕在化してしまいやすいと考える。

そのため、複数のプロジェクトが同時に進行することが多くなるビジネスIT領域を担当するIT組織においては、進行しているプロジェクトの状況を横断的に把握し、問題やリスクの予兆を検知できる仕組みが特に重要になると考える。先に述べた通り、案件ごとにPMOを配置するなどの大幅な増強はリソースとコストの観点から実現性は低い。そのため、複数のプロジェクトの状況を数値化し、IT組織長が全プロジェクトを横断的に把握したうえで、問題・リスク懸念の高いプロジェクトに着目しやすくするためのスコアリングロジックを提言していく。

今回は、IT組織長の立場で各プロジェクトマネージャーが担うプロジェクトを横断的に可視化することを目的としてロジックを検討した。スコアリングに必要と考える要素は以下の２点である。

① 計画・評価等のマネジメントタスクの達成度

② 予定と実績の差異

この２点の情報からプロジェクト状況の数値化を行っていく。プロジェクトマネージャーが行うプロジェクト管理は進捗管理、課題管理、品質管理などPMBOK（Project Management Body of Knowledge:プロジェクトマネジメントに関する知識を体系的にまとめた参考書のようなもの）などで規定されている管理プロセスなどがあるが、これらの詳細情報を把握するには多くのリソースとコストを要してしまうことが想定されることから、必要最低限のシンプルな情報、かつプロジェクトの状況を把握するのに有用な情報を選定し、上記の２点の要素を選定した。以下にて各要素の選定ポイントを述べていく。

プロジェクトの根幹は計画と評価にあると考えられる。限られた納期内・コストで、求められる品質を達成するためには、それを実現していく計画を策定しておくことが必須であると考える。また、各工程での成果物が、求められる品質を達成しているかという点での品質評価を適切な工程やタイミングで実施していくことも必須である。問題プロジェクトの根本原因の代表的なものとして、「計画検討が不十分であった」や「品質評価を適切なタイミングでできていなかった」などがあり、その結果として手戻りやスケジュールの遅延という問題事象が生じていると考える。そのため、プロジェクトが安定的に運営できているかの要素として、プロジェクトにおける計画や工程品質評価というマネジメントタスクを適切なタイミングで立案実施できているか、という点を把握することが最も重要と考えスコアリングロジックの要素として選定した。

計画・評価等のマネジメントタスクとは具体的に以下のようなタスク・成果物を想定している。

• プロジェクト計画
• 全体テスト計画
• 全体移行リリース計画
• 品質評価計画
• 開発工程（基本設計～単体テスト）計画
• 結合テスト計画
• システムテスト計画
• 受入テスト計画
• 移行リハーサル計画

など

これらをマネジメントタスクとして定義したうえで、着手時期と完了時期、そして誰の承認を得たうえで完了させるかという点をあらかじめ明確にさせておく。この明確化ができておらず、かつ明確化がハードルになるプロジェクトがあるかもしれないが、本稿のスコアリングを導入するためには必須の事項であることをご理解いただきたい。

もう一つの要素としては、現時点の進捗状況、つまり予定と実績の差異を把握する必要がある。一つ目の要素では、マネジメントタスクを実施有無のみで判断している。そのため、計画で定めた内容が現実的なものとなっているのかどうかを判断することはできない。現実的でない計画とは、無理やりタスクを終わらすなどの現実的でないスケジュールの計画や、タスクの洗い出しが不十分でタスクを洗い出しながら自転車操業的に進めざるを得なくなるような計画のことをいう。このような現実的でない計画を立案した場合、それは必ず進捗に表れてくると考える。無理のあるスケジュールでの推進であっても、急なタスクが追加された場合であっても、いずれも進捗の遅延という形で表れてくると考えるからである。そこで、プロジェクトの状況をより正確に表すには進捗状況を数値に反映する必要があると考え、以下の数値を利用することにした。

予定に対する実績とは具体的には以下のような指標である。

進捗率％　＝　（　予定されたタスク数　－　完了したタスク数　）　／　予定されたタスク数

プロジェクト状況のスコアリングは一つ目の要素である「計画・評価等のマネジメントタスクの達成度」を基準とする。例えば、数値化を図る時点で本来完了されているべきマネジメントタスクが5タスクで、期限内にすべて完了していた場合、マネジメントタスクの達成度は5÷5＝100%の達成度となる。これをスコアリングの基礎点とする。

次に、二つ目の要素である予定と実績の差異を算出する。例えば、数値化を図る時点で本来完了されているべきタスクが50タスクで、そのうち40タスクしか完了しておらず10タスクが遅延している場合、10が予定と進捗の差異となる。

これらの２つの数値マネジメントタスクの達成度100と、予定と実績の差異10という数字を用いる。この場合のプロジェクト状況は

マネジメントタスクの達成度100 －　予定と実績の差異10　＝　90

がプロジェクト状況を示すスコアとなる。

以上がプロジェクト状況を数値化するスコアリングロジックの概要である。最低限かつプロジェクトの外観的な情報で数値化することが可能となっている。別の状況のプロジェクトと比較するとロジックの有用性の理解が深まると思われる。先に述べたプロジェクトと同様に、予定と進捗の差異は10の遅延の場合、進捗状況だけみると状況は同じと受け取ってしまう可能性がある。しかし、本来5タスク完了しているべきマネジメントタスクが2タスクしか完了していなかった場合は、マネジメントタスクの達成度は2÷5＝40となる。つまりこの場合のプロジェクト状況は、

マネジメントタスクの達成度40　－　予定と実績の差異10　＝　30

となる。これは進捗状況が同じであっても、先の計画が見通せているプロジェクトと自転車操業的に推進しているプロジェクトとでは安定度は大きく異なるという点は明らかである。その感覚的なものを、一つ目の要素である「計画・評価等のマネジメントタスクの達成度」の指標で表現し、プロジェクト状況の数値化に反映させた。

IT組織内における複数のプロジェクトに対して本スコアリングロジックを適用してすれば、全プロジェクトを横断的に数値化することが可能となる。IT組織長はスコアが低いプロジェクトから優先的に状況を把握しに動くなどとしていけば、限られたリソースとコストで複数のプロジェクトを横断的に状況把握することが可能となる。