失敗しないパッケージ導入６
•
0 likes•589 views
システム導入成功率は依然３割。 失敗するなら、やらないほうがマシ・・・、とならずに 確実にシステム導入を成功させるためのポイントを解説します。 中小企業診断士 システム監査技術者 小島規彰 http://www.asahi-bs.com/
Recommended
More Related Content
Similar to 失敗しないパッケージ導入６
Similar to 失敗しないパッケージ導入６ (20)
More from 小島 規彰
Recently uploaded
Recently uploaded (9)
失敗しないパッケージ導入６
- 1. 1. ＩＴプロジェクトは失敗するものだ 2. パッケージ商品の現状 3. ＩＴプロジェクトの失敗とは 4. なぜ失敗するのか 5. 失敗しないために何をすべきか 6. チェックの対象と視点 7. Ⅰ初期検討とプロジェクト立ち上げ準備 8. Ⅱ現状分析と要求仕様・RFP作成 9. Ⅲパッケージソフトとベンダーの選択 10. Ⅳキックオフまでの準備 11. Ⅴ導入フェーズ（前半） 12. Ⅵ導入フェーズ（後半） 13. Ⅶプロジェクトマネジメント 14. Ⅷプロジェクト完了 15. おわりに 95
- 2. Ⅳ－１ 支払い、著作権などは問題は二の次だと思っている 発生する問題 プロジェクトマネージャは自社の新しい生産管理工程の要件定義につきっきりになっていて、契 約書のチェックを事務局に任せていた。要件定義では元になるドキュメントは自社で用意して、 清書・成果物としての作業をベンダーが行うことになっていた。しばらくして、ベンダーが別の ところで生産管理工程の分析サービスを始めていたことがわかり、ドキュメントを入手してみる と、自社の要件定義で行った内容にそっくりの内容だった。このことをベンダー側に問い合わせ ると、著作権が我々にあるので問題ないと回答された。 発生頻度 2 影響度 1 危険度 2 チェック項目 プロジェクトの法的制約事項の理解 チェック視点 ①プロジェクトマネージャ候補者とプロジェクト責任者は、関係法律の内容を理解しているか？ ②関連する法律の洗い出しが行われているか？ ③関連法律への対応が適切に行われているか？ チェック手法 ・プロジェクト計画書の法律に関する認識リスクおよびリスク管理方法の内容を確認 ・プロジェクトマネージャ及び、責任者へのリスクについての認識をヒアリング チェック時期 ・プロジェクト計画書作成中 ・プロジェクト計画作成後 ＯＫ・ＮＧの例 - 96
- 3. Ⅳ－２ あとはＰＭに任せておけば大丈夫だと思われている 発生する問題 事前検討段階での働きを見て、プロジェクトマネージャ候補のＫ君にまかせておけば、事はうまく運ぶだ ろうと経営層は思っていた。プロジェクト開始後、キックオフ直後から小さな問題が発生しだしていた。 しかしながら、Ｋ君はまかせてもらっているとの責任感から、問題の対応を自分でしなければならないと ばかり、紛糾していたようだ。その後法的問題が発生し、どうしても自分では対応できそうにないと、 やっと経営層に報告があたっときは、すでに大きな問題となっており、会社対会社レベルの慎重な対応を せざるをえない状況になってしまった。 発生頻度 3 影響度 2 危険度 6 チェック項目 会社としてのプロジェクト支援体制 チェック視点 ①プロジェクトマネージャまかせのプロジェクトになっていないか？上層部の関心、フォローは十分か？ ②プロジェクトの問題解決のエスカレーション方法は明確になっているか？ チェック手法 ・プロジェクト計画書の問題管理方法の内容を確認 ・プロジェクトマネージャ及び、責任者への問題解決方法についての認識をヒアリング ・上層部へ、プロジェクトの問題への関与方法をヒアリング チェック時期 ・プロジェクト計画書作成中 ・プロジェクト計画作成後 ＯＫ・ＮＧの例 - 97
- 4. Ⅳ－３ リスク計画に関心が薄く、「無謀な」前向き意識 発生する問題 システムの設置場所を自社内とすることとなった。メンバー候補の人間から、それは難しい、やめておい たほうがいいという声があがったが、責任者からは「悲観的だね。そんなことばっかりいってたって始ま らないだろう。新しいことをやるのに、問題があるのは当たり前だ。前向きな姿勢で積極的になってもら わないと困るよ。」と指摘があった。導入後、システム障害やトラブルの度に有償でベンダーに頼る事と なり、ランニングコストが予想外にかかることになってしまった。 発生頻度 1 影響度 2 危険度 2 チェック項目 プロジェクトリスク管理の計画 チェック視点 ①リスクの洗い出し方法は適切か？（漏れなく洗いだせる方法か） ②誰がその内容をチェック、承認しているか？ ③リスクの認識・考え方が適切か？（影響度、頻度等の識別ができているか） ④リスクそれぞれの対応方法が実行可能な内容で検討されているか？ チェック手法 ・プロジェクト計画書の認識リスクおよびリスク管理方法の内容を確認 ・プロジェクトマネージャ及び、責任者へのリスクについての認識をヒアリング ・責任者周辺（取締役クラス）へのリスクの考え方をヒアリング チェック時期 ・プロジェクト計画書作成中 ・プロジェクト計画作成後 ＯＫ・ＮＧの例 - 98
- 5. Ⅳ－４ パッケージ導入だから品質管理の必要性はないだろう 発生する問題 品質も何も、こちら（ユーザ）側がOKしなければ意味がないんだから、そんな管理は必要ないとプロジェ クトマネージャ候補のAさんは考えていた。開発が始まり、細かい部分をチェックしていたが、次第にプ ロジェクトマネージャのAさんがOKだといえばOKというレビュー、チェック体制になってしまった。業務 的に詳しくない部分、技術的にわからない部分についても、チェックするのはプロジェクトマネージャと いう雰囲気になってしまった。プロジェクト中盤になって、技術的に整合性がなくなってきたことがわか り、詳細設計のやり直しとともに、ドキュメントも一から作成し直すことになったが、ベンダーからは追 加コストを要求されることとなった。 発生頻度 2 影響度 2 危険度 4 チェック項目 プロジェクト品質管理の計画 チェック視点 ①何が品質、何をもってOKというかの明確の定義があるか？ ②プロジェクトの品質測定方法は適切（簡易測定可能かつ有効）か？ ③品質基準を下回った時のリカバリ方法は実行可能な内容で検討されているか？ チェック手法 ・プロジェクト計画書の品質管理方法の内容を確認 ・品質管理用のドキュメント・手法を確認、ヒアリング チェック時期 ・プロジェクト計画書作成中 ・プロジェクト計画作成後 ＯＫ・ＮＧの例 - 99
- 6. Ⅳ－５ 要求は確定したから、変更管理はいらない 発生する問題 今回のベンダーとは長い付き合いだし、事前検討でも十分に新しい業務プロセスを理解しているはずだっ た。それもあり、微妙な調整事項が発生したらベンダーと都度話し合って解決していけば問題ないと考え ていた。その後、都度ベンダーの意見を伺いながら調整を進めていったが、詳細設計が終わった段階で、 生産業務の責任者が「これは当初の内容と“なんか”違うな、これじゃ目的を達成できない」との意見が あった。要件定義内容の一部を修正することになったが、思いの他影響範囲が広く、大きくスケジュール 遅延することとなった。 発生頻度 2 影響度 3 危険度 6 チェック項目 プロジェクト変更管理の計画 チェック視点 ①変更管理のルール（起票、検討、承認）がユーザ、ベンダ側と双方合意のとれた内容になっているか？ ②変更の影響が評価されており、しかるべき関係者間で合意されているか？ ③変更発生時の費用（増加）変更を処理できるかどうかの、確認がとれているか？ チェック手法 ・プロジェクト計画書の変更管理方法の内容を確認 ・変更管理用のドキュメント・手法を確認、ヒアリング チェック時期 ・プロジェクト計画書作成中 ・プロジェクト計画作成後 ＯＫ・ＮＧの例 - 100
- 7. Ⅳ－６ 要員計画通りにメンバーがプロジェクトに参画できるのかわからない 発生する問題 「（経理部長）社長から言われて、とりあえずメンバーアサインしたけどさ。うちが忙しい時は誰が手 伝ってくれんのさ？うちだって月次締めとか決算とかいろいろあるから、必ずプロジェクト優先ってわけ にはいかないよ。」 要員を取られることにあまり納得のいかない様子の主管部門以外の責任者。プロ ジェクトの所々で、当初アサインメンバーの代理ということで、新人のメンバーが会議等に参画した。時 には代理無しということもあり、その部分の調整、確認が大幅に遅れ、次第に全体のスケジュールに影響 が出だした。さらに他の部門のメンバーも代理出席等が多くなり、情報共有と意思疎通がやりづらくなっ てしまった。 発生頻度 2 影響度 3 危険度 6 チェック項目 プロジェクト要員管理の計画 チェック視点 ①プロジェクトメンバーのアサインは部門責任者の合意を得ているか？ ②プロジェクト期間中の他の業務の兼ね合いを考慮しているか？ ③業務以外の離脱要素（病気、結婚、妊娠、転職等）の可能性は考慮しているか？ チェック手法 ・プロジェクト計画書の要員計画の内容を確認し、他業務との中期スケジュールとの突き合わせ ・プロジェクトメンバーへのインフォーマルコミュニケーションによるヒアリング チェック時期 ・プロジェクト計画書作成中 ・プロジェクト計画作成後 ＯＫ・ＮＧの例 - 101
- 8. Ⅳ－７ ゴールにあわせたスケジュールが引かれている 発生する問題 はじめてのことなので、本当のところ、どれ位でできるかわからない。しかしそれぞれのタスクをその時間ででき るレベルでやるしかないと、プロジェクトのメンバーは前向きに考えた。慣れていないせいか要件定義やドキュメ ント作成にかける時間がやはり足りないように感じていたが、スケジュール順守で対応していた。その後、設計段 階になって、要件定義の漏れや不整合、ドキュメントがあいまいな部分や足りない所もあることがわかり、後半に なって、場当たり的、手探り状態で進める状況になってしまったため、プロジェクト全体が何をしているのかわか らないくらいの混乱に陥ってしまった。 発生頻度 3 影響度 2 危険度 6 チェック項目 全体スケジュールおよび進捗管理の計画 チェック視点 ①WBSは適切に作成されており、スケジュールは現実的な内容になっていることを関係者が納得しているのか？ ②スケジュール遵守に（政治面での）強いプレッシャーがかかっていないか？ ③進捗基準を下回った時のリカバリ方法は実行可能な内容で検討されているか？ チェック手法 ・プロジェクトマネージャ及び、責任者へのスケジュールについての認識をヒアリング ・プロジェクトメンバーへの作業タスクヒアリング ・ベンダーへのタスク実現性ヒアリング ・プロジェクト計画書記載のスケジュールと、プロジェクト初期検討資料記載スケジュールとの突き合わせ チェック時期 ・プロジェクト計画書作成中 ・プロジェクト計画作成後 ＯＫ・ＮＧの例 - 102
- 9. Ⅳ－８ プロジェクト計画書をキックオフで初めて見るメンバーがいる 発生する問題 アサイン予定のメンバーにはキックオフの2日前にメールが来て、資料読んでおいて下さいと添付 資料が貼り付けてあったが、忙しくて読む暇がなかった。当日キックオフに参加したメンバーの 多くは、自分の担当する仕事に困惑し、「こんなの聞いてませんが誰が決めたんですか？誰が了 解してるんですか？」の声が上がった。これらの質問を押さえつけるように場をまとめたつもり のプロジェクトマネージャだったが、その後プロジェクト開始直後からメンバーとの間に、摩擦 が生じてしまった。 発生頻度 2 影響度 2 危険度 4 チェック項目 関係者のプロジェクト計画の事前理解 チェック視点 ①プロジェクト計画書の作成はキックオフまで余裕を持って作成されているか？ ②キックオフ事前に関係者間での十分なコミュニケーションが行われているか？ チェック手法 ・プロジェクト計画書の作成時期を確認 ・キックオフ前の事前確認会、会議の内容を観察 チェック時期 ・プロジェクト計画書作成中 ・プロジェクト計画作成後 ・キックオフ前の事前確認会にて ＯＫ・ＮＧの例 - 103
- 10. Ⅳ－９ 役割分担が不明確な部分がある 発生する問題 不明確な部分だけでなく、それぞれの担当の仕事の他部門との関連部分も「それはわたしじゃありませ ん」と言われるようになった。誰も手をつけないので、スケジュールは遅れがちになり、責任感の強いプ ロジェクトマネージャは結局、その部分の実作業を担当する事になってしまった。さらに、その後「そこ は私の担当じゃありません」という発言が目立つようになり、要件定義やテストケースの作成についての 漏れや抜けが、素人目に見てもわかるような状態になってしまった。 発生頻度 3 影響度 2 危険度 6 チェック項目 プロジェクトメンバーの役割分担 チェック視点 ①アサインされたメンバーは役割を遂行するために必要な能力と権限を有しているか？ ②ポテンヒットはないか？ ③（過去に曖昧であったところを）新たに定義した役割について、当人または関係部門の理解はあるか？ チェック手法 ・プロジェクト計画書の役割分担表の内容を確認 ・WBSの成果物と担当者部分の確認 ・プロジェクトメンバーへ役割の遂行可否ヒアリング チェック時期 ・プロジェクト計画書作成中 ・プロジェクト計画作成後 ＯＫ・ＮＧの例 - 104
- 11. Ⅳ－１０ アサインメンバーが他人事のように感じている 発生する問題 「（アサインメンバー）上から協力してやってくれと言われてるので、まあ顔は出すけどさ。こっちだっ て仕事あるから出来る範囲でしか無理だよ。計画書にどんなに細かく書いたって、無理なものは無理。」 アサインメンバーはそもそも、プロジェクトに参画しているという意識が低かった為、プロジェクトが始 まっても、会議に来ない、依頼しているドキュメントは期限までに出来ないなどが相次いだ、それを確 認・指摘しても、「忙しいから無理」の一点張りだった。そのメンバーに期待していた要件定義部分が大 幅に遅れたせいで、他メンバーやベンダーの待ちが発生した。 発生頻度 2 影響度 2 危険度 4 チェック項目 プロジェクトメンバーの参画意識 チェック視点 ①プロジェクトメンバーに十分な意識付けがなされているか？ ②プロジェクトメンバーの上長の理解・支援意識は十分か？ チェック手法 ・プロジェクトマネージャ及びプロジェクト責任者へのプロジェクトメンバーへの説明についてヒアリン グ ・プロジェクトメンバーの上司（ライン責任者）への意識づけ内容ヒアリング ・プロジェクトメンバーへのインフォーマルコミュニケーションによるヒアリング チェック時期 ・キックオフ前の事前確認会にて ・キックオフの終了後 ＯＫ・ＮＧの例 - 105
- 12. 1. ＩＴプロジェクトは失敗するものだ 2. パッケージ商品の現状 3. ＩＴプロジェクトの失敗とは 4. なぜ失敗するのか 5. 失敗しないために何をすべきか 6. チェックの対象と視点 7. Ⅰ初期検討とプロジェクト立ち上げ準備 8. Ⅱ現状分析と要求仕様・RFP作成 9. Ⅲパッケージソフトとベンダーの選択 10. Ⅳキックオフまでの準備 11. Ⅴ導入フェーズ（前半） 12. Ⅵ導入フェーズ（後半） 13. Ⅶプロジェクトマネジメント 14. Ⅷプロジェクト完了 15. おわりに 106
- 13. Ⅴ－１ ただ書いてあればいいだけの議事録になっている 発生する問題 口語のコミュニケーションでは、完全かつ明確な疎通というのは難しい。言ったつもりがこちらの意図ど おりに伝わって無いこともある。またベンダーに議事録を書かせるケースも多く見受けられるが、ベン ダーの理解で文書にするため、後になって、ユーザ側の「なんだこれ？」に対し、ベンダーの「先週の議 事録に書いてあるじゃないですか」のような理解のずれが発生する。 発生頻度 2 影響度 2 危険度 4 チェック項目 議事録の作成方法 チェック視点 ①議事録の作成ルールがあるか？ ②議事録の記載内容は適切か？ ③議事録内容を関係者が確認、理解、合意しているか？ ④議事録に記載されている課題、変更等が確実に対応されているか？ チェック手法 ・プロジェクト計画書のコミュニケーションルールの内容を確認 ・会議の内容と議事録の記載内容を付き合わせ ・議事録の記載内容の対応状況をプロジェクトマネージャにヒアリング ・議事録記載の課題、問題と、各種管理資料の内容を突き合わせ チェック時期 ・プロジェクト計画書作成中 ・プロジェクト計画作成後 ・議事録作成後、作成後しばらく経過した時 ＯＫ・ＮＧの例 - 107
- 14. Ⅴ－２ 要求仕様の意図が要件定義に反映されていない 発生する問題 要求仕様をまとめた初期メンバーと実際のプロジェクトメンバーとの十分なコミュニケーションが図れな いまま、要求定義を進めた。事前検討に携わっていないメンバーは、経営レベルでの想いの程度を知る由 もなく、いつのまにかベンダーの「こうしたほうが良いですよ」につられて要件を固めてしまった。シス テムが形になってきた段階で初期メンバーが確認したところ、要求仕様の意図と違う事を指摘され、完成 後の効果に不安がよぎりだした。 発生頻度 2 影響度 3 危険度 6 チェック項目 要件定義工程の進め方 チェック視点 ①要求仕様と矛盾する要件定義をしていないか？ ②要求仕様に携わった要員が要件定義にどうかかわっているか？ ③一意的な内容、判りやすい内容になっているか？ ④細部の変更を後工程になってどういう対応するのかがベンダーとの間で明確になっているか？ チェック手法 ・プロジェクトマネージャへ、要件定義書の作成過程をヒアリング ・要件定義に係る会議体での会話内容を観察 ・要件定義書を確認 チェック時期 ・要件定義を実施するための段取り（資料等準備）中 ・要件定義に係る会議体にて ＯＫ・ＮＧの例 - 108
- 15. Ⅴ－３ 思っていたより高い（安い）最終見積もり、長い（短い）スケジュールになっ てしまった 発生する問題 RFP選定段階の概算では３千万円だったのにもかかわらず、要件定義の後に正式見積もりをしてみ たら５千万円と膨れ上がっている。しかも納期は予定より３か月も遅い。こんなのじゃＡ社にな んて頼めない。RFPの選定からやり直しだ。このやり直しコストをどうしてくれるんだ！？ 発生頻度 3 影響度 3 危険度 9 チェック項目 詳細見積もり前提条件、制約条件の理解度 チェック視点 ①カスタマイズ、アドオン項目についての内容、仕様が明確か？ ②特に非定形な部分の作業に関する工数見積もりは妥当な価格になっているか？ ③○○するためには△△△が必要、前提とする部分の見積もりが適切に反映されているか？ ④見積もり内容に半に重複、余剰な予備、漏れ抜けがないか？ チェック手法 ・要件定義前の見積もり資料の前提条件と最終見積もりで変更になっている部分内容を突き合わせ ・プロジェクトマネージャおよびプロジェクト責任者へ、最終見積もりの内容をヒアリング ・ベンダーへの最終提出見積もりについての考え方を確認 ・最終見積もりの確認についての会議体での会話内容を観察 チェック時期 ・要件定義前の（概算）見積もり完成時 ・最終見積もり（発注前）内容確認ついての会議体にて ＯＫ・ＮＧの例 - 109
- 16. Ⅴ－４ 作成するドキュメントがベンダー任せになっている 発生する問題 工程に余裕が出てきて、成果物であるドキュメントに目を通してみたところ、技術の専門家が見 ればわかるが、ユーザ側がみてもなんのことやらさっぱりわからない。書き直してくれといった ら追加コストですと言われた。さらにカスタマイズやアドオンのソースは中身を覗けときたもん だ。後から確認しても、誰も理解できないシステムになるんじゃないかな・・・。 発生頻度 2 影響度 2 危険度 4 チェック項目 成果物ドキュメントの作成ルール チェック視点 ①WBSに従って必要なドキュメントが明確に定義されているか？ ②ドキュメントのサンプルは事前に確認されているか？ ③WBS上に記載の成果物（ドキュメント）が次のタスクの品質に影響することを十分に理解しているか？ ④誰がチェックして誰が承認するかが明確になっているか？ チェック手法 ・WBSの成果物の項目を確認 ・プロジェクト計画書記載の成果物についての考え方を確認 ・成果物確認に係る会議体での会話内容を観察、関連ドキュメントを確認 チェック時期 ・プロジェクト計画書作成中 ・WBS作成後 ・重要なドキュメントがいくつか出来上がってきた後 ＯＫ・ＮＧの例 - 110
- 17. Ⅴ－５ 時間内にうまくまとめようとするあまり、一部の意見を殺している 発生する問題 わかったわかった、Ｊさんの言いたいことはわかりましたが、ここで手戻りすると全体的なスケ ジュール遅延を起こします。別途そこは検討していただくとして、ここはこのままで進めましょ う。・・・の１ヶ月後、Ｊさんの指摘していたところが原因で、タスク間の整合性が合わなく なってしまった。結局１カ月前の状態に後戻りすることになった。 発生頻度 2 影響度 1 危険度 2 チェック項目 会議等での意見のまとめ方 チェック視点 ①否定的および少数意見を殺していないか？ ②意見と意見の間をとったような決定の仕方をしていないか？ ③思いついた事を然るべき方法、タイミングで発言できる雰囲気があるか？ チェック手法 ・プロジェクト会議体での主な選択肢についての決定にかかわる会話内容を観察 ・意見が却下されるときの会話のプロセスを観察 ・重要決定事項についての会議の議事録の確認 チェック時期 プロジェクト実施中に行われる会議体にて、適時 ＯＫ・ＮＧの例 - 111
- 18. Ⅴ－６ 日々の確認で済ませているから、レビューはあえていらない 発生する問題 日々の会議の中で確認して進めていた。レビューのためのドキュメント作りや日程調整が負荷になり、納期遅延の 原因になりそうだったので、レビューを省くことにした。スケジュール的に余裕もでてきたので、何気なく画面を 確認していると、入力の重複や入力順番の非効率、ユーザビリティの無いレイアウト等があることに気づいた。 日々の確認の中でOKだったはずなのでこれを良しとしておくか、手戻りするか・・・、責任者への説明で何と言お う・・・ 発生頻度 1 影響度 2 危険度 2 チェック項目 プロジェクトのレビュー機能 チェック視点 ①何を持ってOKかの基準が、合理的であるか？ ②レビューのタイミングをあらかじめスケジュールに組み込んでいるか？ ③レビューのための段取りができているか？（特定成果物、管理帳票、他必要資料等） ④しかるべき人がレビューに携わっているか？ チェック手法 ・プロジェクトのスケジュール表、レビュー計画表を確認 ・プロジェクトマネージャへレビューについての見解をヒアリング ・プロジェクトのレビュー会議を観察 チェック時期 ・スケジュール表作成中 ・レビュー計画書作成中 ・レビューについての会議体にて ＯＫ・ＮＧの例 - 112
- 19. Ⅴ－７ 優秀な担当者、ベテランの意見を尊重しすぎている 発生する問題 プロジェクトマネージャがこうしようと決定をしかけたところでも、「それは違う、わかってないな」とベテラン Ｅさんの手厳しい一言。それが何回も続きプロジェクトマネージャの発言はおざなりになり、みんなが、Ｅさんは なんて言ってるんですか？ＥさんがＯＫならそれでいきましょう」とＥさんの意見に従って意思決定するように なってしまった。・・・コスト、納期遅延が発生し、問題が大きくなってきたときだけ、プロジェクトマネージャ なんとかしてよ！と言われるようになった。 発生頻度 2 影響度 3 危険度 6 チェック項目 エース、ベテランの影響力 チェック視点 ①メンバーにエース級やベテランが存在するか？ ②プロジェクトのエース、ベテランの発言によってのみ方向性が決められていないか？ ③プロジェクトマネージャと彼らの関係は適切か？ ④プロジェクトマネージャが一番詳しくなければならないと思われていないか？ ⑤メンバーやエースをしかるべきポジションに据えているか？ チェック手法 ・プロジェクト会議体での主な選択肢についての決定にかかわる会話内容を観察 ・プロジェクトメンバーの業務経歴を確認 ・重要決定事項についての会議の議事録の確認 チェック時期 ・プロジェクト体制構築時 ・プロジェクト実施中に行われる会議体にて、適時 ＯＫ・ＮＧの例 - 113
- 20. Ⅴ－８ みんな真面目で黙々と緊張した雰囲気の中でしっかりやっている 発生する問題 まじめにしっかり集中してやってほしいと続けた言い続けた結果、職場の雰囲気はちょっ と緊張感の漂う静かな感じになった。メンバーは確認したいことがあれば、次の定例で確 認すればいいや、話すと長くなるからメールにしておくか・・・とコミュニケーションが 少なくなった。結果会議で些細な事を話しあうようになり、さらに決まるものもなかなか 決まらないようになり、スケジュール遅延も起き始めた。 発生頻度 1 影響度 2 危険度 2 チェック項目 職場の雰囲気、メンバー感の空気 チェック視点 ①多少の雑談や冗談等のコミュニケーションがあるか？ ②チームの雰囲気は悪くないか？挨拶がきちんとかわされているか？ チェック手法 ・プロジェクトでの全体の様子を観察 ・プロジェクトの電子メールの文面を確認 チェック時期 プロジェクト実施中随時 ＯＫ・ＮＧの例 - 114
- 21. 1. ＩＴプロジェクトは失敗するものだ 2. パッケージ商品の現状 3. ＩＴプロジェクトの失敗とは 4. なぜ失敗するのか 5. 失敗しないために何をすべきか 6. チェックの対象と視点 7. Ⅰ初期検討とプロジェクト立ち上げ準備 8. Ⅱ現状分析と要求仕様・RFP作成 9. Ⅲパッケージソフトとベンダーの選択 10. Ⅳキックオフまでの準備 11. Ⅴ導入フェーズ（前半） 12. Ⅵ導入フェーズ（後半） 13. Ⅶプロジェクトマネジメント 14. Ⅷプロジェクト完了 15. おわりに 115
- 22. Ⅵ－１ え、それ聞いてないなというセリフを良く耳にする 発生する問題 プロジェクトマネージャは詳細設計レベルの技術仕様はわからないので、メンバーやベンダーに任せてい た。メンバー間、ベンダーとの間で個別にやりとりが続き、結合や連結の部分で、「それ聞いてない、 えっ、いつ変わったの？」といった発言が聞かれるようになった。現場では、手直しや調整が増えている ようで、同時にスケジュールの遅延の傾向が見えてきた。これくらいは大丈夫だろうと思っていた矢先に、 大きな手戻りが発生しようだと現場から報告が上がった。 発生頻度 2 影響度 2 危険度 4 チェック項目 情報伝達・共有、プロジェクトメンバーのコミュニケーションの仕方 チェック視点 ①重要な事項のやりとりが口頭でのみ行われていないか？ ②何が重要事項化の判断をメンバーができているか？ ③重要事項のやりとりが、関係者に周知されるコミュニケーションのルールになっているか？ ④その内容がしかるべきドキュメントになっているか？ チェック手法 ・プロジェクト計画書のコミュニケーションルールの内容を確認 ・タスクメンバーとベンダー、メンバー同士の会話等、非公式と思われる場での会話内容をヒアリング チェック時期 ・プロジェクト計画書作成中 ・プロジェクト計画作成後 ・プロジェクト中の様々な場でのコミュニケーション発生直後 ＯＫ・ＮＧの例 - 116
- 23. Ⅵ－２ プロジェクトマネージャは技術にも詳しくないといけないと思っている 発生する問題 詳細仕様やプログラムの書き方まで、すべてのミーティングに顔を出しているプロジェクトマネージャ。 みんなに指示できるようにならないと舐められると思って、技術者の視点でメンバーと細部まで納得でき るまで時間をかけて対応していた。気付けば、変更管理や進捗管理帳票は古いもののままで、報告もまま ならず。経費の支払期日も過ぎてしまった。 発生頻度 1 影響度 2 危険度 2 チェック項目 プロジェクトマネージャとしての仕事の理解度 チェック視点 ①プロジェクトマネージャが必要以上に技術分野に踏み込んでいないか？ ②プロジェクトマネージャが自分の得意領域に偏った管理をしていないか？ チェック手法 ・プロジェクト会議体での発言内容をヒアリング ・プロジェクトマネージャの業務経歴を確認 チェック時期 ・プロジェクト実施中に行われる会議体にて、適時 ・プロジェクトマネージャのデスクワーク時に時々 ＯＫ・ＮＧの例 - 117
- 24. Ⅵ－３ やっても時間の無駄だと思われているミーティングがある 発生する問題 毎週の定例会議だからと言って、遠方の拠点からメンバーを無理言って集めている。プロジェクトマネー ジャは叱咤激励を飛ばしているが、メンバーはいまいちピンと来ていない。あくびや雑談をしている者も いる。「そんなことはわかっている、もっと具体的な話をしたいのに、気合いじゃ解決できんのよ」と陰 口が聞かれるようになり、ミーティング開催者に対するメンバーの心が離れていった。その後別の部分で の指示事項にも従わないメンバーが出てきた。 発生頻度 3 影響度 1 危険度 2 チェック項目 プロジェクトの会議体の運営方法 チェック視点 ①事前に目的、目標、テーマ等が決められ、しかるべきメンバーが参加できているのか？ ②決めるべき内容が決まっているか？（決まらない場合の対応方法は明確か） ③お役所的に、無理やり開催していないか？ チェック手法 ・プロジェクト計画書の会議対運営ルールを確認 ・プロジェクト会議体での全体の様子を観察 ・ミーティング参加メンバー、ベンダーへのインフォーマルな場でのヒアリング チェック時期 ・プロジェクト計画書作成後 ・プロジェクト実施中に行われる会議体にて、適時 ＯＫ・ＮＧの例 - 118
- 25. Ⅵ－４ 明確すぎる役割分担のせいで、メンバー同士がぎすぎすしている 発生する問題 優秀なAさんは定時に帰っているが、Bさんは毎日終電近くまで残業だ。二人の役割分担は明確に分かれて いるので、互いの関心は薄い。プロジェクトマネージャが「Aさん、Bさんを手伝ってあげてよ」と言うが、 「早いのは私が苦労して身に付けたスキルがあるからです、なんで遅い人のフォローをしないとならない んですか？」と反論を受けた。その後メンバー間の協力体制は無く、一部のメンバーが過労で倒れ、その タスクがまったく進まない状況になってしまった。 発生頻度 1 影響度 2 危険度 2 チェック項目 タスク遂行のチームワーク チェック視点 ①メンバー同士の作業負荷のばらつきがないか？ ②特定個人に依存した仕事がクリティカルパス上に存在していないか？ ③優秀な人間のもっともな意見に適切に、プロジェクトマネージャが適切に回答できているか？ チェック手法 ・PERT図/クリティカルパスとWBSを付き合わせ ・要員管理票の残業時間等を確認 ・優秀なメンバーとプロジェクトマネージャとの作業生産性についてのやりとりを観察 チェック時期 プロジェクト実施中随時 ＯＫ・ＮＧの例 - 119
- 26. Ⅵ－５ ラインマネージャがプロジェクトメンバーにあれこれを口をだす 発生する問題 プロジェクトメンバーの直属の上司が、「そんなドキュメントはいらないんじゃないの？ そんなに出張 行く必要あるの？来週まとめていけばいいんじゃないの？」など、プロジェクトの状況を把握せずに、自 部門の都合を優先した指示を出す。挙句のはて、「あいつ（プロジェクトマネージャ）は俺の同期だけど 昔から細かかったんだよな・・・。」と愚痴をこぼされ、メンバーの士気が下がってしまった。 発生頻度 2 影響度 2 危険度 4 チェック項目 プロジェクトメンバーの指揮命令系統 チェック視点 ①指示系統の輻輳によってプロジェクトメンバーのモチベーションダウンはあるか？ ②プロジェクト要員計画についての内容に変更があるのか？ ③プロジェクトマネージャおよびプロジェクト責任者とラインマネージャの関係は良好か？ チェック手法 ・プロジェクトメンバーへの指示系統についてのヒアリング ・プロジェクトマネージャおよび責任者へ、要員管理の実施状況についてヒアリング ・プロジェクト責任者が、プロジェクトメンバー所属部署の業務状況を把握しているかヒアリング チェック時期 プロジェクト実施中適時 ＯＫ・ＮＧの例 - 120
- 27. Ⅵ－６ 関係部門に「さあどうぞ、感想を聞かせて下さい」でテストを行っている 発生する問題 現場のメンバーから、「使い勝手が悪い、レスポンスが遅い」等を言われ、その声だけが一人歩きしてし まう。具体的な改善点が不明確なまま、社長からやり直し再検討を命じられてしまった。その後、プロ ジェクトの評価も悪いものとなってしまった。 発生頻度 2 影響度 3 危険度 6 チェック項目 ユーザ受け入れテストのやり方 チェック視点 ①検証項目と手順は明確なドキュメントになっているか？ ②何をどこまで確認すればいいかが検証者は理解できているか？ ③テスト結果のまとめ方（ドキュメンテーション方法）は予め明確になっているか？ チェック手法 ・プロジェクトマネージャーへ、受け入れテスト計画書の作成過程をヒアリング ・テスト手順書、まとめ用資料フォーマットを確認 ・受け入れテストの様子を観察 チェック時期 ・テスト計画書作成中 ・テスト手順書作成中 ・テスト実施中 ＯＫ・ＮＧの例 - 121
- 28. Ⅵ－７ プロジェクトの問題はプロジェクトマネージャが全部責任を負う 発生する問題 プロジェクトマネージャの上司から、「お前が責任者なんだからそれくらい解決しろ」。といった突き放 しの発言がある。さらに「なんでそんな大きくなるまで放っておいたんだ？そもそもそこが原因だろ。そ れができないようならはじめからプロジェクトマネージャなんて引き受けるな。もうスケジュール遅延も 予算オーバーも許されないぞ。」などの、問題解決にならない言動、叱責が続き、プロジェクトマネー ジャは誰にも相談できず、問題だけが大きななり、表面化したときには、取り返しがつかないほどになっ ていた。 発生頻度 2 影響度 3 危険度 6 チェック項目 上層部のプロジェクトへの関心および支援状況 チェック視点 ①プロジェクトマネージャが問題を抱え込んでいないか？ ②問題リストの滞留が起こっていないか？ ③プロジェクト責任者、上層部（取締役クラス）の理解している情報はタイムリーか？ チェック手法 ・プロジェクトマネージャーへの問題管理、リスク対応状況のヒアリング ・上記結果とプロジェクト責任者へのプロジェクト把握状況についてのヒアリング結果との突き合わせ チェック時期 プロジェクト実施中、適時 ＯＫ・ＮＧの例 - 122