Tweet
Tweet

Slide 1

Slide 1 text

移行できそうでやりきれなかった 10年超えのシステムを葬るための戦略 株式会社CARTA HOLDING 株式会社 fluct ⽯河 ⻯太 PHPerKaigi2025 2025.03.22

Slide 2

Slide 2 text

● 2020年 ○ 新卒でCARTA HOLDINGSに⼊社 ○ ポイントメディアを扱うDIGITALIOに配属 ● 2023年 ○ アドテクノロジーを扱うfluctに異動 ○ 広告配信の設定などを⾏う管理画⾯の開発‧保守をしている 略歴 株式会社fluct 所属 ⽯河 ⻯太 fluct メディア 広告配信をする プラットフォームを提供 fluct経由で広告を表示 fluctのプロダクトの簡単な説明

Slide 3

Slide 3 text

初登壇なのでがんばります！！！

Slide 4

Slide 4 text

10年超えのシステム = 10年超えの管理画⾯

Slide 5

Slide 5 text

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';

Slide 6

Slide 6 text

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時点）

Slide 7

Slide 7 text

PHP 8.1まではアップデートしてある

Slide 8

Slide 8 text

PHP8.0対応をした作業ログにあったつらそうなコメント

Slide 9

Slide 9 text

バージョンが古いという問題に加えて 管理画⾯が3つあるという問題がある

Slide 10

Slide 10 text

広告配信設定をまとめるオーダー機能 移行できそうでやりきれなかった 10年超えのシステムを葬るための戦略 管理画⾯が3つある 同じ機能のページが3つ存在する 補足: 全てオーダーと呼ばれるものを管理する機能。オーダー = 広告のキャンペーンをまとめる機能。ちなみにキャンペーンもそれぞれにある。

Slide 11

Slide 11 text

管理画⾯がたくさんあると つらいところがたくさんある

Slide 12

Slide 12 text

開発も運⽤も つらすぎる現状になっている

Slide 13

Slide 13 text

葬り（ほうむり）

Slide 14

Slide 14 text

移行できそうでやりきれなかった 10年超えのシステムを葬るための戦略 葬り ● CARTAの社内用語 ● 機能提供の停止まですることを「葬り」と呼んでいる ○ 詳しくは「事業をエンジニアリングする技術者たち」という本で 紹介している ● 今回の発表は古い管理画面を葬るお話 https://www.lambdanote.com/products/carta 補足: この本は、 ITエンジニア本大賞2021年技術書部門大賞に輝いている。

Slide 15

Slide 15 text

AGENDA 01 どうしてこうなった 02 旧管理画⾯を葬った 03 実⾏した戦略と振り返り 04 最後に 01

Slide 16

Slide 16 text

AGENDA 01 どうしてこうなった 02 旧管理画⾯を葬った 03 実⾏した戦略と振り返り 04 最後に

Slide 17

Slide 17 text

01. どうしてこうなった どうして管理画⾯が3つもあるのか 旧管理画面 現社内向け管理画面 現社外向け管理画面 作られた時期 2008年ごろ 2014年ごろ 2023年 バックエンド PHP + CodeIgniter PHP + Slim Go フロントエンド twig React Next.js 補足: 社外向け = メディア向け。広告がどれくらい表示、クリック、収益があったかのレポートを見たり、配信に関する設定ができる。 冒頭のCodeIgniter 1.7.3の 管理画面 あとから生まれた管理画面

Slide 18

Slide 18 text

DB 旧管理画面 現社内向け 管理画面 現社外向け 管理画面 PHP8.1 コンテナ Go コンテナ PHPはコンテナ共通 全部同じ DBを 見ている 01. どうしてこうなった どうして管理画⾯が3つもあるのか

Slide 19

Slide 19 text

どうしてこうなった

Slide 20

Slide 20 text

2008年 fluctの創⽴

Slide 21

Slide 21 text

