ITプロジェクトはなぜ失敗するのか：適切な立案と実施計画を
ITプロジェクトの目的は、アプリケーションやシステム、プロセスの改善だ。だが、適切な立案と実施計画がなされていなければ、プロジェクトは失敗してしまう。
ITプロジェクトというものは、アプリケーションやシステム、プロセスの何らかの側面を改善するという趣旨を掲げて、鳴り物入りでスタートする。内部プロジェクトか顧客向けの外部プロジェクトかにかかわらず、プロジェクトごとにビジョンステートメントやミッションステートメントが必ず作られていく。これらと同様にどちらのプロジェクトにも必要なのが、適切な立案と実施計画だ。
立案
プロジェクトがどのように生まれるかを考えておくのは有意義だろう。ごく最初の段階では、プロジェクトは誰かの頭の中で考え出されたアイデアだ。実際、わたしがかかわってきたプロジェクトの多くは、ある人（または少人数のグループ）の意見が出発点となっている。この意見は特定の状況に対する彼らの理解と認識に基づいて組み立てられたものだ。多くの場合、この意見が検討に付され、それを基に一連の手続きを経てプロジェクトが誕生する。わたしはこのアプローチを「ここがうまくいっていないからXYZを行って解決しよう」アプローチと呼んでいる。
プロジェクトで発生する問題の多くは、プロジェクトが生まれる過程に根本的な原因がある。当初の影響分析は多くの場合、不十分な理解や包括的なコンテキストの検討の欠如、最小限の課題定義に基づいている。単刀直入に言えば、人は大局を見失いがちだ。また、プロジェクトが主に個人の力をよりどころにして立ち上げられる場合もある。わたしはこれを、「あの人はベテランだから、ついていけば間違いない」アプローチ、あるいは「上司には黙って従え」アプローチと呼んでいる。
だが、不適切な、あるいは不完全な情報やコンテキストに基づいて考えられたプロジェクトは、ろくにテストしていない車でグランプリレースの未知のコースを走るようなものだ。
このため、事前に十分掘り下げて調査検討を行わなければならないが、そうすると、そもそもプロジェクトを行う必要がないことが判明するかもしれない。
実施計画
プロジェクトの実施に当たっては、あらかじめ適切かつ十分な計画を立てておかないと後々まで苦労するはめになる。ここでの計画は、Microsoft Projectなどを使ったスケジュールやリスク管理表の作成だけを指すわけではない。プロセスや方法論、アーティファクト（成果物）などを包括的に網羅した計画を指している。
適切なアプローチを選ぶ
現状では、ハイブリッドアプローチを選択しているプロジェクトがあまりに多い。こうしたプロジェクトでは、ウォーターフォール、反復型開発、アジャイルの各アプローチが少しずつ組み合わされ、そのほかにも各種のアーティファクトなどを伴うさまざまな手法が利用されている。これは、ベストプラクティスの採用が目的とされる。しかし、ベストプラクティスは結局のところ、特定のコンテキストの下でベストプラクティスであるにすぎない。このことを覚えておく必要がある。アジャイルアプローチのベストプラクティスは、従来型のプロジェクトには通用しないだろう。わたしはプロセスや方法論などの運用が混乱してしまったプロジェクトをしばしば見てきた。
品質に大きな重点を置く
プロジェクトの実施に当たって計画を立てておかないと、ほぼ必ず影響が及ぶ側面の1つが品質だ。品質に十分に重点を置かなければ、多くの問題の芽を摘むチャンスを逃してしまう恐れがある。テストを行うことは、テストケースやテスト計画、欠陥といったものを超えた視点からとらえることができる。本質的に言えば、テストは自らが何を行っているかを問う（ただし、専門的な観点から問う）方法だ。「われわれは正しいことを行っているか？ 正しい方法で行っているか？」と、チームとして自問する方法なのだ。この自問は早いうちから、つまりプロジェクトを開始するときから行う必要がある。
人々がプロジェクトの実現可能性を問題にする場面はよくあるが、「実現可能性」という言葉を使ったとたん、人々は頭の中で既に2番目の段階に移っている。この段階では、プロジェクトを実行することが可能かどうかが問われている。最初の段階で、プロジェクトがそもそも本当に必要なのかどうかをチェックする機会が失われていることになる。
人を大事にする
計画には、プロジェクトメンバーを理解するための計画を含めなければならない。計画を立てるのはプロジェクトを実施するためであり、プロジェクトの実施の成否は人に懸かっている。マネジャーやアーキテクト、リーダーが人の問題を乱暴に扱ったり、十分に考慮していないケースが非常によく見られる。
人の管理はサイエンスではなくアートだ。現在の競争の中で生き残り、勝ち抜くためには、このアートをマスターする必要がある。仕事を楽しいものにし、個々のプロジェクトメンバーとその将来の志望を理解して彼らの可能性を引き出すことは、一朝一夕にはできない。メンバーとは、歯磨きのように日常的に、お互いになじんで気軽に話せるくらいに密なコミュニケーションを取らなければならない。会議室で1回だけ話し合うのでは、生産的な結論に達するよりもかえって相手との距離が遠くなってしまう恐れの方が大きい。
以上のように、最初の段階から自問を重ね、やるべきことをすべて考慮し、大局を見据え、そしてメンバーに気を配ることが重要だ。
わたしはこれらの実践を万能の解決策として勧めるほど単純ではないし、書き方は千差万別ながら、これらと同じ趣旨のことを述べている膨大な記事や調査報告書があることも認識している。しかし、「これらは姿勢として取り入れ、その中に込められた精神こそを生かさなければならない」ということは指摘しておきたい。避けなければならないのは、計画の不備のせいで余分なベストプラクティスを導入済みであるにもかかわらず、これらをさらにもう1つのベストプラクティスとして採用し、チェックリストにチェックを入れる、といった事態になってしまうことだ。
本稿筆者のデバシシ・チャクラバーティ氏は、Sapientのシニアアソシエート。ITとテストに約8年携わっており、機能テスト、非機能テスト、テスト管理を担当している。
Copyright © ITmedia, Inc. All Rights Reserved.