（続）Itプロジェクトマネジメント成功のための勘どころ 20140318

1 Copyright(C) IT innovation, Inc. All rights reserved.
（続）ITプロジェクトマネジメント
成功のための勘どころ
～環境の変化に合わせて、進化するものとは～
株式会社アイ・ティ・イノベーション
http://www.it-innovation.co.jp
取締役兼専務執行役員
能登原伸二

講師プロフィール
能登原伸二
株式会社アイ・ティ・イノベーション取締役兼専務執行役員
名古屋工業大学情報工学科非常勤講師
1960年生まれ、名古屋工業大学情報工学科卒業（1983年3月）。
株式会社ジャパンエナジー（現：JX日鉱日石エネルギー）の情報システム部門において、
長年、情報システムの企画、開発、運用までの幅広い業務に携わり、ITによる業務改
革、収益向上を支援してきた。現在はITベンダー、ユーザー企業の情報システム部門
へのプロジェクト管理標準導入、PMO（Project Management Office）の運営、ITプロ
ジェクトにおけるプロジェクト管理支援コンサルティングなどに加え、IT 構想・企画などの
超上流工程支援、IT戦略・ビジョン策定なども幅広く手がける。常に顧客と共に考え、
行動し、成果を上げることをモットーとしている。
大規模で、複雑なプロジェクト管理の専門家。
プロジェクトマネジメント協会（PMI）会員、PMP
【著書】
「プロジェクト管理大全（共著）」（日経BP）
日経SYSTEMSにて「のとはら先生」シリーズを連載
「プロジェクトマネジメント現場マニュアル改訂版」（日経BP）
「”勝てる”IT構想・企画（共著）」（日経BPコンサルティング）
「医療現場のプロジェクトマネジメント」(ビジネス双書)

3 Copyright(C) IT innovation, Inc. All rights reserved.P.3
＜現代の経営（THE PRACTICE OF MANAGEMENT）＞
部下の育成には、技術の習得や責任の重要さの強調でさえ補うことの
できないある資質が、経営管理者側に要求される。すなわち真摯さである。
＜経営者の条件（THE EFFECTIV EXECUTIVE）＞
①なされるべきことを考える
②組織のことを考える
③アクションプランをつくる
④意思決定を行う
⑤コミュニケーションを行う
⑥機会に焦点を合わせる
⑦会議の生産性をあげる
⑧｢私は｣ではなく｢われわれは｣を考える
おまけ、聞け、話すな
私の好きなドラッカーの言葉

目次
 昨今のITプロジェクトを取り巻く環境変化
 今後の情報システムに求められること
 今後のITプロジェクトに求められること
 プロジェクト・マネジャーに求められることの変化
 変化していないもの
 プロジェクト・マネジャーとして何を磨くか

昨今のITプロジェクトを取り巻く
環境変化

1. 人手に依存
工業製品と比べて、人手で作る割合が高い。
（影響）人のスキル・経験、モチベーション、
リーダの指導・支援によって生産性が変化
2. 要求機能が変動
最終成果物である情報システムが｢モノ｣でなく、
目に見えない｢機能｣であること、及びビジネスが
変化することにより、要求されている機能が開発
途中で大きく変動する。
（影響）発注側が要求した機能が目に見えないため、
追加要求が多発し想定以上に開発規模が膨張
3. 品質測定が困難
中間成果物が設計書やプログラムであるため、
実体が見えず、品質も測定し難い。
（影響）中間での品質が把握できないため、開発の
終盤で、突然システムの不良が発覚
システム開発の特徴
VS.
VS.
VS.
情報システム輸送機械、建築物など
人がチームで作る機械が機械を作る
自動化が進んでいる
全体像が見える全体像が見えない
プログラムを動かすまで
品質が見えない途中経過が見える

IT業界の変化
人材育成
の遅れ
ITプロ
ジェクト
の増加
プロフェッショナ
ル人材の不足
（PM、BA、ITA）
 企業の収益力アップ
 システムの老朽化
 IT領域の広がり
（ゲーム、Web、組み込
み、エンタープライズ）
 オフショア開発
（下流工程の外注）

レガシーシステムの刷新
プロジェクト
グロバールシステムの
開発プロジェクト
アジャイル
プロジェクト
複数のプロジェクトが
連携するプログラム
IoTに関する
プロジェクト
M＆Aプロジェクト
プロジェクト形態の多様化

