プロジェクト中止のタイミングを計る

ときには、痛みをできるだけ抑えながら中止することこそがITプロジェクトにとって最善の措置になる場合がある。その結論にたどり着くのはプロジェクトチームにとって容易ではないが、プロジェクト中止がビジネスのやり方として最も現実的なことはあるものだ。

いさぎよく失敗を認めて中止するのではなく、ひたすら前進を目指して傷口を広げていくプロジェクトにもやがては限界が訪れる。不幸なことに、こうした限界はプロジェクトに追加の時間と資金を注ぎ込んだ後にやって来るので、中止の決断はますます難しくなる。

プロジェクト中止が結果としてプラスになることの証明が必要になったときにやるべきことは、インストール環境におけるアプリケーション構成を検討することだけである。現在稼働中のシステムのなかに、組織の利益を考えれば中止しておくべきだった、と思えるものが少なくとも1つはあるだろうか。組織によっては、中止に値したはずのシステムが複数見つかることも珍しくない。

すべてのシステムがマネジメント層の思いどおりになるわけではない。だとしたら、アプリケーションなしでも組織がうまくやっていけるかをどのように判断すればよいのだろうか。結局、そうしたアプリケーションは日常的に稼働している以上、何らかの価値があるということになる。この主張は表面的には正しいかもしれないが、状況を詳しく調べれば、思ったほど実用的ではないアプリケーションが出てくるかもしれない。

そうした疑わしいシステムを判断するには、以下の質問に答えればよい。

そのシステムがもたらす情報の質はどれほどのものか？　情報は正確か？　情報は古くないか？　情報の内容は組織にとって価値のあるものか？　システムから得られるのは有益な情報か、それとも単なるデータか？
そのシステムを稼働させ続けるためにどれほどのメンテナンスが必要か？　うまく開発されていないアプリケーションを稼働させ続けるために、数名のIT社員を絶えず張り付かせておかなければならないこともある。これからずっと続くメンテナンスの出費は得られる情報に対して妥当といえるだろうか？
システムは定期的に再起動が必要になるか？また、問題解決のためにプログラムを修正した後にも再起動が必要か？
関係する処理サイクルまで台無しにしてしまうような処理の失敗が多いため、システムの再実行が必要になるか？
各アプリケーションが複雑でマニュアルが整備されていないため、IT部門にいる1、2人しか操作方法を理解していないようなシステムか？
システムで利用されているテクノロジは明確になっているか？　テクノロジには使用上の制約があり、ベンダからのサポートはほとんどないか？
アプリケーションを修正して組織の変更要求に合わせるのにかなりの時間と手間が必要か？

現実を直視する

開発のどの段階であってもプロジェクト解散の決定は、プロジェクトチームと関連部門、ときには上位マネジメント層内にも強力な反対と組織的抵抗を生むことになる。プロジェクト中止の問題を提起し、その後の（報酬および心情の両面で）不利益を負うには大変な勇気が必要だ。いったんこの問題を提起すれば、その結果の如何を問わず、自らを苦境に陥れることになるだろう。

たとえば、プロジェクトの中止を求めると、たとえ携わっていたメンバー間に対立や見解の違いがあったとしても、続行を望むメンバーどうしの団結を生むことになる。プロジェクトの中止を提案しただけで激しい反対が生じることは想像に難くない。エゴや自尊心、プロとしての評判、昇進の機会のほか、おそらく雇用の継続といった要因までもが、当事者たちを反対へと駆り立てるのだ。

こうした個人的および風土的な問題の向こうには、プロジェクトの中止に伴うビジネス上のマイナス面が見えてくる。ビジネス上の問題には、プロジェクトへの投資によって生じる収支上の損失が含まれる。また、プロジェクトの中止によって失われる潜在的なビジネス機会の問題もある。プロジェクトの承認を得たときには、プロジェクトの成功によって組織にもたらされるであろう利益の額が説得材料として当然含まれていただろうから、プロジェクトを中止すればこうした利益まで失われてしまうではないか、とすぐに反論してくる者がおそらくいるはずだ。

プロジェクト中止の結果、収支上の損失が出るとともに競合に対する優位性が失われるという事実を隠すことはできない。それでも中止がもっとも現実的な対処策であることを示せない限り、プロジェクトの中止はありえない。

中止を提案するだけの気概のある人物は、批判の嵐の中で耐え抜かなければならず、場合によっては自らのキャリアを危険にさらすことになるかもしれない。ただし、中止の提案こそが組織にとって最善の策だと確信しているなら、そうすることが正しい道だ。

中止に関する事実確認を行う

感情は、プロジェクトを中止に至らせる原動力の1つかもしれない。感情的な理由がどんなに妥当なものに思えたとしても、プロジェクト中止の訴えは、確固たる現実的なビジネスの問題に基づいていることが重要である。プロジェクトが問題を克服できそうにないことや、プロジェクトを軌道に乗せられない挫折感に耐えられないことが中止を求める原動力になっているのかもしないが、そうした感情的な根拠に基づいた訴えは失敗する。

事実を論じることが、プロジェクトの命運を決める人々の関心を惹く唯一の方法である。彼らは、プロジェクトを中止して計上されうるあらゆる損失を受け入れることがビジネス上の解決策として最善であることを納得しないと気が済まない現実主義者になろうとするからだ。

プロジェクト中止の権限を持つ人々は、それが正しいことを示す確固たる証拠を求める一方で、自分たちの周囲にプロジェクトの存続に賭ける人々がいることに気付くだろう。プロジェクトを守ろうとする人々は、必要と思われるどんな手段を使ってでも、中止の訴えが信用に値しないことを示し、プロジェクト中止を求める者を陥れようとするはずだ。そのため、プロジェクトの中止を支持するすべての意見は、強い反論に会うことになる。

しかし、最終的に問われる点はたった1つ、現時点で中止という思い切った措置が組織の利益にとって最善である理由は何か、である。この問いに答えるには、プロジェクトの問題のそれぞれをリストアップして、問題の解決が不可能な理由、または解決には容認できないほどの時間と資金が必要になる理由のどちらかを書き添える。

また、中止を訴える際には、それぞれの項目に対する反論を予想しておき、そうした反論に的確に応じられるように調査によってそれぞれの主張の裏付けを取っておくことだ。説明の途中で、プロジェクト中止に反対する人々がその事実に疑いを持つようであれば、その論争には負けることになるだろう。

まとめ

問題のあるITプロジェクトを中止させようとする場合、実はプロジェクトの関係者の多くが明らかに中止の必要性を感じていることは皮肉なことである。しかし、潜在的に強い影響力を持つ個人的な利害関係から、人々はなかなか行動に踏み切れないのだ。それどころか、プロジェクトの中止を訴えることは自らのキャリアを捨てることにもなりかねない。

もちろん、プロジェクトを中止させるよりも立て直すほうが良いという意見もあるだろうが、その意見が説得力を持つのは、作業の大部分が間違いなく回復できる場合だけである。だが、おそらくその可能性は低いだろう。立て直しを図る方法の問題は、プロジェクトにかかる予算と時間が倍増したうえに重大な欠陥のある業務システムに終わってしまう可能性があることだ。

プロジェクトに問題がある場合、容易に解決できることはまれだが、それに耐えて問題に向き合うことは間違いではない。ITの専門家を自認しているなら、部門内で生み出した成果を率直に評価することもプロとしての責任の1つだ。その成果が妥当な品質基準に満たないのであれば、異議を申し立てる義務がある。そうした主張によって自らのキャリアに傷が付くというのなら、そうさせておけばいい。するべきことをしないのは、組織と自分自身に対する裏切りにほかならない。