ログラスにおける技術的負債との向き合い方のこれまでとこれから
株式会社ログラス 伊藤博志さん
- 本質的複雑性と偶有的複雑性
- 偶有的複雑性の対処をする
- 開発生産性の3階層への影響
- プロダクト開発チームとは別に偶有的複雑性に向き合う組織
- 定期的なライブラリアップデート
- PostgreSQLの11から15へのvup
- 一部の集計をPostgreSQLからBigQueryへの移行
カミナシ、あれからどうなった？
株式会社カミナシ 原トリさん
- リリースから数年経って技術的負債がたまっていた
- 退職リスクの増加など
- 経営陣に説明して対処することに
- 作って終わりではなく老朽化していくと
- 1.5ヶ月新規開発を停止してリファクタリング
- その後は機能開発をしながら
- スプリントの50%を負債返済にあてると合意
- しかし50%もあてられなかった
- オーナーシップ持つ人がいなかった
- 負債返済の専門チームを作った
- CTOとゴールの認識をあわせてある程度効果は出た
- その後専門チームは解散
- 開発チーム
- PM/デザイナー/エンジニアのフィーチャーチーム
- 通常スプリント3wやったら負債返済スプリント1w
- その後
- 認証機能をメインアプリケーションから切り離し
- 1wの負債返済スプリントだとやれる範囲に限界がある
- 機能開発と同じようにバックログ管理
- 脆弱性
- 4段階に分類して対応までの期間をルール化
- AWS Security Hubの情報も
パネルディスカッション＆QA
- 技術的負債の見える化とエンジニアとビジネスのギャップ
- エンジニアからの視点とビジネスからの視点
- 伝えるタイミングが大事
- そのためには双方の状況を知っていること
- 技術的負債の返済効果をどこまで測るか
- 売り上げをベースに見るのは時間差があるし他の要因もあるから難しい
- 大規模なシステムで少しの改善でインフラコストや従量課金に反映される時は見やすい
- 効果を測る必要がないくらい当たり前にやっていけるのが理想
