1. 締め殺しイチジクの話 大きな既存システムにどうやって向き合う？ 原田騎郎 株式会社アトラクタ fi https://commons.wikimedia.org/wiki/File:Strangler_ g_%285731429030%29.jpg
2. 原田騎郎 / Harada Kiro アジャイルコーチ、ドメインモデラ、サプライチェーンコンサルタント。 認定スクラムトレイナーRegional。福岡生まれ 外資系消費財メーカーの研究開発を経て、2004年よりスクラムによる開 発を実践。ソフトウェアのユーザーの業務、ソフトウェア開発・運用の業務 の両方を、より楽に安全にする改善に取り組んでいる 2
3. 株式会社アトラクタについて ✤ 社名：株式会社アトラクタ 英文表記：Attractor Inc. / https://www.attractor.co.jp ✤ 設立：2016年12月 ✤ 所在：東京都港区 ✤ 開発プロセスに関するコンサルティングやトレーニングを提供 ✤ アジャイル開発 / DevOps / チーム育成 / クラウドコンピューティング / ドメインモデリン グなどが専門領域 3
5. fi https://commons.wikimedia.org/wiki/File:Strangler_ g_%285731429030%29.jpg
6. 締め殺しイチジク / Strangler Fig fi https://dianadarie.medium.com/the-strangler- g-migration-pattern-2e20a7350511 6
7. https://martinfowler.com/bliki/StranglerFigApplication.html 7
8. https://bliki-ja.github.io/ StranglerFigApplication/ 8
10. 芽を出す ✤ ✤ 日当たりのいいところに ✤ 外部からの評価が得られるところ ✤ 楽でメリットの大きなところ 元のシステムに依存する ✤ ✤ 新旧の双方向連携が必要 メリットをユーザーが感じられるように ✤ UI / リードタイム 10
11. エフォートインパクトマトリクス かんたん ウケない ウケる だるい 11
12. 根を伸ばす ✤ 元のシステムへの依存を減らす ✤ ✤ 自立して動けるように さらにユーザーメリットを改善する ✤ メリットが大きく、見えやすい ところから 12
13. 待つ ✤ 新しいシステムへユーザーが移ってく るのを待つ ✤ ✤ 移ってこないなら、前からやり直し ここで開発チームを増やさない ✤ 増やさない ✤ 増やさない ✤ 増やさない ✤ 待つ 13
14. 待つ（ちょっと締める) ✤ 並行稼働中の使用状況（ユーザー数、利用回数）に基づいて、新旧システムの費用 対効果を計算する ✤ 旧システムの運用費用は、旧システムユーザーに負担してもらおう ✤ 課金体系の移行に期限をつける ✤ システム単位でなくフィーチャー単位でROIを計算してみる ✤ ユーザーの少ない機能の開発は開発費を負担してもらおう 14
15. 広げつつ待つ（ちょっと締める） ✤ さらにユーザーが移行するのを待つ ✤ ✤ ✤ 「この機能があれば移行するのに！！」に負 けない インパクトエフォートマトリクスにもとづきインパ クトのあるフィーチャーを追加する ✤ 移行した機能数・フィーチャーではなくビ ジネスアウトカムを測る ✤ 移行済みのUIを複雑にしない 待つ 15
16. 待つ（締めなくていいので待つ） ✤ ユーザーと養分(費用負担)がいなくなっ た旧システムは枯れる ✤ ざっくりとした目標数値 ✤ 新システムはフィーチャー数は、旧シ ステムの半分以下（画面数なども） ✤ 新システムのコード量は、旧システム の1/4以下 16
17. fl https://www. ickr.com/photos/axelrd/48266999572/in/photostream/ 17
18. 次は？ ✤ ストラングラーフィグアプリケーションも放置すると複雑になる ✤ アプリケーションを小さくする ✤ 機能・フィーチャーを減らす ✤ 次の木に行く ✤ 作ってた木が古くなってない？ 18
19. まとめ ✤ 旧システムを全部に入れ替える必要はない。全部を理解しなくてもいい ✤ 小さく順次移行する方がリスクが低い ✤ ✤ 双方向連携の仕組みを作るのに、それなりの技術力とコストが必要 ゆっくり作ってユーザーの移行を促すことで、システムを小さくできる 19
20. UnsplashのDavid Clodeが撮影した写真 20
21. 20分に入らなかったこと ✤ 「手戻り」として忌避されていたものが、システムの安定に大事だったのでは？ ✤ 小さな問題に対して小さな解決策を提供できるチームにしか、大きな問題を渡して はならない ✤ 問題よりさらに大きな問題を解決策として、手に負えなくしてしまう ✤ 技術的負債は踏み倒せる ✤ マイクロサービスは、システムのデプロイ単位を小さくする技術 ✤ システムを小さくする技術ではない 21
