【転職ドラフト】事業フェーズの転換点で、開発組織が行ったこと

転職ドラフトはサービス開始から7年目を迎え、いわゆる「0 → 1」のフェーズから「1 → 10」のフェーズへの転換期に突入しています。
その過程で開発組織も転換を求められることとなり、数々の困難に直面することになったと伺っています。
今回は、開発組織や開発手法の転換に伴う苦労と、その対処について、エンジニアリングマネージャーの荒川さん（github: ArakawaShintaro）にお話を伺ってきました。

（インタビューアー：伊藤）

「0 → 1」のフェーズでの開発体制と、そこからの脱却

伊藤：
荒川さんは、いつから転職ドラフトにジョインされているんでしたっけ。その頃の開発について教えていただけますか。

荒川：
2020年9月です。当時はいわゆる「0 → 1」のフェーズにあって、今とはずいぶん開発体制が異なっていました。
当時は、売上を伸ばすというよりも、サービスの世界観を作り上げることに重点が置かれており、現在もそうですが、当時から企画職の方はもちろん、セールスの方や僕らエンジニアも含めて、メンバー全員が企画を提案することができました。そうして各メンバーから起案されたチケットをCPM（チーフプロダクトマネージャー）が全てチェックし、やりたいことがはっきりしたら開発チームに降りてきて仕様化、実装、リリースと進んでいく、この繰り返しです。スピード感はかなりあったので、プロダクトの世界観はとても盤石なものとなり、現在のプロダクトの成長を支えてくれているように思います。

伊藤：
なるほど。順調に開発できているように聞こえますが、いつまでもこのやり方ではいけなかったということですか。

荒川：
そうですね。プロダクトの世界観は割とはっきりしてきた一方で、思うように売上が伸びていかない時期が続き、メンバーからは事業の将来を不安視する声が上がるようになりました。開発チームとしても、このままの開発体制で進んでいくと疲弊していくのではないかという危機感もありました。

伊藤：
危機感ですか。

荒川：
はい。たくさんのチケットがCPMから降りてきて、エンジニアはそれらを実装することに追われていたので、受託開発をしているような気分になることがありました。CPMが企画内容を詰めているので、開発者として企画の内容に入り込む余地も少なかったですし、効果検証をしているわけでもないので、自分たちの実装がどう事業の成長に生きたのかもわからない。残業も少なくなかった記憶もあり、自身の技術力で事業に貢献したいという思いが強いエンジニアが多い弊社では、長続きしなさそうな開発体制でした。

また、開発チームにチーム感がなかったことも問題として挙げられるかと思います。テストをほとんど書いていなかったですし、定例MTGも実施していませんでした。レビューも十分にはしておらず、各自が勝手に実装して動作確認の上リリースするという状況でした。コーディング規約はあっても、動けばいいでしょ感がなかったとは言えませんね。

この辺りのタイミングで僕が開発チームのリーダーになったため、以上の点も含めて開発体制の一新に取り組むことにしました。

「0 → 1」から「1 → 10」へ

伊藤：
具体的に、どんなことに取り組まれたのですか？

荒川：
大きく2つです。スクラムの導入と、開発チームの再構築です。

まずスクラムの導入についてですが、バックログに蓄積されたチケットのストーリーポイントを優先度順に見積もり、MTGでチケットをアサインしてスプリント終了時にベロシティを確認するという軽量型のスクラムを導入しました。
開発チームが企画者の代表であるCPMとMTGを開催してストーリーポイントを見積もる形を取ったので、企画者と開発者が対話する機会を設けることができましたし、ベロシティを計測することにより毎回のスプリントで消化できる大体のタスク量が予測できるので、企画側と作業量に関する合意をとることができるようになり、仕事にゆとりが生まれました。今までCPMが個人で担っていた役割をチームで担うことができるようになったというのは、大きな変化だったと思います。

開発チームの再構築としては、さらに3つに分けられるかなと思っています。
1つ目は、テストを書く文化を作っていったことです。僕個人として、あまり何かを強制するタイプのマネジメントは好きではないのですが、テストを書きましょうねと口を酸っぱくして呼びかけました。
2つ目は、チームメンバー全員がお互いにレビューするようにしたことです。当初は、業務委託の方はレビューをせず、数人の正社員のみがレビューをしている状況だったので、業務委託の方も含めてレビューをお願いすることにしました。
3つ目は、定例MTGを実施したことです。顔を合わせて話すことで連帯感を生みたかったのと、開発チームの人数が増えてきたので、各々が何に取り組んでいるのかを把握しやすくしたかったためです。全員で話しながらタスクの割り振りを行なったことで、各自がやりたいチケットを取れるようになったし、タスクの概要を把握しているのでレビューがしやすくなるという効果もありました。

伊藤：
なるほど、こう言ってはなんですが、当たり前のことを当たり前のようにやったということに尽きるんですかね。

荒川：
はい、そう思っています。当時は、自分のやっていることがあまりにも当たり前のことばかりで、自分は誇れる仕事を何もしていないのではないかと悩むこともありました。当時のVPoEとの面談で、「当たり前のことを当たり前に行うのは大変なことで、その苦労はわかる人にはわかる」と言葉をかけていただき、安心したのを覚えています。

伊藤：
開発体制を一新するにあたって、何か気をつけていたことはありますか。

荒川：
組織の規模が多少大きくなっても、影響を受けにくい構成にしたいとは思っていました。伊藤さんは2022年1月に転職ドラフトにジョインされていますが、ジョイン時に開発チームがごたついている印象はありましたか？

伊藤：
いえ、特に大きな問題は感じずにジョインできた印象が強いです。スクラムポイントの粒度を揃える作業などは発生していましたが、それはメンバーが変わるタイミングでは必須の作業ですよね。

振り返りと、今後の開発について

伊藤：
開発体制を一新して、よかったことはどんなことでしょう。

荒川：
やはり開発チームとしてやれることが増えたことですね。スクラム導入時は、スクラムの教科書に載っているような事例をたくさん経験することができましたし、スクラムが軌道に乗ってきて、開発チームとしても実装した施策に対して振り返りや検証を行うようになったので、「1 → 10」のフェーズに突入することができたと言えるのではないでしょうか。

伊藤：
以下のグラフを見ると、企画と開発チームが連携するようになった2021年あたりから、参加数の伸びが大きくなっているのが分かりますね。