プロジェクトマネジメント - 一般社団法人 PMI日本 …...2 目次 •第1部...

0

アジャイルプロジェクトマネジメント意識調査報告 2016

一般社団法人 PMI日本支部アジャイルプロジェクトマネジメント研究会 2016年11月

©PMI Japan Chapter, 2016. Copyright and all rights reserved.

1

はじめに

本資料は、2016年2月9日～2月29日にPMI日本支部アジャイルプロジェクトマネ

ジメント研究会が実施したアンケート調査「2016年度アジャイルプロジェクトの実

態」の結果で、2016年7月10日に開催された PMI日本フォーラム2日目の H-6

セッションで発表した内容に加筆修正を加えたものです。日本国内におけるア

ジャイル推進の参考資料となるよう、一般に公開いたします。

調査にご協力いただいた皆さま、ありがとうございました。ここに重ねてお礼申し

上げます。

2016年11月

一般社団法人 PMI日本支部

アジャイルプロジェクトマネジメント研究会


2

目次 • 第1部結果報告編

– 調査概要

– 結果概要（全体）

– 結果分析

– 結果報告（考察）

• 第2部提言編

– 提言その１

•アジャイルの基本的な考えかた（マインドセット）を正しく理解しよう

– 提言その２

•経験者の知恵を生かして組織へアジャイルを広めよう


アジャイルプロジェクトマネジメント意識調査報告 2016

PMI日本支部アジャイルプロジェクトマネジメント研究会


1. 結果報告編 A) 調査概要 B) 結果概要 C) 結果分析 D) 考察

2. 提言編 A) その1 B) その2

目次

©PMI Japan Chapter, 2016. Copyright and all rights reserved. 4

はじめに • 本資料では、2月9日-2月29日に実施されたアンケート調査「アジャイルプロジェクトの実態」の結果をご報告いたします。調査にご協力いただいた皆さま、ありがとうございました。

• アジャイル・プロジェクトマネジメント研究会では、アンケートの結果を活用し、今後アジャイルの活用に役立てるようなイベントを計画しています。

• Facebook公式ページ、PMI日本支部ホームページにて告知致しますので、ぜひ、ご参加ください。


アジャイルプロジェクトマネジメント意識調査報告

第1部結果報告編 PMI日本支部

アジャイルプロジェクトマネジメント研究会飯村北海


調査概要アジャイルプロジェクトマネジメント意識調査報告


調査概要 • 目的

–これからのビジネスやソーシャル活動におけるプロジェクトでは必須とされる「アジャイルプロジェクトマネジメント」の導入／展開を推進するための具体策を研究会で検討し、広く情報発信していく。

–上記目的を達成するため、プロジェクト関係者の視点でアジャイルプロジェクトの導入・展開時の関心事にフォーカスして実態を調査し分析した。


調査概要 • 調査対象

–プロジェクト・マネジャー、PMO、プロジェクト・スポンサーなどプロジェクト運営に関わる皆さま

主に • PMI日本支部会員 • 法人スポンサー • PMIに登録されているプロジェクトマネジメント関係者

• 回答数 185名


調査概要 • 調査内容

– 回答者の属性 • 性別、年齢、職種、所属企業の従業員数 • PMIとの関わり、PMI-ACP®に関する質問 • ソフトウェア開発の関わりなど

– アジャイルの導入状況

• 次ページ参照

– アジャイル未経験者に対する質問

– ソフトウェア以外への適用の可能性


これまでにあなた自身およびあなたが担当したアジャイル開発手法のﾌﾟﾛｼﾞｪｸﾄから代表的なものを1つ思い出して、以下の質問にご回答ください。

受験意向など

10

は今回新たに追加した質問項目

調査概要 • アジャイルの導入状況に関する質問

– アジャイルプロジェクトに対する質問 • PJ開始時期、期間、習熟度、発注／受注、開発領域、業種、部門、開発言語、役割、導入のきっかけ、

• アジャイルの形態（チーム規模、人数、イテレーション期間、プロセス／手法、プラクティス）

• PJに対する評価（期待、効果、メトリクス、ツール、予実対比）

• PJの成功／満足／活性度合い、ビジネス価値に関する質問

– アジャイルの一般的な意見 • 経験年数、メリット／デメリット等


結果概要（全体）アジャイルプロジェクトマネジメント意識調査報告


回答者の属性アジャイルプロジェクトマネジメント意識調査報告


結果概要（回答者属性）


166 18

性別

男性女性

1 5 23 32 53 37 21 12

年齢

20代 30-34 35-39 40-4445-49 50-54 55-59 60以上

11 17 41 18 98

従業員数

10人未満 10-100 100-500500-1000 1000以上

n=185

n=185

n=185 90%

10%

1% 3% 13%

17%

29% 20%

11% 7%

6% 9%

22%

10%

53%

14



9

0

1

2

2

2

7

8

10

14

31

31

67

その他 (具体的に)

財務／経理

営業

監査

マーケティング

人事／総務

経営

教育

研究／開発

コンサルティング

エンジニア

PMO

プロジェクト・マネジャー

職種

40

0

0

0

1

1

4

4

8

9

11

47

60

その他

法務

資材

購買

経理／財務

広報／宣伝

商品企画

営業／販売

総務／人事

経営企画

品質保証

製品開発

技術／研究

部門

10 0 0 0 0 1 1 1 2 3 3 3 4 6 6 8 9

128

その他石油/ガス

食品不動産

医療・福祉鉄鋼化学

公共インフラ自動車製薬通信教育建設

機械/金属金融

電気/電子サービス

ＩＴ

業種 n=185 n=185 n=185

15



20 111

54

わからないいいえはい

所属する企業はPMI日本支部法人スポンサーか？ n=185

17 5

162

上記以外 PMI本部会員のみ

日本支部会員 PMIおよびPMI日本支部に入会しているか？ n=184

9 26

122 27

PMP® 無受験予定なし

PMP® 無受験予定あり

PMP® 有他予定なし

PMP® 有他予定あり

PMP®認定資格 n=184

PMP®さえあれば良い？

PMP®資格者数：32,878/712,515 PMI-ACP®資格者数：15/10,708

(2016年1月時点、日本/世界)

16



96

88

知らない

知っている

PMP-ACP®認定資格の認知度

48% 52%

19 82 81

2

英語でも受験したい

日本語化されたら受験したい

受験したいとは思わない

既に資格を取得している

PMP-ACP®認定資格の受験意向

n=184

n=184

10%

45%

44%

1% 受験意向はある

17

PMI-ACP®資格試験について

PMP® 有 PMP® 無合計他の資格の受験予定

有無有無英語でも受験希望 10 4 5 0 19 日本語化されたら受験希望 11 58 12 1 82 受験したいとは思わない 4 60 9 8 81 既に取得している 2 0 0 0 2

