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

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

イントロダクション 自己紹介 新谷 修平 @s__shintani 大学卒業後一年間の独学を経て2021年7月にハイヤールーにジョイン。コー ディング試験サービス「HireRoo」の開発に従事し、システムデザイン形式 や実践形式などの開発を主に担当。業務の傍ら競技プログラミングのコンテ ストに参加するなどエンジニアとして成長すべく日々邁進中。 © HireRoo, Inc. 2

Agenda 1 スタートアップは既存のOSSを活用する しかない？ 2 既存のOSSを「あえて」使わずにフルス クラッチでライブラリを開発した事例 内製 vs OSS 初期フェーズのスタートアップが抱える課題 ドローイングツールの紹介 なぜフルスクラッチで開発することにしたのか？ コードリーディングと概念検証 ドローイングツールの設計と実装 3 技術に投資するハイヤールーのエンジニ ア文化 ハイヤールーが多くの機能をフルスクラッチで開 発している理由 ハイヤールーのエンジニアが大事にしている価値 4 まとめ 観

01 スタートアップは既存のOSSを活用するしかない？

スタートアップは既存のOSSを活用するしかない？ 内製 vs OSS ライブラリを自社で内製するケースと既存のOSSを活用するケースの比較 内製 OSS 開発費用 高い 低い 実装難度 高い 低い ビジネス要件の満足 要件を100%満たすものを作ることができる 要件を満たすOSSが存在するかどうかに依 存する → 開発コストの差からライブラリを内製するという選択肢は敬遠されがち → 既存ライブラリで実現できる範囲でビジネス要件を妥協することも © HireRoo, Inc. 5

スタートアップは既存のOSSを活用するしかない？ 初期フェーズのスタートアップが抱える課題 開発リソース ● ● 数人規模の開発メンバーでは1人で1プロジェクトを担当することも多い その分野のスペシャリストがいない場合は開発者自身がキャッチアップをしながら開発を行う必要がある リリース速度 ● ● PMFの前段階ではプロダクトを継続的に改善するためにはリリースサイクルを短くして顧客からのフィードバッ クを受けることが重要 大きめの機能開発でも着手からリリースまで1ヶ月程度が理想 → 限られたリソースの中でライブラリをフルスクラッチで開発するという選択は現実的ではない...? © HireRoo, Inc. 6

02 既存のOSSを「あえて」使わずに フルスクラッチでライブラリを開発した事例

既存のOSSを「あえて」使わずにフルスクラッチでライブラリを開発した事例 ドローイングツールの紹介 要件 ● ● ● ● ● ● 候補者は自由にエリア内にVMやSQLなど のコンポーネントを配置することができる VPNやサブネットといったネットワークを 表現できる コピーペースト、Redo/Undo、拡大縮小な どドローイングツールとして基本的な機能 が備わっている 共同編集モードでは候補者と面接官がリア ルタイムで同時に問題を解くことができる 候補者が問題を解いた過程をレポート画面 で再現できる 提出された回答は自動で採点される © HireRoo, Inc. 8

既存のOSSを「あえて」使わずにフルスクラッチでライブラリを開発した事例 なぜフルスクラッチで開発することにしたのか？ 内製 vs OSS 内製 OSS (React Flow) 開発費用 高い 低い 実装難度 高い 低い ネットワークの表現 ○ × 共同編集 ○ × 自動採点 ○ × → 既存のOSSはフローチャートを作ることに特化しておりビジネス要件にマッチしなかった → 将来的な拡張性を考えるとフルスクラッチで内製するリターンがコストを上回ると判断 © HireRoo, Inc. 9

• https://reactflow.dev/

