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

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

イントロダクション 自己紹介 谷合 啓輔 @posterkeisuke 株式会社ハイヤールー共同創業者兼CTO 新卒でレバレジーズ株式会社に入社後、複数の新規サービス立ち上げを経験。業務の傍ら同社 の新卒採用にも尽力した。その後Retty株式会社に入社しチームのスクラムマスターを経験。 在籍中の2020年12月に株式会社ハイヤールーを共同創業。 © HireRoo, Inc. SNS ● ● GitHub: poster-keisuke Twitter: posterkeisuke 趣味 ● ● サウナ（あまり開拓できていません。。。） 最近大学生ぶりにギターを弾き始めました 2

イントロダクション ハイヤールーの組織構成について ● ● 2020年12月にエンジニア3名で起業 ○ 2023/04/06日 現在、正社員で10名程度、業務委託メンバーを合わせると21名程度 ○ エンジニアはそのうち13名（役員を含む） ○ エンジニア全員が、サーバーサイド、フロントエンド、インフラまで一気通貫で開発できる ○ ただしサーバーサイド、インフラを得意領域とするメンバーが多い マイクロサービスアーキテクチャを採用、サービス数は30個弱 © HireRoo, Inc. ※2022年10月時点 3

Agenda サービス規模の拡大に起因する課題 1 リリース速度低下の原因 2 なぜハイヤールーは規模が小さい うちから対処しているのか 組織規模の拡大に起因する課題 スタートアップである故の速度とクオリティ エンジニアのためのサービス故のクオリティ 海外展開を見据えた組織とプロダクト 3 ハイヤールーで取り組んでいる具体 的な方法 自立型組織のためのアーキテクチャ アウトプットのクオリティ担保 4 未来を見据えて 5 まとめ 入社する人の期待値コントロール グローバル展開を見据えてやっていること

01 リリース速度低下の原因

リリース速度低下の原因 ● サービス規模の拡大に起因する課題 ○ 依存関係の複雑化によって仕様策定や、リリースまで（主に検証）の時間がかかる ○ 負債の蓄積により、単純な機能も複雑化する ● 組織規模の拡大に起因する課題 ○ 関係者の増加によって、コミュニケーションコストが増加し、意思決定のスピードが落ちる ○ スキルレベルの異なる人が増えることにより、コードの品質が落ちる © HireRoo, Inc. 6

リリース速度低下の原因① サービス規模の拡大に起因する課題 依存関係の複雑化によって仕様策定や、リリースまで（主に検証）の時間がかかる 特にモノリスのようなアーキテクチャの場合、 どこかの改修が別のどこかに影響するようなことが発生しやすい（デグレ） ● 例） ○ ○ 新規テーブル10-15個ほどのスキーマ設計に3ヶ月弱かかる ■ 大規模なシステムに関連するため、依存関係をしっかりしていないと影響が出てしまう ■ 関連する既存テーブルにデータを入れるべきか、新しく作るかなども考慮する必要がある 開発後、リリース前QAの項目が300-500 ■ ビジネスのワークフローに組み込まれているシステムなのでサービスダウンが許されない →逆にいえば依存関係を極力少なくすることができれば、小回りが効く © HireRoo, Inc. 7

リリース速度低下の原因① サービス規模の拡大に起因する課題 Design Payoff Line どのようなアーキテクチャを採用するかによって、開発効率が上がり事業の成長速度を加速することができる 参考: https://martinfowler.com/bliki/DesignStaminaHypothesis.html © HireRoo, Inc. 8

リリース速度低下の原因① サービス規模の拡大に起因する課題 負債の蓄積により、単純な機能も複雑化する サービスの規模が大きくなればなるほど、負債返済の時間的コストがかかる ● 例） ○ ○ ○ 大規模なシステムリプレイスに（構想から含め）2-3年かかる 秘伝のタレとなっている古のソースコードを解読するのに相当な時間がかかる 毎回同じエラーが発生するものの、コードが複雑化していることによって原因の特定が難しい 特にエンジニアバックグラウンドがない経営者だと、 負債返済のコストがもたらすメリットについて把握できておらず、プロジェクトが立ち上がりにくいことも © HireRoo, Inc. 9

リリース速度低下の原因② 組織の拡大に起因する課題 関係者の増加によって、コミュニケーションコストが増加し、意思決定のスピードが落ちる ● 創業初期フェーズでのリリース回数 ○ β版リリースまではエンジニア3人でサービス開発していた ○ サービス数は当時 5-10個程度 ○ 3-5日に1回※メインリリースができる程度の速度感 ※顧客が新しい機能として利用できるくらいの粒度のリリースを指す ● 現在のフェーズでのリリース速度（創業から約2年） ○ フルタイムエンジニア8人程度 ○ サービス数は30個弱 ○ 現在は平均して1週間で1つくらい（細かいリリースの回数は増えている） 人が増えても開発速度が上がらないどころか下がる © HireRoo, Inc. 10

