I suc発表用v2.8

プロジェクトマネジメントの　　チーム果的実践Ｓ１プロジェクトマネジメントの　　チーム果的実践Ｓ１
効果的効果的
プロジェクトマネジメントのプロジェクトマネジメントの
「実践」「実践」
IBM ユーザ会 IT 研究会
関東研 H15 年度 S1 チーム
２００４年１０月２１日

関東研関東研 H15H15 　年度　年度 S1S1 チームチーム
紹介紹介山岸　浩一郎（リーダー）山岸　浩一郎（リーダー）
塩澤　健郎（サブリー塩澤　健郎（サブリー
ダー）ダー）
川合　岳児（フォーラム担川合　岳児（フォーラム担
当）当）
古川　賢太郎（発表者）古川　賢太郎（発表者）
横山　修横山　修
青柳　浩市青柳　浩市
糸永　覚糸永　覚
町町　　明義明義
吉田　岳彦吉田　岳彦
武田　考之武田　考之
浜田　智浜田　智
尾谷　昌彦尾谷　昌彦
堀之内　歌子堀之内　歌子
小林　竜太郎小林　竜太郎
高橋　由幸高橋　由幸
鬼澤　喜一鬼澤　喜一
以上１６名以上１６名
加藤　孝雄（担当委員）加藤　孝雄（担当委員）
林　勇太（アドバイザ）林　勇太（アドバイザ）

アジェンダアジェンダ
1.1. のプロジェクトマネジメントにするＩＴ部門対問題意識のプロジェクトマネジメントにするＩＴ部門対問題意識
2.2. からぶプロジェクトマネジメント失敗学からぶプロジェクトマネジメント失敗学
3.3. からぶプロジェクトマネジメント成功学からぶプロジェクトマネジメント成功学
4.4. に最後・・・に最後・・・

1.1. のプロジェクトマネジメントにするＩＴ部門対問題意識のプロジェクトマネジメントにするＩＴ部門対問題意識
2.2. 失敗から学ぶプロジェクトマネジメント失敗から学ぶプロジェクトマネジメント
3.3. 成功から学ぶプロジェクトマネジメント成功から学ぶプロジェクトマネジメント
4.4. 最後に・・・最後に・・・

システムの情報意義システムの情報意義
情報システムが
“難しい特別な”
ものから、ビジ
ネスの“主流”に
なってきた
経営に対してど
れだけの“貢献”
が出来るのか？
が問われている
“経営”に与える
影響が大きく
なってきた。
ネット証券ネット証券
何故、情報システム開発のプロジェクト何故、情報システム開発のプロジェクト
マネジメントが話題となるのか？マネジメントが話題となるのか？

プロジェクトは成功率プロジェクトは成功率 33 割！割！
品質品質コストコスト納期納期
出典：日経コンピュータ 2003/11/03

で成功率３割程度で成功率３割程度
に経営貢献に経営貢献できるのでしょうできるのでしょう
か？か？

プロジェクトマネジメントって？プロジェクトマネジメントって？
プロジェクトマネ
ジメント標準の
PMBOK ってしっ
てる？
仕様がコロコロ変わるの
を
どうにかしたいんだけど
プロジェクトっ
てそもそも
何？
WBS って何？
ニュース番
組？
を経営判断適
にえないも切行
のか？
プロジェクトが失
敗すると利益がね
コストってあまり
われたことがな言
いなぁ
ISO もとって
いるのにみん
なキチンと出
来てない

S1 チームメンバーの特性S1 チームメンバーの特性
はメンバーをす表はメンバーをす表
一
般
職
と
し
て
経
験
年
数
が
多
い
管
理
職
（
経
営
者
）
と
し
て
経
験
年
数
が
多
い
システムの発注側にいるシステムの受注側にいる

プロジェクトマネジメントにプロジェクトマネジメントに
するをめる対共通理解深するをめる対共通理解深
プロジェクトマネジメントについて最低限「・」プロジェクトマネジメントについて最低限「・」
のの
はしたい。前提知識共有はしたい。前提知識共有
について、ので「ＰＭＢＯＫ」共通課題図書勉について、ので「ＰＭＢＯＫ」共通課題図書勉
した。強した。強
「「をでかす国際標準実践活をでかす国際標準実践活
プロジェクトマネジメント徹底解説！」プロジェクトマネジメント徹底解説！」
IBMIBM 岡村正司氏著岡村正司氏著

