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

なぜリスクマネジメントは形骸化してしまうのか？

2017年 7月 9日

株式会社アイ・ティ・イノベーションシニア・コンサルタント工藤武久

ＰＭＩ日本フォーラム２０１７

～実効性のあるリスクマネジメント定着化についての一考察～

Copyright (C) IT innovation,Inc. All rights reserved. 2

目次

1.自己紹介

2.プロジェクトの成功確率と失敗原因

3.プロジェクト・リスクとは？ 4.なぜリスクマネジメントは形骸化してしまうのか？

～リスクマネジメントに関する７つの誤解～

5.プラスの影響を与えるリスクを無視して良いか？

6.まとめ

http://www.it-innovation.co.jp/index.html


１．自己紹介

略歴 – メーカー系のシステム子会社にて、主に官公庁向け大規模システム開発プロジェクトに、ＳＥ、ＰＭとして携わる。プロジェクトの立ち上げから運用保守フェーズに至るまで、システム開発プロジェクトのマネジメントについて幅広い実務経験を重ねる。

– ２００７年より株式会社アイ・ティ・イノベーションにおいて、プロジェクトマネジメント支援のコンサルティングを手がける。

主な取得資格 – 情報処理技術者試験（プロジェクトマネージャ、システム監査、システムアナリスト、情報セキュリティ、データベース他）

– ベンダ系資格（マイクロソフト認定技術者、オラクルマスター、 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)

発注側

受注側

ＩＴ構想・企画

要件定義

ユーザーテスト移

行・切替

運用

やりたいことが曖昧な企画書。どのようなビジネス価値を実現するのか、“軸”がない。

ユーザーから大量の要件。 “軸”がないため絞り込みも凍結も進まず。

無理やり設計進めるも、要件変更頻発。余裕のない計画の中で品質が犠牲に。

運用環境や管理体制に不備。実現効果は闇の中。

設計

構築

テスト

品質の悪さが露呈。結局大幅な延期に。

新システムを利用して業務を遂行するための準備（意識改革含む）が不十分で、使ってもらえない。

失敗するプロジェクトは、同じような失敗を繰り返している（ように見える）



2.2 プロジェクト失敗の原因 (2/3) SEC BOOKS：ユーザのための要件定義ガイド～要求を明確にするための勘どころ～より

（出典）日本情報システム・ユーザ協会「企業IT動向調査2016」をもとに加筆

工程遅延理由分析

上流が大事だとわかっているのに、同じ失敗を繰り返すのは？⇒リスクマネジメントが出来ていないから！



2.2 プロジェクト失敗の原因 (3/3)

＜プロジェクトの特徴＞ •目的、範囲、成果物、達成目標が明確である •期間が限定されている •全く同じものは存在しない（独自の成果物、その創出プロセス、実行体制、環境･･･） •実現過程は不確実で、段階的な詳細化アプローチをとる •権限を委譲されたプロジェクトマネージャが指揮する

プロジェクトには不確実性が伴うもの！その不確実性（リスク）をコントロールして、成功に導くのがプロジェクトマネジメントの役割

それがわかっているのに、同じ失敗を繰り返すのは、

リスクマネジメントが出来ていないと言わざるを得ない！



1.自己紹介





6.まとめ



３.1 プロジェクトにおける問題とは何か？

プロジェクトにおける問題とは、プロジェクト計画と現状とのギャップである！

▲ 現時点（時間） →

←

（

成果物出来高

）

終了開始

完成予定＝プロジェクト計画

実績

プロジェクト目標

問題ギャップ＝Ａ

Ｂ

プロジェクト終了時点でプロジェクトにおける問題が無くなっていれば、プロジェクトは成功といえる！



３.2 プロジェクト・リスクとは何か？

▲ ▲ 現時点リスク発生時期（未来＝不確実）（時間） →

←

（

成果物出来高

）

マイナスの影響

終了開始

完成プラスの影響

予定＝プロジェクト計画

実績


リスク（事象、状態）

リスク(Risk). もし発生すれば、プロジェクト目標にプラスあるいはマイナスの影響を及ぼす、不確実な事象あるいは状態

【出典】PMI『 PMBOK®ガイド第5版』

リスクが顕在化すると、プロジェクトにおける問題が生じる。リスクをマネジメントすることで、プロジェクトを成功に導ける！



３.3 プロジェクト・リスクの具体例

想定リスク予防対策トリガーポイント発生時対策 1 新規顧客のため、

成果物レビューに想定以上の時間がかかり、進捗遅延が発生する

① 設計工程の早期段階で、数機能分の先行レビューを実施し、顧客の対応を確認する ② 顧客レビューや受入テストなど顧客が関連するタスクは出来る限り余裕のあるスケジュールとする

先行レビューが予定より、２倍以上の期間を要した場合

顧客レビューに時間がかかる原因を分析し、成果物記載方法の見直し、または、レビュー効率化策を顧客と調整

2 要件の難易度が高いため、基本設計品質が確保できず、システムテストで設計バグが多発する

① 基本設計のレビュー後に、主要機能のウォークスルーを実施する ② システムテスト後の受入テスト前に２週間のスケジュール予備を設けるよう顧客と合意する

システムテスト開始後に２０件以上の設計バグが検出された場合

スケジュール予備期間に設計バグ対策を実施。予備期間内に対応が困難な質・量の設計バグが検出された場合は、リリース延期を顧客と調整

3 スケジュール制約が強いことから、要件定義不十分のまま基本設計に着手することで、基本設計が停滞する

① 要件定義完了基準を制定し、基準をクリアしない場合は基本設計に着手しないことを顧客と合意する ② 要件定義開始後１ヶ月、完了前２週間にチェックポイントを設け、リスク顕在化の傾向が無いか評価する

左記②のチェックポイントでリスク顕在化の傾向が明確と判断された場合

プロジェクトを中断し、問題の原因を分析し、要件定義の見直しを含めたプロジェクト再計画を行うことを顧客と調整

プロジェクトの特性に基づき、プロジェクト目標に対してどんな影響が想定されるかを具体的にあげる（過去の失敗事例を参考に）

リスクが顕在化したと判断する基準（トリガーポイント）をあらかじめ規定リスクの顕在化＝プロジェクトにおける問題の発生



012345統合

スコープ

タイム

コスト

品質人的資源

コミュニケーショ

ン

リスク

調達

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 工藤武久（ [email protected] ）『新感覚！プロジェクトマネジメント』ブログ : http://www.it-innovation.co.jp/blog/cat_blog03/ twitter: https://twitter.com/iti_kudot


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

Business

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

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

Business

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

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

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