藤原 大、楽天株式会社 『AgileTourOsaka2012 in Minoh』 講演資料

1. 地図を捨ててコンパスを頼りに進め 楽天株式会社 藤原大

2. 藤原 大
@daipresents
• 楽天株式会社 開発ユニット
アジャイルグループ マネージャ
• プロジェクトファシリテー
ター、トレーナー
• 趣味は沖縄離島巡り
• 実家は箕面市牧落
http://daipresents.com/

3. Agile Conference
Agile Conferenceには2010年から参加しています。記事を書いたりFacebookページを
作ったりして、ちょっとでも自分が好きになった雰囲気が届けばなぁと。今年書いた記事
はこちら => ManasLink - EM ONLINE http://bit.ly/QlZy9N

4. 集え、日本の活動家たちよ。
http://ultimateagilist.doorkeeper.jp/events/1823
Ultimate Agilist Tokyo
11/17 開催！

5. 集え、日本の活動家たちよ。
宝探しAgileゲーム - 安井 力 氏
アジャイルプログラマの定義は俺たちが決める。そして、最速でそう
なってみる - 牛尾 剛 氏
アジャイル テスト開発を考える - 細谷 泰夫 氏
TDDと組織文化 - 天野 勝 氏
家電商品を開発してみると目からウロコなAgileの本質 - 前川 直也 氏
Ruby on Railsによるアジャイル開発事例と注意点 - 川端 光義 氏
The Art Of Agile ProjectManager - 市谷 聡啓 氏
http://ultimateagilist.doorkeeper.jp/events/1823
Can you keep doing that? - 原田 騎郎 氏
アジャイル開発における、システムテストの自動化 - 小井土 亨 氏
リアルウェア - 濱 勝巳 氏
アジャイルに対する見方の変化 - 太田 健一郎 氏
これまでの開発から、これからの開発へのチェンジ - 倉貫 義人 氏
Ultimate Agilist Tokyo
テストを支える。テストを育てる。 - 井芹 洋輝 氏
11/17 開催！
「ふりかえり」をふりかえってみよう。 - 串田幸江 女史

6. SIerでした
•Javaエンジニア
•業務向けWebアプリ
•二次受け
•一人でドナドナ
•ほとんど滝
http://www.flickr.com/photos/lombre/3052877393/

7. 上記以外にもサービスはあります。これだけいろいろなサービスがあると開発方法も様々
です。

8. アジャイル支援歴
•リプレイス6ヶ月
•リプレイス3ヶ月
•若いサービス10ヶ月
私のチームごとサービスを担当するチームに合流し、席を並べて働きます。
週1回とかじゃなくて、毎日一緒です。

9. プロデューサー
登場人物
エンジニア 私

10. 開発の流れ
•PROがアイデアを練って
•ENGが実現する
•この回転を支援

11. 朝礼の
風景
はじめは私がファシリテーターとして運営し、徐々に周りに移譲していく形が多いです。

12. 12

13. 今日のおはなし
l 開発のチェンジ
l マインドセットのチェンジ
l 変化から習慣へ

14. 今日のおはなし
l 開発のチェンジ
l マインドセットのチェンジ
l 変化から習慣へ

15. すぐ見えた壁
•なぜかWF
•開発スキル低（若者多）
•一体感の無さ

16. 考えなおしたこと
計画と仕様

17. 問い
仕様書は
正しいのか？
photo - http://www.flickr.com/photos/richardvignola/4566774290/

18. こういう意見が多数
仕様がないと作れないから
早く決めてほしい

19. 一方で
仕様どおりつくるだけだと
つまらない
もーわがままなんだからぁ

20. ソフトウェア開発とは、
ユーザーのニーズやマーケ
ティング上の目標をソフト
ウェア製品に変換する作業
である。
ソフトウェア開発 - Wikipedia http://bit.ly/A63xPS

21. 違った使い方された
Publicにメッセージが飛び合う事を
想定していたのに、Closedなメッ
セージ交換に使われていた

22. 仕様がゴールか？
サービス開発だとこの考え方はリスクがあります。サービス開発だけなんですかね？
ソフトウェア開発全般に当てはめてもいい気がします。
photo - http://www.flickr.com/photos/druclimb/480108350/

23. 今の答え
仕様は仮説でしかない