リリース速度低下の原因② 組織の拡大に起因する課題 スキルレベルの異なる人が増えることにより、コードの品質が落ちる ● ● 個人の問題 ○ 例） ■ コードリーディングに時間がかかる ■ 実装漏れによって、不具合が混ざった実装をしてしまう チームへの影響 ○ 例） ■ バグ修正にリソースを取られるようになる ■ 設計やディスカッション中に前提知識が揃っていないことで、意図しない設計が含まれる ■ 育成に時間が使われてしまう © HireRoo, Inc. 11

02 なぜハイヤールーは規模が小さいうちから 対処しているのか

なぜハイヤールーは規模が小さいうちから対処しているのか 1. スタートアップ故にリリース速度もクオリティも求められる ○ その先のスケールも見越して今から対処する 2. エンジニアのためのサービス故のクオリティ 3. 海外展開を見据えた組織、プロダクトのスケーラビリティを考慮する必要がある © HireRoo, Inc. 13

なぜハイヤールーは規模が小さいうちから対処しているのか スタートアップ故にリリース速度もクオリティも求められる © HireRoo, Inc. 14

なぜハイヤールーは規模が小さいうちから対処しているのか スタートアップ故にリリース速度もクオリティも求められる © HireRoo, Inc. 15

なぜハイヤールーは規模が小さいうちから対処しているのか スタートアップ故にリリース速度もクオリティも求められる © HireRoo, Inc. 16

なぜハイヤールーは規模が小さいうちから対処しているのか スタートアップ故にリリース速度もクオリティも求められる © HireRoo, Inc. 17

なぜハイヤールーは規模が小さいうちから対処しているのか 1. スタートアップ故にリリース速度もクオリティも求められる ○ その先のスケールも見越して今から対処する 2. エンジニアのためのサービス故のクオリティ 3. 海外展開を見据えた組織、プロダクトのスケーラビリティを考慮する必要がある © HireRoo, Inc. 18

なぜハイヤールーは規模が小さいうちから対処しているのか エンジニアのためのサービス故のクオリティ “ Our Mission すべてのエンジニアが正当に評価さ れ、個々の力が最大限に発揮できる世 界を実装する。 © HireRoo, Inc. 19

なぜハイヤールーは規模が小さいうちから対処しているのか エンジニアのためのサービス故のクオリティ ● エンジニアのためのサービスと謳っているので、我々が見本とならなくてはならない ○ ● それ故、質も速度も妥協できない エンジニア組織も投資対象とみなして積極的に投資している ○ エンジニアの創業者がエンジニアのために作った会社でありプロダクトである ○ セールスでもマーケティングでもなくプロダクトが強みの会社である ○ プロダクトで勝つ会社であるが為に、ここでは負けられない © HireRoo, Inc. 20

なぜハイヤールーは規模が小さいうちから対処しているのか 海外展開を見据えた組織、プロダクトのスケーラビリティを考慮する必要がある ● マーケットの本場は北米やヨーロッパ圏であるため、海外展開は必然的 ● またサービスの特性上、海外展開も比較的しやすい ● ただし海外展開のためには、組織プロダクトともにスケーラビリティが求められる © HireRoo, Inc. 21

03 ハイヤールーで取り組んでいる具体的な方法

リリース速度低下の原因（再掲） ● サービス規模の拡大に起因する課題 ○ 依存関係の複雑化によって仕様策定や、リリースまで（主に検証）の時間がかかる ○ 負債の蓄積により、単純な機能も複雑化する ● 組織規模の拡大に起因する課題 ○ 関係者の増加によって、コミュニケーションコストが増加し、意思決定のスピードが落ちる ○ スキルレベルの異なる人が増えることにより、コードの品質が落ちる © HireRoo, Inc. 23

ハイヤールーで取り組んでいる具体的な方法 ● サービス規模の拡大に起因する課題 ○ 依存関係の複雑化によって仕様策定や、リリースまで（主に検証）の時間がかかる ■ →①自律型組織のためのアーキテクチャ採用とバリュー定義 ○ 負債の蓄積により、単純な機能も複雑化する ■ →②基盤への投資と、負債返済の時間確保 ● 組織規模の拡大に起因する課題 ○ 関係者の増加によって、コミュニケーションコストが増加し、意思決定のスピードが落ちる ■ ①自律型組織のためのアーキテクチャ採用とバリュー定義 ○ スキルレベルの異なる人が増えることにより、コードの品質が落ちる ■ →③アウトプットのクオリティ担保 ■ →④入社する人の期待値コントロール © HireRoo, Inc. 24