01. どうしてこうなった 創⽴当初管理画⾯は1つだった（2008〜） 旧管理画面 作られた時期 2008年ごろ バックエンド PHP + CodeIgniter フロントエンド twig 旧管理画面が 生まれた

Slide 22

Slide 22 text

01. どうしてこうなった 創⽴当初管理画⾯は1つだった（2008〜） 旧管理画面 作られた時期 2008年ごろ バックエンド PHP + CodeIgniter フロントエンド twig 社内も社外も この画面で操作していた 旧管理画面が 生まれた

Slide 23

Slide 23 text

2013年頃 会社をまたいだ操作がしたくなった

Slide 24

Slide 24 text

01. どうしてこうなった 会社をまたいだ操作がしたくなった（2014ごろ） サイト1 A社 サイト2 サイト3 B社 サイト4 A社はサイト 1, サイト2を持つ B社はサイト 3, サイト4を持つ

Slide 25

Slide 25 text

01. どうしてこうなった 会社をまたいだ操作がしたくなった（2014ごろ） サイト1 A社 サイト2 サイト3 B社 サイト4 社内ユーザはサイト 2を操作するために A社としてログインしてページを開く必要がある

Slide 26

Slide 26 text

01. どうしてこうなった 会社をまたいだ操作がしたくなった（2014ごろ） サイト1 サイト一覧 サイト2 サイト3 サイト4 サイト1 A社 サイト2 サイト3 B社 サイト4 fluctに登録されている全てのサイトを 一覧したいというニーズが登場

Slide 27

Slide 27 text

01. どうしてこうなった 社内管理画⾯が⽣まれた（2014〜） 旧管理画面 現社内向け管理画面 作られた時期 2008年ごろ 2014年ごろ バックエンド PHP + CodeIgniter PHP + Slim フロントエンド twig React 現社内向け管理画面が 生まれた

Slide 28

Slide 28 text

01. どうしてこうなった 社内管理画⾯が⽣まれた（2014〜） 旧管理画面 現社内向け管理画面 作られた時期 2008年ごろ 2014年ごろ バックエンド PHP + CodeIgniter PHP + Slim フロントエンド twig React 社内のオペレーションは 「基本的に」ここで 行われるようになった 現社内向け管理画面が 生まれた 現社内向け管理画面が 生まれた

Slide 29

Slide 29 text

01. どうしてこうなった 社内管理画⾯が⽣まれた（2014〜） 旧管理画面 現社内向け管理画面 作られた時期 2008年ごろ 2014年ごろ バックエンド PHP + CodeIgniter PHP + Slim フロントエンド twig React 社内のオペレーションは 「基本的に」ここで 行われるようになった 一部の社内向け機能が 旧管理画面にまだある 社外ユーザ → 旧管理画面 社内ユーザ → 旧管理画面 + 現社内向け管理画面 現社内向け管理画面が 生まれた

Slide 30

Slide 30 text

2022年ごろ 旧管理画⾯の限界がきた

Slide 31

Slide 31 text

01. どうしてこうなった 旧管理画⾯の限界がきた（2022年ごろ） 旧管理画面 現社内向け管理画面 作られた時期 2008年ごろ 2014年ごろ バックエンド PHP + CodeIgniter PHP + Slim フロントエンド twig React 旧管理画面が見づらい

Slide 32

Slide 32 text

01. どうしてこうなった 旧管理画⾯の限界がきた（2022年ごろ） 旧管理画面 現社内向け管理画面 作られた時期 2008年ごろ 2014年ごろ バックエンド PHP + CodeIgniter PHP + Slim フロントエンド twig React 旧管理画面が見づらい 多言語対応など新しく やりたいことが増えてきた

Slide 33

Slide 33 text

