そのままではITプロジェクトは永遠に失敗する
書籍情報
著者／編集 : ビジネスプロセス・アーキテクト協会
出版社 : 日経BP
発行形態 : 単行本
書籍説明
内容紹介
プロジェクトはなぜ成功しないのか、根本原因に迫る
情報システムは確かに動いたが、経営層とりわけ経営トップはIT投資の結果に納得していない。こうした「システムは導入できても、結果は失敗」というプロジェクトが後を絶たない。日本企業・組織の多くが、失敗の根本原因に相対していないからだ。
本書は、経営の視点からITプロジェクトが失敗する根本原因に切り込み、解決策を提示する。500を超えるプロジェクトを経験してきた筆者らが経験を基に成功への道筋をまとめ、新たな人材像「ビジネスプロセス・アーキテクト」を提示している。
実話に基づく生々しい失敗プロジェクトのエピソード、IT投資が適切かどうかを確認するチェックシート、経営層が知っておきたい基本IT用語40と併せて、IT投資の責任者がプロジェクトを成功に導くために必要な知識を、この一冊で丸ごと習得できる。
情報システムは確かに動いたが、経営層とりわけ経営トップはIT投資の結果に納得していない。こうした「システムは導入できても、結果は失敗」というプロジェクトが後を絶たない。日本企業・組織の多くが、失敗の根本原因に相対していないからだ。
本書は、経営の視点からITプロジェクトが失敗する根本原因に切り込み、解決策を提示する。500を超えるプロジェクトを経験してきた筆者らが経験を基に成功への道筋をまとめ、新たな人材像「ビジネスプロセス・アーキテクト」を提示している。
実話に基づく生々しい失敗プロジェクトのエピソード、IT投資が適切かどうかを確認するチェックシート、経営層が知っておきたい基本IT用語40と併せて、IT投資の責任者がプロジェクトを成功に導くために必要な知識を、この一冊で丸ごと習得できる。
目次
【1章】実録 失敗プロジェクト
事例1 ベンダーべったりの態度が失敗を招く
事例2 安すぎる見積もり金額に要注意
事例3 システムの必要性を思いつきで判断するトップ
事例4 プロジェクト体制を「ベンダーにお任せ」は危険 44
事例5 プロジェクトを振り回す素人CIO
【第2章】失敗事例から浮かび上がる五つの問題点
問題点1 「システム構想」が不明確
問題点2 構築金額に納得感がない
問題点3 責任者が曖昧または不適切
問題点4 参加すべき要員が参加していない
問題点5 ベンダーマネジメントが不十分
【第3章】まずはここから！ プロジェクトの失敗を防ぐ五つのポイント
構想ポイント①IT投資の構想が腑に落ちているか
（1）ビジネスとして何を実現したいのか、タガをはめているか
（2）コスト・ROI のフレームワークを明示しているか
（3）実現すべき内容が十分具体的・詳細か
構想ポイント②構築金額に納得感があるか
（1）成功の価値とそれを得るための費用、
リスクへの対応を含めた妥当性はあるか
（2）スキル不足やリスクの過大評価による見積もりの誤りはないか
（3）経営視点で見て妥当性はあるか
構想ポイント③「いかに実現するか」が明確か
（1）作業計画を想定しているか
（2）推進体制は適切か
（3）リスクを想定し対策を立てているか
（4）実現できそうな「匂い」を感じるか
体制ポイント①適切な人材をプロジェクト責任者に任命したか
（1）「成功」の責任を持っているか
（2）ITでビジネスにインパクトを与えたいと考えているか
（3）ベンダーマネジメントの責任を持っているか
体制ポイント②マネジャーが必要なスキルを備えているか
（1）事業・業務の構造を正しく理解しているか
（2）問題・課題の「本当の原因」を突きとめられるか
（3）関係者との利害調整をスムーズに行えるか
（4）ITを特別視せず分析・判断できるか
IT投資可否判断用チェックシート
【第4章】プロジェクトを成功に導く ビジネスプロセス・アーキテクト
ビジネスプロセス・アーキテクトが成否の鍵を握る
（Column）システム構築と建築の類似点と相違点
ビジネスプロセス・アーキテクトが持つべきスキル
（1）社内で育成可能なスキル
（2）外部からの導入を検討すべきスキル
【付 録】経営層が押さえておきたい 基本IT用語40
■ ITベンダー
■ ERPパッケージ
■ 運用
■ オフショア開発
■ 外注
■ 開発リスク
■ カスタマイズ、アドオン
■ 稼働判定
■ 業務アプリケーション
■ 業務改革マネジメント
（チェンジマネジメント）
■ クラウド
■ 工数
■ サービスレベル
■ 再構築
■ システム基盤
■ システム構想
■ システム構築プロセス
■ システム導入効果
■ システムトラブル
■ 仕様書
■ 情報システム
■ ステアリングコミッティー
■ 提案依頼書
（RFP ＝アールエフピー）
■ データ移行
■ テスト
■ デッドライン
■ 内製
■ バージョンアップ
■ PMO
■ フィット＆ギャップ
■ フェーズ分け
■ プロジェクト
■ プロジェクトオーナー
■ ヘルプデスク
■ 保守
■ 丸投げ
■ 要件定義
■ リアルタイム
■ リリース
■ 老朽化
事例1 ベンダーべったりの態度が失敗を招く
事例2 安すぎる見積もり金額に要注意
事例3 システムの必要性を思いつきで判断するトップ
事例4 プロジェクト体制を「ベンダーにお任せ」は危険 44
事例5 プロジェクトを振り回す素人CIO
【第2章】失敗事例から浮かび上がる五つの問題点
問題点1 「システム構想」が不明確
問題点2 構築金額に納得感がない
問題点3 責任者が曖昧または不適切
問題点4 参加すべき要員が参加していない
問題点5 ベンダーマネジメントが不十分
【第3章】まずはここから！ プロジェクトの失敗を防ぐ五つのポイント
構想ポイント①IT投資の構想が腑に落ちているか
（1）ビジネスとして何を実現したいのか、タガをはめているか
（2）コスト・ROI のフレームワークを明示しているか
（3）実現すべき内容が十分具体的・詳細か
構想ポイント②構築金額に納得感があるか
（1）成功の価値とそれを得るための費用、
リスクへの対応を含めた妥当性はあるか
（2）スキル不足やリスクの過大評価による見積もりの誤りはないか
（3）経営視点で見て妥当性はあるか
構想ポイント③「いかに実現するか」が明確か
（1）作業計画を想定しているか
（2）推進体制は適切か
（3）リスクを想定し対策を立てているか
（4）実現できそうな「匂い」を感じるか
体制ポイント①適切な人材をプロジェクト責任者に任命したか
（1）「成功」の責任を持っているか
（2）ITでビジネスにインパクトを与えたいと考えているか
（3）ベンダーマネジメントの責任を持っているか
体制ポイント②マネジャーが必要なスキルを備えているか
（1）事業・業務の構造を正しく理解しているか
（2）問題・課題の「本当の原因」を突きとめられるか
（3）関係者との利害調整をスムーズに行えるか
（4）ITを特別視せず分析・判断できるか
IT投資可否判断用チェックシート
【第4章】プロジェクトを成功に導く ビジネスプロセス・アーキテクト
ビジネスプロセス・アーキテクトが成否の鍵を握る
（Column）システム構築と建築の類似点と相違点
ビジネスプロセス・アーキテクトが持つべきスキル
（1）社内で育成可能なスキル
（2）外部からの導入を検討すべきスキル
【付 録】経営層が押さえておきたい 基本IT用語40
■ ITベンダー
■ ERPパッケージ
■ 運用
■ オフショア開発
■ 外注
■ 開発リスク
■ カスタマイズ、アドオン
■ 稼働判定
■ 業務アプリケーション
■ 業務改革マネジメント
（チェンジマネジメント）
■ クラウド
■ 工数
■ サービスレベル
■ 再構築
■ システム基盤
■ システム構想
■ システム構築プロセス
■ システム導入効果
■ システムトラブル
■ 仕様書
■ 情報システム
■ ステアリングコミッティー
■ 提案依頼書
（RFP ＝アールエフピー）
■ データ移行
■ テスト
■ デッドライン
■ 内製
■ バージョンアップ
■ PMO
■ フィット＆ギャップ
■ フェーズ分け
■ プロジェクト
■ プロジェクトオーナー
■ ヘルプデスク
■ 保守
■ 丸投げ
■ 要件定義
■ リアルタイム
■ リリース
■ 老朽化
著者情報
一般社団法人ビジネスプロセス・アーキテクト協会
