2012/07/03 第3回アジャイルサムライ読書会inファンコミュニケーションズ道場で発表した資料

1. の ロ
へ ゼ
発 ・
開 ンF@N
ル ョ 会 IN
イ シイ読書
ャ ー ムラ
ジ レイルサ
ア テ ジャ
イ 3 回ア
第

2. ファンコミュニケーションズ
での
アジャイル導入事例

3. シラトリです。
Twitter: shitai246_
•ファンコミュニケーションズ
技術開発部開発課 所属
•エンジニア兼マネージャー
•TDD/Scala/JoJo などの話題を振ると喜びます。

4. 2012/01
Doing
Agile

5. いろいろやってみた

6. インセプションデ
ッキ
パッケージデザインを作る
解決案を描く
エレベーターピッチを作る 夜も眠れない問題は何だろう
？
我われはなぜここにいるのか
？ 期間を見極める
やらないことリストを
何を諦めるのかはっきりさせ
作る る
「ご近所さん」を探せ
何がどれだけ必要なのか

7. refactoring
test-driven
development
red green

8. カンバン

9. い
か
上
な
手
い
く
こ
と

10. 価
値継
の続
あす
るる
物

11. いろいろありました
• インセプションデッキ
• テスト駆動開発
• 継続的インテグレーション
• カンバン
• イテレーション運営
• バーンダウンチャート
• Etc…

12. 僕はアジャイルなのか？

13. Yes!

14. じゃぁみんなは？

16. … 即答できない

17. なぜか？

18. 顧客に価値を届けているか？

19. カイゼンできているか？

20. みんなはバスに乗っているのか？

22. Doing Agile では
上手くいかないんじゃないか？

23. 2012/05
Being
Agile

24. Doing Agile ≠ Being Agile
トップダウンでアジャイルをやる
のではなく
みんながアジャイルになる

25. Doing Agile ≠ Being Agile
ぼくのかんがえたさいきょうのかいはつ
ではなく
みんなでかんがえるさいこうのかいはつ
を目指す

26. アジャイル推進 MTG

27. アジャイル推進 MTG
 アジャイル開発を推進していく上での課題を共有し
、
自分たちの”アジャイル”を模索していく場
 隔週開催（毎月第１・３水曜日）

28. 一
番
の
問
題

29. みんながバスに乗らない

