開発チームが少人数で効率よく開発するために選択したこと
株式会社マイベストでCTOをしている渡邊です。早いもので、この会社に入社してから4年ほど経ちました。
今回は「選択」をテーマにした株式会社マイベストのAdvent Calender 2021にちなんで、今年開発チームがどういう選択をしてきたのか？をまとめつつ振り返ってみようと思います。
※このnoteは、株式会社マイベストのAdvent Calender 2021に参加しています。「選択」をテーマにメンバーが日替わりで記述しています。エンジニア・デザイナーだけでなく、商品を検証したりコンテンツ制作を行っている方も投稿しているとても多様性のあるアドベントカレンダーですので、ぜひご覧ください！
マイベストは国内と海外8ヶ国でサービス展開しており、国内のmybest（ http://my-best.com/ ）は、現在5000万PVを超えるようなサービスとなっており、このサービスを現在は以下のようなメンバー構成で、開発・運用しています。
やることに対して人数的に決して潤沢ではない状況で、どういった工夫をしながら選択し改善しているのか少しでも伝わればと思います。
やるべきことに比重を置くために、業務委託の方に協力してもらう体制を整備した
こちらの記事で紹介していますが、開発部では1年ほど前から、やりたいことが数多くある中で、プロダクトとしてやらなくてはいけないことにリソースを集中させるために、マイベストの開発チームはミッションという形でチームを構成しております。
（図と課題はイメージです）
ただ、完全に分割できているかというと実際はそうではなく、実際にはミッションには入り切らなかったけどやる必要があるミッション外というタスクが存在していたり、細かな負債の解消を空き時間で行うような働き方になっていました。（負債の解消に関しては、Spark Joy Dayなるものを定期的に実施し、細かな負債やリファクタリングを行ったりもしていたのですがプロダクトの成長速度に対して仕組みだけでカバーするのも中々厳しいような状況でした）
この状況を解消すべく、ミッション以外の課題を対応する担当として業務委託・副業の方にお手伝いしていただけるような環境を整えました。現在ではこのような形で役割を分けつつ進めています。
具体的に、中・長期的な事業・技術課題に関しては社員の方が対応し、それの補佐相談や展開、短期的な部分での課題は業務委託・副業の方々にお願いする体制にしました。
この体制によって、ミッション内では優先度の判断や期待値のすり合わせをしやすくなり、中・長期的な課題に対してかけられる時間やマインドシェアが増えました。また、業務委託の方にお願いする際の要件も整理できたことで、タスクの依頼や参加ミーティングの棲み分けを進めることができました。
（この仕組みを支えてもらっている業務委託・副業の方々にはとても感謝しています）
意思決定の速度を落とさないために、権限を移譲した
3〜4名で開発している頃は様々な意思決定やコードレビューなどをチーム全体で共有しながら行うことが多かったのですが、人数が増えるにつれてコードレビューや技術課題に関する旗振り役が曖昧になってきたため、フロントエンドとバックエンドそれぞれに強みを持った方々がある程度増えたタイミングで、フロントエンドとバックエンドのチームに分けそれぞれにリードをアサインし、ルール策定含め移譲しました。
その際、スタートアップで4年も働いていると、”知らない間に色々な役割や権限を暗黙的に持っていた” みたいなことも十分あり得るため、移譲にあたってはホラクラシー組織を参考にしながら 権限を移譲する際に必要なものをまとめていきました。
そして、holaspiritを利用して可視化・言語化してメンバーに共有しました。
今では、それぞれのリードとなってくれているメンバーが旗振り役となって能動的に技術課題の対応や開発体験（DX）を改善してくれているのでとても助かっています。ただ、ホラクラシー組織的な観点で見るとまだまだ改善の余地は多く、このあたりは来年以降も振り返りながら対応してこうと思っています。
サイトパフォーマンスやシステムの性能を監視するために、健全性指標を導入した
数年前から、プロダクト開発部のOKRには必ずパフォーマンスに関するものが立てられており、通常業務とは別にパフォーマンスを改善するようなイベントなどを通してパフォーマンスの改善を図ってきました。（以下の記事にもある通り、開発部最初のOKRはパフォーマンスでした）
そこから数年かけ少しずつパフォーマンスを改善する施策を積み上げてきましたが、既存のアーキテクチャではそろそろ改善幅的にコストパフォーマンスに見合わないぐらいの施策しか残らないという状態になっていました。
そうなると、目標が改善するというより維持するという意味合いが強くなってきたため、チームのKRとしてではなく、ミッション毎の健全性指標として監視するように変えました
これによって、”なぜ今パフォーマンスを改善すべきか？”ということがわかりやすくなりました（ちなみに、この指標設定後に、対応が必要になるような状態になったことがないので実際にうまく活用されるのかはもう少し先の話かもしれません）
おまけ（個人で選択したこと）
ここまではチームとして選択したことを中心に挙げてきましたが、最後に個人的に今年選択したことを一つ。色々と改善事例の話をしてきましたが、とはいえスタートアップのこのフェーズに於いてはまだまだ改善しなくてはならないことが多く、事前に想定していた状況が覆るようなことが度々起きます。むしろ想定外なことが起きすぎて、想定外が起きるのは想定内みたいなよくわからない状況になります。
そんな時、自分に余裕がない状態で物事を選択すると、後からふりかえった時にその選択があまりベターではなかったかもと思うことが多々ありました。ほぼ0→1の頃からやっているということもあり、裁量が広いと自分で色々やりたくなってしまうんですね（俗に言う「自分がやった方が早い病」っぽいやつかもしれません）
そんな状態だと自分にもチームにも良くないだろうと思い、最近では自分の担当を具体的に定めずにできるだけメンバーに頼り、誰が拾ったらいいのかわからないような課題やチームがミッションや課題に集中するための障害となりそうな課題に対しては自分が拾えるように立ち回りを変えるようにしました。
まだうまく行っているのかはちょっとわからないですが除々にコードを書く量が減っていたり、意思決定ではなく議論・共有のやり取りが増えていることもあり、少しずつスケールしている感じはあります。
（このあたりは、自律的に動いてくれているメンバーのおかげで成り立ってます）
そんなこんなで、今年開発チームが選択してきたことをいくつかまとめてふり返ってみました。同じような事業フェーズや組織規模感において、似たような悩みを抱えられているような方の助けとなれば幸いです。
ここには書ききれませんでしたが、他にも多くの選択をしておりネタはまだまだありますので、このあたりにご興味があるような方はぜひお話をさせてください〜！
また、現在はまだ少人数での開発となっておりますが、エンジニア・デザイナーの採用に関しては絶賛募集中です！
それでは皆様良いお年を。
この記事が気に入ったらサポートをしてみませんか？