長崎ＩＴ技術者会　第１０回勉強会　「Turnip＆アジャイルプラクティス導入事例＆メトリクス入門」　発表資料です。

1. アジャイルプラクティス
導入事例
長崎IT技術者会 第10回勉強会 2016.1.23

2. 自己紹介
名前：角田 俊（つのだ しゅん）
コミュニティ：長崎IT技術者会
Twitter：＠imtnd
勤務先：通信系製造業
業務：ソフトウェア開発 ４年目

3. 今日の話の目的
アジャイルのプラクティスを導入して経験し
て得た知見の共有
（本資料は個人的感想と、個人的見解によって書かれています）

4. アジャイル
アジャイルソフトウェア開発 (アジャイルソフトウェアか
いはつ、英: agile software development) は、ソフトウェ
ア工学において迅速かつ適応的にソフトウェア開発を行う
軽量な開発手法群の総称である。
Wikipediaより

5. ウォータフォールとの違い
期間とゴールを細かく設定し見通し、今見通
せる期間で作業を行う
最初から大きな物の完成を目指さず、小さな
機能の本当に必要なものから作成を行う

6. ウォータフォール開発 アジャイル開発
ウォータフォールとの違い

7. アジャイル開発プロセス
アジャイル開発プロセスとは、より柔軟にソ
フトウェアの要求の変更に対応できるように
するための開発手法例
アジャイル開発手法の代表例
スクラム
エクストリームプログラミング

8. アジャイル開発プラクティス
アジャイル開発プラクティスとは、アジャイ
ル開発プロセス内で定義されている具体的な
実践方法
先人達のより良いソフトウェアの開発手法例

9. アジャイル開発プラクティス
アジャイルのプラクティスをただ実践している
ウォータフォール開発
！＝ アジャイルのプラクティスが適応出来ない
！＝ アジャイル開発

10. 質問
10

11. 質問
現状のソフトウェア開発の方法で不満を
感じることはないですか？

12. 質問
より良い開発手法を試してみたくないで
すか？

13. もし、今のやり方で上手く行っ
ていないのであれば……

14. アジャイル開発のプラクティス
を試してみよう

15. 導入事例紹介

16. プロジェクト概要
5人の開発メンバで、スキルや年齢はバラバラ
動作確認ができることを優先して、動く部分
からソフトウェアの作成を行う
開発規模が小さくパイロットプロジェクトと
しては最適

17. 導入したプラクティス
タスクかんばん
バーンダウンチャート
デイリースタンドアップ
ペアプログラミング
テスト駆動開発
プランニングポーカー

18. タスクかんばん
http://www.infoq.com/jp/articles/hiranabe-lean-agile-kanban

19. タスクかんばん
付箋紙にチームのやるべきタスクを書き出す
タスクをTODO,DOING,DONEに分けて可視化する
TODO 担当者 DOING DONE
タスク４
タスク５
タスク６
タスク７
タスク８
タスク９
タスク１０
タスク１
タスク２
タスク３
A
B
C

20. 良かったこと
誰が何の作業をしているのか全員が一目で分かる
残タスク、終了タスクが分かりやすい
アラートを挙げなくても困っていそうなときは周
りが分かる
例
タスクがDOINGから長期間動かない
→ 問題が発生している可能性がある事が一目で分かる

21. 発生した問題
プロジェクトが終盤になり、忙しくなってく
ると、かんばんが移動されないことがある

22. 発生した問題
プロジェクトが終盤になり、忙しくなってく
ると、かんばんが移動されないことがある
→自分が今どんなタスクをしているのか主張
し、共有するという気持ちを持つ事が必要

23. 発生した問題
プロジェクトが進むと、小さなタスクが発生
するが、どの程度のタスクからかんばんにす
べきか難しい
簡単なタスクはかんばん作るもの面倒くさくなっ
てくる

24. 発生した問題
→ 最初はどんなタスクもかんばんにしておくと良い
自分が何をしたのかのエビデンスとなる
プロジェクトが進むと、小さなタスクが発生
するが、どの程度のタスクからかんばんにす
べきか難しい
簡単なタスクはかんばん作るもの面倒くさくなっ
てくる

25. バーンダウンチャート
http://www.infoq.com/jp/articles/agile-kanban-boards?r=1&l=ri&fst=0

26. バーンダウンチャート
終了タスクをグラフ化する
縦軸：タスク量
横軸：作業開始日から終了日までの日付
タスク数から終了日まで一直線に引いた線が
予定となる
進 率、予定と実績の差分が可視化される