01. どうしてこうなった 旧管理画⾯の限界がきた（2022年ごろ） 旧管理画面 現社内向け管理画面 作られた時期 2008年ごろ 2014年ごろ バックエンド PHP + CodeIgniter PHP + Slim フロントエンド twig React 旧管理画面が見づらい アーキテクチャ 古すぎて辛い 多言語対応など新しく やりたいことが増えてきた

Slide 34

Slide 34 text

01. どうしてこうなった 社外向け管理画⾯が⽣まれた（2023〜） 旧管理画面 現社内向け管理画面 現社外向け管理画面 作られた時期 2008年ごろ 2014年ごろ 2023年 バックエンド PHP + CodeIgniter PHP + Slim Go フロントエンド twig React Next.js 現社外向け管理画面が 生まれた

Slide 35

Slide 35 text

01. どうしてこうなった 社外向け管理画⾯が⽣まれた（2023〜） 旧管理画面 現社内向け管理画面 現社外向け管理画面 作られた時期 2008年ごろ 2014年ごろ 2023年 バックエンド PHP + CodeIgniter PHP + Slim Go フロントエンド twig React Next.js 社外のオペレーションは 「基本的に」ここで 行われるようになった

Slide 36

Slide 36 text

01. どうしてこうなった 社外向け管理画⾯が⽣まれた（2023〜） 旧管理画面 現社内向け管理画面 現社外向け管理画面 作られた時期 2008年ごろ 2014年ごろ 2023年 バックエンド PHP + CodeIgniter PHP + Slim Go フロントエンド twig React Next.js 一部の社外向け機能も 旧管理画面にまだある 社外のオペレーションは 「基本的に」ここで 行われるようになった 社外ユーザ → 旧管理画面 + 現社外向け管理画面 社内ユーザ → 旧管理画面 + 現社内向け管理画面

Slide 37

Slide 37 text

2023年〜 管理画⾯が3つになった

Slide 38

Slide 38 text

01. どうしてこうなった 管理画⾯が3つになってしまった 旧管理画面 現社内向け管理画面 現社外向け管理画面 作られた時期 2008年ごろ 2014年ごろ 2023年 バックエンド PHP + CodeIgniter PHP + Slim Go フロントエンド twig React Next.js 本来はこの 2つで十分なはず

Slide 39

Slide 39 text

01. どうしてこうなった 管理画⾯が3つになってしまった 旧管理画面 現社内向け管理画面 現社外向け管理画面 作られた時期 2008年ごろ 2014年ごろ 2023年 バックエンド PHP + CodeIgniter PHP + Slim Go フロントエンド twig React Next.js 社内、社外向けの機能が残っていため 使わざる得ない 本来はこの 2つで十分なはず

Slide 40

Slide 40 text

本当にあったつらい話

Slide 41

Slide 41 text

01. どうしてこうなった 本当にあったつらい話 管理画面で広告の URLを変えたら 広告がでなくなりました 運用者

Slide 42

Slide 42 text

01. どうしてこうなった 本当にあったつらい話 ● 前提 ○ 旧管理画面と現社内向け管理画面に（ほぼ）同じ機能がある ● 調査した結果

Slide 43

Slide 43 text

広告設定を更新する処理 // 旧管理画面の処理（配信される） $result = $this->oldRepository->update( $id, $name, $url, 1, ); // 現社内向け管理画面の処理（配信されない） $result = $this->newRepository->update( $id, $name, $url, null, ); ● 本来値が入ってあるべきところに社内向け管理画面はnullになっていた ● 広告配信に必須なパラメータだったため、配信ができなくなっていた こっちは 1 こっちは null

Slide 44

Slide 44 text

01. どうしてこうなった 本当にあったつらい話 機能対応していくのつらい 開発者 結局、どこから設定すれば大丈夫なの？ そもそも、複数あるの難しい 運用者

Slide 45

Slide 45 text

開発者も運⽤者も つらい状態が⽣まれてしまった

Slide 46

Slide 46 text

広告配信ミスは売上の低下だけでなく fluctを使ってくれるメディアへの 信頼にも直結する

