機能を削る説明の方法
しかし、情報量の多いものに慣れた人に直接的に説明したときに伝わらない場合がある
そういうときの工夫
A案は機能や表示するものが多いもの
B案はシンプルなもの
という2つがあるときにどう説明するか?
正論をぶつける
認知コストが下がる
実装コストが下がる
機能が減る
バグが減る
「これができないじゃん」と言われたら「ここをこうしたら解決できます」と跳ね返す
意見を受け入れつつ跳ね返す
A案とB案の工数を見せて比較させる
A案を実装しようとするとお金と時間がかかりますね...と説明する
ちょいテクとしては、A案の工数をちょっと盛れば良い
正論をぶつけるのではなく、相手の意見も考慮している感じを出す
面倒なのはやまやまだが、相手によっては後者のほうが上手くいくのだろうと思うmrsekut.icon
機能を減らすための分析
https://gyazo.com/b71af5e4684f9efc9cd5aec1229d8804 https://levtech.jp/media/article/interview/detail_370/
利用者数とプロダクトの方向性とのマッチ度で分類している
確かに、既に実装されている機能に対し、感覚的に「これ不要では」と思うものも、不要さの根拠を示す必要があるmrsekut.icon
そうでないと、「いや残してたほうがいいでしょ」の主張と立場とほぼ同じになる
根拠が感覚に基づいている
使われいてるか、方向性的に必要なのか、また他の指標から分析した上で、
消しちゃおう、もっと良い解決策の提案、等々をやっていくべき
図でいうと、①<②=③<④の順で検討が難しくなる印象がある
①は自明なので、決定さえできれば誰でも消せる
④は既存のものを常に批判的に見る必要がある
もっと良い方法あるよね、と
https://gyazo.com/f5b13ed4aca96ce845eb6cc71e5d1c3e
利用するユーザの割合と、利用する頻度でマトリックスにする
Core(赤)のやつだけいれる
Coreが多くなりすぎる場合、コンセプトが曖昧であるというヒントになる
コンセプトの練り直しが必要
to Bシステムが前提にありそうだが
汎用性があるか?
事業に大きな価値をもたらすか?