品質をカイゼンするフィードバックを作る

全４回のウォータースクラムフォールをガチでディする連載の最終回です。前回までのエントリーはこちら。

「正しいアジャイル」は品質向上プロセスをどのように回しているのか？

前回のエントリで、アジャイルで品質向上サイクルを回すための方法として「TDDにも品質についてもハイスキルなエンジニアのチームを作る」を挙げた。まず、正しいアジャイルではTDDによってどのように品質向上サイクルが回るのかを考えたい。

TDDは「テストを書く」「テストを通す」「リファクタリング」の黄金の三角形を回しながらソフトウェアを開発するプラクティスだ。「テスト駆動開発」の名前のためかテストを最初に書く、つまり「テストファースト」な特徴に注目が集まりがちだが、その本質はレビュー観点を区別した品質向上サイクルにあると考えている。

TDDはまず最初にテストを書く。しかしただテストを書くだけではない。優秀なエンジニアは、仕様に抜け漏れがないか？設計は妥当かを考えながらテストを書く。これはいわゆる「仕様書•設計レビュー」に相当する。

テストの実装の後、機能を実装しテストを通す。ここで熟練したエンジニアはただテストを通すだけでなく、書いた機能のコードについてマルチスレッドやメモリーリーク等のバグがないか「探索的テスト的なレビュー」を行う。

テストがパスした後、そのテストが失敗しない事を確認しながら内部設計の改修を行う。これはすなわち、ソースコードの「保守性をレビュー」している事に他ならない。

TDDではこの黄金の三角形のサイクルを小さくリズミカルに回しながら開発を行う。

f:id:kokotatata:20150301165135p:plain

　このプロセスは非常に優れている。優れたエンジニアはTDDによって、ソフトウェア品質モデルに含まれる「プロセス品質」「内部品質」「外部品質」について、「テストを書く」「テストを通す」「リファクタリング」のアクションでそれぞれレビューをし、小さな品質向上のフィードバックを継続的に回す事が出来る。

f:id:kokotatata:20150301170237p:plain

そう、TDDの本質はエンジニア個人が小さな品質向上のフィードバックループを継続的に回す事にある。

チームで品質に関するフィードバックを回す

エンジニア個人はTDDによって品質に関するフィードバックループを回す事が出来る。しかし、要求分析、設計、品質とどこかのスキルに特化したチームが複数ある場合、チームレベルでのフィードバックを回すにはどうしたらよいのか？

答えはもうすでに、アジャイルテストの細谷さんと永田さんが出して下さっていた。

品質に関する要求もバックログで管理し、スプリント中に実施する
品質エンジニアも設計チームに参加し、積極的に品質に関するフィードバックをする

1.の意味は2つある。１つ目は開発プロジェクトの最後に品質の門番としてのQAを実施するのではなく、開発初期からテスターが品質の視点でプロジェクトに関わる事。2つ目は、品質に関する要求をプロジェクトの初期から明示的に管理する事。ここで言う品質は、パフォーマンスや運用性などの非機能要求も含まれる。

ただし、１.だけでは本当の意味でのアジャイルな品質向上にはならない。アジャイルの品質向上活動の本質は、動作するソフトウェア上での迅速なフィードバックにある。だから、アプリケーションをデプロイ、品質を評価し設計にフィードバックする。

参考文献：

先日、永田さん、細谷さんとお話をし、アジャイルでの品質向上の本質がフィードバックループにあるという事に確信を持った。また、下記ののコラムが非常に面白いので、興味のある方は是非読んで頂きたい。

その中で一番中心になったのが、なぜ、アジャイル開発では設計から要求仕様書が出ないのだろうか、というストレートな疑問でした。その中で細谷さんは、フィードバックの設計という話をされました。ソフトウェア開発では、いたるところでフィードバックループがあります。アジャイル開発はそれを早く（アジャイルに）回すのです

第161回シンクロニシティな世界アジャイル、欠陥エンジニアリング、そして要求開発編（全4回の第4回）｜SQiP：Software Quality Profession

リーンとカイゼン

この「品質に関する迅速なフィードバック」を回す事は、日本の製造業がずっと大切にしてきた「品質を作り込む」という思想そのものに他ならない。そしてその思想は、同じ思想の源流を持つ「リーン開発」の中に受け継がれている。(川口さんの有名な絵画を拝借します。)

f:id:kokotatata:20150301184318p:plain

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を作るのが重要」という話が上がり、あぁ、リーンとカイゼンはソフトウェアの継続的な向上の為の二輪となるコンセプトなんだなと改めて感じた。

ソフトウェア開発プロセスの中に「品質をカイゼンするフィードバックを作る」。古くて新しいソフトウェア品質の考え方だ。