「「 PMBOKPMBOK とは」とは」
• AA GGuide to theuide to the PProjectroject MManagementanagement
BBodyody ooff KKnowledgenowledge
• 国際的に認められているプロジェクト国際的に認められているプロジェクト
マネジメントを遂行するにあたってのマネジメントを遂行するにあたっての
知識体系知識体系
• システム開発に限らずプロジェクトマシステム開発に限らずプロジェクトマ
ネジメントが要求される全業界を対象ネジメントが要求される全業界を対象
– エンジニアリング、建設、防衛エンジニアリング、建設、防衛 etcetc

つのエリア９「知識」つのエリア９「知識」
ｺﾐｭﾆ
ｹｰｼｮﾝ
品質
リスク
調達
スコープ
コスト
ﾋｭｰﾏﾝ
ﾘｿｰｽ
タイム
統
合
はプロジェクトマネジメンＰＭＢＯＫ
トのであるが、で必要条件十分条件
はないことがわかった！
HOWHOW がないがない

1.1. ＩＴ部門のプロジェクトマネジメントに対する問題意識ＩＴ部門のプロジェクトマネジメントに対する問題意識
2.2. からぶプロジェクトマネジメント失敗学からぶプロジェクトマネジメント失敗学
4.4. 最後に・・・最後に・・・

なぜシステムプロジェク開発なぜシステムプロジェク開発
トはトは
するのか失敗？するのか失敗？

のプロセス問題抽出のプロセス問題抽出

カードして化分類・検討カードして化分類・検討
フェーズ分類項目件数
企画スケジュールに必然性がない 3
投資対効果が計測されていない 3
提案依頼プロジェクトの目的が曖昧 3
提案見積妥当性 5
リスクの影響 3
パートナー選定 3
投資対効果 1
契約成果物 1
計画リスクコンティンジェンシープラン 7
スケジューリング 2
スコープ管理 5
計画策定 4
要求分析要求定義の手法が確立されていない 4
目的が曖昧なことが原因 1
設計予見 3
変更管理 3
開発・テスト・移行コミュニケーション 11
その他 3
上
流
工
程
風土一般的情シス部門の特性 14

にが上流工程失敗要因集中にが上流工程失敗要因集中
69%
31%
上流工程
下流工程
システム開発プロジェクトの失敗原因
は、上流工程にあるのではないか？

プロジェクトのトラブル失敗原因プロジェクトのトラブル失敗原因

でのとは上流工程失敗？でのとは上流工程失敗？

　失敗事例１　失敗事例１
１．現象１．現象
• システムのサービスインがとなり、基幹統合・２回延期当初予定システムのサービスインがとなり、基幹統合・２回延期当初予定
からヶにリリースされることとなった。７月後からヶにリリースされることとなった。７月後
２．影響２．影響
• がにしたスケジュールがにした。経営陣対外的案内大幅遅延がにしたスケジュールがにした。経営陣対外的案内大幅遅延
• をにオーバー。開発予算大幅をにオーバー。開発予算大幅
３．経緯３．経緯
はメーカーへとして。本開発某ＳＩ発注はメーカーへとして。本開発某ＳＩ発注
• をしてせる。げした。ＳＩｅｒ信頼任＝丸投をしてせる。げした。ＳＩｅｒ信頼任＝丸投
• もけにげしていた。ＳＩｅｒ下請丸投もけにげしていた。ＳＩｅｒ下請丸投
４．原因４．原因
• の、をしているがいなかった。要件定義際現行業務理解人間必要の、をしているがいなかった。要件定義際現行業務理解人間必要
なをなかった。人的資源投入出来なをなかった。人的資源投入出来
• のがでなかった。だけのレビューと要件定義品質確認十分形承認のがでなかった。だけのレビューと要件定義品質確認十分形承認
。。

