狩野モデルを使ったSaaS開発現場でのタスク管理とふりかえり。

こんにちは！
コロナのせいでますます引きこもりが加速している9課代表のabengerです。

自宅ではデスク、チェスト（スタンディングデスク代わり）、ベッドをMacbook片手に行ったり来たりしてるのですが、ベッドでの作業効率化に膝デスクを買ったところ、思いのほか良かったのでオススメ😎

膝デスクと言えばYogibo（ヨギボー）がCMやってましたが、個人的には↑の安物のクッションのほうが硬さがあって流れにくく使いやすかったです。ご参考まで。

さて、今回はこれまで9課の技術面や運用面についてあまり書いてなかったので、少しそのあたりの振り返りを書きたいと思います。

そもそも狩野モデルってなんぞや？

本記事のタイトルにもある狩野モデルですが、そもそもどんなものなのか？

ざっくり書くと、狩野モデルは主にプロダクトの品質管理やUXといったワードと一緒に登場することが多く、よりユーザ目線で満足度の高いサービス開発（やマーケティング等）を行うために用いられる優先度付けのモデルです。

狩野モデルでは、対象となる機能やサービスについて下図のような形で「充足・非充足」の質問を行い、その結果を６分類（実質５）へとマッピングします。

超適当ですが…例えば『ユーザが投票できる機能』が、有ると「ちょっと使いたくなる」けれど、無かったからといって「不満に感じることもない」ものだとすると、それは上のマップでいうE：魅力的（差別化要素）に属します、という感じ。

なお、狩野モデルの分類名については複数の異なる呼び方があるようで、9課では以下の分類名で管理しています。

ただ、実際に使用されるのは上から３つの分類のみであり、下２つを使うことは基本ありません。
（そこへ分類される機能の開発を検討することがない）

また、上記要素をグラフで表すと下図のような形になります。

右上エリアは顧客が満足しており、利用継続される可能性の高い状態です。

そのため、理想は右上エリアに該当する要素の拡充ですが、実際のところ最も優先度が高いのは、不満（＝解約理由）と直結した「当たり前要素」への対応となるでしょう。

ここを放置して、他サービスとの差別化を狙った魅力的な機能拡充ばかりを優先していても、結局既存ユーザの不満は溜まり、チャーン（解約率）が高まるというSaaSにおいてNGな結果となってしまいます。

このような感じで、これから開発・提供を検討している機能やサービスが、自分たちの顧客（ユーザ）にとってどういった位置付けのものなのか？を理解＆定義し、より正しい優先順位で進めるためのもの…それが狩野モデルと理解しています。

なぜ狩野モデルをサービス開発に採用しているか？

要素が直感的で分かりやすい

優先度付けのフレームワークは狩野モデル以外にも様々あります。

よく聞くのは重要度ｘ緊急度のマトリクスや意思決定マトリクス、トレードオフ・スライダーなどですが、各チームそれぞれにあった手法でスコアリングしたり、付箋管理したり色々工夫しているかと思います。

例：重要度ｘ緊急度のマトリクス

以前は重要度ｘ緊急度マトリクスを使ったりもしていましたが、狩野モデルのほうが直感的かつユーザ目線で分類しやすそうということで採用に至りました。

9課のアジャイル風開発とマッチしてるっぽい

１．ユーザからの要望をガシガシチケット化

9課ではタスク管理ツールにClickupを使っており、そこへユーザからの要望やメンバーの気づきから発生した開発チケットをガシガシ投げ込んでいます。

このとき、緊急系でないものはまず最初に「割り振り前チケット」として放り込まれます(ノ・ω・)ノ

２．狩野モデルによる要素タグを付与

次に、上に出てきた分類要素（魅力的要素、一元的要素…等）を各チケットに割り振っていきます。

この際、チケット作成者のほうで要素タグを付与するわけですが、狩野モデルは「その機能が有るとユーザはどう感じるか？また、無いとどう感じるか？」という点でマッピングするので、重要度や緊急性の判断よりも曖昧になりづらく、且つ開発目線ではなくユーザの満足度として想像しやすい気がします。

そういった意味でもVoC（顧客の声）やユーザファースト姿勢を重要視する弊社には合っているのかもしれません。

３．次四半期の開発チケットとしてタグから優先度決め