合計 27 122 26 9 184



PMI-ACP®資格試験について

PMI-ACP®の認知合計

ありなし英語でも受験希望 13 6 19 日本語化されたら受験希望 42 40 82 受験したいとは思わない 32 49 81 既に取得している 1 1 2

資格を知らなかったけれども、日本語であれば受けたいと思っている人がいる

日本語になってさえいればPMPを持っていなくても資格を受けたいと思う人がいる

18



151人, 82%

33人, 18%

ソフトウェア開発に関係しているか

はいいいえ

ソフトウェア開発関係者（自社開発、発注者、受注者）あるいはステークホルダー（ユーザー、スポンサーなど）として関係している

まったく関係していない

n=184

55人,

77%

16人,

23%

2015年度

19

アジャイル全般アジャイルプロジェクトマネジメント意識調査報告


結果概要（アジャイル）


56人,

37%

16人,

11%

68人,

45%

10人,

7%

自部門でアジャイルを

導入しているか？

継続中やめた

未導入わからない

n=150

42人,

57%

32人,

43%

自身のアジャイル経験

ありなし

n=74

43人,

68%

20人,

32%

アジャイルを継続しているか？

はいいいえ

n=63

55人,

31%

16人,

9%

104

人,

58%

4人,

2%

2015年度

21

前職で経験あり、現職で経験ない場合

結果概要（情報収集）


32%

18% 37%

13%

100人未満 100-500人未満

500-1000人未満 1000人以上

16%

24%

13%

47%

100人未満 100-500人未満

500-1000人未満 1000人以上

25%

17%

11%

47%

100人未満 100-500人未満

500-1000人未満 1000人以上

11%

18%

19%

52%

100人未満 100-500人未満

500-1000人未満 1000人以上

アジャイル導入状況 2015

アジャイル導入状況 2016 n=106

n=175

導入経験あり導入経験なし

導入経験あり導入経験なし

今年度の回答者は

大規模企業で導入経験者が少ない

22



【継続中】

はいいいえ

【やめた】

はいいいえ

【未導入】

はいいいえ

「アジャイル開発」という言葉を知っていますか？

知っている 100%

知っている 100%

知っている 94%

n=140

23



【継続中】

はいいいえ

【やめた】

はいいいえ

【未導入】

はいいいえ

「アジャイルマニフェスト」という言葉を知っていますか？

知っている 71%

知っている 50%

知っている 34%

n=140

24



【継続中】

はいいいえ

【やめた】

はいいいえ

【未導入】

はいいいえ

「アジャイルプロジェクトマネジメント」という言葉を知っていますか？

知っている 73%

知っている 75%

知っている 63%

n=140

25



言葉【継続中】【やめた】【未導入】

アジャイル開発 100% 100% 94% アジャイルマニフェスト 71% 50% 34% アジャイルプロジェクトマネジメント 73% 75% 63%

アジャイルで開発する方法が

やっぱりまだ普及していないのでは？

アジャイルに関する言葉の知っている度合い

2015年度アンケート【継続中】【やめた】【未導入】


26



過去6ヶ月での自身の行動継続中やめた未導入研修／セミナーを受講した 50% 56% 29% イベントに参加した 36% 44% 15% 書籍を読んだ 61% 63% 24% ネット記事を読んだ 71% 81% 59% 特に何もしていない 9% 13% 26%

過去6ヶ月での周囲とへの行動継続中やめた未導入社内の同僚や部下と会話をした 77% 81% 46% 社内の上司と会話をした 46% 44% 21% 社内の他部門と会話をした 41% 44% 18% 社外の受注先と会話をした 34% 19% 12% 社外の発注先と会話をした 25% 31% 12% 社外の受・発注先以外の人と会話をした 32% 31% 22% 誰とも話をしていない 9% 19% 37%

経験がある群の方がアジャイルに関する行動を行っている

ネット記事は読んでも書籍は読まない

27

アジャイル導入状況アジャイルプロジェクトマネジメント意識調査報告


結果概要（導入状況）


0 15 16

10

わからない

2年以上前

1年から2年前

1年以内

PJ開始時期 n=41

5 3

1 4

12 14

2

今も継続中 24ヶ月以上

18ヶ月以上-24ヶ月未満 12ヶ月以上-18ヶ月未満

6ヶ月以上-12ヶ月未満 2ヶ月以上-6ヶ月未満

2ヶ月未満

PJ継続期間 n=41

7

11

23

4回目以上

2-3回目

はじめて

アジャイル習熟度 n=41

5 5

24 7

社内開発＋委託開発

委託（ベンダーへ）

受託（顧客から）

社内開発

PJタイプ n=41

29



1

1

1

2

2

4

4

6

6

10

バックオフィス向け

セキュリティ関係

BI系

自社開発パッケージ

開発用ツール

モバイル・スマデバ

組み込み

基幹業務

Webアプリ

業務アプリ

製品領域 n=38

2 0 0 0 0 0 0 1 1 1 2 2 2 3 4 4

6 10

その他石油／ガス

鉄鋼製薬化学食品教育建設

不動産医療・福祉電気／電子機械／金属

公共インフラ通信

自動車サービス

金融 IT

業種

3 0 0 0 0 1 1 1 1 2 2 3 3 4 5

7 7

9 12

15 19

その他 RPG

ScalaAssembler

ABAPCOBOL

PL/IPerl

ソフトウェア開発… SHELL

パッケージ特有の… C

PL/SQLRuby

VB / VBAC#

PHPC++

Java ScriptSQLJava

開発言語 n=38 n=38

30



0 9

27 2

その他

開発支援部門

開発部門

業務部門

所属部門 n=38

1

0

3

4

4

6

6

7

8

20

その他

スポンサー

プロダクトオーナー

ビジネス・アナリスト

部門責任者、ライン管理職

チームメンバー

アーキテクト

PMO

スクラムマスター

プロジェクト・マネジャー

役割（ロール）

3 1 2 3 5 6

17

その他

競合他社との兼ね合い

セミナー等で興味をもったから

トップダウンでの指示

スポンサーや発注先からの指示

自分が推進する立場

開発チームが自主的に判断

導入のきっかけ

n=37

n=37

31


1 4

11 15

6

21名以上 11-20名

7-10名 4-6名 1-3名

チーム規模 n=37

2 2 3 4

7 19

6チーム以上 5チーム 4チーム 3チーム 2チーム 1チーム

同時最大チーム数 n=37

1 1

6 2

0 8

3 2

4

その他わからない

決めていない 2ヶ月間 1.5ヶ月

4週間 3週間 2週間 1週間

イテレーション期間 n=37

40名 15チーム



2

1

2

6

7

8

12

12

19

その他

DAD