　失敗事例２　失敗事例２
• のカルテシステムがをこし、某市立病院電子障害起１０日間停のカルテシステムがをこし、某市立病院電子障害起１０日間停
した。止した。止
• していたシステムのもくなったため、の接続医療事務動作遅一連していたシステムのもくなったため、の接続医療事務動作遅一連
を、のをってすることになった。業務紙伝票使処理を、のをってすることになった。業務紙伝票使処理
• カルテシステムのサーバーにはしていなかった電子設計時想定負カルテシステムのサーバーにはしていなかった電子設計時想定負
がにかっていたが、にシステムとした。荷定常的掛更医療事務接続がにかっていたが、にシステムとした。荷定常的掛更医療事務接続
その、カルテシステムのレスポンスがにくなった結果電子極端遅その、カルテシステムのレスポンスがにくなった結果電子極端遅
。。
• にクライアントでにのカルテしかかな設計時１ＰＣ一度一人分開にクライアントでにのカルテしかかな設計時１ＰＣ一度一人分開
いであったが、には、のカルテをにいて想定実際複数人分同時開いであったが、には、のカルテをにいて想定実際複数人分同時開
するがにまっていた。入力方病院内広するがにまっていた。入力方病院内広

　失敗事例３　失敗事例３
• のでのったがされ、にさ関東某学校通知表誤成績印刷生徒配布のでのったがされ、にさ関東某学校通知表誤成績印刷生徒配布
れた。れた。
• システムをし、ったがされたい学籍管理修正誤成績印刷約４割近システムをし、ったがされたい学籍管理修正誤成績印刷約４割近
のをしてしなおした。生徒成績表再印刷配布のをしてしなおした。生徒成績表再印刷配布
• パッケージののにのにＦｉｔ＆Ｇａｐ際学年最終成績算出方法パッケージののにのにＦｉｔ＆Ｇａｐ際学年最終成績算出方法
パッケージとうがあり、そのがされなかった。仕様違点仕様実装パッケージとうがあり、そのがされなかった。仕様違点仕様実装
• のれもさることながら、テストのサンプルがな仕様確認漏時数少のれもさることながら、テストのサンプルがな仕様確認漏時数少
かったために、するまでもそのりにかなかった。配布誰誤気付かったために、するまでもそのりにかなかった。配布誰誤気付

の上流工程失敗要因の上流工程失敗要因
失敗を招いた要因失敗を招いた要因根源的な問題根源的な問題
事例事例
１１
業務知識の欠如業務知識の欠如経営幹部の目的と開発チームの経営幹部の目的と開発チームの
目的がバラバラ目的がバラバラ
事例事例
２２
具体的な利用方法の理解不足具体的な利用方法の理解不足
業務に対する観察の不足業務に対する観察の不足
ユーザの利用目的と開発者の想ユーザの利用目的と開発者の想
定していた利用目的が違った定していた利用目的が違った
事例事例
３３
パッケージ仕様のＦｉｔ＆Ｇａパッケージ仕様のＦｉｔ＆Ｇａ
ｐの漏れｐの漏れ
利用者の優先する課題と開発利用者の優先する課題と開発
チームの優先する課題が違ったチームの優先する課題が違った
これら失敗要因の根底には、プロジェクトの目的（経営
課題）がステークホルダー間で共有できていない。特
にシステム部門が確実に把握していない、という問題があ
ぶりだされた。

のがないのは目的共有出来のがないのは目的共有出来
か何故？か何故？

• システムの部門問題システムの部門問題
– システムがユーザーのの部門真要求（経営システムがユーザーのの部門真要求（経営
のを上課題）のを上課題）できない理解できない理解。。
• の利用部門問題の利用部門問題
– のをせるがプロジェクトに真要求出人のをせるがプロジェクトに真要求出人し参加し参加
ていないていない。。

