技術的負債をコントロールする方法イベントに参加してきた

# 参加背景

# ログラスにおける技術的負債との向き合い方のこれまでとこれから

偶有的作業とは、本質的作業である要求以降のフェーズにおいて、
デコレートされていく余計なノイズのことを指す？　これで意味合いはあってるぽい

## Tech Value
・顧客への本質的価値の提供
・上記実現するための学びと適用
・技術的卓越性の追求と還元

の３つの活動原則。

## 負債の対局をとらえる
ソフトウェアの本質と偶有的複雑性　

ソフトウェア構築＝本質＋偶有的複雑性

言語名に使うとかビルドのために～みたいなことは、偶有的複雑性。
銀の弾丸はないっていうのは、本質的複雑性を減らせない。
偶有的複雑性ってのは、減らしても本質的ではない。
技術的負債の解消は、あくまでも偶有的複雑性を減らすこと。

### 開発生産性の３階層
レベル2の阻害要因のレベル１の部分が技術的負債のこと。
だから、本質的部分であるレベル２とかの阻害要因になっていないなら、
それは技術的負債として考えないってこと。

## 組織構造
分かれてるのではなく、イネイブラーたちがストリームに入り込んで支援。
イネイブラーが技術的負債の解消を行って、ストリームが本質部分を担当している。

チームが自律的に本質課題に向き合うために、イネイブラーQAたちが支援。

## フロントエンドのリプレイス
このときにリアクトにしてなかったら多分今苦労していただろうという話


## ライブラリアップデート
２週間に一回。
ライブラリをほぼ最新の状態に近い状態に保っている。

## ロジカルレプリケーションでDBのバージョンアップ
本番にリリースした後も
万が一問題があっても古い方にすぐに戻せるように可逆性を担保するようにした。

## 技術的負債にならないようなアーキテクチャを実現できていた
去年とあるDB集計のパフォーマンス劣化した。
その際に、集計クエリをDWH並行するという大規模な手術が必要であった。
でももともとオニオンアーキテクチャのスタイルを徹底していたからか、
たった１か月で実現できた。

## これからの取り組み
もとからオニオンアーキテクチャを徹底してるのもあり、リプレイスはできやすい。
しかしながらドメインの複雑な絡み合いがあり複雑化してきている。
２年かけての大規模なリアーキテクチャを計画中とのこと。

## 主観
要求定義の段階で、要望から要求へ洗練する工程を得ないことには、
余計なノイズだらけの本質的作業ではない偶有的作業ばかりになってしまう。
さらに偶有的作業の掛け合わせで、さらに技術的負債が爆発的に大きくなってしまうと感じた。

この意味でも、要求などの上流工程にて複数の品質特性軸による脅威モデリングを行い、脅威同士の関係性マップをしておくことが重要とおらためて感じる。


# カミナシ、あれからどうなった？

## あれとは、
2022/9で技術的負債解消のプロジェクト

5月に経営陣が負債解消の合意→２フェーズに分けて負債解消PJの着手

75%くらい運用フローなどに使っていて、１年半くらい新しいものにトライできていないというのが経営陣の課題意識としてあった。

6月に全社向けの説明会を行ってから、1.5か月間完全機能開発を停止
ビジネスロジックは絶対に触らない。
バックエンドを中心にパッケージ構造をシンプルに！→エンジニアの精神衛生がだいぶ改善した
　マンションの老朽化で喩えた

スプリントの半分を負債返済に充てるというルールを設けた。
しかしこの試みは完全失敗した。

結局、機能開発で半分、問い合わせ対応で半分という感じになっていた。
これは具体的な目標設定や責任者を置かずにルールだけで縛っていたから。


短期的な負債解消として、生産性向上効果の高い技術負債の特定(真因)とゴール明示化

通常の機能開発を１スプリント×３やったら、残りの1週間は内部品質改善スプリント
　これは一定機能したが、それ以上は機能しなかった

 

## 2023/7以降のかみなし
ID管理・認証機能をメインプロダクトから独立プロダクトとして分離を開始
これによって、コアドメイン(ID管理・認証機能)の負債解消がスムーズに進むようになった。

関心の分離の徹底

## 各チームの取り組み
リスク評価　リスクマトリクス対応方針の策定
Findingsへの対応ポリシーも同じプロトコルを利用している

