ID:66747さん

このプロジェクトは友人4人(現在は3人)とはじめました。 開発しているプロダクトを一言で表すと「GitHubのIssueをサイドバーで開く」ものです。 https://chrome.google.com/webstore/detail/mokuren-for-github/nikennffbfoadbajdgnhlngjahofhdef エンジニアとしてはもちろん、以下の役割も担っています。 * プロダクトマネージャー(インタビューを通してユーザーを知り、プロダクトの方向性を決める) * プロジェクトマネージャー * UX 具体的にやっていることは下に記載します。 # Mokurenを始めた背景 このプロダクト自体の解決している課題は、「ブラウザがGitHubのタブで埋め尽くされている」というものです。 現在働いている企業や、友人との開発でGitHubのIssueを使うことが多く、使いにくさを感じていました。 インタビューを重ね、同じような課題を持っている人が多くいたため開発を始めました。 # 技術周り 以下の技術をチームで採用しています。(%は自分のコミット量) * Vue.js(Typescript) (70%) * クリーンアーキテクチャー参考 (20%) * Git・GitHub チーム全員が違った技術スタックだったため、共通認識を持って開発をスタートするのが苦労しました。 そのために、スタート初期は勉強会を隔週で開催したり、時間をとって設計を全員で行うことでスムーズに開発を行えるようになりました。 # プロダクトマネージャーとしてやっていること 自分のプロダクトマネージャー(以下PdM)としての役割は、**インタビューやデータ分析を通してユーザーの課題を見つけ、プロダクトの方向性を決める**ことです。 インタビューは合計約20人ほど行っています。 ### リリースして終わり Mokurenを進めていく中で、新しい機能を作っても、データだけ見て良し悪しを判断し、次の一手を打てないという課題がありました。 例えば、1つ機能をリリースしてGoogle Analyticsで想定していたより使われてない場合、その理由がわからず自分たちの想像の中でしか改善ができていませんでした。 その原因は * ユーザーインタビューができていない * 全ユーザーが触る機能なので、作り込みたくなってしまう という課題がありました。 これを「ベータ版リリース」という方法で解決しました。つまり、直接連絡が取れ、信頼関係ができているユーザーだけのバージョンを用意しました。 それにより、他のユーザーに影響が出ない & 多少のバグも目を瞑ってくれる中でリリースができ、 さらにはインタビューをしやすい環境を作りました。 その結果、機能を作って壊すサイクルが格段と早くなりました。 ### 課金導入の障壁 このプロダクトは長い間、無料でした。 開発している我々も、本業ではないため収入がなくてもなんとなくで続けていくことは可能でした。 しかし、そんな中で続けていてもプロダクトの成長は止まるし、誰も幸せにしないことに気づきました。 収入を得るための方法として課金機能を実装することは全員の頭にありましたが、後回しにしがちでした。 このままではよくないと考え、「2023年の3月末までに1円以上の収入がなければこのプロジェクトはやめる」という決め事を作り、追加しようとしていた機能を一度全て止め、課金機能に取り掛かりました。 結果的に明確な数字の目標ができたため、「お金を払ってもらうにはどうするべきか」にフォーカスできたことが最大のメリットだと感じています。 しかし課金機能はユーザー離脱のリスクもあるため、β版などをうまく活用しながら実験中です。 # プロジェクトマネージャーとしてやっていること 主に進捗管理をしていますが、それ以上に必要なのはメンバーのモチベーション管理だと思っています。 このプロダクトは私の課題起点だったため、他のメンバーは自分ごと化するのが難しい状況でした。 そんな中で意識していたのは「一人一人責任領域を持たせ、その領域は完全に任せること」です。(後述しますが、これが完全にはできていなく、失敗したストーリーがあります) 具体的なストーリーとしては、 実装の設計やテストなどが好きなメンバーには、チーム内のCTOという役割を与え、テストなどがどれくらいうまくいっているかのKPIを一緒に考えたりしました。 (もちろんテストを1人に任せるのではなく、リードをお願いしているかたちです) その結果、各メンバーがそれぞれの領域についての発言ややりたいことなどが増え、モチベーションが上がったように見えました。 ### それでもだめだった話 それでも、それぞれのコミット量の要因はモチベーション以外にもありました。 本業だったりプライベートが理由でどうしても自分だけがコミットする環境になってしまいました。 正直、「なんでやってくれないんだ」という思いが溜まってしまい、チームメンバーに相談しました。 (少し言い合いになりました) 話し合う中で見えてきた原因は、 * それぞれが自分以外の人がMokurenに使える量を把握してない * 将来Mokurenで稼いだ時に、貢献した分のお金をもらえる仕組みがない というのでした。 解決策としてはタスク1つ1つにポイントを振り(スクラムのポイントのようなもの)、その割合でもらえる金額が変わるという仕組みを導入しました。 一見不健全な仕組みに思えますが、そのおかげで他の人がどれくらい貢献しているかなどが可視化され、コミットが多い人も納得し、少ない人も罪悪感を抱くことなく開発できています。

現在所属している企業のプロジェクトで、今はFlutterでフロント(スマホアプリ)の実装をしています。 (新卒)入社直後はRuby on Railsでサーバーエンドの実装をしていました。 2年ほど前にフロントにチェンジしました。 変わった理由は当時、個人開発でFlutterを使ってアプリを1つリリースした経験があり、Flutterを業務で挑戦してみないか?という誘いからでした。 このプロダクトはコミュニティ通貨サービスで、人と人とをつなげます。 通貨はコミュニティごとの通貨で(例えば鎌倉ではクルッポ)、地域に興味があるスポットやユーザーさまが利用します。 # 個人開発を活かす強み 上記で述べたとおり、もともとサーバーサイドを担っていましたが、個人開発での経験を認めてもらいフロントにジョブチェンしました。 他にも、ユーザーインタビューの経験や、企画、データ分析など個人開発の経験を生かした数は数え切れません。 プロダクト作り全てを経験したいと言う姿勢が、いろんなことを学び、いろんな方向性で貢献できる力を身につけたと思います。 # 興味がなくて苦労した 1番苦労したのは、自分は地域創生に全く興味がなかった点です。 原因を考えるとキリがないですが、ずっと都会暮らしだったため「地元」とか「地域」という概念が薄かったのだと思います。 それは自分だけではなく、特に若いメンバーに多いように見受けました。 Mokurenでも記載しましたが、モチベーションという面では、やはり自分ごと化するの強いと思います。 幸いにも、会社は鎌倉にあり、鎌倉ではまちのコインを導入しています。 そのため、「スポット回り」という会社近くのスポットをめぐってアプリを使うイベントを定期的に開催しました。 自分と同じような課題を持った人が集まってくれて、継続することができました。 その結果、自分たちのアプリを使ってる人の顔がわかる、という環境ができ、モチベーションが上がったという声をいただきました。