24. 詳細を決めすぎない
• 小さなプロトタイプを作る
• どこまでも考え過ぎない
• 大事なら時間をかける

25. 25
僕も実際に開発をやっていて違いを感じたのですが、こういうビルを建てるような開発じゃない雰囲気です。
photo - http://www.flickr.com/photos/nknh/2447013697/

26. ちょっとずつリリースを繰り替えいしているとこういう街のようなシステムを作っている気分になってきます。
26
この中に赤いビルを建てようとは思わないですよね。そういう統一性は設計時に考えます。
photo - http://www.flickr.com/photos/brucehh/7627194894/

27. メアリーさん なぜ全部計測しないの？
社内トレーニングでお招きしたときの話。言われて悔しい思いをしました。

28. 効果測定の強化
•リリース後に勝負が始まる
•効果測定で見える化
•使われているか？
•想定した使われ方か？

29. デモ、見える化
•デモは途中で止めた
•そのかわりにできたら集合
•
レビューとしてリリース後
のKPIを共有

30. 再度、今の答え
リリースは出口じゃなく
入り口だろう？
参考：AKB48 “GIVE ME FIVE!” http://bit.ly/TEH2sh
photo - http://www.flickr.com/photos/maurymccown/1614878016/

31. 問い
計画は
守らなければ
ならないのか？
photo - http://www.flickr.com/photos/richardvignola/4566774290/

32. こういう意見が多数
間に合うようにがんばって
て欲しい

33. 一方で
•丸投げはがんばれない
•開発だけでがんばれない
•いつまでもがんばれない
ただ、年に2∼3回がんばらざるをえない時期はありますよね。

34. 不可能な計画を可能にするのが
エンジニアの仕事ではない！
がんばりを続けるとつかれるリスクがあるってことです。
参考：「不可能を可能にする男」Wikipedia http://goo.gl/Riu6V
プロゴルファー猿Complete BOX-Vol.1 [DVD]: 頓宮恭子, 高木早苗, 峰あつ子: DVDhttp://amzn.to/R0jxNj

35. こういう意見も
今の見積りは余裕やゆとり
があるように見える

36. 見積もりで会話
見積りは正確に測定しないで、「間違ってたら気がついた時にフィードバックする」意識を持ってもらっていま
す。正解か不正解は重要ではなく、はやく気がつくことを重要視しているからです。

37. 見積りは確率
だが、コミット
メントは確率で
はない
楽天ブックス: アジャイルな見積りと計画づくり - マイク・コーン http://bit.ly/RhGkCO

38. 今の答え
ちゃんと計画する
計画は変更する

39. 計画
l 1∼2週間のタイムボックス
l 比較的柔軟なリリース日
l フェーズをやめる

40. ビジョン、
マイルストーン
は作る
大体の方向性とそこまでの距離は知っ
ておきたいですよね。そのためのマイ
ルストーンです。 photo - http://www.flickr.com/photos/eesti/276022325/

41. マイルストーン
的なカード 41

42. こういう意見も
今回はサービスの手触りま
で考える余裕がなかった

43. DONEの定義は？
l 作った、動いた
l レビュー終わった、UT終わった
l システムテスト終わった
l 手触りの良いサービスにしあげた

44. http://corp.rakuten.co.jp/company/message.html

45. 今日のおはなし
l 開発のチェンジ
l マインドセットのチェンジ
l 変化から習慣へ

46. 考えなおしたこと
成功と品質

47. 問い
成功とは
なんだ？
photo - http://www.flickr.com/photos/richardvignola/4566774290/

48. 成功とは？
•リリースが成功する
•バグがない
•トラブルがない

49. 今の成功とは
•仕様どおり
•ビジネス価値が正しかった
•
これを 安定 して 継続的
に 繰り返すこと

50. ユーザの信頼
最悪の選択
変 ・なにもしない
デリバリスピード
・リプレイス
更 ・お金をかけ続ける
の
技術的負債による
コ
コスト肥大
ス ギャップ
ト 理想のコスト
時間

51. 作らないへ
•大抵作ることができる
•いかに必要な物だけ作るか？

52. 問い
品質とは
なんだ？
photo - http://www.flickr.com/photos/richardvignola/4566774290/

53. 品質とは？
•仕様書通り
•バグがないこと

