「アジャイルな見積もりと計画づくり」で紹介されていた「狩野モデル」。
要求（プロダクトバックログ）を分類する方法です。
今回は後輩社員と一緒に架空のサービスの要求をいくつかだし、それを狩野モデルを用いて分類してみました。
狩野モデルとは
要求を分析・分類するための方法です。
[参考]https://sites.google.com/site/techdmba/kanomodel
要求に対し「充足質問」と「不充足質問」を行い、その回答によって分類します。
質問の回答は以下から選びます。
- 充足質問「この機能があるとどう思いますか？」
- 不充足質問「この機能が無いとどう思いますか？」
E ・・・魅力的。競合との差別化に有効な機能。隠れたニーズとも呼ばれ、体験するまで気が付かない場合がある。
M ・・・必須。あって当然の機能。
L ・・・線形。あればあるほど満足度があがるような機能。コストとのバランスを考慮する必要がある。
I ・・・無関心。あってもなくても気にならない程度の機能。優先度が低い。
R ・・・逆効果。あると困る機能。
Q ・・・懐疑的回答。回答が不整合。
プロダクトバックログ
イメージしやすいように、簡単なサービスとしました。
イベントの管理サービスを作ることを想定。
（DoorkeeperとかATNDみたいなもの）
以下のバックログを分類していきます。
やってみた結果
ほぼMになってしまいました。
ちょっと必須の機能ばっかりでしたね…。
もっと色んな機能を含めておけばわかりやすかったかもしれません。
気づき
意見を出し合うことが大事
人によって認識が違います。なるほどなー、という意見もありました。
この分析・分類は本来多くの人にインタビューやアンケートをして回答を得るようです。
（もちろん回答にバラつきがあるので重みづけを行い、判断材料とします）
顧客視点を失ってないか
話し合いの中で、明らかに「開発者視点」で語っている場合がありました。
「イベントの修正機能はいるかどうか」という話の中で、管理者が間違えなければ必要ないんじゃない？という意見でした。
利用シーンなどコンテキストによりますが、ユーザに責任を押し付けるような視点になっていると感じました。
我々のようなSIをやっている開発者はともするとこのような視点になりがちです。
「このシステムは使う価値があるかどうか。自分たちだったら使いたいと思うかどうか」は常に気にかけないとダメですね。
プログラムのお勉強として実際に作ってみる
このメンバーでプログラムの勉強として、このプロダクトを実際に作ってみることにしました。
エンジニアとはいえプログラム経験が非常に少ない後輩たち。はたして完成する日はくるのでしょうか。
楽しみです。
