移行できそうでやりきれなかった 10年超えのシステムを葬るための戦略 / phper-kaigi-2025-ryu

プロポーザル: https://fortee.jp/phperkaigi-2025/proposal/0b6a029d-27d6-49c7-965e-beef885c0294

私はアドテクノロジーを扱う会社で、広告配信の制御や入稿を行うための管理システムの開発を行っています。そのシステムでは社内用の広告配信設定の管理、メディア用レポート閲覧、広告配信設定機能が行えます。

歴史的経緯から3つの管理システムが存在してます。

10年以上の歴史を持つ古い社内・社外向け管理システム(PHP + CodeIgniter)
社内向け新管理システム(PHP + Slim)
社外向け新管理システム（Go）
1番のシステムは10年以上保守運用されており、システムも運用も把握しきれない部分が多く、フレームワークの保守も厳しくなってきました。過去に何度も古い管理システムを葬ろうと挑んでは、志半ばで取り組みが終わることを繰り返してきていました。今回、古い管理システム の葬りが完了する目処が立ちました。

今回の発表では、 「過去、なぜ、移行しきれなかったのか」、「今回、なぜ、移行の目処が建てられたのか」、「今回の移行戦略」 をお話します。

具体的には以下の戦略を取りました。

ロードマップを作成
ステークホルダーに宣言
移行をやり切るためのサポート（ヒアリング、移行アナウンスや進捗の分かるシートへのリンクを表示）
旧管理画面の解像度を上げる工夫（Xdebug によるデバッガ、OpenTelemetry + Jaeger による SQL ログなど）
自動テストの拡充
聞いてほしい人

長年改修されてきたシステムのリプレイスや移行を考えている人
移行タスクが志半ばで終わった経験がある人
フルサイクル開発の仕事の進め方に興味がある人

Transcript