AUP

Lean

XP

カンバン

ウォーターフォール

カスタム

SCRUM

導入したプロセス・手法 n=37

4 5 5 5 6 7 8 8 9 10 10 11 12 13 13 14 16 18 18 19 19 19

30

アジャイルコーチ

テスト駆動開発

ビルド自動化

プランニングポーカー

KPT

リファクタリング

ストーリーポイント

リリース計画

プロダクトバックログ

チケット駆動

バーンダウンチャート

朝/昼/夕会

適用したプラクティス n=37

• アジャイルとウォーターフォールのミックス

• 自社のをベースにクライアントに合わせてカスタマイズ

※複数回答 ※複数回答

次ページ参照


プラクティス


• バックログ • 見える化 • 生産性 • コーディング • 育成・計画 • 自動化 • 継続的XX

34

※数量化理論Ⅲ類：カテゴリなど質的なデータを扱う分析手法


2 1 3 4 7 7 8 9 10 11 13 14 15 16 18

23

その他

評価をしていない

Earned Value

顧客満足度

ストーリーポイントの消化数

チームのモチベーション

仕様変更数

開発金額

試験／障害件数

ベロシティ

開発規模

期間、リードタイム

レビュー

チケット数

バーンダウンチャート

開発工数

マネジメントに使用したメトリクスやツール n=33

4

3

3

12

14

19

24

していない

開発者スキル

顧客満足度

生産性

品質

コスト

スケジュール

メトリクス評価の予実対比によるマネジメント項目 n=33

• テストのカバレッジソースコードの静的解析

• CCPM

※複数回答 ※複数回答 ©PMI Japan Chapter, 2016. Copyright and all rights reserved. 35

20 13

ビジネス価値をどのように評価しているか？

評価していない評価している



n=33

61% 39%

• 営業からの定性的反応 • 顧客側の受注金額 • 営業効率 • 不具合の提言 • 利用者数 • ポータルサイトへのアクセス向上、回避

• アクセス数 • 製造コストの削減 • 顧客満足 • 使用性 • 本来解決すべき事項以外の所要時間、操作数

• 売上 36


10

3

8

5

4

2

1年未満

1-2年未満

2-3年未満

3-4年未満

5-10年未満

10年以上

アジャイル経験年数 n=32

1

10

5

1

1

1

9

2

2

1週間

2週間

3週間

4週間

1.5ヶ月

2ヶ月

決めていない/一概に言えない

わからない

その他

適切なイテレーション期間 n=32


アジャイルに対する期待や効果アジャイルプロジェクトマネジメント意識調査報告


結果概要（期待や効果）


1.0 2.0 3.0 4.0

負荷の平準化

学びとプロセス改善

無駄なものを作らない

開発生産性向上

開発プロセス改善

システム品質向上

チームの成熟度向上

コスト削減

開発者のモチベーションアップ

納期（開発期間）短縮

顧客満足度向上

ビジネス価値創造

変化対応（仕様、環境など）への柔軟性

アジャイル開発への期待と結果の比較

【未導入】期待【継続中】期待【継続中】結果【やめた】期待【やめた】結果

まったく期待していないまったく効果がなかった

とても期待しているとても効果があった

※得点は各群の回答者の得点を加重平均したもの

39



1.0 2.0 3.0 4.0

チームの成熟度向上

コスト削減

開発者のモチベーションアップ

納期（開発期間）短縮

顧客満足度向上

ビジネス価値創造

変化対応（仕様、環境など）への柔軟性

アジャイル開発への期待と結果の比較（分割）





期待を大きく下回る

期待を大きく下回る

40



1.0 2.0 3.0 4.0

負荷の平準化

学びとプロセス改善

無駄なものを作らない

開発生産性向上

開発プロセス改善

システム品質向上

アジャイル開発への期待と結果の比較（分割）





41


3.3

3.4

1 2 3 4

やめた

継続中

成功度 n=33

3.2

3.5

1 2 3 4

やめた

継続中

満足度 n=33

3.2

3.4

1 2 3 4

やめた

継続中

活性度 n=33

3.4

3.5

1 2 3 4

やめた

継続中

ビジネス価値の意識度 n=33

©PMI Japan Chapter, 2016. Copyright and all rights reserved. ※得点は各群の回答者の得点を加重平均したもの

成功していない成功している

活性していない活性している

満足していない満足している

意識していない意識している

42



アジャイルを友人や同僚に薦める可能性はどのくらい？（Net Promoter Score）

0% -100% 100% 50% -50%

アジャイルを薦めるのはまだちょっと早い？

顧客ロイヤルティ、顧客の継続利用意向を知るための指標。点数評価推奨者

(Promoter) ロイヤルティが高い熱心な顧客。自らが継続購入客であるだけでなく、他者へサービスを勧める『推奨』の役割も担う。

中立者 (Passive)

満足はしているが、それ程熱狂的ではなく、競合他社になびきやすい。

批判者 (Detractor)

劣悪な関係を強いられた不満客。放置しておくと悪評を広める恐れがある。

-10%

43

アジャイルに対する自由記述アジャイルプロジェクトマネジメント意識調査報告




アジャイル開発を継続していない理由 • 時間的余裕がなく着手できない • 時期尚早 • 要求がウォーターフォール型向きのため • 受託開発においては割に合わないため • 従来のウォーターフォールがメイン • 開発組織ではない • 従事していない • エンジニアのスキル不足でできない • 担当しているプロジェクトの期間が短くなったため

• プロジェクト終了 • 適当な案件がない • 顧客から品質劣化について注意を受けた • 異動になり現状は機会がない • マネジメント層とQMSが変化しない

• agileを推進したプロジェクトとは別のプロジェクトに参画していて、そこではagile開発のニーズと優先度低いため

• 金融機関の大型プロジェクトには向かない

• アジャイルでやるといいつつ、実態はウォーターフォールかスパイラル

• どちらかというと、ウォーターフォールがあっている

• プロジェクトが中止となったため

n=20

※自由記述、順不同



アジャイル開発手法を取り入れるにあたって一番大切なこと n=20


【知識】 • イテレートの順番 • ステークホルダーのアジャイルへの理解

• アジャイル開発に関する理解の共有 • 設計ドキュメント作成の目的とタイミングについてのユーザーでの柔軟な理解。「設計書レビュー完了後でないと開発着手できない」という従来のウォーターフォール型の開発標準の遵守を掲げられると無理。

• 開発チームだけでなく、周り（ステークホルダーなど）との合意

• 経験者からのアドバイス

【マインド】 • 短納期でリリースするために全ステークホルダーが協力する意識を持つこと。たとえば、詳細設計上の複数の実装オプションが出た場合のソリューション選択が必要な場合に、IT担当者とユーザー部門の代表が必ず24時間以内に決断するなどのルール化。

