AndroidエンジニアがmikanでGrowthやりたいと宣言して実行できた話
はじめに
皆さん、こんにちは！英語学習アプリmikanでAndroid Leadをやらさせてもらっている gumioです！
こちらはmikan advent calender 2023の3日目の記事になります！
昨日の弊社取締役mizorinによる、「mikanでのプロダクトづくりが面白い理由」はいかがだったでしょうか?
mikanのプロダクトづくりが面白いのはほんとそうで、よく聞かれるのが「mikanってもう完成されたプロダクトなんじゃないの??」と。全くそんなことはなく、まだまだこれからでっす！
まだ読んでない方は是非！
さて今回は珍しく技術的な記事ではなく、自分の考えてるキャリアのお話。そしてそれをmikanで実現できているという非常にタイムリーなお話をしていこうと思います
プロダクトを成長させたい
あれは遡ること~…というのは5000文字くらいかかるので省略させていただいて、自分は将来的にはエンジニアのエキスパートでもなく、マネージャーでもなく、プロダクトを成長させられるエンジニアを目指したいなという気持ちでmikanにやってきました！
世間ではGrowth engineerなんて呼ばれたり、してることもあります。 詳しくはこちらのnoteの方が分かりやすいと思いますので、是非！
最初はプロダクトを成長させれる~なんて、そんなしっかりした言葉では定まってませんでした！Growth engineerやりたいです！くらいの温度感でした。 結局は組織や個人で定義などは異なってくると思うので、言語化して僕なりの解釈として落ち着いたのは
「プロダクトを成長させられるエンジニア」
になりました。
いいもん作って、ユーザーさんを熱中させたい！そのために必要なことはエンジニア観点でやれることはやってこう！的なノリで捉えてください
そろそろぶちかましたい
そんな事を言いながらも、メイン業務はAndroidエンジニアです。えぇ
なんならリファクタリング, 不具合, mustではないけど実はやりたい機能開発…etc.とやりたいことは他にもたくさんあります…
が！！！！！何かこう、プロダクトに貢献してる感が薄れてきたんですよね。
「あれ?? Androidってmikanに貢献できてる??」
と。それが2023年9月末の出来事です。タイムリーですよね〜
大前提として、貢献はかなりしてます！！！mikanではiOSの方が先行リリースされていたという背景から、MUSTの機能差分などができていたのでその機能差を埋めることが直近のミッションでした。そんな差分も夏頃のBookReader(電子書籍)機能でほぼ終わりました。
もちろんまだ差分はあったりしますが、今すぐやるものではないくらいには追いつきました。これは機運だと。やるしかないと
ということで、2023年10月から記事を書いている現在進行形でやりたかったことを実現させるために動きました！
上記の気持ちも含め、事前に取締役陣には相談して、実施していく流れになったのですが、mikanの好きなとこは個人の成長のことも考えてくれてるので、非常に相談 → 提案 → 実施がしやすいと思ってます。
余談で今回は省略しますが、上記をやる上でBackendのこともちょっとは分かっておいたほうがいいよな??ってことで、Backendもちょろっと開発可能だった時にコミットさせてもらったのですが、その時はBackendチームが親身になってサポートなどもしてくれたので、ほんといい人達ばかりだな〜なんて感動してました…(いつもありがとう)
動き方
さてさて、ここからはもう一生俺のターンだZE！！！ドロー！！！ってしたい気持ちで言語化してから、動いたのですが最終的に初期は以下のような形で動くことで落ち着きました。
「エンジニアリング業務の3割を削り、施策検討・分析の時間に充てて、その施策の実装も自分がやる」
上記を実行していく上でのリソース割合は下記のような感じで、検証期間や施策がストックしてきて、実装集中する期間もあると思ったので範囲を持たせてる感じです。
実装: 70%
メインの開発とGrowth施策で半々
分析 / 仮説立て: 20 ~ 30 %
施策・バックログ整理: 0 ~ 10%
やってみた
実際に着手する際、好き勝手やるのはブレができてよくないため、領域を絞って方向性を決めるところから入りました。
今回のテーマはこちらっ
「通知」
なぜ?
mikanは学習アプリなので、続けてもらうことが大事
実は今まで通知を科学するということをしてこなかった
ここまで決まれば、動き方とやや重複しますがこんな感じで進めていきました
通知関連の施策をAndroidチーム、PM含めて皆でDraft形式で非同期で考えて、貯めていく
週一 or 隔週で集まり、Draftで貯まったものを採択したりして、Backlogに貯める
順次要件整理、仕様などを詰めて実装を進めていく
施策の実装 or メインの実装
リリース
検証(ABの場合)
検証期間中はメイン実装のみをやる
検証終了 → 分析
レポート書いて、施策の最終判断をし、学びを蓄積
これが一番大事だと思っている
の繰り返しでした！
インプットもしたよ
また、上とは別枠で、インプットする時間も増やしたいということで社内の分析マスターことitoryo先生に夕会後30分だけ時間を頂いて、分析講座なんかを開いてもらいました。
mikanはこのような人がたくさんいて、ありがたい限りですね(n回目)
もう一つ別枠で他社さんの成功 / 失敗施策という学びをインプットして、視点を増やすためにアプリマーケティング研究所さんを課金して、読み漁りました。今までにない気づきや発見があり、読んでいくうちにいい施策などの共通点にも気づけたりするので、こういうの好きな人はおすすめです！
実際にいいやんけ！って思ったすぐ試せそうな施策は見事に無風でした….。(世知辛いね)
やはりこれに関してはサービスの性質というのがそれぞれあるので、そのサービスには刺さる, 刺さらないの差分が出てくるのは面白いですね！
結果はよくなかったけど、自身のサービスの性質みたいなところが学びとして蓄積されていくので、どんどんまわしていきたいお気持ちです。
現在は自信ある施策がこれから出ていく予定なので、お楽しみを〜！！！
どうだった?
mikanで一番楽しく、一番大変だった(白目)
Good
自分たちで仮説、issueを考えるのでwhyが明確
コミュニケーションコストがかなり少なく、スピーディーに進めれた
数値に対しての意識が身につくので、定点観測の習慣化がされる
Log設計で自分で分析できる?の自己問答が入って、分析者フレンドリーになれる
世の中のアプリや施策に対しての視点が増えた
簡単な分析ができるようになる
More
主に実装以外の慣れない動きで時間配分が狂う
普段使用する脳みそと違うから疲れる(個人差)
今回に限ってですが、MUSTではなくてもめちゃくちゃでかい開発を並行で行うとスイッチングコストが凄まじい
フォーカスするために仮説領域を絞っていたのに別の領域の施策を別枠で考えてしまってた
デザインは自己完結せずに頼ってしまったので、デザイン部分だけコミュニケーションコストが高めになってしまった
普段通りではありますが、速度を出せるメリットを軽減させてしまったなと反省
このような発見が得れただけでも、やってよかったかなと思ってます！振り返りをしっかりして、改善していきますので乞うご期待くださいませませ
さいごに
いかがだったでしょうか?? 是非これからキャリアを考えられる方や、こんな働き方もあるのか~という参考になれば幸いです！
さて、そんなmikanでは現在最高の英語アプリを共に作っていける仲間を探しております！
ちょっとでも気になったよ〜！って方、もっと話を聞いてみたいと思ってもらえましたら、X経由でも下記のHERP経由でも最近始めさせていただいたPittaでもお気軽にでご連絡ください。主はSplatoonが大好きなのでSplatoon面談なんかでもWelcomeです！
明日はyauが担当です！お楽しみに！
この記事が気に入ったらサポートをしてみませんか？