アジャイルテストのテスト設計の話
Incremental test design
昨年度追加されたISTQBのFoundation Level Extension Syllabus Agile TesterのAgile Testing Practicesの項にはテスト設計に関する興味深い記述がある [1]。
Incremental test design: Test cases and charters are gradually built from user stories and other test bases, starting with simple tests and moving toward more complex ones.
アジャイルテストのテスト設計の特徴として
- ユーザーストーリーをテストベースとして用いる事
- シンプルなテストケースの追加から始まり、より複雑なものへと変化して行く事
- Incrementalである事
が挙げられている。
アジャイルテストについておさらい
アジャイルでは顧客に価値を届ける最小単位の要求をユーザーストーリーと呼ぶ。スプリント等と呼ばれるタイムボックスの中で、複数のユーザーストーリーの開発を行う[2]。
アジャイルテストではこのユーザーストーリーをテストベースとして用いる。ユーザーストーリーに記載されている顧客目線でのシステムの期待される振る舞いを、テスターはテスト可能なストーリーへと変換する。ExampleやBDDなどの記法とコミュニケーションを通じて顧客、開発者、テスター間で期待するシステムの仕様について合意する[3]。また、シンプルなハッピーパスのテストから始め、そのテストがパスしてからエッジケース等の複雑なテストケースに進む[4]。
厳密にはアジャイルテストではないが、アジャイルテストの原型となっているのがテスト駆動開発(TDD)だ。テストを先に書く事によってレビューとリファクタリングを繰り返しながら設計を改善していく事が可能であると言われている [5]。
アジャイルテストにはもう一つ、アジャイルテスト４象限という大切な概念がある。アジャイルテストが取り扱うテストを４つのグループにカテゴライズし、テスト計画を立てて行くというものだ[6]。
- 開発者のためのテスト=内部品質
- 顧客のためのテスト=利用時品質
のようにカテゴライズし、それらのテストをいつどのように実施するか計画を立てる事を推奨している。
アジャイルテストのテスト設計の特徴
これらを踏まえ、アジャイルテストのテスト設計には以下の特徴がある。
顧客のテスト設計への参加
アジャイルテストでの重要なテスターの役割は、顧客のビジネス的なシステムへの要求を非エンジニアである顧客にも理解可能なExampleやテストに変換する事だ。これにより、テスト設計への顧客の参加が可能になる。
開発開始前のテスト設計の実施
アジャイルテストではスプリントの開始前、つまり開発の開始前にテスト設計を行い顧客、開発者と合意する。ここでいうテスト設計は一般的な意味での網羅的なテスト設計ではなく、
- テスト観点の洗い出し
- Happy path（やCritical path）のExample
のみしか含まないかもしれないが、あえてここではテスト設計と書く。
これはテストプロセス視点で見ると、テスト設計を通じて仕様についての抜け漏れや間違いのレビューを早期に実施している事になる。
ユーザーストーリーとテストの追跡性
ユーザーストーリーをテストベースとしてテスト設計を行うため、ユーザーストーリーとテストの追跡性が担保される[7]。そのため、ユーザーストーリーへの変更要求に起因するようなテストスクリプトへの変更や、ユーザーストーリーレベルでのテスト設計の変更が容易であるという長所がある。また、ユーザーストーリーの範囲で、単体テストやコンポーネントテストの継続的なリファクタリングが行われる[8]。
Happy path から Edge caseへ
Incrementalなテスト設計と呼ばれる理由の一つがここにあると考えている。アジャイルテストでは、スモークテストで実施するようなhappy pathのテストとedge caseのテストのテスト実施を段階を分けて行う。実際にはテスト実施だけでなく、テスト設計も段階を分ける事が多い（と身の回りでは感じる）。
テストの優先順位付けを行いリスクの大きいバグを早期に発見する事で、より俊敏で安定した開発•テストプロセスを築く事が出来る。
スプリントごとのアドホックなテスト設計の追加
アジャイルテストのテスト設計がIncrementalであると言われるもう一つの理由がここにあると考えられる。テスト設計はスプリントの開始前にユーザーストーリーをテストベースとして実行される。そのため、テスト設計はスプリントごとに追加される。
アジャイルテストのテスト設計が苦手な事
こうやって書いてくると良い事ずくめに感じられるアジャイルテストのテスト設計だが、これらの特徴に起因する苦手な事が存在する。
スプリントをまたいだ機能のテスト設計が苦手
ユーザーストーリーをテストベースとしてテスト設計を行うので、どうしてもスプリントをまたいで実現される機能のテストが苦手という特徴が生じる。この弱点は通常は問題にはならない。優秀なプロダクトオーナーやアーキテクトは、システム要求をよしなに分割してストーリーは作られているはずである。例えば、機能BとCが機能Aに依存している場合、
- スプリント1: 機能A の開発とテスト
- スプリント2: 機能B の開発と 機能AとBの結合テスト
- スプリント3: 機能C の開発と 機能AとCの結合テスト
といったように。しかし、ここで、
- スプリント1: 機能AとCの一部を開発
- スプリント2: 機能BとCの一部を開発
- スプリント3: 機能AとBの一部を開発
のように、ユーザーストーリーがきちんと整理されていないと、結合テストをいつやるか？結合テストのスコープは何か？といった問題が生じる。（そんなのScrumじゃないと言ってしまえばそこまでだが、Scrumじゃない事を見落とすと非効率なテスト設計の本質を見失う。）
スプリントをまたいだテスト設計の最適化が苦手
テスト設計の重要な役割として、テストカバレッジを担保しながらテストケース数を減らすテストの経済学の考慮がある[9]。しかし、アジャイルテストではスプリントをまたいだテスト設計の最適化が苦手である。
何故か？第一にユーザーストーリーに対するカバレッジを100%にする事を大前提としている事、次にユーザーストーリーに対する追跡性を重要視しているため、システム全体でどのようなテストがどれくらいの規模で行われているのかを可視化する事が苦手な事に起因している。
例えば今回のスプリントで追加した10件のテストケースによって、前回のスプリントで作成した100件のテストのテストケースを削除しても同等のパスカバレッジを担保出来るといった状況であっても、一般的にテストケースの最適化は行われていないのではないかと思う。
こう考えている理由は、○○百億件のテストを自動化しナイトリービルドで実行しているエンジニアから「実はテストケースの減らし方が分からない」という話を聞いた事があるからだ。この会社では、テストの最適化をテスト実行の優先順位付けで行っているのは有名な話だ。
また、実践アジャイルテストの 著者のJanet Gregoryの"Traceability"というタイトルのブログエントリが興味深い。ユーザーストーリに対する"Traceability"そのものは重要だが、"Traceability Matrix"のような全体を俯瞰するための表はいらないと述べている[10]。
アーキテクチャのテスト設計が苦手
賛否両論あると思うが、アジャイルテスト４象限の第４象限に非機能要件のテストが定義されているのにも関わらず、アジャイルテストは非機能要件のテストが苦手だと指摘されている[11][12]。
この問題は根が深い。アーキテクチャが自律的に、継続的に進化するのであれば、当然その反映であるシステムの品質、例えばパフォーマンスや運用性と言った品質も継続的にテスト、モニタリングされる必要がある。
これは、アジャイルでのアーキテクチャの肩身の狭さのため、アーキテクチャの反映であるシステム品質がおろそかにされがちな為なのでは、と考えている。この問題の解決策として、パフォーマンスやユーザビリティ等の非機能要件もユーザーストーリとしてバックログに追加する事が提案されている[13]。
まとめ
アジャイルテストではユーザーストーリーを中心に据える事で、
- 顧客がテスト設計に参加
- テスト設計を通した仕様のレビューの前倒し
- Incrementalにテスト設計
をし、アジャイルなテスト設計を実現している事を挙げた一方で、
- スプリントをまたぐテスト設計の最適化、
- ユーザーストーリーとの関連が低いアーキテクチャ等の品質のテスト
が苦手な事を述べた。
アジャイルテストを導入するにあたっては、その長所はもちろんだが苦手な部分についてもきちんと考慮する必要がある。苦手な部分を無視するとテストの作り過ぎによる炎上やテストの抜け漏れを引き起こす。それらにきちんと対処すれば迅速で安定したテストプロセスの構築を可能にする。
一方でこれらのアジャイルテストのテスト設計の苦手な部分は、これからアジャイルテストが体系化していくにあたっての課題であると考えられる。現在までアジャイルテストはどちらかというと「開発者側のもの」という印象があったが、これらの課題を解いていくにはテストや品質のスキルも必要になると考えられる。
リフェレンス
- [1] Certified Tester Foundation Level Extension Syllabus Agile Tester
- [3] Agile Testing and Process Thoughts with Janet Gregory: ATDD vs. BDD vs. Specification by Example vs ....
- [4] A Testers Role On Agile Projects - Janet Gregory
- [6] Agile Test Planning with the Agile Testing Quadrants
-
[7] BDD & the Holy Grail of User Story Testability & Traceability | Agile Zone
- [8] Refactoring test code
- [9] The Art of Software Testing
- [10] Agile Testing and Process Thoughts with Janet Gregory: Traceability
- [11] Agile Testing and Quality Strategies: Discipline Over Rhetoric
- [12] Missing Test Competencies in Agile
- [13] JDD2014: QA to AQ: shifting from quality assurance to agile quality -…
２次元の表によるテスト管理の限界
ソフトウェアテスト業界の古き大発明
どの業界にも大発明が起きる瞬間がある。オーディオ業界のステレオスピーカー、映像業界のDVD、携帯電話業界のソフトウェアインターフェースなどなど。これらの破壊的な発明はそれまでの常識を覆し、全く新しい利便性や効率性をもたらす。過去使われていた方法は淘汰され、長期間に渡って多くの人に親しまれる。こういった大発明は劇的に世界を変える一方、多くの人に長期間親しまれてきたため、次に起きそうな革新を阻害するという事がしばしば起きる。誰だって長期間親しんで来たものが変化する時には少なからずの抵抗を覚える。
「２次元の表によるテスト設計とテストケースの管理」はまさにこれにあたる。これだけ多くのテスター、テストアナリスト、テストマネージャーに親しまれ、長く使われて来たのはおそらく「革新的な発明」であり「とても便利なツール」だったからだ。しかし、次世代のテストを考える場合、この大発明を棄てる事も選択肢として考えなければならない。
２次元の表
２次元の表によるテスト管理の特徴
様々な情報をすべて２次元の表に詰め込む。これが２次元の表でテストを管理する事の特徴だ。以下のような異なる属性が一つの２次元の表で管理されているテスト設計をみなさんも見た事があるのではないだろうか？
- テスト環境
- テスト観点
- テスト条件
- テスト技法
- テスト事前条件
- 期待値
- テスト手順
すべての情報が一つのテーブルによって表されている事が大きな特徴だ。
２次元の表によるテスト管理の利点
すべての情報が一つのテーブルによって管理されているので全体の見通しが良いというのが大きな利点の一つだ。特にマネージャーはこのテーブルを見るだけで、何をどのようにテストしているのか一目瞭然に分かる。テスト観点やテスト条件を見れば何をテストしているのか分かるだろうし、テスト手順や技法を見ればどのようにテストしているのか分かる。
また、この２次元の表によるテスト管理の利点としてもう１点、テスト設計者とテスト実行者を分ける事が可能になる事がある。 なるほど。どこかで聞いたような話だが、テスト設計とテスト実行の役割を明確に分ける事により、テスト実行の部分をスケール出来るようにする。「人月の神話」を信じているような、レガシーな大規模開発ではありえそうな話だ。
利点の前提条件
しかし、この利点を効果的に得る為には一つの条件が前提となる。それはテスト設計に変更が入らないという事。少し条件を弱めれば、テスト設計の時点でテスト設計への変更要求がある程度予測可能である事である。
ウォーターフォール開発が一般的であった時代には少なくともプロジェクトマネージャー、アーキテクト、QAマネージャー間では合意可能な前提であったのだと思う。しかし、アジャイル開発のようなテスト設計への変更要求が大前提の開発スタイルではいくつかの大きな問題を引き起こす。
２次元の表によるテスト管理の問題点
①テスト条件の追加•変更更要求に対し、変更箇所が多い
テーブルを非正規化してしまっている事の弊害として、テスト設計変更要求に対して変更箇所が多いというメンテナンス容易性の問題がある。例えば、新しい仕様の追加によりテスト条件を１カ所追加したい場合、正規化しているテーブルに対してならば１カ所だけ変更するだけで済むものも、非正規化しているテーブルに対しては、select文で条件に合致するレコードを抽出し、条件に合致するレコード全てに対してテスト条件を追加する必要がある事と同じ問題が起きる。
②テスト設計の継続的改善が難しい
また、テスト設計の継続的改善が難しい事も問題である。テスト設計は一度実施したら終わりというものではなく、継続的に改善する必要がある。これには2つの理由がある。
１つ目の理由は、テストの実行結果によってテスト設計も改善する必要がある事である。テスト実行前にバグを発見可能と予測して作ったテストケースと、実際にバグを見つけたテストケースとの間にはきっと差分がある。その差分によりテストケースを追加する事は当然であるが、加えてテスト設計も見直す必要がある。
2つ目の理由は、プロダクト側のアーキテクチャ変更に伴うものである。アーキテクチャが変われば当然求められる品質も変わる。テスト設計自体を変更する必要性が生じる。
③テスト自動化への移行の問題
テスト自動化が成功していない事例をいくつか見たり聞いたりしてきたがその原因の一つに、手動テストが前提の"テスト設計者"と"テスト実行者"のロールモデルをそのままに、テスト自動化プロジェクトを実施したというものがある。
よく聞く「手動のテスト実行よりも、テストスクリプトの実装の方がコストが高い」という話。今まで通りのテスト設計をして、テスト実行をテスト実装で置き換えるという前提であれば、その比較は正しい。しかし、僕はこの比較についてかなり懐疑的に考えている。「手動テストに最適化されたプロセスのコスト」と、「自動テストに最適化されていないプロセスのコスト」の比較にどんな意味があるのだろうか？
テスト自動化へ移行する場合、少なくとも
- テストスクリプトを実装するエンジニアにとっての必要最低限な情報は何か？
- テスト設計プロセスの中で、テスト実装者が実行した方がプロセスが最適化されるものは何か？
についての議論を踏まえ、自動テストに最適化されているプロセスを定義し比較する事が必要である。
まとめ
僕はこれらの「２次元の表によるテスト管理の限界」について、テスト設計がリファクタリング不可能である問題、とこれから呼ぶ事にする。
継続的インテグレーションが導入されているプロジェクトでは、リファクタリングを定期的に行い技術的負債を返済しながらプロダクトの品質改善を行うのと同様に、テスト設計も定期的に改善されていかなければならない。そう、きっとテスト自動化プロジェクトとスクラムはとても相性がいいのだ。
次回のエントリでは、アジャイルテスターの人達がどのようにテスト設計とそのリファクタリングについて考えているのか、何も考えていないのか、について書く。
参考情報
品質をカイゼンするフィードバックを作る
全４回のウォータースクラムフォールをガチでディする連載の最終回です。前回までのエントリーはこちら。
- プロトタイプはリアルプロダクトたりえないのか？ 〜そのテストはプロジェクトのリスク管理に貢献していますか？〜 - Test Automation
- 「継続的デリバリー」から考えるソフトウェア開発の入り口、出口問題 - Test Automation
- 品質改善をしないアジャイル ~ウォータースクラムフォール~ - Test Automation
「正しいアジャイル」は品質向上プロセスをどのように回しているのか？
前回のエントリで、アジャイルで品質向上サイクルを回すための方法として「TDDにも品質についてもハイスキルなエンジニアのチームを作る」を挙げた。まず、正しいアジャイルではTDDによってどのように品質向上サイクルが回るのかを考えたい。
TDDは「テストを書く」「テストを通す」「リファクタリング」の黄金の三角形を回しながらソフトウェアを開発するプラクティスだ。「テスト駆動開発」の名前のためかテストを最初に書く、つまり「テストファースト」な特徴に注目が集まりがちだが、その本質はレビュー観点を区別した品質向上サイクルにあると考えている。
TDDはまず最初にテストを書く。しかしただテストを書くだけではない。優秀なエンジニアは、仕様に抜け漏れがないか？設計は妥当かを考えながらテストを書く。これはいわゆる「仕様書•設計レビュー」に相当する。
テストの実装の後、機能を実装しテストを通す。ここで熟練したエンジニアはただテストを通すだけでなく、書いた機能のコードについてマルチスレッドやメモリーリーク等のバグがないか「探索的テスト的なレビュー」を行う。
テストがパスした後、そのテストが失敗しない事を確認しながら内部設計の改修を行う。これはすなわち、ソースコードの「保守性をレビュー」している事に他ならない。
TDDではこの黄金の三角形のサイクルを小さくリズミカルに回しながら開発を行う。
このプロセスは非常に優れている。優れたエンジニアはTDDによって、ソフトウェア品質モデルに含まれる「プロセス品質」「内部品質」「外部品質」について、「テストを書く」「テストを通す」「リファクタリング」のアクションでそれぞれレビューをし、小さな品質向上のフィードバックを継続的に回す事が出来る。
そう、TDDの本質はエンジニア個人が小さな品質向上のフィードバックループを継続的に回す事にある。
チームで品質に関するフィードバックを回す
エンジニア個人はTDDによって品質に関するフィードバックループを回す事が出来る。しかし、要求分析、設計、品質とどこかのスキルに特化したチームが複数ある場合、チームレベルでのフィードバックを回すにはどうしたらよいのか？
答えはもうすでに、アジャイルテストの細谷さんと永田さんが出して下さっていた。
- 品質に関する要求もバックログで管理し、スプリント中に実施する
- 品質エンジニアも設計チームに参加し、積極的に品質に関するフィードバックをする
1.の意味は2つある。１つ目は開発プロジェクトの最後に品質の門番としてのQAを実施するのではなく、開発初期からテスターが品質の視点でプロジェクトに関わる事。2つ目は、品質に関する要求をプロジェクトの初期から明示的に管理する事。ここで言う品質は、パフォーマンスや運用性などの非機能要求も含まれる。
ただし、１.だけでは本当の意味でのアジャイルな品質向上にはならない。アジャイルの品質向上活動の本質は、動作するソフトウェア上での迅速なフィードバックにある。だから、アプリケーションをデプロイ、品質を評価し設計にフィードバックする。
参考文献：
先日、永田さん、細谷さんとお話をし、アジャイルでの品質向上の本質がフィードバックループにあるという事に確信を持った。また、下記ののコラムが非常に面白いので、興味のある方は是非読んで頂きたい。
その中で一番中心になったのが、なぜ、アジャイル開発では設計から要求仕様書が出ないのだろうか、というストレートな疑問でした。その中で細谷さんは、フィードバックの設計という話をされました。ソフトウェア開発では、いたるところでフィードバックループがあります。アジャイル開発はそれを早く（アジャイルに）回すのです
第161回 シンクロニシティな世界アジャイル、欠陥エンジニアリング、そして要求開発編（全4回の第4回）｜SQiP：Software Quality Profession
リーンとカイゼン
この「品質に関する迅速なフィードバック」を回す事は、日本の製造業がずっと大切にしてきた「品質を作り込む」という思想そのものに他ならない。そしてその思想は、同じ思想の源流を持つ「リーン開発」の中に受け継がれている。(川口さんの有名な絵画を拝借します。)
Agile and Lean from altitude 12,000 feets // Speaker Deck
例えばJoseph Yoder氏は"QA to AQ"という考え方の中で「非機能要求も整理し、バックログで管理しなければならない」という事を主張している（JDD2014: QA to AQ: shifting from quality assurance to agile quality -…）し、James O. Coplien氏は「Lean Testing」という考え方の中で「テストもリーンになる必要がある」と主張している(Beyond Agile Testing to Lean Development — Rakuten Technology Confere…）。
そう、アジャイルやリーン開発と、品質の継続的なフィードバックを作る事はとても相性がいいのだ。そういえば、先日インドのテストエンジニアコミュニティの方とお会いしてリーン開発でのテストの話をしている時に、「リーン開発のテストではカイゼン=Continuous Improvementを作るのが重要」という話が上がり、あぁ、リーンとカイゼンはソフトウェアの継続的な向上の為の二輪となるコンセプトなんだなと改めて感じた。
ソフトウェア開発プロセスの中に「品質をカイゼンするフィードバックを作る」。古くて新しいソフトウェア品質の考え方だ。
品質改善をしないアジャイル ~ウォータースクラムフォール~
ウォータースクラムフォールをガチでディする全４回連載の３回目です。はい、そうです。前２回のエントリは今回ウォータースクラムフォールをガチでディする為の前振りです。ウォータースクラムフォールの説明は以下のページをご覧下さい。
実用主義者が勝ったのか？Water-Scrum-Fallが一般的に
ウォータースクラムフォールの問題点
ウォータースクラムフォールの問題点は上記の記事のこちらの一節に凝縮される。
多くのアジャイル導入は実作業者によって主導され、実作業者が最も緊密に作業する領域、つまりソフトウェア開発ばかりにフォーカスすることから、このようなことが起きるのだとForrester社は見ている。リリース管理やプロジェクト計画のような領域は、未だに伝統的な手法で行われているのだ。
ウォータースクラムフォールの問題は、プロジェクト関係者がソフトウェア開発ばかりにフォーカスする事で、テストや運用計画、リリース管理等のソフトウェアの品質改善に直接貢献するプロセスが全く回らない事。
スクラムでスプリントを分割しイテレーションで開発するのは
- プロジェクトの外部要因の変化への対応を容易にする
- プロジェクト内からのフィードバックループにより改善する
が大きな目的だ。しかし、多くのウォータースクラムフォールプロジェクトでは1.にばかり注目し2.の意味を軽視している。
プロジェクトの始めに、一番大きな仮説についてプロトタイプを作る事はもちろん外部要因の変化に対応するため重要だ。だがそのプロトタイプをきちんとテストし、アーキテクチャや運用設計についてフィードバックループを回さなければ、そのプロトタイプはシステムの品質には寄与しない。（ 連載第一回目の記事：プロトタイプはリアルプロダクトたりえないのか？ )
スプリント中でいくら単体テストを自動化したとしても、コンポーネントの結合やシステム運用レベルの仮説はまだまだ残っている。機能やユースケース等の外部品質はもとより、使用性や運用性などの利用時品質は実際にデプロイして、試用してみなければその評価や改善をする事は出来ない。（連載第二回目の記事：「継続的デリバリー」から考えるソフトウェア開発の入り口、出口問題 )
ウォータースクラムフォールには品質改善のフィードバックループというソフトウェア開発の重要な概念が抜けてしまっている。
ウォータースクラムフォールが品質を向上させない理由
スクラムはソフトウェア開発プロジェクトのプロセス品質を向上させる為の素晴らしいプラクティスだ。ストーリーを定義しベロシティを計測する事はプロジェクトの進捗の予測性を改善するし、レトロスペクティブはその自己的な改善活動を促進するだろう。定期的なクライエントへのデモは要求とのギャップを改善し、手戻りを大幅に減らすだろう。
しかし、スクラムは内部品質や外部品質の向上には寄与しない。それらも改善する為にはXPのCIやTDDを導入する事が必要だ。CIはコンポーネントの結合に関するリスクを大幅に減少させるし、TDDはプロセス品質、内部品質、外部品質を劇的に改善する素晴らしいプラクティスだ。
問題は、多くのウォータースクラムフォールと呼ばれるプロジェクトでCIやTDDが正しく導入されていない事。開発とQAが独立した組織では対立構造を作りやすいためCIやTDDの導入は困難だ。また、テスターの設計•プログラミングスキル不足により、テスターが品質に寄与出来るようになるまでプロジェクト終盤まで待たなければならないというのも問題だ。同じように開発者の品質への理解不足は間違ったアジャイルを促進しTDD自体の品質向上を徹底的に妨げる。
結局のところ、スクラム、XP、そして品質についてもスキルの高い開発者ばかりを集めて、正しいアジャイルを実践する以外に品質を向上させる手段はないという結論になってしまうのかもしれない。
ウォータースクラムフォールを乗り越える為に
いや、その結論でこの問題を結論づけるのは早計だ。では設計やテスト、品質それぞれ一つのスキルに特化したメンバーが集まっているチームで品質を上げて行く為にはどうしたら良いのか？そのヒントは品質大国日本の生産工程そしてリーンにある。
- Agile and Lean from altitude 12,000 feets // Speaker Deck
-
Beyond Agile Testing to Lean Development — Rakuten Technology Confere…
ウォータースクラムフォールや間違ったアジャイルに欠けている品質改善のフィードバックループを作る為にはアジャイルテストを越えて、継続的システムテストそしてリーン開発へと進まなければならない。
全４回連載、最後のエントリとなる次回ではスキルに特化したメンバーが集まったチームでの品質改善フィードバックについて述べる。
次回エントリはこちら
「継続的デリバリー」から考えるソフトウェア開発の入り口、出口問題
「継続的デリバリー」(*1)の章の構成はとても興味深い。第一章では「The problem of deriverling software」というタイトルで、ソフトウェア開発の目的を顧客に価値をデリバリーする事とし、その上でリリースにまつわるアンチパターン３つの紹介から始まる。
* Deploying software manually
* Deploying to a Production-like Environment Only after Development Is Complete
* Manual Configuration Management of Production Environments
これは「継続的デリバリー」というタイトルから考えるに妥当に感じるかもしれないが、一度考えてみて欲しい。
何故リリースにまつわるアンチパターンの紹介から始まるのか？
それはソフトウェア開発に関する問題の多くが顧客に価値を届けるvalue streamの入り口と出口に潜んでいるから。
ここで素晴らしい事は入り口に関する問題の解決方法は多くの良書で語られている事。アジャイル関連の本には特に多い。残念な事は出口に関する問題の解決方法を語っている本は「継続的デリバリー」くらいしかない事。「継続的デリバリー」自身が第一章1pで語っている。
There are many software development methodologies, but they focus primarily on requirement management and its impact on the development effort. There are many excellent books that cover in detail different approaches to software design, development, and testing; but these, too, cover only a fragment of the value stream that delivers value to the people and organizations that sponsor our efforts.
「継続的デリバリー」が出版された頃と比較して、CIツールや自動テストツール等、デプロイメントパイプラインを構成する技術要素が進化、普及し簡単に継続的デリバリーを実現出来るようになった。AntやMavenでビルドを自動化する事、Seleniumを使って画面テストを自動化する事、Jenkinsを使ってそれらの自動実行をスケジューリングする事 、ChefやFabricでprovisioningやdeployを自動化する事。どれも手軽に出来る。
その一方で、ウォーターフォールへのテーラリングやお手軽なテスト自動化などが進み、変な継続的デリバリーが増えてしまっているように思う。変な継続的デリバリーは出口の問題を解決しないので、開発もテストも運用もどんどん疲弊していく。単体テストでコードカバレッジ100%を目指す「自動化ハイ」なんかはその典型的な例だろう。
継続的デリバリーが手軽に実現出来るようになった今では、冒頭で紹介されているリリースにまつわるアンチパターンは、継続的デリバリー実現のアンチパターンと読み替えてもいいかもしれない。
- プロビジョニングに関する環境の構成管理とデプロイ方法を自動化する事で、疑似本番環境へのデプロイを毎週、または毎日行っていますか？
- 毎週、または毎日デプロイを行う事で、デリバリーが成功すると自信を持って言えていますか？
「リリース」というソフトウェア開発プロジェクトの中で大きなリスクを伴うプロセスを擬似的にプロジェクトの初期から継続的に実施する。それによってそのリスクを大幅に減らす事が出来る。そういう世界だからこそ、開発者はその設計や実装のスキルを発揮出来るし、テスターや運用者は要求や設計に関わるフィードバックを回す事が出来る。「デプロイメントパイプライン」の中での品質の作り込みを実現していく事が可能になる。
参考文献
(*1)
楽天ブックス: 継続的デリバリー - 信頼できるソフトウェアリリースのためのビルド・テス - ジェズ・ハンブル - 4048707876 : 本
プロトタイプはリアルプロダクトたりえないのか？ 〜そのテストはプロジェクトのリスク管理に貢献していますか？〜
ソフトウェアプロダクトを開発する時、色々なリスクが想定される。今から開発するプロダクトは本当に顧客の要求を満たすのか？選定した技術要素は本当に設計要求を満たすのか？プロジェクトは期限内に終るのか？
そんなソフトウェア開発プロジェクトのリスクを軽減する方法として、プロジェクトの最初にプロトタイプを作成し、仮説を検証する方法がしばしば取られる。プロトタイプを作成し顧客要求の仮説を検証する。プロトタイプによって設計要求に対する仮説を検証する。などなど。
あなたはこの「プロジェクトの最初に作成したプロトタイプ」を仮説の検証が終った後に捨てていませんか？
もし、このプロジェクトの一番最初に作成したプロトタイプを捨てているのだとしたらなんともったいないことか。だってそのプロトタイプはプロジェクトの重要な仮説を検証しているのだから。リアルプロダクトとしてきちんとテストして、そのテストを自動化すれば、プロジェクトの期間中ずっとリスクが顕在化していない事を確認する事が出来る。
テスターは、しばしば品質保証の対象を「完成したプロダクト」に限定する。でも、Leanな開発プロジェクトでアジャイルテスターは「これから開発するプロダクト」のリスクも検証する。だからプロダクトオーナーやアーキテクトとのコミュニケーションが求められる。
ウォーターフォールにおけるテスト自動化では、しばしばテスト自動化の本質を「工数削減」に置く。でもLeanな開発プロジェクトでアジャイルテスターは、テスト自動化をリスク管理をするためのツールとして使う。加えてプロジェクトのプロセス品質とプロダクト品質を継続的に計測しフィードバックする。
Leanについては、平鍋健児さんの"リーンとカンバンの本質"の6pのスライドをご参照ください。 http://www.slideshare.net/hiranabe/lean-from-the-trenches
Leanの開発プロジェクトで、何故こんなに細いテストプロセスで品質保証が可能なのか？その本質はアジャイルテスターがテスト自動化と継続的な品質改善によってプロジェクトのリスク管理に貢献するからである。
IT勉強会からの越境 #devlove
このエントリーはDevLOVE Advent Calendar 2014の1月10日の記事として執筆しています。
執筆のモチベーション：
昨年度の私のJaSSTやSQiPでの事例発表が「IT勉強会からの出口」「IT勉強会からの越境」として取り上げられていた事を受けて、それをテーマに記事を書いてみようと思いました。
-
飯尾 淳 - Yoshiokaさんが講演で教えてくれた事例．「勉強会のひとつの出口として，研究会が受け皿になるべきでは... | Facebook
- 「越境するといろいろ面白いことが怒るような気がします」
あまり「越境している」という自覚はなかったのですが、上記で取り上げられているのを読み、あぁ自分はIT勉強会から越境していたんだなと気付きまして。越境をテーマにしているこちらのAdvent Calendarに
- IT勉強会との関わり
- 何故IT勉強会から越境したのか？
- 越境して気付いた事
- 越境を阻むものを乗り越える
について、Fearless Change のパターンを参考にしつつ書きます。
Fearless Change
自分の社内勉強会の活動やIT勉強会からの越境は『Fearless Change』のパターンの文脈で考えてみるとすごく伝えやすいと思います。
楽天ブックス: FEARLESS CHANGE - アジャイルに効くアイデアを組織に広めるための４８の - マリリン・マンズ - 462108786X : 本
昨年度のデブサミで監訳の川口さんのご協力のもと著者のサインを集めてからこの本を読み込みました。何かを変えたいと思ったエバンジェリストが組織や社会にその活動を広めていくためのヒントが詰まっている本です。そのヒントも「何か食べながら」「便乗」など結構身近な方法が多く、スラッと簡単に読める本です。
IT勉強会との関わり
自分とIT勉強会との初めての深い関わりは社内で「テックトーク CIスペシャル」という勉強会を企画してからです。この頃はテスト自動化に苦しんでいる時期で、ただ漠然と仲間を増やしたいという気持ちで企画しました。昨年私の周囲では「ぼっち」という言葉が流行したりしましたが、面白いのは社内勉強会は「ぼっち」をつなぐ役目を果たしている面がある事です。
エンジニアとして自分の仕事の価値を考えた時に、現場で例えば「テスト自動化したい」「キレイなコードを書きたい」「運用設計を開発にフィードバックしたい」といった想いを抱く事があると思います。難しい点はそういった想いを持ったエンジニアは現場では最初少数派である事が少なくない事。特に上に挙げたようなテーマは「クラウド」や「ビックデータ」などと違って、わざわざそれについて組織として特別力を入れようという話にまでなかなかいかないのが難しいところでして。でも、各部署に一人や二人そういったところに悩んでいたり取り組んでいたりするエンジニアがいたりします。
そういった「部署内ぼっち」をつなげる役目を社内勉強会は一つ担ってるのかなあと感じます。Fearless Changeのパターンで言うと
- 勉強会(25）
- 体験談の共有(32)
ですね。
またIT勉強会にも似たような側面があるのかなあと思います。例えば社内にアジャイルを導入したい、でも自分は社内では少数派、といった場合に社外の同じような経験や悩みを抱えている人と共有するだけでも色々と楽になる事があります。
何故IT勉強会から越境したのか？
もともと自分の中には「越境しよう」というモチベーションはありませんでした。ただ漠然と「エンジニアなら技術で仕事して特許取ったり論文書いたりするのが当たり前でしょ」という考えがあります。なので、いつも仕事をしながら目の前の技術を見て「これはLTネタになるかも」「これは特許がとれるかも」とか「これは論文になるかも」とか、業務とは別の軸での着地点を考えています。
JaSSTやSQiPなどの発表についても、２年間続けて構築してきた自動テストプラットフォームについて"なんとなく"論文になるんじゃないかと思ってまとめてみたというのがホントのところです。。（ホントは経験論文にしたかったのだけどまとめるまでの時間の都合で事例発表になっていますが 笑）
もちろんビジネスとしての出口の「成果」やサービスとしての出口の「リリース」も重要です。それと同じくらいエンジニアリングとしての出口の「特許や論文」も大事だと思っていて、そのバランスがうまくとれている会社や仕事はステキだなあと思っています。
越境して気付いた事
そんな曖昧なモチベーションで越境してたのですが、越境してみて実際に色々な気づきがありました。
① 客観的なデータと論理構成に基づく発表
テスト自動化について仮説を立て、色々な施策を実行しその結果をデータ分析に基づいて客観的に考察したSQiPの発表は、テスト自動化や継続的インテグレーションの導入について決断を下す責任ある役割を担っている方達に特に刺さっていたという話を後から何度か聞きました。
業界の有識者が集まるシンポジウムという事で客観的なデータ分析と論理構成に特に注力してまとめたのですが、結果的にそういった立場の方達が判断をする際のリフェレンスにして下さっていたり、「あの発表から勇気をもらった」と直接コメントを頂いたりしました。
IT勉強会の発表では感情に訴えかけるような発表もしばしば重要です。Fearless Changeを一緒に行う現場レベルの仲間を探す時には効果を発揮するし、実際僕自身もそういった発表に救われた事が何度もあります。一方で感情を抜きにした論理的な発表は、少し年配の方や責任ある立場の方に対して
- 達人を味方に(14)
- 経営層の支持者(28)
- 身近な支援者(35)
といったパターンが期待出来るという事が気づきとしてありました。
② 襟を正して参加するようなシンポジウムは意外と効果がある
襟を正して参加するようなシンポジウムの効果は意外と大きいなという事も感じました。
私の周囲では何がテスト自動化の正解なのかよく分からずみんな手探りであれこれと試しながら成果を出したり失敗したりというのが実情として多いです。で、①でも触れたように、ある層の方達がテスト自動化の成功事例として参照して下さっていたのですね。ソフトウェア品質の有識者が集まるシンポジウムでの発表、しかも賞を頂いたという事が
- 外部のお墨付き(12)
を得て、テスト自動化の正解パターンの一つとして周囲に認知された背景にあるのかなあと感じます。
③ 振り返りと有識者のフィードバック大切
有識者に見て頂く発表としてまとめる事で、自分達の仕事や成果を俯瞰して振り返る時間を持つ事が出来ました。そういった時間から、例えば「あの時自分たちはAというアプローチで問題を解いたけど、実はBやCといった解き方もあった」など、日常の業務の中からはなかなか得られない気づきを得る事が出来ます。
また外部の有識者と話す事で、自分たちにとっては当たり前だった"変化"が一般的にはそうではなく、じゃあ何で自分たちのケースではうまくいったのだろうとコンテキストの違いや、ちょっとした工夫の効果について深く考えてみるきっかけとなった事もありました。
普段の業務から考えるとちょっと特別な
- ふりかえりの時間(5)
- 達人のレビュー(31)
を得る事で、日常の仕事の中からはなかなか見つけ出す事の出来ない気づきを得るきっかけになると感じます。
④ Fearless Changeはパターンの積み重ね
発表を作るにあたってたくさんの専門書を読んだり社外のエキスパートの方達と議論をする中で、エンジニアリングの世界には正解パターンがある事も多いという事を感じました。自分の業務の中に閉じこもっているとなかなか気付かないのですが、業務で出くわす様々な問題や悩みは、もうすでに誰かが解いている事も多いのですよね。
この２年の中でかなりの数のソフトウェアテストや品質の研究論文を２年の中で読み、また自分でもトライしてみました。その経験の中で、何がもうすでに解かれている問題なのか？それらの問題はどのようなアプローチで解かれているのか？何がまだ解かれていない問題なのか？を自分の中でかなり整理出来てきたのかなあと思います。引き出しの中の正解パターンの数がこの２年で100倍〜1000倍に増えている 笑。
もちろん、過去の研究や正解パターンを完全に否定する事で起きるイノベーションがある事も重々承知しています。一方で、大きな問題を分解し
- 種をまく(22)
- 適切な時期(23)
- ちょうど十分(34)
といった小さな正解パターンを
- ステップバイステップ(3)
で積み上げていくだけでも解ける事がたくさんある、そしてその積み重ねがFearless Changeそのものなんだなあと思います。
最後に：越境を阻むものを乗り越える
ボキャブラリーや文化、考え方の違いが越境を阻む事も少なくないですよね。IT勉強会とシンポジウムや研究会はそういった違いが敷居の高さを作ってるように感じる事があります。ですが、その壁はきっとエンジニア個人の努力で乗り越えられる。
例えば「アジャイル」と「品質保証」はお互い相容れないと考えられていた時期というのがあったように思います。それぞれが出て来た文脈が違うので一見すると全然異なる事を主張しているのではとギョッとする事があるのかもしれません。でも「継続的デリバリー」と「ソフトウェア品質知識体系ガイド」は、サービスやソフトウェアの品質を継続的に改善して行こうという目的は一緒です。また、たくさんのエンジニアがそれぞれの分野の『越境』をくりかえしてきたため、そこで主張されている方法論についてほとんど矛盾を感じません。
先日、ソフトウェア開発について「テスト」も「レビュー」も「XP」についても造詣の深いエキスパートの方に「色々な分野でご活躍されてますがご専門は何ですか？」と質問しました。その方の答えは「特に１つの分野に限定して専門を考えた事はない。どんな分野のエキスパートともディスカッションをすると興味深い知見が得られるし、そのためにどんな分野についても議論出来るように勉強している」というものでした。
目的さえ同じならば、ボキャブラリーや文化、考え方の違いは個々のエンジニアの努力次第で乗り越えられるんだなあ、越境を繰り返すエンジニアによって技術の進歩は支えられていると実感させて下さる、偉大な先輩の言葉でした。
IT勉強会からの越境に壁を感じたとしても
- 怖れは無用(46)
です。IT勉強会から越境して様々な分野のエキスパートと出会い、議論する事で、もしかしたらあなたの新しいキャリアが始まるかもしれません。
次の人へ
明日のDevLove Adventcalendar 2014の記事執筆は岡山さをりさんです。
おまけ
1月15日に「自社内で開く「カフェ・ソフトウェアクオリティ」勉強会」というテーマでソフトウェア品質の勉強会を楽天タワー２号館で開催します。ご興味のある方の参加をお待ちしております。