• 委託、開発側双方の協力が必要と考える。 • 関係者が当事者意識を持つこと • 顧客の理解と信頼関係 • 利用者目線 • 参加者（ユーザー側、開発側）の意識 • 自発性



アジャイル開発手法を取り入れるにあたって一番大切なこと n=20


【環境】 • チームが楽しくプロジェクトを進められること

• なぜ取り入れるのかという目的を明確し、目的から外れていると感じたら、どんどんやり方を変える。

• 関係者の合意 • とにかくやってみて経験を積むこと。 • 経営陣の理解（アジャイルに必要な予算確保と人事調整の理解がプロジェクトの成功には必須）

【チーム】 • メンバーの資質．特に人を扱う互いの意欲とスキル．

【手法】 • コミュニケーション • コロケーション • 文化への適応と周囲の理解・支援



【チーム】 • リリースタイミングが細かく明確なため、メンバーの意識が下がらない。（学生症候群のような事象が起きにくい。）

• コミュニケーションが活発になる • チームの活性化と不確実性への対応能力の向上

• チームの成長 • チーム全体でプロジェクトの状況を共有出来る。

• メンバーが楽しそうだと自分も楽しいから

• メンバーの成長，自己実現感覚． • 関係者の精神的成長

【生産性】 • 開発activityを分解可能なまでに細分化して、activityの依存関係を考慮して開発期間の枠にマップすることで、全開発局面を通じて、開発チームの空き時間を最小化できた。言い換えれば、同じ人数で開発期間を短縮できるので、サービス提供金額を低くできる。

• 納期短縮 • 計画立案のコストが下がるとともに変化に対応しやすくなる。

• 後戻りの防止 • 柔軟性

アジャイル開発手法による一番のメリット n=20




【ビジネス価値】 • プロジェクトに柔軟性を取り入れることが可能になること

• ユーザー側が結果イメージを持ちやすい

• PoCのスピード • 起案から市場へ提供するスピードが速い。その結果（試行）のフィードバックも早い。

• 顧客の要望の早期実現 • 早い段階で動くものを確認 • 手戻り防止と利用者の満足度

アジャイル開発手法による一番のメリット n=20




【アジャイルの理解】 • アジャイル開発を知らない開発メンバーや管理層への説明が必要。

• 理解が浸透していないためレポートラインへの説明が難しい

• 品質の劣化・マネジメント層のアジャイル開発でのスキル不足（ウォーターフォール型マネジメントが得意な人が直ぐに順応できない）

• 意識改革が必要で、とても大変 • 半端な知識で始めると、逆に現場が混乱する。

• 教科書通りでもうまくいかないので、現場の実情に合わせたカスタマイズは必要。

【期待のマネジメント】 • 計画との差異についてチームの責任になってしまうことがある

• 結果を保証することが難しい．ウォーターフォールではできる，人に対する割切り，成果を優先する判断が適用しがたい．

【スコープ】 • スコープ拡大 • 全体像を見失いやすい

アジャイル開発手法による一番のデメリット n=20




【手戻り】 • イテレートの順番を間違ってしまうと、逆に手戻りが発生してしまいイテレートが守れなくなる。

• 仕様にあいまいな部分が多いため、リリース間際まで仕様変更の可能性が高い

• 成果物に対する手戻りの多さ • 評価可能な短期的な結果が出にくい

【目的化】 • アジャイルのプラクティスを重視しすぎて、顧客も含めたチームから孤立してしまうと楽しくないので良くない

• ウォーターフォールでうまくいかないプロジェクトがアジャイルでうまくいくようになるという勘違い

【従来型との連携】 • ウオータフォールとの兼ね合い • 従来のウォータフォール型でマネジメントとの整合【チーム】 • 自発的でない人や新人には馴染むのに時間が掛かる

• 全開発局面の最初から最後まで、プロジェクトメンバーはフル稼働を維持しなければならない。3ヶ月続くとメンバーが疲弊する。

アジャイル開発手法による一番のデメリット n=20


アジャイル未導入の調査アジャイルプロジェクトマネジメント意識調査報告


結果概要（未導入）


34人,

44%

5人,

6%

39人,

50%

アジャイル開発手法を

導入したいと思うか

はいいいえどちらとも言えない

n=78

1%

37%

52%

10%

アジャイル開発の導入時

周囲の協力は

どの程度得られそうか

かなり協力を得られそう

やや協力を得られそう

あまり協力を得られそうにない

まったく協力を得られそうにない

n=71

協力を得ることは難しそう

53



• 流行 • 日本以外では標準であること。ソフト開発に向いている開発手法であると思われること。

• 当時アジャイル開発で進めようと試みたが失敗した。ユーザーからの最新のニーズを取り入れるにはアジャイル開発の方が向いているのかと思うため

• 短期に効果を出すことは顧客に意味がある • 早い段階でユーザーが試作品を見ることにより後工程での手戻りが減少する（ユーザーの要望に沿ったシステムが作りやすい）

• 顧客満足度を上げたい • 顧客満足度の向上が見込める • 経験してみないと、実際に分からないため。 • 経営スピードに対応するため • 開発要件がはっきりしない案件が増加してきたため

• 海外のベンダーはアジャイル開発がデフォルトになっているから。

• プロジェクトリスクの軽減のため • ビジネス変化に速度に合うシステム開発を行うためのひとつの選択肢であると考えているため。

• デリバリータイム要求への対応 • ウォーターフォール型開発が限界に達しつつある状況のため

「導入したいか？」に「はい」と回答した理由

• ウォーターフォール開発が正しくできないのに、新しいことはできない。

「導入したいか？」に「いいえ」と回答した理由



どちらとも言えないと回答した理由 • よく理解できていないため・開発部門ではないので • 興味はあるが無償の具体な事例集を知らないため、具体的な行動をしていない。 • アジャイルの良さは判るが、実際にスクラムでプロジェクトを管理した際に、手法が自身に合わなかった（プランニングポーカー等）

• 社内の開発工程がウォータフォールモデルのため、導入が難しいと思われる。 • 導入のメリットが不明です。・導入すべき理由がはっきり分からない。 • 大規模な開発機会がないから。・受注側につき、客先次第 • ホストシステム開発・保守への適合に疑問・わからないため • 今のところビジネス上具体的な必要性が無い・導入効果が不明 • 効果が今一つ見えないから・利点が分かっていない • 客先で導入しようとしているが、我々の開発に適用できるか疑問 • 構築あるいは運用系業務が多く取り入れ方がわからない • 具体的なメリット／デメリットを理解できていないから。 • 期間の短縮、コスト削減に直結しない。手法を変えるためには手順・ガイド等の作成に多大なワークがかかるため・ユーザも含めて向き不向きがある

