こんにちは。たまには実務的なネタもありかなと思っています。
仕事の方で、タイトル通りのサービスを企画-運用まで全部やってみて1年半くらいが経ちました。

結果的に、一部機能は残したまま畳んだも同然の状態まで規模を縮小することになりました。
いっときは良いものが作れた、これで会社がよくなると思っていたワクワク感が、もうメンテナンスする手間もかからないほどに廃れ、社外でも社内でも使われないものになってしまった。

そんな失敗談を残しておこうと思います。
※会社としての公式な見解ではなく、作った中の人から見た主観と偏見で語ります。

企画した背景

新卒で入社して、OJTにも慣れ、現場に馴染んできたような頃。
B2Bの自社サービスを作っている当時の会社を見てて感じたのは、 ユーザが何を求めているか把握できていない ということでした。
例えば新しい機能を作ったり、既存の機能を改修したりということに優先順位がついてない。
なにをしたらどれくらい変わるのか、見込めるのか、が全然見えてない。
何をするにも根拠や勝算がない。根拠にできる元がないから。

ユーザが意見や要望を送るフォーム自体は存在していたが、送ったものをきちんと追ってないし可視化もできていなかった。
他にも色んな所から要望を投げる口があり、色んな所から要望が飛び、数的には集まってる割には活かせていなかった。

極端な言い方をすれば、ユーザが何を求めているのか把握できないまま、
「〜なはず！」とか根拠のない妄想で語っているように見えた。

こんな雲を掴むような状態のまま、ユーザに届く自社サービスを維持できるのか？ 対策したほうが良いのでは。という想いが根っこにあった。

企画してみた

• ユーザからの要望を吸い上げることは同じ
• その要望がどれくらい望まれているのか可視化できるようにする
  • 各ユーザからの要望を社内クローズにせず、全ユーザに公開
  • 公開されている要望のうち「自分も欲しい」と思ったら投票
  • 多くのユーザが求めているなら自然と票が多くなり、限定的なニーズは票が少なくなる
• その結果を元にして、着手する優先度付けができる
• 重複コンテンツが生まれないようにうまいこと抑止できる仕組みを導入しノイズを減らす

という要件で企画を持っていってみた。修正点は色々あったけど通った。
一応SEというかPG的な職なので、企画は私の領分ではないし、もともと勉強してたわけでもない。

作ってみた

ベンチマークは、当時ちょうど見つけたChatWork ご意見・ご要望フォーラムを参考にした。

ソースは公開できないし詳しい話も書きませんが、
過去に書いたこの記事は、企画中のサービスを作ってた当時の情報です。

FuelPHPでInnoDBの全文検索を利用してみる | WEB EGG

重複コンテンツの排除とか実装したことなかったので、とりあえず全文検索とやらを入れてみたらなんかいい感じだったので、そのまま押し通したという感じ。

社内の要望管理にも使われた

なんやかんやで作り終え、いざお披露目してみたところ社長の耳に届いたらしく、
「いいねそれ、社内の要望管理にも使えないかな？」的な話をもらう。

使ってもらえるのは嬉しいし、カテゴリの整理とかちょっとした手間で社内用にも流用できる作りなのでやった。
ということで自社サービスと社内の要望管理の２つに使われるツールになった。

運用してみた結果

今まで平坦だった膨大な量の要望が、ユーザ投票によって重み付けされて、
効果が高そうな要望とそうではない要望の差が徐々についていく。
これで着手することに根拠が持てるようになるので、新規の開発案件の仮説検証に使用したり、不足している機能の洗い出しに使用したり色々なことに活用できそうな気がしていた。 ほんの序盤だけは。

---

…運用しつつ、データ見ていて気づいた。というかデータなんて見なくても誰の目にも明らかだった。
業務設計の時点でミスをしていた。全く要望がさばけていない 。
それでも要望はバシバシ届くので、「意見出してんのに何もしてくれない」と捉えられても仕方ない状況になっていった。

自社サービスの方は「開発コストがカツカツで余剰リソースを要望対応に割けなかった」し、
社内の要望の方は「制度設計とか対応完了まで時間がかかる案件が多い」とか同様に「対応リソース不足」が目立った。

各種調整や、時間・人のリソース確保が不足していたので、対応要員は増えず、そして私一人で要望を捌けるわけもなく。
可視化して重み付けするための”機能”に目が行ってしまっていて、リリースした後の社内の業務フローの設計や裏取りを全くやっていなかった。

参考にしていたChatWorkのフォーラムの方も要望数の割に消化率は良いとはいえず、
企画の時点で「懸念点として要望が消化できずユーザの不満を募らせる可能性があります」と言ったものの、回避策を真剣に練っていなかった。
まさかリスクど真ん中を貫かれるとは当時思っていなかった。

そして、可視化するためのツールなので、定量的・定性的なデータが取れてしまう。
言ってしまえば「定量的なデータを使ってます感を出しつつ、うまく誤魔化せる言い訳」になりつつあった。
悪意をもっての利用ではないと思うが、目眩ましに使われるケースが図らずして存在していることを知った。

振り返り

やがて形骸化し、サービス縮小して今に至る。
悪いことが目立つように書いてしまったが、悪いことだけではなかったと思っています。

• 今まで平坦だった膨大な要望に色がついていく感じはした
• 見えないもの・見にくいものを可視化するという視点は、後にも今にも活きている
• 浅いけど全文検索のノウハウが少しできた
• 企画 – 設計 – 実装 – テスト – 運用・保守まで全部一人で通せたので断片的に感じていた業務が流れで掴めた
• “変わった後”だけではなく”変えてく過程”の視点を持たないと実現できない理想論で終わってしまう

他にも細かいのは色々あるけれど、このあたりが大きかったと感じている。

さいごに

私は屍を1つ積んだので、同じ屍にならない良い施策が生まれることを願っています。
似たような事を考えてる人がもし居たら、この記事の内容が少しでも参考になれば幸いです。