この記事はヤプリ #1 Advent Calendar 2022 - Adventarの18日目として投稿させていただきます。
こんにちは、開発ディレクターの小野田です！ もう2022年も終わりですね。年末ということで、今年買ってよかったものはなんだったかな〜と振り返ってみたのですが、第一位は削りかすが出ない爪やすり「魔法のつめけずり」です。 matsumoto-kanagata.net
そんなことはさておき、今回はヤプリの顧客や社内の要望を叶える仕組み「ideabox」についての取り組みと、運営する上で感じた課題、2022年に行った２つの改善（リリースした時の社内への通知・投稿のフォーマット変更）をご紹介しようと思います。
ideaboxとは
その名の通り、プロダクトへの改善アイデアを全社員が投稿できる仕組みです。ここの機能のここがちょっと使いづらい、Yappliでこんなことができたらもっと売れそうと商談で思いついた、お客さまとのミーティングでこんな課題を見つけたので改善してほしい！など日々多くのアイデアが投稿されています。
ちなみにプロダクトの不具合や仕様確認、クライアントが紐づいた要件がある場合については別の窓口が用意されています。ビジネスサイドからプロダクト開発本部への問い合わせパスとしては他に「Yappedia」「開発相談」が設けられており、それらとは以下のように区別されています。
このように、ideaboxは「クライアントさんが紐づいているわけではないが、これが実現できたらきっとみんな嬉しいんじゃない！？」といったようなアイデアが多く集まる場所になっています。 というわけで、非常に多くの改善要望が日々投稿されており、2022年はなんと約250件ものアイデアが投稿されました。
ideabox投稿後のフロー
ideabox投稿後、開発ディレクターチームで投稿内容を確認し、ざっくり以下のように振り分けていきます。
着手するべきかつ、小規模な開発で実現できるもの
着手するべきだが、大規模な開発になりそうなもの
着手するべきでないもの
①着手するべきかつ、小規模な開発で実現できるもの
プラットフォームに取り入れるにあたり汎用性があり多くのクライアントに価値がある、かつ実装のコストがそこまでかからないアイデアがこれに分類されます。もちろん投稿されたアイデア（解決策）の実装工数が重そうであれば、課題を見極めてより少ない実装工数で済むような解決策を提案することもあります。ここは開発ディレクターの腕の見せ所ですね。
①に分類された場合、エンジニアが着手できる状態になるよう開発ディレクターで詳細な仕様を検討する必要があるものは開発ディレクター着手待ち案件としてプールしておきます。特に課題がない場合はそのままエンジニア実装着手待ち案件としてこれもプールしておきます。これらは月に２回のYappdateDayで仕様策定または実装されていきます。
現在進行しているプロジェクトのチームで実装できそうな場合は、そのチームに直接お願いすることもあります。
YappdateDayについてはこちら times.yappli.co.jp
ヤプリの開発体制についてはこちら tech.yappli.io
②着手するべきだが、大規模な開発になりそうなもの
①と同様多くのクライアントに価値をもたらしそうなものの、実現させるとしたら複数のエンジニアでプロジェクトチームを組んで対応しないといけないようなアイデアはこちらに分類されます。これらは開発バックログとしてプールされ、経営会議やヤプリクなどで採択される瞬間を待ちます。
ヤプリクについてはこちら note.com
③着手するべきでないもの
課題が限定的であまり汎用的でないアイデアや、例えばクライアントのチャーン・アプリのリジェクト・インシデントなどの原因になる可能性が否定できない、マイナスの影響がありそうなものなどが分類されます。
といってもこの③に分類するのは全体の10%以下程度で、ほとんどのアイデアがやる意義のある、内容の濃いアイデアばかりです。（いつも投稿いただいている社員のみなさま、本当にありがとうございます！）
蛇足ですが、ヤプリは年間200件以上と非常に多くのプロダクトアップデートを行っているので、アイデア投稿いただいても「もうそれできますよ！」と返す場合もありますw
ideabox運営に関して実施した改善策
ideabox自体は数年前から存在していたのですが、1年ほど前から私がideaboxのオーナーとなり現在も運営を行っています。 その中で次の２つの改善を行ったため紹介しようと思います。
①ideabox案件がリリースした際にSlack通知するようにした
ヤプリの社員は#yappli-ideabox というSlackチャンネルでワークフローからideaboxを投稿することができます。
以前はアイデアがリリースされていても特にこのチャンネルで触れられることはなく、別の場所でリリースノートとしてまとめられている程度でした。投稿した社員本人はさすがに気づくケースが多いかとは思いますが全体へのアピールとしては控えめでした。「ideabox起因でこんなにリリースされていますよ！」といったアピールがもっとされてもいいのでは！？と考え、#yappli-ideabox にリリースした時の通知botを走らせるようにしました。
botはJIRA AutomationとZapierを組み合わせて構築しています。
リリースされるとこんな感じで投稿者をはじめとしてポジティブな絵文字で反応している社員が多く、ideaboxのイメージ向上に寄与できているのではないかと思っています。実際に、最近実施した社内アンケートでも「通知が来るようになって素晴らしいと思います」といった声をいただくことができました。
②「解決策」ではなく「課題」にフォーカスするように投稿フォーマットを変更した
「顧客からのフィードバックリストに解決策や機能を書くな、課題を書け」というのはプロダクトマネジメントを語る上でよく言われていることかと思います。
参考： note.com
以前は「プロダクトへの改善要望アイデアを投稿してください」といったコミュニケーションで、例えば解決策や課題などのどちらかにフォーカスするような誘導はしていませんでしたが、ここ最近では課題にフォーカスするようにフォーマットを修正しました。
修正後のフォーマットの一部がこちらです。
個人的なこだわりポイントは以下です。
- 「概要」と「詳細」を分けることで、あえて短く端的に言うなら？を記載いただくようにしている
- 考えられる解決策は任意とし、開発サイドに一任する形をOKとしている
こちらも運用を初めて2ヶ月ほど経ちますが、解決策はそこそこに、課題をしっかり記載いただいているパターンがかなり多くなってきた印象です。
ちなみに以前のフォーマットだと、解決策にフォーカスされがちで、なぜやりたいのか・顧客は何をしたくてこの要望をあげているのかが不明瞭な投稿が多い傾向にありました。そのためチームでideaboxを確認するときに、読み解くのに時間がかかったり、再度ヒアリングする必要があったりと、多くの手間がかかっている状態でした。 思い返すといわゆるアンチパターンだったのかもしれないですが、その苦労を知ったからこそ今後は同じような場面で失敗しない気もしています！
最後に
ヤプリの顧客や社内の要望を叶える仕組み「ideabox」についてご紹介しました！
ヤプリでは他にもさまざまな業務改善を行い、より多くの価値を素早く届けられるよう試行錯誤しています。 ヤプリに少しでも興味がある方、カジュアル面談で話を聞いてみませんか？ open.talentio.com