• 開発内容によって向き不向きがあるように思える・まだ知識が足りないため • 手法として適した開発ではないため、利点などが現状では不明のため。

4 11

23 24

34 40

44 44

48

その他目標設定と人事評価

品質の担保チームビルディング

開発ツールやインフラ環境契約形態

お客様の理解と協力人材、スキル

社内の理解と協力（企業文化）

アジャイル導入にあたっての課題点

結果概要（状況別）

※複数回答

n=71


• インクリメンタル的な本番開始が業務上はできない場合が多い。従って開発形態としてアジャイル風にできたとしても開発負荷の平準化に効果があるが、最終のテストと検収は全体の開発が完了してから行うのであれば意味・効果が少ない。

• 具体なプロジェクト事例を知らない

• 自分自身が理解し、経験をすること

• 要件の流動性

3, 30%

2, 20% 1, 10%

1, 10%

1, 10%

2, 20%

2016

導入するメリットが明確になっていない

導入しなくても解決できる

導入できる人材がいない

導入時のデメリットが明確になっていない

現在の開発プロセスで問題を感じていない

その他


n=5

12,

26%

10,

22% 7, 15%

5, 11%

5, 11%

7, 15%

2015

導入するメリットが明確になっていない

導入できる人材がいない

現在の開発プロセスで問題を感じていない

導入時のデメリットが明確になっていない

導入しなくても解決できる

その他

n=24


アジャイル開発を導入しない理由

※複数回答 ※複数回答

57

その他アジャイルプロジェクトマネジメント意識調査報告


結果概要（その他）

13 12

36 47

59 61

110

その他ソフトウェア開発のみ

セールス社会貢献（プロボノ）

マーケティング災害復興

製品開発・設計

ソフトウェア開発以外の適用領域

※複数回答 n=170


17人,

10%

153人,

90%

ソフトウェア開発以外にアジャイル開発手法を

適用したことがあるか？

あるない

59

• 「アジャイルの手法」の定義次第である。狭義の意味であればソフトウェア開発以外にあり得ない。

• 領域というよりは、兎に角、前に進めたい事案／プロジェクトに適用するべきと思う。

• スクラムについてはプロジェクト全般に適用可能 • 現状のアジャイルはソフトウェア開発に最適化されす

ぎているので他分野への適用は難しい • 教育・業務改革・開発コンサルタント • インテグレーションワーク • アジャイル＝リーンの考え方はどの分野にも適用でき

る。

• ITインフラ構築プロジェクト・ PMO業務・学習 • アジャイルは考え方、姿勢と思っています。 • インテグレーションワーク・ Risk Management • 医薬品の開発（アライアンス品目）・製品企画 • 海外のASPベンダーがアジャイル開発したアプリケー

ションを日系企業の顧客への導入／移行支援(ブリッジSEとして) ・自動車部品の設計・業務規則の作成

• 業務プロセス改善・建設プロジェクトの立ち上げ時 • 事務／総務系などのタスク管理・品質改善 • 翻訳プロジェクト。システム開発と似た構造を持ちつ

つ、日本では大きな企業がなくマネジメントを整理するリーダーがいない。・要求開発（ただし、ここで言ってる「アジャイルの手法」ってなんですか？

多変量解析によるパス解析アジャイルプロジェクトマネジメント意識調査報告


各質問項目の概要


【成功度】適用してどの程度プロジェクトが成功したか（4段階）

【習熟度】アジャイルの実施は何度目か？（初回／2-3／4回目以上）

【効果】適用してどの程度効果があったか？（4段階）

【経験年数】アジャイル経験年数（1年未満／1-3年／3年以上）

【活性化】適用してどの程度メンバーが活性したか（4段階）

【会社規模】社員数（100未満／100-1000／1000以上）

【満足度】適用してどの程度プロジェクトに満足したか（4段階）

61

PJ成功度への要因


成功度

習熟度効果経験年数活性化会社規模

0%有意 5%有意

効果が出ているから成功していると判断をしている一方で、ある程度はアジャイルの手法に習熟していないと成功の評価ができないのでは？

アジャイルの実施は何度目か？（初回／2-3／4回目以上）

適用してどの程度効果があったか？（4段階）

適用してどの程度プロジェクトが成功したか？（4段階）

x%有意：「仮説」と「実際に観察された結果」との差が統計学的に偶然ではないことを意味し、その時の水準を示す。 ※%の値が小さいほど、偶然の度合いが小さい

62

PJ満足度への要因


満足度

効果成功度活性化

0%有意 0.1%有意

成功していれば満足度も高まるという当然の結果ではあるが、 PJメンバーが活性化しているかどうかも満足度の指標になりうる

x%有意：「仮説」と「実際に観察された結果」との差が統計学的に偶然ではないことを意味し、その時の水準を示す。 ※%の値が小さいほど、偶然の度合いが小さい

適用してどの程度プロジェクトが成功したか？（4段階）

適用してどの程度メンバーが活性したか？（4段階）

適用してどの程度プロジェクトに満足したか？（4段階）

63

PJ成功/満足度への要因


成功度

習熟度効果経験年数活性化会社規模

0%有意 5%有意

効果が出ているから成功し、満足していると判断をしている一方で、ある程度はアジャイルの手法に習熟していないと成功の評価ができないまた、PJメンバーが活性化しているかどうかも満足度の指標になりうる

満足度

0%有意

0.1%有意

アジャイルの実施は何度目か？

適用してどの程度効果があったか？

適用してどの程度メンバーが活性したか？

適用してどの程度プロジェクトが成功したか？

適用してどの程度プロジェクトがに満足したか？

64

結果報告（考察）アジャイルプロジェクトマネジメント意識調査報告


結果報告（考察） • PMI®の各種資格について

– PMI-PBA®やPMI-ACP®などの資格保持者を増やすのであれば、ユーザー企業にアプローチをすべき

– PMI-ACP®などの試験は日本語化すれば、資格保持者が増える


結果報告（考察） • アジャイルに対する正しい理解が足りない

–アジャイル経験者は書籍やインターネットなどで情報収集をし、周囲と会話をしてアジャイルに関する理解を深めているものの、アジャイル未経験者は書籍を読む割合は少なかった

–従来のアプローチで十分対応できるため、アジャイルの手法が必要であると感じない限りはアジャイルに関する情報を積極的には収集しないと推察される

–ある程度は習熟度がないとアジャイルの効果が出ているかどうかの判断をすることが難しい


結果報告（考察） • アジャイルを始める際の壁

–アジャイルを導入する際に、自社/顧客といった、周囲の協力があまり見込めないことや、スキル不足などの懸念があり、始めようとしても始められない状況にある回答者もいると推察される

–既存のプロジェクトに対してアジャイルをそのまま適用することは難しいと感じている回答者もいる


