情報システム部門、IT担当者必携!
『システム発注から導入までを成功させる90の鉄則』
当社ITコンサルタントが執筆した、システム導入プロジェクトを成功させるためのノウハウを一挙公開!本書は、ユーザー企業のITプロジェクト関係者すべてに向けて書かれています。特に以下に複数該当する方には必読と言えます。
- ・ITプロジェクトの主導権を自社で握りたい
- ・ITプロジェクトの進め方を網羅的に教えてほしい
- ・すぐに使えるノウハウとサンプルを入手したい
- ・ベンダーとWin-Winのアプローチを知りたい
- ・自社で情報システム部門を立ち上げたい
- ・システムの導入効果を最大限に引き出したい
- 出 版 社:
- 発 行 年:
- 2017年
- 著 者:
- 田村 昇平(株式会社インフィニットコンサルティング ITコンサルタント)
- 価 格:
- 2,398円 (税込)
<本書の関連記事はこちら>
本書の目次
はじめに
目次
第1章 システムの企画提案~ITベンダー選定までのルール
- 1-1
- ITプロジェクトを社内横断的に立ち上げる
- 01
- ITプロジェクトで自社を加速させる
- 02
- ITプロジェクトは人選が運命を決める
- 03
- オーナーの立ち位置がプロジェクトの成否を分かつ
- 04
- 役割分担表はまず上流工程のみ定義する
- 1-2
- 適切な企画でプロジェクトの成功レールを敷く
- 05
- 企画がダメだと全てダメになる
- 06
- 企画書の目次はこう作る
- 07
- 全社目線でシステム導入の目的を設定する
- 08
- システム導入の背景・目的・効果はこう考える
- 09
- システムの効果は全ての数値化を試みる
- 10
- 要求機能一覧でブレない自社の基準を作る
- 11
- 要求機能一覧はこう作る
- 12
- システム関連図で森を描く
- 13
- パッケージ導入は選定がすべて
- 14
- パッケージ導入スケジュールはこう作る
- 15
- スクラッチ開発は総合力が問われる
- 16
- スクラッチ開発スケジュールはこう作る
- 17
- クラウドは事業面や業務面から相性を判断する
- 18
- クラウドでIT部門の負担を軽減する
- 19
- 基幹システムは全体計画に従い導入する
- 1-3
- 自社に最適なITベンダーを見つけるためにRFPを活用する
- 20
- RFPは最適なパートナーを選ぶ手段である
- 21
- RFP未完成でベンダーに声をかけない
- 22
- RFPの自社フォーマットを確立する
- 23
- RFPの目次はこう作る
- 24
- RFP本編はこう作る
- 25
- RFP本編で注意すべきこと
- 26
- RFP別紙で自社の業務内容を柔軟に伝える
- 27
- 業務フローで自社の説明責任を果たす
- 28
- 業務フローは自社で整理する
- 29
- 業務イベント図で業務をシンプルに表す
- 30
- 社内合意していないRFPは無意味
- 1-4
- ITベンダーは客観的かつ公正なプロセスで選ぶ
- 31
- ITベンダーと会う前に評価基準を作っておく
- 32
- 選定方針に従いベンダー評価シートを作成する
- 33
- ベンダーの実績を軽視しない
- 34
- あらゆる手段を駆使してRFP発行先を見極める
- 35
- ベンダーの提案を主体的に検証する
- 36
- パッケージは「ノンカスタマイズ」を目指す
- 37
- 「アップルtoアップル」で完成させる
- 38
- 選定会議で会社としての結論を出す
- 1-5
- ITベンダーとの契約書でトラブルを未然に防ぐ
- 39
- 著作権は必ず自社に帰属させる
- 40
- 瑕疵担保責任期間は1年を基準とする
- 41
- 多段階契約は自社に不利となる
第2章 プロジェクト立ち上げ~要件定義までのルール
- 2-1
- プロジェクト計画でベンダーとの良好な関係の枠組みを作る
- 42
- プロジェクト計画書で共同作業の方向を定める
- 43
- ベンダーWBSとは別に社内WBSを作る
- 44
- 社内WBSは全て自社タスクで構成する
- 2-2
- システム要件を俯瞰し導入効果を最大化する
- 45
- 要求機能一覧をベンダーと精査していく
- 46
- 現行帳票は全て無くす勢いで見直す
- 47
- システム間連携は自社の連携力が問われる
- 48
- システム間連携で注意すべきこと
- 49
- 自社でデータの手加工運用を前提としない
- 2-3
- 自社の課題解決力で進捗を加速させる
- 50
- 自社の課題管理表の方こそ重要
- 51
- 課題管理表はこう作る
- 52
- 課題管理は進捗を聞くだけでは意味がない
- 2-4
- マスターデータは自社の生死を分かつ
- 53
- マスターデータの手入力は最後の手段とする
- 54
- マスターデータは全件テストする
第3章 ユーザー受入テスト~システム検収までのルール
- 3-1
- システム検証の前にプロジェクト計画の仕切り直しをする
- 55
- 下流工程の役割分担表で仕切り直しをする
- 56
- 本物の管理者かどうかはWBSの扱いでわかる
- 57
- 管理者も仕様から逃げない
- 3-2
- 納品されたシステムを自社責任で徹底的に検証する
- 58
- 受入テストをカオスにしないためには
- 59
- 受入テストは4種類で計画する
- 60
- 機能確認テスト項目書はこう作る
- 61
- システム間連携テスト項目書はこう作る
- 62
- シナリオテスト項目書はこう作る
- 63
- シナリオテストはコーディネートするもの
- 64
- 現新比較テストは全件で行ってこそ意味がある
- 65
- 現新比較テストをExcelで行う方法
- 66
- 合わない理由を徹底的にトレースする
- 67
- 検収を遅らせるとlose-loseになる
- 3-3
- システム障害を主体的に管理することで致命傷を防ぐ
- 68
- 受入テストの障害管理表は自社が管理する
- 69
- 障害管理表はこう作る
- 70
- 障害管理表のボールが止まっていないか
- 3-4
- ITベンダーへのアプローチを工夫し品質を引き上げる
- 71
- 事前にベンダーテスト結果を確認する
- 72
- スクラッチ開発は品質報告書を要求する
- 73
- その遅延は本当にベンダーのせいか
第4章 ユーザー教育~システム本稼働までのルール
- 4-1
- マニュアルを作成し混乱と不満を最小限に抑える
- 74
- マニュアルは2種類ある
- 75
- マニュアルは誰が作るのか
- 76
- 業務マニュアルは大勢で作らない
- 4-2
- システムを実際に使うユーザーを味方につける
- 77
- 説明会で良いイメージをもってもらう
- 78
- 業務説明が先、システム操作が後
- 79
- システム操作説明会のリハーサルは必ず行う
- 4-3
- 新システムの稼動判定会議を開催し全社的に判断する
- 80
- システム稼働判定は自社主導で必ず行う
- 81
- 稼動判定表はこう作る
- 82
- 並行稼働後の稼働判定表はこう作る
- 83
- 稼動判定はプロジェクトマネージャーの責任で進める
- 4-4
- 万全な準備で本番稼動を迎える
- 84
- 初回稼動時は考えうる全てのチェックを行う
- 85
- 本番障害は軽率な対応をおこなわない
- 86
- 社内のミスによる本番障害は再発防止を考える
第5章 システム運用/保守のルール
- 5-1
- システムの開発体制から運用体制へスムーズに引き継ぐ
- 87
- 社内引継ぎの前に体制を明確にする
- 88
- 保守メンバーを交えて課題をたな卸しする
- 89
- ベンダーと積み残しの最終確認を行う
- 5-2
- システムの導入効果を最大限に引き出す
- 90
- 導入効果は定期的に点検しないと得られない
おわりに
巻末資料
本書序章(はじめに)
0.はじめに
プロジェクト失敗は誰のせいか
私はもともとITベンダー(システムを構築するIT企業)出身で、システム開発を行っていました。転職してコンサルタントになってからは、ベンダー側の支援、システムを発注するユーザー企業側の支援、客観的な立場での監査など、いろいろなポジションでITプロジェクトに関わってきました。
多くの成功プロジェクトに関わってきた半面、多くの失敗プロジェクトも見てきました。ベンダーの立場、ユーザー企業の立場、客観的な立場と様々な切り口で失敗を見てきました。そこで初めて分かってきたことがあります。 「失敗の原因はユーザー企業の力量不足」 ということです。
今までの失敗事例を振り返ってみると、ベンダーにも問題はありましたが、それ以上にユーザーに問題があることに気づきました。ただユーザーはお金を払う発注者の立場であり、責任を追及されることがないだけなのです。何か問題が発生すると、それは全てベンダーの責任とされます。ユーザーに問題があったとしても、ベンダーに責任転嫁されます。これはユーザー側に「お金を払っているんだから、それぐらいやってくれて当たり前だろう」という発注者マインドが作用しているためです。しかし、このような考え方をしている限りは、次のプロジェクトも同じ失敗を繰り返します。ベンダーが変わったところで、負を再生産する発注者が変わっていないからです。
例えば、ベンダーがプログラムを「失敗」した場合、おおよそ数十万円かかります。一方、ユーザーが間違った機能を要求したり、目的のずれたシステム構築を依頼したという「失敗」はどうなるでしょうか。金額換算すると機能単位では数百万円、システム単位だと数千万以上の損害が発生します。同じ「失敗」でも、ベンダーの失敗とユーザーの失敗では、与える影響が天と地ほどの差があるということです。
私は「プロジェクトの根幹を支えたい」そう思うようになりました。プロジェクトを支援するには、システムの作り手であるベンダー企業からではなく、使い手であるユーザー企業からの支援が最も効果があると判断しました。私は徐々に軸足をユーザー企業側に移していき、今ではユーザー企業の支援を専門としています。
なぜユーザーのノウハウが蓄積されないのか
なぜ、ユーザー企業はITプロジェクトを失敗するのでしょうか。ユーザー企業は、少なからず何らかのシステム導入を経験しています。その経験が、ノウハウとして蓄積されているはずです。しかし、実際には経験を生かせずに失敗してしまいます。その理由を3点挙げてみます。
- ①ベンダーのやり方にばらつきがある
- ベンダーは大手から中小企業まで実に多くの企業が存在し、1つとして同じ対応ではありません。独自のノウハウで主導権を握ろうとするベンダーもいれば、全て受身で下請け体質のベンダーもいます。設計書の書き方も、テストのやり方も、障害時の対応スタンスも全く異なります。つまり、1つのベンダーと築き上げたやり方が、別のベンダーでは通用しないのです。
- ②プロジェクトの推進と責任をベンダーに丸投げしている
- 本来は、発注側のユーザー企業が主体的にプロジェクトを推進し、責任を負う覚悟を持つべきです。しかし多くの現場では、ベンダーに推進と責任を丸投げしています。これではベンダー側にはノウハウが蓄積されますが、自社には何も残りません。
- ③書籍やインターネットで調べても何も出てこない
- ユーザー企業側でのITプロジェクトに関する書籍は、実はほとんどありません。ITベンダー側の本はかなり充実しているのですが、ユーザー側の本は見当たりません。企画やRFP作成など部分的なものはあるのですが、プロジェクト全工程を解説した書籍はほぼ皆無です。インターネットで検索しても、ほとんどヒットしません。抽象的な表現に終始していて、実際に使えるノウハウやサンプルはありません。「ユーザー側のノウハウが世にないなら自分で書いてシェアしよう」これがこの本を書いた動機です。③を解決すれば、①と②も解決します。自社のノウハウが確立できれば、ベンダーに振り回されることはありません。
ユーザー主導権で進めましょう!
本書は、ユーザー企業のITプロジェクト関係者すべてに向けて書きました。特に以下に複数該当すれば、お役に立てると思います。
- ITプロジェクトの主導権を自社で握りたい
- ITプロジェクトの進め方を網羅的に教えてほしい
- すぐに使えるノウハウとサンプルを入手したい
- ベンダーとWin-Winのアプローチを知りたい
- 自社で情報システム部門を立ち上げたい
- システムの導入効果を最大限に引き出したい
ユーザー企業でITプロジェクトのノウハウを蓄積していくためには、自分たちが主体的にプロジェクトに関わっていくしかありません。自分たちで悩んで考えて作り上げたやり方が形となり、ノウハウとなって蓄積されていきます。自社で責任をもって進めるからこそ、成功も得られるのです。1つでも多くのITプロジェクトが成功し、システム関係者全員が笑顔になること。そのお手伝いできれば、これ以上に嬉しいことはありません。多くのユーザー企業が最適な情報システムを導入し、多くの企業が成長していく。多くの企業が世の中に貢献することで、日本全体が活性化する。これが私の目標です。ITプロジェクトをベンダーに依存せずに、自社で手綱をしっかり握って進めていきましょう!そして多くのユーザー企業の方が、ITプロジェクト成功の達成感を味わっていただければ幸いです。
2017年3月
株式会社インフィニットコンサルティング
田村 昇平
*** 関連記事はこちら ***
『システム発注から導入までを成功させる90の鉄則』出版記念インタビュー(20170411)【前編】
『システム発注から導入までを成功させる90の鉄則』出版記念インタビュー(20170411)【後編】
「システム発注から導入までを成功させる90の鉄則」著者に聞いたSEへの思い
***
『システム発注から導入までを成功させる90の鉄則』レビュー 【RULE02】ITプロジェクトは人選が運命を決める
『システム発注から導入までを成功させる90の鉄則』レビュー 【RULE05】企画がダメだとすべてダメになる
『システム発注から導入までを成功させる90の鉄則』レビュー 【RULE30】社内合意していないRFPは無意味
『システム発注から導入までを成功させる90の鉄則』レビュー 【RULE57】管理者も仕様から逃げない
『システム発注から導入までを成功させる90の鉄則』レビュー 【RULE73】その遅延は本当にベンダーのせいか
***
『システム発注から導入までを成功させる90の鉄則』レビュー(現場SE編)【RULE27】業務フローで自社の説明責任を果たす
『システム発注から導入までを成功させる90の鉄則』レビュー(現場SE編)【RULE36】パッケージは「ノンカスタマイズ」を目指す
『システム発注から導入までを成功させる90の鉄則』レビュー(現場SE編)【RULE45】要求機能一覧をベンダーと精査していく
『システム発注から導入までを成功させる90の鉄則』レビュー(現場SE編)【RULE48】システム間連携で注意すべきこと
『システム発注から導入までを成功させる90の鉄則』レビュー(現場SE編)【RULE56】本物の管理者かどうかはWBSの扱いでわかる
『システム発注から導入までを成功させる90の鉄則』レビュー(現場SE編)【RULE70】障害管理表のボールが止まっていないか
『システム発注から導入までを成功させる90の鉄則』レビュー(現場SE編)【RULE84】初回稼動時は考えうる全てのチェックを行う
『システム発注から導入までを成功させる90の鉄則』レビュー(現場SE編)【RULE85】本番障害は軽率な対応を行わない
***