Slide 47

Slide 47 text

01. どうしてこうなった 旧管理画⾯を葬りたい 旧管理画面 現社内向け管理画面 現社外向け管理画面 作られた時期 2008年ごろ 2014年ごろ 2023年 バックエンド PHP + CodeIgniter PHP + Slim Go フロントエンド twig React Next.js 旧管理画面の機能をあるべきところに移して 旧管理画面を葬りたい

Slide 48

Slide 48 text

⾟いなら 早く葬ればよいんじゃないか?

Slide 49

Slide 49 text

なんで今まで葬れなかったんだっけ?

Slide 50

Slide 50 text

● 難易度が高い ○ 旧管理画面のコードを読み解いて移植するのが大変 ● そもそも、問題が山積みでその対応に時間がかかっていた ○ CodeIgniter 1.7.2をベースにしているのでセキュリティの問題があり 本家のセキュリティパッチの取り込み ○ オンプレからクラウドへの移行 ○ 認証認可の仕組みの整備 ○ テンプレートエンジンをクライアントとAPIに分離 01. どうしてこうなった なんで葬れなかったんだっけ? 志半ばでプロジェクトが終わっていた

Slide 51

Slide 51 text

旧管理画⾯がずっと葬れずに つらい状況が続いている

Slide 52

Slide 52 text

AGENDA 01 どうしてこうなった 02 旧管理画⾯を葬った 03 実⾏した戦略と振り返り 04 最後に 02 01

Slide 53

Slide 53 text

今⽉、ようやく葬れそう🎉 残り2機能...!

Slide 54

Slide 54 text

● 去年の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

Slide 55

Slide 55 text

葬った結果どうなるのか

Slide 56

Slide 56 text

● 開発者、運用者ともに良い状態になる ● 開発者 ○ 旧管理画面を気にして開発、保守をしなくて良くなる ○ PHPのバージョンなど開発基盤の改善がしやすくなる ○ テストコードが不十分だったが、移行に伴ってテストコードを増やせた ● 運用者 ○ 運用コストが減る ○ モダンなUI/UXになり使いやすくなる 02. 旧管理画面を葬った 旧管理画⾯を葬れそう

Slide 57

Slide 57 text

なんで今回 葬る⽬処がたった？

Slide 58

Slide 58 text

● チームとして旧管理画面を葬ると決めた ○ 葬り作業に担当者を当て続けることができた ● 葬り切るための戦略を立てて遂行した 02. 旧管理画面を葬った なんで葬る⽬処がたった？

Slide 59

Slide 59 text

AGENDA 01 どうしてこうなった 02 旧管理画⾯を葬った 実⾏した戦略と振り返り 04 最後に 01 03

Slide 60

Slide 60 text

● 実行した戦略 ○ 計画を立てる ■ スケジュールを決める ■ WBSを作る ○ 対話をする ■ 運用者と開発者双方と対話をする ○ デバッグ環境を整える ● どういう課題があったのか、なにをしたか、どうだったかを話していく 03. 実行した戦略と振り返り 実⾏した戦略と振り返り

Slide 61

Slide 61 text

AGENDA 実⾏した戦略と振り返り 03 計画を⽴てる 対話をする デバッグ環境を整える 01 02 03

Slide 62

Slide 62 text

AGENDA 実⾏した戦略と振り返り 03 計画を⽴てる 対話をする デバッグ環境を整える 01 02 03 01

Slide 63

Slide 63 text

03. 実行した戦略と振り返り 課題感 半年経ったけど葬り終わりません

Slide 64

Slide 64 text

● あらゆるプロジェクトは4つのフォースによって統治されている 03. 実行した戦略と振り返り 課題感 荒ぶる四天王[1] [1] ＪｏｎａｔｈａｎＲａｓｍｕｓｓｏｎ ; 西村直人; 角谷信太郎. アジャイルサムライ――達人開発者への道 (p.136). オーム社. Kindle 版. 固定

