開発の優先順位付け、難しいですよね。
ユーザの方からは日々多くの要望を頂きます。現時点でリストには500以上。
機能が足りなくて困っているケースもあれば、検討段階で「○○があれば使う」という導入判断になるケースもあります。
また、「以前要望した○○はまだですか」なんて言われることもあります。（やるとは言っていないのですが・・・）
もちろん要望以外に、そもそもboardとして実装したいと考えている機能もあります。
これらすべてを対応するのは無理ですし、それをやったら、機能てんこ盛りで、使い勝手の悪いシステムになってしまいます。
そのため優先順位を付けて取捨選択していく必要がありますが、これが色々な要素が絡んで難しい。
既存ユーザの方で機能が足りなくて困っている場合は、それによって満足度が落ちてしまうし、最悪boardから離れてしまうかもしれない。
検討中の方の場合は、それが理由でboardを使わないという判断になるかもしれない。
以前要望出したのに対応されないと不満が募るかもしれない。
でも要望ばかり対応していたら、boardとして搭載したい機能の開発ができない。
基本的に不安との葛藤な気がしますが、そんな中でどうやって整理していっているかを紹介したいと思います。
要望は全てTrelloで管理
要望は全てTrelloで管理しています。要望の数が多いので、Trello上で細かく分類します。
開発前のものを以下のように分類して、右側に行くほど対応が近い・優先度が高いものになります。
アイデアの種→アイデア（低）→アイデア（高）→要件検討中→開発準備OK→次開発予定
新規の要望をもらうと、このうちのどれかに入れます。
また、既存の要望の場合は、そのタイミングで、その位置で良いのか、優先度を上げるかを都度判断していきます。
boardでは問い合わせ管理の仕組みとしてintercomを使用しています。
intercomでは問い合わせごとにスレッドになっていて、それぞれURLがあるので、Trelloにintercomの該当の問い合わせのURLも一緒に記入し、後からそのやり取りを確認できるようにしています。
基本的な方針
まず大前提の方針として、「ターゲットがぶれないようにする」というのを気をつけています。
boardの場合、
・業種は幅広いですが、ビジネスモデルとして受託型に最適化
・中小規模の会社がターゲットで、数人〜数十人規模がメイン
としています。
規模が大きいところまで広げていけば単価は上がりますし、より多くのビジネスモデルをサポートしていけば、より多くの会社に使ってもらえるかもしれません。
ただ、これがぶれてしまうと、誰にとっても中途半端な使い勝手になってしまうので、この方針をぶらさないようにしています。
優先順位付けで気をつけていること
現在は以下のようなルールでやっています。
自分がプロダクトオーナーとして一貫して意思決定をする
サービスのコンセプトがぶれないように、意思決定の一貫性は非常に大事だと思っています。当然社内でも使っているので、他のメンバーから意見をもらったり議論することはありますが、最終的には、自分が全体のバランス・一貫性を踏まえて決定するようにしています。
知り合いや有名な会社の要望に流されない
知り合いや有名な会社からの要望は、どうしても影響を受けがちです。しかし、必ずしもそれが正しいとは限らないですので、優先順位の判断で影響を受けないように、要望を管理しているTrello上では会社名はわからないようにしています。
ロードマップを半年ごとにし、その枠に収まるものを取捨選択する
ロードマップは公開する以上、ある程度は守らないといけないので、無理に詰め込むようなことはしません。そのため、ロードマップを決める過程はわりと保守的になるので、この段階で、無駄が削ぎ落とされます。
既存機能の改善、要望対応、新機能追加をバランスよく対応する
既存機能で不足している点や使いにくい点の改善、要望の対応、全く新しい機能の追加をバランスよく対応するようにしています。
既存機能の改善や要望対応は、既存のユーザ満足度の向上に繋がり、継続して利用して頂くという点でプラスになると思っています。
全く新しい機能の追加は、既存ユーザさんだけでなく、これまで機能が足りずに利用を控えていた見込みユーザが使ってくれるきっかけになるかもしれません。
そのため、どれかに偏るのではなく、バランスよく対応していくようにしています。
整理のための質問
以下のようなものを自問自答します。
・この機能は本当に必要か
・どのくらいの人が使うか
・業務上不可欠なものか、それともあったら便利か
・単なる習慣による要望で、実はなくても問題ないものではないか
全てに当てはまらないと対応しないというわけではありませんが、特に要望が多くて対応しようと思ったものに対して、「あれ、これ実はあまり必要ないんじゃない？」と気づくきっかけになります。
要望の多さと優先順位
要望の多さはニーズの多さでもあるので、ある程度優先順位には反映させるようにしています。ただしboardの思想・方向性的にずれているものは、どれだけ要望が多くても対応しないようにしています。
何度か、サービスをやっている人から「要望の多さと優先順位を連動させるのは違うんじゃない？」と言われたことがあるのですが、業務システムの場合、取引先との関係で、業務上避けられないものなども多数存在します。
使い勝手やUIなど、主観が多分に入っている要望は別ですが、業務的なニーズの場合は、要望の多さは重要な判断材料のひとつにしています。
ロードマップに沿う
・「○○ができないなんて考えられない」「○○は至急対応してほしい」といった大きい声や、「○○があれば使う」といった声に流されないようにするため、原則、半年単位で公開しているロードマップにないものは次のスパン以降での検討にするようにしています。
ちなみに、ロードマップになくても、元々「要望があれば対応しよう」と考えていたものは、要望があればすぐに対応したりもしてます。
こういったルールを決めてからは、だいぶ流されなくなりました。
一応誤解のないように言っておくと、ユーザさんの声には耳を傾けるべきですので、頂いた要望はすべてTrelloで管理し、1〜2ヶ月に1回はすべて見返しています。
ただ、短期的なスパンでは影響されないようにすることは大事かなと思っています。
最初の1年目はぜんぜん違うスタンスだった
現在は、ある程度機能も揃ってきていて、以前に比べたら、「○○がないと・・・」というものはかなり減りました。そういった背景もあり、上記のようなルールで運用しています。
しかし1年目は全く違うスタンスでした。
要望の数自体も少なかったので、要望が多いものはどんどんと対応していました。
ただ、その中で大事にしていたのは、「自分自身がその機能を欲しいか」という点です。
これは、そもそも自分のために作り始めたという背景があったり、自分自身もターゲットユーザだったりしたので、その感覚を大事にしていました。自社サービスの経験がなかったので、これを拠り所にしていた感じです。
また、基本的な方針として、「派手な新機能よりも、基本的に既存機能の完成度の向上と、コア機能に関連する業務的に不足しているものの対応」というものがありました。
これは、うちが知名度の低い無名のベンチャーだったことがかなり影響しています。
無名の会社・サービスにとって、「知ってもらうこと」「お試ししてもらうこと」のハードルはものすごく高いです。
1週間で何日も新規お試し登録が0件の日がありました。
そんな状況の中で、お試ししてくれた方を逃がす余裕なんてないんですよね。
なので、お試ししてくれた方に出来る限りそのまま有料へ転換して欲しい。そのためには、とにかく今ある機能の完成度を高めておくこと、まずはターゲットにしている業界・会社規模を絞って、そこでの業務がしっかりカバーできていること、そこを目指しました。
たぶん、それが功を奏して、「要望の対応が速い」と言ってboardを推してくれたり、「受託の会社にとってはものすごくフィットする」といって紹介してくれたり。
boardは当時から今でも、口コミに支えられているのですが、その土台は、最初の1年目のそういったスタンスによる取り組みの効果が大きかったのではないかなという気がしています。
ちなみにこのスタンスの弊害は、リリース内容が非常に地味です。何度「もう少し記事に取り上げられるようなリリースないんですか」と言われたことか・・・。
でも、記事に取り上げて頂くようなリリースをするよりも、目の前のユーザさんをターゲットに開発することを選びました。
＊そういった中でがっつり記事を書いてくれたASCIIさんにはほんと感謝しかありません。
1年目のスタンスから今の運用ルールに至った経緯
1年目のそういったスタンスから、前述の現在のルールに至った経緯は、最低限の基本的な部分はカバーできたことが大きいですが、自分自身が慣れてきたという点もあります。
ずっと受託をやってきた人間からすると、多くの顔を合わせたことのない方々から様々な要望が来て、時には「これがないなんてありえない」と言われる経験ってあまりに不慣れで、だいぶ動揺しますよね・・・。
開発ロードマップの公開はかなり初期の頃からやっていましたが、この頃から、「半年単位」という今のスタンスができました。
ちなみに、今でも、「自分自身がその機能を欲しいか」という視点は大事にしています。
さすがに最近は、自社で業務的に必要がない機能も出てきているので、そういうケースは、「その機能に納得感があるか」という視点で見るようにしています。自分が納得しない機能は要望が多くても対応しないようにしています。
実装とのバランス
最近ようやくもう一人開発に入っていますが、それまでの約2年半は、受託の合間にちょっと手伝ってもらう以外は、ほぼ自分一人で開発してきました。
プロダクトオーナーと開発者が同じなので、実装レベルまで完全に頭に入った中で優先順位を考えます。
そのため、機能の対応順番を考える時に、単純な機能の優先順位だけでなく、コードのレベルで考えて、効率が良い、バグを生みにくい順番を考えています。
受託をやっていて、「あー、この仕様、前回の開発の時に一緒に言っててくれれば・・・」なんてことあったりしますよね。
できるだけお客さんと話をしてそういったことを減らせるように取り組んでいますが、今後の予定や構想が全部こちらに伝わっているわけではないので、なかなか難しいんですよね。
あとは、要望は少なくても、「これあるといいな。しかも簡単にできるし」みたいなものは空き時間にさくっとやったり。で、それが意外と好評だったり。
こういったことができるのは、エンジニアがプロダクトオーナーであるケースの強みなのかなと思います。
まとめ
最終的には、ユーザの声は聞きつつも、声に流されないようにする、という点が非常に大事なのかなと思っています。
気持ちの面で戦わないといけない部分もありますが、ロードマップの公開のような仕組みによって、短期的には影響を受けにくくするのも、安定した開発・運営には大事な気がします。
