🌸 イベントについて

HireRoo（ハイヤールー）はエンジニア採用における、採用ミスマッチを防ぐためのコーディングテストサービスです。

エンジニア向けのサービスであるため、HireRoo を開発するエンジニア組織も投資対象であり、理想を求めて妥協せず試行錯誤を続けながら進めています。

本勉強会は記念すべき #1 として、HireRoo の中でも特にイチオシの内容を登壇者が話します。

🕖 タイムテーブル

🗣️登壇者

アイコン	名前	自己紹介
	Yuichi Ito	2018年新卒でレバレジーズ株式会社へ入社後、看護・介護職関連サービスのインフラ管理・改善、Q&Aサービスteratailにおけるインフラのパフォーマンス改善に従事していた。その後2020年12月に株式会社ハイヤールーを共同創業。
	Kosei Himeno	前職のドワンゴにてニコニコ生放送のWebフロントエンド開発を中心に担当。BFF（Backend For Frontend）をKubernetes上で稼働させるためのノウハウをハンドブックとして公開するだけでなく、OSSでTypeScript向けのOpenAPI Code Generatorなどを提供し、フロントエンド開発の足回りを整備することも守備範囲とする。
	Shuhei Shintani	大学卒業後1年間の独学を経て2021年7月にHireRooにJoin。コーディング試験サービス「HireRoo」の開発に従事し、システムデザイン形式や技術特化形式などの開発を主に担当。業務の傍ら競技プログラミングのコンテストに参加するなどエンジニアとしてレベルアップすべく邁進中。
	CTO Keisuke Taniai	新卒でレバレジーズ株式会社に入社後、複数の新規サービス立ち上げを経験。業務の傍ら同社の新卒採用にも尽力した。その後Retty株式会社に入社しチームのスクラムマスターを経験。在籍中の2020年12月に株式会社ハイヤールーを共同創業。

ℹ️ セッション詳細

マイクロサービス導入で起きがちな課題とその具体的な対処法

マイクロサービスを導入している人たちの中には、多様な課題があって「ちゃんと活用できています」と言えずに苦しんでいる人や、「俺達は雰囲気でマイクロサービスを使っている」と思っている人、「現状モノリスだけどマイクロサービスに変えたいがどんな課題があるかわからん」という人などがいます。

HireRoo は創業者がエンジニアであり、創業前に在籍していたメガベンチャーで様々なマイクロサービスの活用方法や課題の解消について経験しました。その経験を活かし、 HireRoo では「マイクロサービスで起きがちな様々な課題」について事前に打ち手を打っています。

本登壇では、一般的にマイクロサービスの導入でどういった課題が生じがちなのかご紹介しつつ、 以下のような HireRoo が具体的に対応した課題についてご紹介します。

• 管理するリポジトリが多い
• マイクロサービス雰囲気勢が環境やコードを壊しがち
• 新規開発をする際の初期化に時間がかかる

鋼の意思で実施した、技術的負債解消のためのリアーキテクチャ

もっと開発を早くできそう、もっと品質担保のためにできることがありそう、でもやるべきことが多すぎてどこがボトルネックになっているのかの調査も難しい。いつか余裕ができた際には、この「もやもや」を脱してより解像度が高い状態を目指し、改善を進めていきたいものの、時間がたてば立つほど、この「もやもや」は増えていってしまう。

HireRoo でも、少数のエンジニアでフロントエンドとサーバサイドの両方を担当して開発を行っており、開発速度の遅さや、品質担保の維持に漠然とした課題感、つまり「もやもや」を抱えていたことがありました。

本登壇では、HireRoo が抱えていた「もやもや」を技術的な負債として解像度を上げ、それらの負債に対して具体的にどのような対応を行ったか、アーキテクチャをどう変えて負債を生みにくくしたか、それらの対応にどの程度のコストがかかったのか、実際に経験した内容をお話します。

OSSの原理を理解しスクラッチで開発できるエンジニア文化とは

開発のスピードをあげるため OSS を活用することは多いですが、ビジネス要求と完全にマッチした OSS があることは少ないです。多くの企業では OSS と同程度のものをつくるのは時間がかかりすぎるので非効率と判断し、元々の要求を妥協するなどしてありものの OSS をそのまま使っています。しかし、本当に非効率で時間をかけるべきではないものなのでしょうか？

HireRoo はエンジニア組織として「原理の理解」をとても重要視しています。一見複雑に見える実装も実はシンプルな技術の組み合わせであることが多いので、技術的に妥協せずに読み解こう！という文化のもと、スクラッチで既存の OSS と同程度のものを自分たちで開発しています。

本登壇では、「共同編集機能」を実現する事例をもとに、ビジネス要求にマッチする既存の OSS がなかったところからどのように参考となるOSSを読解しスクラッチで開発をおこなったのか、どういう考え方や方針であればOSSと同程度のものを自分たちでつくるという判断を選択肢に入れることができたのか、具体的に HireRoo で実施した事例をもとにご紹介します。

将来起きる組織課題を逆算してつくったエンジニア組織と文化

事業が成功しエンジニアが増えていくと、コミュニケーションコストが膨大に増えることで開発速度が上がらなくなったり、担当者によってクオリティがバラバラになる、などの問題が発生しがちです。このような「エンジニア組織」の問題はエンジニアが増えれば増えるほど大きくなるものの、将来を見越して逆算して対処することは難しいです。

HireRoo はエンジニア向けのコーディングテストサービスであるため、それを開発するエンジニア集団は「開発速度やクオリティ、エンジニア組織としてのあり方」で妥協するわけには行かず、開発組織も投資対象としてみなし、理想をもとめて色々と試行錯誤し進めています。

本登壇では、サービスが急成長しつつグローバル展開も見据えた HireRoo が、将来を見越した上でどんなエンジニア組織をつくり、クオリティ担保や開発速度維持のためにどんなことを行ったのか、具体的に行った事例をもとにご紹介します。

📺 開催場所

オンライン（申し込みいただいた方に URL を共有します）