結果報告（まとめ） • アジャイルマニフェストの認知度から推測すると、アジャイルに関する理解度は昨年から変わっていない

• アジャイルの導入時に協力者が周りにいない • PMI-ACP®の試験は日本語化すれば受験したいと考えている人数が一定の割合で存在する

• PMP-ACP®の認知度が低い • 今回の回答者は大企業ほどアジャイルを導入していない傾向が見られた


アジャイルプロジェクトマネジメント意識調査報告

第2部提言編 PMI日本支部

アジャイルプロジェクトマネジメント研究会木村卓央


アジェンダ

• はじめに • 提言

1.アジャイルの基本的な考えかた（マインドセット）を正しく理解しよう

2.経験者の知恵を生かして組織へアジャイルを広めよう


はじめに

• 本セッションでは、第一部結果報告編の内容を受け、アジャイルプロジェクトマネジメントの導入・展開時の課題と、それに対する施策を提言します。


提言その１アジャイルの基本的な考えかた（マインドセット）を正しく理解しよう

アジャイルマニフェストの認知度より


結果報告（まとめ）

• アジャイルマニフェストの認知度から推測すると、アジャイルに関する理解度は昨年から変わっていない






言葉【継続中】【やめた】【未導入】


アジャイルで開発する方法が

やっぱりまだ普及していないのでは？

アジャイルに関する言葉の知っている度合い

2015年度アンケート【継続中】【やめた】【未導入】


75

アジャイルの基本的な考え方を理解する

• 形ばかりのアジャイルに囚われていませんか？ – アジャイル開発手法のプロセスに則っていれば良いというものでもない

• アジャイルの基本的な考え方(マインドセット)を理解して、アジャイル開発プロセスに取り組みましょう！ – アジャイルマニフェスト

(アジャイルソフトウェア開発宣言)


アジャイルソフトウェア開発宣言私たちは、ソフトウェア開発の実践

あるいは実践を手助けをする活動を通じて、よりよい開発方法を見つけだそうとしている。

この活動を通して、私たちは以下の価値に至った。

プロセスやツールよりも個人と対話を、包括的なドキュメントよりも動くソフトウェアを、

契約交渉よりも顧客との協調を、計画に従うことよりも変化への対応を、

価値とする。すなわち、左記のことがらに価値があることを認めながらも、私たちは右記のことがらにより価値をおく。

Kent Beck Mike Beedle Arie van Bennekum Alistair Cockburn Ward Cunningham Martin Fowler

James Grenning Jim Highsmith Andrew Hunt Ron Jeffries Jon Kern Brian Marick

Robert C. Martin Steve Mellor Ken Schwaber Jeff Sutherland Dave Thomas

http://agilemanifesto.org/iso/ja/

© 2001, 上記の著者たちこの宣言は、この注意書きも含めた形で全文を含めることを条件に自由にコピーしてよい。


12の原則 1

顧客満足を最優先し、価値のあるソフトウェアを早く継続的に提供します。

2 要求の変更はたとえ開発の後期であっても歓迎します。変化を味方につけることによってお客様の競争力を引き上げます。

3 動くソフトウェアを、2〜3週間から2〜3ヶ月というできるだけ短い時間間隔でリリースします。

4 ビジネス側の人と開発者は、プロジェクトを通して日々一緒に働かなければなりません。

5 意欲に満ちた人々を集めプロジェクトを構成します。環境と支援を与え仕事が無事終わるまで彼らを信頼します。

6 情報を伝えるもっとも効率的で効果的な方法はフェイス・トゥ・フェイスで話をすることです。

http://agilemanifesto.org/iso/ja/ ©PMI Japan Chapter, 2016. Copyright and all rights reserved. 78

12の原則 7 動くソフトウェアこそが進捗の最も重要な尺度です。

8 アジャイル･プロセスは持続可能な開発を促進します。一定のペースを継続的に維持できるようにしなければなりません。

9 技術的な卓越性と優れた設計に対する不断の注意が機敏さを高めます。

10 シンプルさ（ムダなく作れる量を最大限にすること）が本質です。

11 最良のアーキテクチャ、要求、設計は、自己組織的なチームから生み出されます。

12 チームがもっと効率を高めることができるかを定期的にふりかえり、それに基づいて自分たちのやり方を最適に調整します。

http://agilemanifesto.org/iso/ja/ ©PMI Japan Chapter, 2016. Copyright and all rights reserved. 79

大事なこと

• 顧客中心 • 検査・適応 • チーム(人)


顧客中心

• システム開発の目的は、顧客の満足 –最初の要求通りに作ることが目的ではない –顧客に価値を届けているのかを考える –顧客満足に結びつかないものは、極力排除してより顧客満足に結びつく活動に注力する


予測型・適応型


予測型

全要件を洗い出し正確な計画を立て作業を始める

優先順位の高い要求を整理し短い計画を立て作業を始める

予定した全要件を満たしたら作業完了

目標を達成したら作業完了

適応型

変更を嫌う

変更は目標に到達するためには必要

82

アジャイルは適応型プロセス

• 成果に影響する様子が、結果責任を持つ者に対して見える化されていること

• プロセスを指す用語が関係者全員で共有されていること

透明性

• 異常をすぐに検知できるように頻繁に検査する

• ただし作業の妨げになってはいけない

検査

• 検査した結果から、異常に気付いたら、速やかに調整する

適応


よくある間違い

• アジャイルで実施すると問題が多い • 問題？なんで今からそんなこと言ってるの？


アジャイルで実施すると問題が多い？

85

違います

素早く問題に気づけるのです


86

全員で早い段階(問題が大きくなる前)

に素早く対応する flickr - LEGO MARVEL AVENGERS / STICK KIM

適応問題が見つかったら


87

WF-Agile

Water Fall

Agile

flickr - Jun Seita

flickr - jessica


ウォーターフォールでの進め方

88

要件定義

基本設計

詳細設計

コーディング

単体テスト

結合テスト

総合テスト

プロジェクト立ち上げリリース


要件定義

基本設計

詳細設計

コーディング

単体テスト

結合テスト

総合テスト

プロジェクト立ち上げリリースビジョニング

ストーリー収集

アジャイルでの進め方

89

イテレーション

リリース計画


ウォーターフォールとアジャイル

• 実施する内容は基本的には同じ • 基本的な考え方(マインド)が異なる

–アジャイルマニフェスト (アジャイルソフトウェア開発宣言)

• 考え方が異なるので、進め方も異なる


ウォーターフォールとアジャイルの考え方① ウォーターフォール(予測型) アジャイル(適応型)

ゴール計画通りに、予定していた全ての要求を満たす

顧客の目標の達成

