NTTコムウェア | エバンジェリストが語るICTの未来 | Scrum Fest Osaka 2021講演リポート　開発者の現場で考えるべき、プロダクトの品質とユーザー視点の品質

「品質」への見方が変わった。
今、開発者が考えるべき
２つの「品質」とは？
アジャイルでも「当たり前品質」を
満たすためのアプローチとは？

アジャイルにおける
「魅力的品質」へのアプローチ
アジャイル開発での「品質」へ、
現場が考えるべき２つのアプローチ

NTTコムウェアのアジャイルとScrum Fest Osaka 2021 TOPページへ

2021年6月25日・26日の2日間、Scrum Fest Osaka 2021がオンラインで開催された。このイベントは、スクラムやアジャイルプラクティスに関心が高いユーザー企業やIT企業から集結したエキスパートや初心者たちが、自らの知識や情熱を共有するために活発な議論を行う場である。NTTコムウェアからは伊山宗吉がセッションスピーカーとして登壇し、開発の現場で今、考えるべき“品質”とそれを実現するためのアプローチについて語った。
（講演資料はこちら）※外部サイト

「品質」への見方が変わった。
今、開発者が考えるべき２つの「品質」とは？

「品質」とは、つながって当たり前、何があっても動き続けるというもので、「品質」≒「信頼性の高いシステム」というイメージがある種の現場にはある。
そのイメージで開発されてきたのは「SoR：データの記録を中心とした基幹系システム」であり、業務そのものをIT化する仕組みであった。
そして現在、広く求められるようになったものに、お客さまにサービスを提供する「SoE：顧客接点を中心とした情報系システム」がある。
この変化の中で、私たちNTTコムウェアが実感してきたのは、従来のような稼働率、堅牢性を「品質」としているのでは要望に応えきれれない。つまり、私たち開発者が重要であると見ていた「品質」は、その一部であったと捉え直す必要があるということ。
SoEの開発に適したアジャイルでは、「プロダクトの品質」≒「ユーザー視点の品質(顧客満足)」という価値観があり、この価値観を表現した有名な「狩野モデル」※では、顧客満足に影響を与える品質を「魅力的品質」「当たり前品質」としている。

※狩野モデル　東京理科大学名誉教授の狩野紀昭氏が1980年代に開発した顧客満足モデル

「魅力的品質」と「当たり前品質」についての解説

アジャイルにおいてはこの「魅力的品質」と「当たり前品質」の両立を考えることが、「品質」の重要なポイントである。
私たち開発者は現場でこれまで「ビジネス側」と「開発側」という形で明確に役割分担し、プロダクトの信頼性とユーザーニーズなど「品質」も分けて捉えていたが、アジャイル開発においてはこの垣根を取り払う必要がある。

「魅力的品質」と「当たり前品質」についての解説

アジャイルでも「当たり前品質」を満たすためのアプローチとは？

「当たり前品質」とは、そもそも何なのか？

まずは、アジャイルにおいて「当たり前品質」の担保に取り組もう。
プロダクトの「人によって異なる、当たり前」とは何だろうか？それが「なんとなくそうだよね」では、要求、設計、実装、テストのいずれもが人によってバラバラになってしまい、ユーザーがほしいものにならない。
だからこそ、私たちは最初に「当たり前品質」について認識合わせをする手法を重視している。

「当たり前品質」の認識合わせについての解説

この手法に至る前は、品質は後で付加していけばいいという “無計画”や、ウォーターフォールと同じように考えた “過剰品質”となるケースもあった。しかし失敗から学び、現在は認識合わせこそアジャイルの「当たり前品質」の前提として社内に広めている。

具体的には、何について認識合わせするのか？

私たちが参考にしているモデルは品質要求や評価に関するISO/IECの国際規格の「SQuaRE」であり、その中で製品品質のモデルが「当たり前品質」に相当する。
製品品質のモデルによる品質目標の認識合わせは「やる/やらない/後で決める」、つまり、インセプションデッキの「やらないことリスト」と同様に議論するように推奨している。
認識合わせした内容を開発のバックログ、設計、実装、テストの内容に反映していくことで、「当たり前品質」に関する考慮漏れを防ぐアプローチをとっている。

製品品質のモデルを参考にした品質目標の認識合わせの解説

しかし、製品品質のようなモデルだけを提示しても、「何を議論するのか」という疑問が現場に残ることがある。そこで現場への参考として、アジャイル開発向けに性能・セキュリティなど8つの品質ごとに具体例を挙げたリストを展開。リストを見ながら、「やる/やらない」を一つひとつ確認することで認識齟齬を防ぐアプローチもとっている。

品質目標を現場でどう達成するのか？

私たちは、スクラムガイド2020※に書いてある中から、以下の２つを持って品質目標の達成としている。

