品質チェックリスト
- パターン：品質チェックリスト（原題Quality Checklists, 原著 Joseph W. Yoder, Rebecca Wirfs-Brock, Hironori Washizaki）[5]
「たとえ経験豊富な人が使ったとしても、チェックリストは私達が想像する以上に、仕事で起き得る多くの失敗を未然に防いでくれる」― 書籍『アナタはなぜチェックリストを使わないのか？』Atul Gawande [Gaw]
どのプロジェクトでも、非機能要件やシステムが持つべき品質特性をどのように扱うのが最善かということが課題になります。セキュリティや使いやすさなどの品質特性は、その機能を使ってみなければ確認できません。保守性や拡張性などの他の品質特性は、ソフトウェアをどのように構築したかによって変わります。
アジャイルチームは、システムを実装する時に、さまざまな品質特性について考慮しなければなりません。あるユーザーストーリーの品質受け入れ基準を定義するために、ユーザーストーリーに品質受け入れ基準（折り込み品質）を追加することができます。また、セキュリティのように複数のユーザーストーリーにまたがる品質特性は、全体で矛盾が生じないようにしなければなりません。トランザクションのスループットや同時ユーザー数などは、複数のユーザーストーリーにまたがる要件なので、ソフトウェアの設計と構造に大きく影響します。
たとえ品質に注意を払っていたとしても、システムが進化するにつれて品質特性を維持することに問題が生じます。かつては要件を満たしていたシステムが、品質要件の変化に伴い、今では要件を満たさなくなっているかもしれません。
システムが進化し続けても、システムの品質要件が保証され、見落とされないようにするにはどうすればよいでしょうか？
＊＊＊
ユーザーストーリーは、その受け入れ基準が満たされるまで完成（Done）となりません。とはいえ、システムを発注する側は、往々にして受け入れ基準に品質要件を含めることにまで気がまわりません。発注する側は、開発者がユーザーストーリーを実装する時に品質特性を考慮することが当たり前だと思うものです。たとえ、発注する側が特定の品質要件に精通しており、ユーザーストーリーにその要件を明記していたとしても、その要件が既にある機能で満たされているという理由で、その他の品質要件も満たされているだろうと思い込むことがあります。
チームがシステムの品質特性に関する暗黙の知識や思い込みだけに頼っている場合は、どのような品質特性が重要なのかを理解することが難しくなるでしょう。具体的な品質特性は新機能によって異なるかもしれませんが、チームは品質を維持するために「標準」機能に何が期待されているかを知っておく必要があります。
チームがアジャイル開発に習熟しており、システム品質のために何が必要なのかを十分理解しているのなら、新機能を実装する時に一貫して品質特性を組み込むことができるでしょう。特にチームの規模が大きくなると、一貫して対応する必要があるシステムの品質特性が何か気づいた時に大きな問題になることがあります。
たとえ心の準備をしていたとしても、システムが発展していく中で驚くようなことが起きるものです。事前にテストしたシステムのパフォーマンスがリリース後に低下することもあります。当初はパフォーマンスに問題がなかったために、アーキテクチャは今も適切である、という誤った感覚に陥ってしまうこともあるでしょう。そして、新しい機能が追加されてリリースされると、もはや注意は不要と思われた何かが問題を引き起こしてしまうのです。
伝統的な開発手法で育ってきた開発者は、実装する必要があるものは要件で指定されたものだけと思いがちです。技術的かつ非機能的な品質特性のことは、多くのユーザーストーリーから省かれています。ユーザーストーリーで指定されていることと、システムが可用性と拡張性、そして保守性を一貫して満たすために必要とされることとの間には、大きなギャップがあります。
品質目標の期待値は、新しいテクノロジーが採用されるにつれて変わることがあります。そのため、今日の品質への期待値は、初期のソフトウェアでは受け入れられていた値よりも厳しくなっています。進化し続けるシステムに合わせて品質目標の期待値を調整するには、システム全体を通して期待される品質特性を明確にしておく必要があります。
＊＊＊
システムで共通の、一貫して満たすべき、望ましい、システムが持つべき品質特性の期待値を記したチェックリストを作成しましょう。開発チームはチェックリストを確認することで、機能がリリースされる前に品質特性を満たしているかを確認します。また、開発チームは品質保証活動の一環としてチェックリストの検証を行います。
チェックリストは、品質関連の期待値や行動を意識させる優れた手法です。さまざまなユーザーストーリーで一貫して提供すべき品質特性は何か、新しい機能を追加する際に考慮すべき重要な品質特性は何かを明らかにしておくことは、チームに品質要件を意識させるのに役立ちます。
チェックリストには、「読み取り／レビュー」型と「実施／確認」型の2種類があります[Gaw]。「読み取り／レビュー」型のチェックリストは、チームメンバー各自が前もって作業を済ませ、その後集まって各チェック項目を問題なくクリアしているか確認するという使い方をします。「実施／確認」型のチェックリストは、各チェック項目をその場で検証し、それから次のステップに進む、という使い方をします。
チェックリストの使用に適した状況とは、先に進む前に一時停止して振り返る時間ができる時です。アジャイルチームにとってこうした一時停止ポイントを見つけることは難しいことではありません。スプリントの振り返り会議やリリース計画会議の一部、結合テスト後、デプロイ前、ビルド後、またはアーキテクチャに起因するような状況であればいつでも、チェックリストを使うタイミングとして適していると言えます。実際、チェックリストは日常業務の中でざっと目を通すことができます。あるアジャイルチームは、日々のスタンドアップミーティングで目を通すチェックリストに、システムの改善、技術的負債の削減に取り組んだか、というチェック項目を入れています。また、このチームはかんばんボードのステータス変更に関するチェックリストも使っています。
チェックリストは、過去の経験や想定されるリスクを元にして、将来を見越して作成します。たとえばデータ移行には、重要な情報の損失など多くの潜在的なリスクがあります。過去の経験から、チェックリストとロールバックのやり方を含めた移行手順を作成し、移行を始める前に検証することができます。そのチェックリストには、移行作業中に一時停止して確認するポイントや、上手くいっているかどうかを確認するポイント、問題があれば、次の移行ステップに進む前にリカバリーのために取ることができるアクションが含まれています。
チェックリストの更新に良い時期とは、品質特性の向上に前向きに取り組んでいるにも関わらずシステムに問題が起きる時です。何をすべきかわかっていたにも関わらず、手を抜かないようにするために必要な行動をとっていなかった場合です。行動する前に確認できるリマインダーなどがあれば、一時停止、中止、そして適切な行動をとることができるかもしれません。例えば、最悪のシステム停止を経験したある開発チームは、デプロイ用チェックリストに「本番用データベースのスキーマ変更がデプロイされる前に、スキーマを元に戻すスクリプトが作成されており、かつ、それが検証済みであることを確認する」というチェック項目を追加しました。
特定の品質目標を達成しようとする中で出てくる反省点や課題から問題が見つかる場合もあります。チェックリストは、システムの品質を確保するという目標を達成できなくなったら更新が必要です。無視されている、または、見落とされている項目が見つかったら、チェックリストの修正を検討してください。仕事のやり方を向上させていくことと同様に、チームメンバーはチェックリストを作成、所有、更新させていく必要があります。その際、何が重要なのか推測を要する観念的なチェックリストになってしまわないよう注意が必要です。
導入初期段階では、チェックリストは面倒臭いとか、細かすぎると思われてしまうことがあります。扱いにくいチェックリストに従って作業するのを面倒だと感じる開発者は、使うことを拒むかもしれません。適切に設計されたチェックリストは、開発者とQA担当者を、品質関連のあらゆる要件を意識するために、実装の詳細にまで深く分け入っていくような苦労から解放します。品質チェックリストがチームに受け入れられるには、チェックリストの作成者とチームとの間に合意があり、品質チェックリストがチームにとって、開発時に役立つガイドであり、機能をデプロイする前の最終確認項目でもあると認識してもらう必要があります。
書籍『アナタはなぜチェックリストを使わないのか？』で、著者のAtul Gawandeは、チェックリストが医療専門職にどのように採用されてきたかを調査しています[Gaw]。Atul Gawandeは、チェックリストの受け入れには1つ大きな課題があり、それは手順やチェックリストに従うことを恥ずかしいと感じる意識の克服であると述べています。「私たちは、チェックリストを使うのは恥ずかしいことだと心の奥底で思っているのだ。本当に優秀な人はマニュアルやチェックリストなんて使わない、複雑で危険な状況も度胸と工夫で乗り切ってしまう、と思い込んでいるのだ。「優秀」という概念自体を変えていく必要があるのかもしれない。」（Gawande 2009、吉田訳 2016、p.198）
医師がチェックリストの使用方法を学び、仕事の質を向上させているなら、アジャイルチームでも同じことができます。システムの品質特性のチェックリストは、創造性を抑えるものではなく、セーフティネットとして機能します。開発者には特定のシステム品質要件について何が重要かを意識させ、QAには特定の品質特性だけではなく、システムとして期待されることを確実に把握させてくれます。
PLoP（Pattern Language of Programs）2015 Workshopで同僚だったJames Thorpeのチェックリストの例を次に示します。
チェックリストは1ページに収まることが重要です。上記の例には、Jamesの会社のプロジェクトで重要とされることが含まれています。このチェックリストには、コード品質と具体的なパフォーマンス指標の項目があります。満たせない品質要求は記述しなくても構いませんが、一般的な要求の例外があるなら、簡単に記述する必要があります。
良いチェックリストとは何でしょう？
- チェックする項目が多すぎないこと
- システム品質カテゴリごと、または、コンポーネントごとに整理されていること
- アーキテクチャを横断し、多くの異なるストーリーに影響を与える品質属性の、測定可能な値を指定していること
- 重要な品質特性の基準値を明記していること
- 特定のプロジェクトまたは製品に合わせて調整されていること
コードの品質などに関する一部のチェックリストは、各スプリントで「完成（done）」を宣言する前に評価される必要があります。ただし、パフォーマンスやセキュリティなどのチェックリストは、システム全体が統合されてからでないと検証ができません。また、チェックリストを自動でチェックする支援ツールを自作して使っても良いのですが、チェック項目が検証済みであることをしっかり検査することの替わりにはなりません。別のアジャイルチームの例ですが、開発者がレビューしなくても大丈夫と思った急ぎの「修正（fix）」が商用トラブルを引き起こしてしまい、その後、Webアプリケーションのスレッドに関するコード変更は、デプロイ前にすべてレビューする、というチェック項目を追加したそうです。
チェックリストは複数あっても良いでしょう。どのチェックリストも、目の前のタスクに限定したものである必要があります。これを使用して、プロセスの次のステップに進む前に、満たす必要のある項目にチェックマークを付けます。たとえば、コードの品質、パフォーマンス、セキュリティに関する、特定のチェックリストがあるかもしれません。チェックリストはさまざまなレベルの粒度で作成できますし、品質に関する項目はすべてのチェックリストに含めることができます。たとえば、ソフトウェアを商用環境にリリースするための品質チェックリストに、環境のセットアップやロールバックの検証などで必ず実行する詳細な手順が含まれていることがあります。または、次のスプリントを計画する前に、クリティカルなアジャイル着陸ゾーンの最小値を下回っていないか確認するという、パフォーマンス関連のチェックリストがあるかもしれません。
