【ITニュース解説】Approving a Project Cost Nothing, So We Approved Everything

システムエンジニアを目指す皆さんにとって、プロジェクトを成功させることは重要な目標だ。しかし、技術的なスキルだけでは解決できない、プロジェクト管理における根深い問題が存在する。今回のニュース記事は、そうした問題とその解決策について深く掘り下げている。

このIT部門では、年間で同時に進められるプロジェクトの上限が約12件であるにもかかわらず、年初には41ものプロジェクトが進行中だった。これは、部門の対応能力を大幅に超える数だ。このような過剰なコミットメントは、誰かの意図的な決定ではなく、組織の仕組みから自然発生的に生まれたものだった。

その原因は、プロジェクトの承認プロセスにある。投資委員会は、個々のプロジェクトが予算に見合うか、どれだけの利益を生むかといった「費用対効果」は評価していた。しかし、「そのプロジェクトを実行するだけの人員や時間が確保できるか」という「キャパシティ（対応能力）」については、全く評価されていなかった。委員会が判断できるような明確なキャパシティの数値が存在しなかったためだ。さらに、魅力的なビジネスケース（事業計画書）を持つプロジェクトに対しては、「今、忙しいから」という理由だけで承認を拒否することは非常に困難だった。

その結果、部門の対応能力をはるかに超える数のプロジェクトが承認され、以下のような深刻な問題が発生した。 まず、「すべてのプロジェクトが均一に遅れる」という現象だ。処理能力を超えても、プロジェクトは順番待ちの「キュー（待ち行列）」にはならず、すべてが同時に進行し、結果としてどれもが中途半端に遅れてしまった。 記事によれば、特定の6人の専門家が19もの異なるプロジェクト計画に名前を連ねていた。これは、それぞれの専門家が1つのプロジェクトに割ける時間がごくわずかであることを意味する。その結果、プロジェクトの完了までの期間が約2倍に延びてしまった。プロジェクトが長引くほど、開始時に想定されていた便益（メリット）の前提が古くなり、その価値が低下していくという悪循環に陥る。 さらに、どのプロジェクトを優先して進めるかは、「最も粘り強く要求した人」によって決まるようになっていた。これでは、本来会社の戦略や価値に基づいて決めるべき優先順位が形骸化し、本当に価値の高いプロジェクトが後回しにされる事態も起こり得る。

もう一つの大きな問題は、「一度始まったプロジェクトが、決して止まらない」という点だった。プロジェクトの「一時停止（Pause）」は、担当者が他の緊急性の高い作業に必要とされれば、公式な決定なしに自然と発生した。しかし、「中止（Cancel）」となると事情は異なる。中止するには、「過去に承認されたプロジェクトが間違っていた」と誰かが公式に認めなければならないが、これは組織にとって非常に難しい決断だ。結果として、会社が抱える全プロジェクト（ポートフォリオ）は増え続ける一方だった。実質的には何ヶ月も休止しているプロジェクトが、形式上は「進行中」としてカウントされ続け、全体の約3分の1を占めるまでに膨れ上がっていた。

このような状況を改善するため、この部門は抜本的な対策を講じた。 第一に、「キャパシティステートメント」の導入だ。これは、各チームが1ヶ月あたりにどれだけの作業をこなせるかを具体的な単位で明確に示したもので、キャパシティを「見える化」した。そして、「プロジェクトは、人員が確保されていなければ開始しない」というルールを徹底した。 第二に、「可視化されたキュー」を導入し、プロジェクトの開始待ちリストに明確な順序をつけた。これにより、優先順位が客観的に決定されるようになった。また、新しいプロジェクトを開始するには、「現在進行中のどれかのプロジェクトを終了させるか、あるいは停止させる」ことを明示的に宣言する必要があるようにした。これは、無限にプロジェクトが増え続ける状態に歯止めをかける重要な仕組みだ。 第三に、プロジェクトの進捗報告方法を変更した。以前の「完了率（パーセンテージ）」は、実質的な成果がなくても数字だけは上がり続けるという問題があった。そこで、今後は「開始された作業量」に対して「実際に完了した作業量」を報告する形に変更した。これにより、本当の意味で何がどれだけ完了したのかが明確にわかるようになった。

これらの改革は、短期間で具体的な成果を生んだ。最初の四半期だけで、4つのプロジェクトを正式に停止し、6つのプロジェクトを意図的に、かつ書面で一時停止させ、そして9つのプロジェクトを完了させた。特に注目すべきは、停止された4つのプロジェクトのうち3つは、すでにその責任者である「スポンサー」がいなくなっていたことだ。これは、それらのプロジェクトが実質的に放置され、死んでいた状態だったことを裏付けている。

このニュース記事が私たちに教えてくれる最も重要な教訓は、「優先順位付け」の本質だ。優先順位付けとは、「何が重要でないか」を決めることではない。実際、ほとんどすべてのプロジェクトは、何らかの形で重要性を持っていた。真の優先順位付けとは、「何が待つべきか」を決定することである。そして、その判断を下し、実行することを許された人が、組織の中に存在しなければならない。

システムエンジニアとして皆さんが関わるプロジェクトは、個々の技術だけでなく、このようなプロジェクト全体の管理や運営の仕組みに大きく影響される。効率的なプロジェクトの進行を阻害する根本原因を見つけ出し、改善していく視点は、将来どのようなITプロジェクトに関わる上でも非常に価値のあるものとなるだろう。この事例は、現場のシステムエンジニアの働き方や、生み出される成果物の質にも直結する重要なテーマであることを理解してほしい。