要はバランスからの卒業 #yumemi_grow

TechTrain: https://service.techtrain.dev/

Transcript

2. 梶川 琢馬 𝕏 @kajitack 株式会社 TechBowl VPoT TechTrain の開発やメンターを担当 関数型まつりのコアスタッフ https://x.com/kajitack
3. 設計議論の終わり際、 誰かが必ず言う 「要は、バランスでしょ」 3/14
4. 構造を疑う 評価する 意思決定しやすくする 4/14
5. 構造を疑う その「バランス」は、本当に対立か？ 誤った二分法（false dichotomy） 複数の選択肢があるのに、2 つだけを提示する誤謬 5/14
6. 選択肢は、もっとある モノリス or マイクロサービス → モジュラーモノリスがある AI を使うと品質が下がる →　品質向上にも AI を使う 中間と代替を、ちゃんと並べてみる 6/14
7. 評価する 「要はバランス」と言いがちなのは、 情報不足が原因 定量化する。知識を集める。選択肢を増やす。 バランスの議論の9割は、情報を集めれば消える 7/14
8. 意思決定しやすくする 個人が情報を集めても、 決められない／変えられない構造なら意味がない 意思決定できる組織構造 ＋ 意思決定を支えるアーキテクチャ 「決まる仕組み」を、組織と設計の両輪で作る 8/14
9. 実践例： 結合のバランスを 定量化する 要素を洗い出す → モデル化する → スケールを調整する 9/14
10. ① 要素を洗い出す 結合を 3 つの次元で見る 強度 : 弱い（コントラクト）←→ 強い（侵入） 距離 : 近い（同オブジェクト）←→ 遠い（別ベンダー） 変動性 : 低い（レガシー）←→ 高い（コア・サブドメイン） 10/14
11. ② 論理式でモデル化 均衡度 = (強度 XOR 距離) OR NOT 変動性 強度と距離が「ズレて」いる (モジュール性が高い) か、変動性が低ければ、バランスが取れる 良いか悪いかを式で表現できる 11/14
12. ③ スケールを調整する 均衡度 = max(|強度 - 距離| + 1, 10 - 変動性 + 1) 変動性が低ければ、多少モジュール性が低くても許容できる バランスを点数で表現できる 12/14
13. 「要はバランス」から卒業する トレードオフからスタートし、二項対立を疑い、選択肢を模索し、定量評価して バランスを取る。 議論を膠着させるではなく、前に進めよう。 13/14
14. 「要はバランス」は 議論の着地点ではなく、 スタート地点 14/14