PMI日本フォーラム2017 講演資料アイ・ティ・イノベーション　工藤武久

なぜリスクマネジメントは
形骸化してしまうのか？
2017年 7月 9日
株式会社アイ・ティ・イノベーション
シニア・コンサルタント工藤武久
ＰＭＩ日本フォーラム２０１７
～実効性のあるリスクマネジメント
定着化についての一考察～

Copyright (C) IT innovation,Inc. All rights reserved. 2
目次
1.自己紹介
2.プロジェクトの成功確率と失敗原因
3.プロジェクト・リスクとは？
4.なぜリスクマネジメントは形骸化してしまうのか？
～リスクマネジメントに関する７つの誤解～
5.プラスの影響を与えるリスクを無視して良いか？
6.まとめ

１．自己紹介
 略歴
– メーカー系のシステム子会社にて、主に官公庁向け大規模システム
開発プロジェクトに、ＳＥ、ＰＭとして携わる。プロジェクトの立ち
上げから運用保守フェーズに至るまで、システム開発プロジェクトの
マネジメントについて幅広い実務経験を重ねる。
– ２００７年より株式会社アイ・ティ・イノベーションにおいて、
プロジェクトマネジメント支援のコンサルティングを手がける。
 主な取得資格
– 情報処理技術者試験（プロジェクトマネージャ、システム監査、
システムアナリスト、情報セキュリティ、データベース他）
– ベンダ系資格（マイクロソフト認定技術者、オラクルマスター、
SAP認定アプリケーションコンサルタント）
– プロジェクトマネジメントプロフェッショナル（ＰＭＰ）
 ブログ執筆『新感覚！プロジェクトマネジメント』
http://www.it-innovation.co.jp/blog/cat_blog03/
シニア・コンサルタント工藤武久（くどうたけひさ）

1.自己紹介
6.まとめ

26.7 31.1
75.0
73.3 68.9
25.0
0%
20%
40%
60%
80%
100%
2003年 2008年 2014年
失敗
成功
？
2.1 プロジェクトの成功確率は上がってきているのか？ (1/3)
日経コンピュータ 2008年12月1日号、
2014年10月14日号より
プロジェクトの成功確率
システム開発プロジェクトの現場にいると
成功確率がＵＰしている実感はありません！

11.1 19.7 21.9
36.9
35.7 35.8
52.1 44.5 42.3
0%
20%
40%
60%
80%
100%
04～08年度 09～14年度 15年度
予定より遅延
ある程度は予定通り完了
予定通り完了
8.2 14.1 14.2
61.8 56.7 59.6
30.2 29.2 26.1
0%
20%
40%
60%
80%
100%
04～08年度 09～14年度 15年度
満足ある程度は満足不満
システム開発工期遵守状況システム開発品質状況
SEC BOOKS：ユーザのための要件定義ガイド～要求を明確にするための勘どころ～より
（出典）日本情報システム・ユーザ協会「企業IT動向調査2016」をもとに加筆
（システム規模：500人月以上）
ユーザからの評価は、それほど高く無い！
ほぼ横ばい（特に大規模システム）

 発注側はシステム化目的の明確化への努力が必要
 受注側は顧客への貢献度を評価軸に加える必要がある
 成功の定義（プロジェクト目標）について、
発注側、受注側で合意する必要がある！
プロジェクト成功確率について議論するには、
「成功の定義」の標準化が不可欠！
 受注側視点 ⇒ Ｑ（品質）Ｃ（コスト）Ｄ（納期）の達成
 発注側視点 ⇒ システム化目的の達成という評価軸も必要
「プロジェクトの成功」について、
受注側と発注側でとらえ方が異なる？

2.2 プロジェクト失敗の原因 (1/3)
発
注
側
受
注
側
Ｉ
Ｔ
構
想
・企
画
要
件
定
義
ユ
ー
ザ
ー
テ
ス
ト移
行
・切
替
運
用
やりたいことが曖昧な企画書。
どのようなビジネス価値を実現
するのか、“軸”がない。
ユーザーから大量の要件。
“軸”がないため絞り込みも
凍結も進まず。
無理やり設計進めるも、要件変更頻発。
余裕のない計画の中で品質が犠牲に。
運用環境や管理体制に不備。
実現効果は闇の中。
設
計
構
築
テ
ス
ト品質の悪さが露呈。
結局大幅な延期に。
新システムを利用して業務を遂行
するための準備（意識改革含む）が
不十分で、使ってもらえない。
失敗するプロジェクトは、同じような失敗を
繰り返している（ように見える）

