転職会議で新サービスMIRRORを作った話

はじめに

こんにちは。転職会議事業部でエンジニアをやっている落合です。最近、転職会議事業部では転職会議MIRRORという新サービスをリリースしました。

詳しくは以下のプレスリリースをご覧ください。

prtimes.jp

私もエンジニアの1人として開発に携わっていたのですが、今回はMIRRORの開発プロジェクトチームにプロジェクトの流れや技術選定・気をつけていたことなどをインタビューしました。

新規サービスの開発の進め方や、リブセンスでのエンジニアの働き方の一例として参考になると嬉しいです。

インタビューに答えていただいた方

転職口コミサイト「転職会議」のエンジニアのみなさんと、開発プロジェクトのプロダクトオーナーの方にお話を伺いました。

転職会議では開発手法としてスクラムを採用しており、1つのスクラムチームにエンジニアが2〜3名と企画職のプロダクトオーナーが1〜3名アサインされて開発を進めることが多いです。

まずはMIRRORの開発に携わったチームメンバーを簡単に紹介します。

川上さん
- 今回のMIRRORプロジェクトのプロダクトオーナー。今年から転職会議に異動したにもかかわらず、上司からの~~無茶振り~~熱い期待でMIRRORの開発プロジェクトのプロダクトオーナーを担当。企画や仕様の検討、他チームとの調整、ワイヤーフレームの作成などを担当。
城川さん
- 今回のMIRRORプロジェクトのエンジニアの一人。フロントエンドの開発に強みを持っていることを活かし、ワイヤーフレームの作成および、フロントエンドの開発を担当。
仁科さん
- 今回のMIRRORプロジェクトのエンジニアの一人。サーバーからフロントまで幅広く開発を担当。
浜田さん
- 今回のMIRRORプロジェクトのエンジニアの一人。サーバーからフロントまで幅広く開発を担当。
落合
- 私です。広く浅くなタイプなので、フロントからインフラまで幅広く開発タスクを担当していました。

MIRRORというサービスや、サービスを作ることにした経緯

落合：早速ですが、MIRRORというサービスを作ることにした背景を教えてください！

川上：昨年までは転職会議は求職者向けの機能開発に力を入れていました。どの会社に入るかを検討するための機能や、転職会議内で求人を探せるようにしたり転職会議内でいい企業を探せるようにするための機能を重視して開発していました。

今年からは求職者だけでなく、積極的に採用活動をしていきたい企業に向けても価値提供をしていきたいと思っています。

転職会議の口コミは社員からみた企業の実情が集まっていると思っていて、その実情をみて自分たちの直すべきところや良いところに気づいてもらい、より良い会社を作るために転職会議と企業が一緒になって企業を改善していくような未来を作るために、MIRRORというサービスを立ち上げることにしました。

城川：転職会議としては中立的な立場で求職者にも幸せになってほしいし、企業側にも組織改善を通じて幸せになってほしい、という思想があるので自然な流れで生まれたサービスだと思います。

落合：今回のMIRRORのリリースはβ版という位置付けですが、具体的にはどんな機能を作ったんでしたっけ？

川上：いきなり組織改善のための機能を作るのではなく、まずはニーズが大きい採用ブランディングの一環として、企業側からも転職会議上から情報を発信してもらえる機能を開発しています。集まった企業への口コミに対して返信をしたり、企業側が口コミをピックアップして企業の評判ページに表示できるようにすることで、正確な情報や企業がアピールしたい情報を伝えられるようにしています。

仕様の決定から、実装までの流れ

城川：正式にプロジェクトが発足したのは1月からでしたが、11月ごろから準備は始まっていました。プロジェクトのきっかけとして、転職会議の事業内新規サービスとして提供したい企画の草案があったのですが、その企画を実装可能な要件に落とし込む作業をプロダクトオーナー側でやれる工数がなかったんですよね。

だから、いったん僕と落合さんの2人の工数を割いて、その時点で検討されていた抽象的な企画に対して、技術的な制約等も踏まえた上で実現可能性が高い開発内容を検討しました。

