改善vs新機能追加。プライオリティを判断する実践的な尺度がほしい。

「改善vs新機能追加」というのは悩ましい問題です。F's Garageさんが先日のmixiのニュース表示機能追加をネタにこんなことをおっしゃっています。

mixiのニュース機能追加に対する評価はいろいろ。ネガティブな方の評価だと、デザインやブラウザサイズに対する抵抗もあるが、印象的だったのは、要するに
「細かい仕様改善もせずに機能追加にリソースを割くとは何事だ」
ということではないでしょうか。

ほんとに。

困ったことにどんな場合でも次の式が成り立ってしまうものだと思います。

で。どこかで、改善を進めて既存顧客の満足度向上を図るか、新しいセールスポイントとなる機能を追加するか、の判断をしなくてはいけなくなるわけです。

上のF's Garageさんの記事でもこう書かれており、

自分たちで良い物を作って、できるだけ市場の評価と、製品品質が同期するような（つまり、工数をうまく両方に効果的に適用されるように）仕事をすることだけに邁進してく所存であります。
〜中略〜　一打席一打席を大事に積み上げて、イチローのような結果を出すこと。

ほんとそうだと思うのですが、なにが「効果的」なのかというところはやっぱり難しいです。

機能追加要望にどうやってプライオリティをつけるかについては、方針によってかわるもんなので、もちろん結論なんて出せないわけなんですけど、そんななかでもなんとか地道かつ魅力的な機能改善/追加をしていかないといけない。

で、「重要性」×「工数」で判断するのがわりと一般的なんじゃないかという気がします。実際に、会社でもよく使ってきました。

でもその場合の「重要性」っていったいなんですか？

わざわざ要望として出てくるからには全部それなりに重要ですよね。濃淡の差こそあれ。

ここを適当にしとくと、偉い人や営業さんの「これが重要」や開発さんの「これは工数がかかる」の狭間で身動きが取れなくなっていくので、とても嫌。

そんな「営業さんと開発さんの中心で○○を叫ぶ」問題に苦慮して最近会社でこんなものを提案しました。

使い方はこうです。

「〜できないと意味がない」基本的な機能
- 意地でも実装する。工数がかかってもやる。
- ないと利用の有無に直結するので、利用ユーザ数の多い機能からひたすら実装する。
- 利用頻度の大小は問題ではない。低頻度でも必須の機能はあるから。
「〜できればできただけいい」標準的な機能
- 空きリソース量の分だけコツコツ実装していく。
- これもユーザ数で判断。満足度の基礎となるはず。
- 「あんま意味は感じないけど競合が実装しているから仕方なく」みたいなのはここ。
「〜できると素晴らしい（なくても意識されない）」満足度アップ機能
- 年に1つ。半期に1つ。と決めて、最も魅力的っぽいものだけ実装する。
- 利用ユーザ数の少ないものは思い切って切り捨て。

だいたい「ユーザ数」×「狩野モデル」で判断。（「狩野モデル」については先日「魅力品質を語る前に、基本品質を見つめなおせ、と。」というエントリで紹介しました。）

ちなみに下敷きとした考え方は次のようなものです。

もちろんユーザー数の想定や、ユーザーの目的の設定を誤ったりすれば意味なくなってしまいますが、ざっくり「重要性」って言ってしまうよりは客観的な判断基準として使えるんじゃないかと思って、とりあえずこれで社内の開発フローを回してみたいと思ってます。

ユーザー数の想定や、ユーザーの目的の設定なんかは、市場調査というひとつ上のレベルの計画から落としてこれるものだと思うので、上流工程との接続もまぁ難しくはないはず。

あるユーザにとって「意味がない」機能でも、ほかのユーザにとっては「不可欠」である場合もあります。そのへんはユーザ数に応じて、ペルソナ作ったり、実際のサポートに入ってくる要望を元にしたりして、「ゴムのユーザ」にならないようにします。

まぁ、あれこれいってもセンスにはかないません。

だって結果が同じなら、調査や評価、基準設定に時間かけるより、「これがいいなー」で決めちゃったほうが100倍早い。

属人性をどこまで嫌うかですよね。あーセンス。ほしい。

みなさん、このへん、どうやって判断されてますでしょうか？　いい知恵あったらぜひ教えてください。