要求最初に全てを集め確定する最初に全てを集めるのは困難集められたとしても変わる要求は発生するもの

変更変更管理で管理する基本的に変更を嫌う

顧客の目標に到達するためには変更は必要。いつでも変更は受け付ける

計画正確な計画を立て、それに従う正確な計画を立てるのは不可能短い計画を立てる

見積り計画通りに進めるために必要将来を予測するために必要

リリース最後にリリース頻繁にリリースし、フィードバックを得る


ウォーターフォールとアジャイルの考え方② ウォーターフォール(予測型) アジャイル(適応型)

工程存在する存在しない

リスク最初に全て想定する時間を掛けずに想定し検証により問題を見つけ、早期にリスクの軽減を図る

品質テスト工程で品質を担保早い段階で品質を担保

バッファ考慮する考慮しない

チーム機能的、専門的自己組織化、機能横断的

マネジメント

どちらかというとX理論チームの作業を管理する

Y理論チームを信頼し、チームの障害を取り除く


ゴールについて

93

機能の利用度


要求・変更について

• よくある問題 – 要求を出す人と実際に使う人が異なる – 詰め込まれる – リリースまでに考え方が変わる

• アジャイルでは – 頻繁にリリースすることで、フィードバックを得て、正しい要求に近づける

– 要求はいつでも追加可能 – 30日以内(1週間から2週間が多い)にはリリース


よくある問題

• 要求はいつでも追加可能 –スコープクリークに陥るのでは？


新たな要求優先順位の低い要求

95

チームについて • よくある問題

– スキルが高く無いとアジャイルできない – 設計しかできない、テストしかできない – チームを信頼しても上手くいかない

• アジャイルでは

– スキルは身につけるもの – 機能横断的なチーム

• T型人材、π型人材 • ペアプロ、ペアワーク

– 自己組織化されたチーム • サーバントリーダーシップ


自己組織的なチーム


自己組織化チームは作業を成し遂げるための最善の策を、チーム外部からの指示ではなく、自らが選択する

参考：｢自己組織化チームとは何か？｣ http://www.infoq.com/jp/articles/what-are-self-organising-teams

自己組織化チームは次のような特徴を備えています。 • コントロールの分散化，すなわち集権的管理が存在しない。 • 変化する環境への継続的な対応。 • 局所的なインタラクションから発する創発的構造。 • 肯定的ないし否定的なフィードバック。 • システムの修復および調整能力を源泉とする復元力。

97

アジャイルでのマネジャーの役割

• Y理論 • 改善も含め自己管理するチームに責任を委譲する

–サーバントリーダーシップ


全体の方向性設定

チームと組織的コンテキストを設計作業プロセスと進捗の監視と管理

チームタスクの実行

マネジャー主導チーム

自己管理型チーム

自己設計型チーム

自己統治型チーム

マネジメントの責任

チームの自己責任

Learge Scale Scrum/ Craig Larman , Bas Vodde http://less.works/jp/less/management/self_managing_teams.html Copyright © 2014 ~ 2016 The LeSS Company B.V. All Rights Reserved 98

http://less.works/jp/less/management/self_managing_teams.html


http://less.works/

マネジャーの責務への影響

マネジャーの責務ではない • スプリントの状況を追う • 進捗会議やマネジャー会議を持つ • チームに作業指示や残業を指示する • 製造上の課題解決にかかる担当者を当てる • 「アジャイルプロジェクト管理ツール」でチームを監視する

チームが行う • 進捗監視: 計画通りかを確認 • 進捗管理:計画から外れていれば対処 • プロセス管理:作業のやり方を決定 • プロセス監視:チームの意見衝突や問題はチームで解消

Learge Scale Scrum/ Craig Larman , Bas Vodde http://less.works/jp/less/management/self_managing_teams.html Copyright © 2014 ~ 2016 The LeSS Company B.V. All Rights Reserved ©PMI Japan Chapter, 2016. Copyright and all rights reserved. 99



http://less.works/

提言その１まとめ • アジャイルの基本的な考え方(マインドセット)を理解して、アジャイル開発プロセスに取り組みましょう！ – アジャイルマニフェスト

(アジャイルソフトウェア開発宣言) • 基本的な考え方は、従来とは異なる

– 従来のマインドのまま、プロセスだけを導入しただけでは上手くいかない

• 大事なこと – 顧客中心

• システム開発の目的は顧客満足 – 透明性・検査・適応 – チーム(人)

• 自己組織的なチーム • マネジャーの役割の変化


提言その2 経験者の知恵を生かして組織へアジャイルを広めよう

アジャイル導入にあたっての課題点より


結果報告（まとめ）

• アジャイルマニフェストの認知度から推測すると、アジャイルに関する理解度は昨年から変わっていない






34人,

44%

5人,

6%

39人,

50%

アジャイル開発手法を

導入したいと思うか

はいいいえどちらとも言えない

n=78

1%

37%

52%

10%

アジャイル開発の導入時

周囲の協力は

どの程度得られそうか

かなり協力を得られそう

やや協力を得られそう

あまり協力を得られそうにない

まったく協力を得られそうにない

n=71

協力を得ることは難しそう

103

4

11

23

24

34

40

44

44

48

その他

目標設定と人事評価

品質の担保

チームビルディング

開発ツールやインフラ環境

契約形態

お客様の理解と協力

人材、スキル

社内の理解と協力（企業文化）

アジャイル導入にあたっての課題点


※複数回答

n=71


協力を得ることが課題となっている

104


どこから始めたらいいのかわからない

アジャイルを導入したい

仲間を見つけたい

理解者を増やしたい

上司に理解してもらいたい

105

Fearless Change 変化に導く戦略

– たくさんのチェンジリーダーが持つ戦略をまとめたもの

– うまくいく戦略をパターンとして文書化 – パターンとは繰り返し発生する問題のうまい解決方法を捉え、明文化したもの

– パターンは、コミュニティで議論されている – 各パターンに書かれる項目：問題、状況、解決方法、その根拠、結果、既知の使用方法、そしてパターン名


Fearless Change アジャイルに効くアイデアを組織に広めるための48のパターン丸善出版 (2014/1/30) Mary Lynn Manns (著), Linda Rising (著), 川口恭伸 (監訳), 木村卓央 (翻訳), 他 6名

106

パターン・ランゲージパターン・ランゲージは、建築家のクリストファー・アレグザンダーが提唱した知識記述の方法です。アレグザンダーは、建物や街の形態に繰り返し現れる法則性を「パターン」と呼び、それを「言語」（ランゲージ）として記述・共有する方法を考案しました。 <中略> パターンには、デザインにおける「問題」と、その「解決」の発想が一対となって記述され、それに名前が付けられます。パターン・ランゲージの利用者には、自らの状況に応じてパターンを選び、そこに記述されている抽象的な解決方法を、自分なりに具体化して実践することが求められます。