27. 良かったこと
一目で現在の進 が把握できる
チームとしての作業遅延がメンバ全員に分か
る
いつ、どのタスクが原因で作業が遅れ始めた
のかという事が分かりやすく可視化される
進 状態に嘘がなくなる

28. デイリースタンドアップ
http://bliki-ja.github.io/ItsNotJustStandingUp/

29. デイリースタンドアップ
決まった時間に全員参加でミーティングを開く
全員で立って行う
時間は１５分程度で「昨日やったこと」、「今
日やること」、「共有しておくべき情報」を話
す
簡単に結論の出ない議題が出たら別途話し合い
を設ける

30. 良かったこと
進 と、今日何やるかが毎日共有される
問題点が発生した場合は毎日共有される
全員が立ったままミーティングを行うことで話
し合いが長くならない
話が長くなりそうな時は別途機会を設けること
で、決めるべき結論を共有できた会議が開ける

31. ペアプログラミング
http://hiroki.jp/2011/07/05/2009/

32. ペアプログラミング
二人一組でプログラミングを行う
担当をドライバーとナビゲーターに分けて交
代しながら行う
ペア自体も時間を決めて流動的に組み直す

33. 良かったこと
作成物に関して開発メンバ2人以上の同意の上
で作成される
ソースコードの属人性が排除される
ソースコードに所有権がなくなる
分かりやすい綺麗なソースコードが成果物と
して残る

34. 発生した問題
経歴、年齢バラバラなペアでは抵抗感がある

35. 発生した問題
経歴、年齢バラバラなペアでは抵抗感がある
→ そのプロジェクトにペアプログラミング
が向いているのかは、開発メンバ次第

36. 発生した問題
最初は１時間区切りで、ペアの役割を交代、
ペアの組み換えと決めていたが、タスクの進
上難しかった

37. 発生した問題
→ ペアを流動的にすることは必要だが、
交代基準は現場により話し合って考える必要がある
最初は１時間区切りで、ペアの役割を交代、
ペアの組み換えと決めていたが、タスクの進
上難しかった

38. テスト駆動開発
http://qiita.com/masakinihirota/items/80a29d91618a3669bf9a

39. テスト駆動開発
達成すべきテストコードを記述し、それを達
成するソースコードを作成する
テストコードが達成されたら、成果物のソー
スコードを見直す
修正を入れた後にも、最初に作成したテスト
コードがNGとならないことを確認する

40. 良かったこと
作成すべきものが明確になる
作成物コードを書いた後、すぐにどう動作す
るのかのフィードバッグが得られる(安心感)
リファクタリングをプロセスに組み込む事で、
綺麗なソースコードが残る

41. 発生した問題
テストを先に書くのに抵抗がある

42. 発生した問題
→ 個人的には、テストは後でも良いと思っている
TDDの目的はフィードバッグを早く得ること
すぐにコーディングのフィードバッグを得ることで
バグの原因の特定が早くなる
テストを先に書くのに抵抗がある

43. プランニングポーカー
http://alpha.mixi.co.jp/entry/2012/10857/

44. プランニングポーカー
専用のカードを用いて見積もる
開発メンバ全員で見積もりを行う
見積もりの値が開いていた場合は認識のズレ
がある可能性があるため話し合う

45. やってみよう

46. お題
一人でメモ帳アプリケーションの作成を任さ
れました
自分で考えて見積もりを出してください
ポーカの「１」を半日とする

47. どうでしたか？
人それぞれ見積もりがバラバラではないですか?
メモ帳アプリといっても人により認識は様々
見積もりを出したからには根拠がある
見積もりがバラバラということは認識がずれ
ている可能性がある
→ 認識を合わせるため話し合う

48. 良かったこと
見積もり時の属人性の排除
見積もりを通して認識の共有が行える
開発メンバの平均スキルで見積もる
スキルが高い人が見積もると、その見積もり
通りにはならない

49. 最後に

50. 全体を通しての感想
個人で仕事をするという認識を捨て、チーム
で仕事をしているという認識を持つことが必
要
人間的に積極性などを求められる

51. 導入のススメ
アジャイル開発のプラクティスを導入してみ
ることで、現状でのやり方の課題と改善策が
見つかるかもしれない
大切なのは、今の課題を見つけて改善策を常
に模索していくこと