プロジェクトがうまくいかない真因は何か
シ
ス
テ
ム
開
発
構
想
・
企
画
・
計
画
2．要求される機能
（仕様）が膨らむ
1．構想・企画・計画が
曖昧・誤り
目的、スコープ、体制等
納期遅延コスト増・納期遅延
3．品質が悪く正常に
動作しない
品質低下、
納期遅延
ビジネスの機会損失
予定してサービスが提供で
きず、投資効果得られず
大幅なコスト増
当初の契約外の作業につ
いては新たなコストが発生
品質低下
潜在的な障害を抱えたまま
での運用
保守コストの増大
遅延作業従事者の
機会損失
遅延対応作業のため、
新規業務に従事できない
本番稼動
予定
遅延対応
作業
発注企業側への影響
例）年間12億円のコストが
かかるプロジェクトで1ヶ月
遅延すると1億円予算超過
要件定義
設計
構築
テスト
移行
導入
IT構想・
企画
計画
 システム開発の特性から発生する失敗で企業は多大な損害を受ける。
根本原因

役に立つシステムを構築するために必要なこと
のぞましい姿
経営の課題達成型
（長期的な戦略指向）
よくない姿
情報システム
ビジネス
戦略
組織・業務
現場の問題解決型
（短期的な合理化指向）
IT戦略
ビジョン
取り巻く環境の変化
組織・業務
情報システム
IT戦略
ビジネス
戦略
取り巻く環境の変化
ビジョン
ビジョン・戦略達成に向けて一貫性
があり、かつ、環境変化への対応が
できる構造になっている
ビジョンや戦略が不透明で、取り巻
く環境の変化に振り回される

企業理念
全社戦略
機能別
戦略
ビジョン
ビジネス戦略
営業戦略
生産・調達戦略
研究開発(R&D)戦略
財務戦略
Ｍ＆Ａ戦略
マーケティング戦略
人材戦略
IT構想・企画
要求の
取りまとめ
業務・
システムの
概要定義
実現
シナリオの
策定
業務改革系構想・企画業務改革系プロジェクト
開発工程
要件
定義
外部
設計内部
設計
構築
ﾃｽﾄ
移行
導入
稼動
ＩＴ構想・企画
:
・
・
・
業務＆システムの変革
業務のみの変革
ビジョン、IT戦略、IT構想・企画、開発の連動
ＩＴ戦略
ＩＴ戦略には他の機能別
戦略とも関連するもの
がある
超上流工程

 構想・企画の戦略・計画のミスが、プロジェクト失敗の大きな原因になる。
1.要求の
取りまとめ
（Why）
2.業務・システ
ムの概要定義
（What）
3.実現シナリ
オの策定
（How）
IT構想・企画
IT構想・企画のプロセスIT構想・企画を起因とする失敗のパターン
要件定義～開発
プロジェクトの実行
プロジェクト計画
【技術不適切型】
選定したツールや
サービスが複雑で
あったり、未成熟で
あったため、品質や
生産性の悪化をま
ねき、プロジェクトが
完成しなかった。
【目的あいまい型】
目的があいまいで
あったため、ビジネス
に役立たないシステ
ムが構築された。
【現行見えない型】
現行システムが未
調査で、現行業務
を保証するシステム
設計ができない。
また、現行システム
から新システムへの
移行もできない。
【無理な計画型】
スケジュール、体制、
コストの検討が不十
分（実現性未検
証）で、無理な計
画を実行することに
なり、品質不良、コ
スト増の負のサイク
ルとなった。

今後の情報システムに求められること

情報システム部門の目的
多様化する要求に対して、柔軟にスピーディーに対応する
安定したＩＴサービスを提供する
ＩＴサービスの導入にあたり、高品質、短納期、低コストを実現する
ＩＴサービスにおけるセキュリティ、コンプライアンスを統制する
グローバルの観点は必要

果たすべき機能
• 情報体系と情報基盤を使ってどのように課題・
問題を解決するかを決定する。
• 全社横断的な視点から、業務改善を推進する。
ビジネス上の
課題・問題解決
• ユーザから要求される情報を、正確かつ効率的に
提供するために、情報システムで扱われるデータ
（意味、属性）全体を整備する。
情報体系の管理
• 情報基盤（インフラ、アプリケーション）の
アーキテクチャを整備する。
• 情報基盤の構築、運用の方針を決定し、常に最
適な状態となるように管理する。
情報基盤の管理
• 情報戦略を立案する。
• 情報システムの企画、開発、運用プロセスを整備する。
• 情報システムに係わる組織を管理する。
• 情報システムの投資対効果を管理する。
情報システムと
組織の管理
情報システム部門が果たす4つの役割