ハイヤールーで取り組んでいる具体的な方法① サービス規模の拡大に起因する課題 （再掲） 依存関係の複雑化によって仕様策定や、リリースまで（主に検証）の時間がかかる 特にモノリスのようなアーキテクチャの場合、 どこかの改修が別のどこかに影響するようなことが発生しやすい（デグレ） ● 例） ○ ○ 新規テーブル10-15個ほどのスキーマ設計に3ヶ月弱かかる ■ 大規模なシステムに関連するため、依存関係をしっかりしていないと影響が出てしまう ■ 関連する既存テーブルにデータを入れるべきか、新しく作るかなども考慮する必要がある 開発後、リリース前QAの項目が300-500 ■ ビジネスのワークフローに組み込まれているシステムなのでサービスダウンが許されない →逆にいえば依存関係を極力少なくすることができれば、小回りが効く。 どのようなアーキテクチャを採用するかによって、開発効率が上がり事業の成長速度を加速することができる © HireRoo, Inc. 25

ハイヤールーで取り組んでいる具体的な方法① 自律型組織のためのアーキテクチャ採用とバリュー定義 ● マイクロサービスアーキテクチャを採用 ○ 自律的に判断してリリースを行えるような組織を見据えた設計 ■ 逆コンウェイの法則「アーキテクチャのための組織を作る」 ○ 各人がオーナーシップをもって、判断できるような組織設計 ■ 各マイクロサービスにはコードオーナーが存在し、コードオーナーの許可なくリリースができない ● 「Fail Fast」精神をバリューに含め、チーム間で共有する © HireRoo, Inc. 26

ハイヤールーで取り組んでいる具体的な方法② サービス規模の拡大に起因する課題（再掲） 負債の蓄積により、単純な機能も複雑化する サービスの規模が大きくなればなるほど、負債返済の時間的コストがかかる ● 例） ○ ○ ○ 大規模なシステムリプレイスに（構想から含め）2-3年かかる 秘伝のタレとなっている古のソースコードを解読するのに相当な時間がかかる 毎回同じエラーが発生するものの、コードが複雑化していることによって原因の特定が難しい 特にエンジニアバックグラウンドがない経営者だと、 負債返済のコストがもたらすメリットについて把握できておらず、プロジェクトが立ち上がりにくいことも © HireRoo, Inc. 27

ハイヤールーで取り組んでいる具体的な方法② 基盤への投資と、負債返済の時間確保 ● ● マイクロサービスプラットフォーム（各サービスで共通する基盤となるもの）を利用する ○ KubernetesやTerraformの初期テンプレートを用意 ○ Datadogのアラート設定 ○ サービスのInitialize設定 負債返済を投資とみなし積極的に行う ○ 例） ■ インフラ基盤ををCloud RunからKubernetesを1Qかけて実施 ■ 現在フロントの基盤も移行中 © HireRoo, Inc. 28

ハイヤールーで取り組んでいる具体的な方法③ 組織の拡大に起因する課題（再掲） スキルレベルの異なる人が増えることにより、コードの品質が落ちる ● ● 個人の問題 ○ コードリーディングに時間がかかる ○ 実装漏れによって、不具合が混ざった実装をしてしまう チームへの影響 ○ バグ修正にリソースを取られるようになる ○ 設計やディスカッション中に前提知識が揃っていないことで、意図しない設計が含まれる © HireRoo, Inc. 29

ハイヤールーで取り組んでいる具体的な方法③ アウトプットのクオリティ担保（課題） ● アウトプットのクオリティに個人によってムラがある ○ 故に、システムの一部が誰かに依存してしまったりなどの問題生じがち ○ レビュー時に共通言語で会話できないなどによって、時間がかかる（実装の手戻りなども） ● 個人のスキルアップのための施策はあれど、やらない人がいる ○ チーム全体のレベルは一番レベルの低い人が基準となってしまう ○ チームのレベルを上げる必要がある © HireRoo, Inc. 30