SEC BOOKS：ユーザのための要件定義ガイド～要求を明確にするための勘どころ～より
（出典）日本情報システム・ユーザ協会「企業IT動向調査2016」をもとに加筆
工程遅延理由分析
上流が大事だとわかっているのに、同じ失敗を繰り返
すのは？⇒リスクマネジメントが出来ていないから！

＜プロジェクトの特徴＞
•目的、範囲、成果物、達成目標が明確である
•期間が限定されている
•全く同じものは存在しない
（独自の成果物、その創出プロセス、実行体制、環境･･･）
•実現過程は不確実で、段階的な詳細化アプローチをとる
•権限を委譲されたプロジェクトマネージャが指揮する
プロジェクトには不確実性が伴うもの！
その不確実性（リスク）をコントロールして、
成功に導くのがプロジェクトマネジメントの役割
それがわかっているのに、
同じ失敗を繰り返すのは、
リスクマネジメントが出来て
いないと言わざるを得ない！

1.自己紹介
6.まとめ

３.1 プロジェクトにおける問題とは何か？
プロジェクトにおける問題とは、
プロジェクト計画と現状とのギャップである！
▲
現時点
（時間） →
←
（
成
果
物
出
来
高
）
終了開始
完成
予定＝プロジェクト計画
実績
プロジェクト
目標
問題ギャップ＝
Ａ
Ｂ
プロジェクト終了時点でプロジェクトにおける問題が
無くなっていれば、プロジェクトは成功といえる！

３.2 プロジェクト・リスクとは何か？
▲ ▲
現時点リスク発生時期（未来＝不確実）
（時間） →
←
（
成
果
物
出
来
高
）
マイナスの影響
終了開始
完成
プラスの影響
実績
プロジェクト
目標
リスク
（事象、状態）
リスク(Risk). もし発生すれば、プロジェクト目標にプラスあるいは
マイナスの影響を及ぼす、不確実な事象あるいは状態
【出典】PMI『 PMBOK®ガイド第5版』
リスクが顕在化すると、プロジェクトにおける問題が生じる。
リスクをマネジメントすることで、プロジェクトを成功に導ける！

３.3 プロジェクト・リスクの具体例
想定リスク予防対策トリガーポイント発生時対策
1 新規顧客のため、
成果物レビューに
想定以上の時間が
かかり、進捗遅延
が発生する
① 設計工程の早期段階で、数機能
分の先行レビューを実施し、顧客の
対応を確認する
② 顧客レビューや受入テストなど
顧客が関連するタスクは出来る限り
余裕のあるスケジュールとする
先行レビューが予
定より、２倍以上
の期間を要した場
合
顧客レビューに時間がか
かる原因を分析し、成果
物記載方法の見直し、ま
たは、レビュー効率化策
を顧客と調整
2 要件の難易度が高
いため、基本設計
品質が確保できず、
システムテストで
設計バグが多発す
る
① 基本設計のレビュー後に、主要
機能のウォークスルーを実施する
② システムテスト後の受入テスト
前に２週間のスケジュール予備を設
けるよう顧客と合意する
システムテスト開
始後に２０件以上
の設計バグが検出
された場合
スケジュール予備期間に
設計バグ対策を実施。
予備期間内に対応が困難
な質・量の設計バグが検
出された場合は、リリー
ス延期を顧客と調整
3 スケジュール制約
が強いことから、
要件定義不十分の
まま基本設計に着
手することで、基
本設計が停滞する
① 要件定義完了基準を制定し、基
準をクリアしない場合は基本設計に
着手しないことを顧客と合意する
② 要件定義開始後１ヶ月、完了前
２週間にチェックポイントを設け、
リスク顕在化の傾向が無いか評価す
る
左記②のチェック
ポイントでリスク
顕在化の傾向が明
確と判断された場
合
プロジェクトを中断し、
問題の原因を分析し、要
件定義の見直しを含めた
プロジェクト再計画を行
うことを顧客と調整
プロジェクトの特性に基づき、
プロジェクト目標に対してどんな影響
が想定されるかを具体的にあげる
（過去の失敗事例を参考に）
リスクが顕在化したと判断する基準
（トリガーポイント）をあらかじめ規定
リスクの顕在化
＝プロジェクトにおける問題の発生