システム部門の問題システム部門の問題
システムがユーザーのののをできな部門真要求（経営上課題）理解システムがユーザーのののをできな部門真要求（経営上課題）理解
い。い。
• 経営課題を理解するための知識がない経営課題を理解するための知識がない
• 経営課題を引き出すための手法や技術を持って経営課題を引き出すための手法や技術を持って
いないいない
– インタビュー技術インタビュー技術
– 図解の技術図解の技術
– 提案の手法提案の手法
• 経営課題を立体的に理解するための業務知識が経営課題を立体的に理解するための業務知識が
ないない
• 20072007 年問題やオープン化、アウトソーシング化年問題やオープン化、アウトソーシング化
や子会社化がこれらを更に悪化させる。や子会社化がこれらを更に悪化させる。

システム部門の対策システム部門の対策
システムがユーザーのののをできな部門真要求（経営上課題）理解システムがユーザーのののをできな部門真要求（経営上課題）理解
い。い。
• 情報システム部門の請負体質から、社内情報システム部門の請負体質から、社内
コンサルへの意識改革コンサルへの意識改革
• 業務知識や要求の引き出し手法を情報シ業務知識や要求の引き出し手法を情報シ
ステム部門（ステム部門（ ITIT ベンダーを含む）の教育ベンダーを含む）の教育
体系の中に組み込んでいく。体系の中に組み込んでいく。

の利用部門問題の利用部門問題
のをせるがプロジェクトにしていない。真要求出人参加のをせるがプロジェクトにしていない。真要求出人参加
• 経営課題を意識しながら仕様を要求でき経営課題を意識しながら仕様を要求でき
る人材がプロジェクトに投入できない。る人材がプロジェクトに投入できない。
• プロジェクトの方向性に対して判断が出プロジェクトの方向性に対して判断が出
来る人材をプロジェクトに投入できない来る人材をプロジェクトに投入できない
。。

の利用部門対策の利用部門対策
のをせるがプロジェクトにしていない。真要求出人参加のをせるがプロジェクトにしていない。真要求出人参加
• 経営者とシステムの目的を共有化するた経営者とシステムの目的を共有化するた
めに集中的に討議する場を設ける。めに集中的に討議する場を設ける。
• ステークホルダーが一同に会するステアステークホルダーが一同に会するステア
リングコミッティを定期的に開催する。リングコミッティを定期的に開催する。
• 要件定義段階では、キーパーソンを専任要件定義段階では、キーパーソンを専任
でプロジェクトに参加させる。でプロジェクトに参加させる。

上流工程で目的のズレを
極小化するためのスキル向上と
組織つくりが、システム部門と利用部門
双方に必要である。
つまり・・・つまり・・・

のができれば目的共有のができれば目的共有
プロジェクトはするの成功プロジェクトはするの成功
か？か？

がされても、目的共有がされても、目的共有
ソフトウェアエンジニアリングの「問ソフトウェアエンジニアリングの「問
や題」や題」
プロジェクトマネジメントの「問題」プロジェクトマネジメントの「問題」
でで
するケースがありうる。失敗するケースがありうる。失敗
プロジェクトの遂行上問題プロジェクトの遂行上問題

本業強化本業強化
ソフトウェアエンジニアリングの＜問題＞ソフトウェアエンジニアリングの＜問題＞
• システムのりをらない作方知システムのりをらない作方知
– モジュール分割方法モジュール分割方法
– 構造化／共通化構造化／共通化
– テスト方法テスト方法
– ユーザ教育方法ユーザ教育方法
＜対策＞＜対策＞
• ソフトウェアエンジニアリングソフトウェアエンジニアリングにづいた、手法基にづいた、手法基
しいをする正開発手法適用しいをする正開発手法適用

マネジメント強化マネジメント強化
プロジェクトマネジメントの＜問題＞プロジェクトマネジメントの＜問題＞
• プロジェクトのマネジメントプロジェクトのマネジメントのをらない。方法知のをらない。方法知
＜対策＞＜対策＞
• のプロセスとコントロールのをＰＭＢＯＫ知識活のプロセスとコントロールのをＰＭＢＯＫ知識活
し、用し、用プロジェクトをコントロールプロジェクトをコントロールしていく事していく事

プロジェクトので遂行過程プロジェクトので遂行過程
しないためには失敗しないためには失敗
「ソフトウエアエンジニアリング」
「プロジェクトマネジメント」の
どちらも組織として知識や手法を
定型化・標準化し、共有していくことが
失敗プロジェクトを生み出さない秘訣だ！