完成の定義を忠実に守ることにより品質を作り込む
完成の定義とは、プロダクトの品質基準を満たすインクリメントの状態を示した正式な記述である。
プロダクトバックログアイテムが完成の定義を満たしたときにインクリメントが誕生する

「完成の定義」を私たちは「Doneの定義」と呼んでいて、これが品質の重要な要素になる。私たちは最初に開発の準備段階で、認識合わせをした品質を目標とする。そして、目標にあった作業や確認内容をプロセス設計（Doneの定義）に反映させる。目標にあったプロセスで開発するので、リリース時にはこの「Doneの定義」を満たしていれば（もちろんその他の要素もあるので一概には言えないが）現場はリリース可と判断できるのである。

※スクラムガイド　スクラムの定義、理論が記載されているKen Schwaber & Jeff Sutherlandによる⽂書で、スクラムの考え方の原典とされる。直近の改訂が2020年版。

「当たり前品質」を考える上で大切なこと１.「開発者の継続的なスキルアップ」

ここまでの仕組みをふまえても、プロセス設計だけで品質目標の達成に十分かどうかという疑問は日々感じている。
プロダクトを今後育てていく上で良い設計になっているのか、作り込みすぎていないか、本当に試験は十分なのか、といったところは開発者のスキルにどうしても依存していると感じてしまう。
これについては、有識者の参画やサポートなど、メンバーのスキル継承を考慮した体制・仕組みに加えて、開発者自身による継続的なスキルアップが、やはり最後は重要になる。

「当たり前品質」を考える上で大切なこと２.「自動化」

Doneの定義を満たすために、テストを繰り返し実施したり、コードやチケットを分析したり、継続的にビルド／デプロイを行うが、当然手作業では時間がかかりすぎる。解決は自動化しかない。もちろん、コストがかかる、これも面倒だが、早期から自動化を小さく積み上げることが重要になる。

これらが「当たり前品質」を現場で確保するための入り口である。そして、ユーザーにプロダクトを選択してもらうには、ここまでの「当たり前品質」に加えて、これからお話する「魅力的品質」が非常に重要である。

アジャイルにおける「魅力的品質」へのアプローチ

「魅力的品質」は、これまで開発者があまりユーザーと関わってこなかったため、苦手としているところでもある。
ここでも最初期の段階での認識合わせが大切になる。「開発側」もインセプションデッキなどで方針を話し合うので、「ビジネス側」の考えるユーザーの課題や、それを解決できるアイデアの「仮説」はわかるようになる。しかし、この段階ではあくまで「仮説」でしかなく、これだけでは十分ではない。

1アイデア検証と開発を連動させる

プロダクトが魅力的かどうかは最終的にユーザーが判断するものであり、ユーザーに繰り返し提供し、フィードバックをもらい続けるという、まさにアジャイル開発のアプローチが大切になる。
ただし、開発にも相応のコストがかかるので、見込みを立ててバッグログを整理していかないとムダなものを作るリスクが高くなる。
対策として、開発に入る前に行う「事前調査」、開発に入ってからの「都度調査（フィードバック）」によって、開発候補のアイデアに価値があることを検証しておくことが、アジャイル開発では有効なアプローチになる。

「魅力的品質」に対するアプローチ、アイデア検証と開発連動の解説

2デザインシンキングの採用

ユーザー中心の問題探索と検証には、デザインシンキングを採り入れる。ユーザーの立場で問題を定義し、解決方法のアイデアを出し、プロトタイプでテストし、ソリューションが実際にユーザーの望むことにフィットしているのかどうかを確認してから、開発に入る。

「魅力的品質」に対するデザインシンキングのアプローチの解説

NTTコムウェアではデザインシンキングはお客さまと直に接して要件定義をしてきたSEが得意とするので、彼らのノウハウを私たちのような開発者に提供してもらい、活用している。
これによって実際にMVP（Minimum Viable Product）を精査することができ、開発中に得た情報から最小限のプロダクトに立ち戻って見直すことで、アイデア創出や優先順位の判断につながるケースが出ている。
開発したMVPの魅力的品質に関する評価は、先ほども活用した国際規格の「SQuaRE」の「利用時の品質」を参考にし、客観的評価と主観的評価で得ている。

「魅力的品質」の評価とSQuaREの「利用時の品質」について

アジャイル開発での「品質」へ、
現場が考えるべき２つのアプローチ

アジャイル開発で明確に定義されていない部分の「品質」についても、私たちは品質モデルや手法を参考に具体化し、実現する方法を考え、模索しながら実践している。
私たちは現場において「プロダクトの品質」≒「ユーザー視点の品質（顧客満足）」と考えている。それには「当たり前品質」と「魅力的品質」の両立が必要であり、これまで以上に、ビジネス側と開発側の連携が必要とされる。