失敗しないパッケージ導入７
•
0 likes•311 views
システム導入成功率は依然３割。 失敗するなら、やらないほうがマシ・・・、とならずに 確実にシステム導入を成功させるためのポイントを解説します。 中小企業診断士 システム監査技術者 小島規彰 http://www.asahi-bs.com/
Recommended
More Related Content
What's hot
Viewers also liked
Similar to 失敗しないパッケージ導入７
Similar to 失敗しないパッケージ導入７ (20)
More from 小島 規彰
Recently uploaded
Recently uploaded (11)
失敗しないパッケージ導入７
- 1. 1. ＩＴプロジェクトは失敗するものだ 2. パッケージ商品の現状 3. ＩＴプロジェクトの失敗とは 4. なぜ失敗するのか 5. 失敗しないために何をすべきか 6. チェックの対象と視点 7. Ⅰ初期検討とプロジェクト立ち上げ準備 8. Ⅱ現状分析と要求仕様・RFP作成 9. Ⅲパッケージソフトとベンダーの選択 10. Ⅳキックオフまでの準備 11. Ⅴ導入フェーズ（前半） 12. Ⅵ導入フェーズ（後半） 13. Ⅶプロジェクトマネジメント 14. Ⅷプロジェクト完了 15. おわりに 123
- 2. Ⅶ－１ ボトムアップの意見が上がらない雰囲気になっている（問題管理） 発生する問題 メンバーからの問題提起があったが、プロジェクトマネージャの理解では、該当メンバーがもっと頑張っ ていれば（例えば、残業してでも対応）起きなかったはずの問題である。ゆえに、「あなたの責任で対応 しなさい」と、メンバー個人の責任にしてしまうような発言を皆の前でしてしまった。その後、メンバー は自分の責任になるならと、問題があっても発言しないようにしようという雰囲気ができてしまった。 発生頻度 3 影響度 3 危険度 9 チェック項目 プロジェクトの問題検知能力 チェック視点 ①メンバーの発言を抑え込むような雰囲気になっていないか？ ②なんとなくな流れ、全体の雰囲気、特定の上席者等誰かの顔色を伺う的なものができあがっていない か？ ③問題を面倒臭がるような雰囲気になっていないか？ チェック手法 ・問題管理票の各項目に関して、その発生経緯をプロジェクトマネージャと問題起票者にそれぞれヒアリ ング、差異を確認 ・プロジェクトメンバー、ベンダーへの抱えている問題についてのヒアリング ・上記ヒアリング結果と問題管理票記載のリスト内容との突き合わせ チェック時期 プロジェクト実施中随時 ＯＫ・ＮＧの例 - 124
- 3. Ⅶ－２ 遅延しないよう、メンバーにもベンダーにも無理を言って、残業、休日出勤さ せる（要員管理） 発生する問題 初めが肝心とスケジュール通りの進捗を順守するあまり、メンバーの健康を無視した対応を要求した。ひ とりふたりと体調不良を訴える者が出てくると、残りのメンバーの負荷も高まり、そのメンバーも何かと 体調不良を訴え、有休を取りたがる状態になってしまった。 発生頻度 1 影響度 2 危険度 2 チェック項目 プロジェクトメンバーの健康 チェック視点 ①80時間を超える残業・時間外勤務が３ヶ月続いていないか？100時間を超える残業が２ヶ月連続してい ないか？ ②プロジェクトマネージャが納期厳守にあまりにも固執していないか？ ③プロジェクトの良い雰囲気が強すぎる責任感を生んでいないか？ チェック手法 ・プロジェクトマネージャへのスケジュール遅延の対策についての見解をヒアリング ・プロジェクト会議体でのスケジュールについての会話内容を観察 チェック時期 ・工数管理票作成後 ・週次、月次勤務表作成後 ＯＫ・ＮＧの例 - 125
- 4. Ⅶ－３ スケジュールを延ばし延ばしにしている（進捗管理） 発生する問題 遅延しそうでも、紙面上のスケジュールを変更するだけで、なんとかなると思われ、「もっともな理由を 言えばプロジェクトマネージャもうるさく言わない。」といった雰囲気がメンバーに浸透している。それ に伴い、さまざまなところで合意した内容の変更、約束が守れないなど、緊張感がゆるみだした。 発生頻度 3 影響度 1 危険度 3 チェック項目 スケジュール管理の実態 チェック視点 ①「しょうがないな」で期限を延ばしていないか？ ②期限が伸びることによる全体への影響をプロジェクト関係者が理解・合意しているか？ ③スケジュール遅延の原因を分析し、キャッチアップのための対策を講じているか？ チェック手法 ・プロジェクト会議体でのスケジュール変更についての会話内容を観察 ・スケジュール表の版数およびをその変更内容をチェック ・スケジュール変更内容と変更管理票関連事項との突き合わせ チェック時期 ・プロジェクト実施中に行われる会議体にて、適時 ・スケジュール表の内容変更後 ＯＫ・ＮＧの例 - 126
- 5. Ⅶ－４ いまさらコストとか言っていたら進むものも進まない（コスト管理） 発生する問題 プロジェクトも後半になって、メンバーも進め方にはだいぶ慣れてきたと同時に責任感も芽生えてきた。 品質チェックやドキュメントの整理に時間を割くあまり、当初計画していた工数をオーバーするように なった。それくらいは問題ないだろうとプロジェクトマネージャは考えていたが、経理からは残業代が増 えていると注意されたが。「なんとかお願いします」とやり過ごしていたものの、ラインマネージャから も「コスト管理くらいしっかりやってくれないと、メンバーこれ以上貸さないよ」と言われてしまった。 同時に「最近上司からあたりが厳しく、プロジェクトの仕事がやりづらい」とメンバーが困惑しだした。 発生頻度 2 影響度 2 危険度 4 チェック項目 コスト管理の実態 チェック視点 ①特に要員について、コストの予実管理が適切できているか？ ②実績について、ラインマネージャの了解、合意は得ている？ チェック手法 ・実績管理帳票の記録状況をチェック ・アーンドバリュー分析等の結果をチェック チェック時期 プロジェクト実施中に作成される、コスト管理票作成後（週次、月次） ＯＫ・ＮＧの例 - 127
- 6. Ⅶ－５ 仕様変更の意思決定が、技術者の意見に左右される。（変更管理） 発生する問題 技術部分に詳しくないプロジェクトマネージャが、難しい技術のことを言うエンジニアに遠慮してしまう。 それによって、コスト、スケジュール、新業務機能への影響の有無を十分に検討せずに、当初の仕様から 徐々にずれていく。一度変わった仕様については、もはやプロジェクトマネージャの技術的理解を超え、 サーバやストレージの調達コストが当初の2倍に跳ね上がってしまった。 発生頻度 3 影響度 2 危険度 6 チェック項目 変更管理の実態 チェック視点 ①技術以外の観点からも検討し、プロジェクトマネージャが総合的な判断をしているか？ ②その変更がプロジェクトの目的に照らして妥当な内容なのか、しかるべき人が説明できるのか？ ③変更が、適切な手順（影響範囲調査、承認、費用変更）で検討されているか？ チェック手法 ・プロジェクト会議体での仕様変更についての会話内容を観察 ・変更管理用ドキュメントの議事内容（検討内容、承認者）を確認 チェック時期 ・プロジェクト実施中に行われる会議体にて、適時 ・変更管理票の起票後、承認後 ＯＫ・ＮＧの例 - 128
- 7. Ⅶ－６ win-loseな安易な仕様変更をベンダーに強いる （スコープ管理） 発生する問題 プロジェクトがうまくいっており、スケジュールにも余裕がある。もっとできるんではないかとの思いか ら、これをやるにはこうしたほうがいい、ここをこうするにはあっちも同時に変えたほうがいいなど、要 求仕様の範囲が広がってしまった。もともとのスケジュール内に収まるならと、ベンダーにも無理な要求 をのませることとなった。しかしプロジェクト後半になり、追加した部分の細かな調整が影響し、全体の スケジュールに遅れが出てきた。ベンダーからは追加要件分のコスト追加を要求されている。 発生頻度 3 影響度 3 危険度 9 チェック項目 スコープ管理の実態 チェック視点 ①「これなんとかならない？ ねっ頼むよ！」で仕様変更を依頼していないか？ ②不利・未確定の交換条件（「次なんかあったきもお宅にお願いすることになるんだから」等）をもとに 交渉していないか？ チェック手法 ・プロジェクト会議体での仕様変更についての会話内容を観察 ・変更管理用ドキュメントの議事内容（検討内容、承認者）を確認 ・プロジェクト計画書のスコープ記述部分と変更内容の突き合わせ チェック時期 ・プロジェクト実施中に行われる会議体にて、適時 ・変更管理票の起票後、承認後 ＯＫ・ＮＧの例 - 129
- 8. Ⅶ－７ ベンダーとの関係が、いつまでたっても良くならない（ベンダー管理） 発生する問題 上からリスクはベンダーに負わせろと言われていたので、契約書、覚書等文書できっちり定義されたこと でないと交渉ができない状況になっている。ベンダー側もそれを察知し、契約書に書いていない内容なの で知りません、やれませんといった対応が続き、ドライな関係ができてしまった。ちょっとしたお願いに も費用追加を言われ、一言しゃべるにも気を使う関係になり、進みが悪くなった。 発生頻度 2 影響度 2 危険度 4 チェック項目 ベンダーとの連携/協力関係 チェック視点 ①冗談が言い合える雰囲気が作れているか？ ②「ごめんなさい」や「私の失敗です」が言える雰囲気があるか？ ③適度な緊張感がある距離感をお互いが作ろうとしているか？ ④時間外のコミュニケーションが図れているか？ チェック手法 ・プロジェクト会議体での全体の様子を観察 ・会議体以外での、ユーザ側とベンダー側のコミュニケーションンの雰囲気を観察 チェック時期 ・プロジェクト実施中随時 ＯＫ・ＮＧの例 - 130
- 9. Ⅶ－８ 機能の実現を一番の重要事項として、次工程へのＯＫを出してしまっている。 （品質管理） 発生する問題 要件で定義した機能が実現した。非機能要件のほうは30%のずれがあったが、プロジェクトマネージャは、 さほど問題ないレベルだろうと考えた結果ＯＫを出した。その後工程が進み、いくつかの要件を確認した のち、非機能要件のずれは要求の100%ずれを生じるまでになってしまった。これらの解決のためにはハー ドを追加してもらわなければならないとコスト負担を強いられた。 発生頻度 3 影響度 2 危険度 6 チェック項目 品質管理の実態 チェック視点 ①計画時に作成した品質測定を継続して行っているか？ ②要件確認、工程レビューの時に、「動けばいい」の確認になっていないか？ チェック手法 ・品質チェックの時期を品質計画の内容と突き合わせ ・品質管理用のドキュメントを閲覧、確認 ・ベンダーからの品質確認に対する回答内容を観察 チェック時期 ・プロジェクト実施中に行われる会議体にて、適時 ・プロジェクトマネージャが品質管理票を更新した直後 ＯＫ・ＮＧの例 - 131
- 10. Ⅶ－９ ベンダーから提出された契約書に忙しくて目が通せていない（契約管理） 発生する問題 プロジェクト計画書の共通理解や要件定義等、決めるべきことはすべて決めてきたと、プロジェクトマ ネージャには一応の安心感があった。またプロジェクト管理に忙しい毎日が続き、契約書の中身の確認は 事務局にまかせていた。プロジェクト終了後に要件事項に関連すると考えられる事項の不具合が発生した が、契約書に記載している「要件以外の不具合は瑕疵担保の範囲外との」内容を理由に、対応が有償に なってしまった。 発生頻度 2 影響度 3 危険度 6 チェック項目 契約内容の理解 チェック視点 ①プロジェクトマネージャとプロジェクト責任者は、契約の内容を理解しているか？ ②契約内容がプロジェクトを遂行していく上での必要十分な内容になっているか？ チェック手法 ・プロジェクトマネージャとプロジェクト責任者への契約内容把握状況ヒアリング ・内容に問題ないことをどうやって、誰が承認したのかを確認（専門家への相談など） チェック時期 ・ベンダーからの契約書提出後 ・契約書の内容確認の会議にて ・契約締結前 ＯＫ・ＮＧの例 - 132
- 11. 1. ＩＴプロジェクトは失敗するものだ 2. パッケージ商品の現状 3. ＩＴプロジェクトの失敗とは 4. なぜ失敗するのか 5. 失敗しないために何をすべきか 6. チェックの対象と視点 7. Ⅰ初期検討とプロジェクト立ち上げ準備 8. Ⅱ現状分析と要求仕様・RFP作成 9. Ⅲパッケージソフトとベンダーの選択 10. Ⅳキックオフまでの準備 11. Ⅴ導入フェーズ（前半） 12. Ⅵ導入フェーズ（後半） 13. Ⅶプロジェクトマネジメント 14. Ⅷプロジェクト完了 15. おわりに 133
- 12. Ⅷ－１ 悪いところ、マイナスばかり原因追及している 発生する問題 今回のプロジェクトは予定のスケジュールを大きく遅延した。その原因を突き止め、誰に責任があるのか をはっきりさせようと会議が開かれた・・・。新業務プロセスへ要件定義部分での遅れは、経理部門から 参加していたメンバーの要件定義能力が低かったとしたが、メンバーからはプロジェクトマネージャの理 解が全然なく、関連部門への調整もメンバーにまかせっきりだったと反論した。プロジェクトマネージャ と経理部長の関係が良くないことも話にでてきており、話がどろどろな方向に進んでいった。 発生頻度 3 影響度 1 危険度 3 チェック項目 プロジェクト評価の姿勢、中身 チェック視点 ①「事」でなく、「犯人探し」のやり方になっていないか？ ②犯人を特定し、反省を促すような叱責を行っていないか？ ③事を指摘し、改善するための具体的策についての本質を話し合っているか？ チェック手法 プロジェクト終了後の反省会にて、その議論内容を観察 チェック時期 プロジェクト終了後の反省会にて ＯＫ・ＮＧの例 - 134
- 13. Ⅷ－２ 財務的な面でのみ、効果を測ろうとする 発生する問題 今回の給与計算パッケージの導入でどれくらいのコスト削減になるのか社長に報告することとなった。 「生産性アップによって人件費削減になっていることにしないと、費用対効果が無いといわれて怒られる ぞ。実際はどうなんだ？」「まだ現場になじんでなくて生産性なんてアップしてませんよ・・・」 発生頻度 3 影響度 1 危険度 3 チェック項目 プロジェクトの定性的評価 チェック視点 ①売上利益アップ、原価削減だけの指標で、良い悪いを論じていないか？ ②プロジェクト検討書での効果内容と違いの無い視点で評価されているか？ ③バランススコアカード、その他のフレームワーク等を用いて多面的に評価しているか？ チェック手法 プロジェクト終了後の効果検討会にて、その議論内容を観察 チェック時期 ・プロジェクト終了後の効果検討会にて ・プロジェクト終了後の投資効果検証シート作成途中、作成後 ＯＫ・ＮＧの例 - 135
- 14. Ⅷ－３ 要件通りに一応はできたが実際の効果はわからない 発生する問題 トラブルがたくさん発生したが、なんとか新パッケージの導入が終わった。ユーザ教育も終わりやっと新 業務の定着を進めているところだ。後は現場が使い方に慣れてくれれば、長くて辛かったプロジェクトが 終わって解放されると、プロジェクトマネージャは思っている。同時に定着が進めば予定通りの効果もで るだろうと期待している・・・。しばらくして現場からやりかたは変わったが、全体的に何が変わったの かはわからないという声が聞こえてきた。その声は「意味がない」に変化しつつ、社長にも伝わってしま い、説明を求められた。 発生頻度 2 影響度 2 危険度 4 チェック項目 プロジェクトの投資効果の検証 チェック視点 ①プロジェクト実施前後で、同じ観点での評価を行っているか？ ②プロジェクトの目的に照らして正しい評価ができているか？ ③効果を検証するための手順、指標（KPI）が明らかになっているか？ チェック手法 ・プロジェクト終了後の効果検討会にて、その議論内容を観察 ・新パッケージでの業務開始後しばらくした後の効果検討会にてその議論内容を観察 チェック時期 ・プロジェクトの初期段階での効果検証手順検討段階 ・新パッケージでの業務開始後 ＯＫ・ＮＧの例 - 136
- 15. Ⅷ－４ 心身ともに疲れたが、会社はどう見てくれているのかわからない 発生する問題 プロジェクトにアサインされた若手メンバーたちは、自分らは本当に頑張ったと思っている。「残業や休 日出勤もしたし、徹夜だってした。プロジェクトマネージャは現場の事をわかっていないし、ただやれや れ言うだけだった。これらの頑張りを認めてもらって給料あげてもらわないとわりにあわない。」と思っ ていた後、プロジェクトマネージャは課長から部長に出世した。若手メンバー数人は特段評価されること もなく、社長に直訴があった。 発生頻度 3 影響度 2 危険度 6 チェック項目 プロジェクトにかかわったメンバーの評価 チェック視点 ①プロジェクトへの貢献がどう評価に反映されるか、透明性があるか？ ②プロジェクトの成功を会社が適切に評価しているか？ ③評価の方法は会社の全体バランスを配慮しているか？ チェック手法 ・プロジェクト責任者へのプロジェクト評価についてのヒアリング ・ラインマネージャ（プロジェクトメンバーの上司）へ、プロジェクトメンバーの業績についてのヒアリ ング チェック時期 ・プロジェクト開始前 ・プロジェクト終了後 ＯＫ・ＮＧの例 - 137
- 16. Ⅷ－５ 予実管理のドキュメントが整理されていない 発生する問題 （次のパッケージ導入プロジェクトにて）現状分析に必要な工数を算出するのに、前回のプロジェクトを 参考にすることにした。前回のプロジェクトでは社内の工数が大幅に上回っていたのだが、前プロジェク トマネージャの記憶頼りにすることにした・・・。このプロジェクトでも予定と実績の乖離が大きく発生 してしまった。 発生頻度 3 影響度 1 危険度 3 チェック項目 プロジェクトの実績データ保存（ナレッジ化） チェック視点 ①差異の分析が適切に行われているか？ ②次プロジェクトへのインプット事項がドキュメントになっているか？ ③実績データがナレッジとして社内関係者に認識されているか？ チェック手法 ・実績管理の資料を確認 ・予実分析の結果を考察したドキュメントを確認 ・分析結果の利用方法についてプロジェクトの責任者にヒアリング チェック時期 ・予実の分析が完了した後 ・実績データのドキュメント整理後 ・プロジェクト終了後 ＯＫ・ＮＧの例 - 138
- 17. 1. ＩＴプロジェクトは失敗するものだ 2. パッケージ商品の現状 3. ＩＴプロジェクトの失敗とは 4. なぜ失敗するのか 5. 失敗しないために何をすべきか 6. チェックの対象と視点 7. Ⅰ初期検討とプロジェクト立ち上げ準備 8. Ⅱ現状分析と要求仕様・RFP作成 9. Ⅲパッケージソフトとベンダーの選択 10. Ⅳキックオフまでの準備 11. Ⅴ導入フェーズ（前半） 12. Ⅵ導入フェーズ（後半） 13. Ⅶプロジェクトマネジメント 14. Ⅷプロジェクト完了 15. おわりに 139
- 18. チェックリストを見ていただいてお気づきになったかもしれま せん。人間的なところに力点を置いたチェックリストになって います。 プロジェクトマネジメントの知識をどんなに頑張って吸収して も、失敗するときは失敗します。 やると言ってもやらないのが人間、やりたくてもやれないのが 人間、守れと言っても守らないのが人間です。 要は綺麗事をどんなに口に出しても、泥臭い部分や腹黒い 部分、誰もが嫌だと思う部分が消えるわけではありません。 パッケージ導入プロジェクトを成功させるためには、綺麗事だ けではどうにもならない問題を、発生させない、もしくは発生 直後に修正しなければなりません。 140