3.3. からぶプロジェクトマネジメント成功学からぶプロジェクトマネジメント成功学
4.4. 最後に・・・最後に・・・

マネジメントやテクニックだマネジメントやテクニックだ
けでなのか充分？けでなのか充分？

などをしなくてもプロジェクＰＭＢＯＫ利用などをしなくてもプロジェクＰＭＢＯＫ利用
トはする。成功（例：文化祭実行委員）トはする。成功（例：文化祭実行委員）
– よくするととがている。分析自然協力体制出来よくするととがている。分析自然協力体制出来
– メンバーがをってちんだり、の全情熱持打込他メンバーがをってちんだり、の全情熱持打込他
　メンバーのにをっている。仕事関心持　メンバーのにをっている。仕事関心持
チームビルディングの重要性チームビルディングの重要性
プロジェクトの成功には、
「チームビルディングの成功」
という人間的要素が欠かせないのではないか。

システムプロジェクトにの開発特有システムプロジェクトにの開発特有
チームビルディングのしさ難チームビルディングのしさ難
• ソフトウェアはにえない、の開発目見形ソフトウェアはにえない、の開発目見形
ないものをるなプロセスである。作知的ないものをるなプロセスである。作知的
• をう、ながい。頭脳労働伴孤独作業多をう、ながい。頭脳労働伴孤独作業多
• プレーがいため、チームの個人多一体感プレーがいため、チームの個人多一体感
をりづらい。作をりづらい。作
• のモチベーションのがチームの個人持続のモチベーションのがチームの個人持続
にきなをえる。開発生産性大影響与にきなをえる。開発生産性大影響与

チームビルディングをする形成工夫チームビルディングをする形成工夫
• チームとしてのがプロジェクトの一体感チームとしてのがプロジェクトの一体感
にはなであるが、システム成功重要要素にはなであるが、システム成功重要要素
プロジェクトでは、この開発プロジェクトでは、この開発の一体感醸の一体感醸
がしい成難がしい成難。。
• にけをって、チームビル意識的仕掛作にけをって、チームビル意識的仕掛作
ディングをする形成ディングをする形成かみのあるが温工夫かみのあるが温工夫
必要必要。。

チームがれるとき崩・・・チームがれるとき崩・・・

チームがれるとき壊チームがれるとき壊
• チームのがなとき全体責任分担曖昧チームのがなとき全体責任分担曖昧
• のをさせる会社都合優先のをさせる会社都合優先
• するにきなムラがあるとき指示内容大するにきなムラがあるとき指示内容大
• りはいが、がないＰＭ気取多ＰＭ気質少りはいが、がないＰＭ気取多ＰＭ気質少
• のワンマンＰＭ発言のワンマンＰＭ発言
• をする個人攻撃をする個人攻撃

チーム全体の責任分担が曖昧なとチーム全体の責任分担が曖昧なと
きき
 プロジェクトが進行に伴い、当初決定した役割プロジェクトが進行に伴い、当初決定した役割
とは異なり、出来る人に仕事が集中とは異なり、出来る人に仕事が集中
 仕事をやらない人、オーバーフローする人が出仕事をやらない人、オーバーフローする人が出
現現
 指示系統もあいまいになる指示系統もあいまいになる
 役割分担、責任範囲が明確にしないままプロ役割分担、責任範囲が明確にしないままプロ
ジェクトを開始ジェクトを開始
 当初、明確にしていても、状況に合せた見直し当初、明確にしていても、状況に合せた見直し
を実施せず、成り行きに任せるを実施せず、成り行きに任せる

会社の都合を優先させる会社の都合を優先させる
 プロジェクトが成り行き任せになるプロジェクトが成り行き任せになる
 プロジェクトの外部の状況に左右され、コントプロジェクトの外部の状況に左右され、コント
ロールを失うロールを失う
 タイトなスケジュールに必死になっているときタイトなスケジュールに必死になっているとき
に、「残業が多いから早く帰れ！」と言われるに、「残業が多いから早く帰れ！」と言われる
。。
 チームメンバーが次々と入れ替わり、最終的にチームメンバーが次々と入れ替わり、最終的に
