システム導入を発注側から支援する株式会社インフィニットコンサルティング

BOOK | 書籍紹介

システム発注から導入までを成功させる90の鉄則

情報システム部門、IT担当者必携!!

システム発注から導入までを
成功させる90の鉄則

当社ITコンサルタントが執筆した、システム導入プロジェクトを成功させるためのノウハウを一挙公開!本書は、ユーザー企業のITプロジェクト関係者すべてに向けて書かれています。特に以下に複数該当する方には必読と言えます。

システム発注から導入までを成功させる90の鉄則
  • ・ITプロジェクトの主導権を自社で握りたい
  • ・ITプロジェクトの進め方を網羅的に教えてほしい
  • ・すぐに使えるノウハウとサンプルを入手したい
  • ・ベンダーとWin-Winのアプローチを知りたい
  • ・自社で情報システム部門を立ち上げたい
  • ・システムの導入効果を最大限に引き出したい
出 版 社:
技術評論社
発 行 年:
2017年
著   者:
田村 昇平


(株式会社インフィニット
コンサルティング ITコンサルタント)
価   格:
2,354円 (税込)

本書の目次

はじめに

目次

第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月
株式会社インフィニットコンサルティング
田村 昇平

page top