CodeZine(コードジン)

特集ページ一覧

品質の可視化のためのパターン「システム品質アンドン」「品質ロードマップ」「品質バックログ」

QA to AQ 第8回

  • LINEで送る
  • このエントリーをはてなブックマークに追加
2021/03/25 11:00

 本連載では、アジャイル開発において効率的かつ効果的に品質保証を進めるために有用な実証済みのパターン集『Quality Assurance to Agile Quality』(以下、QA2AQ)の和訳を、関連するいくつかのまとまりに分けて提供することで、アジャイル開発における品質保証の実践をお手伝いしてきました。最終回となる第8回は、重要な品質を可視化しチームメンバーに気付かせるパターンをまとめた、分類「品質の可視化」の中から3つのパターン「システム品質アンドン(System Quality Radiator)」「品質ロードマップ(Qualify the Roadmap)」「品質バックログ(Qualify the Backlog)」の和訳を提供します。

目次
表1 QA2AQにおける分類とパターン
分類 概要 パターン名
中核 他のパターンを用いるうえでの基礎となるパターン
  • アジャイル品質プロセス [1](第1回)
  • 障壁の解体 [3](第1回)
品質のアジャイルなあり方 アジャイルプロセスにおける品質保証のあり方や役割のパターン
  • QAを含むOneチーム [1](第2回)
  • 品質スプリント [1](第2回)
  • プロダクト品質チャンピオン [5](第2回)
  • アジャイル品質スペシャリスト [6](第3回)
  • 品質チェックリスト [5](第3回)
  • 品質作業の分散 [6](第3回)
  • 品質エキスパートをシャドーイング [5](第4回)
  • QAリーダーとペアリング [3](第4回)
  • できるだけ自動化 [6](第4回)
品質の特定 重要な品質を特定するためのパターン
  • 重要な品質の発見 [2](第5回)
  • 品質シナリオ [1](第5回)
  • 品質ストーリー [1](第5回)
  • 測定可能なシステム品質 [2](第6回)
  • 品質の折り込み [1](第6回)
  • 着陸ゾーン [2](第6回)
  • 着陸ゾーンの再調整 [2](第7回)
  • 着陸ゾーンの合意 [2](第7回)
品質の可視化 重要な品質を可視化しチームメンバーに気付かせるパターン
  • システム品質ダッシュボード [2](第7回)
  • システム品質アンドン [4](第8回)
  • 品質ロードマップ [4](第8回)
  • 品質バックログ [4](第8回)

システム品質アンドン

  • パターン:システム品質アンドン(原題System Quality Radiator 原著 Joseph W. Yoder, Rebecca Wirfs-Brock, Hironori Washizaki)[4]

 「豪華なプレゼンテーションは自分にとって魅力的であるとともに、他の人を納得させるものでなければならない」――Freddie Mercury(クイーンのボーカリスト)

 通常、アジャイルソフトウェア開発では、アーキテクチャやクリティカルな品質など、システムの他の重要な側面に注意を払うより前に、見栄えや機能性に注目します。アジャイルプロジェクトでは、「動くものを作ってから、最適化する」といった声を耳にすることがあります。ほとんどのアジャイルプラクティスでは、プロダクトオーナーによって優先度付けされたバックログに従い、重要な機能要件を開発するように促されるでしょう。

 システムが発展するにつれて、システムが持つべき品質特性の何が重要で、どのようにそれらを測定するか理解しはじめます。そして、これらの品質特性の測定値を追跡することと、システムの現在の品質を知ることは、ますます重要になっていきます。品質特性の中には製品の成功の鍵となる必要不可欠なものもあるからです。

 アジャイルチームは、システムの重要な品質特性とその現在のステータスを、アクセスしやすく、確認しやすくする手段を、どうすれば提供できるでしょう?

