品質特性と狩野モデルの話
株式会社アカツキでエンジニアをしています。あでぃです。 この記事はAkatsuki Advent Calendar 2018 - Adventarの20日目の記事です。 前回は @shairo_jp さんのUnityでAPK拡張ファイルを利用するときのあれこれ - Akatsuki Hackers Lab | 株式会社アカツキ（Akatsuki Inc.)でした。
今日のテーマ
今日は品質についての一考察です。 アカツキではほとんどのチームが、開発時間を一定のタイムボックスに区切って開発項目を決定し実装/リリースしていく、というイテレーション開発のスタイルを採用しています。イテレーション開発では大きな開発項目(便宜的にバックログ(アイテム)と呼びます)を小さな単位に分割して開発を進めていきます。 一方、プロダクトには「品質」という概念があります。それはバグの量や頻度以外にも手触り感とかおもしろさみたいなのも含む場合があり、良いプロダクトを作るには欠かせない観点です。これは開発と切っても切れない関係にありますが、視点が非常に多く、人によってポリシーが異なってしまう部分でもあります。 この2点をうまく制御して、継続的に価値を出していくためには結論として「バックログにより魅力的な開発項目を積む」必要があると考えています。今回は「現場ですぐに使える！魅力品質のつくり込み方～狩野モデルを用いた新しい手法～ 」という研修に参加したので、そこから感じたことを書きたいと思います。
品質の定義
品質の意味を定義しておきます。今回の記事では「品質の高さ = 要求と仕様のギャップの小ささ」と表現します。高品質であれば要求通りの製品、低品質であれば要求をあまり満たせていない製品ということにします。 市場の要求は常に変わり続けるものであって、差を縮める製品やサービスをつくったとしてもギャップが生まれ続けます。そちらは開発プロセスの話(今回は触れません)で回収していくこととして、まずは市場の要求を品質として正しく定義する必要があるよね。という話をします。
狩野モデルについて
狩野モデル、というものが存在します。これは東京理科大学名誉教授の狩野紀昭氏の提唱したもので、顧客の求める品質をモデル化したものです。興味のある方は「魅力的品質と当り前品質」という論文を御覧ください。
品質というものを「魅力品質」「一元的品質」「当たり前品質」に分類しています。
魅力品質
なくても仕方がないかな、と思うことはできるがあれば満足。あればあるほど満足度は上がるが、全部なくても不満ではない。といった項目です。
あたり前品質
これはないと不満、あってあたり前だと考えられるもの。なければないほど満足度は下がるが、全部あってもそれだけで満足はならない。といった項目です。
一元的品質
あればあるほど満足度は上がり、なければないほど満足度は下がるという項目です。 これらを中心に、マトリクスで表現すると以下のようになります。
| 充足 \ 不充足 | 気に入る | 当然 | なんとも感じない | 仕方がない | 気に入らない |
|---|---|---|---|---|---|
| 気に入る | 懐疑的評価 | 魅力的評価 | 魅力的評価 | 魅力的評価 | 一元的評価 |
| 当然 | 逆評価 | 無関心評価 | 無関心評価 | 無関心評価 | 当たり前評価 |
| なんとも感じない | 逆評価 | 無関心評価 | 無関心評価 | 無関心評価 | 当たり前評価 |
| しかたがない | 逆評価 | 無関心評価 | 無関心評価 | 無関心評価 | 当たり前評価 |
| 気に入らない | 逆評価 | 逆評価 | 逆評価 | 逆評価 | 懐疑的評価 |
充足質問 : この機能が備わっていたらどう思うか？ 不充足質問 : この機能が備わっていなかったらどう思うか？ になります。 このモデルを使うときには「誰が満足するのか」をしっかりと考える必要があります。例えば「BtoBtoC」であればエンドユーザーが満足なのか、エンドユーザーにサービスを提供する人が満足なのか、です。僕の作っているゲームであればもうちょっと考えやすいかも知れないです。 しかしながら、実際に運営しているプロダクトではユーザー様に満足いただく以外にも運営メンバーが満足することなども存在します。人と議論するときにはこの観点を明らかにしておくことが重要だと思います。
これを元になにをするか？
実際にチームでやることととしては、バックログのアイテムを上記マトリックスに当てはめながら議論をし、本当に必要なものを見極めていきます。
なにをやめるか、をきめる
何をするかという話は非常に重要であるという前提の元「何をやらないかを決める」というのも同じように非常に重要です。 「利用状況を想定した要求事項」をちゃんと定義しないと、どうしても作りやすいものに流れてしまうと思います。人間なので仕方がないです。また解決すべき状況はその状況に置かれた人自身も実ははっきりわかっていないことも多く、この「利用状況を想定した要求事項」をいかに精度高く定めるかという話になるのですが、その際に要不要の議論はしっかりとする必要があると思います。その際の指標に用います。 さらに、これは一度議論したら終わりではなくひたすら検証/FBするしかなくて、そのサイクルの精度をあげていくためにより正解に近いあたりをつけるような手段としてもこれを利用できそうです(スピードは開発プロセスの話ですね)
本質は速度ではない
早く出すのは非常に重要である上で、品質の高いものをつくることも同様に重要です。良いものを早く、が最高であると定めるなら「やるべきことは端折らずにやる」ということを心に刻んでいたいなと思いました。例えば品質やその検証方法を定めることです。「とりあえずやってみる」というのがとても大事だと思っているので、そのためにやるべきことはしっかり定めて「とりあえずやるべきことへ動き出してみる」という気持ちを持てるようにやるべきことはしっかり定めていきたいです。
まとめ
何をつくるか、というのは非常に大切なことです。「「どう作るのか」より「なぜ作るのか」」とはよく言ったものです。品質についても魅力的品質、あたり前品質、どっちをどうやればいいとかじゃなくて、これはなんのために/誰のために作っているのか。がしっかりしていないと良いものになる確率は下がってしまうのではないかと思います。スクラムだとそういった市場価値などを定義するのはPOの役割とはいえPOも人間でスーパーマンではないので、そのへんはみんなで考えていけるチームをこれからも作っていきたいなと思いました。
参考
以下の研修に参加して学んだこと/考えたことを書きました。 参加した研修「現場ですぐに使える！魅力品質のつくり込み方～狩野モデルを用いた新しい手法～ 」
明日は @kackyt さんです。