1. 移行できそうでやりきれなかった 10年超えのシステムを葬るための戦略 株式会社CARTA HOLDING 株式会社 fluct ⽯河 ⻯太 PHPerKaigi2025 2025.03.22
2. • 2020年 ◦ 新卒でCARTA HOLDINGSに⼊社 ◦ ポイントメディアを扱うDIGITALIOに配属 • 2023年 ◦ アドテクノロジーを扱うfluctに異動 ◦ 広告配信の設定などを⾏う管理画⾯の開発‧保守をしている 略歴 株式会社fluct 所属 ⽯河 ⻯太 fluct メディア 広告配信をする プラットフォームを提供 fluct経由で広告を表示 fluctのプロダクトの簡単な説明
3. 初登壇なのでがんばります！！！
4. 10年超えのシステム = 10年超えの管理画⾯
5. 10年超えの管理画面のCodeIgniter.php /** * CodeIgniter * * An open source application development framework for PHP 4.3.2 or newer * * @package CodeIgniter * @author ExpressionEngine Dev Team * @copyright Copyright (c) 2008 - 2010, EllisLab, Inc. * @license http://codeigniter.com/user_guide/license.html * @link http://codeigniter.com * @since Version 1.0 * @filesource */ // CI Version /** @noinspection PhpUnused */ const CI_VERSION = '1.7.3';
6. 10年超えの管理画面のCodeIgniter.php /** * CodeIgniter * * An open source application development framework for PHP 4.3.2 or newer * * @package CodeIgniter * @author ExpressionEngine Dev Team * @copyright Copyright (c) 2008 - 2010, EllisLab, Inc. * @license http://codeigniter.com/user_guide/license.html * @link http://codeigniter.com * @since Version 1.0 * @filesource */ // CI Version /** @noinspection PhpUnused */ const CI_VERSION = '1.7.3'; 2003年リリース 2010年リリース バージョン 1系... 最新は4.6.0 （2025/03時点）
7. PHP 8.1まではアップデートしてある
8. PHP8.0対応をした作業ログにあったつらそうなコメント
9. バージョンが古いという問題に加えて 管理画⾯が3つあるという問題がある
10. 広告配信設定をまとめるオーダー機能 移行できそうでやりきれなかった 10年超えのシステムを葬るための戦略 管理画⾯が3つある 同じ機能のページが3つ存在する 補足: 全てオーダーと呼ばれるものを管理する機能。オーダー = 広告のキャンペーンをまとめる機能。ちなみにキャンペーンもそれぞれにある。
11. 管理画⾯がたくさんあると つらいところがたくさんある
12. 開発も運⽤も つらすぎる現状になっている
13. 葬り（ほうむり）
14. 移行できそうでやりきれなかった 10年超えのシステムを葬るための戦略 葬り • CARTAの社内用語 • 機能提供の停止まですることを「葬り」と呼んでいる ◦ 詳しくは「事業をエンジニアリングする技術者たち」という本で 紹介している • 今回の発表は古い管理画面を葬るお話 https://www.lambdanote.com/products/carta 補足: この本は、 ITエンジニア本大賞2021年技術書部門大賞に輝いている。
15. AGENDA 01 どうしてこうなった 02 旧管理画⾯を葬った 03 実⾏した戦略と振り返り 04 最後に 01
16. AGENDA 01 どうしてこうなった 02 旧管理画⾯を葬った 03 実⾏した戦略と振り返り 04 最後に
17. 01. どうしてこうなった どうして管理画⾯が3つもあるのか 旧管理画面 現社内向け管理画面 現社外向け管理画面 作られた時期 2008年ごろ 2014年ごろ 2023年 バックエンド PHP + CodeIgniter PHP + Slim Go フロントエンド twig React Next.js 補足: 社外向け = メディア向け。広告がどれくらい表示、クリック、収益があったかのレポートを見たり、配信に関する設定ができる。 冒頭のCodeIgniter 1.7.3の 管理画面 あとから生まれた管理画面
18. DB 旧管理画面 現社内向け 管理画面 現社外向け 管理画面 PHP8.1 コンテナ Go コンテナ PHPはコンテナ共通 全部同じ DBを 見ている 01. どうしてこうなった どうして管理画⾯が3つもあるのか
19. どうしてこうなった
20. 2008年 fluctの創⽴
21. 01. どうしてこうなった 創⽴当初管理画⾯は1つだった（2008〜） 旧管理画面 作られた時期 2008年ごろ バックエンド PHP + CodeIgniter フロントエンド twig 旧管理画面が 生まれた
22. 01. どうしてこうなった 創⽴当初管理画⾯は1つだった（2008〜） 旧管理画面 作られた時期 2008年ごろ バックエンド PHP + CodeIgniter フロントエンド twig 社内も社外も この画面で操作していた 旧管理画面が 生まれた
23. 2013年頃 会社をまたいだ操作がしたくなった
24. 01. どうしてこうなった 会社をまたいだ操作がしたくなった（2014ごろ） サイト1 A社 サイト2 サイト3 B社 サイト4 A社はサイト 1, サイト2を持つ B社はサイト 3, サイト4を持つ
25. 01. どうしてこうなった 会社をまたいだ操作がしたくなった（2014ごろ） サイト1 A社 サイト2 サイト3 B社 サイト4 社内ユーザはサイト 2を操作するために A社としてログインしてページを開く必要がある
26. 01. どうしてこうなった 会社をまたいだ操作がしたくなった（2014ごろ） サイト1 サイト一覧 サイト2 サイト3 サイト4 サイト1 A社 サイト2 サイト3 B社 サイト4 fluctに登録されている全てのサイトを 一覧したいというニーズが登場
27. 01. どうしてこうなった 社内管理画⾯が⽣まれた（2014〜） 旧管理画面 現社内向け管理画面 作られた時期 2008年ごろ 2014年ごろ バックエンド PHP + CodeIgniter PHP + Slim フロントエンド twig React 現社内向け管理画面が 生まれた
28. 01. どうしてこうなった 社内管理画⾯が⽣まれた（2014〜） 旧管理画面 現社内向け管理画面 作られた時期 2008年ごろ 2014年ごろ バックエンド PHP + CodeIgniter PHP + Slim フロントエンド twig React 社内のオペレーションは 「基本的に」ここで 行われるようになった 現社内向け管理画面が 生まれた 現社内向け管理画面が 生まれた
29. 01. どうしてこうなった 社内管理画⾯が⽣まれた（2014〜） 旧管理画面 現社内向け管理画面 作られた時期 2008年ごろ 2014年ごろ バックエンド PHP + CodeIgniter PHP + Slim フロントエンド twig React 社内のオペレーションは 「基本的に」ここで 行われるようになった 一部の社内向け機能が 旧管理画面にまだある 社外ユーザ → 旧管理画面 社内ユーザ → 旧管理画面 + 現社内向け管理画面 現社内向け管理画面が 生まれた
30. 2022年ごろ 旧管理画⾯の限界がきた
31. 01. どうしてこうなった 旧管理画⾯の限界がきた（2022年ごろ） 旧管理画面 現社内向け管理画面 作られた時期 2008年ごろ 2014年ごろ バックエンド PHP + CodeIgniter PHP + Slim フロントエンド twig React 旧管理画面が見づらい
32. 01. どうしてこうなった 旧管理画⾯の限界がきた（2022年ごろ） 旧管理画面 現社内向け管理画面 作られた時期 2008年ごろ 2014年ごろ バックエンド PHP + CodeIgniter PHP + Slim フロントエンド twig React 旧管理画面が見づらい 多言語対応など新しく やりたいことが増えてきた
33. 01. どうしてこうなった 旧管理画⾯の限界がきた（2022年ごろ） 旧管理画面 現社内向け管理画面 作られた時期 2008年ごろ 2014年ごろ バックエンド PHP + CodeIgniter PHP + Slim フロントエンド twig React 旧管理画面が見づらい アーキテクチャ 古すぎて辛い 多言語対応など新しく やりたいことが増えてきた
34. 01. どうしてこうなった 社外向け管理画⾯が⽣まれた（2023〜） 旧管理画面 現社内向け管理画面 現社外向け管理画面 作られた時期 2008年ごろ 2014年ごろ 2023年 バックエンド PHP + CodeIgniter PHP + Slim Go フロントエンド twig React Next.js 現社外向け管理画面が 生まれた
35. 01. どうしてこうなった 社外向け管理画⾯が⽣まれた（2023〜） 旧管理画面 現社内向け管理画面 現社外向け管理画面 作られた時期 2008年ごろ 2014年ごろ 2023年 バックエンド PHP + CodeIgniter PHP + Slim Go フロントエンド twig React Next.js 社外のオペレーションは 「基本的に」ここで 行われるようになった
36. 01. どうしてこうなった 社外向け管理画⾯が⽣まれた（2023〜） 旧管理画面 現社内向け管理画面 現社外向け管理画面 作られた時期 2008年ごろ 2014年ごろ 2023年 バックエンド PHP + CodeIgniter PHP + Slim Go フロントエンド twig React Next.js 一部の社外向け機能も 旧管理画面にまだある 社外のオペレーションは 「基本的に」ここで 行われるようになった 社外ユーザ → 旧管理画面 + 現社外向け管理画面 社内ユーザ → 旧管理画面 + 現社内向け管理画面
37. 2023年〜 管理画⾯が3つになった
38. 01. どうしてこうなった 管理画⾯が3つになってしまった 旧管理画面 現社内向け管理画面 現社外向け管理画面 作られた時期 2008年ごろ 2014年ごろ 2023年 バックエンド PHP + CodeIgniter PHP + Slim Go フロントエンド twig React Next.js 本来はこの 2つで十分なはず
39. 01. どうしてこうなった 管理画⾯が3つになってしまった 旧管理画面 現社内向け管理画面 現社外向け管理画面 作られた時期 2008年ごろ 2014年ごろ 2023年 バックエンド PHP + CodeIgniter PHP + Slim Go フロントエンド twig React Next.js 社内、社外向けの機能が残っていため 使わざる得ない 本来はこの 2つで十分なはず
40. 本当にあったつらい話
41. 01. どうしてこうなった 本当にあったつらい話 管理画面で広告の URLを変えたら 広告がでなくなりました 運用者
42. 01. どうしてこうなった 本当にあったつらい話 • 前提 ◦ 旧管理画面と現社内向け管理画面に（ほぼ）同じ機能がある • 調査した結果
43. 広告設定を更新する処理 // 旧管理画面の処理（配信される） $result = $this->oldRepository->update( $id, $name, $url, 1, ); // 現社内向け管理画面の処理（配信されない） $result = $this->newRepository->update( $id, $name, $url, null, ); • 本来値が入ってあるべきところに社内向け管理画面はnullになっていた • 広告配信に必須なパラメータだったため、配信ができなくなっていた こっちは 1 こっちは null
44. 01. どうしてこうなった 本当にあったつらい話 機能対応していくのつらい 開発者 結局、どこから設定すれば大丈夫なの？ そもそも、複数あるの難しい 運用者
45. 開発者も運⽤者も つらい状態が⽣まれてしまった
46. 広告配信ミスは売上の低下だけでなく fluctを使ってくれるメディアへの 信頼にも直結する
47. 01. どうしてこうなった 旧管理画⾯を葬りたい 旧管理画面 現社内向け管理画面 現社外向け管理画面 作られた時期 2008年ごろ 2014年ごろ 2023年 バックエンド PHP + CodeIgniter PHP + Slim Go フロントエンド twig React Next.js 旧管理画面の機能をあるべきところに移して 旧管理画面を葬りたい
48. ⾟いなら 早く葬ればよいんじゃないか?
49. なんで今まで葬れなかったんだっけ?
50. • 難易度が高い ◦ 旧管理画面のコードを読み解いて移植するのが大変 • そもそも、問題が山積みでその対応に時間がかかっていた ◦ CodeIgniter 1.7.2をベースにしているのでセキュリティの問題があり 本家のセキュリティパッチの取り込み ◦ オンプレからクラウドへの移行 ◦ 認証認可の仕組みの整備 ◦ テンプレートエンジンをクライアントとAPIに分離 01. どうしてこうなった なんで葬れなかったんだっけ? 志半ばでプロジェクトが終わっていた
51. 旧管理画⾯がずっと葬れずに つらい状況が続いている
52. AGENDA 01 どうしてこうなった 02 旧管理画⾯を葬った 03 実⾏した戦略と振り返り 04 最後に 02 01
53. 今⽉、ようやく葬れそう🎉 残り2機能...!
54. • 去年の10月くらいから計画が始まり12月から本格着手 ◦ 基本的には私を含めて2人で進めていた • 着手時点で旧管理画面に33の機能が残っていた • 2024/12 から 2025/03 の間に私は 33,364行 追加して 32,688行 葬っていた 02. 旧管理画面を葬った 旧管理画⾯を葬れそう 補足: 自動生成と思われるコードをざっくり省いたら追加 29,624、削除18,866だった。 旧管理画面 現社内向け管理画面 現社外向け管理画面 作られた時期 2008年ごろ 2014年ごろ 2023年 バックエンド PHP + CodeIgniter PHP + Slim Go フロントエンド twig React Next.js
55. 葬った結果どうなるのか
56. • 開発者、運用者ともに良い状態になる • 開発者 ◦ 旧管理画面を気にして開発、保守をしなくて良くなる ◦ PHPのバージョンなど開発基盤の改善がしやすくなる ◦ テストコードが不十分だったが、移行に伴ってテストコードを増やせた • 運用者 ◦ 運用コストが減る ◦ モダンなUI/UXになり使いやすくなる 02. 旧管理画面を葬った 旧管理画⾯を葬れそう
57. なんで今回 葬る⽬処がたった？
58. • チームとして旧管理画面を葬ると決めた ◦ 葬り作業に担当者を当て続けることができた • 葬り切るための戦略を立てて遂行した 02. 旧管理画面を葬った なんで葬る⽬処がたった？
59. AGENDA 01 どうしてこうなった 02 旧管理画⾯を葬った 実⾏した戦略と振り返り 04 最後に 01 03
60. • 実行した戦略 ◦ 計画を立てる ▪ スケジュールを決める ▪ WBSを作る ◦ 対話をする ▪ 運用者と開発者双方と対話をする ◦ デバッグ環境を整える • どういう課題があったのか、なにをしたか、どうだったかを話していく 03. 実行した戦略と振り返り 実⾏した戦略と振り返り
61. AGENDA 実⾏した戦略と振り返り 03 計画を⽴てる 対話をする デバッグ環境を整える 01 02 03
62. AGENDA 実⾏した戦略と振り返り 03 計画を⽴てる 対話をする デバッグ環境を整える 01 02 03 01
63. 03. 実行した戦略と振り返り 課題感 半年経ったけど葬り終わりません
64. • あらゆるプロジェクトは4つのフォースによって統治されている 03. 実行した戦略と振り返り 課題感 荒ぶる四天王[1] [1] ＪｏｎａｔｈａｎＲａｓｍｕｓｓｏｎ ; 西村直人; 角谷信太郎. アジャイルサムライ――達人開発者への道 (p.136). オーム社. Kindle 版. 固定
65. • あらゆるプロジェクトは4つのフォースによって統治されている 03. 実行した戦略と振り返り 課題感 荒ぶる四天王[1] [1] ＪｏｎａｔｈａｎＲａｓｍｕｓｓｏｎ ; 西村直人; 角谷信太郎. アジャイルサムライ――達人開発者への道 (p.136). オーム社. Kindle 版. 固定 スコープで調整していく
66. • 葬りは納期などの外からの締め切りは（基本的に）ない ◦ 困ったら延々と時間を伸ばすことができてしまう 03. 実行した戦略と振り返り 課題感 荒ぶる四天王[1] [1] ＪｏｎａｔｈａｎＲａｓｍｕｓｓｏｎ ; 西村直人; 角谷信太郎. アジャイルサムライ――達人開発者への道 (p.136). オーム社. Kindle 版. 時間がずっと荒ぶる
67. 期限がないなら ⾃分で期限を決めるしかない
68. • 期限を自分で決めて上長、チームメンバーに共有した 03. 実行した戦略と振り返り 締め切りを作った 今クウォーター中にここまで 終わらせます
69. 03. 実行した戦略と振り返り 締め切りを作った • 時間の荒ぶりを抑えることができた • 次はスコープが立ちはだかってくる 荒ぶる四天王[1] [1] ＪｏｎａｔｈａｎＲａｓｍｕｓｓｏｎ ; 西村直人; 角谷信太郎. アジャイルサムライ――達人開発者への道 (p.136). オーム社. Kindle 版. 抑えることができた
70. 03. 実行した戦略と振り返り 締め切りを作った • 時間の荒ぶりを抑えることができた • 次はスコープが立ちはだかってくる 荒ぶる四天王[1] [1] ＪｏｎａｔｈａｎＲａｓｍｕｓｓｏｎ ; 西村直人; 角谷信太郎. アジャイルサムライ――達人開発者への道 (p.136). オーム社. Kindle 版. 抑えることができた 立ちはだかってくる
71. 03. 実行した戦略と振り返り 課題感 移行対象に関連するバッチが 古い基盤に乗っているから これを機に新しい基盤に移したい いつかはやりたいけど今じゃなくて良い仕事をやりたくなる
72. • いつかはやりたい仕事もスコープにいれると、時間が荒ぶってしまう • 決めた締め切り内に葬りが終わらない 03. 実行した戦略と振り返り 課題感 荒ぶる四天王[1] 葬りに関係がある仕事だけをスコープにする必要がある [1] ＪｏｎａｔｈａｎＲａｓｍｕｓｓｏｎ ; 西村直人; 角谷信太郎. アジャイルサムライ――達人開発者への道 (p.136). オーム社. Kindle 版. 荒ぶり始める
73. 葬りに関係がある仕事って何？
74. • 必要な作業を整理し、WBSを作る ◦ 旧管理画面に残っている全てのページを洗い出す ◦ 運用状況の整理、移行の可否、移行作業の難易度を整理 03. 実行した戦略と振り返り WBSを作る 補足: WBS = Work、Breakdown、Structure。プロジェクトのタスクを分解して管理する。
75. 03. 実行した戦略と振り返り • 期限に合わせたスコープを適切に設定することができた • 移行漏れがなかった • 進捗共有に役立った WBSはどうだったか
76. AGENDA 実⾏した戦略と振り返り 03 計画を⽴てる 対話をする デバッグ環境を整える 01 02 03 02
77. 03. 実行した戦略と振り返り 対話をする 私 運用者 開発者 運用者と開発者双方への対話が必要
78. 03. 実行した戦略と振り返り 対話をする 私 運用者 開発者 まずは、運用者側の対話
79. 03. 実行した戦略と振り返り 課題感 謎の機能の管理画面があるけど これは一体何だ ...?
80. 03. 実行した戦略と振り返り 課題感 この管理画面って知っています？ なにこれ？ 半年に1回 くらい触る 運用大変なので 辞めたい ... 昔は力を入れていたが、いまは力を入れていない機能の管理画面だった 運用者たち
81. • みんなが困っていた ◦ 運用コストも高いし、決まった担当者はもういない ◦ 現管理画面への移行コストも高い • その機能を適切な状態にしたかった ◦ また力を入れると決めて、担当者を決めて、移行をする ◦ もう力を入れないと決めて、機能自体を停止して、移行をしない 03. 実行した戦略と振り返り 課題感 ビジネスフローを見直す必要があり、自分だけでは決められなかった
82. • slackの過去ログを見て、機能について詳しそうな人を見つけ対話をした ◦ どういうビジネスフローで、なにができる機能なのか ◦ どれくらい使われているのか ▪ アクセスログやDBの書き込みも見た ◦ どれくらいお金になっているのか ◦ 本来はどうあってほしいか 03. 実行した戦略と振り返り 対話をして現状を知る 機能自体を葬る方に倒したほうが良いとわかった
83. • ビジネスフローを変える判断ができるステークホルダーを巻き込んで　　　 対話をした • 葬りたい旨を最初にステークホルダーに伝えた ◦ 「使います?」だと「使います」と回答されてしまいがち ◦ 「葬りたいです」とコミュニケーションをスタートした • 集めた事実に加えて機能の代替案を用意した ◦ どうしてもやりたくなったら　　　　　　　　　　　　　　　　　　　 コストはかかるが同等のことはできる状況は残した 03. 実行した戦略と振り返り ステークホルダーを巻き込んだ
84. • 無事、サービスの新規利用の停止し、管理画面の移行もしないに　　　　　 話をまとめられた • 愚直にやっていたら、工数が追加で2, 3週間くらいかかっていた • 運用者的に重い運用フローをなくせた 03. 実行した戦略と振り返り 対話をしてどうだったか
85. 03. 実行した戦略と振り返り 対話をする 私 運用者 開発者 次に、開発者側の対話
86. 03. 実行した戦略と振り返り 課題感 葬り作業 やっていくぞ なんかよくわからないけど 忙しそう 長い仕事を独立してやっていると同じチームで他人事感がでてしまう 開発者たち
87. • 全体の流れと現在地がわからないとレビューがしにくくなる • 相談を怠ると自分だけの視点しか入らなくなる ◦ 本当に良い選択肢かどうかがわからなくなる • 他の人から応援してもらえるかどうかは大切 03. 実行した戦略と振り返り 課題感 自分の状況を知ってもらう必要があると思った
88. • 数週間ごとに、葬りについて話す会を催した ◦ 対応状況のリストを見せながら現状を説明 ◦ どう対応しようとしているかの説明 ◦ 今、悩んでいることの説明 03. 実行した戦略と振り返り チームにコンセンサスを取った
89. • チームメンバーから応援をしてもらえていた • コンテキストを知っていないと指摘できないようなレビューをもらえた • 話す会でチームメンバーから良いアドバイスがもらえた ◦ 芸歴が5, 6年目になってくると、基本的には大丈夫でしょという信頼を得て　　　 悩んでいることに対して深く相談するのがおろそかになっていた ◦ 悩んでいるって前提のMTGを開催することでアドバイスがもらいやすかった 03. 実行した戦略と振り返り チームにコンセンサスを取ってどうだったか
90. AGENDA 実⾏した戦略と振り返り 03 計画を⽴てる 対話をする デバッグ環境を整える 01 02 03
91. 03. 実行した戦略と振り返り 課題感 アカウント編集機能を移行したい
92. 03. 実行した戦略と振り返り 課題感 クライアントからは読み取れない 特殊処理はあるのか ? 最終的にどのテーブルたちに 書き込まれるんだ？ 権限はどう管理しているのだろう か？ 知らないといけないことがたくさんある
93. 03. 実行した戦略と振り返り 課題感 詳しい人に教えてもらうか
94. 有識者がいないので コードを愚直に追うしかない
95. • 塩漬けされていた旧管理画面の処理を愚直に追うのはつらすぎる ◦ テストコードから処理を逆算しようにもテストコードがない ◦ fatなController ◦ テンプレートエンジンなのも相まって、時代を感じるソースコード • 大事な機能が残っているので実装漏れを起こしたら一大事 03. 実行した戦略と振り返り 課題感 どんな処理をしているかを 知りたいだけなのに … 補足: Controllerに直接SQLが書かれていたりもした。社外、社内共用の管理画面だったので権限の分岐もたくさんあった。
96. • ローカル環境にOpenTelemetry（OTel）+Jaeger（イェーガー）を導入した 03. 実行した戦略と振り返り デバッグ環境を整えた https://opentelemetry.io/ https://www.jaegertracing.io/ 補足: OTel+Jaegerの詳しい説明は https://blog.shin1x1.com/entry/php-opentelemetry-primer が参考になりました
97. 03. 実行した戦略と振り返り デバッグ環境を整えた • サービスやアプリケーションのテレメトリデータを計装、生成、収集、 送信するためのオブザーバビリティフレームワーク ◦ テレメトリデータ = トレース、メトリクス、ログなど • 受信して、加工して、送信するものなので、単体ではテレメトリデータを　　可 視化できない • トレースを収集して、Webベースの分析UIを提供するOSS 補足: OTel+Jaegerの詳しい説明と導入は https://blog.shin1x1.com/entry/php-opentelemetry-primer が参考になりました
98. 03. 実行した戦略と振り返り デバッグ環境を整えた PHPアプリケーション ② APIが呼ばれる ⑤ テレメトリデータの送信 ④ テレメトリーデータの送 信 ③ テレメトリデータを 生成 ① 管理画面で操作 ⑥ テレメトリーデータをブラ ウザで確認 ① 管理画面で操作
99. 03. 実行した戦略と振り返り デバッグ環境を整えた PHPアプリケーション ② APIが呼ばれる ⑤ テレメトリデータの送信 ④ テレメトリーデータの送 信 ③ テレメトリデータを 生成 ① 管理画面で操作 ⑥ テレメトリーデータをブラ ウザで確認 ② APIが呼ばれる
100. 03. 実行した戦略と振り返り デバッグ環境を整えた PHPアプリケーション ② APIが呼ばれる ⑤ テレメトリデータの送信 ④ テレメトリーデータの送 信 ③ テレメトリデータを 生成 ① 管理画面で操作 ⑥ テレメトリーデータをブラ ウザで確認 ③ テレメトリデータを 生成
101. 03. 実行した戦略と振り返り デバッグ環境を整えた PHPアプリケーション ② APIが呼ばれる ⑤ テレメトリデータの送信 ④ テレメトリーデータの送 信 ③ テレメトリデータを 生成 ① 管理画面で操作 ⑥ テレメトリーデータをブラ ウザで確認 ④ テレメトリーデータの送 信
102. 03. 実行した戦略と振り返り デバッグ環境を整えた PHPアプリケーション ② APIが呼ばれる ⑤ テレメトリデータの送信 ④ テレメトリーデータの送 信 ③ テレメトリデータを 生成 ① 管理画面で操作 ⑥ テレメトリーデータをブラ ウザで確認 ⑤ テレメトリデータの送信
103. 03. 実行した戦略と振り返り デバッグ環境を整えた PHPアプリケーション ② APIが呼ばれる ⑤ テレメトリデータの送信 ④ テレメトリーデータの送 信 ③ テレメトリデータを 生成 ① 管理画面で操作 ⑥ テレメトリーデータをブラ ウザで確認 ⑥ テレメトリーデータをブラ ウザで確認
104. 03. 実行した戦略と振り返り デバッグ環境を整えた（余談） PHPアプリケーション ② APIが呼ばれる ⑤ テレメトリデータの送信 ④ テレメトリーデータの送 信 ③ テレメトリデータを 生成 ① 管理画面で操作 ⑥ テレメトリーデータを DATADOGで確認 最後のテレメトリーデータを扱う部分は 任意の分析ツールに置き換えることもできる
105. 03. 実行した戦略と振り返り デバッグ環境を整えた 編集フォームを表示 編集処理 編集した詳細を表示 アカウントの編集する流れが見れる
106. 03. 実行した戦略と振り返り デバッグ環境を整えた 編集フォームを表示 編集処理 編集した詳細を表示 アカウントの編集する流れが見れる HTTPリクエストごとに 見れる
107. 03. 実行した戦略と振り返り デバッグ環境を整えた このSQLと同じ処理を再実装すればよい 実行されたSQLを見れる
108. 03. 実行した戦略と振り返り デバッグ環境を整えた 実行されたSQLを見れる selectしてる insertしてる このSQLと同じ処理を再実装すればよい
109. • 作業効率が上がった ◦ 処理を愚直に追わなくても、ブラウザでI/Oがわかるのが助かる • 正しい挙動を知ることができた ◦ 「必要なテーブルにinsertしてなかった!」のような障害が起きなかった 03. 実行した戦略と振り返り どうだったか
110. AGENDA 01 どうしてこうなった 02 旧管理画⾯を葬った 03 実⾏した戦略と振り返り 最後に 01 04
111. • 葬るのは難しい ◦ 直接的なお金にならない ◦ 本当に葬って良いんだっけ？ ◦ KIAIでやっていくしかない • 今、移行しきれなかったプロジェクトを持っている人たち ◦ 葬りプロジェクトを立ち上げて頑張ってほしい 04. 最後に 最後に 補足: KIAI（気合）はCARTAの社内用語（?）。気持ちをいれるときに単語を UPPERで表現をする。類義語 : YARUKI。
112. • どうしてこうなった ◦ fluctは歴史的経緯で管理画面が3つになった ◦ 一番古い管理画面は10年以上まえに作られたもので、その管理画面を葬りたかった • 戦略を立てて旧管理画面葬った ◦ 計画を立てる ▪ 締め切りを作る ▪ WBSを作る ◦ 開発者と運用者双方と対話をする ◦ デバッグ環境を整える ▪ OpenTelemetry + Jaegerを導入 移行できそうでやりきれなかった 10年超えのシステムを葬るための戦略 まとめ