株式会社マイベストでエンジニアをしています、あまね(@isaka1022)です。
2023年4月よりmybestの新規事業「favlist」の開発を担当しており、ちょうど10月で半年が経ちました。
今回はその半年間の経験を振り返りつつ、学びや反省点を残しておきたいと思います。
背景
私の経歴でいうと、新規事業やスタートアップへの興味から、ビジネスやサービスに対してエンジニアとして価値提供したいという思いでmybestへ入社しました。
そこからmybestの開発に携わり、要件定義、設計、コーディングやプロジェクトリードなども一通り経験しました。
その後favlistへの配属が決まり、「ひとりエンジニア」つまり、これまでチームに複数人のエンジニアがアサインされてチーム開発するのではなくて、エンジニアの役割を持っているただ一人のメンバーとしてチームに貢献するという新たな挑戦をスタートしたような背景があります。
favlistとは
私が開発することになったfavlistとは、様々な分野の専門家が、自由にリアルな愛用品やおすすめ商品を紹介するプラットフォームです。
憧れの著名人やインフルエンサーがおすすめするものを知れ、クリエイターとファンが「お気に入りのもの・おすすめのもの」で繋がれる場所を提供しています。
mybestが「比較」を軸にしておすすめの商品を知れるのに対して、favlistではユーザーの「憧れの人のお気に入り」という軸でおすすめ商品を知り、すぐに買うことができるという体験を提供しています。
初期の課題・困難
アサイン後、まずは事業の方向性を決める難しさに直面します。PdMと自分と2人の体制で、ユーザーにどのような価値を提供するかを一から議論しながらの走り出しとなりました。事業づくりの考え方や、プロダクトを方向性の決め方、目標や取り組む施策の順番などわからないことだらけの中でスタートしました。
また、技術的な側面でも、1人エンジニアとしての責任や役割が増大し、様々な課題に直面しました。プロダクト自体は私が配属される前から形としてはできていた状態だったのですが、手がついてなかった期間が長い部分もあったため、負債が溜まっていたり、今の形に適していない箇所もありました。
エンジニアひとりということで、
- フロントエンド/バックエンドすべての実装
- 技術選定や設計
- 見積もりなどのビジネス側とのコミュニケーション
- チームとしての働き方改善
- これまでに溜まっていた負債箇所の返上・解消
などなど自分がやらないと何も動かない状態になりました。
半年の成果・達成点
そんな走り出しから半年経ち、その期間での変化や、今考えていることを書いていきたいと思います。
フロントエンド/バックエンドを両方見るようになった
もともと私はRuby on Railsをメインでmybestのデータベースやランキング周りを開発することが多かったのですが、そこから一転し、Next.js×TypeScriptを使ってUIを改修したり、ユーザー向けの施策を実施することが増えました。
配属前はフロントエンドは「触ったことがある」程度だったのですが、開発を通してReactにおける状態管理やコンポーネントの分割の考え方、GraphQLのFragment Colocationの概念、デザインシステムとの連携など、フロントエンドの解像度がかなり高まったと感じています。
mybest, およびfavlistではAPIでGraphQLを用いており、それまではバックエンド側からしか見えていなかった部分も、フロントエンド側の視点から見ることができたのも良かったと思っています。
ここについては、弊社のフロントエンドのテックリードのサポートやコードレビューを受けながら、徐々にキャッチアップをしていきました、
ひとりでもDesign Docsを書くことで整理した
マイベストではチームで設計レビューや共有のために、Googleでも使用されているDesign Docsを使って運用をしています。
favlistはエンジニアひとりなので、あえてDesign Docsを書かずに設計や実装を進めても問題はないのですが、システム開発の意図や全体像、および技術選定の根拠をはっきりとさせるためにも、規模が大きい開発についてはDesing Docを書いています。
言語化をしておくことで不安な点は他のエンジニアに設計レビューをもらうこともできますし、後から人が増えても当時の設計意図が伝わるという効果があるかなと思っています。
何よりも、書くことで自分の頭が整理されて、よりよい設計ができている実感があります。
こちらは、これまでに書いたDesign Docの例の一部です。
技術負債の解消
プロジェクトを進める中で、どうしてもPdM側で次に検証する仮説を見つけたり、施策の効果を検証するフェーズなどで少し時間が手が空く「待ち時間」が発生しました。
この、施策と施策の小さな隙間を使い、あるいは施策に関連したリファクタリングの時間をPdMと相談して取ることで、これまでに使われていなかった不要なコードなどをたくさん削除することができました。
チームや事業としての大きな進展や変化は？
チームとしても日々のふりかえりの時間でKPTを回して働き方を改善していきました。
なかなか成果が見えづらい中でのふりかえりだったので、最初はついProblremばかりにフォーカスしてしまっていたのですが、それだとどうしてもチームとしての雰囲気が暗くなってしまったり、前進しているはずなのに手応えがでなかったりしてしまいます。
そこで、メンバーからの提案で、途中からは自分たちがやったことや小さい成果にも着目し、ちゃんとGoodやKeepも起票するし、大げさに喜ぶような働きかけをしました。これは今でもワークしています。
また、メンバーが少ないので、個々の連携を取ったりする意味でも、メンバーが他のメンバー全員とそれぞれ1on1の時間を1ヶ月に一度程度取って、コミュニケーションの時間を増やしたりしました。
反省点・学び
反省としては、もっとスピード感出せたということがあります。半年経過しましたが、当初設定した目標にはまだまだ到達できませんでした。
配属当初はこれから作ろうとする機能について、それまで開発していたmybestと同じようにしっかりと作り込む（しっかりと設計をし、検討し、レビューももらい、修正する、などのフローを通して実装していました）。
ところが、実際にリリースを重ねると、全く使われなかったりする機能もあり、「それならば最初から軽い実装で出してみて、使われることがわかった段階で作り込み始めてもよいのではないか」と考えるようになりました。
favlistは新規事業なので見える将来像が限られていたり、方向性が変わることも考えられるなかで、もしかしたら今自分が作っている機能がユーザーの課題を解決するかどうか、わからないことが多々あります。
ときには書いたコードを捨てる可能性もある中で「しっかりと作り込む」ところ「試す」ところ、あるいは「作らず」実現できるところを見極め、これらの選択肢を含めて最適な実装ができるようにしていくことで、より「試してみる」「検証してみる」回数を増やすことが大事なのだなと気づきました。
このあたりは、配属当初も色々な型の記事を参考にさせてもらいましたが、その言葉の解像度が今のほうが高まっていると感じています。
今後の展望
favlistへ配属されて半年が経ち、リリースや試行錯誤を繰り返し、当初はなかった実際のデータやユーザーの声が集まってきました。
ファクトがあるおかげで、今では地に足がついた議論ができるようになっていると感じています。
また、途中からチームの人も増えてきているので、できることがどんどん増えていると感じています。
今後は、前期の反省も活かして、プロダクトを磨いて価値を検証し終えて、その次の伸ばしていくようなフェーズにできたらと思っています。
今後人が増えることも見越して、ひとりからチーム開発になったとしても、柔軟性もち、ビジネス側とも密なコミュニケーションを取りながら事業に効くような開発ができるとよいなと思っているので、そのためのアーキテクチャやチームの体制なども考えていきたいなと思っています。
まとめ
まだまだ半年で私自身試行錯誤中でもあるので、ぜひこのあたり情報交換できる方、あるいはお手伝いしていただける方がいましたらぜひお話できると嬉しいです！
株式会社マイベストのテックブログです！ 採用情報はこちら > notion.so/mybestcom/mybest-information-for-Engineers-8beadd9c91ef4dc2b21171d48a4b0c49
Discussion