2015年5月27日に開催した名古屋アジャイル勉強会の資料です。

1. 「検査」、してますか？
2015/05/29
名古屋アジャイル勉強会
山本 博之
http://www.irasutoya.com/

2. 2
自己紹介
● 山本 博之(やまもと ひろゆき)
● 先日50才になりました！
●
金融系システムのデータ移行支援の仕事をしてい
ます。
– プログラミング機会がほぼ無くなってしまって悲しい！
●
仕事で行っているテストや検査：
生産物は都度グループ内で相互レビューしていま
す。でも、いろいろ仕様が決まっていないところが多
くペンディング事項だらけで危機感半端ないです。

3. 3
アジェンダ
● 「検査」、してますか？/今日の目的
●
自己紹介
●
アジャイル開発における「検査」と例
●
アジャイル開発以前のソフトウェア開発と、アジャイ
ル開発におけるテストの考え方
●
ワークショップ：検査してみよう
●
まとめ

4. 4
「検査」、してますか？
●
みなさんは「検査」と聞いてどんなことを思い浮かべま
すか？
– 視力や聴力の計測？
– 病気の診断？
– あるいは建物や機械の安全確認？
●
ソフトウェア開発で検査といえば、製品やシステムが仕
様通り問題なく動作するかの確認（テスト）作業ですね。
●
「検査」「テスト」というと、最終段階で問題の有無を見
極めること、場合によっては不合格になってしまう「関
門」というイメージがあるかもしれません。

5. 5
今日の目的
●
しかし、アジャイル開発での「検査」の捉え方は違い
ます。アジャイル開発における「検査」はプロジェクト
のエンジンとも言えるものです。これをみていきま
しょう。
●
今日の目的：
– アジャイル開発における、「検査」の位置付け、考え方を
学びます。
– その考え方を明日からの仕事に活かす方法を考えてみ
ます。

6. 6
自己紹介
●
ここで、みなさんに自己紹介をしていただきます。
● 以下をA3用紙に書いてください
– お名前（本名でなくてかまいません）
– お仕事（お話できる範囲でかまいません）
– 仕事でどんなテストや検査を行っていますか?
●
書けたら順番に自己紹介してください

7. 7
アジャイル開発における「検査」
●
代表的なアジャイル開発手法である「スクラム」に
は、三本の柱があるとされています：
– 検査
– 適応
– 透明性
●
プロダクト（製品）やプロセス（やチーム）を検査し、
適応させます（改善します）。検査と適応が容易で
あるために、検査対象や検査結果の透明性が重要
です。

8. 8
アジャイル開発における「検査」
●
そもそもなぜ適応が必要なのでしょうか。ユーザが
求めているものを探求しなければならないから、技
術的あるいはスケジュール的な困難や制約に対応
しなければならないから、などなど。
●
固定的なやり方ではうまくいきません。
●
アジャイル開発では、プロダクトやプロジェクトをさ
まざまなタイミングで、さまざまな方法で検査し、適
応のきっかけを探します。
●
その例をいくつか、みていきましょう。

9. 9
例：朝会
● 毎日スタンドアップで行う10分程度のミーティングで
す。3つの質問に、参加者が答えます。
– 昨日行なったことはなにか
– 今日行なうことはなにか
– 問題点があるならそれはなにか
●
この質問こそが、「検査」に
他なりません。この検査は、
メンバーのタスク実行状況を
確認して、サポートや場合に
よっては進め方やスケジュール
などの見直しを行う入力に
なります。 http://www.objectclub.jp/ml-
arch/magazine/magazine105/meeting.jpg

10. 10
例：ニコニコカレンダー
●
メンバー別の行と、日毎の列のマトリクスに、毎日退
社時に、その日の自分の仕事に対する「気分」をシー
ルあるいは手書きのフェイスマークで書き込みます。
●
これはよりシンプルな
「検査」の例であると
言えるでしょう。
●
気持よく仕事ができて
いるかどうかを見える化し、
原因の分析と対策の
トリガーになります。
http://www.geocities.jp/nikonikocalendar/pics_j
a/jirei.JPG

11. 11
例：ふりかえり
● スプリント（1〜4週間程度の、開発の基本単位であ
る期間)終了時に、その期間のできごとをふりかえ
り、うまくいった続けたいこと、問題点、改善策や新
たに試したいアイデアを話し合います。
●
ここで挙げられて
採用された改善策は、
次のイテレーションで
実施して、その結果は
また次のふりかえりで
評価・フォローします。
http://cdn-ak.f.st-hatena.com/images/fotolife/y/youandi/20120727/20120727202736.jpg

12. 12
例：常時テスト
● Jenkinsなどのツールを使えば、定期的（毎日、毎
時、ソースコードに変更があるたび、など）にテスト
実行を行うことができます。
https://wiki.jenkins-ci.org/display/JENKINS/Stickers
●
ここでいうテストは、単体テストや機能
テストなどの動的テスト（プログラムが
期待通りに動作するかの確認）も含み
ますし、ソースコードの静的解析（バグと
は言えないまでも、その温床となりうる、
好ましくない記述などを見つけるなど）
やテストのカバー範囲の計測も含める
ことができます。

13. 13
例：常時テスト
●
こういった自動テストでは、テストの失敗は、メール
やメッセンジャーを通じて開発者に直ちに通知され
対処されます。
●
また静的解析の結果から、適切なタイミングでの
コードやテストのクリーンアップのタイミングを知る
ことができます。
https://wiki.jenkins-ci.org/display/JENKINS/Stickers