ハイヤールーで取り組んでいる具体的な方法③ アウトプットのクオリティ担保 ● 誰が入ってきても開発速度が落ちないような基盤 ○ マイクロサービス開発時には、必要なセットが含まれているテンプレートを用意 ○ フロントエンドのアーキテクチャでは、ファイル生成、依存テストなどを自動化し、意図した通りにしかか けないような構造 ○ 各種ドキュメントの整備 ■ 開発環境のセットアップ ■ デプロイ方法 ■ ローカルでの開発方法など ● チームレベルのスキルアップ ○ 社内勉強会の開催 ■ チーム内でスキルの底上げを図ることによって、共通言語ができ、実装・レビュー時の効率化に ■ Lunch and Learnと第してランチタイムに話題を持ち寄ってスキルアップ ● 例) ○ アルゴリズムとデータ構造 ○ フロントエンド開発におけるベストプラクティス ■ 勉強会で利用したマテリアルや勉強会の動画は業務委託を含め誰でも閲覧可能 ○ OKRレベルで個人の成長を促す © HireRoo, Inc. 31

ハイヤールーで取り組んでいる具体的な方法④ 入社する人の期待値コントロール（課題） ● 学歴や前職の経歴だけで採用してみたものの、実際に手を動かしてもらったら期待と異なっていた ○ チームの士気が下がり開発速度の低下に ○ 再度そのポジションを埋めるための採用が必要 ○ 教育コスト © HireRoo, Inc. 32

ハイヤールーで取り組んでいる具体的な方法④ 入社する人の期待値コントロール ● 原理を知っている or 原理まで調べに行くような人であれば、現在開発経験がなくても採用する ○ 自社サービスを利用してコーディング試験を運用し、スキル面を担保 ● エンジニアはほぼ入社前に業務委託から入ってきてもらっている人が多い ○ 時給制ではなくタスクごとのpt × 単価による給与 ○ 優先度が低めだが、必要なタスクをその人の興味等をもとに決定 © HireRoo, Inc. 33

ハイヤールーで取り組んでいる具体的な方法⑤ （おまけ）グローバル展開を見据えてやっていること（課題） ● 国内需要だけではビジネスが成り立たなくなることがわかっている ○ それ故今後どの企業のどのビジネスも外資を稼ぐ戦略を取らざるを得ない ● 組織規模が大きくなってから社内の英語化で失敗している企業が多い ● 英語に抵抗がある日本人は多く、外国人（日本語が話せない人など特に）は採用できないか、コミュニケーション の問題で組織の立ち上げが難しくなる © HireRoo, Inc. 34

ハイヤールーで取り組んでいる具体的な方法⑤ グローバル展開を見据えてやっていること ● 最初からグローバルレベル動作するアプリケーション設計や開発、ベストプラクティスを取り入れる ● ドキュメントを最初から英語で作成 ● 社内のコミュニケーションの英語化 ● Slack上での会話 ● Daily StandupなどのMTG © HireRoo, Inc. 35

04 未来の開発組織を見据えて

未来の開発組織を見据えて 未来の開発組織を見据えて ● バグを生みにくいアーキテクチャ、バグにすぐに気づける体制 →ユニットテストのカバレッジ率を上げる リリース前のQAを導入してクオリティを担保する →適切なログや監視によって、先回りして異変検知 ● 必要な機能開発にフォーカス →分析基盤や顧客へのヒアリング結果などから、どの機能が使われているか、使われていないかを元に開発すべき項目の 優先順位を定める © HireRoo, Inc. 37

05 まとめ

Take Away 全体のまとめ ● ● ● ● ● 開発組織は大きく2つの理由でリリース速度が低下する ○ プロダクトの拡大に伴って、機能リリースまでの依存関係の複雑化や負債蓄積によるもの ○ 組織の拡大に伴って意思決定の長期化や、コードの品質が低下することによるもの ハイヤールーは海外展開を目指すスタートアップであり、エンジニアのプラットフォームであるが故に、リリース の速度も、クオリティも妥協できない そのため、設立2年の組織ですでに将来起こる組織課題を逆算して手を打っている ○ 自律型組織のためのマイクロサービスアーキテクチャと、会社のバリュー策定 ○ アウトプットのクオリティ担保のための、アーキテクチャ設計と各種ドキュメントの整備 ○ 基盤への投資と、負債返済の時間確保 ○ 入社する人の期待値コントロールのためのコーディング試験の徹底 ○ （グローバル展開を見据えて、最初から社内コミュニケーション英語化） 一方でまだまだ道半ば、理想の途中である ○ ユニットテストやログの監視によって、バグやインシデントに素早く対応できる ○ 不必要な機能開発を避け、顧客の求める機能開発にフォー化する これらを一緒に実現してくれる人を募集中です！ © HireRoo, Inc. 39

ご清聴ありがとうございました 40