既存のOSSを「あえて」使わずにフルスクラッチでライブラリを開発した事例 コードリーディングと概念検証 コードリーディング ● 類似のOSSライブラリのソースコードを読み、仕組みを理解する ○ How it works ■ フローチャートの状態の表現 ■ データの永続化 ■ 共同編集における状態の同期 ○ 参考にしたOSS ■ React Flow (https://github.com/wbkd/react-flow) ■ Excalidraw (https://github.com/excalidraw/excalidraw) 概念検証 ● ● 大きな手戻りを避けるためできるだけ早い段階で全ての要件が実現可能かどうかを検証したい 一週間程度で最低限動くプロトタイプを作成し、共同編集についても実現方法を把握した上で細部の実装に進んだ © HireRoo, Inc. 10

• https://github.com/wbkd/react-flow
• https://github.com/excalidraw/excalidraw

既存のOSSを「あえて」使わずにフルスクラッチでライブラリを開発した事例 ドローイングツールの設計と実装 全体設計 ● ● ● クライアント: React ○ チャートの状態はReactのStateとして管理され る ○ チャートはラベルや座標といった情報をもつ構 造体（Element）の有向グラフとして表現される サーバー: Firebase Realtime Database ○ 全ての操作ログが履歴としてFirebaseに保存され る ○ 共同編集ではFirebaseのイベントを監視すること でピアの変更を自身の状態に適用する 描画エリア: SVG ○ 配置可能なコンポーネントは全てSVG要素 ○ マウス操作がSVG要素に登録されたイベントを トリガーして操作内容をFirebase Realtime Databaseに送信 © HireRoo, Inc. 11

既存のOSSを「あえて」使わずにフルスクラッチでライブラリを開発した事例 ドローイングツールの設計と実装 Elementの構造 ● ● ● ● Elementには主にNode, Edge, Networkの3種類 が存在 Node ○ VMやロードバランサーといったコン ポーネントを表現する ○ ラベルや座標などを保持 Edge ○ コンポーネント間のリクエストの流れを 表現する ○ 両端のNodeのIDを保持 Network ○ VPNやサブネットといったネットワーク を表現する ○ Nodeと同様ラベルや座標を保持 © HireRoo, Inc. 12

既存のOSSを「あえて」使わずにフルスクラッチでライブラリを開発した事例 ドローイングツールの設計と実装 操作ログをFirebaseに保存する ● ● ユーザーがコンポーネントの追加や削除と いった操作を行うと特定のマウスイベントに 紐付けられたイベントハンドラが実行される コンポーネントを追加する関数（右コード） ○ 引数として渡されるElementのIDや座標 からFirebaseに保存する操作ログを生 成 ○ Undo/Redoができるように反転したオ ペレーションをスタックに保持 ○ Firebaseの特定のパスに生成した操作 を保存 © HireRoo, Inc. 13

既存のOSSを「あえて」使わずにフルスクラッチでライブラリを開発した事例 ドローイングツールの設計と実装 編集過程の再現 ● ● Firebaseから操作ログを全て取得し、時間 軸ごとにチャートの状態を復元すること で、候補者が問題を解く過程を再現 復元関数の処理内容 ○ 第一引数として渡される操作ログを 第二引数のatで指定された時間軸ま でループする ○ 操作の種類ごとにSwitch文で処理が 分岐し、操作内容に応じてチャート の状態を更新 © HireRoo, Inc. 14

既存のOSSを「あえて」使わずにフルスクラッチでライブラリを開発した事例 ドローイングツールの設計と実装 共同編集における処理競合 ● ● 複数人が一つのドキュメントを編集する際、ネットワークの遅延によって変更の適用順序が前後すること で、意図に反する変更が適用されてしまうこと 具体例 ○ abcというテキストをユーザーA, ユーザーBが同時に編集する ○ ユーザーAの変更が先に適用されるケース ■ ユーザーAが2文字目にEを入れる → aEbc ■ ユーザーBが3文字目にFを入れる → aEFbc ○ ユーザーBの変更が先に適用されるケース ■ ユーザーBが3文字目にFを入れる → abFc ■ ユーザーAが2文字目にEを入れる → aEbFc → テキストの状態がユーザーAとユーザーBの間で乖離してしまう © HireRoo, Inc. 15

既存のOSSを「あえて」使わずにフルスクラッチでライブラリを開発した事例 ドローイングツールの設計と実装 処理競合を解決する代表的なアルゴリズム ● ● OT（Operational Transformation） ○ Google Docsにも用いられている技術 ○ 中央集権的なサーバーがユーザー間で競合する操作をマージして別の操作に変換 CRDT（Conflict-free Replicated Data Type） ○ 中央集権的なサーバーを介さずにユーザー同士が直接操作内容を送り合う ○ 各操作は順序を入れ替えても結果が同じになる（可換） ○ それぞれのユーザーがピアの変更内容を自身の状態とマージ → 一時的なネットワークの遮断を除き基本的にはオフラインでの編集は想定していないので変更内容が上書きされる こともある程度許容できることを踏まえ、CRDTのコンセプトを参考に処理競合を解決する簡易なロジックを考案 © HireRoo, Inc. 16

既存のOSSを「あえて」使わずにフルスクラッチでライブラリを開発した事例 ドローイングツールの設計と実装 CRDTのコンセプトに基づいた共同編集の仕組み ● ● ● Firebaseを介して各ユーザーは操作内容を送り合う 操作は順序を入れ替えても結果が同じになる（可換）よ うに定義されている ○ 例えばElementを(0, 0)の位置からx軸方向に20移動 する操作とy軸方向に20移動する操作はどちらを 先に適用しても最終的に(20, 20)の位置に収束する 右図は以下の操作を相互に送り合っている ○ ユーザーAが(100, 100)の位置にSQLを配置 ○ ユーザーBがSQLをx軸方向に20, y軸方向に20移動 ○ ユーザーAが(200, 200)の位置にキューを配置 © HireRoo, Inc. 17

既存のOSSを「あえて」使わずにフルスクラッチでライブラリを開発した事例 ドローイングツールの設計と実装 エッジケースの対処①: 更新が競合するケース ● ● ● 同じタイミングでユーザーAがあるElementの名前を 「a」に変更し、ユーザーBが同じElementの名前を 「b」に変更する ネットワークには遅延が発生するため、相手の変更 が自身の変更の後に反映される 結果、ユーザーAのElementは「b」、ユーザーBの Elementは「a」となる → Last one winsで更新日時のTimestampが後の操作を優先 して適用する © HireRoo, Inc. 18

既存のOSSを「あえて」使わずにフルスクラッチでライブラリを開発した事例 ドローイングツールの設計と実装 エッジケースの対処②: 更新と削除が競合するケース ● ● ● 同じタイミングでユーザーAがあるElementの名 前を「a」に変更し、ユーザーBがそのElementを 削除する ユーザーBは自身が削除したElememtに対して後 から更新がかかる 更新対象のElementが存在しないためパニックが 起きてしまう → 削除時にElementを配列から物理削除するのではな く、deleted_atを書き込むなど論理削除にとどめること で、削除後のElementに対しても問題なく更新をかける ことができる © HireRoo, Inc. 19

03 技術に投資するハイヤールーのエンジニア文化

技術に投資するハイヤールーのエンジニア文化 ハイヤールーが多くの機能をフルスクラッチで実装している理由 コアとなる機能はフルスクラッチで開発 ● ● ● オンラインコード実行環境 オンラインIDE 共同編集可能なドローイングツール 公開されているAPIを利用してコードを実行したり、Visual Studio CodeのWeb Viewを利用するといった選択も考えられる が、あえて自社で開発している © HireRoo, Inc. 21

技術に投資するハイヤールーのエンジニア文化 ハイヤールーが多くの機能をフルスクラッチで開発している理由 初期コストはかかるが将来的に機能拡張が容易になったり、競合優位性につながる リターンが見込める 原理を理解してツールを作れるエンジニアの集団 内製 vs OSS 内製 OSS 開発費用 高い 低い 実装難度 高い 低い ビジネス要件の満足 要件を100%満たすものを作ることができる 要件を満たすOSSが存在するかどうかに依 存する 顧客のニーズに応え続けるためには拡張性のある自社ライブラリが最適 要件の水準が高くOSSで代替できないケースが多い © HireRoo, Inc. 22

技術に投資するハイヤールーのエンジニア文化 ハイヤールーのエンジニアが大切にしている価値観 フルスクラッチで開発することを後押しするエンジニア文化 ● ● ● 顧客目線 ○ 開発者目線ではなく顧客が求めているものを作る ○ プロダクトの品質に妥協しない Fail Fast ○ 例え失敗してもそこから学びがある限り賞賛される文化 原理を理解する ○ ツールを使うだけでなくツールを作れるエンジニアを目指す © HireRoo, Inc. 23

Take Away 全体のまとめ ● ● ● フルスクラッチでライブラリを開発するにはコストがかかるが、ビジネスのコアとなる機能であれば投資する価値 は十分にある 原理を理解しツールを使えるだけでなく作ることができるエンジニアを目指そう 保守的にならず複雑な課題にチャレンジしやすい環境を作るためにはそれを下支えする文化を育むことが大切 © HireRoo, Inc. 24

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