http://learningpatterns.sfc.keio.ac.jp/patternlanguage.html パターン・ランゲージの考え方より抜粋

Copyright (C) 2009 - 2013, 慶應義塾大学湘南藤沢キャンパス井庭研究室. All rights reserved. 107

アイデアを推進していく人エバンジェリスト(1) 新しいアイデアを推進していきたい情熱を持った人新しいアイデアを導入するために、そのアイデアにかける情熱で、あなた自身を突き動かそう

正式な推進担当者(29) 正式に任命されたエバンジェリスト説明責任がついてくる。得られた結果と小さな成功を記録して、あなたの活動のメリットを継続的にアピールしよう

©PMI Japan Chapter, 2016. Copyright and all rights reserved. 参考：Fearless Change アジャイルに効くアイデアを組織に広めるための48のパターン

108

推進していくために必要なもの


小さな成功(2) 組織変革の道のりは困難な道のりとなる。たとえ小さな成功であってもお祝いしよう。

ステップバイステップ(3) どんな計画を立てれば良いのか迷っている。短期的な目標を立て、漸進的なアプローチを取ろう。

予備調査(4) それが組織に合うのかまだわからない。パターンを１つか２つ選んで使い評価しよう。

ふりかえりの時間(5) 私たちは同じ思い込みや同じ間違いをする。上手くいっている事や改めるべきところをふりかえろう。

参考：Fearless Change アジャイルに効くアイデアを組織に広めるための48のパターン 109

一歩踏み出すためにやってみる(17) いいアイデアを持っているが、まだ使った経験はない。まず今やっている仕事にそのアイデアを使ってみよう。

何か食べながら(9) たいていの場合、ミーティングはごくありふれた人間味のないイベントだ。食べながら体験した人や物は、より好ましく感じるようになる。食べ物は、ただのミーティングをイベントに変えるのだ。


110

周囲の協力が得られない


外部のお墨付き(12) そのアイデアが外部からのお墨付きがあるか確かめたくなる。外部発信で組織内の人に有用な情報を提供しよう。

謁見(38) 著名人を招く(27)ならば機会を最大限に活かしたい。招待したスピーカーと会話する機会を作ろう。

相談できる同志(39) 新しいアイデアを導入しようともがいているときはくよくよと悩みがちになる。興味を持っている人たちと定期的に集まろう。

身近な支援者(35) 新しいアイデアを導入するには関心をひかなくてはならない。支持してくれる現場のマネジャーを見つけよう。

参考：Fearless Change アジャイルに効くアイデアを組織に広めるための48のパターン 111

Fearless Change 使い方 • アジャイル導入するための課題を洗い出す

– ワークショップ形式でやると良いです • その課題を解決できそうなパターンを選ぶ

– 例えば • 課題：「周囲の協力が得られない」先ほど紹介した以外では • 協力を求める(6): 組織に新しいアイデアを導入するというのは、大変な大仕事だ。あなたのがんばりに協力してくれる人やリソースを探そう

• ブラウンバッグ・ミーティング(7): 日常のランチタイムを、新しいアイデアを聞くための手軽で気軽な場として活用しよう

• 勉強会(25): あるトピックについて継続的に探求したい・学びたい同僚を集めて、小さなグループを作ろう

• 個人的な接触(20): 新しいアイデアの価値を納得させるため、その人にとってどれだけ有用で、価値あるものなのかを示そう

• 種をまく(22): 興味をかきたてるために、機会のあるときに資料（種）を持っていって、それらを見せる（蒔く）ようにしよう


112

提言その２まとめ • アジャイルを導入する手法として、

Fearless Change – 先人たちが、うまくいく戦略をパターンとして形式値化

– 課題を解決できそうなパターンを選び、実践してみる


予備調査(4) それが組織に合うのかまだわからない。パターンを１つか２つ選んで使い評価しよう。

113

アジェンダ

• はじめに • 提言

1.アジャイルの基本的な考えかた（マインドセット）を正しく理解しよう

2.経験者の知恵を生かして組織へアジャイルを広めよう


Don’t do Agile , Be Agile.


PMI日本フォーラム2016 講演者アジャイルプロジェクトマネジメント意識調査報告


自己紹介 • 氏名飯村北海いいむらきたみ

• 会社株式会社クレスコ • 所属営業統括部

ビジネス開発室 • 職種 ITビジネスエンジニア • 資格 PMP®

• 経歴 – B2BのWebアプリエンジニアを経て自社ソリューション開発＆デジタルマーケティング化に邁進中


Certified Scrum Professional®/Scrum Developer®/ScrumMaster®/Scrum Product Owner®

Project Management Professional (PMP)®

EXIN Agile Scrum Foundation 認定講師アジャイルサムライ横浜道場主催 PMI日本支部アジャイルプロジェクトマネジメント研究会会員 TOCfE横浜塾主催 LeSS Study主催 Fearless Changeアジャイルに効くアイデアを人めるための48のパターン共訳

木村卓央 KIMURA Takao

アジャイルコンサルタント

@tw_takubon

http://facebook.com/kimura.takao

http://about.me/tw_takubon ©PMI Japan Chapter, 2016. Copyright and all rights reserved. 118

[email protected]

119

おわりに今回のアンケートでは、昨年同様に、まだアジャイルが正しく理解されていない

状況が浮き彫りにされました。また、アジャイルを導入しようとしても周囲から協

力を得るのが難しい場合が多く、組織に変化をもたらすことは大きなチャレンジ

となっているようです。

2017年度も、昨年および今年のアンケート実施の振り返り結果を反映させ、継

続してアンケート調査を実施し、日本国内におけるアジャイル導入の実態を追っ

ていきたいと思います。

ご協力頂きましたPMI日本支部会員の皆様、法人スポンサーの皆さま、プロジェ

クトマネジメント関係者の皆さまにお礼申し上げます。

引き続き皆さまのご理解とご協力を賜りますよう、よろしくお願い申し上げます。

2016年11月

一般社団法人PMI日本支部

アジャイルプロジェクトマネジメント研究会


プロジェクトマネジメント - 一般社団法人 PMI日本 …...2 目次 •第1部...

Documents

Transcript of プロジェクトマネジメント - 一般社団法人 PMI日本 …...2 目次 •第1部...

プロジェクト マネジメント - 一般社団法人 PMI日本 …...2 目次 •第1部...

Documents

Transcript of プロジェクト マネジメント - 一般社団法人 PMI日本 …...2 目次 •第1部...

プロジェクトマネジメント - 一般社団法人 PMI日本 …...2 目次 •第1部...

Transcript of プロジェクトマネジメント - 一般社団法人 PMI日本 …...2 目次 •第1部...