2025年6月19日、サンクトペテルブルクで開催されたPiterJS #79に参加しました。この回のテーマは、派手な新機能の作り方ではなく、すでに存在するシステムをどう保守するかという、かなり現実的なものでした。扱われたのは、モニタリング、デプロイ、リファクタリングです。
プログラムもそのテーマに沿っていました。Pavel Shlykov氏は古いモノリスの改善について、Alexander Panfilov氏はFrontOpsについて、Igor Antonov氏はWebアプリケーションのパフォーマンス指標について話しました。私は3つのセッションすべてから、実務に持ち帰れるメモを残しました。
予想外だったのはQ&Aです。セッション中に質問した結果、Q&Aでベスト質問として賞を2つ受け取りました。小さな出来事ですが、むしろこれが一番記憶に残っています。オフラインの技術ミートアップには、録画を見るだけでは得にくい価値があると改めて感じたからです。発表を聞くだけでなく、その場で自分の理解を確かめ、登壇者に直接問い返すことができます。
新しさよりも「保守」が中心だった
フロントエンド系のイベントは、新しいフレームワーク、API、抽象化の紹介が続く場になりがちです。PiterJS #79はもう少し地に足がついていました。告知でも、すでに作られたソフトウェアをどう支えるかがテーマとして示されていました。
これは重要です。実際のエンジニアリングの多くは、最初のリリースが成功したあとに始まります。レガシーなモノリスだからといって、それだけで悪いシステムとは限りません。また、「モダナイズ」が必ずしも全面的なリライトを意味するわけでもありません。実務で問うべきことはもっと具体的です。今どの制約が本当に問題になっていて、どの変更なら、取り除くリスク以上の新しいリスクを増やさずに状況を改善できるのか。
そう考えると、3つのセッションはきれいにつながります。リファクタリングはコードを変えます。FrontOpsは、フロントエンドをどうビルドし、パッケージし、届け、運用するかを変えます。パフォーマンス改善は、その結果をどう測るかを変えます。別々の話に見えても、成長した実システムを理解可能で制御可能な状態に保つという、同じ問題の異なる層です。
FrontOpsはDockerfileより広い
ミートアップで残したメモの一つが、Dockerを使ったFrontOpsでした。ただし、ここは用語を混同しないほうがいいと思います。DockerはFrontOpsのために使える道具の一つであって、FrontOpsそのものの定義ではありません。
フロントエンドの責任は、npm run buildが成功したところで必ず終わるわけではありません。本番では、再現可能なビルド、成果物のパッケージング、設定値の受け渡し、リリースのロールバック、キャッシュの挙動、障害の観測方法などを誰かが考える必要があります。コンテナはその一部を予測しやすくできますが、運用上の判断そのものを代替してくれるわけではありません。
ここには大事な区別があります。ビルド成功が証明するのは、ビルドが完了したということだけです。正しくデプロイできること、本番で正しく動くこと、問題が起きたときに簡単に復旧できることまでは証明しません。
パフォーマンス改善は「遅い」を定義するところから始まる
パフォーマンスのセッションは、問題設定が特に実践的でした。事前の説明では、読み込み速度に影響する要因、複数のフロントエンド・パフォーマンス指標、「遅い」を定量化する方法、そして最適化が常に必要とは限らない理由まで扱うとされていました。
最後の点は意外と重要です。「もっと速くする」は客観的な目標に見えますが、指標もユーザーに見える問題もないまま進めると、高価な推測になりがちです。パフォーマンス改善の基本は、何が遅いのかを定義し、測定し、ボトルネックを特定し、関係する変更を一つ行い、もう一度測ることです。
もちろん、単一の指標がそのままユーザー体験になるわけではありません。それでも、共通の物差しにはなります。測定なしの最適化は、技術的には面白くても、本当に重要だった問題を改善した証拠がない変更の集まりになりかねません。
Q&Aでミートアップの価値が変わった
録画はあとから見られますし、リンクも保存できます。一方で、発表の周囲で生まれるやり取りは、あとから同じ形で再現するのが難しいものです。良い質問を作ろうとすると、自分が何を理解できていないのかを、他のエンジニアが答えられるほど具体的な形に圧縮する必要があります。
賞を2つもらえたのは素直にうれしかったですが、より重要だった学びは単純です。オフラインのミートアップは、ライブ版YouTubeプレイリストとして消費するより、参加するつもりで行ったほうがはるかに価値が大きくなる。
良い技術質問には、たいてい文脈と制約があります。「最適なアーキテクチャは何ですか？」よりも、レガシーシステムを全面的に書き直せない場合にトレードオフがどう変わるのか、後方互換性を保ったままデプロイしなければならない場合はどうするのか、指標は改善したのにユーザーが体感する差がない場合はどう考えるのか、といった問いのほうが具体的です。
すべての質問を気の利いたものにする必要はありません。前提、適用範囲、失敗しうる条件を明らかにできれば十分です。
次の技術ミートアップに持っていきたいルール
- そのセッションが自分にとってなぜ重要かを決めておく。 始まる前に、実際の問題や不確実な点を一つ書き出す。
- 登壇者の経験と自分のシステムを分けて考える。 有益な事例は証拠にはなるが、万能なレシピではない。
- トレードオフを聞く。 「どのツールが一番ですか？」より「どんな条件なら使いませんか？」のほうが多くを教えてくれることがある。
- フォローアップを一つ残す。 ミートアップ後に確認する、試す、読む、といった次の行動につながるメモにする。
- 説得力のある発表と、本番環境での証明を混同しない。 アーキテクチャ、デプロイ、パフォーマンスの判断は、自分の環境で検証する必要がある。
PiterJSのあとに残ったもの
一度のミートアップの影響を大げさに語るつもりはありません。PiterJSから万能なアーキテクチャ設計の答えを持ち帰ったわけではありませんし、良い発表がドキュメント、プロファイリング、テスト、本番データの代わりになるわけでもありません。
それでも、持ち帰ったものは具体的でした。レガシーなモノリスのモダナイズ、Dockerを使ったFrontOps、Webパフォーマンスの測定に関する実用的なメモ。Q&Aで受け取った2つの賞。そして、地域の開発者コミュニティには、実際に足を運ぶ価値があるという再確認です。
録画は発表そのものを残せます。残しにくいのは、その周りで生まれた会話です。