技術的負債返済の意義を考える、あの時の”やる・やらない”判断基準どうしてた？

技術的負債返済の意義を考える、あの時の”やる・やらない”判断基準どうしてた？

【再増枠】技術的負債返済の意義を考える、あの時の”やる・やらない”判断基準どうしてた？ - connpass

「事業観点から見る技術的負債の返済」 めもりー

事業進捗への妨げ

人数が増えてコミュニケーションパス、組織の変化など

チームを移動すると知らない領域が増えるので時間がかかる -> わかる

いかに労働集約から知的集約に寄せ、利益幅を大きくしていくか

BS, P/L

BS バランスシート上、ソフトウェア資産になっている
Profit and Loss 損益計算書で売り上げないし利益の伸長を計画し、損益分岐点を見極めるか

スタートアップと上場企業の戦い方

スタートアップはアセットが限られている。外部からアセットを調達する必要がある

上場企業では既存システムのランニングコストが課題になることが多い。PMF (Product Market Fit) して黒字化する成長期に課題となりやすい

ソフトウェア「資産」にまつわることなのでボードメンバー間で共有されている必要がある

「資産」なので監査会社からの監査対象になる

スタートアップだとメンバーが少ないので意思決定がスピーディ
上場企業は取締役会があるので時間がかかる

期中に返済を計画すると、事業計画との整合性が担保できなくなってしまう

課題認識と手段

スコープ

何を持って技術的負債とするか共通認識を醸成する（納得感ではない）
ゴールが見えないまま走っても気づいたら新たな負債を作っているまである

KPI を設定する必要もある。自分たちが今どの地点にいるのか

返済をブーストさせる

開発の妨げになっているものはできる限り排除する
どうやって一人一人の時間の余暇を捻出するか

開発者体験を向上させる

エンジニアリングと経営

エンジニア、ビジネス、コーポレートなどが三位一体となって、全体最適を考え、価値のある事業をしていかなければならない

いくつかある手段を全体最適から見て選択していく
「楽しく働ける」「クリエイティブなことができる」などの定性的な感情は不可欠。それらを満たせる環境を作っていくことが大切なんじゃないかなと

「技術的負債を楽しもう」吉田 俊明

Togetter の人か！個人開発からスタートした

リファクタリングは腕の見せどころ → わかる
入出力を変えない → ビジネスとは関係がない -> だから好き勝手できる！（それはそう）

エンジニアリングに没頭できる

ビジネスではそうもいかない
負債返済のタイミングをビジネスの中でどう設定するか

リファクタリングをビジネスの中でどう設定するか -> 無視して勝手にやろう（ええ…）

お金をもらいながら強い技術力が身につく

タスク化せず120%達成として使う

マネジメント層は負債返済をタスクではなく評価ポイントとしてみる

「ファインディの4年に渡る技術的負債の返済」佐藤 将高

2020年大きな転換点
フルタイムエンジニア 5-6 名

backend/frontend の同時リリースが必須。ということはそもそも別々だったのか？

背景

1回目のリリースが大事だった、が。。。
DesignDoc としてコンテキストを残せなかった

新規開発が優先

取り組み

テスト文化の確立

テストの価値への理解不足はあるよなあ

デプロイ自動化

モノリス解体

Backend/Frontend の完全分離

サービスの3ヶ月完全停止 -> やっぱりコードフリーズはどこかで必要だよなあ…

フロントエンド刷新

インフラ刷新

リリース作業の完全自動化

GraphQL化

2024年

エンジニア60名程度

疎結合アーキテクチャ -> マイクロサービス化しすぎない

---

すごい開発サイクルが回っているなあ

現在の状況

• 定期的なリファクタリング
• テックリードによる改善活動
• 負債かもと思ったらすぐ課題にあげる
• 早めの決断、早めの投資
• コツコツと返済
• リスペクトも忘れず

日頃から掃除していれば大掃除はいらない -> それはそう

---

そもそも、技術的負債とは？

パネルディスカッション

• 返済をすることで更なる価値を生み出せるなら返済を進めるべき
• 作っているその時点から負債
  • 止まっていると負債化していく
• 技術選定の最適解
  • その時はよかった
  • 前提としてリスペクトや背景をきちんと理解する
• 意思決定の背景が書いていない
  • 大きな負債になりやすい

やるやらの判断基準

• 顧客への価値につながるところを最優先に
• 経営層への説明
• ライブラリのバージョンアップはあまり積極的にやらない
  • バグの原因になったりするため
• 勝手にやる小さなものと1ヶ月以上の単位で進めるものと

test を書かないとマージしない仕組みにした -> これは良さそう。まあ例外もあるだろうけど

Q. 技術的負債を返済した際のリターンを定量的に説明するのは難しいのでは？

• 失敗する可能性も許容する。いくつかパターンを考えて試しながら実績を作っていく
• サーバーコストの削減などわかりやすいものから

Q. 年6800件のデプロイ リリースルールとかは？エンジニアの裁量に任せている？

• ユーザーに届かなくてもエラーがない状態でデプロイし続ければ問題ない
• Feature flag などを活用。常にずーっとデプロイしている状態

Q. 負債返済と通常の機能開発チーム分けや配分について

• 1年規模で返済するぞ！って走った
• 専用チームを作ったが人員不足で新規開発から引っ張ってきたり
• 7:3 8:2 くらいで分けてる
  • 自分たちでバランスを探っていった