それぞれの機能について要件を具体化できたところで、プロジェクトメンバーの人数などを検討していただくために、開発工数の試算や粗い粒度でのタスク洗い出しなどを行いました。他のプロジェクトの仕事もしながらでしたが、この作業に大体1ヶ月半ぐらいかかっていた感じですね。

落合：このプロジェクトは『4~5月に最初のリリースを実施してクライアント企業の方の反応を見たい』という事業部としての希望があって、最初のリリースをしたい時期が決まっていたんですよね。

なので、プロジェクトを本格的に始める前に仮でもいいので開発に必要なタスクと開発に必要な工数を出して、どの機能を最初のリリースに含めるのか議論するためのたたき台を作った感じでしたよね。ここら辺は、結構うまくいった感じありましたよね。

城川：そうですね。この時期はプロダクトオーナー側もかなり忙しかった時期だったので、比較的当時のプロジェクトの状況が落ち着いていたエンジニアが職域を越えてタスクを巻き取れたのはいいことだったんじゃないかなと思います。

落合：1月から正式にプロジェクトが発足して、ここから川上さん、仁科さん、浜田さんにプロジェクトに入っていただきましたよね。この時期は12月に作った仕様を元に開発内容や設計をさらに精緻化していったと思うんですが、どのように進めていったんでしたっけ？

城川：目の前のやることが決まっている開発作業にまず着手するというより、まず開発の流れを止めてしまうようなタスクを優先して対応するように進めていきました。

この時点では実装したい機能は決まっていても、画面の構成やデザインが決まっていなかったので、川上さんと一緒にできるところからワイヤーフレームの作成作業を進めていました。

それと並行して、エンジニアだけで開発が進められるバックエンドのAPIや開発環境のインフラについては、先行して実装を進めていましたね。川上さんは1月から転職会議事業部に異動してきて、何もかも初めてだったと思うので最初から全て任せるのではなく、自分と二人三脚でワイヤーフレームを作ってもらいました。

川上：何もかも初めてだったのですが、うまく仕事を進められたんじゃないかなと思っています。当時はプロジェクトチームに企画担当が3人いたので、それぞれが何のタスクをやるかは手探りだったと思います。

そこで『川上にはまずワイヤーフレームを作ってもらう』という役割が与えられたことで、自分が責任を持ってやる仕事が明確になって仕事がやりやすかったです。ワイヤーフレームも今まで書いたことがなかったのですが、城川さんが最初はつきっきりで一緒に作ってくれたので作業が進めやすかったです。

城川さんがすぐ相談できるところにいてくれたことで、実装面で不必要な工数がかかる画面設計になってしまうことを避けることができました。

城川：この時期は自分と落合さんって全然別のタスクをしていた気がしていて。この時って落合さんは意識していたことってあるんですか？

落合：そうですね。デザインとかフロントエンドの領域は城川さんのほうがスキルは高いし、城川さんと川上さんがワイヤーフレームを作ってくれているのはわかったので、スクラムイベントがしっかり回るように仕組みを整えるとか、スクラムマスター的な部分を巻き取って画面設計の作業に集中してもらうことは意識していましたね。

あとは並行して画面設計が関わらないバックエンドやインフラ構築の開発はあったので、そこを仁科さんや浜田さんと分担して進めていました。2月、3月はどんなことをしてましたっけ？

城川：その辺りは作成したワイヤーフレームをもとにデザイナーさんにデザインを作ってもらったり、作ってもらったデザインをもとに開発タスクを追加・修正したりという細かい作業が多かった印象ですね。

落合：あとは、デザインや開発タスクの修正が終わった段階でもう一度タスクのポイント見積もりをやり直して、今のペースで本当に計画通りリリースができそうか？を再確認していましたけど、要件や仕様が大きく変わることもなく、淡々と開発を進めていった感じですよね。

城川：このあたりは11月から1月までの準備がうまくいっていたので、大きなトラブルなくスムーズに進めることができましたね。

エンジニアと他職種との関わり方

落合：エンジニアにとって、他職種で一番関わりが多いのはプロダクトオーナーだと思うのですが、どのようにコミュニケーションをとっていましたか？