***

 アジャイル開発者は、ユーザーストーリーに基づいてシステムを開発することは得意でしょう。重要な品質特性が何かを理解することも、重要な機能が何かを理解することに加えて重要なのです。重要な品質特性を可視化することは、プロジェクトの成功の鍵となるものをチームが知る上で役に立つでしょう。

 いくつかの品質特性は、可視化された有意義な指標を作成し維持することが困難です。何らかの動きがあるか、品質特性の値がそれなりの頻度で変化しない限り、人はそれらを気にしなくなるでしょう。リマインダーも有意義ですが、無視されてしまう可能性があります。

 品質状況を可視化するための多くのツールとディスプレイを作ることは、システムが出荷に必要な条件を十分に満たしているかを確認することと比べると、無意味な贅沢のように思えるかも知れません。ディスプレイの作成には時間がかかり、QAツールの構築に割けるリソースと人員は限られています。多くの場合、設計が重要な品質に与える影響を慎重に検討する時間はありません。

 同様に、何を測定し監視するかを慎重に検討する時間もありません。どの品質のモニタリングが重要であるかを知ることは困難です。より多くのシステムが構築され、品質特性が実装されるにつれて、特定の品質特性をモニタリングすることが重要になってきます。性能などの品質特性は、新しい機能を追加すると劣化することがあります。一方、一度検証され、テスト可能になったものには、時間とともに変化する可能性が低いものもあります。

 性能および信頼性といった特定の品質特性が定期的に追跡されていないと、開発プロセスの後半で改善することが非常に困難になる可能性があります。当初のシステムは品質の制約を満たしていた可能性があるものの、システムが発展するにつれて、品質特性が見えなくなり、その結果、時間とともに維持されなくなります。

***

 誰もが質問する必要なく、仕事中または休憩中に人々が見ることができるように特定のシステム品質特性とその現在のステータスに関する情報を知らせるディスプレイを設けましょう。

 システム品質アンドンには、ポスターやディスプレイから、かんばんボード上の色付きの付箋、色付きのバックログアイテムまで、さまざまな形式があります。重要なことは、品質アンドンが目の届くところにあって理解しやすいことです。また、品質アンドンを最新の状態に保つことも重要です。Alistair Cockburnは次のように述べています[Coc]:

 「アンドンは、仕事をしている人や通りすがりの人が目にできる場所に掲示されているディスプレイである。それは、皆が関心のある情報を、誰にも質問する必要がない形で表示するものである。これは、割り込みをより少なくし、より多くのコミュニケーションを可能にすることを意味する」

 ディスプレイには、チームが積極的に取り組んでいる、現在の着陸ゾーンの値、現在のスプリントの品質ストーリー、品質に関する活動についてのリマインダー、または品質の測定値が表示される場合もあります。その日のあるシステム品質関連テストの結果を表示するだけのこともあるでしょう。サードパーティのツールを使用して、主要なシステム品質特性と現在の値を表示することもあります。

 また、測定可能なシステムを監視して可視化する特定のツール(場合によっては開発環境へのプラグインとして)を作成する必要がある場合もあります。チームがシステムのリアルタイム監視を開始すると、ツールがシステム品質ダッシュボードに発展する可能性もあります。一部の品質特性は直接測定できませんが、注意することが必要です。これらの品質特性はアンドンとして掲げて、チームで忘れないようにしましょう。

 システム品質アンドンにはシステム品質ダッシュボードを含めることができますが、アンドンとダッシュボードの主な違いは、アンドンが意図的に品質の状態と情報を一目で伝えることを目的としていることです。一方、ダッシュボードには、ちょっと立ち寄っただけの観察者には簡単に理解できない、非常に詳細な情報を含んでいる場合があります。システム品質ダッシュボードは必ずしもシステム品質アンドンではありませんが、システム品質アンドンの一部として含めることはできます。

 また、システムの重要な品質特性のチャートやリストをその目標値とともに作成し、それをチームに見えるようにしてください。このチャートには、特定の品質についての測定値ではなく、あるスプリントで、または複数のスプリントで関心のあった特定の品質項目に関するリマインダーが含まれている場合があります。

 品質関連のよくあるリマインダーの例を次に示します。

  • すべてのサービス呼び出しのパフォーマンスを調整する…
  • 監査ログが生成されていることを確認する…
  • セキュリティホールの特定に関心を持つ…
  • キャッシングによる高速化に取り組み続ける…

 システム品質アンドンは、実際の測定値、目標、短期的な目標、および長期的な品質目標を組み合わせたものにすることもできます。品質に関する情報の表示は1つだけとする必要はありません。重要なことはシステム品質アンドンを新しい情報で頻繁に更新することです。そうしないと見て貰えなくなるでしょう。出される情報が多すぎると、何が本当に緊急で重要な品質なのかを解釈することが難しくなり、値の変化を見失ったり無視したりする可能性もあります。


  • LINEで送る
  • このエントリーをはてなブックマークに追加