54. 例えば
•レガシーシステム
•単体テストなんてない状態
•どう改善するか？

55. テスト計画書
55

56. アジャイルテストの4象限
自動と手動 手動
探索的テスト
機能テスト 例として シナリオ
ストーリーテスト ユーザビリティテスト
ユーザ受け入れテスト
我々のやり方には合わない
プロトタイプ
シミュレーション アルファ / ベータ
単体テスト パフォーマンス / 負荷テスト
コンポーネントテスト セキュリティテスト
「∼性」テスト
自動 ツール

57. 自分たち用に整理
自動 手動
ユーザ受け入れテスト 探索的テスト
（UAT） ユーザビリティテスト
単体テスト（UT） パフォーマンスツール
セキュリティツール
自動 ツール

58. テストのトレードオフ
シンプルな機能
このへんは日々の画面チェック
でカバーされてた
超重要
マイナーな機能 メジャーな機能
このへんは日々の画面チェック
でカバーされてた
重要58
あきらめ対象
複雑な機能

59. 選択と集中
自動 手動
時間削減
ユーザ受け入れテスト
（UAT）
注力
探索的テスト
ユーザビリティテスト
単体テスト（UT） パフォーマンスツール
時間削減 時間削減
自動
セキュリティツール
ツール

60. 価値のある手作業へ
• 画面デザインは人の目を使う
• 手動で操作して触り心地を確かめる
• 「気づき」をFBにつなげる
「こうなっていたらいいのに」もここで洗い出し、受け入れ担当者に仕様変更か無視かの判断をしてもらう。
開発者全員で時間をあわせ、せーのでテストしていくと盛り上がる

61. ユーザ受け入れテスト
(UAT)
•117 ケース
•356 クリック
•347 チェック

62. コスト
•30min 環境作成
•30min ペアプロレクチャー
•2days + リファクタリング

63. 生まれた価値
•QA前に125バグ
•デグレード阻止多数
•QAでのバグ率0.2%

64. “Quality is value
to some person”
品質とは誰かにとっての価値である
by Gerald Weinberg
スーパーエンジニアへの道 - 技術リ-ダ-シップの人間学
ジェラルド・Ｍ．ワインバ-グ http://bit.ly/Qf2SUk

65. 今の品質
ユーザの価値
ビジネスの価値
個人の価値
どれが一つだけだと食べていけなくなっちゃう

66. 今日のおはなし
l 開発のチェンジ
l マインドセットのチェンジ
l 変化から習慣へ

67. サービス開発を
プラクティス ゴール
原則 マインド
価値 技術力
アジャイルに クラフトマンシップ？

68. 地図を捨てて
コンパスを
頼りに進め
リーンスタートアップ 解説より
1
photo- http://www.flickr.com/photos/pedrobelleza/6255124245/

69. 地図を捨てる
•地図は作るし時間もかける
•地図は変更する
•正しいを疑う

70. コンパスを頼りに
•ユーザのフィードバック
•問題に俊敏に気がづく
•少しだけ、少しづつ

71. 大体、まっすぐ進む
71
ちょっとぐらいのずれは気にしないで、大体まっすぐに進んでいること。半歩でも前に進んでいることを重視し
ています。

72. ふりかえりを活用
•週1回1時間
•課題を掘り下げる
•リリースの効果も確認

73. Velocity

74. タスクの統計

75. スピードの安定

76. DONE率 .410
初めてアジャイル開発に取り組んだチー
ムが、数カ月間でユーザーストーリーを
Doneできた割合
半分もDoneできないという気づきを得た。ただ、イチローより高い打率。

77. 20％のKPI向上
効果はモチベーションに繋がり、次のア
クションが明確になる。

78. 地図を捨てて
コンパスを
頼りに進め
1
Typhoon #14 "Nabi" ¦ Flickr - Photo Sharing! http://bit.ly/x60eXR

79. 理想の開発を
しよう

80. 地図を捨てて
コンパスを
頼りに進め
photo - http://www.flickr.com/photos/usfwssoutheast/7644512048/

81. 誰かがやってくれ
ると思うな

82. 地図を捨てて
コンパスを
頼りに進め
photo - http://www.flickr.com/photos/jannem/2079422115/

83. これまでの当たり前
を変化させよう

84. 習慣よ変われ