Slide 65

Slide 65 text

● あらゆるプロジェクトは4つのフォースによって統治されている 03. 実行した戦略と振り返り 課題感 荒ぶる四天王[1] [1] ＪｏｎａｔｈａｎＲａｓｍｕｓｓｏｎ ; 西村直人; 角谷信太郎. アジャイルサムライ――達人開発者への道 (p.136). オーム社. Kindle 版. 固定 スコープで調整していく

Slide 66

Slide 66 text

● 葬りは納期などの外からの締め切りは（基本的に）ない ○ 困ったら延々と時間を伸ばすことができてしまう 03. 実行した戦略と振り返り 課題感 荒ぶる四天王[1] [1] ＪｏｎａｔｈａｎＲａｓｍｕｓｓｏｎ ; 西村直人; 角谷信太郎. アジャイルサムライ――達人開発者への道 (p.136). オーム社. Kindle 版. 時間がずっと荒ぶる

Slide 67

Slide 67 text

期限がないなら ⾃分で期限を決めるしかない

Slide 68

Slide 68 text

● 期限を自分で決めて上長、チームメンバーに共有した 03. 実行した戦略と振り返り 締め切りを作った 今クウォーター中にここまで 終わらせます

Slide 69

Slide 69 text

03. 実行した戦略と振り返り 締め切りを作った ● 時間の荒ぶりを抑えることができた ● 次はスコープが立ちはだかってくる 荒ぶる四天王[1] [1] ＪｏｎａｔｈａｎＲａｓｍｕｓｓｏｎ ; 西村直人; 角谷信太郎. アジャイルサムライ――達人開発者への道 (p.136). オーム社. Kindle 版. 抑えることができた

Slide 70

Slide 70 text

03. 実行した戦略と振り返り 締め切りを作った ● 時間の荒ぶりを抑えることができた ● 次はスコープが立ちはだかってくる 荒ぶる四天王[1] [1] ＪｏｎａｔｈａｎＲａｓｍｕｓｓｏｎ ; 西村直人; 角谷信太郎. アジャイルサムライ――達人開発者への道 (p.136). オーム社. Kindle 版. 抑えることができた 立ちはだかってくる

Slide 71

Slide 71 text

03. 実行した戦略と振り返り 課題感 移行対象に関連するバッチが 古い基盤に乗っているから これを機に新しい基盤に移したい いつかはやりたいけど今じゃなくて良い仕事をやりたくなる

Slide 72

Slide 72 text

● いつかはやりたい仕事もスコープにいれると、時間が荒ぶってしまう ● 決めた締め切り内に葬りが終わらない 03. 実行した戦略と振り返り 課題感 荒ぶる四天王[1] 葬りに関係がある仕事だけをスコープにする必要がある [1] ＪｏｎａｔｈａｎＲａｓｍｕｓｓｏｎ ; 西村直人; 角谷信太郎. アジャイルサムライ――達人開発者への道 (p.136). オーム社. Kindle 版. 荒ぶり始める

Slide 73

Slide 73 text

葬りに関係がある仕事って何？

Slide 74

Slide 74 text

● 必要な作業を整理し、WBSを作る ○ 旧管理画面に残っている全てのページを洗い出す ○ 運用状況の整理、移行の可否、移行作業の難易度を整理 03. 実行した戦略と振り返り WBSを作る 補足: WBS = Work、Breakdown、Structure。プロジェクトのタスクを分解して管理する。

Slide 75

Slide 75 text

03. 実行した戦略と振り返り ● 期限に合わせたスコープを適切に設定することができた ● 移行漏れがなかった ● 進捗共有に役立った WBSはどうだったか

Slide 76

Slide 76 text

AGENDA 実⾏した戦略と振り返り 03 計画を⽴てる 対話をする デバッグ環境を整える 01 02 03 02

Slide 77

Slide 77 text

