10月30日アジャイル開発実践セミナーのスライド

1. いちたに としひろ
市谷 聡啓
・東京でSI、受託開発(永和システムマネジメント所属)
・開発現場のためのコミュニティDevLOVE主催
・「リーン開発の現場」翻訳しました
twitter : @papanda
2013年10月31日木曜日

2. 正しいものを、正しく作る
2013年10月31日木曜日

3. 開発現場のためのコミュニティ
・1600名
・2008年から5年半運営、全142回
・東京/神奈川/名古屋/仙台/大阪/四国
http://www.devlove.org
2013年10月31日木曜日

4. 監訳 角谷信太郎
共訳 市谷聡啓
藤原大
・10月26日発売
・電子版もあります
・リーン開発の実践記
・現実的な作戦
・大規模プロジェクト
・カンバンの活用
・平鍋健児の解説
2013年10月31日木曜日

5. 課題からみるプラクティス実践例1
2013年10月31日木曜日

6. よくある課題
ソフトウェア開発を
襲うコスト問題。
なぜ、開発コストは
超過してしまうのか？
2013年10月31日木曜日

7. よくある課題
ソフトウェア開発を
襲うコスト問題。
なぜ、開発コストは
超過してしまうのか？
要するに想定以上のことをしている
2013年10月31日木曜日

8. よくある問題
開発が想定を超えてしまう理由
2013年10月31日木曜日

9. よくある問題
開発が想定を超えてしまう理由
①作ったモノが顧客にとって必要
では無かったことが作ってから判
明する。やり直しになる。
②顧客にとって必要なモノの定義
があいまいでやり直しが終わらな
い。
2013年10月31日木曜日

10. リファレンスガイドの
「5. 活用のポイント」を参考にする
2013年10月31日木曜日

11. 事例から学ぶ
作ったモノが顧客に
とって必要では
必要ないものを
作るムダをなくす
無かったことが
作ってから判明する。
作るモノへの認識の
相違を無くす
顧客にとって
必要なモノの定義が
あいまいでやり直しが
終わらない。
2013年10月31日木曜日
作っているものが
正しいモノ
か検証する

12. 事例から学ぶ
作ったモノが顧客に
とって必要では
必要ないものを
作るムダをなくす
無かったことが
作ってから判明する。
作るモノへの認識の
相違を無くす
顧客にとって
必要なモノの定義が
あいまいでやり直しが
終わらない。
2013年10月31日木曜日
作っているものが
正しいモノ
か検証する

13. 事例から学ぶ
作ったモノが顧客に
とって必要では
必要ないものを
作るムダをなくす
無かったことが
作ってから判明する。
作るモノへの認識の
相違を無くす
顧客にとって
必要なモノの定義が
あいまいでやり直しが
終わらない。
2013年10月31日木曜日
作っているものが
正しいモノ
か検証する

14. 事例から学ぶ
作ったモノが顧客に
とって必要では
必要ないものを
作るムダをなくす
無かったことが
作ってから判明する。
作るモノへの認識の
相違を無くす
顧客にとって
必要なモノの定義が
あいまいでやり直しが
終わらない。
2013年10月31日木曜日
作っているものが
正しいモノ
か検証する

15. 調査事例における対応策
必要ないものを
作るムダをなくす
何がどれから(欲しい)
という要求を管理する
活用するプラクティス
プロダクトバックログ(優先順位付け)
プロダクトとして何を作るべきかをリストで管理し、その優先順
位をチームとの会話を踏まえ、プロダクトオーナーに判断しても
らう。その結果、チームは何から開発を行えばよいか明確にな
る。
2013年10月31日木曜日

16. Pivotal Tracker
2013年10月31日木曜日

17. カンバンボード
http://ja.wikipedia.org/wiki/かんばん_(ソフトウェア開発)
2013年10月31日木曜日

18. 調査事例における対応策
必要ないものを
作るムダをなくす
何がどれから(欲しい)
という要求を管理する
活用するプラクティス
プロダクトバックログ(優先順位付け)
プロダクトとして何を作るべきかをリストで管理し、その優先順
位をチームとの会話を踏まえ、プロダクトオーナーに判断しても
らう。その結果、チームは何から開発を行えばよいか明確にな
る。 チーム全員がいつでも状態を把握できること
2013年10月31日木曜日

19. 調査事例における対応策
作るモノへの認識の
相違を無くす
認識の相違が生まれる
期間をできるだけ
短くする
活用するプラクティス
迅速なフィードバック
アウトプットが適切かどうかわかりにくい時は、迅速なフィードバックを心掛ける。その
結果、現状把握と軌道修正がしやすくなる。
オンサイト顧客
開発者と顧客が常に会話ができる環境で仕事をしよう。その結果、顧客と開発者のコミュ
ニケーション量が増えて、顧客が望むソフトウェアが作られやすくなる。
スプリントレビュー
イテレーションの終わりに完了したものを関係者にデモをする。その結果、チームは次の
イテレーションで何をするべきかフィードバックを得る。
2013年10月31日木曜日

20. 調査事例における対応策
作っているものが
正しいモノ
か検証する
正しさの基準(顧客の意
図する働き)を作り
機能の仕様が合致して
いるか確認する
活用するプラクティス
受入テスト
ユーザーストーリーが完了したかを判定するために、プロダクト
オーナーと合意した受入テストを作成する。その結果、ユーザー
ストーリーの完了条件が明確になり開発チームとプロダクトオー
ナー間の認識の齟齬がなくなる。
2013年10月31日木曜日

