Funakoshi Table of Contents
sigfyについて
導入・運用がとにかく楽な連絡サービス
連絡をメールやLINE、スマホアプリといった複数の方法で受け取ることができる連絡サービスです。 学校法人・保育園・病院など、数万人ものユーザーに連絡を届けています。
という感じのサービスです。 それなりにレッドオーシャンな領域のサービスではありますが、 機能をシンプルに使いやすく・連絡を確実に素早く届け・ユーザー様の運用を徹底的に楽にするといった特徴を評価いただき、口コミ等で全国の学校様を中心に広がっております。
12月頭にアプリが新規リリースとなりました！バンザーイ！！
0. まず無知を認めた…
さて、私自身、「プロダクトマネジメント」を明確に意識できたのはこの1年くらいです。きっかけは、pmconf2019でした。
pmconfは、最高にクールで個人的にめちゃくちゃ好きなカンファレンスです。
ここでPMというものに出会うまで、恥ずかしながらPMという仕事を明確に意識できておりませんでした。
自分の立場としてPjMを学んだり、サービスの視点としてITサービスマネジメント（ITIL）を学んだりとやってはいたものの、どうもクリティカルなものに出会わない…。そんな中参加したpmconf2019は、私が望んでいる仕事、目指したい領域であり、コレだ！と感じさせてくれるものでした。
そこで感じたのは、自分自身の無知、また自社サービスにPMが存在していないことへの危機感・恐怖感です。
そんなわけで、この無知をみとめ、まずは知識を頭につっこんでいきながら、プロダクトsigfyに色々とトライしていきました。PMの方にはおなじみだと思いますが、 INSPIRED 熱狂させる製品を生み出すプロダクトマネジメントは特に私の支えとなりました。
まだまだ理解も浅く、手探り状態ではありますが、以下にいくつかのPMとしてのアクションを紹介していきます。
1.現在のVision（Why）を言語化した
sigfyは2017年にリリースされました。これまでも誰に向けて、どんなものを提供していくのかといったところはチーム内で頻繁に議論共有してきました。そこにはVisionのようなものも含まれていたと思います。
ところが、次なる成長（大きな数値目標）が与えられることで、「アレもコレもやりたい・やらなきゃ…」とアイデアが膨らんでいきます。それ自体は悪いことではないのですが、何をやるの？について雰囲気で取捨選択していくのは大変です。理由わからずアイデアを却下されたりすると、チームメンバーとしても気持ちがよくありません。
そのときに大事になるのが、「なぜやるの？」がわかること…。
このWhyさえはっきりしていると、「うーん、悪い機能ではないけど今は違う！」みたいな判断に説得力がでてきます。
これ、Whyがうっすら共有されているくらいの状態では、Whatにあわせてブレブレになってしまう可能性があります。 しっかり明言・明記しておくことは、想像以上に大切なことではないかと考えています。
そこで、Whyの言語化を以下のように行っていきました。
前提として、すでにWhyに関してもある程度共有されてきた過去がありますので、チームメンバー全体が概ね近いWhyのイメージを持っていました。そこで、今回は各々で一度言語化してもらい、その上で投票・すり合わせをしていきました。「現時点でのメンバー間のズレを認識したい」意図もあったように思います。
各々で言語化→チーム内投票→票数が高いものを確認の上、再度各々で言語化→チーム内投票→PMが言葉を紡ぎ合わせ、声に出しながら復唱しつつブラッシュアップ→確定
という感じです。声に出すと違和感に気づきやすくなります。
Vision（Why）は以下のように設定しました。
学校・保護者・その他利用者の、もっと大事なことをするための「時間を作る」
これまで、連絡サービスとしてシンプルさ・確実さを大切にしてきましたが、そこはもはや我々にとっては当たり前に提供したい品質となっています。今後さらにお客様へ貢献できるように、時間を作るサービスへ進化していきます。
2.改めて問題に恋をした
Fusicはエンジニアが多い会社です。さっと作れちゃうことが多い。
そんな経緯もあってか、「プロダクトアウト」で開発することが少なくありません。
ゆえにサービス初期には、「ユーザーが抱える問題」の解像度がまだまだ低く、思ったほど使われない機能も存在していました。
一方で、その状況を理解していた当時のチームリーダーが決めた「ユーザーのために徹底的にブレる」というコンセプトがあり、ユーザーのお悩みをヒアリングしながら、サービスを進化させることで喜ばれてもきました。このおかげでこれまでも上手に「マーケットイン」なプロダクト開発ができていたようにも思います。
さて、そんな中、プロダクトの今後を期待され、約３年後を見据えた【大きな売上目標】が設定されます。これは、今のまま成長するだけでは、達成が難しい目標です。
このような状況になると、「売上を達成するために必要な機能」という方向に気持ちが向かってしまい、「ユーザーの問題解決のための機能」という視点から少し離れてしまいがちです。
そこで、「売上を達成するために必要な機能」が「ユーザーの問題解決のための機能」として強く結びつくものなのかを導けるようアクションしました。
具体的には、1.ユーザーアンケートです。以下のようなことを尋ねます。
- 現状sigfyの満足度
- 不満点や足りない機能は何か？（要望の収集）
- sigfy 新機能に関する需要の調査
- sigfy 新機能に関する不安材料の調査
ユーザーアンケートを実施した印象は、非常に良いです。
アンケート結果は、今後の機能追加、改善を考える上で重要な宝の地図となったように思います。
さらに、一斉アンケートだけでは引き出しづらい情報については、**お客様個別でのヒアリング（N1分析）**を行いました。この対応により、必要な機能のイメージがより具体的になっていきます。（N1分析については顧客起点のグロースフレームワーク（pmconf2020）の発表が参考になりました。）
これらの行動により、単なる「売上を達成するために必要な機能」になるかもしれないと思っていたものが、しっかりと「ユーザーの問題解決のための機能」である確信になり、自信をもって開発を進められるものとなりました。
ユーザーの問題を認識できることが、機能検討にも非常に重要であることを感じられる良い機会となりました。
なお、この新機能は、現在開発進行中ですので、今後の発表をご期待くださいませ。
3.デザイナーを横におく
今現在、Fusicには残念ながらデザイナーがおりません。（こちらで募集中ですので是非！）
プロダクトを考えたときにデザイナー及びデザインが重要になることは明らかです。これまでも、外部のデザイン会社様に協力いただきデザインを依頼するようなことはありました。これも効果はあるのですが、もっとチームメンバーとして活躍できるデザイナーを欲していました。
そこで、長期的にプロダクトに関わっていただく形でCGFM様に入っていただくことができたのは、ありがたく非常に大きかったと感じています。
大きなメリットは「UI品質の向上」「チームメンバーのデザイン意識の向上」です。
その他にも
-
チームにガッツリ入っていただくための情報共有により、メンバーのsigfy理解も深まった
- デザイナーの上手な質問や客観的視点によって、引き出され再認識できた
-
ペルソナ・ユーザーシナリオ等から作成し、具体的なユーザーイメージを深めることができた
-
これまで以上にユーザー目線を意識した画面設計を行うことができた
- 機能からではなく、ユーザー心理から画面を検討していく流れが当たり前になった
-
我々だけではたどり着けないステキな見た目のアプリになった
などなどたくさんあります。
アプリ開発の際には、今までに無いレベルでプロトタイプ段階でのブラッシュアップを行いました。
もちろんデザイナーだけではなく、PM・営業サポート・エンジニアの各メンバーが集まってレビューを行います。想像していた以上にデザインを完成させる工程は時間も体力も必要です。
本気でユーザー視点を大切にし、レビューを行っていきました。 Web版とは異なるけれども本当にわかりやすい画面になったと感じています。
DBの都合や開発コストの都合から、ユーザー目線でないことを許容してしまうことは起こり得ることです。しかしながら、そのように開発メンバーが納得できていないプロダクトは、ユーザーにはもっと使いづらいものになります。さらに、営業提案をするときにも、自信を持っておすすめできなくなる…。そんなマイナス面を考えると、初期工程において開発工数を投じ、高いレベルで満足できるものを作り出すことは、トータルで見たときにはお釣りがでるほどプラスになるのではないかと思います。
デザイナーが入り、ユーザー目線を徹底することで、本当に満足のいくアプリになりました。
4.完璧を目指さない
細かな改善の話です。何か改善を行うとき、どうせならアレもコレもとなっていきがちです。
軽微な改善で効果が高いものがあります。それでも、完璧を目指すと改善速度は低下してしまいます。そこで日々の改善で大切にしたのは「完璧を目指さない」ことです。（もちろん、改善の内容にはよりますが…）
判断としては「今より良いかどうか」。
完璧を目指して遅くなるより、「今より良い」を素早く繰り返すことによる、プロダクト品質の向上を行い続けました。
繰り返しの改善はお客様にも伝わるようで、喜びや感謝の言葉を伝えられる機会が増えたことも考えていなかったメリットに繋がりました。
5.ロードマップを描く
大まかではありますが、sigfyの未来を示すロードマップを描きました。（ぼかしてます、ごめんなさい。）
1でつくったVisionは我々チームを熱狂させるものです。
さらに、今つくっているものが、未来のsigfyにどう役立っていくのか理解する。この発展の先に、お客様や我々にどんな幸せな世界が待っているのか？をイメージする。これは、チームが全力で開発を進めるためにも重要な情報であると考えています。
夢と情熱を持てるチームは強い！
まだまだ不確定要素のある大枠のロードマップではありますが、都度都度状況に応じてアップデートしていければと考えています。
（ピンチをチャンスに：未来をつくるプロダクトロードマップ（pmconf2020） ではVisionやRoadmapの役割についてお話をされていましたのでご参考まで。）
おわりに
記事のまとめ
- 現在のVision（Why）を言語化した
- 改めて問題に恋をした
- デザイナーを横におく
- 完璧を目指さない
- ロードマップを描く
Funakoshi
プロジェクトマネージャー。自称、愛とわくわくの伝道師。 自社サービスsigfyでは、プロダクトマネージャー的なことをしている。 元ゲームプランナー＆ディレクター。趣味で少しだけYoutuber。 娘中心の生活。
