Adways Advent Calendar 2019 12日目の記事です。

http://blog.engineer.adways.net/entry/advent_calendar_2019

この春から開発組織でエンジニアリングマネジメントをしている金谷です。
これまで、15年以上をインフラ組織でエンジニアやマネージャとして歩んできましたが、自分の得意領域から外れた環境で組織づくりに挑戦したいと思い、異動してきました。

年末のこの時期、大きなリリースはやや控え目になり、やり残しのチケットや期末の振り返りを行うことが多いと思います。今日はそんな時にちょうど使える、「システム・ソフトウェア製品の品質モデル」を活用した課題発掘ワークをご紹介いたします。

「システム・ソフトウェア製品の品質モデル」とは

皆さんのチームではシステム品質を体系的かつ網羅的にマネジメントする仕組みはありますか？それは有効に機能していますか？

今回はソフトウェア品質の国際規格である ISO/IEC 25000シリーズ、通称 SQuaRE（スクウェア）に定義されている品質モデルを引用して話を進めて行きます。

f:id:AdwaysEngineerBlog:20191216230513p:plain

この品質モデルには、機能適合性、性能効率性、互換性、使用性、信頼性、セキュリティ、保守性、移植性の計8つの品質特性が定義され、それぞれに品質副特性が展開されています。
例えば、「保守性が低い」という話になったときに、それは変更時の影響具合を見極めづらいという「解析性」の事を指すのか、または変更のしやすさを示す「修正性」を指すのか、このモデルを見ながら話すことで、品質全体を意識し具体的な課題感の認識をチームで持つ事ができます。

機能適合性：
- 明示された状況下で使用するとき，明示的ニーズ及び暗黙のニーズを満足させる機能を，製品又はシステムが提供する度合い
性能効率性：
- 明記された状態（条件）で使用する資源の量に関係する性能の度合い
互換性：
- 同じハードウェア環境又はソフトウェア環境を共有する間，製品，システム又は構成要素が他の製品，システム又は構成要素の情報を交換することができる度合い
使用性：
- 明示された利用状況において，有効性，効率性及び満足性をもって明示された目標を達成するために，明示された利用者が製品又はシステムを利用することができる度合い
信頼性：
- 明示された時間帯で，明示された条件下に，システム，製品又は構成要素が明示された機能を実行する度合い
セキュリティ：
- 人間又は他の製品若しくはシステムが，認められた権限の種類及び水準に応じたデータアクセスの度合いをもてるように，製品又はシステムが情報及びデータを保護する度合い
保守性：
- 意図した保守者によって，製品又はシステムが修正することができる有効性及び効率性の度合い
移植性：
- 一つのハードウェア，ソフトウェア又は他の運用環境若しくは利用環境からその他の環境に，システム，製品又は構成要素を移すことができる有効性及び効率性の度合い

※品質副特性の詳細については今回は割愛

どうやって課題発掘ワークに活用するか

システムを開発する際、様々な理由で機能開発が中心的に進められ、品質についてはつい後回しになってしまう状況が、身近な経験だけでなく、アンチパターンとしてよく語られているかと思います。
そうした誤った開発プロセスを根本的に正していくこと(※)も重要ですが、すでに目の前にある「品質後回し」の産物を相手する際、このワークが役立つのではないかと思います。
※私たちは、@t_wadaさんの「質とスピード」をチームで読み解くところから始めました。

ワークの順序を以下に記します。一例として参考にしてください。

まずは、製品品質モデルに頼らず「システムの品質で課題に思うところ」や「品質上の改善アイデア」をチームで出していきます。付箋でどんどん貼っていくと良いでしょう。我々は、リモート拠点のメンバーもいたこともあり、 Miroを使いました。
一通り出し切ったあと、製品品質モデルを見ながら、品質特性別に振り分けていきましょう。意見の偏りや、網羅性の度合いが見えてくるはずです。出てきた意見を振り分けながら、課題感の認識を合わせていきましょう。
最後に、意見の出なかった品質特性について、「見過ごしている課題はないか？」話し合ってみましょう。もう一度、付箋で意見出しをしてもよいですね。緊急性は低いものの重要な品質課題などが浮かび上がってこないでしょうか？

ここまで出来れば、あとは緊急性や優先度を決めて、タスクとして切り出していくことで品質改善の活動に繋げることができるはずです。

なお、このワークのポイントは2点あり、

現状の品質に対してチームが思っている課題認識をまず出し切ること。（チームは、色々な課題意識を常に持っているはず）
その上で、品質全体を見渡したときに、抜け漏れがあることに気づくこと

にあります。

最初から製品品質モデルを踏まえて意見出しをしていく方法も良いかと思いますが、抜け漏れに対する気づきや学びを得るために、私たちはこの方法で試してみました。品質との向き合い方に対する内省を深める狙いもあります。

最後に

今回引用したSQuaREシリーズには、「システム／ソフトウェアの製品品質モデル」の他に、「利用時の品質モデル」と「データ品質モデル」も存在します。それぞれの視点で同じように活用することが出来るでしょう。
また、品質管理の1つである本ワークは、「品質保証」の実践として提案するものですが、そもそも「品質保証」の原則に立ち返ると、