役割分担
機能を果たすために、情報システム部門は一般的に、以下のように役割を分担
エンド
ユーザ
ー
ユーザー企業パートナー（ベンダー）
ユーザー部門情報システム部門
ITサービス全般
ビジネス計画管理
ITサービス統制管理
(IT組織運営)
情報システム設計・開発
サービス計画管理
IT資産管理
情報システム
設計・開発
エンドユーザー
活用支援
ビジネス戦略サービス評価分析
エンドユーザー
活用支援
ITサービス支援管理
ITサービス運用提供
エ
ン
ド
ユ
｜
ザ
｜
情報システム導入・変更
プロセスで発生する
全ての資産
情報システム導入変更業務・システムの移行が連携
・ユーザー満足度情報
・サービスレベル情報
・利用支援状況
・ヘルプデスク問合せ集計情報
・ユーザー要望
・ITサービス運用状況
・信頼性、効率等向上提案
・障害情報
ITサービス全般
エンドユーザー要求
←エンドユーザー要求
ユーザ支援→
サービス提供

情報システムに求められるもの
ビジネスの
変化が激しい
• ITの重要性UP
• 想定外の変化
• グローバル対応
• 人材の流動化
• 情報システム部門
の弱体化
柔軟なITアーキ
テクチャの構築
（都市計画）
• システムの見える化
• 適切なIT戦略とその
実行
ビジネスに俊敏
に対応してシス
テムを構築
（アジャイル）
• ビジネスに必要な部
分を必要なだけ作る。

今後のITプロジェクトに求められること

 構想・企画の戦略・計画に時間を取って、正しい方針を導く。
1.要求の
取りまとめ
（Why）
2.業務・システ
ムの概要定義
（What）
3.実現シナリ
オの策定
（How）
IT構想・企画
IT構想・企画のプロセスIT構想・企画で思考する
要件定義～開発
プロジェクトの実行
プロフェッショナル（PM、BA、ITA）を
集める。
プロセスに従い、検討する。
多数の代替案を多面的に検討する。
レガシーシステムの刷新
グローバルシステム開発
アジャイル
複数プロジェクト連携のプログラム
IoTに関するシステム開発
適した
アプローチ

リーン製品開発
時間
代
替
案
Ｓｔａｒｔ
セットベース開発：多数の代替案を並行して評価しながら、
徐々に絞り込んで、設計していく方法
LAMDAサイクル
Look：観察する
Ask：問いかける
Model：モデル化する
Discuss：話し合う
Act：行動する
製品開発：イノベーションを起こし、価値を生む
生産：製品開発が生み出した設計情報に基づいて、繰り返し生産する
構想設計詳細設計～
LAMDA
LAMDA
LAMDA
LAMDA
LAMDA
LAMDA
※稲垣公夫著：“開発戦略は「意思決定」を遅らせろ！”を参照。

システム開発
時間
代
替
案
Ｓｔａｒｔ
目的：ビジネスに役立つ情報システムを作る
（システム開発も、製品開発と同様にプロジェクト）
IT構想・企画開発工程
目的・要求
ソリューション
・要件
アーキテクチャ
体制・ベンダー
アプローチ
多数の代替案を多面的に検討して、
システムを企画する
確定した要件に基づき、
設計・プログラミング・テストを実施

IT構想・企画でやること
何のために
Why
どのような業務・システムを
どのように実現するか
What
How
ビジョン・戦略
ITプロジェクト
本気で目的・要求を
考える
正しいプロジェクトを創る
（実現可能性の検証）

