品質保証の説明の難しさ
プロダクトの品質についての理解とは、エンジニアと非エンジニアの間でしばしば誤解が生じるテーマです。
「品質」と一言に表しても、それは「内部品質」、「外部品質」に分けられ、「内部品質」と「外部品質」に関してもISO/IEC 25010:2023[1]で定義されている複雑な品質特性と副特性が存在します。
ステークホルダーが一番気にしているのはアウトカムであることが多く、一方でソフトウェアエンジニアが気にしているコードの品質やアーキテクチャ、テストなどにはなかなか目が向けられないことが多いかと思います。
ソフトウェアエンジニアとしては「プロダクトの品質向上」「生産性向上」の観点から、アウトカム以外の品質の改善も進めていきたい場面もあるため、その旨をステークホルダーに説明して理解してもらう必要があります。
ですが、色々と言葉を尽くした結果、あまりステークホルダーの理解が進まなかったという経験はみなさんにもあるのではないでしょうか。
品質保証はプロダクトに関わる全員が留意すべき事項ですが、品質保証に関して専門家ではない（ソフトウェアエンジニア以外の）ステークホルダーに対して、どこまで細かい情報まで含めて説明すると良いのでしょうか。
品質の新たな説明モデル
ソフトウェアエンジニアとして、ステークホルダーに理解してもらいたいのはアウトカムの品質以外の重要性ですが、説明も理解も難しいものです。
もっとシンプルに説明できないかと他業界を見ていると、医療の質を評価する「ドナベディアンモデル[2]」が参考になるのではないかと考えました。
ドナベディアンモデルは、医療の品質を「ストラクチャー（構造）」、「プロセス」、「アウトカム（結果）」の3つの要素で説明するもので、シンプルなモデルです。
このシンプルなモデルをソフトウェア開発の品質評価に適用することで、より多くの人に理解してもらえるのではないでしょうか。
ドナベディアンモデルを用いた説明の例
プロダクトの品質と聞いて何を想像するでしょうか。
顧客に提供する価値でしょうか、インシデントの回数でしょうか。
もちろんそれらも品質に含まれますが、プロダクト開発に関わるのであれば「アウトカム」だけの品質を考えるだけでは不十分です。
根本的な品質保証には「アウトカム」を生み出す「プロセス」、「ストラクチャー」にまで目を向けなければ、恒久的な品質保証は難しいものです。
恒久的な品質保証のために考える必要があるのは、「ストラクチャー」「プロセス」「アウトカム」の3つの観点です。
たとえば道路（ストラクチャー）に穴が空いていたとして、穴を避けて進んだり、スピードを落として進んだり（プロセス）して、事故を避けることもできます。
いかに小回りを利かせて穴を避けるか、いかにスピードを落とさずに穴を避けるかといったプロセスの改善もできますが、根本的な解決方法は穴を塞ぐことです。
目的地に向かうために毎回穴を避けたり、スピードを落とすことは、それが与える影響がどんなに最小のものとなっても無駄な行為です。
もちろん穴を塞ぐことにもコストはかかりますが、一度穴を塞いでしてしまえば、そのあとは安心・安全に運転することが可能となります。
事故を起こさないという同じアウトカムは得られますが、プロセスやストラクチャーに目を向けないということは無駄な行為（穴を避けたり、スピードを落としたり）をし続けることにつながります。
ChatGPTによる生成画像
以降は、ストラクチャー、プロセス、アウトカムについて、ソフトウェア開発に近づけて考えてみます。
ストラクチャー
ChatGPTによる生成画像
ストラクチャーは、プロダクトが提供されるための基盤となる要素を指します。
これには、「利用可能なリソース」「チームの構成」「使用される技術、ツール」などが含まれます。
ストラクチャーは開発プロセスをスムーズに進め、高品質なプロダクトを生み出すための基礎となるため、適切なストラクチャーを整えることが重要です。
例えば、十分な予算と人的資源がある組織は、より高品質のプロダクトを生み出す可能性が高いですし、経験豊富なエンジニアやQA専門家がいるかどうかも、品質に大きな影響を与えます。
ストラクチャーの要素について、いくつか例を挙げてみます。
リソース
極端な例かもしれませんが、メモ帳で開発するのと、Intellij IDEAのようなIDEを利用するのとではどちらが良い品質を提供できそうでしょうか。
IDEを利用したほうが、IDEによる補助を受けられるため、より良い品質のコードを早く書けるのではないでしょうか。
チームの構成
経験豊富なソフトウェアエンジニア、デザイナー、プロダクトマネージャーから構成された多様なスキルセットを持つチームと、ソフトウェアエンジニアだけで構成されたチームとではどちらが良い品質を提供できそうでしょうか。
おそらく多様なスキルセットを持ったチームの方が、それぞれの専門性を活かしてより良い品質を提供できるでしょう。
Tips: ストラクチャーは開発プロセスの可能性を決定する
リソース（財務、人的資源、技術）と能力（チームのスキルセット、知識）は開発プロセスの可能性を決定します。
十分な資金があれば有用なツールやサービスを導入できますし、QAのスペシャリストがいれば品質保証のレベルも上がります。
組織の構造もプロセスに影響を与えます。
たとえば、「フィーチャーチームか、コンポーネントチームか。」「フラットな組織構造か、ピラミッド型の組織構造か。」によってプロセスは変化します。
アウトカムやプロセスがストラクチャーの上に成り立つものである以上、組織構造によって影響を受けるものは多く、ストラクチャーの改善は品質にとって非常に重要なファクターとなります。
プロセス
ChatGPTによる生成画像
プロセスは、プロダクトがどのようにして提供されたかに関するものです。
これには、「要求分析から設計、実装、テスト、リリースまでの一連の手順」が含まれます。
効率的かつ効果的なプロセスの構築は、時間とコストを節約しながら品質を維持または向上させることができます。
プロセスがアウトカムに影響を与えるというのは、ソフトウェアエンジニアにとっては想像がつきやすいものだと思います。
例えば、アジャイル開発方法論の採用や、コードレビュー、継続的インテグレーション（CI）、継続的デリバリー（CD）などを実践することで、柔軟で迅速な開発プロセスを構築することができます。
アウトカム
ChatGPTによる生成画像
アウトカムは最もわかりやすい話だと思います。
開発されたプロダクトが市場でどのような成果を達成したか、またはユーザーにどのような価値を提供したかについての指標です。
顧客満足度、市場シェア、収益性、ユーザーエンゲージメントなどのKPIを用いて、プロダクトの成功を測定することが多いでしょう。
まとめ
ソフトウェア開発の品質を改善するためには、ストラクチャー、プロセス、そしてアウトカムの面からアプローチする必要があることが、ドナベディアンモデルを応用することで理解しやすく伝えることができるのではないでしょうか。
品質に対する関係者の理解を深めることは、組織内のコミュニケーションを改善し、品質保証の取り組みを全社的に推進する上で非常に価値がありますが、必ずしも全員が専門的な詳細部分までを理解をする必要はありません。
アウトカムを構成する要素として、プロセスがあり、ストラクチャーがあることを理解してもらうことができれば、非エンジニアの方と共通言語で対話するための第一歩を踏み出せるでしょう。
もし非エンジニア向けの品質保証の説明に困っていらっしゃる方がいれば、一度ドナベディアンモデルを用いた説明から始めてみてはいかがでしょうか。
補記：当社本部長（非エンジニア）からは、わかりやすかったと評価いただきました。
Discussion