0
1
2
3
4
5
統合
スコープ
タイム
コスト
品質人的資源
コミュニケーショ
ン
リスク
調達
6月
9月
12月
１２３４５
＜リスク評価＞
低高
３.4 個別リスクとプロジェクト全体リスク (1/2)
プロジェクト全体リスクとは？
最終的にどうなりそう？成功？失敗？どの程度？許容範囲内か？
「プロジェクト全体リスク」の評価例
参考文献
・Project Management Institute, Inc.(2010)
『プロジェクト・リスクマネジメント実務標準』ＰＭＩ日本支部
･トム・デマルコ、ティモシー・リスター、伊豆原弓訳(2003)
『熊とワルツを~リスクを愉しむプロジェクト管理』日経ＢＰ社
・トム・デマルコ、伊豆原弓訳(2001)
『ゆとりの法則誰も書かなかったプロジェクト管理の誤解』
日経ＢＰ社
「リスクには全体リスクと部分リスク
があり、それぞれ扱い方が異なる」
By トム・デマルコ
プロジェクトの最終結果そのものの不確実性である！
 「個別リスク」への対応戦略
⇒ 「回避」「転嫁」「軽減」「受容」など
 「プロジェクト全体リスク」への対応戦略
⇒ 「プロジェクト中止」「再計画」など

３.4 個別リスクとプロジェクト全体リスク (2/2)
▲
現時点（時間） →
←
（
成
果
物
出
来
高
）
終了開始
完成
実績
不確
実性
プロジェクト
全体リスク
＝
プロジェクト
最終結果の振れ幅
プロジェクト
目標
プロジェクトの最終結果そのものの不確実性 ⇒ 振れ幅
プロジェクトマネージャはプロジェクト最終結果を見据えて、
プロジェクトをコントロール（意志決定）する必要がある！

３.5 リスク管理手順
リスク一覧表
スケジュール表など
追記
予防対策を
タスク化
③リスクが顕
在化した場合
問題課題リスト
リスク一覧表
④リスクを再分析し、
リスク一覧表を見直す
問題課題管理へ
リスク一覧表
追記
予防対策をタスク化
進捗会議にて報告
進捗会議にて報告
開発工程毎の
レビューにて報告
作成
予防対策をタスク化
発生時対策を
タスク化
プロジェクト全体リスク
の評価
（プロジェクト着手可否判断）
重点監視対象とする
個別リスクの洗い出し
プロジェクト全体リスク
の再評価
（プロジェクト継続可否判断）
重点監視とする
個別リスクの見直し
重点監視対象とした
個別リスクのモニタリング
プロジェクト実行時IT構想・企画、
プロジェクト
計画時
追記
システム企画書
プロジェクト計画書
①プロジェクト目標達
成に向けたリスク分析、
リスク一覧作成
②新たなリス
クが想定され
た場合
各工程完了時、または、
ステアリングコミッティ
開催時

1.自己紹介
6.まとめ

4.1 リスクマネジマントの形骸化事例
① プロジェクト開始時に
リスク一覧を作成するものの、
プロジェクト実行時には見向き
もされない！
② ステアリングコミッティ
でのリスク状況報告は、
当たり障り無い報告でごまかし！
または、
既に顕在化している
問題をリスクとして報告！
④ リスク一覧を定期的に
更新しているが、進捗遅延、
仕様変更多発など既に発生して
いる問題状況を記載してる。
つまり、
問題発生状況の棚卸リスト
になっている！
③ 数えきれないほどリスクが
あげられ、プロジェクト実行時
には全部見切れずに結局放置！
⑤ リスク一覧に記載された
予防対策が実施されず、
リスク棚卸のたびに
「やんなきゃね。」
で終わってしまう。
確かにリスク一覧を作成、定期的に棚卸、リスク状況を報告、
・・・してはいるけど、
本当の意味でのリスクマネジメントになっていない！

実は、リスクについて、わかっているようでわかってない！
『リスクマネジメントに関する７つの誤解』
4.2 リスクマネジマントに関する７つの誤解
1.「リスクは失敗の卵」という誤解
2.「リスクは漠然とした不安」という誤解
3.「リスクは漏れなく洗い出し、管理すべき」という誤解
4.「プロジェクト全体リスクと個別リスクの関係」への誤解
5.「プロジェクト目標とリスクの関係」への誤解
6.「発注側と受注側のリスク認識は同じはず」という誤解
7.「進捗・品質・コスト管理とリスク管理の関係」への誤解