IT構想・企画のプロセス
「Why」「What」「How」の３つの切り口で段階的に検討し、最終的に企画
書としてまとめる。
1.1
ビジネスの
方向性を
理解する
1.2
現行の業務・
システムを
把握する
1.3
業務・システム
の要求を
概括する
2.1
ハイレベルな
業務プロセスと
概念データの
モデルを作成する
2.3
技術的な
アーキテクチャ
を定義する
3.1
実現のシナリオ
を策定する
3.2
企画の承認
を得る
3.
実現シナリオの策定
2.
業務・システムの概要定義
1.
要求の取りまとめ
IT構想
・企画
プロセス
トップダウン
（経営）の視点
ボトムアップ
（現場）の視点
2.2
業務運用の
体制を定義す
る
2.5 ソリューション候補を評価する
2.4
移行を
検討する
今後の業務の概要、必要となる
役割や組織、情報システムの構
造、現状からの移行を検討し、そ
の実現性や効果を確認する。
ビジネスの方向性から見える
あるべき姿と、業務・システム
の現状から、必要な要求を洗
い出し、その要求を実現する
ソリューション候補を検討する。
新業務・システムを実現する
シナリオ（今後のプロジェクト
定義、リスク、マスタースケ
ジュール、体制、投資対効果
等）を策定し、システム企画の
承認を得る。
システム
企画書
何のためにどのような業務・
システムを
どのように実現す
るか

Business
ITアーキテクト
ＡｓＩｓ
MODEL(Blue-Print)
System
ＴｏＢｅ
Migration Plan
Business
ＩＴの課題ﾋﾞｼﾞﾈｽの
特性分析
Analyze Describe
・レガシーシステムの刷新では、ToBeモデルの明確化と開発アプローチの設計が重要
MODEL
MODEL
アーキテクチャ設計の重要性

Business
System
・アーキテクチャは、様々な事情で最適化を阻害される。
ビジネス上の期限が切
迫していて最適化して
いる暇がない。
選択した製品がユー
ザーの業務やニーズ
と合っていない。
昔作ったシステムがその場
限りの仕様になっている。
そもそも仕様が残っていない
。
製品のアーキテクチャは全
体最適とは無関係で身
勝手に作られている。
・機能やデータが重複し、複雑でスパゲ
ティ化したシステム。
・ちょっとした改変でも多大な時間とコス
トが掛かる。
プロジェクト失敗の例

プロジェクト・マネジャーに求められ
ることの変化

プロジェクトマネージャーとは
プロジェクトの推進責任者
プロジェクトの目標を達成する責任を負う
与えられたリソースの範囲で、プロジェクトを計画し、
推進する。

プロジェクトマネージャ（PM）の資質と能力
プロジェクトの目的・目標
管理・調整力
プロジェクトマネジメント
の知識・手法
正しい考え方（信頼、誠実……）
コミュニケーション力
コミットメントを達成する力
リーダーシップ
何としても、
成功に導くという
熱意、必死さが
最も重要な
要素

具体的なリーダー像とは
 『苦労している人を励ますのがリーダーの仕事・・・と言ってい
る人のもとでは働きたくない。私の能力を認め、それを伸ばす
人の下で働きたい。』
（トム・デマルコ：米国の著名なITプロジェクト専門家）
どういうプロジェクトマネージャー（PM）と
一緒に働きたい？
 『危機管理は、通常の場合、集団のルールに則って実施すれ
ば良いが、いざとなった場合、指揮官が現場に降りて実践する
ことも必要である。』
（香月智防衛大学校教授）

ステークホルダー・マネジメント
多様なプロジェクト形態により、ステークホルダーとの良好な関係が重要
プロジェクト
マネジャー
レガシーシステムの
刷新
・アプローチ方針の理解
・既存システム運用担当
との関係
グローバルシステムの
開発
・グローバル人材との関係
アジャイル
・アジャイル・アプローチへの
理解
複数プロジェクト連携
のプログラム
・IT以外の担当者との関係
・他社との関係
対応領域が広く、政治的な対応も実施
（PMだけでなく、経営層も含めたチームで対応）
チームの認識を一致するために、十分な時間が
必要
（コミュニケーション、ファシリテーション）

ビジネス上
の問題を定
義し解決が
できる
やり方に従って
実行できる
学習中
運用スペシャリスト開発スペシャリスト
プロジェクトマネジャービジネスアナリスト
ＩＴアーキテクト
エンジニア
IT構想・企画に必要なスキル
実務
実務
実務
実務
実務
実務
実務
様々な立場での実務を経験し
、幅広いスキル、経験をする必
要がある
 対象範囲が広く、複雑なシステムに対応するためには、幅広いスキルが必要
ビジネス分析や
アーキテクチャ設計
についての知識も
習得する

変化していないもの

プロジェクトマネジメントの必要性
不確実、リスク不確実、リスク
Goal
Start
Goal
Start
？
プロジェクトマネジメントにより、
リスクを予測し、先手を打つことで
失敗を防ぐ
プロジェクトの目標達成を支援する活動
（プロジェクトマネジメント）が必要
プロジェクトは、非定常活動であるため、不確実性を伴う。
ハイリスクであり、何も手を打たなければければ、失敗する可能性が高い。