あなたにオススメ

著者プロフィール

  • 鷲崎 弘宜(ワシザキ ヒロノリ)

     早稲田大学 研究推進部 副部長・グローバルソフトウェアエンジニアリング研究所所長・教授。国立情報学研究所 客員教授。株式会社システム情報 取締役(監査等委員)。株式会社エクスモーション 社外取締役。ガイオ・テクノロジー株式会社 技術アドバイザ。ビジネスと社会のためのソフトウェアエンジニアリングの研...

  • 長谷川 裕一(ハセガワ ユウイチ)

     合同会社Starlight&Storm 代表社員。日本Springユーザ会会長。株式会社フルネス社外取締役。  1986年、イリノイ州警察指紋システムのアセンブリ言語プログラマからスタートして、PL,PMと経験し、アーキテクト、コンサルタントへ。現在はオブジェクト指向やアジャイルを中心に...

  • 濱井 和夫(ハマイ カズオ)

     NTTコムウェア株式会社 技術企画部プロジェクトマネジメント部門、エンタープライズビジネス事業本部事業企画部PJ支援部門 兼務 担当部長、アセッサー。PMOとしてプロジェクトの適正運営支援、及びPM育成に従事。  IIBA日本支部 教育担当理事。BABOKガイド アジャイル拡張版v2翻訳メンバー...

  • 小林 浩(コバヤシ ヒロシ)

     株式会社システム情報 フェロー CMMコンサルティング室 室長。CMMI高成熟度リードアプレイザー(開発,サービス,供給者管理)。AgileCxO認定APH(Agile Performance Holarchy)コーチ・アセッサー・インストラクター。Scrum Alliance認定ScrumMas...

  • 長田 武徳(オサダ タケノリ)

     株式会社エヌ・ティ・ティ・データ シニアITアーキテクト。ITサービス・ペイメント事業本部所属。2006年入社以来、決済領域における各種プロジェクトを担当後、2018年よりプロダクトオーナ・製品マネージャとしてアジャイル開発を用いたプロジェクトを推進。現在は、アジャイル開発におけるQAプロセスの確...

  • 田村 英雅(タムラ ヒデノリ)

     合同会社 GuildHub 代表社員。日本 Spring ユーザー会スタッフ。大学で機械工学科を専攻。2001 年から多くのシステム開発プロジェクトに従事。現在では主に Java(特に Spring Framework を得意とする)を使用したシステムのアーキテクトとして活動している。英語を用いた...

  • 陳 凌峰(チン リョウホウ)

     フリーランサー。2003年に上海交通大学(ソフトウエア専門)を卒業後、2006年から日本でシステム開発作業に従事。技術好奇心旺盛、目標は世界で戦えるフルスタックエンジニア。現在はマイクロサービスを中心にアジャイル 、DevOpsを展開中。

バックナンバー

連載:QA to AQ:アジャイル品質パターンによる、伝統的な品質保証からアジャイル品質への変革

もっと読む

All contents copyright © 2005-2021 Shoeisha Co., Ltd. All rights reserved. ver.1.5