エンジニア不足の中で どう技術的負債と向き合ったのか RevComm Research の場合 -

「技術的負債に向き合う Online Conference」 2023/11/21 の発表資料です。 https://findy.connpass.com/event/297813/

Transcript

1. Copyright © RevComm Inc. エンジニア不足の中で どう技術的負債と向き合ったのか - RevComm Research の場合 - 技術的負債に向き合う Online Conference by Findy
2. Copyright © RevComm Inc. contents 1. 自己紹介と会社 (RevComm) 紹介 2. 入社時の状況と当時の課題 3. 課題を解消するための戦略 4. 結果、そして現在の状況 5. Q&A
3. Copyright © RevComm Inc. 自己紹介 @keigohtr 2009年4月 富士ゼロックスにて自然言語処理の研究開発に 従事。 2017年11月 LINE Clovaチームに所属。機械学習モデルの 配信基盤プロジェクトをリードする。 2019年6月 ABEJAにてMLOpsの製品開発に従事。 2020年5月 Woven Planet HoldingsにてMLOpsチームのエ ンジニアリングマネージャー兼テックリードとしてチーム を牽引。 2021年12月より現職。 ２児の父。ホームオフィス沼作りにハマっている。Hazy IPA (クラフトビール) が好き。 3
4. Copyright © RevComm Inc. 弊社（RevComm）について 4 参考資料 会社紹介資料/Company Deck エンジニア向け_会社説明資料/Company Deck for Engineers
5. Copyright © RevComm Inc. MiiTel とは？ 5 参考資料 会社紹介資料/Company Deck エンジニア向け_会社説明資料/Company Deck for Engineers
6. Copyright © RevComm Inc. 成長しています！ 6 参考資料 会社紹介資料/Company Deck エンジニア向け_会社説明資料/Company Deck for Engineers
7. Copyright © RevComm Inc. 7 エンジニア不足の中で どう技術的負債と向き合ったのか
8. Copyright © RevComm Inc. 当時（2021年12月）のプロダクトの状況 • 約 35,000 人のユーザーを抱え、一日に数万件以上の商談を解析していた。 当時のチームの状況 • 私以外に４人のメンバーがチームに所属。 • 一人は完全な研究者で、論文を書くことが主な仕事。 • 一人は別チームとの兼務者で、当時は主に別チームで活動。 • 一人は研究者として働きつつ、開発も担当。 • 一人は開発者として働きつつ、研究も担当。 入社時の状況 8
9. Copyright © RevComm Inc. • 数十行の変更のプルリクのレビューに１週間以上かかる。 • プルリクをマージすると本番環境に出てしまう状況のため、プルリクをマージできない。 • CIが稀に良く死んでいる。さらにCIが死んだかどうかを知るすべがない。CIが動作することを祈るしかない。 • リリース作業は22時以降に実施することになっており、リリース作業はだいたい1時間かかる。 • 何かPythonのパッケージを変更（追加、削除、更新）した場合、リリース作業は数時間におよぶ。 • 機械学習の機能を含む巨大なモノリス。パッケージの依存関係が複雑に絡み合い、パッケージを変更できない。 • パッケージ管理ツールは使っておらず、ゆえにサービスがどのパッケージとバージョンを使っているか知らない。 • テストがほとんど存在せず、コードを変更したらリリース後に MiiTel を実際に動かして挙動を目視で確認する。 • ログにエラーが出ているが「これは常に発生するので無視して良い」というエラーもいくつか存在。 • サービスは正常に解析を終了したというステータス、しかし稀に隠れたエラーがあり解析が失敗している。 • 開発の日々のオペレーションコストが高すぎて、研究活動の時間がない。 • ドキュメントはほとんど存在せず、障害対応が属人化。 • チームメンバーが日々何をやっているかよくわからない。大量のslackチャンネルと大量のASANAボードがある。 • 負債を解消すべく方針を検討するも、飛び込んでくる計画外の仕事に忙殺されて負債の解消が進まない。 • チームのエンジニアリングにかけられる工数は、全員分を集めても１人分。 • etc... 当時の課題（一部） 9
10. Copyright © RevComm Inc. Note: 技術的負債の種類 10 アーキテクチャの負債 現在のアーキテクチャではビジネスが必要とする機能を構築するのが難しすぎる、あるいは ビジネスのユーザー数やパフォーマンス要件を満たせない。 コードの負債 ベストプラクティスに則っていないため、理解や保守が困難なコードになっている。 テストの負債 十分な自動テストがないため、コードベースの正しさをチームが確信できない。 インフラの負債 監視が十分でない、システムが堅牢ではない、メンテナンスが不十分。 ドキュメントの負債 ドキュメントが不十分、あるいは古くて不正確。 スキルの負債 チームメンバーがコードや周辺のインフラを保守・更新するのに必要なスキルが不足してい る。 プロセスの負債 チームの問題解決方法に一貫性がなく、ミスや遅延、コスト増につながる。
11. Copyright © RevComm Inc. 組織の観点 - 組織としての仕組みを整える チームの観点 - チームの体質を改善する 個人の観点 - 目の前の課題を解決する 課題を解消するための戦略 11 時間はかかるが、スケールする 時間はかからないが、スケールしない 💡 各観点を攻略する。 それぞれの観点は成果を収穫できる時期が異なるため、並行して実行する。 組織 チーム 個人
12. Copyright © RevComm Inc. 組織の観点 - 組織としての仕組みを整える チームの観点 - チームの体質を改善する 個人の観点 - 目の前の課題を解決する 課題を解消するための戦略 12 時間はかかるが、スケールする 時間はかからないが、スケールしない 💡 各観点を攻略する。 それぞれの観点は成果を収穫できる時期が異なるため、並行して実行する。 組織 チーム 個人
13. Copyright © RevComm Inc. 組織の観点で私が考えたこと • 我々が会社の中で果たさなければならない使命は何か？ • その使命を果たすためにどういう組織体制になっていなければならないか？ やったこと 1. チームのミッションとバリューを明確化 2. 未来の組織図を作成 3. JD (Job Description: 求人要項) の作成 4. 採用プロセスの見直し 組織の観点 13
14. Copyright © RevComm Inc. チームのミッションとバリューを明確化 14 💡 ワークショップを開催して、メンバー自身で自分たちのミッションとバリューを再認識した。 -> 上から与えられるのではなく自分たちで考えることで、自分の意見=当事者意識、となった。
15. Copyright © RevComm Inc. 未来の組織図を作成 15 💡 数年後の自分たちはどういう組織体制で働いているべきか「チームトポロジー」を基に設計した。 -> 自分たちの目指す状態がクリアになった。現在と未来のギャップが明確になった。 当時 未来
16. Copyright © RevComm Inc. JD (求人要項) の作成 16 💡 未来の組織に必要なコンピテンシーを明確にした。 -> ターゲットが明確になり、採用プロセスで見なければならない観点が明確になった。
17. Copyright © RevComm Inc. 採用プロセスの見直し（RevComm Researchのみ） 17 💡 面接内容を見直し、構造化面接を採用し、ソフトスキルとハードスキルを評価するように変更した。 各ステークホルダーから理解を得るために段階的にプロセスを変更した。 -> 面接での評価ポイントが明確になった。面接官同士のキャリブレーションもやりやすくなった。 当時 1. 面接 2. 面接 3. 面接 4. オファー 過渡期 1. スクリーニング by コーディングテスト 2. ハードスキルインタビュー by 服部 3. 上司面接 4. 役員面接 5. オファー 現在 1. スクリーニング by コーディングテスト 2. ハードスキルインタビュー by メンバー 3. ソフトスキルインタビュー by 服部 4. 役員面接 5. オファー
18. Copyright © RevComm Inc. 組織の観点 - 現在の状況 18 IC: 2 -> 9名 EM: 1 -> 3名 (2名) (5名) (1名) 💡 開発グループができた。 -> チームトポロジーに基づくことで、各チームの責任範囲が明確になった。 チームが必要とするコンピテンシーを持つメンバーを採用できた。 優れたエンジニアリングのプラクティスを導入できるようになった。 IC: 2 -> 8名 💡 研究グループができた。 -> 研究者が研究に専念できるようになり、競争力を安定して生み出せるようになった。
19. Copyright © RevComm Inc. 組織の観点 - 組織としての仕組みを整える チームの観点 - チームの体質を改善する 個人の観点 - 目の前の課題を解決する 課題を解消するための戦略 19 時間はかかるが、スケールする 時間はかからないが、スケールしない 💡 各観点を攻略する。 それぞれの観点は成果を収穫できる時期が異なるため、並行して実行する。 組織 チーム 個人
20. Copyright © RevComm Inc. 当時のチームは「個人の集まり」だった。属人化が高いため個人の裁量が大きくアジリティも高いというメリットがある 一方で、プロダクトの成長につれて個人の担当範囲が広がり個人の能力の限界を超えていた。 -> 「個人」から「チーム」になる必要があると私は感じた。 チームの観点でやったこと 1. 振り返りを導入する ◦ ２週間に１回、レトロスペクティブ ◦ ４半期に１回、Team health check 2. 情報を得るために必要なコストを減らす ◦ slackのチャンネルを統廃合した。 ◦ ASANAのボードを統廃合し、ひとつに集約した。 3. 暗黙知を形式知に ◦ ドキュメンテーションを推進。ADR、ポストモーテム、障害対応マニュアルの更新、など。 ◦ チケットに AC（達成条件）を含めるようにした。 4. 優先度を決める - やるべきことをやる。 ◦ KANBANを開始した。 ◦ EMが優先度を決定した。他部署からの依頼も優先度をEMが評価した。 チームの観点 20
21. Copyright © RevComm Inc. 振り返りを導入 21 💡 KPT (Keep / Problem / Try) を実施。KeepとProblemを書き出してもらい、投票により議論するトピックを決める。 トピックに対して実際にあった事実を書き出し、その事実の原因を議論する。 議論尽くしたあとに Try を書き出し、担当者を決めてコミットする。 -> 例えば「障害対応マニュアルの作成」や「huddle の常時接続」など色々な Try が実行された。
22. Copyright © RevComm Inc. チームの体質を改善するために私が最も意識したことは、チーム自身に課題感を持ってもらうこと。チームメンバーが課 題を発見し、チームメンバーが解決策を生み出すことで、チームに責任感が生まれる。 「振り返り」を繰り返すことで、チームは自己組織化する。 チームの自己組織化は、トップダウンの文化からは生まれない。 「振り返り」の中で↑の課題が選ばれたとき、そのときがチームが変化するタイミング。 変化を焦らない。改善を焦らない。焦ると失敗する。変化には忍耐が必要。 「振り返り」が最も重要 22 チームの観点でやったこと 1. 振り返りを導入する ◦ ２週間に１回、レトロスペクティブ ◦ ４半期に１回、Team health check 2. 情報を得るために必要なコストを減らす ◦ slackのチャンネルを統廃合した。 ◦ ASANAのボードを統廃合し、ひとつに集約した。 3. 暗黙知を形式知に ◦ ドキュメンテーションを推進。ADR、ポストモーテム、障害対応マニュアルの更新、など。 ◦ チケットに AC（達成条件）を含めるようにした。 4. 優先度を決める - やるべきことをやる。 ◦ KANBANを開始した。 ◦ EMが優先度を決定した。他部署からの依頼も優先度をEMが評価した。
23. Copyright © RevComm Inc. チームの観点 - 現在の状況 23 💡 ↑ は全部実行し、それぞれのチームで運用されるようになった。 -> 「振り返り」の体質を作ったことで、チームが継続的に改善できるようになった。 チームの観点でやったこと 1. 振り返りを導入する ◦ ２週間に１回、レトロスペクティブ ◦ ４半期に１回、Team health check 2. 情報を得るために必要なコストを減らす ◦ slackのチャンネルを統廃合した。 ◦ ASANAのボードを統廃合し、ひとつに集約した。 3. 暗黙知を形式知に ◦ ドキュメンテーションを推進。ADR、ポストモーテム、障害対応マニュアルの更新、など。 ◦ チケットに AC（達成条件）を含めるようにした。 4. 優先度を決める - やるべきことをやる。 ◦ KANBANを開始した。 ◦ EMが優先度を決定した。他部署からの依頼も優先度をEMが評価した。
24. Copyright © RevComm Inc. 組織の観点 - 組織としての仕組みを整える チームの観点 - チームの体質を改善する 個人の観点 - 目の前の課題を解決する 課題を解消するための戦略 24 時間はかかるが、スケールする 時間はかからないが、スケールしない 💡 各観点を攻略する。 それぞれの観点は成果を収穫できる時期が異なるため、並行して実行する。 組織 チーム 個人
25. Copyright © RevComm Inc. 個人の観点 25 アーキテクチャの負債 現在のアーキテクチャではビジネスが必要とする機能を構築するのが難しすぎる、あるいは ビジネスのユーザー数やパフォーマンス要件を満たせない。 コードの負債 ベストプラクティスに則っていないため、理解や保守が困難なコードになっている。 テストの負債 十分な自動テストがないため、コードベースの正しさをチームが確信できない。 インフラの負債 監視が十分でない、システムが堅牢ではない、メンテナンスが不十分。 ドキュメントの負債 ドキュメントが不十分、あるいは古くて不正確。 スキルの負債 チームメンバーがコードや周辺のインフラを保守・更新するのに必要なスキルが不足してい る。 プロセスの負債 チームの問題解決方法に一貫性がなく、ミスや遅延、コスト増につながる。 技術的負債の種類 やる。それだけ。
26. Copyright © RevComm Inc. （チームメンバーの功績も含みます） • AMI (Amazon Machine Image) ベースのリリースから、コンテナベースのリリースに変更。 ◦ 当時のサービスをそのままコンテナには移行できなかったので、分割しつつ段階的に移行。現在はコンテナ化。 ◦ 上記に伴ってマイクロサービス化を推進。 • 既存のリポジトリを「廃止予定」に位置づけ、新しいリポジトリを作成。新しいリポジトリではエンジニアリングのベストプラクティ スを導入。 ◦ モノレポ + ビルドシステム (pants) の採用。 ◦ CICDの自動化の徹底。 ◦ CODEOWNERSの設定、レビューによるコード品質の引き上げ。 ◦ DDDなどのプラクティスの導入。 ◦ テストカバレッジ 80% 以上。 • 負荷テストの導入と自動化。新しいリポジトリに移行するまでは、既存リポジトリのテスト負債は負荷テストで代替する。 • CICDの自動化および負荷テストの導入により、リリース時間をピークタイム（10:00 - 14:00）以外に拡張。ワークライフバランスが 改善。 • サービス監視を強化。不要なコードを削除。エラーハンドリングを改善。エラー監視条件を洗練。 • etc... 個人の観点 - やったこと＆現在の状況 26
27. Copyright © RevComm Inc. 当時の課題はこうなった！ • プルリクのレビューは基本的に当日中に終わる！ • プルリクをマージしても本番環境に出てしまわない。プルリクをマージできる！ • CIが生きている！動作している！ • リリースはピークタイム（10:00 - 14:00）を除けばいつでもできる！ • マイクロサービスはパッケージを変更できる！ • パッケージを管理している！サービスがどのパッケージのどのバージョンを使っているか分かる！ • 新しいコードベースはテストカバレッジが80％を超えている！ • 「これは常に発生するエラーなので無視して良い」などない！ • サービスは正常に解析を終了した！ • 研究チームが独立したので研究活動の時間が取れる！ • ドキュメントは充実してきた。障害対応の属人化は減ってきた。 • チームメンバーが日々何をやっているかわかる！ • 飛び込んでくる計画外の仕事も適切に優先度をつけて対応している！ • チームにエンジニアがたくさんいる！ • etc... まとめ - 今はどうなったか？ 27 💡 組織の観点、チームの観点、個人の観点で課題を攻略した。 組織体制を整え、チームの体質を改善しつつ、目の前の課題を解決した。 エンジニアの人数が足りないからこそ、３つの観点でやる必要がある。
28. Copyright © RevComm Inc. Thank you! 28