14. 14
アジャイル開発における「検査」
●
さまざまなタイミング・方法で、プロダクトやプロジェ
クトの状態を把握し、それによって得た知見を適応
に利用します。
●
これを繰り返していきます。
●
そういう「流れ」を作り、円滑に回していくこと、プロ
ダクトとプロセスを成熟させていくことこそが、アジャ
イルな考え方なのです。

15. 15
ここまでの理解度チェック
●
ここまで、アジャイル開発における「検査」を見てきま
した。
●
ここまでのみなさんの理解をじゃんけん（グー、チョ
キ、パー）で確認したいと思います。
– グー：さっぱり分からない。ちょっと待ってください
– チョキ：大体分かった。進めてください。
– パー：完璧に理解しました。
●
質問などあればお願いします。

16. 16
ソフトウェア開発におけるテスト
●
あらためて、ソフトウェア開発におけるテストについ
て考えてみたいと思います。
●
アジャイル以前のソフトウェア開発におけるテスト
と、アジャイル開発におけるテストの考え方をみてい
きます。

17. 17
アジャイル以前の考え方
●
アジャイル以前のソフトウェア開発におけるテストの
考えかたは、「仕様をください、テストしますので」と
いうものでした。
●
ですから、仕様が固まるまで、テストを行うことはで
きません、往々にして、仕様が固まるのは実装も固
まった頃（プロジェクト後半）であり、テストも設計や
準備が必要ですから、テストが実施されるのはプロ
ジェクトの最後の時期になってしまいます。
●
プロジェクトの最後では、テストからのフィードバック
を活かすことはほぼ不可能です。バグを直すのがせ
いぜいでしょう。これはプロジェクトにとって残念な
ことです。

18. 18
アジャイル開発では
●
では、アジャイル開発ではどうでしょうか。
●
アジャイル開発では、ユーザーストーリーと呼ばれる、ユー
ザー視点で表現した要求事項の短い文章を開発の単位・出
発点とします。
●
ユーザーストーリーを具体的にするために、開発者とユー
ザー（の代表者または代理であるプロダクトオーナー）は対
話を重ねていきます。ここにテストエンジニア（開発者が兼任
しているかもしれません）も参加し、ユーザーストーリーが実
現できているとはどういうことか、それを確認できるためには
どのような工夫をすればよいのかを探っていきます。
●
そして、テストは製品と並行して設計・開発され、継続的に実
施されます。こうした意味で、アジャイル開発は、「ミニ・ウォー
ターフォール」（の繰り返し）ではありません。

19. 19
完成の定義
●
ちなみに、ユーザーストーリーには「完成の定義」があり、完成してい
るかしていないかのいずれかしかありません。「８０%完成しました」
ということはないのです。
●
完成の定義とは、
– ユーザーストーリーの「満足条件」が満たされていること。満足条件は「受け
入れ条件」とも呼ばれ、期待されるプロダクトの振る舞いをユーザー視点で
記述したもので、ユーザーストーリーを記述する際に合わせて作成します。
– やるべきことはすべて行われていること。開発の諸作業、テスト、ドキュメン
テーションなど、開発組織の慣習・標準などを含みます。
●
ストーリーが完了している＝ユーザーに提供するにあたり、なにも残
課題はないと言えるためのチェック項目のリストが完了の定義です。
●
完了の定義についてメンバーが共通の理解を持ち、透明性（状態が
「見える化」されていること）を確保する必要があります。

20. 20
ワーク：テストを行ってみよう
●
それではここで、実際にテストを体験してみたいと思
います。
●
手順は以下の通りです。
– 1. お題を出しますので、完成の条件（なにが満足されれば
よいか、やるべきことはなにか）を話しあって、リストを作成
してください。
– 2. 実際に作業を行なってください。作業の結果を書き出し
てください。
– 3. 作業の結果を評価し、完成の条件を満足できたか、話し
あってください。改善点についても話しあってください。

21. 21
サイコロを検査してみよう
●
サイコロをひとりひとつづつ持ち、それを同時に振ります。出
る目の合計の数を予想します。
●
予想を検査する方法を、グループで話しあってください。
– 出目が予想できたとは、どういうことでしょうか？
– それを確認するために行うべきことはなんでしょうか？
– 確認結果は目に見えるようにしてください。
●
実際に検査してみてください。
●
結果はどうなりましたか？
予想は「完了」できましたか？
●
改善点がありましたか？
http://www.irasutoya.com/

22. 22
まとめ
●
アジャイル開発では、検査と適応を継続的に行うこと
で、プロダクトとプロセスを成熟させていきます。
●
検査はフリーズされた仕様やルールに対して後から
行うよりも、仕様やプロセスを探索しながら行ってい
くことで、より豊かなフィードバックを得ることができ
ます。
●
ユーザーストーリーをベースしたアジャイル開発で
は、満足条件を一緒に考え、それを満たすこと、やる
べきことをすべて行うことを完了と考えます。完了に
ついての理解を共有し、状態の透明性を求めます。

23. 23
参考資料・文献
●
エッセンシャルスクラム
– Kenneth S. Rubin 著、岡澤裕二他訳、翔泳社刊
●
スクラムガイド
– Ken Schwaber、Jeff Sutherland著、角征典訳
– http://www.scrumguides.org/docs/scrumguide/v1/Scrum
-Guide-JA.pdf
● 「完成（Done）」の定義のさまざまな側面
– Savita Pahuja著、笹井崇司訳
– http://www.infoq.com/jp/news/2015/03/definition-of-done