03. 実行した戦略と振り返り 対話をする 私 運用者 開発者 運用者と開発者双方への対話が必要

Slide 78

Slide 78 text

03. 実行した戦略と振り返り 対話をする 私 運用者 開発者 まずは、運用者側の対話

Slide 79

Slide 79 text

03. 実行した戦略と振り返り 課題感 謎の機能の管理画面があるけど これは一体何だ ...?

Slide 80

Slide 80 text

03. 実行した戦略と振り返り 課題感 この管理画面って知っています？ なにこれ？ 半年に1回 くらい触る 運用大変なので 辞めたい ... 昔は力を入れていたが、いまは力を入れていない機能の管理画面だった 運用者たち

Slide 81

Slide 81 text

● みんなが困っていた ○ 運用コストも高いし、決まった担当者はもういない ○ 現管理画面への移行コストも高い ● その機能を適切な状態にしたかった ○ また力を入れると決めて、担当者を決めて、移行をする ○ もう力を入れないと決めて、機能自体を停止して、移行をしない 03. 実行した戦略と振り返り 課題感 ビジネスフローを見直す必要があり、自分だけでは決められなかった

Slide 82

Slide 82 text

● slackの過去ログを見て、機能について詳しそうな人を見つけ対話をした ○ どういうビジネスフローで、なにができる機能なのか ○ どれくらい使われているのか ■ アクセスログやDBの書き込みも見た ○ どれくらいお金になっているのか ○ 本来はどうあってほしいか 03. 実行した戦略と振り返り 対話をして現状を知る 機能自体を葬る方に倒したほうが良いとわかった

Slide 83

Slide 83 text

● ビジネスフローを変える判断ができるステークホルダーを巻き込んで　　　 対話をした ● 葬りたい旨を最初にステークホルダーに伝えた ○ 「使います?」だと「使います」と回答されてしまいがち ○ 「葬りたいです」とコミュニケーションをスタートした ● 集めた事実に加えて機能の代替案を用意した ○ どうしてもやりたくなったら　　　　　　　　　　　　　　　　　　　 コストはかかるが同等のことはできる状況は残した 03. 実行した戦略と振り返り ステークホルダーを巻き込んだ

Slide 84

Slide 84 text

● 無事、サービスの新規利用の停止し、管理画面の移行もしないに　　　　　 話をまとめられた ● 愚直にやっていたら、工数が追加で2, 3週間くらいかかっていた ● 運用者的に重い運用フローをなくせた 03. 実行した戦略と振り返り 対話をしてどうだったか

Slide 85

Slide 85 text

03. 実行した戦略と振り返り 対話をする 私 運用者 開発者 次に、開発者側の対話

Slide 86

Slide 86 text

03. 実行した戦略と振り返り 課題感 葬り作業 やっていくぞ なんかよくわからないけど 忙しそう 長い仕事を独立してやっていると同じチームで他人事感がでてしまう 開発者たち

Slide 87

Slide 87 text

● 全体の流れと現在地がわからないとレビューがしにくくなる ● 相談を怠ると自分だけの視点しか入らなくなる ○ 本当に良い選択肢かどうかがわからなくなる ● 他の人から応援してもらえるかどうかは大切 03. 実行した戦略と振り返り 課題感 自分の状況を知ってもらう必要があると思った

Slide 88

Slide 88 text

● 数週間ごとに、葬りについて話す会を催した ○ 対応状況のリストを見せながら現状を説明 ○ どう対応しようとしているかの説明 ○ 今、悩んでいることの説明 03. 実行した戦略と振り返り チームにコンセンサスを取った

Slide 89

Slide 89 text

● チームメンバーから応援をしてもらえていた ● コンテキストを知っていないと指摘できないようなレビューをもらえた ● 話す会でチームメンバーから良いアドバイスがもらえた ○ 芸歴が5, 6年目になってくると、基本的には大丈夫でしょという信頼を得て　　　 悩んでいることに対して深く相談するのがおろそかになっていた ○ 悩んでいるって前提のMTGを開催することでアドバイスがもらいやすかった 03. 実行した戦略と振り返り チームにコンセンサスを取ってどうだったか