4.3 「リスクは失敗の卵」という誤解
リスクの顕在化
プロジェクト計画書
タスク追加
計画の見直し
プロジェクトマネジメントの失敗では？
プロジェクト計画の誤りでは？
プロジェクト計画書の改善が先決となり、
効果的なリスクマネジメントの充実につながらない
プロジェクトには不確実性があることの再認識！
⇒最初から完璧な計画はできない！（段階的詳細化）
 実行段階で、リスクをつぶしながら計画を精緻化
 精緻化しきれていない部分は、リスク監視が必要
リスクの洗い出し
問題の発生

4.4 「リスクは漠然とした不安」という誤解
なんらかの原因で進捗が遅れるかもしれない！
なんらかの原因で品質が悪くなるかもしれない！
なんらかの原因で予算超過するかもしれない！
リスク予防対策発生時対策
進捗遅延リスク週次進捗で進捗モニタリング体制強化、スケジュール見直し
品質劣化リスク品質指標設定、定量的管理品質向上策の追加
予算超過リスク月次でコスト予実管理バッファ切り崩し、予算追加
どれだけあげれば十分？優先順位は？
具体的な対策は？通常のＱＣＤ管理と何か違う？
 プロジェクトの特性に応じたリスクを取り上げる
 過去の失敗事例をもとに、リアルなリスク顕在化
シナリオを想定し、具体的なリスク対応策を検討

4.5 「リスクは漏れなく洗い出し、管理すべき」という誤解
 継続的に監視するリスクは、プロジェクト目標への
影響度などで絞り込む！（目線を高くする）
 プロジェクト固有のリスク、過去の失敗事例に
基づくリアルなリスクを中心にピックアップ！
想定されるリスク
は全て洗い出しな
さい！
大分類小分類
ビジネス・リスク・事業合併／撤退
・法制度変更・自然災害・・・
顧客特性・要件定義へのユーザ参画度
・顧客キーマンの継続的参画・・・
技術／製品リスク・パッケージのFit&Gap
・セキュリティ／脆弱性・・・
・・・・・・
どれだけあげれば十分？優先順位は？
監視対象のリスクの数が多いと管理しきれない！
結局、ＰＭ、ＰＭＯのさじ加減（属人的）管理となる

4.6 「プロジェクト全体リスクと個別リスクの関係」への誤解
 プロジェクト全体リスクと個別リスクは、
明確に分けて状態監視、報告する！
仕様変更が多発して、進捗遅延が起き
始めているため、このプロジェクトは
失敗するリスクが高まってきた！
仕様変更多発
個別リスクの顕在化
プロジェクト最終結果への
個別リスクの予防対策は機能していたのか？
⇒ 個別リスクへの対応がうまくいっていないことを
プロジェクト全体リスクの状況悪化にすり替え！

4.7 「プロジェクト目標とリスクの関係」への誤解
 システム化の目的、プロジェクト目標の明確化は、
実効性のあるリスクマネジメントのためにも重要！
終了開始
完成
プラスの影響
リスク
ＢＰＲ？
作業効率化？
ＥＯＬ対応？
プロジェクト目標が不明確だと、顕在化時の影響も不明確！
⇒どの個別リスクを重点監視すべきか判断できない！
プロジェクト目標が何で
あれ、監視すべきリスク
に変わりは無いはず。

4.8 「発注側と受注側のリスク認識は同じはず」という誤解
 立場の違いを理解し、お互いに歩み寄る姿勢が大事
 発注側、受注側がそれぞれでリスク管理を行い、
共有できるリスクを選択して、協力して対応する！
・予算超過リスク
・品質劣化リスク
・納期遅延リスク
・・・
・損益悪化リスク
・過剰管理リスク
・・・
受注側リスク認識発注側リスク認識
対立関係
Win-Winが望ましいが、対立関係となることも多い
「発注側から見た成功」と「受注側から見た成功」の認識GAP
発注側も受注側も一体となって、
全てのリスクに対応して行こう。

プロジェクト全体のマネジメント
4.9 「進捗・品質・コスト管理とリスク管理の関係」への誤解
 通常のQCD管理でカバーできるものはリスク一覧から除外
 プロジェクト固有のリスク、過去の失敗事例の再発防止に
集中することで、実効性のあるリスクマネジメントになる！
プロジェクト全体のマネジメント
≒ リスクマネジメント
Ｑ（品質）
マネジメント
Ｃ（コスト）
マネジメント
Ｄ（進捗）
マネジメント
Ｑ（品質）
マネジメント
リスク
マネジメント
Ｃ（コスト）
マネジメント
Ｄ（進捗）
マネジメント
ＱＣＤマネジメントは
リスクマネジメントに包まれる！
品質管理＝障害多発リスクへの対応策
進捗管理＝進捗遅延リスクへの対応策
コスト管理＝予算超過リスクへの対応策
ＱＣＤ管理と
リスク管理は
同列でしょ？

