keita_shimabの日記

京都在住Webディレクターのイベント参加メモや読書メモなど。

ITプロジェクトを失敗させる方法~失敗要因分析と成功への鍵~(読書メモ1)

 

f:id:keita_shimab:20170219120815j:plain

 

『ITプロジェクトを失敗させる方法~失敗要因分析と成功への鍵~』

2008年発行と少し古い本ですが、本書によるとプロジェクトの半数以上が失敗しているとか。

ITプロジェクトの成功率に関するいくつかの調査結果を見ると、その成功率は30%~50%という結果が出ています。つまり、ITプロジェクトの半数以上が失敗に終わっているということになります。

 

数字の出所が気になるところですが、興味深いテーマ。

 

目次は以下の通り。今回は「1.」の議事メモ。

  1. ITプロジェクトは、なぜ失敗するのか
  2. 提案・受注段階での失敗
  3. 立ち上げ・計画段階での失敗
  4. 実行段階での失敗
  5. 終了段階での失敗


失敗の種類

まずは「失敗」の定義から。以下いずれかに当てはまるものは失敗(残念)。

  1. 納期遅れ
  2. 予算超過
  3. 品質粗悪
  4. 利用されず廃棄
  5. プロジェクトの中止
  6. 関係者の疲弊

「4.」については、爆速でβ版をリリースして高速PDCAを回す過程の話であれば失敗ではないだろうと思わなくもないけれど、規模によっては確かに「失敗」と定義されて然り。

 

失敗要因分析の4つの切り口

プロジェクトの前提条件。これを捉えたうえで「どう成功を目指すか」なんだろうなと。

 

①ITプロジェクトの特徴

  • 結局は「人間業」であること。能力や体調、モチベーションが多分に影響する。
  • (ハンドリングが難しいけれど)仕様の曖昧性を許容する必要がある(創造的な作業であるため走りながら考える)。 etc

ゼロからイチを生み出す、ある種 宿命のようなものだと解釈(「仕様の曖昧性を許容」は個人的には大きな気付き)。

 

②ITプロジェクトを取り巻く環境

プロジェクト=茨の道としか捉えられない(笑)

  • コンピューター・システムが利用される領域が広がり、要求が多様化。要求の把握が困難に。
  • プロジェクトが企業の存亡をかけたものになり、外部環境の変化とスピードにあわせて仕様を変える必要がある。
  • 効率化と分業化の難しさ。そうせざるを得ないのだけれど、「問題やリスクが共有されない」「作業分担の隙間で発生する作業を誰も引き受けない」などの問題が出がち。etc

 

ステークホルダー(利害関係者)の影響

顧客(ユーザー)、ベンダー、プロジェクトマネージャー、プロジェクトチーム・メンバー、全ステークホルダーとの協業体制が必須。無関心や丸投げはダメ絶対。

 

④プロジェクトの段階

大きく以下のフェーズに分かれる。

  • 提案・受注段階
  • 立ち上げ・計画段階
  • 実行段階
  • 終了段階

それぞれの分析は、また別記事で。