こんにちは。プラットフォーム開発部 EMのchikaです。
先月、アジャイル開発におけるQAの考え方 という記事を投稿しました。
miraitranslate-tech.hatenablog.jp
今回は、その中で触れられなかった、品質ってなんだっけ？アジャイル開発では品質って今までと同じ考え方でいいの？ということ考えたときに調べたことなどを紹介しようと思います。
品質って、何ですか？
「このプロダクトにおける品質ってなんでしょう？」という質問は難しいなといつも思います。明快に答えられるチームは本当に素晴らしいなと思います。
品質を上げる、品質を保証する・担保する、などという言い方がされますが、品質とは何でしょうか？
普段何気なく使ってしまうわりには決して簡単には答えの出ない問いですが、品質という言葉は非常に広い概念なので、せめてプロダクト開発をするチームやエンジニア・QAがスコープとすべき品質が何か、アジャイル開発では品質として何を考えればよいのかの指針がほしいところです。
今回は、プロダクトの品質というよりは開発チームが考えるべき品質について、主にアジャイル開発をベースとしたチームにおいて考えるべきことについて調べてみました。
まずは、ソフトウェアやサービスにおける品質とは何かの定義から探っていきます。
品質の定義・分類のモデル
アジャイル開発に限らない話ですが、品質スコープを考える際に参考となる品質の分類方法について、基礎知識として知っておきたいモデルを3つ、簡単に挙げておきます。
- ISO/IEC 25010:2011
- 外部品質、内部品質
- 狩野モデル
これらをご存知の方は、以下の説明は飛ばしてください。
ソフトウェア品質特性の８分類（ISO/IEC 25010:2011）
ソフトウェアの品質は誰のためのものかと言えば、まず思い浮かぶのは利用者ですが、提供側にもビジネス担当者、開発者、運用担当者など、ステークホルダーは広く存在しているため、それら幅広い関係者の期待する品質観点を整理されたものが、国際規格「ISO/IEC 25010:2011」であり、以下8つの分類から成り立っています。
| 分類 | 概要 |
|---|---|
| 1.機能適合性 | 実装された機能がニーズを満たす度合い |
| 2.性能効率性 | システムの実行時の性能や資源効率の度合い |
| 3.互換性 | 他製品やシステムと機能や情報を共有、変換できる度合い |
| 4.使用性 | 効果的、効率的に利用できる度合い |
| 5.信頼性 | 必要時に実行できる度合い |
| 6.セキュリティ | 不正に悪用されることがなく、情報やデータが保護される度合い |
| 7.保守性 | 効果的、効率的に保守や修正ができる度合い |
| 8.移植性 | 効果的、効率的に他のハードウェアや実行環境に移植できる度合い |
外部品質、内部品質
先の8分類が、ステークホルダーの多様な要求を特性として整理したものであるのに対して、利用者と提供者でそれぞれ評価する項目が違うことを観点に外部品質、内部品質という2つの分類にしたものもあります。
- 外部品質（利用者品質）
- 顧客を含む製品のユーザーが実際に製品を利用した時に感じる品質を示す概念
- 正確性、使いやすさ、効率性、信頼性などが含まれ、利用する過程で気づくことができるもの
- 内部品質（提供者品質）
- ソフトウェア内部のつくりを示す概念で、ユーザーには見えない品質
- ソースコードや仕様書のほか、保守性や柔軟性、移植性、テストのしやすさ（テスト容易性）などが含まれる
- ソフトウェアの開発に携わった開発者や運用・保守担当者により影響を与える品質
狩野モデル
こちらは顧客の求める品質に焦点を当てて品質要素を5つに分類したモデルで、そのうち特に以下の3つがよく用いられます。
- 当たり前品質
- あって当たり前、ないと不満
- 仕様通り動くこと、「当然あるよね？」と思われる機能
- 一元的品質
- あると嬉しいけど、ないと不満
- UI使いやすい / 使いにくい
- 魅力的品質
- なくても構わないが、あると嬉しい
- 動画の自動翻訳機能、次に読む本のレコメンド、スケジュールの自動登録、サービス自動連携など
これらは、顧客満足度の向上を実現するための課題の重要度、優先順位付けを考えるのに有効です。
（参考文献）
上記3つのモデルについてはこのSHIFT社のサイトが参考になります。
詳しく知りたい方は是非読んでみてください。
プロダクト開発のときに品質モデルが教えてくれること
ここまでに取り上げた品質モデルがどう役に立つのか、ということですが、プロダクト開発チームのエンジニアが開発のプロセスで品質のスコープや優先順位を考える際には、ISO/IEC 25010:2011 の8分類や、外部品質・内部品質という考え方（特に内部品質）が参考になると思います。
内部品質には、ソースコードや仕様書にバグがないか、といったおよそイメージされる品質だけでなく、保守性や移植性、テスト容易性なども含まれるため、リリース後の運用まで含めたライフサイクルの中で重要となる品質分類です。
一方、POと一緒にプロダクトの品質を考える際には、顧客の求める品質の分類である狩野モデルが役に立ちそうです。
無限に出てくるプロダクト施策の優先順位を検討するにあたり、
を考えて取捨していくことが、プロダクトに対する価値観を合わせることにもなるかと思います。
統計的品質管理における品質の代用特性
アジャイル開発における品質を考える際に、もう1つ参考になる観点が品質の代用特性です。
以下の記事を参考に紹介します。
アジャイル開発の品質管理技法（中編）- 統計的品質管理の応用
代用特性とは、ある特性を直接測定できない場合に、対象の特性と連動する他の特性を観測することで代替する特性のことを言います。
（例）アルコール温度計は温度ではなく、アルコールの体積を測っている（温度とアルコール体積が連動するため、代用特性として利用できる）
ウォーターフォール開発においては、統計的品質管理*1によって品質を評価するにあたり、設計指摘数、コード行数、テスト本数、バグ数*2 などの指標が品質基準となっていたと言います。
これは、過去の様々な別プロジェクトにおける指標と比較することで、そのプロジェクトでの品質の評価がしやすかった（他に方法がなかった）からです。
アジャイル開発における品質の代用特性
では現代の開発現場に多いアジャイル開発では何が代用特性になり得るのでしょうか。
結論を言えば、アジャイル開発はスピードに着目し、リードタイム、サイクルタイムを表すメトリクス、具体的にはチケットのライフサイクルで観測するということを先の記事で言及されていました。
これは、アジャイル開発では過去の比較対象とすべきは数多ある別のプロジェクトではなく、同じメンバー・技術・開発プロセスで開発してきた自分たちの過去（直近）の開発のプロセスとするのが最もふさわしいということです。
チケットのライフサイクルからプロセスの安定化を見ることで、それが品質そのものを表すわけではないですが、プロセスが乱れたときに「何か想定外のことが起きている可能性がある」という事が検知でき、再点検するアクションが取れるということです。
この、スピードに着目して品質を考えるという話は個人的にすごく納得感がありました。
品質とスピードはトレードオフなのか？
ここまでで出てきた「品質」と「スピード」というキーワードを聞いて思い出しましたが、品質とスピードはトレードオフ要素として捉えられがちですが、果たして本当にそうでしょうか？
仮に、内部品質（ソフトウェアの作りの品質）を犠牲にしてスピードを上げようとしたらどうなるでしょうか。
確かに短期的には工数が短縮できるかもしれませんが、以下のような事態が容易に想定され、中長期的にはスピードも犠牲になっていきます。
- リリース後に不具合が発生すれば改修することになるのでスピードが落ちるどころか開発が止まる
- 保守性の悪いコードを生み出してしまったら、そのコードに対する追加開発や改修を行う難易度が上がってしまい、スピードはじわりじわりと低下していく（技術的負債の蓄積）
逆もまた然りで、つまりトレードオフの関係にはない、ということです。
このあたりについては、ここで色々説明するよりも、以下の資料を読めば明確に分かると思いますので、参考までに貼っておきます。
※毎年、登壇テーマに合わせて一部を変えたりしてブラッシュアップされ続けている、これぞまさに超高品質なプロダクトですね。
↓動画講義もあります。
TEST Study #1「品質とスピード」 #TEST_Study - YouTube
品質は保証できるものなのか？
ところで少々余談ですが、品質は「保証」できるのでしょうか？
QA＝Quality Assurance ではありますが、QAによって品質を「保証します」「担保します」というのがどうにも違和感ががあります。
仮に従来型QAの考えで 「仕様通りに動くこと」を確認できたとしても、そもそも「（仕様通りに動いても）品質って保証できるんだっけ？」と思ってしまいます。
この点、アジャイルコーチの藤原 大さん (@daipresents)のブログで言及されており、QA＝品質保証でなく、品質合意という解釈を用いていました。
どのレベルまでテストするか？といったテストのスコープぎめが重要になります。そのスコープに対して品質合意（Quality Agreement：QA）をチーム全体で行います。
（アジャイル開発とQA（品質保証）は相性がバツグンに悪いより抜粋）
個人的にはいつも「品質を担保する」というのが重々しく感じてしまい発しにくいと思っているので、「品質合意」という言葉はとても良いなと思いました。
まとめ
アジャイル開発を志向するにあたり、QAエンジニアが「QAフェーズ」で「品質保証」するという考え方に開発プロセスとしての違和感を感じたこと、伝統的な開発プロジェクトのように「仕様通りであること」「バグがないこと」に焦点を当てることが現代的な開発に合っているのか？と疑問に感じていたことなどを発端として、今回は色々調べてみました。
アジャイルQAで品質を上げるのに重要なのは開発プロセスの質とスピードであり、チーム全員のQAに関する意識やスコープであり、それを牽引するリーダーとなるQAエンジニアであるという事が分かり、一本筋が通った理解ができた気がします。
そして、アジャイル開発で品質を向上するということは、テストも含めた開発プロセスを小さく速く回してデプロイし続けることで、常に改善し続けられる状態 にすることではないかと理解しました。
参考
- アジャイル開発とQA（品質保証）は相性がバツグンに悪い
- アジャイル・DevOps時代の テストと品質保証
- アジャイル開発の品質管理技法（中編） 統計的品質管理の応用
- fukabori.fm - 71. アジャイルソフトウェア開発と統計的品質管理 w/sakata_akinori
- "品質指標は、いつもと同じかどうかを見ていただけ"
- 質とスピード（2022春版、質疑応答用資料付き）
We are hiring!
みらい翻訳では、私たちと一緒にプロダクト開発を進めていただけるエンジニアを募集しています！ ご興味のある方は、ぜひ下記リンクよりご応募・お問い合わせをお待ちしております。