30. ､ --‐ 冖‘⌒￣￣ ` ｰ - ､
／⌒ ` 三ミヽｰ - ﾍ ,_
__,{ ;;,, ミミ ｉ ´Z,
ゝ ’‘〃 //,,, ,,.. ｀ミﾐ､ _ ノリ }j; f 彡
_) 〃 ///, ,; 彡’ rff ｯ､ｨ彡‘ﾉ从 i ﾉ彡
>’;;,, ノ丿川 j ! 川｜ ; :.`7 ﾗ公 ‘ > 了
_ く彡川 f ﾞノ’ノﾉ ノ _ ノノﾉイシﾉ｜ }.: ‘〈八ﾐ､､ ;.)
ヽ .:.:.:.:.:.;= ､彡／‐ - ニ’‘ _ ｰ＜、 {_, ﾉ - 一ヾ `~;.;.; ）
く .:.:.:.:.:! ﾊ .Y イ ぇ’无ﾃ ,` ヽ｝｝ } ィ t 于 ｀ | ィ“ ~
):.:.:.:.:|.Y }: :! ｀二 ´/‘ ; | 丶ﾆ ﾉﾉ
） :.: ﾄ､リ : :! ヾ : 、 丶 ; | ﾞ ｲ :} 逆に考えるんだ
｛ .:.: ｌ ｛ : : } ｀ ,.__(__,} / ﾉ
ヽ ! `’ ﾞ ! ,.,,.` 三‘ﾞ､ ,_ /´ 「みんなをバスに乗せなくたっ
ていいや」と
,/´{ ﾐ l / ﾞ ,:-…- ～､ ） |
,r{ ＼ ﾐ ＼ `' '≡≡' " ﾉ 考えるんだ
__ ノ ヽ ＼ ヽ＼ 彡 , ｲ _
＼ ＼ ヽ 丶 . ノ !| ヽ｀ヽ、
＼ ＼ヽ ｀ ¨¨¨¨´/ | ｌ ト､ ｀ ' ｰ - ､ __
＼ ｀ ' ｰ - ､ / ／ /:.:.} ｀ ' ｰ､ _
｀､＼ ／⌒ヽ /!:.:.|
｀､ ＼ / ヽ L ｆ ___ ハ / {
′ / ! ヽ

31. みんなをバスに乗せない
 最初から全員に気持ち良く乗ってもらうのは不可能
 そんな方法があるなら教えて欲しい…
 無理に乗せても良いものは生まれない
 最初はバスに乗ってくれるメンバーだけで発車する
 とにかく結果を出し、理解を得るよう努める
 バスに乗る気になった人は歓迎し、対等に扱う
 古株だから偉いとかは無い

32. アジャイル推進 MTG
 アジャイル開発を推進していく上での課題を共有し
、
自分たちの”アジャイル”を模索していく場
 隔週開催（毎月第１・３水曜日）
 参加自由

33. 実際に、やってみた

34. 参加自由にして良かったこと
 意外に参加人数が多い
 参加率 5 割超え！正社員の半分以上が参加。
 前向きな意見がたくさん出る
 MTG で発言しない人がいない
 次のチャレンジが明確になる
 課題や良かったことがきちんと共有できるため
次のチャレンジも明確になる

35. 大
事
な
こ
と

36. みんなでコミットする

37. p44
チームメンバーが
誰もいないところ
で合意したことを
前提にしているか
ら、
プロジェクトがだ
めになるんだ

38. 新
試た
みな
、

39. ① ペアプロタイム
 試験導入中
 社歴の短い人が多く、ノウハウ共有に課題があるため
 ペアプロを申し込まれたら断ってはいけない時間
 申し込まれる側はベテラン 3 人に固定
 障害対応とかどうしようもない場合は例外
 ペアプロする作業は申し込む側が提案する
 自分の抱えている作業で OK
 実際にペアプロしたらフィードバックをもらう
 今後どう展開していくか、辞めるのかの判断基準に

40. ポイント！
 申し込まれたら断ってはいけない人がいるだけで
申し込まないといけない時間ではない
 そもそも試験導入中
 リスクを冒して失敗したら次がなくなる
 本当に効果があるのか半信半疑
 「はい二人組くんでー」にはしない
 それは反則です
 ペアを組みたくない人もいるかも？
 数時間単位で全員の予定を固定するのは難しい

41. ② ディスカッション形式テスト設計
 ディスカッション形式でテスト設計をします（その
まんま）
 ざっくりとした手順
 要件・仕様を確認する
 要求品質は何か確認する
 機能要件・非機能要件を整理する
 どんなテストが必要なのか議論する
 テスト項目の洗い出し方を議論する
 どこまでの品質なら許容できるのか議論する
 以上をディスカッション形式で決めていく

42. ポイント！
 テストの知識がある人を１人は参加させる
 新人ばかりでやっても非機能要件や異常系が漏れる
 ファシリテートの上手いテストエンジニアがいると良さそう
 「他に非機能要件ないよね？」の一言が大事
 細かいテスト項目の話はしない
 ちゃんと設計が出来ていればテスト項目の精度も上がる
 事前に叩き台を作らない
 モノがあるとレビューになってしまう
 レビュー形式で対等な会話をするのは難しい
 「プロジェクトの最初」と「テストをやる前」に実施す
る

43. ③ インセプションデッキ
 プロジェクトメンバー全員（ PO ､ PM ､開発者）を
集め、
その場でインセプションデッキを作っていく
 サクサク進めても 3 時間くらいはかかる
 プロジェクトによっては全ての問いに答えなくても
OK
 どの問いに答えるかもメンバー全員で決めていく

44. ポイント！
 必ずメンバー全員でコミットをとる
 部署を跨ると全員に参加してもらうのが難しかったりす
る
 全員参加できてないときは “仮コミット” 扱いにし
後で PM が個別に調整していく
 ファシリテート重要
 人数が多ければ多いほど発言する人は偏る
 「じゃぁこれでいいですかー次いきますよー」に対して
ちゃんと反応してくれない人が結構いる

45. ま
と
め

46. まとめ
 みんなをバスに乗せない
 無理にバスに乗せても良いものは生まれない
 バスに乗る気になった人は歓迎する
 みんなでコミットする
 メンバーがいないところでの合意が無価値なの
は
開発プロジェクトでもアジャイル導入でも同じ
 そのためにファシリテートが重要