http://blog.engineer.adways.net/entry/advent_calendar_2019この春から開発組織でエンジニアリングマネジメントをしている金谷です。これまで、15年以上をインフラ組織でエンジニアやマネージャとして歩んできましたが、自分の得意領域から外れた環境で組織づくりに挑戦したいと思い、異動してきました。年末のこの時期、大きなリリースはやや控え目になり、やり残しのチケットや期末の振り返りを行うことが多いと思います。今日はそんな時にちょうど使える、「システム・ソフトウェア製品の品質モデル」を活用した課題発掘ワークをご紹介いたします。SQuaRE(スクウェア)に定義されている品質モデルを引用して話を進めて行きます。セキュリティ、保守性、移植性の計8つの品質特性が定義され、それぞれに品質副特性が展開されています。「保守性が低い」という話になったときに、それは変更時の影響具合を見極めづらいという「解析性」の事を指すのか、または変更のしやすさを示す「修正性」を指すのか、このモデルを見ながら話すことで、品質全体を意識し具体的な課題感の認識をチームで持つ事ができます。機能適合性:明示された状況下で使用するとき,明示的ニーズ及び暗黙のニーズを満足させる機能を,製品又はシステムが提供する度合い性能効率性:明記された状態(条件)で使用する資源の量に関係する性能の度合い互換性:同じハードウェア環境又はソフトウェア環境を共有する間,製品,システム又は構成要素が他の製品,システム又は構成要素の情報を交換することができる度合い使用性:明示された利用状況において,有効性,効率性及び満足性をもって明示された目標を達成するために,明示された利用者が製品又はシステムを利用することができる度合い信頼性:明示された時間帯で,明示された条件下に,システム,製品又は構成要素が明示された機能を実行する度合いセキュリティ:人間又は他の製品若しくはシステムが,認められた権限の種類及び水準に応じたデータアクセスの度合いをもてるように,製品又はシステムが情報及びデータを保護する度合い保守性:意図した保守者によって,製品又はシステムが修正することができる有効性及び効率性の度合い移植性:一つのハードウェア,ソフトウェア又は他の運用環境若しくは利用環境からその他の環境に,システム,製品又は構成要素を移すことができる有効性及び効率性の度合い※品質副特性の詳細については今回は割愛どうやって課題発掘ワークに活用するかシステムを開発する際、様々な理由で機能開発が中心的に進められ、品質についてはつい後回しになってしまう状況が、身近な経験だけでなく、アンチパターンとしてよく語られているかと思います。した誤った開発プロセスを根本的に正していくこと(※)も重要ですが、すでに目の前にある「品質後回し」の産物を相手する際、このワークが役立つのではないかと思います。※私たちは、@t_wadaさんの「質とスピード」をチームで読み解くところから始めました。ワークの順序を以下に記します。一例として参考にしてください。製品品質モデルに頼らず「システムの品質で課題に思うところ」や「品質上の改善アイデア」をチームで出していきます。付箋でどんどん貼っていくと良いでしょう。Miroを使いました。一通り出し切ったあと、製品品質モデルを見ながら、品質特性別に振り分けていきましょう。意見の偏りや、網羅性の度合いが見えてくるはずです。出てきた意見を振り分けながら、課題感の認識を合わせていきましょう。最後に、意見の出なかった品質特性について、「見過ごしている課題はないか?」話し合ってみましょう。一度、付箋で意見出しをしてもよいですね。緊急性は低いものの重要な品質課題などが浮かび上がってこないでしょうか?ここまで出来れば、あとは緊急性や優先度を決めて、タスクとして切り出していくことで品質改善の活動に繋げることができるはずです。現状の品質に対してチームが思っている課題認識をまず出し切ること。(チームは、色々な課題意識を常に持っているはず)その上で、品質全体を見渡したときに、抜け漏れがあることに気づくことにあります。最初から製品品質モデルを踏まえて意見出しをしていく方法も良いかと思いますが、抜け漏れに対する気づきや学びを得るために、私たちはこの方法で試してみました。品質との向き合い方に対する内省を深める狙いもあります。最後に今回引用したSQuaREシリーズには、「システム/ソフトウェアの製品品質モデル」の他に、「利用時の品質モデル」と「データ品質モデル」も存在します。それぞれの視点で同じように活用することが出来るでしょう。顧客視点の品質保証であること組織的な品質保証活動を行うこと定量的な先手品質マネジメントであることこれらを踏まえた計画と実践を継続的に行うことが重要になってきます。今日紹介したワークは、どちらかと言えば後手となった時の一歩目に他なりません。エンジニア、デザイナー、プロダクトオーナー、時にはステークホルダーも交えて品質に対する言葉の定義と重要性を認識し、正しい開発プロセスを継続的に行う「品質保証」活動に繋げていくことが大切です。皆さんのシステムの品質改善に何かしら役立つ知見となれば幸いです。最後までお読みいただき有難うございました。次はりょーまさんの記事です。http://blog....2019-06-28使われるモノを作るためにARRRAを採用したお話こんばんは。