概要
前提
Teracyはプロダクトの良さが全てである
主役
エンジニアがそのプロダクトを生み出す大部分の実務を担う
課題
森井・浅野が開発における課題の解像度を正しく理解できていない
弊害
それにより、ロードマップの精度、チーム采配に適切な判断が持てない、開発速度の読みがズレる
解決
開発課題の解像度を共有し、長期構想から逆算し取るべき打ち手は何かを明らかにする
メモ
パフォーマンス・チャット開発速度
DB構造がマズイ
Terra時代から使いまわしてる (めっちゃ昔 / 3-4年前から)
カゲマサの時からスキーマが変わっていない
RDBが癖強い → ユーザー情報をいっぱいとってしまう
何かの情報をフィルタして取れない
DB設計が美しくない → 負債になっている
チャットもDB構造を引き継いだまま
フロント側の構造は変えた
それによってDBの闇が明らかになった
文化的な話
ゼロベースで打ち手を考える
ロングタームで意思決定をする
身銭を切れる人が責任を持ってボールを持って管理する
経営視点をチームメンバーにインストールする
「もっと良い方法はないか？」を常に考えるべきである
技術負債の解消