城川：MIRRORプロジェクトではアジャイルのスクラム開発の型に則って開発していたので、基本は各スクラムイベントやSlackなどのチャットツールを使ってコミュニケーションをとっていましたね。

落合：スクラムにしたところも、今回のプロジェクトの体制や前提を踏まえた上でスクラムを使って開発するのが本当にいいのか一度検討した上で決めましたよね。

城川：そうですね。今回はリリースしたい期日が決まっていたので、ポイントを見積もって1スプリントあたりのベロシティを計測することで開発完了日の予測がたてやすいこと、スクラムイベントがあらかじめ定義されていることでコミュニケーションの頻度を担保しやすいことあたりがやっぱり魅力的だろうということで、今まで通りスクラムを使うことにしましたね。

浜田：既に他のプロジェクトでもスクラムを使っていてエンジニアが慣れていたこと、部署のエンジニアの中にスクラムマスターの資格を持っている人がいたことも大きかったですよね。

落合：プロダクトオーナーとはスクラムイベントなどで定期的にやりとりしてましたが、デザイナーさんとの関わり方で工夫したところはあります？

城川：プロジェクト開始当初は事業部でデザイナーが1人という状況で他のプロジェクトのデザインも並行して進めてもらう必要があったので、スクラムチームに入ってもらうのではなく、スクラムチームが作った要件やワイヤーフレームをもとにデザインを作ってもらうといった関わり方をしましたね。

ワイヤーフレームを作るツールもデザイナーさんが普段使っているFigmaに合わせたりなど、デザイナー側でプロジェクト側に合わせるような負担は少なく済ませるようにしていました。

コミュニケーションで気をつけていたこと

落合：1月から正式にプロジェクトが発足して、ここから川上さん、仁科さん、浜田さんにプロジェクトに入っていただきましたよね。この時期は初対面の人もいるし、作るものもまだよくわからないし、って状態だったと思うのですがコミュニケーション回りで工夫したところ、うまくいったところってどこでしたか？

城川：僕らで作った仮の要件や設計、開発タスクの読み合わせもやっていましたが、一番大きかったのは川上さんのオンボーディングがスムーズに終わったことだと思います。川上さんに早いうちから1つ大きめの仕事をお任せして、そこを主体的にリードしてくれたので、そこがすごく良かったポイントかなと。

落合：川上さんは1月から転職会議事業部に異動になって、転職会議事業部の組織やシステムの中身のことを何も知らない状態だったと思うのですが、この1月にどういうことをやっていたかとか、オンボーディングでありがたかったこととかを教えてもらっていいですか？

川上：城川さんと同期ということもあって、『困ったら言ってね』という雰囲気は元からあったんですが、細かいちょっとした疑問を言う機会って最初は無くて。リブセンスはtimesという分報をする社員が結構いて、文化的にも根付いていたので自分用の分報チャンネルを作って困ったことをつぶやいたりしていました。

timesでは小さな思いつきの言葉も言えて、細かい疑問も投稿してからすぐ誰かが答えてくれたり、チームメンバーが心理的安全性を高めてくれたのでやりやすかったです。あとは、デイリースクラムの中で相談タイムを作ってくれたのも大きかったですね。

スクラムボードの中に相談事項レーンを作っておいて、急ぎではない相談はそこにチケットを貯めておいてデイリースクラムのタイミングで話し合ったり疑問を解消したりするという運用をしたことで、カジュアルに質問できる雰囲気、出てきた疑問をちゃんと解消できる雰囲気を作ってもらえたことが、キャッチアップが早く進んだ理由の一つだと思います。

落合：城川さんこの辺り気をつけていたことってあります？

城川：特にこのプロジェクトだから気をつけていたことはあまりないですね。前々から意識していた、得られた知見やハマったポイントを個人だけの知識じゃなくてチームの知識にするためにドキュメントをちゃんと書く、なるべくオープンな場所でコミュニケーションする、ということは気をつけていましたね。

あとは川上さんが言ってくれたオンボーディングぐらいしか気をつけてないですね。仁科さんも浜田さんも元から転職会議事業部で働いてくれていて、道の上の障害物をどかしていけば勝手に開発速度が上がっていくことはわかっていたので。

