技術改善は未来への投資 〜技術的負債に向き合い“続ける“ための取り組み〜

■イベント
エンジニアリングの舞台裏 〜価値を追求する設計と改善の取り組み〜
https://sansan.connpass.com/event/309786/

■発表者
技術本部 Strategic Products Engineering Unit Contract One Devグループ
原 圭介

■Contract One 開発エンジニア 採用情報
https://media.sansan-engineering.com/contractone-engineer

Transcript

1. Sansan株式会社 部署 名前 技術改善は未来への投資 Sansan技術本部 技術的負債に向き合い“続ける“ための取り組み Sansan株式会社 技術本部 Strategic Products Engineering Unit Contract One Devグループ 原 圭介
2. 原 圭介 Sansan株式会社 技術本部 Strategic Products Engineering Unit Contract One Devグループ - 2020年にSansan株式会社に⼊社。 - 最初はEightのグロースを担う開発チームでエンジニア として従事。 - 新規事業系の部署に異動し、SmartエントリーやSmart パンフレット、Seminar Oneなどのイベントテック事業 向けのプロダクト開発に複数携わる。 - 現在はContract Oneでリードエンジニアとして技術改善 活動を推進しながら新機能開発のプロジェクトリーダ ーなども兼任。
3. Contract One とは？
4. 契約データベース「Contract One」とは Contract Oneは、あらゆる契約書を正確にデータ化し、契約データベースを構築。 法務部⾨に限らず、全社員が契約情報をビジネスで活⽤できるようにすることで、 さまざまな部⾨の課題を解決するサービスです。
5. 開発組織 Webエンジニア （複数チームで分割） Contract One Dev グループ 約 20 名 プロダクトユニット PdM・デザイナー 研究開発部 AIなどの技術提供 Digitization部 データ化周りの オペレーション 2024/02/19 時点
6. 技術的負債に向き合い続ける話
7. 僕がContract Oneに来る直前 - ゆるふわアプリケーションアーキテクチャで実装⽅法がみんなカオス - みんな⼀⼈⼀⼈の⼼に、みんなそれぞれのアーキテクチャがある(たぶん) - きっとDDDっぽいことをやりたかった雰囲気だけ残ってる… - テストコードがまともに動かない - そもそもローカルPCでもCI環境でもまともに動かない - 動いたとしてもテストコード実⾏が延々に終わらない - たまに落ちる謎テスト(フレーキーテスト) - まともに動かないから失敗しているテストが放置(テストコードとは？) - ビルド時間⻑すぎてステージング環境へのデプロイがかなり待たされる - 1回で20~25分くらいだった気がする… - ３チームくらいあるのにステージング環境が１つしかない - 少なすぎてみんなで環境を取り合う 機能開発を優先しすぎていた結果、かなりの技術的負債が放置状態 - アプリのヒープメモリ、CPU、DBコネクションプール、最⼤同時接続数、スレッド関係など の基盤周りのパラメータが適当に設定されたまま放置 - 負荷のかかり⽅によってシステム全体のパフォーマンスが落ちる - インフラやアプリのパフォーマンス監視をしていない - CPUやメモリの使⽤率がどうなってても、アプリのレイテンシがどうなっても放置 状態。ユーザからの問い合わせでやっと気づく - パフォーマンスに問題があっても、それを分析する仕組みがない - 各運⽤作業において煩雑な⼿作業が多い - ⼤事な開発時間が奪われてしまう - 既存のORMが使いづらく、データベースへアクセスするための実装が⾯倒 その他いろいろ (恥ずかしくてあんまり⾔えない)
8. - 事業開始からしばらく経って、多数のお客様、多数の契約書を取り扱う ⽴場になってきている - システム品質への責任が⼤きくなってきている - まだまだ実装したい機能がたくさんあって、競合他社との競争もある - 開発の⽣産効率は下げれない、というか上げたい 技術改善チームの⽴ち上げ 技術改善チームを発⾜（当時は3⼈が専任）
9. - 事前に何⼈かに現状をヒアリングし、聞くべきカテゴリをある程度絞る - これがないとアンケート設問数が爆発する - 意味のない設問が増えて、分析や考察が困難になってくる - 主に以下のデータを収集 - 満⾜度を中⼼とした定量的なデータ - コメント記⼊欄などの定性的なデータ 開発者アンケートを実施
10. アンケート結果を考察 例えば…
11. これを各カテゴリに対して⾏った結果を⾒て、コメント記⼊も併せて考察する アンケート結果を考察
12. ⼯数感やインパクトを加味しながら、どの課題を選び、それをどれくらい改善していくかを決める 技術改善チームでディスカッション(優先順位をつける)
13. もくもくと技術的負債を返済していく - 新しいアプリケーションアーキテクチャの導⼊ - アーキテクチャの策定 & 開発ガイドラインの作成 - 導⼊のための勉強会を開催 - 設計・実装のレビュー ＆ サポート活動 - 設計ドキュメントのフォーマットと運⽤ルールの策定 - テストコード周り改善 - そもそもまともに動いてなかったため修正 - フレーキーテストの撲滅と警告の仕組み導⼊ - CIテストの実⾏時間短縮 - GithubActionsの導⼊ - テストレポートの導⼊ - 新たな開発環境の増築 - BE＆FEのライブラリ⼀⻫バージョンアップ - ヒープメモリ、CPU、DBコネクションプール、最⼤同 時接続数、スレッド関係などの基盤周りのパラメータ の調整 - インフラとアプリのシステムメトリクスの⼀元管理と 分析の仕組みを導⼊ > システムのパフォーマンス監視の仕組みも導⼊ - 開発チームごとにデータベースが持てるように改善 - 新しいORMの導⼊ - 運⽤作業を簡略化するための社内Webアプリの開発 - FE単体でローカル動作確認できるように改善 その他、いろいろ…
14. - アンケートだけでは、エンジニアの「気持ち」しか汲み取れない - 改善をやり続けた後の実際の効果がわからない - 定量的なデータを収集して考察したりできない - 改善策を企画する際にも、説得材料が⾜りない場合がある 開発者アンケートだけでは物⾜りない問題
15. SPACEフレームワークを採⽤して⽣産性指標を作成 - 5つのカテゴリで指標を検討して、なるべく指標どうしでトレードオフ関係を作り上げるもの （ 例: リリース回数 と １⼈当たりの開発時間 ） - 開発現場を多⾯的に観測して、⽣産性の向上をなるべく正しく観測する Contract Oneの⽣産性指標を作成 Satisfaction and well-being ⾃分の仕事、チーム、 ツール、⽂化に対して の満⾜度。 ⾃分がどれくらい健康 的で幸福であるか。 Performance 開発者が書いたコード は、期待されたことを 確実に実⾏したか。 Activity 作業の実⾏中に 完了したアクション またはアウトプットの数 Communication and collaboration メンバーやチームが どのようにコミュニケ ーションし、 協⼒し合っているか Efficiency and flow 中断や遅延を最⼩限に 抑えて作業を完了 または進⾏させる能⼒
16. Contract Oneの⽣産性指標を作成 現在Contract Oneで収集している指標（収集作業のほとんどは⾃動化） - Satisfaction and well-being - 開発者アンケート結果(満⾜度) - Wevoxの各種スコア - Performance - インシデント数 - 各チームの1⼈あたりの作業⼯数(⽉平均) - 各チームのポイント消化効率 - Activity - PRの数 - Communication and collaboration - ※ まだ収集できていない - Efficiency and flow - リリース頻度 - 各種リードタイム
17. ⽣産性指標で⾒た改善の結果
18. リードタイム ⽣産性指標で⾒た改善の結果 29%削減 (⽉平均 62.5 h → 44.2 h) ※ 回帰直線
19. リリース頻度 ⽣産性指標で⾒た改善の結果 リリース回数：2.3倍 全メンバー開発⼯数：1.7倍 (※ メンバー数が増えているので増えている) 約 1.35倍の効率化
20. これからの技術的負債への向き合い⽅
21. 技術改善チームを解散 各機能開発チームで改善していく⽅針に
22. - メリット - 機能開発だけでなく、システム基盤や開発環境もいじっていくので技術スキルが ⾝につきやすい - “機能開発の⼈”と”技術改善の⼈”との距離が無いので、施策の布教がしやすい - 開発メンバーに主体性が⽣まれやすい - デメリット - 機能開発に追われて、技術的負債を返済する暇が確保しずらい - ⻑期間で専任になる⼈を作りづらい 各機能開発チームで改善するとなると…
23. 機能開発に追われて、 技術的負債を返済する暇がない
24. - ⼤きめの改善策については各クォータの⽬標に盛り込んでいる - やらなければいけない強制⼒をある程度出す - 盛り込みすぎないよう、ほどほどに… - 開発時間のうち10~15%ほどを改善の時間にあてる - 「10~15%」はだいたいの⽬安 - 実際は各チームのリーダーが適宜時間を確保する > 機能開発との兼ね合いもあるので、状況次第でスプリントに⼊れないときがある 時間をどう確保する？
25. - UIコンポーネントライブラリの開発 - 今使っているSemantic UI がプロダクトのデザインに合わなくなってきた - 会社として共通のUIコンポーネントライブラリを持って、デザイン統⼀と⽣産性を向上させたい… - VRTの導⼊ - UI部品などの修正によって画⾯崩れなどがたまに出てくる… - バグの原因になりがちな機能のリファクタリング - DDDをベースにドメインモデルを定義して作り直したい… - 契約書の検索機能のパフォーマンス改善 - いろいろな項⽬をいろんな条件で検索するため、パフォーマンスを保つのが難しい… 「みんなで改善」はまだ始まったばかり… その他いろいろある…
26. これからも頑張ってく！
27. 最後に… We are hiring! Contract Oneは「技術で価値を魅せてくれる」仲間を募集しています！
28. Sansan 技術本部 募集ポジション紹介 https://media.sansan-engineering.com/