は最初とまったく違うメンバーになっていたは最初とまったく違うメンバーになっていた

指示する内容に大きなムラがあると指示する内容に大きなムラがあると
きき
 チーム全体の責任分担が崩れ、役割分担も形骸チーム全体の責任分担が崩れ、役割分担も形骸
化する化する
 ＰＭのワンマン的印象が時間とともに強くなりＰＭのワンマン的印象が時間とともに強くなり
、モチベーションが下がる、モチベーションが下がる
 ＰＭが得意な部分は、他人の責任範囲にまで入ＰＭが得意な部分は、他人の責任範囲にまで入
り込んで、細かく指示り込んで、細かく指示
 ＰＭが不得意な部分においては、放置するＰＭが不得意な部分においては、放置する

ＰＭ気取りは多いが、ＰＭ気質がＰＭ気取りは多いが、ＰＭ気質が
少ない少ない
 全て、メンバーに押し付けているというＰＭは全て、メンバーに押し付けているというＰＭは
何もしないという感じがチームに充満する。何もしないという感じがチームに充満する。
 進んで作業をする気持ちが失せる。進んで作業をする気持ちが失せる。
 期限の迫った仕事ばかりを割り当てる期限の迫った仕事ばかりを割り当てる。。
 「俺は何も分からないからそっちで判断して」「俺は何も分からないからそっちで判断して」
とと指示を装って、自分は関わらない。指示を装って、自分は関わらない。
 自分で話をするのではなく、他の人にさせる。自分で話をするのではなく、他の人にさせる。

ＰＭのワンマン発言ＰＭのワンマン発言
 判断基準がみえず、ＰＭの気分次第でのマネジ判断基準がみえず、ＰＭの気分次第でのマネジ
メントにしかみえない。メントにしかみえない。
 モチベーションがさがり、メンバーも勝手な判モチベーションがさがり、メンバーも勝手な判
断で作業するようになる。断で作業するようになる。
 「俺は今度の進め方、気に入らねーんだよ！」「俺は今度の進め方、気に入らねーんだよ！」
と、自分に課せられた理不尽なことに対する不と、自分に課せられた理不尽なことに対する不
満をメンバーにぶつける。満をメンバーにぶつける。
 発言内容の根拠も確認せずに、表面的な状況発言内容の根拠も確認せずに、表面的な状況
でで
ＰＭが即断してしまうＰＭが即断してしまう

個人攻撃をする個人攻撃をする
 自分は信頼されていない。→やる気を失う。自分は信頼されていない。→やる気を失う。
 責任逃れに使われた！→ＰＭへの信頼を失う。責任逃れに使われた！→ＰＭへの信頼を失う。
 会議での発言をしなくなる。会議での発言をしなくなる。
 会議の場などメンバーの前で、怒鳴る。会議の場などメンバーの前で、怒鳴る。
 あえて個人名をあげて、上司に失敗報告をするあえて個人名をあげて、上司に失敗報告をする
。。
 発言内容ではなく、発言者の立場やチーム内発言内容ではなく、発言者の立場やチーム内
での存在、役割で判断し、意見を公平に扱わでの存在、役割で判断し、意見を公平に扱わ
ない。ない。

ここまでの　ここまでの　まとめまとめ
目的マネジメント／
テクニック
チームビルディング
プロジェクト
計画
不明確不足
リーダーシップ

4.4. に最後・・・に最後・・・

プロジェクトのために成功プロジェクトのために成功
経営者経営者ユーザユーザ
ＩＴ部門ＩＴ部門
開発開発
ベンダーベンダー
プロジェクトのプロジェクトの
成功成功
開発開発
開発開発
開発開発
開発開発

ご清聴ありがとうございましたご清聴ありがとうございました

I suc発表用v2.8

Empfohlen

Empfohlen

Weitere ähnliche Inhalte

Was ist angesagt?

Was ist angesagt? (20)

Ähnlich wie I suc発表用v2.8

Ähnlich wie I suc発表用v2.8 (20)

I suc発表用v2.8

Hinweis der Redaktion