Slide 90

Slide 90 text

AGENDA 実⾏した戦略と振り返り 03 計画を⽴てる 対話をする デバッグ環境を整える 01 02 03

Slide 91

Slide 91 text

03. 実行した戦略と振り返り 課題感 アカウント編集機能を移行したい

Slide 92

Slide 92 text

03. 実行した戦略と振り返り 課題感 クライアントからは読み取れない 特殊処理はあるのか ? 最終的にどのテーブルたちに 書き込まれるんだ？ 権限はどう管理しているのだろう か？ 知らないといけないことがたくさんある

Slide 93

Slide 93 text

03. 実行した戦略と振り返り 課題感 詳しい人に教えてもらうか

Slide 94

Slide 94 text

有識者がいないので コードを愚直に追うしかない

Slide 95

Slide 95 text

● 塩漬けされていた旧管理画面の処理を愚直に追うのはつらすぎる ○ テストコードから処理を逆算しようにもテストコードがない ○ fatなController ○ テンプレートエンジンなのも相まって、時代を感じるソースコード ● 大事な機能が残っているので実装漏れを起こしたら一大事 03. 実行した戦略と振り返り 課題感 どんな処理をしているかを 知りたいだけなのに … 補足: Controllerに直接SQLが書かれていたりもした。社外、社内共用の管理画面だったので権限の分岐もたくさんあった。

Slide 96

Slide 96 text

● ローカル環境にOpenTelemetry（OTel）+Jaeger（イェーガー）を導入した 03. 実行した戦略と振り返り デバッグ環境を整えた https://opentelemetry.io/ https://www.jaegertracing.io/ 補足: OTel+Jaegerの詳しい説明は https://blog.shin1x1.com/entry/php-opentelemetry-primer が参考になりました

Slide 97

Slide 97 text

03. 実行した戦略と振り返り デバッグ環境を整えた ● サービスやアプリケーションのテレメトリデータを計装、生成、収集、 送信するためのオブザーバビリティフレームワーク ○ テレメトリデータ = トレース、メトリクス、ログなど ● 受信して、加工して、送信するものなので、単体ではテレメトリデータを　　可 視化できない ● トレースを収集して、Webベースの分析UIを提供するOSS 補足: OTel+Jaegerの詳しい説明と導入は https://blog.shin1x1.com/entry/php-opentelemetry-primer が参考になりました

Slide 98

Slide 98 text

03. 実行した戦略と振り返り デバッグ環境を整えた PHPアプリケーション ② APIが呼ばれる ⑤ テレメトリデータの送信 ④ テレメトリーデータの送 信 ③ テレメトリデータを 生成 ① 管理画面で操作 ⑥ テレメトリーデータをブラ ウザで確認 ① 管理画面で操作

Slide 99

Slide 99 text

03. 実行した戦略と振り返り デバッグ環境を整えた PHPアプリケーション ② APIが呼ばれる ⑤ テレメトリデータの送信 ④ テレメトリーデータの送 信 ③ テレメトリデータを 生成 ① 管理画面で操作 ⑥ テレメトリーデータをブラ ウザで確認 ② APIが呼ばれる

Slide 100

Slide 100 text

03. 実行した戦略と振り返り デバッグ環境を整えた PHPアプリケーション ② APIが呼ばれる ⑤ テレメトリデータの送信 ④ テレメトリーデータの送 信 ③ テレメトリデータを 生成 ① 管理画面で操作 ⑥ テレメトリーデータをブラ ウザで確認 ③ テレメトリデータを 生成

Slide 101

Slide 101 text