重要な土台：プロジェクトメンバー全員が
「プロジェクトの目的とルールを共有し、実践する」こと
マネジメントプロセス
計画実行、監視・コントロール立上げ終結
開発プロセス
要件定義
基本設計
詳細設計ﾌﾟﾛｸﾞﾗﾐﾝｸﾞ
単体テスト結合テスト
総合テスト
移行サービス
開始
Check
Check
Check
Check
Check
Check
Check
Check
問題課題
発生
知見・ノウハウ
収集
プロジェクトマネジメントの要所
工程遅延
①リスクを考え、
計画する
②問題の兆候を
とらえ、対応する
③品質の状況を
知る
④変更を把握し、
交渉する

①リスクを考え、計画する

プロジェクト計画の手順
タスクの
分解
プロジェクト
体制の立案
外部委託計画
の立案
品質計画の
立案
リスク評価、
対策の立案
実行予算の設定
の承認を獲得
スパイラルに精緻化！
タスクに要員を
割当て、工数を見積り
コミュニケーション
計画の立案
スケジュール
の作成
プロジェクト
を定義
体制
ＷＢＳ工数見積り
会議体
マスター
スケジュール開発アプローチ
リスクを十分に
考慮して行うこ
とが重要！

リスクとは
脅威
（損害を与える原因）
脆弱性
（組織の弱点）
リスク発生・コスト増大
・納期遅延
・品質悪化
もしも発生した場合、プロジェクト目標やコミットメント（責任ある約束）
にマイナスの影響（損害）を与えるであろう、不確かな事象、状態
リスクを予測し、先手を打つ
リスクが存在することをなるべく早期に識別し、対応策を
策定／実施する。
プロジェクト実施

リスク一覧表
想定されるリスク、対応策などをリスク一覧表にまとめる。
想定リスク影響予防対策発生時対策
トリガー
ポイント
複数部門に関係
する案件のため、
業務要件が確定
しない。
開発スケジュー
ルが遅延し、開
発費用が膨らむ。
・ユーザに対して、事前に
仕様決定プロセスと決
定時期を明確にする。
また、遅延時の影響を
十分、説明しておく。
・要件とりまとめ責任者に、
影響力のあるリーダを選
定する。
・緊急のワークショップを
開催して業務要件を
確定する。
・場合により責任者同
士の協議・決定の場を
設ける。
設計進捗
が2週間遅
れると予想
される時点。
対象業務のBPR
中のため、要件
定義レビュー後に
仕様変更が多発。
設計作業の手
戻りとなり、開発
スケジュールが遅
延し、開発費用
が膨らむ。
・ユーザに対して仕様変
更が与える影響を十分、
説明しておく。
・厳格な仕様変更管理
を実施する。（変更承
認の最終決定者、判
断基準の優先度を定
義しておく）
・原則、仕様変更は稼
動後のフォローアップとし
て対応する。
・しかし、絶対必要な要
件については、ステコミ
の判断を仰ぎ、開発予
算/スケジュールの変更
を含め対応する。
仕様変更
の吸収が、
納期に影
響すると判
断した時
点