仁科：あとは、スクラムボードに相談事項レーンを作るとか川上さんにtimes作ってもらうみたいな仕組みの部分も、本当にうまくいく仕組みなのかとかは深く考えずにダメだったら止めればいい精神でいったんやってみるという考え方にしたのは良かったと思います。

落合：結果ダメだったものは撤廃しましたし、運用して良かったものは自然とプロジェクトチームの習慣・仕組みとして定着しましたしね。

使用したツールや、使い分け

落合：開発の中でどんなツールを使っているかや、ツールの使い分けを教えてください。

城川：今回は新しいツールを入れることはせず、今まで使っていたツールやサービスを使っていましたね。まず、企画や仕様に関するドキュメントはConfluenceを使って管理していました。

マスタとして運用する資料については特に念入りに更新することも心がけていましたね。あとは文字だけだと表現しづらいような部分はFigmaを使っていました。

仁科：自分が1月から入ってきたのですが、落合さんや城川さんが要件や仕様をあらかじめConfluenceにまとめてもらっていたので助かりました。要件も大項目、小項目に分かれていて最初に開発したい内容を理解したり、開発途中で作る内容を確認したりする時にこれらの資料が役立ちました。

浜田：スクラムのチケットはGitHub + ZenHubでスクラムボードを作って運用していました。うちのチームはZenHubをスクラムのタスク管理の中心として使っていますよね。GitHubとの連携もしっかりできるし、チーム内でも使い慣れていましたし。

城川：あとはスクラムの振り返りでは、miroも使ってましたよね。

落合：リブセンスでは全社的にリモート環境で働いていてほとんど出社しないので、物理的なホワイトボードが使えないんですよね。miroだと付箋を貼ったり、ボードを複数人で同時に編集できたり、会議でインタラクティブにコミュニケーションするには便利だったと思います。

文書を構造的に整理することは難しいので、議事録を取る必要がある会議で使うには向いていないと思うけど。

技術選定や技術的に工夫したポイント

落合：技術選定や、技術的に工夫したポイントを教えてください。

城川：フロントエンドはReactとNext.jsで構築しています。状態管理はデータのキャッシュ効率の最大化を狙って、Reduxを採用しています。ちゃんとRedux公式が推奨している設計を調査・理解した上でそれに沿って開発できたのは良かったと思います。

仁科： 技術選定の背景などをちゃんとドキュメントに残せたのは良かったと思います。仮に今いるエンジニアが全員いなくなったとしても、その場にいるエンジニアがなぜその技術を採用したか理解できるので。

城川：バックエンドはどうでしょう？

浜田：バックエンドは転職会議で普段使っている技術を踏襲して、RubyとRailsで開発しました。再利用できるモジュールも多かったので、そういうのを最大限利用して効率よく開発を進めるといったコンセプトだったと思います。

今回は認証認可が一般的な形とは違った形になっているのですが、その辺りは開発チーム内でしっかりと議論した上で決められたかなと思います。

落合：インフラについてだと、転職会議のアプリケーションはEKS上に作られているので割とテンプレに沿った形でmanifestを書くだけでさくっとインフラ環境を作ることができましたね。

AWSのリソースについてもTerraformで管理しているので、こちらもtfファイルに必要なリソースを追記すればアプリケーションエンジニアでも簡単にAWSのリソースを追加・変更できる状態でした。こういう環境が整っているのは開発を効率的に進める上ですごく助かりました。

城川：早い段階で、サービスで使用するURLはまとめて定義しちゃったんですよね。URLはプロダクトオーナーとか事業部外の分析基盤を開発しているチームとかに連携する必要があったので、複数のステークホルダーが関わりそうなところは先に決めておくという進め方は今振り返ってみると良かったですね。

他にはAPIのインターフェースなどについては慎重に決めてましたよね。

仁科：RESTの一般的な方式で開発していくと言うのはみんな合意できていたし開発経験もあったけど、今までの転職会議の開発でリソースを変更するようなRESTのAPIが必要になることがあまりなかったから、どんなインターフェースにするかなどは改めてベストプラクティスを調査したり、他のサービスのエンドポイントを調べたりしながら話し合って決めていきましたよね。