03. 実行した戦略と振り返り デバッグ環境を整えた PHPアプリケーション ② APIが呼ばれる ⑤ テレメトリデータの送信 ④ テレメトリーデータの送 信 ③ テレメトリデータを 生成 ① 管理画面で操作 ⑥ テレメトリーデータをブラ ウザで確認 ④ テレメトリーデータの送 信

Slide 102

Slide 102 text

03. 実行した戦略と振り返り デバッグ環境を整えた PHPアプリケーション ② APIが呼ばれる ⑤ テレメトリデータの送信 ④ テレメトリーデータの送 信 ③ テレメトリデータを 生成 ① 管理画面で操作 ⑥ テレメトリーデータをブラ ウザで確認 ⑤ テレメトリデータの送信

Slide 103

Slide 103 text

03. 実行した戦略と振り返り デバッグ環境を整えた PHPアプリケーション ② APIが呼ばれる ⑤ テレメトリデータの送信 ④ テレメトリーデータの送 信 ③ テレメトリデータを 生成 ① 管理画面で操作 ⑥ テレメトリーデータをブラ ウザで確認 ⑥ テレメトリーデータをブラ ウザで確認

Slide 104

Slide 104 text

03. 実行した戦略と振り返り デバッグ環境を整えた（余談） PHPアプリケーション ② APIが呼ばれる ⑤ テレメトリデータの送信 ④ テレメトリーデータの送 信 ③ テレメトリデータを 生成 ① 管理画面で操作 ⑥ テレメトリーデータを DATADOGで確認 最後のテレメトリーデータを扱う部分は 任意の分析ツールに置き換えることもできる

Slide 105

Slide 105 text

03. 実行した戦略と振り返り デバッグ環境を整えた 編集フォームを表示 編集処理 編集した詳細を表示 アカウントの編集する流れが見れる

Slide 106

Slide 106 text

03. 実行した戦略と振り返り デバッグ環境を整えた 編集フォームを表示 編集処理 編集した詳細を表示 アカウントの編集する流れが見れる HTTPリクエストごとに 見れる

Slide 107

Slide 107 text

03. 実行した戦略と振り返り デバッグ環境を整えた このSQLと同じ処理を再実装すればよい 実行されたSQLを見れる

Slide 108

Slide 108 text

03. 実行した戦略と振り返り デバッグ環境を整えた 実行されたSQLを見れる selectしてる insertしてる このSQLと同じ処理を再実装すればよい

Slide 109

Slide 109 text

● 作業効率が上がった ○ 処理を愚直に追わなくても、ブラウザでI/Oがわかるのが助かる ● 正しい挙動を知ることができた ○ 「必要なテーブルにinsertしてなかった!」のような障害が起きなかった 03. 実行した戦略と振り返り どうだったか

Slide 110

Slide 110 text

AGENDA 01 どうしてこうなった 02 旧管理画⾯を葬った 03 実⾏した戦略と振り返り 最後に 01 04

Slide 111

Slide 111 text

● 葬るのは難しい ○ 直接的なお金にならない ○ 本当に葬って良いんだっけ？ ○ KIAIでやっていくしかない ● 今、移行しきれなかったプロジェクトを持っている人たち ○ 葬りプロジェクトを立ち上げて頑張ってほしい 04. 最後に 最後に 補足: KIAI（気合）はCARTAの社内用語（?）。気持ちをいれるときに単語を UPPERで表現をする。類義語 : YARUKI。

Slide 112

Slide 112 text

● どうしてこうなった ○ fluctは歴史的経緯で管理画面が3つになった ○ 一番古い管理画面は10年以上まえに作られたもので、その管理画面を葬りたかった ● 戦略を立てて旧管理画面葬った ○ 計画を立てる ■ 締め切りを作る ■ WBSを作る ○ 開発者と運用者双方と対話をする ○ デバッグ環境を整える ■ OpenTelemetry + Jaegerを導入 移行できそうでやりきれなかった 10年超えのシステムを葬るための戦略 まとめ