1.自己紹介
6.まとめ

5.1 プラスの影響を与えるリスクを無視してよいか？ (1/2)
▲ ▲
現時点リスク発生時期（未来＝不確実）
（時間） →
←
（
成
果
物
出
来
高
）
終了開始
完成
プラスの影響
実績
プロジェクト
目標
リスク
（事象、状態）
個別リスクはプロジェクト目標に対してマイナスの影響しか
及ぼさないと考えると、「個別リスクを全て無くさないと
プロジェクト目標が達成できない？」ということになる！

▲
現時点（時間） →
←
（
成
果
物
出
来
高
）
終了開始
完成
実績
不確
実性
プロジェクト
全体リスク
＝
プロジェクト
最終結果の振れ幅
プロジェクト
目標
プロジェクト最終結果の振れ幅がマイナス方向だけ
と考えると、プロジェクト目標の達成は至難の業！
マイナスの影響を及ぼすリスク（脅威）とプラスの影響を
及ぼすリスク（好機）をバランス良く取り扱おう！
5.1 プラスの影響を与えるリスクを無視してよいか？ (2/2)

5.2 プラスの影響を与えるリスクの具体例
プロジェクト目標達成に向けたプロジェクト推進施策は、
プラスの影響を与えるリスクへの対応計画である！
××システム開発プロジェクト計画書
目次
１. プロジェクト目的・範囲
２. プロジェクト制約事項・前提事項
３. プロジェクト全体作業フロー
４. プロジェクト成果物ドキュメントリスト
５. プロジェクト標準
６. プロジェクト推進施策
７. プロジェクトスケジュール
８. マイルストーンと完了基準
９. プロジェクト必要資源
１０. プロジェクト体制
１１. プロジェクトコスト・要員山積み
１２. プロジェクトリスク評価
１３. トレーニング計画
１４. 品質目標
１５. プロジェクト・チーム目標
１６. 実績データ収集計画
１７. 保守引継ぎ計画
１８. プロジェクト管理方針
１８.１コミュニケーション管理方針
１８.２進捗管理方針
１８.３構成管理方針
１８.４変更管理方針
１８.５品質管理方針
１８.６問題・課題管理方針
１８.７リスク管理方針
１８.６外部委託先管理方針
・・・
添付資料
添付１マスタースケジュール
添付× リスク一覧表
プラスの影響を及ぼす
リスクの強化策例
 機能共通化による
開発量削減
 過去成果物流用による
生産性向上
 開発支援ツール活用
による生産性向上
・・・
※「好機」が顕在化した場合はコストダウンにつながるので計画に織り込みやすいが、
「脅威」が顕在化した場合はコストアップにつながるので計画に織り込みづらいことに注意！

1.自己紹介
6.まとめ

6. まとめ
プロジェクト固有のリスクと過去の失敗事例
の再発防止に集中することで、実効性のある
リスクマネジメントを定着化させよう！
 プロジェクト成功の定義は発注側と受注側でずれている
 同じ失敗を繰り返すのはリスクマネジメントが出来ていないため
 個別リスクは、もし発生すればプロジェクト目標にプラスあるいは
マイナスの影響を及ぼす不確実な事象あるいは状態
 プロジェクト全体リスクは、プロジェクトの最終結果そのものの不確実性
 『リスクマネジメントに関する７つの誤解』が形骸化を招く
 マイナスの影響を及ぼすリスク（脅威）とプラスの影響を及ぼすリスク
（好機）をバランス良く取り扱う

（ご参考）
アイ・ティ・イノベーション概要

