適切な立案と実施計画を
ITプロジェクトはなぜ失敗するのか
ITプロジェクトの目的は、アプリケーションやシステム、プロセスの改善だ。だが、適切な立案と実施計画がなされていなければ、プロジェクトは失敗してしまう。
ITプロジェクトというものは、アプリケーションやシステム、プロセスの何らかの側面を改善するという趣旨を掲げて、鳴り物入りでスタートする。内部プロジェクトか顧客向けの外部プロジェクトかにかかわらず、プロジェクトごとにビジョンステートメントやミッションステートメントが必ず作られていく。これらと同様にどちらのプロジェクトにも必要なのが、適切な立案と実施計画だ。
立案
プロジェクトがどのように生まれるかを考えておくのは有意義だろう。ごく最初の段階では、プロジェクトは誰かの頭の中で考え出されたアイデアだ。実際、わたしがかかわってきたプロジェクトの多くは、ある人（または少人数のグループ）の意見が出発点となっている。この意見は特定の状況に対する彼らの理解と認識に基づいて組み立てられたものだ。多くの場合、この意見が検討に付され、それを基に一連の手続きを経てプロジェクトが誕生する。わたしはこのアプローチを「ここがうまくいっていないからXYZを行って解決しよう」アプローチと呼んでいる。
プロジェクトで発生する問題の多くは、プロジェクトが生まれる過程に根本的な原因がある。当初の影響分析は多くの場合、不十分な理解や包括的なコンテキストの検討の欠如、最小限の課題定義に基づいている。単刀直入に言えば、人は大局を見失いがちだ。また、プロジェクトが主に個人の力をよりどころにして立ち上げられる場合もある。わたしはこれを、「あの人はベテランだから、ついていけば間違いない」アプローチ、あるいは「上司には黙って従え」アプローチと呼んでいる。
だが、不適切な、あるいは不完全な情報やコンテキストに基づいて考えられたプロジェクトは、ろくにテストしていない車でグランプリレースの未知のコースを走るようなものだ。
このため、事前に十分掘り下げて調査検討を行わなければならないが、そうすると、そもそもプロジェクトを行う必要がないことが判明するかもしれない。
実施計画
プロジェクトの実施に当たっては、あらかじめ適切かつ十分な計画を立てておかないと後々まで苦労するはめになる。ここでの計画は、Microsoft Projectなどを使ったスケジュールやリスク管理表の作成だけを指すわけではない。プロセスや方法論、アーティファクト（成果物）などを包括的に網羅した計画を指している。
適切なアプローチを選ぶ
現状では、ハイブリッドアプローチを選択しているプロジェクトがあまりに多い。こうしたプロジェクトでは、ウォーターフォール、反復型開発、アジャイルの各アプローチが少しずつ組み合わされ、そのほかにも各種のアーティファクトなどを伴うさまざまな手法が利用されている。これは、ベストプラクティスの採用が目的とされる。しかし、ベストプラクティスは結局のところ、特定のコンテキストの下でベストプラクティスであるにすぎない。このことを覚えておく必要がある。アジャイルアプローチのベストプラクティスは、従来型のプロジェクトには通用しないだろう。わたしはプロセスや方法論などの運用が混乱してしまったプロジェクトをしばしば見てきた。
品質に大きな重点を置く
プロジェクトの実施に当たって計画を立てておかないと、ほぼ必ず影響が及ぶ側面の1つが品質だ。品質に十分に重点を置かなければ、多くの問題の芽を摘むチャンスを逃してしまう恐れがある。テストを行うことは、テストケースやテスト計画、欠陥といったものを超えた視点からとらえることができる。本質的に言えば、テストは自らが何を行っているかを問う（ただし、専門的な観点から問う）方法だ。「われわれは正しいことを行っているか？ 正しい方法で行っているか？」と、チームとして自問する方法なのだ。この自問は早いうちから、つまりプロジェクトを開始するときから行う必要がある。
人々がプロジェクトの実現可能性を問題にする場面はよくあるが、「実現可能性」という言葉を使ったとたん、人々は頭の中で既に2番目の段階に移っている。この段階では、プロジェクトを実行することが可能かどうかが問われている。最初の段階で、プロジェクトがそもそも本当に必要なのかどうかをチェックする機会が失われていることになる。
人を大事にする
計画には、プロジェクトメンバーを理解するための計画を含めなければならない。計画を立てるのはプロジェクトを実施するためであり、プロジェクトの実施の成否は人に懸かっている。マネジャーやアーキテクト、リーダーが人の問題を乱暴に扱ったり、十分に考慮していないケースが非常によく見られる。
人の管理はサイエンスではなくアートだ。現在の競争の中で生き残り、勝ち抜くためには、このアートをマスターする必要がある。仕事を楽しいものにし、個々のプロジェクトメンバーとその将来の志望を理解して彼らの可能性を引き出すことは、一朝一夕にはできない。メンバーとは、歯磨きのように日常的に、お互いになじんで気軽に話せるくらいに密なコミュニケーションを取らなければならない。会議室で1回だけ話し合うのでは、生産的な結論に達するよりもかえって相手との距離が遠くなってしまう恐れの方が大きい。
以上のように、最初の段階から自問を重ね、やるべきことをすべて考慮し、大局を見据え、そしてメンバーに気を配ることが重要だ。
わたしはこれらの実践を万能の解決策として勧めるほど単純ではないし、書き方は千差万別ながら、これらと同じ趣旨のことを述べている膨大な記事や調査報告書があることも認識している。しかし、「これらは姿勢として取り入れ、その中に込められた精神こそを生かさなければならない」ということは指摘しておきたい。避けなければならないのは、計画の不備のせいで余分なベストプラクティスを導入済みであるにもかかわらず、これらをさらにもう1つのベストプラクティスとして採用し、チェックリストにチェックを入れる、といった事態になってしまうことだ。
本稿筆者のデバシシ・チャクラバーティ氏は、Sapientのシニアアソシエート。ITとテストに約8年携わっており、機能テスト、非機能テスト、テスト管理を担当している。
Copyright © ITmedia, Inc. All Rights Reserved.
関連記事
新着ホワイトペーパー PR
-
製品資料
[o9ソリューションズ・ジャパン株式会社] 「改正物流効率化法対策」徹底解説 総物流費を抑制するサプライチェーン戦略 -
製品資料
[o9ソリューションズ・ジャパン株式会社] 「サプライチェーン最適化」実践ガイド：効果的な意思決定を実現する秘訣とは？ -
製品資料
[株式会社リンプレス] 非デジタル／IT人材を「自走するDX推進者」に変えるための育成ロードマップ -
市場調査・トレンド
[ワンアイルコンサルティング株式会社] AI時代の組織設計：「判断と責任」を人に残すための2つの原則とは？ -
技術文書・技術解説
[ワンアイルコンサルティング株式会社] システムの保守がモダン化を阻む？ 「変えない判断」から脱却する方法とは
こんなメディアも見られています
TechTargetジャパンに関連する情報をお探しであれば、こちらのメディアもお役に立てるかもしれません。
ベンダーコンテンツ PR
From Informa TechTarget
SpecialPR
アクセスランキング
-
1
「完璧な設計」なのに3000万円溶けた AWSの失敗事例から学ぶ3つの教訓
-
2
パナソニックが国内製造26拠点のERPを「SAP S/4HANA」に統一 アドオン7割削減
-
3
「AIバブル」は崩壊するのか？ 熱狂の後に来る“尻拭い”と4つの防衛策
-
4
Microsoft製品でここまで自動化できる 情シスがやめられる手作業10選
-
5
守るべきは「開発者のフロー状態」 AIによる生産性改善の6施策
-
6
脱VMwareの前提が崩れる BroadcomのVDDK公開停止で確認すべき点
-
7
「データストレージの活用方法」に関するアンケート
-
8
全社標準「Copilot」にダメ出し？ 現場の8割が不満を抱く“致命的な欠点”
-
9
「企業内サーバ環境の利用実態」に関するアンケート
-
10
100億円の「Linux更新」を回避 みずほ銀行が選んだ“おきて破り”のRHEL延命策
ホワイトペーパーランキング PR
-
1
JR西日本ITソリューションズが「監視業務の属人化」を解消した方法とは？
-
2
インシデント対応工数を約3割削減、東京ガスの事例に学ぶ監視体制刷新のコツ
-
3
生成AIで文書活用を進めるには？ 効率化と安全性をどう両立する
-
4
Windows PCとMacの選択制で生産性向上 LINEヤフーが実践する運用管理方法とは
-
5
DX／AI投資の壁を突破、現代の最高財務責任者が直面する課題と克服のヒント
-
6
「Google Workspace」活用事例34選、先進の生成AIによる組織変革の全貌
-
7
「人員を増やす」という選択肢はない 情シスが負の連鎖から抜け出すには？
-
8
Linuxのスキルを証明する“激推し”の認定資格はこれだ
-
9
「問題が深刻化しやすいプロジェクト管理」から脱却する方法とは？
-
10
Microsoft 365を安全に運用 うっかりミスやサイバー攻撃に備えるデータ保護術
TechTargetジャパン SNS
@techtarget_itmをフォロー
インフォメーション
注目情報をチェック
TechTargetジャパンをフォロー