あとは上で付与した要素タグで優先順位を確認しつつ、四半期ごとに開発チケットの棚卸しを行う形で進めています。

ただ、9課では比較的小さな機能単位で設計→開発→テスト→リリースを進めていくので、毎月チケットの横入りや優先度変更が多々あり、大した棚卸しにはなってませんが。。

月次振り返りで理想のパーセンテージを目指す

Clickup x esa x 狩野モデルで前月の動きを振り返り

さて、このような感じで狩野モデルによる開発チケットの分類を行いましたら、月次ふりかえり時にもそれを活かして確認します。

9課ではドキュメント管理に esa 🐥を使っているのですが、これが Clickup との合わせ技でいい感じ☺️

１．Clickupで前月完了したチケット一覧をコピー

前月のクローズチケットを各要素タグ（狩野モデル）ごとに絞り込み、結果一覧をコピー。

２．esa にてMarkdown（テーブル）形式でペースト

esaにそのまま貼り付けるとMarkdown形式にするか聞かれるのでOKするだけ。

上は未整形のサンプルなのであれですが、要はさくっと要素別で前月完了したチケットをまとめて記述できるので便利なんです。

それぞれの要素ごとに前月完了したチケット一覧を貼り付けて、最後に要素別パーセンテージを出したら完成。

お恥ずかしい限りですが、例えば上の月なんかは当たり前のことで手一杯であり、攻めの開発が行われていないことが丸わかりです😇
（各所に影響する不具合が見つかったことが大きな原因…）

前に進むための開発ができているか？が見える化してきた。

狩野モデルを取り入れた類別＆ふりかえりを始めて良かったのは、常時MAX頑張ってゴリゴリ開発を進めてるけれど、それって本当に顧客満足度の向上に繋がる開発だった？という点が見える化したことだと思います。

「前月も色々開発して頑張ってたよね！」が、
実は「色々やってたけど、殆ど既存問題の改修や必須対応に追われてた」だった…という悲しい事実もよりハッキリ見えてくるため、なんとなく頑張った感を無くす振り返りができて満足しています。

なお、チームで月に1,2個の機能をリリース…などであれば、特に上のような心配は不要かもしれません。
うちの場合は各自が月に2,3個の機能をリリースしていくスタイルのため、どこかで精査しないとスピード感だけは凄い感じる…！みたいなことになっちゃうのです。

理想（目標）のパーセンテージを決めておく

とはいえ、要素タグを付けて結果を見守るだけでは意味がないので、要素別の目標パーセンテージも決めておきます。

まだ実験中なのでこの割合が相応しいかは分かりませんが、ここを決めておくことでチケットの優先度を考える際の指標にもなり、全体がより繋がるかと思っています。

なお、各チケットや要素毎に工数がどれだけで、費用対効果が如何ほどで〜とさらに細かく分析・管理していってもよいのですが、今のところはあまり厳密にせず、モチベーションが上がる程度の管理にしている感じです。

一番大切なのは、ユーザ要求への正確な判断

最後に、当たり前ではありますが上の話はあくまでテクニックであり、そもそもユーザの欲求を正確に把握することこそが最も重要だと思っています。
結局、狩野モデルにしても最初の分類がズレていたら、あんまり意味がありませんしね😅

なお、狩野モデルの場合は、アンケートを取る形でユーザ自身にマッピング協力をいただくことも多いようですが、忘れてはいけないのが「ユーザは今この瞬間の問題を解消したがる」という点です。

「○○がしたい！だからこの機能が必要！」と多くのユーザは求めますが、案外それらの多くは代替手段の提案で充分に満足できたり、また数カ月後の未来には不要になっていたりするもの。

だからこそ、あまりアンケート結果などは鵜呑みにしすぎず、ユーザの本来のゴールに向き合うことが重要だと個人的には考えています。

9課では代表である私も含め、社員メンバー全員で直接CS対応を行い、日々ユーザの声を聞いて深堀りすることで本当に必要な機能を優先的に開発するよう心がけていますが、またそれはいつかの機会にまとめられればと思います。

　

以上、このような感じで9課では１年ほど前から狩野モデルを取り入れたチケット管理＆振り返りをやってみてるよ！というお話でした。

それではさらだばー