会社名株式会社アイ・ティ・イノベーション（IT innovation, Inc.）
所在地〒108-0075 東京都港区港南4-1-8 リバージュ品川5階
設立年月日 1998年7月1日
資本金 1億円
代表取締役林衛
従業員数 44名
売上高 10.5億円（2016年6月期）
事業内容 1.ビジョン・戦略策定支援
・ビジョンの策定支援
・IT事業戦略・中期計画策定支援
・人材戦略／人材育成のための仕組み、見える化支援
2.ITアーキテクチャ支援
・方法論の導入と定着化支援
・ITアーキテクチャ設計・評価支援
・ITアーキテクト人財の育成支援
3.BA（ビジネスアナリシス）支援
・IT構想・企画書作成支援
・IT構想・企画立案人材育成支援
4.PM（プロジェクト・マネジメント）支援
・プロジェクトに対するマネジメント実行支援
・プロジェクトマネジメント人材の育成支援
5.ビッグデータ・AIイノベーション支援
・インドのITラボと連携し最新技術で、ビッグデータ・AIシステムの設計構築を行う
・データアナリティックス
・画像分析（コンピュータビジョン）
・自然言語処理（NLP）／機械学習（Machine Learning）
・IoTビッグデータ基盤構築など
・ホームページ
http://www.it-innovation.co.jp/
・ITプロジェクトの現場で活躍するPMの為のメルマガ
【ザ・グローバル・イノベーターズ】
メルマガ登録 https://s360.jp/form/32135-22/
バックナンバー http://it-innovation.hateblo.jp/
（ご参考）アイ・ティ・イノベーション会社概要

（ご参考）方法論・シリーズについて
『』シリーズは、長年アイ・ティ・イノベーションが実務を通して蓄積した
ノウハウを体系立て、そして実用的にまとめた方法論です。企画、プロジェクトマネジメン
ト、ＭＤＭ（Master Data Management）、見積り、開発、テスト、運用、人材に関する８つ
の方法論があります。 ※ （モーダス）＝ラテン語で「方法(論)」の意味。
システムの開発規模や工数を見積るためのフレームワークを提供する方法論です。
（見積り方法論）
ＩＴにかかわる人材の育成や能力開発、人材管理のための考え方やプロセスを体系的にまとめた方法論です。
（人材戦略・人材育成方法論）
システム開発プロジェクトをマネジメントするための考え方やプロセスを体系的にまとめた方法論です。
（プロジェクトマネジメント方法論）
システムを構想・企画するための考え方やプロセスを体系的にまとめた方法論です。
（IT構想・企画方法論）
システムによるサービス提供を維持・管理していくための考え方やプロセスをまとめた方法論です。
（SLA・SLM方法論）
（システム開発方法論）
分析、設計、プログラミング、テスト、移行といったシステムの開発工程全般について体系的にまとめた方法論です。
テストの計画、設計、準備、実施、およびマネジメントのための方法論です。
（テスト方法論）
企業システムにおけるMDM（Master Data Management）を構築するための考え方やプロセスをまとめた方法論です。
（MDM設計構築方法論）

（ご参考）方法論・シリーズの体系
要件
定義
外部
設計
内部
設計
プログラ
ミング
単体
テスト
結合
テスト
システム
テスト
運用テスト
移行
立上げ計画実行、監視コントロール
（進捗管理、品質管理、変更管理、リスク管理、構成管理、外部委託管理）
終結
IT構想・企画運用・保守
(運用、保守、ｻｰﾋﾞｽﾚﾍﾞﾙ)
人材育成計画、トレーニング、評価、改善
戦略・企画プロセス
人材育成プロセス
方法論－Modusシリーズ
情報システムマネジメントプロセス
プロジェクトマネジメントプロセス
経営戦略
事業戦略
IT戦略
BABOK®に準拠
PMBOK®に準拠
（見積り方法論）
（人材戦略・人材育成方法論）
（プロジェクトマネジメント方法論）
（IT構想・企画方法論）（SLA･SLM方法論）
（システム開発方法論）
（テスト方法論）
ＭＤＭ（Master Data Management）構築
（MDM設計構築方法論）
システム開発プロセス

ご清聴ありがとうございました！
株式会社アイ･ティ･イノベーション
〒108-0075 東京都港区港南4-1-8 リバージュ品川5F
Tel： 03-5783-2811 / Fax： 03-5783-2813
URL： http://www.it-innovation.co.jp
工藤武久（ kudot@it-innovation.co.jp ）
『新感覚！プロジェクトマネジメント』
ブログ : http://www.it-innovation.co.jp/blog/cat_blog03/
twitter: https://twitter.com/iti_kudot

PMI日本フォーラム2017 講演資料アイ・ティ・イノベーション　工藤武久

Recommended

Recommended

More Related Content

Similar to PMI日本フォーラム2017 講演資料アイ・ティ・イノベーション　工藤武久

Similar to PMI日本フォーラム2017 講演資料アイ・ティ・イノベーション　工藤武久 (20)

Recently uploaded

Recently uploaded (8)