日経コンピュータの人気コーナーの単行本。10年以上前に出たものですが、ITプロジェクトの失敗の本質は今も昔も変わらないので、勉強になるのです。
↑気になったらここからポチっと↑
注）Challengedは費用やスケジュールが予定を超過したがやり切ったもの（炎上→鎮火）、Failedはプロジェクト自体を中断したもの（炎上→撤退）を示します。
Source: https://www.standishgroup.com/sample_research_files/CHAOSReport2014.pdf
※最新版は有料ですが、過去分（2014年版など）は無料で閲覧できます。
↓気になったらここからポチっと↓
↑気になったらここからポチっと↑
動かないコンピュータ
日経コンピュータという日経が発行するIT総合情報誌の人気コーナーである”動かないコンピュータ”の単行本です。様々な業界におけるITシステム導入の失敗事例を基に、”何が起こり、どうすれば防げたのか”を考察していきます。ITシステム導入における失敗要因
本書では以下の11の失敗要因を挙げています。同じ業界で仕事をする者としては”あるある”ばかりなのです。- ソフトの不具合を解消できず：人間が作ったソフトにはバグはつきもので、それを試験フェーズで見つけていくのですが、設計フェーズがグズグズだとバグが収束せず炎上案件になるのです。
- システム構築企業の業務知識不足：ビジネス拡大のために経験のない業務を無理矢理受注して炎上するケースです。
- スケジュールに無理があり、仕様が不完全：これも無理矢理受注したケースです。本来は設計フェーズで仕様を固める必要があるのですが、スケジュールの都合で仕様が煮詰まらないままモノづくりに突入して炎上することが多いです。
- 顧客の受入確認が不十分：出来上がったITシステムはお客さんに受入試験（期待する動作をするかの確認）をしてもらいます。主にシステム部門のお客さんに確認いただくことが多いのですが、実際にシステムを使うお客さんのユーザー部門の関与が少ないと納入後にユーザー部門からクレームが出てもめることになります。
- システム構築企業の関与が足りず、顧客がシステムを運用できず：ITシステムは作って終わりではなく、実際にお客さんに使ってもらって初めて価値が出るため、システム構築企業はITシステムを納入し、安定稼働するまで面倒を見る責任があるのです。
- 顧客にシステム専任要員がいない：お客様システム部門の関与が薄いとシステム構築企業への丸投げになり、ユーザーが意図しないものが納入されて炎上します。
- 利用したPKGが業務に合わない：ERPのような標準機能を詰め込んだ製品をパッケージ（PKG）と呼びます。IT企業側としては、PKGが想定する業務フローにお客様業務を合わせてもらうよう働きかけるのですが、完全に合わせられることなどないので、どこまでを合わせて、どこまでをカスタマイズとして個別開発するかの線引きが腕の見せ所なのです。
- 顧客とシステム構築企業の役割分担があいまい・契約が不明確：責任の所在や役割分担をプロジェクト開始時に書面等で合意しておかないと実行フェーズで”言った・言わない”になったり、作業のお見合いが発生したり、丸投げになったりして炎上していくのです。
- システム運用の準備不足：5点目とも似ていますが、作って終わりではなく、安定稼働させなければ意味がないのです。
- 顧客の社内（システム部門とユーザー部門など）、顧客とシステム構築企業との人間関係のこじれ：ITシステム開発はお客様システム部門だけでなく、お客様経営層・ユーザー部門など様々なステークホルダがいるので、ステークホルダマネジメントが大事なのです。
- システム構築企業側担当者の異動・退職：作業やノウハウが属人化している場合、1人の担当者が抜けただけで炎上することもあるのです。
ITシステム開発は難しいのか？
自動車などの製造業やゼネコンなどの建設業と比較して、ITシステム開発は難易度が高いのでしょうか？個人的には難易度は高いんだろうなと思っています。いくつか理由を挙げるとこんな感じです。- 作っているものが目に見えづらい：製造業や建設業が作るモノと比較すると、ITシステム（プログラム）は目に見えづらくお客さんにとっては最終形がイメージしにくいのではないかと思います。特に設計フェーズでは紙の設計書がアウトプットであり、モノがないのでイメージしづらくなるのだと思います。プロトタイプを作ったりと努力はしていますが、クルマの模型やマンションのショールームと比較するとやはり一目で把握できる度合いが違いますよね。
- 労働集約的な産業である：ITと聞くとなにやら洗練されたイメージを持つかもしれませんが、実際の開発現場は人手による労働集約的な環境です。自動化ツールなどの導入も進んできましたが、人間がドキュメントを書いて→コードを書いて→試験をして→試験結果を赤ペンで消し込むという人力中心の開発現場はザラにあります。人手に依存するので作業効率や品質にムラができやすいのです。
- 若く未成熟な産業である：上記とも若干かぶりますが、IT業界自体が若い産業なので生産技術や方法論が発展途上です。機械によるファクトリーオートメーション導入前の自動車産業くらいの成熟度かもしれません。
世界的にはITプロジェクトの成功率は40％くらい
アメリカのStandish Groupという調査会社がChaos Reportというリサーチを行っています。”アメリカ版動かないコンピュータ”のようなもので、ITプロジェクトの成功・失敗をプロジェクトの規模や業態などで分析しています。以下の表がChaos Report 2014に掲載されているサマリです。成功率は概ね4割程度であり、半数以上が失敗・炎上していることになります。注）Challengedは費用やスケジュールが予定を超過したがやり切ったもの（炎上→鎮火）、Failedはプロジェクト自体を中断したもの（炎上→撤退）を示します。
※最新版は有料ですが、過去分（2014年版など）は無料で閲覧できます。
↓気になったらここからポチっと↓