出た！！チェックリスト

脅威モデリングイベントへの勧誘

## 
システムメトリクスを週次？で定点観測して、いまのアーキテクチャでおかしくないか？
などを議論した。


## 


# パネルディスカッション
# 可視化と効果測定

## 負債の見える化 -ビジネスとエンジニアのギャップをどう埋めるか？-
### 伊藤さん意見
両サイドある。
ビジネスサイドが感じてるギャップをエンジニア側からウメに行く。
エンジニアが感じてるギャップをエンジニア側が埋めに行く。
イネイブラーが抽象度の飛躍を埋めるファシリテーション？
これはビジネスアーキの役割の1つでは？と感じる。


ここから
投資家にとっては、事業のKGIがいかに実践できているか？
というデータが特に関心がある。

スタートアップの時には、技術的負債って純資産と負債からなる。
バランスシートの一定の割合が負債。
負債を積みながらスピードを上げる。
積んだものを一定経過したら、負債って借金なので、どんどんスピードが鈍化する。
その指標をあらかじめ決めておくことが重要。
今は負債を積んででも、素早い機能リリースを優先などの方針定義。

### かみなし
いつ突っ込むかのタイミングが大事。
次の資金調達が終わって、キャッシュが入ってくるのが見えるまでにDocで提示？

日々のセールスチームのミーティングに参加して、今どんな精神状況なのか？
が議事録などを読むと見えてくる。

どんなタイミングでどういう持っていき方をしたらいいか？

「相手方の見ている景色で通じる言葉、モデルで会話を行う。」って意味と解釈した。

## 技術的負債の返済効果をどこまで測るか？
効果測定の必要性について。

計測はコストかかるし、すぐには効果が表れない。

### かみなし
売り上げに紐づけていない。

レスポンスタイムなどのメトリクスで効果を出す。
わかりにくいのは、認知負荷が下がってコードを素早く書けるようになったという効果。
（今までブログ書いてなかった人が書いたとか）

開発にどのくらい時間を使えているのか？というメトリクス

### 伊藤さん
プロダクト開発によって売り上げに反映されるのは、遅効。
遅行指標。は追わないとか、期待付加価値
この機能があれば買い続けてくれるというものを明確化する。

技術的負債があったら、それによって開発生産性が低下すると、
期待付加価値がどのくらい低下するか？というものを定性的に表現。

そもそも効果を図る必要がない文化を作る。
ボーイスカウト原則をあたり前な生活にする。毎日の歯磨きのごとし。
負債返済がプロジェクト化する時点で日々の行いがよくないってこと。

# Q & A
いろんな品質特性軸の中で、それぞれの文脈で得意なそれぞれが大事にしてる軸(保守性)での負債解消に走らないように心掛けていることってあるか？　品質同士のトレードオフ
どんな利用者目線での品質を改善したくて、どの内部品質を改善するのが、もっとも最小限コストでできるのか？

要約：負債の解消が個別最適にならないようにするために心がけてることは？
論理と感情に分けて話してもらえると嬉しい。

## かみなし
規模の大きいものはドキュメントでかいて
これによって新たな副作用がないかってことをドキュメント化して
詳しい人連れてきて突っ込んでもらう

かみなしは、インフラコスト制約は少し緩めにしている。スタートアップなので。
発見できずに偏ってしまったときには、また都度議論して　ワンサイズフィッツオール。
トレードオフはおこなったうえで、気づかなかったら後から治す。

### 聞いていての発見仮説
大きめのリアーキテクチャする際には、前提条件ツリーなるものを計画段階で作成して、
実行後の効果をデータで監視しながら、前提条件ツリーの仮説モデルの修正に使う。

## ログラス
OKRを目標設定にしている。共通目標をチームで言語化している。
この大目標をずらさない。
日々の歯磨き改善　個別最適は自分の範疇で行う。
他のチームへの影響もあるような大きい回収は、説明できるように行う。

あとは採用で目的思考の人を採用する。技術課題を設けて一定以上の質の人材確保。
「このラインを設けて」という評価軸をもうけておく
ビジネスと利用者という外側と内側の目線の行き来。

# 懇親会で得た知識
負債とSWOTモデルのトレーサビリティ