1. アジャイルカンファレンス tokyo
行ってきました
藤川 康之

2. アジェンダ
アジャイルカンファレンス tokyoとは
21世紀のソフトウェアデザイン
21世紀型ポートフォリオ管理への変革

3. アジャイルカンファレンス tokyoとは

4. ThoughtWorks社、
株式会社テクノロジックアート

5. http://pw.tech-arts.co.jp/act2012/

6. 21世紀のソフトウェアデザイン
マーティン・ファウラー氏（ThoughtWorks Inc.）

7. マーティン・ファウラー氏

8. マーティン・ファウラー氏
Wikipediaより

9. アジャイルの本質に立ち返る

10. アジャイルソフトウェア開発宣言から10年

11. 当初の意味の
希薄化（Semantic Diffusion）
起きてしまった

12. デリバリーまでに時間がかかりすぎる
意味のないシステムを作り上げる
品質の低いシステムとなったりする
すべてできて当たり前の状況であった

13. 計画駆動型開発(Plan-Driven)
※日本で一般的なウォーターフォール型も
この考え方に属する
CMM(Capability Maturity Model)
※能力成熟度モデル

14. アジャイル

15. Agile Plan-Driven
適応的な計画 予測的な計画
（Adaptive Planning） （Predictive Planning）
人主導 プロセス主導
(People-first) (Process-first)

16. Agile Plan-Driven
適応的な計画 予測的な計画
（Adaptive Planning） （Predictive Planning）
人主導 プロセス主導
(People-first) (Process-first)

17. よく失敗したプロジェクトの話

18. 「管理者が無能で要件を固定できなかった」
「顧客がわがままで最後まで要件を決めてくれ
なかった」

19. 計画駆動のソフトウェア開発では

20. 成功のために要件をいかに
安定
させるかということに力を注いでいた。

21. アジャイル開発では
違うアプローチ

22. 要件の安定に依存するのは健全ではない。

23. 要件が不安定であっても

24. プロジェクトを前に進めていく

25. アジャイルの考え方とアプローチ

26. アジャイルの考え方

27. 要件が
不安定
であるということを認める

28. 作業が進められるように
計画を適応させる

29. アジャイルなアプローチ

30. 少しだけ計画
そこから学習する

31. アジャイルの適応性を理解する

32. 適応性
外的な刺激や環境の
変化に応じて，
それにふさわしいように
自分を変えていく性質能力。

33. ユーザーも開発者も学びを続け

34. 徐々にお互いが有効に機能する
方向に収束していく

35. Agile Plan-Driven
適応的な計画 予測的な計画
（Adaptive Planning） （Predictive Planning）
人主導 プロセス主導
(People-first) (Process-first)

36. 科学的管理法
※労働者管理の方法論

37. プロセスがはっきりしている
→プロセスに従って働く人

38. プロジェクトのチームに対して
この人はプログラマ
この人はテスター
この人はアナリスト など

39. プロセスがいちばん重要

40. このやり方に疑問を持つ

41. 優秀な人たちがよい関係で仕事をする

42. そうしなければ
仕事は、うまくいかない

43. アジャイル開発では

44. 優秀な人をさがし

45. チームとして協力できるかを見極める

46. 自分たちでやりやすい環境や
プロセスを作る

47. プロセスありきから、人ありきになる

48. もたらす結果

49. 押し付けられていない

50. 自分で選択しているという
チームメンバーの考えが生まれ

51. 自分で選択しているという
チームメンバーの考えが生まれ

52. もっとプロセスを良くしようとして
プロセスが進化する

53. 改善に熱意を燃やす

54. 最後に

55. Perfect

56. 名詞ではなく動詞

57. 「完璧」なソフト

58. 「完璧を目指して改善する」

59. Agile
適応的な計画 人主導
（Adaptive Planning） (People-first)

60. 21世紀型ポートフォリオ管理への変革
David Joyce 氏（ThoughtWorks Inc.）

61. プロジェクトについて

62. プロジェクトが始まるときは、
最終的な結果を考えて予算などが決められる。

63. スケジュールなどがちゃんと
なっているかを「監視」している。

64. しかし、「価値」ということは見落としている。

65. 古い考え方

66. １．ウィジェット工学

67. 図を描いて、その図の通り作る

68. ２．御用聞き体質

69. 作れと言われたものを作る

70. ３．機会の最大化

71. 始まりが多ければ、終わりも多い

72. ４．マイルストーンの制御

73. 現在地が分からないのであれば、
より詳しいデータが必要だ

74. ５．丸一年のプロジェクトを計画できる

75. 詳細な計画を立てれば、今年は必ず成功する

76. ６．とにかくやる

77. 合意された計画なのだから、実行する

78. こういうことを推奨している
ヒーローに振り回され
残業残業ということになってしまう。

79. ガントチャート

80. 1919年のガントチャートと
同じ物が今でも使われている

81. 21世紀ということで違う思考で
ソフトウェア開発をしてもよいのではないか？

82. 「WFでうまくいっているであれば、
それでいいじゃないか」という考え方もある。

83. 一昔は、3年後ならというプランニングができた。
しかし、今は3ヶ月となっている。

84. WFでは、今の時代の速さについていけない。

85. 考え方を変える必要がある

86. 真ん中の部分だけちょっとアジャイルを
入れてみようという変化がある。

87. 開発フロー
WF Agile WF
要件定義、設計 製造、単体テスト 結合テスト etc

88. しかし、これでは
ビジネスアジャリティ（俊敏性）
というのは「ない」

89. すべての開発フローをアジャイルにすること

90. 詳細なビジネスケース＆計画から
研究、仮説、実験へ

91. 作っているものは、
コンスタントに確認していく。

92. プラン（計画）通り作成されていても

93. お客さまがその成果物で
納得するかどうかは別問題

94. 詳細な実行計画を作って実行を学習はできない。
実験をしなければならない。

95. いきなり予算をボンッともらうわけではなく
ある小さなことを解決する
予算をもらうようにする。

96. シードファンディングと呼んでいる。

97. 少しずつ芽が出てきたら追加で
予算をもらうようにする。

98. 逆に芽が出なかったら
別のことに使うということになる。

99. アジャイルという手法だから
出来るやり方

100. 大きなプロジェクトではこれができない

101. 細かくやっていくことが大事。

102. 優先度高