リスク対応策の計画への反映
予防策に記載した内容は、体制、スケジュールに盛り込む。
リスク発生に備えて、追加工程及びコストを見積る。
設計
構築
(製造）～
要件
定義
リスク対策
リスク対策
余
裕
工
数
リスク対策を盛り込んだ計画リスク係数＝1.xx
PM
業務グループ
業務（部門）A
担当
財務、人事
：
業務（部門）B
担当
リスク対策
リーダー
システムグループ
アプリケーション
担当
インフラ担当運用担当
リスク対策
リーダー
リスク対策
PMOチーム
アドバイザ
リスク対策を盛り込んだ体制
リスク
一覧表

②問題の兆候をとらえ、対応する

プロジェクトの問題構造をとらえてコントロールする
各種管理
プロセス
基本的な日常のコミュニケーション
進捗品質
変更コスト
監視
でのコミュニケーション
兆候（不審点）を感知する
対策案の洗い出し
実施対策の決定
報告
会議体
（表層的）問題
問題
問題
主原因
問題
問題
プロジェクトの実態
（問題構造）
問題
調査・確認
プロジェクトの実態（問題構造）の把握
問題の関
連要素の
分解
問題原因の洞察
対策
『問題』
（リスク=将来の問題の候補）

問題の兆候とは？
 進捗の“やや遅れ”継続
 遅れの理由があいまい、変わる
 品質の低下傾向
 未解決問題の増加
 度重なる仕様の変更
 チーム内の会話が減少（議論すべき
課題が多いのに・・）
 会議などの集合時間がルーズに・・
 残業の継続、増加

③品質の状況を知る

品質を確保するためのシナリオ
時間
達
成
度
合
い
Ｇｏａｌ
Ｓｔａｒｔ
• ゴール（品質目標）を設定する
• チェックポイント（品質保証活動）を計画し、実行する
• チェックポイントで用いる評価基準を設け、測定する
• 問題があれば、是正処置をする
• 品質状況を把握する
管理不在のケースでは、
最終段階で品質不良が
発覚、リカバリーに多大
な時間とコストがかかる
チェックポイント
測定
乖離
是正処置
品質確保のシナリオ

品質目標の設定
システムに求められる品質を、その達成度合いがわかるよう具体的な目標
値として設定する。
重要度が高い機能は、利用者が
ストレスを感じないレベルのレスポ
ンスを確保する。
信頼を大きく損なうため、不具合は
あってはならない。
オンライン処理の応答時間：
重要度（高）機能：3秒/１アクション以内
重要度（低）機能：5秒/１アクション以内
稼動後3ヶ月までに発生しうる誤り件数/
生産量（KL）：0.01％以下
具体的には？具体的には？

品質保証活動の計画
レビューやテスト等の品質保証活動を綿密に計画し、実行する。
「漏れなくテストができるようになっ
ているか」をレビューする
「仕様どおりに正しく動作するか」を
テストする
要件定義
基本設計
詳細設計
ﾌﾟﾛｸﾞﾗﾐﾝｸﾞ単体テスト
結合テスト
総合テスト
ユーザ
テスト
要件定義書
ユーザテスト
仕様書
基本設計書
総合テスト
仕様書
詳細設計書
結合テスト
仕様書
ソースコード
単体テスト
仕様書
「要求事項を正しく仕様として反映
しているか」をレビューする

品質状況の測定
品質保証活動の結果を可視化して、評価する。
テストケース設定率
【単体テスト】 100件/KS
【結合テスト】 20件/KS
【総合テスト】 5件/KS
不具合検出率
【単体テスト】 10件/KS
【結合テスト】 2件/KS
【総合テスト】 0.5件/KS
要件定義
基本設計
詳細設計
ﾌﾟﾛｸﾞﾗﾐﾝｸﾞ単体テスト
結合テスト
総合テスト
ユーザ
テスト
要件定義書
ユーザテスト
仕様書
基本設計書
総合テスト
仕様書
詳細設計書
結合テスト
仕様書
ソースコード
単体テスト
仕様書
レビュー指摘率
0.5件/頁

工程完了の判定（関所の機能）
プロジェク
ト計画
（品質管
理計画）
要件
定義
基本
設計
詳細
設計
プログ
ラミング
単体
テスト
結合
テスト
総合
テスト
移行
サービ
ス開始
本番
稼働
要件定義
工程完了判定
基本設計
工程完了判定
詳細設計
工程完了判定
PG/単体テスト
工程完了判定
結合テスト
工程完了判定
総合テスト
工程完了判定
移行工程
完了判定
リリース判定
開発の各工程完了判定のタイミングで、当該工程における品質
状況を総括して報告。品質不良の場合は、次工程に進まない。
進捗報告等の定例会議（▲は、品質状況報告もあわせて実施）
△ ▲ △ ▲ △ △ ▲ △ △ ▲ △ △ ▲ △ △ ▲ △ △ ▲ △ △ ▲ △
工程途中の品質状況は、進捗報告等の定
例会を利用して、定例的に実施。

品質管理のPDCAサイクル
開発現場での主体的な品質管理と、統括的な品質管理をうまく
組み合わせ、それぞれのPDCAサイクルをしっかり機能させる
各工程各工程
品質状況の把握
計画の見直し
Action
開発現場での主体的な品質管理プロジェクト計画
・品質管理計画
・品質目標
Plan
作業
（レビュー
・テスト等）
Do
品質状況報告
（週次，月次）
Check
品質保証活動
の計画
品質の
測定・評価
原因分析
対策の実施
Plan Do
CheckAction
品質を作り込む担当（設計・プ
ログラミング・テスト）は現場
プロジェクト
計画書

④変更を把握し、交渉する

変更の手順
変更要求の受付
変更可否の判断
 影響範囲の特定：
 変更に伴い必要となる成果物の修正箇所
（直接の変更箇所だけでなく、影響を受ける成果物や作業の全てを見通す）
 スケジュール、品質、コスト、体制・要員、リスクなどへの影響：
 変更作業、および影響を受ける全ての作業の負荷（工数）を見積る。
 必要な手順・体制・要員計画や、リスクへの影響なども検討する。
 大規模な変更は、プロジェクト計画の変更の必要性の有無も判断する。
※ プロジェクトの終盤に発生した変更は、成果物の修正による手戻りが多く、影響
度が大きい
影響度分析
変更要求は必ず公式な手順で受付け、影響度を分析の上、変更可否
を判断する。
変更の実施

変更管理の重要成功要因
変更要求の受付
変更可否の判断
影響度分析
変更の実施
変更管理手順や
管理の仕組みを
定義している
公式の意思決定
の場（プロセス）
が事前に設定さ
れ、関係者の合
意を得ている
変更管理のため
のツールが用意
されている
（例）変更案件がＤＢ/プログ
ラムなどに与える影響範囲
の調査ツール
変更に関する情
報（要求、影響、
実施状況等）が
一元管理され、
関係者と共有化
されている
変更対応のため
の余裕コストが
確保されている

変更の多発を抑え込む対策
多少の変更はやむを得ない。しかし、
多発はプロジェクトを混乱に！
詳細
設計
・・・
基本
設計
要件
定義
要件凍結仕様凍結
変更管理
要件定義、設計
の品質を高める
プロジェクト目的・目標と
の整合性を重要視して、
変更可否を決定する
要件/仕様凍結
後は、必ず変更
管理手順に基づ
き運営する
プロジェクトに変更が与
える影響（ある時点から
コスト追加になること）を
ユーザにもよく説明する
変更要求
変更要求
変更要求

プロジェクトとして一つのチームになる
事業部門
プロジェクトを成功させるためには、発注側（事業部門、情報シス
テム部門）、受注側（開発部門）で信頼関係を築き、一つのチーム
となってプロジェクトを進めることが必須。その要がＰＭ。
発注側
受注側
情報システム
部門
開発部門

プロジェクト・マネジャーとして何を磨くか

変革を達成
現状の維持
出来事／事象
人の持つ
最大の力は
選択の力
成長に対して真摯な態度とは
オープンで創造的、積極的、粘り強い行動
機会（チャンス）と考える
現状の枠内で安全な行動、抵抗
どうすれば良いかわからない
リーダーシップ
リスクを冒すことで
成長できる
※ニュージーランド企業である
ＩＡＳラーニング・グループの考え方を参照。

プロジェクトで構成される組織
機構、規範、機能の面から
組織を捉える伝統的な組
織論
• 権限、責任、専門分業、ライン、
スタッフなどの機能規定
• 命令の一元化、階層、秩序、
調整などの運用ルール
組織は複数の個人が協働
する体系
• 人間は自由意志によって行動する。
• 個人では目標を達成できないので、
組織を作り、目標を達成する。
※チェスター・バーナードの「行動科学的組織論」の考え方を参照。
 目的を共有すること
 目的を実現しようとする協働意欲を持つこと
 協働のためのコミュニケーションがあること
プロジェクトに適した組織

ファシリテーション能力を磨く
 目的を共有すること
 目的を実現しようとする協働意欲を持つこと
 協働のためのコミュニケーションがあること
プロジェクト目的を
説明し、周知する
プロジェクトに置き換えると・・・・。
話し合いの場を
作り、メンバーの
認識を一致させる
重要なステーク
・ホルダーと緊密な
コミュニケーションを
図る
ファシリテーションのスキルを利用し、実現する

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

（続）Itプロジェクトマネジメント成功のための勘どころ 20140318

Recomendados

Recomendados

Mais conteúdo relacionado

Mais procurados

Mais procurados (20)

Destaque

Destaque (20)

Semelhante a （続）Itプロジェクトマネジメント成功のための勘どころ 20140318

Semelhante a （続）Itプロジェクトマネジメント成功のための勘どころ 20140318 (20)

Último

Último (8)

（続）Itプロジェクトマネジメント成功のための勘どころ 20140318