21. 2013年10月31日木曜日

22. <サンプル>
2013年10月31日木曜日

23. <サンプル>
ユーザーストーリー
＜ユーザーの種類＞として
＜達成したいゴール＞したい
なぜなら＜理由/動機＞だからだ
完了条件
2013年10月31日木曜日

24. 調査事例における対応策
作っているものが
正しいモノ
か検証する
正しさの基準(顧客の意
図する働き)を作り
機能の仕様が合致して
いるか確認する
活用するプラクティス
受入テスト
ユーザーストーリーが完了したかを判定するために、プロダクト
オーナーと合意した受入テストを作成する。その結果、ユーザー
ストーリーの完了条件が明確になり開発チームとプロダクトオー
ナー間の認識の齟齬がなくなる。
完了条件が明確になっている=開発準備ができている
2013年10月31日木曜日

25. 開発準備OK
開発対象の機能について、
・関連ドキュメントがどれか分かっている。
・連絡窓口が決まっている(対象について業務知識
が豊富な人)。
・顧客に価値をもたらすこと。
・チームによって見積もられていること。
・受け入れテストのシナリオが
書かれていること。
「リーン開発の現場」より
2013年10月31日木曜日

26. ダイアログ
<5分>
自己紹介
1. 普段のお仕事
2. 本セミナーへの期待
話しあってみよう
<20分>
以下についてグループ内で話しあってください。
1. 「コスト問題」はなぜ起きるか
2. 「コスト問題」にどのような対処ができるか
3. 「紹介したプラクティス」から現場でできることは何か
グループ共有
各グループからどんな議論が出たか共有してもらいます。
2013年10月31日木曜日
<5分>

27. 約束事
・目的は、相手の意見を聴いて、
様々な見方を知る。
→自分の意見を押し付けたり、
どっちが勝ったという議論ではない
・1人の人が話し過ぎない。
→目的を忘れずに
・いつもより心持ち、うなずき多めに。
→うなずきがあると話しやすい
2013年10月31日木曜日

28. プロダクトバックログ(優先順位付け)
プロダクトバックログは、全体の71%の事例で適用されていた。
特に中大規模では90%以上が適用していたが、受託開発での適用
は約50%に滞っていた(スコープの考え方)。
B社事例(2)では、プロダクトバックログの順序について、最終的な判断はプロダクト
オーナーが行っていたが、管理はチームメンバーが代行していた。優先順位の基準は、
インセプションデッキで作った際の、プロダクトのビジョンを用いた。
C社事例(4)では、最低限なくてはならない必須機能と、あれば良いという機能を明確に
分けて、プロダクトバックログで管理した。最初は、欲しいものから項目を洗い出し、
プロジェクトの途中からは、予算から判断して必要な機能に絞るようにした。
G社事例(9)(10)では、プロダクトバックログアイテムの管理に、ユーザーストーリー
マップ（ユーザーの行動に即してユーザーストーリーを洗い出して整理した図）を主とし
て活用している。プロダクトオーナーとはユーザーストーリーマップを使って、コミュニ
ケーションを取っていた。
2013年10月31日木曜日

29. 迅速なフィードバック
B社事例(2)では、共通の部屋やオンサイト顧客などのプラクティスで迅速なフィード
バックを得られるようにし、開発チームとプロダクトオーナーのコミュニケーションを
密にしたところ、緊急対応などの無理な要求が発生して、チームが要求の対応に追われ
てしまい、結果的に開発チームが集中できない状況になってしまった。
F社事例(8)では、カナリア環境と呼ぶ実行環境を用意している。希望ユーザーに機能を
本実装する前のプロトタイプを利用してもらい、その機能についての要望を収集し
フィードバックを得ることができる。
スプリントレビュー
B社事例(2)では、朝会でステークホルダーにデモをしていた。そのため、スプリントレ
ビューは対象機能の完了を確認するのみとし、デモは行わないことにした。
B社事例(3)では、「完了」の定義を作成していなかったため、確認があいまいとなって
しまった。
G社事例(9)では、デモに時間がかかり過ぎていたため、受入テストツールを使ったテ
ストシナリオを事前にスプリントレビュー参加者に共有することで、デモの実施時間を
短縮することができた。
2013年10月31日木曜日

30. 受入テスト
受入テストは、全体で44%の事例で適用されていた。そのうち自
動化を実現している事例はさらに少数であった。
A社事例(1)では、受入テストの自動化は実施しておらず、プロダクトオーナーと正常系
のエンド・ツー・エンドテストを手動で行っていた。
G社事例(10)では、受入テストツールのCucumberを用いた。日本語を用いてテストシナ
リオを書き、それを元に受入テストの自動化を行った。テストシナリオを開発チームと
プロダクトオーナーの間で合意しているため受入テストの成功がユーザーストーリー完了
の条件になっていた。受入テストは何度も実施していたが、プロダクトオーナーにテスト
結果を公開することはしていなかった。プロダクトオーナーが信頼して開発チームに任せ
ていたためである。
K社事例(20)では、プロダクトオーナーからテスト作業はできないとの申し入れがあっ
た。テストシナリオを確認することは問題ないが、膨大な量のテストは実施してはもら
えないため、開発チームが受入テストを実施した。
Redmineに仕様、受け入れ条件や制約を記述している。遠隔地にいるプロダクトオー
ナーがその内容を確認したり、印刷したりすることができるようにした。
2013年10月31日木曜日