divide and conquer

Transcript

1. Divide and Conquer
2. 私の好きなアルゴリズム 私の一番好きなアルゴリズムは Divide and Conquer（分割統治） です。 なぜ好きか？応用範囲が異常に広い アルゴリズム システム設計 仕事の進め方 日常生活
3. 今日話したいこと Divide and Conquer とは何か？ なぜこの考え方がここまで強いのか？ システム設計でどう使われているか 日常生活でどう使えるか そして、どこで失敗するのか
4. SECTION 01 Divide and Conquer とは？
5. Divide and Conquer の定義 大きな問題を 小さな問題に分割し それぞれを解決し 結果を統合する考え方
6. 基本ステップ STEP 1 Divide 問題を小さくする STEP 2 Conquer 小さな問題を解く STEP 3 Combine 解をまとめる 実は Combine が一番難しい
7. なぜ Divide and Conquer は強いのか？ 理由 ① 人間の限界に合っている 理由 ② 変更と成長に強い 理由 ③ 失敗しても致命傷になりにくい 現実世界は「一発成功」前提ではない
8. アルゴリズムの代表例 一気に解こうとしない
9. マージソート（超ざっくり） [8, 3, 5, 1] ↓ Divide [8, 3] [5, 1] ↓ Conquer [3, 8] [1, 5] ↓ Combine [1, 3, 5, 8] ✓ 分割は単純 半分に分けるだけ ✓ 統合ルールが明確 小さい順にマージ Combine が設計の肝
10. SECTION 02 システム設計における Divide and Conquer
11. システム設計は巨大な問題 要件が多い 関係者が多い 変更が前提 正解が一つではない Divide and Conquer しないと破綻する
12. 分割の軸（よく使われる） ドメイン（業務） 責務 データのライフサイクル 同期 / 非同期 チーム構成
13. マイクロサービスは分割の成功例…？ ✓ Divide は成功しやすい •サービス単位で分割 •チーム単位で分割 •デプロイ単位で分割 ✗ しかし Combine が地獄 •API が増えすぎる •データ整合性が崩れる •障害調査が難しい •「結局どこが悪いの？」 分割より統合の方が難しい
14. Combine で必要になる設計 最初から設計するもの
15. 分割の失敗パターン 失敗例 ① レイヤーで切りすぎる Controller → Service → Repository 変更理由が同時に変わる → 結局全部直す 失敗例 ② 技術都合で分割 DB ごと、言語ごとに分割 業務上の意味がない → 統合コストだけ増える 失敗例 ③ Combine を考えずに分割 API が場当たり的、責務が曖昧 分割した瞬間から 負債が始まる
16. 分割の判断基準（実践編） どこで切るか？考え方の順序 1. この変更は何が原因で起きるか？ 2. 一緒に変わるものは何か？ 3. 別々に変えたいものは何か？ 4. 失敗したらどこまで壊れてよいか？ 良い分割のサイン ✓ 変更理由が1つ ✓ 名前で説明できる ✓ 単独でテストできる ✓ チームの境界と合っている
17. SECTION 03 日常生活の Divide and Conquer
18. 実は毎日やっている 引っ越し 大掃除 仕事のタスク 勉強計画
19. 大きすぎるタスク Before 「新機能を作る」 不安・先延ばし・停止 ✓ Divide するとこうなる 1. 要件整理 2. 設計 3. 実装 4. テスト 5. リリース 今日やることが見える 進められる
20. CONCLUSION まとめ
21. 今日のメッセージ Divide and Conquer は「生き方」 分割は簡単、統合が本番 良い分割は未来の自分を助ける
22. 難しい問題は まだ分割が足りていないだけ