こんにちは。スタメンでCTOしております、ちゃんたく ( @tnir / @takuya_stmn ) です。 先日7月12日にTUNAGプロダクトは10周年を迎えました。（2026-07-12 14:41 JSTコミット） 2016年7月12日git init 私たちは当社主幹プロダクトであるTUNAGの日々の開発にGitHubをフル活用しており、コードの品質とセキュリティを高く保つための取り組みを継続しています。 その一環として、最近GA（一般提供）されたGitHubのネイティブなコードスキャンツールであるCodeQL-powered analysis for Code Qualityを導入し、高度なコードセキュリティ機能をフル活用しています。そのコア技術となっているCodeQLのおかげで、脆弱性の早期発見が可能になり、より安全なプロダクト開発が実現できるように設計しています。 しかし、CodeQLを運用していく中で、とある大きな「壁」にぶつかりました。 今回は、10年以上の歴史を持つリポジトリに約8年間潜んでいたレガシーコードを発見・分離し、実行時間を平均20分から3分へと短縮した取り組みをご紹介します。 課題：長すぎるCodeQLの実行時間（平均20分）とセキュリティ上のリスク CodeQLは非常に強力なツールですが、私たちのメインリポジトリで実行すると、完了するまでに平均で約20分もかかってしまっていました。 20分という時間は、CI/CDパイプラインにおいて致命的です。Pull Requestを作成してから結果が出るまで長時間待たされるため、開発者のフィードバックループが遅延し、開発体験（DX）の著しい低下を招いていました。 さらに重大な問題として、平均20分も時間がかかると、Pull RequestにおけるCIステータスのクオリティゲート（必須ワークフロー）として組み込むことができないという点がありました。マージのたびに20分待たせる運用は現実的ではなかったためです。 その結果、高度なコードセキュリティ機能を導入したものの、 CI/CDプロセス自体はセキュリティ対策として脆弱な状態（危険なコードのマージをCIでブロックできない状態） のまま運用せざるを得ないという本末転倒な状況に陥っていました。 私たちのリポジトリは10年以上にわたって運用されてきた歴史があり、コードベースの肥大化は認識していましたが、セキュリティクオリティゲートを正常に機能させるためにも、この20分という実行時間は絶対に解決すべき課題でした。 Datadog CI/CD Optimization (CI/CD Explorer) を用いた GitHub Code Quality (CodeQLパート) の実行時間分析 原因の特定：導入者は不在…しかし「Gitの歴史」が答えを教えてくれた なぜこれほどまでに時間がかかっているのか、解析のログや対象ファイルを詳細に調査しました。 しかし、調査対象となったコードは、現在在籍しているエンジニアやマネージャーの誰も背景を知らないブラックボックスと化していました。大昔に導入されたものであり、当時の関係者はすでに社内に一人も残っていなかったためです。 ここで力を発揮したのが、すべての変更履歴を正確に記録し続けていたGitでした。 Gitのコミット履歴やそのblameを遡って調査した結果、約8年前にサードパーティーから購入し、リポジトリ内に配備された 「管理画面用のUIライブラリ」 が原因であることが判明しました。一般的な社内エンジニアが実装したJSライブラリやビジネスロジックではなく、静的ファイルとしてリポジトリ内に鎮座し続けていたベンダー製のコードでした。 CodeQLは律儀にこの約8年間放置されていた外部ライブラリの隅々まで脆弱性スキャンを行っていました。私たちが日常的に手を加えることのない古いベンダーコードの解析に、CIの貴重な時間を大量に奪われていました。 解決策：235 MBに及ぶコードの切り出しと別リポジトリでの分離運用 原因が特定できれば、やるべき方針は明確でした。 今回特定されたサードパーティー製ライブラリは、コードの分量が約100 MBにも及ぶ非常に巨大なものでした。これほど大規模なコードを、メインプロダクトの単一リポジトリ内で維持し続ける必要性はありません。 あえてモノリシックに維持するのではなく、メインプロダクトとは明確に 「ライフサイクルの異なるソフトウェア」として、意図的に別リポジトリへ切り出して独立管理するのが適切である と判断しました。 そこで、メインリポジトリからはこの100 MBのUIライブラリを完全に削除し、別リポジトリとして独立させて異なるライフサイクルで管理する施策を実行しました。 驚きの結果とセキュリティクオリティゲートの実現 この235 MBのレガシーコードをメインリポジトリから削除した結果、CodeQLの実行時間は平均20分から「3分」へと劇的に短縮されました！ 実行時間が3分になったことで、CodeQLをPull Requestの必須クオリティゲートとして正式に設定可能となり、セキュリティリスクを抱えたコードがマージされるのをCI上で確実にブロックできるようになりました。 開発者のフィードバックループ（DX）が飛躍的に向上しただけでなく、CI/CDパイプライン全体のセキュリティ強度を真の意味で高めることができました。 ビルドパイプライン ビルドパイプラインは創業時の2016年7月よりRuby on Railsに付属のSprocketsベースのアセットビルドを利用していました。7年強続いたアセットパイプラインを2023年秋に見直していたため、Yarn+esbuildによる実装に修正するプロジェクトがあり、そこから3年ほどはアプリケーションレイヤーのフロントエンドアセットパイプラインを問題なく維持運用していました。 なお、ベースとなるサードパーティー製ライブラリはgulpが設定されていましたが、当該プロダクトへの導入時点よりwebpackでのビルドとして開発されていました。この点はフロントエンドパイプラインをモダナイズする上ではとても助かる点でした。 Bootstrap 4ベースのUIライブラリ 今回切り出した「サードパーティー製ライブラリ」はBootstrap 4.0.0 (alpha) ベースであり、かなりレガシーでした。筆者自身は5年以上前からBootstrap 5.0、そして、最新の5.3に関わるまで1ユーザーでもあるものの、Tailwind CSS v4.3（執筆時の最新バージョン）ベースに切り替えるプロジェクトを未着手のまま温めている状況です。 当該ページ群を使うユーザーはTUNAG全体の大規模なユーザーベースと比べると少ないのですが、いつかはやらなくてはならないタスクだと認識しており、LLMを使って一気に対処してくれるエンジニアを継続募集しています。 読者の皆様へのTakeaway（持ち帰り知識） 今回の私たちの経験から、皆さんの開発現場でも活かせるポイントをまとめました。 CI実行時間の短縮は「セキュリティクオリティゲート化」の絶対条件 セキュリティスキャンツール（SAST）を導入しても、実行時間が長いとPRの必須チェックに設定できず、セキュリティプロセスが形骸化・脆弱化してしまいます。「スキャンを高速化し、必須クオリティゲートとしてCIに組み込むこと」こそが、堅牢なCI/CDセキュリティを実現する鍵となります。 ライフサイクルが異なる巨大コードは別リポジトリへ分離する 200 MBを大幅に超える巨大なサードパーティー製ライブラリをメインリポジトリに含め続けると、静的解析やビルド時間のボトルネックになります。プロダクト本体とライフサイクルが異なるソフトウェアは、あえて同一リポジトリで維持せず、別リポジトリとして分離・運用することがアーキテクチャ上も有効です。 Gitの履歴は属人化したナレッジを救う最強のドキュメント 当時の担当者が一人も残っていない状況でも、Gitの履歴がしっかり残っていれば「いつ・なぜ・何が導入されたのか」を正確に突き止めることができます。歴史あるリポジトリの調査において、Gitのログを辿る重要性を再確認しました。 おわりに CodeQL-powered analysis for Code Qualityは、スキャン対象を最適化しプロジェクトの構成を適切に保つことで、本来の優れたパフォーマンスを発揮してくれます。 10年以上の歴史があるリポジトリでも、適切な棚卸しとアーキテクチャの見直しを行えば、DXとセキュリティの両立は十分に可能です。もし「CIが遅くて必須化できない」とお悩みの場合は、リポジトリ内に長年鎮座している外部コードや分離可能なモジュールがないか、ぜひ探してみてください！ また、われわれと一緒にレガシーアプリケーションの継続的モダナイズをしたいエンジニアを募集しています。詳しくは当社採用サイトをご覧ください。

はじめに こんにちは、AIテクノロジーグループの検索チームです。 昨年公開した エニグモのAI活用を支える「AIテクノロジーグループ」について紹介します！ では、グループ全体の体制と各チームの役割を紹介しました。 本記事ではそのなかの検索チームに焦点を当て、日々どんなシステムを運用し、どんな案件を進めているかをもう一段詳しくお伝えします。 検索チームは名前のとおり BUYMA の検索システムを担当していますが、それだけではありません。 データサイエンティストが開発したモデルを安定して動かす MLOps と、生成AIを使ったシステムの実装・PoC も担っています。検索基盤から機械学習の本番化、AI の実装までを同じチームが見ることで、インフラからアプリケーションまで一気通貫で課題を解けるのがこのチームの特徴です。 対象読者としては、検索・MLOps・データ基盤まわりのエンジニアの方を想定しています。検索エンジニアという職種は専門性が高く、会社によって担当範囲が大きく違うものと思われます。BUYMA の検索チームが実際に何をしているか、その具体性を示し、この領域のイメージを持ってもらうことが、この記事の目的です。 検索チームの役割 検索チームの業務は、次の3つの柱で整理できます。グループ紹介記事で触れた内容を、本記事では案件の粒度まで落とします。 BUYMA の検索システムの運用改善 大小あわせて8つの検索システムを運用し、その中核である商品検索では、ユーザーが探している商品を見つけられる状態を維持する。 MLOps データサイエンティストが開発したモデルを、求められるレイテンシ・可用性・セキュリティを満たす形で本番に載せ、繰り返し改善できるサイクルをつくる。 AIシステムの開発・PoC 生成AIをはじめとするサービスを使い、BUYMA 向けの AI 機能を実装し、PoC で終わらせず運用に載るところまで持っていく。 検索チームの3つの柱。検索、MLOps、生成AIの実装・PoC 担当範囲は検索エンジンそのものにとどまりません。検索API、商品データの投入、中間DB（MySQL）、クラスタ、監視、CI/CD まで、検索と機械学習サービスが動くための一式を見ています。 これらの基盤は Google Cloud（以下、GCP） 上で運用しており、GKE、Cloud Run、Vertex AI などを組み合わせて構成しています。 検索システムの運用改善 検索システムの運用改善では、まず「検索が止まると何が起きるか」、次に「なぜ本体から独立できたか」、最後に「独立したからこそ進んでいる Elasticsearch への載せ替え」の順で書きます。検索を止めないことが前提で、そのうえで基盤を進化させる、というのがこの領域の進め方です。 1. 検索が止まると、発見も購入も止まる BUYMA は世界中のファッションアイテムを購入できるマーケットプレイスです。 出品中約630万点のなかから、ユーザーが「これだ」と思える商品にたどり着く。その入口が検索です。キーワードやカテゴリ、ブランド、価格などの条件を組み合わせて探す体験が、発見と購入を支えています。 ピーク時の検索リクエストは約400 RPS に達します。検索が止まると、画面は残っていても、購入までの導線が途切れます。 サービスの主軸を担っている、という実感はここにあります。 絞り込みやファセット、並び順を含めた現行の検索体験を維持したまま、基盤を進化させていく必要があります。 検索チームが管理している検索システムは、大小あわせて8つあり、規模も用途もさまざまです。本記事ではそのうち、ユーザーの発見と購入に直結する商品検索に絞って書きます。 商品検索では、GKE 環境の更新、中間DBの MySQL、検索API、インデックス更新までを一体で見ています。いまは検索を止めない運用と基盤更新が中心で、検索結果の精度をよりよくしていくのはその先です。 検索システムの変遷については、以前の刷新の記録もあります。 BUYMAの検索システムを刷新したお話 2. GCP 移設と同時に境界を設け、BUYMA 本体から独立できた 2024年7月に、大小あわせて8つの検索システムをすべて GCP へ移設しました。移設と同時に、BUYMA 本体との境界も設けています。 【当時の課題】 移設前は、検索の大きな変更が BUYMA 本体（Rails / PHP 側）のリリースサイクルに引きずられやすい構造でした。検索エンジンのインデックスの洗い替えなどを、本体と切り離して進めにくい状態です。 【設けた2つの境界】 参照 : 本体は検索エンジンの実装を意識せず、検索APIのインタフェースを通じて検索を利用する 更新 : 商品データの更新は、MySQL を挟んで検索側へ渡す 検索APIと検索エンジンは、検索チームのリポジトリとデプロイで完結します。この境界があることで、検索側の基盤変更が BUYMA 本体のリリースを待つ必要がなくなりました。 参照は検索API、更新はMySQL 8つすべてが同じ切り出し方になっているわけではありません。 商品検索をはじめとする主要な検索は、検索APIを境界に独立した構成 で運用しています。残りのシステムは GCP 上で動いていますが、本体との結合の度合いはそれぞれ異なります。 【独立して進めるようになったこと】 独立した検索では、 検索領域だけの案件を、検索チームの裁量で企画・検証・リリースしやすくなった ことが大きいです。マイクロサービス化の効果は、運用が楽になることだけではありません。 たとえば次のような業務を、本体の大規模リリースに乗せることなく進められます。 検索クラスタの構成変更やスケール インデックスの投入パイプラインの刷新 検索APIの置き換え 検索エンジンそのものの検証と段階的な載せ替え 辞書やマッピングの更新を、検索を止めずに反映する仕組み 通常は BUYMA 本体が従来どおり検索APIを呼べばよく、裏側の実装は検索チームが差し替えられます。デプロイは検索側で完結します。インタフェースやデータの投入口を変えるときだけ、本体側のリクエスト処理や更新処理まで検索チームが担います。専門性の高い検索の問題を、検索ドメインの中で完結して解ける状態です。検索を独立したプロダクトとして扱える、というのがいまの進め方の前提です。 3. Solr から Elasticsearch への載せ替えを、検索チームのペースで進める 独立して案件を進められるようになった具体例が、現在進行中の Solr から Elasticsearch への移行です。 【当時の課題】 商品検索を支えているのは Apache Solr です。GCP 上で同一データを持つ2クラスタ、合計24ノードの冗長構成です。スケールや運用の柔軟性を上げたくても、本体と結合したままではエンジンごと変える判断は現実的ではありませんでした。 いまは同じ GCP 上で、Elasticsearch への置き換えを検証・構築しています。 【移行で外せない要件】 出品中約630万点の商品を対象にした全文検索 ブランド・カテゴリ・価格などのファセット 現行に近い並び順・グループ化 ピーク約400 RPS でも、ユーザー向けの応答速度を維持すること インデックスの洗い替えのために検索を止めないこと 【解決へのアプローチ】 エンジン選定 フルマネージドの検索サービスも検討しましたが、ファセットや複雑なソートを現行どおり載せるには、カスタマイズの余地が足りませんでした。既存の GCP 環境との統合のしやすさも踏まえ、Elasticsearch を GKE 上で運用する方針にしています クラスタ構成 Solr では安定運用のために必要だった2クラスタの冗長構成を、Elasticsearch では1クラスタにまとめる想定です 検索APIの刷新 検索APIとデータ投入も検索システム側で作り直しています。本体向けのインタフェースは現行に合わせつつ、裏側は Solr 前提の実装から切り離します。現行の検索APIは Python で、CPU 使用率が高く、アクセスが増えると 20〜30 インスタンスが起動し、コストも増えやすい状態です。新しいAPIは Go に書き換え、Cloud Run 上に設置済みですが、本番トラフィックの切替はこれからです クエリの見直し Solr 向けのクエリをそのまま写したところ、見た目の検索結果は近づけたつもりでも、本番相当の負荷をかけるとおよそ200 RPS で頭打ちし、ノードの CPU が飽和しました。現行の検索体験は残したまま何度もクエリの組み立てを見直し、ピーク約400 RPS の要件に乗せられたときは大きな達成感がありました 現行 Solr は同一データの2クラスタ。Elasticsearch は1クラスタにまとめる 検索がマイクロサービスとして独立しているからこそ、現行 Solr を止めずに並行して検証し、検索チームのペースで載せ替えを進められています。 MLOps：モデルを「定期的に、安全に」本番へ載せる 検索チームは、もともと検索エンジニアリングの専任でした。 推薦や機械学習の案件が増えるにつれて、モデルを本番で動かし続ける基盤、いわゆる MLOps も担当するようになりました。 実験を本番の定期ジョブに載せ、運用を回す 【役割分担】 データサイエンティストは、施策の設計、特徴量、学習、評価を担います。検索チームは、その成果物がオンラインの推論でも、毎日・毎週のバッチでも、想定した品質で動き続けるための実行基盤を担います。 不正検知については、分析・導入判断の経緯を別記事でも紹介しています。検索チームの役割は、そうしたモデルを「検証で終わらせず、運用に耐えるサービス」にする側です。 対応例: 不正対策の機械学習導入までに検証したこと 【基盤の構成】 学習・推論は Vertex AI Pipelines（Kubeflow Pipelines）上のパイプラインとして定義し、前処理・学習・予測・評価などのコンポーネントはコンテナイメージとしてバージョン管理します。GitLab CI/CD でテスト、ビルド、デプロイまでつなぎ、推論結果を下流のサービスやバッチが受け取れる形で届けます。 パイプラインには、推薦や不正対策、定期バッチで回すスコア系など、オンラインの推論とバッチの両方を載せています。 データサイエンティストの実験を、CI/CD と Vertex AI Pipelines を経て形にする 【いちばん詰まったところ：バージョン整合】 パイプライン定義、コンポーネント、下流のジョブで共通ライブラリを使い回すときのバージョン整合です。片方だけ新しいイメージに載せ替えると、学習は通っても、推論側で想定どおり動かないことがあります。派手な障害ではないのですが、原因の切り分けに時間がかかるタイプです。コンポーネントとパイプラインのバージョンを分け、共通ライブラリの整合を取りながら回すようにしたことで、大きな安心感を得られました。 【この領域の面白さ】 機械学習システムは、一度出せば終わりではありません。データが変わり、モデルが更新され、しきい値も動きます。そのたびに同じ品質で出し直せる状態を維持します。レスポンス速度や可用性、セキュリティは、検索APIと同じ目線で設計します。 ここでの面白さは、アルゴリズムそのものというより、 実験を本番の定期ジョブに載せ、運用を回せる状態にすること です。 AIシステムの開発・PoC 以前は検索運用と MLOps が主でしたが、生成AIの API が実用的になったこともあり、AI を使ったシステムの開発や PoC も担当するようになっています。 テキストや画像を対象にしたチェック処理を本番に載せるほか、商品検索とつながる「AIでさがす」にも関わっています。 生成AIによる感情分析・各種チェック 【対象にしているもの】 BUYMA は、出品者と購入者がメッセージを交わす CtoC の場でもあります。正当な商品のやりとり（在庫、サイズ、色味、配送追跡、公式サイトとの照合）と、スパム・フィッシング・外部誘導を切り分ける必要があります。 【ルールベースだけでは足りない理由】 ルールベースだけでは、新しい手口に追いつけません。逆に「外部URLがある」「BUYMA の外のサイトだ」だけで止めると、正常な購入会話まで不可となってしまいます。 【実装しているチェック】 検索チームでは Gemini を使い、次のようなチェックをマイクロサービスとして実装しています。 問い合わせメッセージのスパム・フィッシング判定 感情分析など、テキストのトーンやリスクを見る処理 画像に含まれる、外部サイトへの誘導につながりやすい要素の検出 【運用上の判断】 同期の API と、まとめて処理するバッチの両方があります。過検知と見逃しのどちらを許容するかは、カスタマーサポートや不正対策の運用チームとすり合わせます。モデルの世代が上がったときは、精度・速度・コストのバランスを見て載せ替えるかどうかを決めます。速いが高コスト、あるいは高精度だがレイテンシが合わない、といった上位モデルを見送る判断もここに含まれます。 【BUYMAドメインの制約】 検索で「現行の体験を維持したまま裏側を差し替える」のと同じで、生成AIでも、まずドメインの制約から設計します。ファッションの CtoC では、韓国・欧米の正規 EC の URL や配送会社の追跡リンクは日常的に登場します。その文脈を無視した汎用のスパム判定では、実運用には耐えません。 生成AIと商品検索の接点：「AIでさがす」 BUYMA の「AIでさがす」は、記事コンテンツを根拠にした提案へと進化しています。 ここは、検索チームが運用する商品検索APIと、生成AI側のキーワード生成・文書検索が接続する領域です。検索基盤が独立していることで、AI 側の変更と、商品検索エンジン側の変更を並行して進められます。 対応例: 「AIでさがす」サービスのリニューアル これから取り組むこと 検索チームとして、目の前にある大きな業務は次のようなものです。 Elasticsearch の品質確認と、Go 製検索APIを含めたトラフィックの段階的な切替 独立した検索基盤の上で、検索結果の精度をよりよくしていくこと 推薦・不正検知などの ML パイプラインを、より安定して回し、より載せやすくすること 生成AIのチェックや AI 検索を、既存の検索・ML 基盤と無理なくつなぐこと 「完成した基盤を保守する」フェーズではありません。切り離した検索プラットフォームの上で、エンジンも ML も AI も、まだ載せ替えと拡張の途中にあります。新メンバーには、アーキテクチャ設計から主導していただく余地が十分にあります。 インフラから API、データ、評価までを、同じチームで担っているのも醍醐味の一つです。 さいごに 検索チームは、出品中約630万点を支える商品検索をはじめ、BUYMA の検索を止めないことと、機械学習と生成AIを本番に載せることを並行して実施しています。 2024年の GCP 移設で検索APIを境界にして商品検索を独立させたことが、いまの Elasticsearch 移行のような「検索単体の大きな案件」を可能にしています。 現在は検索チームとしての幅を広げ、検索基盤・MLOps・生成AIまでを見ています。 今後はデータ基盤チーム等と統合し、よりプラットフォーム全体を見る体制へ変遷していく予定です。検索に閉じず、データを集め、モデルを回し、サービスとして届けるところまでを同じ視点で扱える場が、さらに広がっていくと考えています。 ここまで、いま私たちが担当しているものと、これから広がっていく業務の範囲を書いてきました。少しでも業務イメージが伝われば幸いです。 株式会社エニグモ すべての求人一覧 hrmos.co

こちらの記事は「MEDLEY Summer Tech Blog Relay」の17日目の記事です。 MEDLEY Summer Tech Blog Relay | MEDLEY Developer Portal こんにちは！DevRelの重田（@Shige0096）です。 メドレーでは夏企画として『MEDLEY Summer Tech Blog Relay』と題して、ブログリレーを開催します！ 7/13(月)〜8/21(金)まで毎日異なるメンバーが... developer.medley.jp はじめに 株式会社メドレー 人材プラットフォーム本部でエンジニアをしています、佐藤です。 直近の7月にエンドユーザー向けの開発担当チームのリーダーから、プラットフォーム開発担当のチームへリーダーとして異動しました。1ヶ月半ほど経ちましたので、異動後のマインドセットの変化や学びを記載させていただければと思います。 プラットフォームチームについて 弊社人材プラットフォーム本部でのプラットフォームチームでは、開発者体験の向上やプロダクト開発のスピード・品質の持続的な向上を目的とし、現状以下のような取り組みを実施しています。 システムとして必須のサブドメインを共通基盤として切り出し・MSA化 Ruby on Railsをはじめとした利用ライブラリのバージョンアップの仕組み化 CI/CD・監視アラート等の最適化 AIを利用したバグ検出→自動解消の仕組み化 AIでの開発を前提とした開発環境の整備　など ※メドレーでは生成AI利用のガイドラインが社内で展開されており、各部門の業務ではそのガイドラインに沿って利用をしています。 異動前にやっていたこと エンドユーザー向けの開発を行っていたときは、当然ですが担当ドメイン領域においての価値の最大化を目的としていました。PdMと協力しながら、比較的短期のプロジェクトや改善施策を継続的にリリースする体制を作る、という動きです。 品質問題がない状況で、早く出し、早くフィードバックを得て、KPIに対し効果が出ればそのまま継続、悪影響が出たら切り戻し、という形でフィードバックサイクルを高速に回すことを主眼においていました。 いち開発者としてのペインも感じる場面が多かったため、プラットフォームチームへの異動後はそういったものを高速で解消していこうというマインドセットでいました。 異動後の戸惑い 異動後は、チームの現状の取り組みを把握しつつ、以下のような業務を実施していました。 共通基盤への機能追加 既存コードの管理体制とCDの整備 運用業務の定義と対応計画の立案 開発環境の整備 実施する中で、「1〜2日程度で終わると思っていたものが思ったよりかかる」「一つ一つの理解に時間がかかる」といった、自分の中の見込みとのズレを感じるようになり、想定よりスピードが出せないことに焦りと戸惑いを感じていました。 技術スタック自体は異動前と大きく変わっていないのにうまくいかない。この違和感の正体を振り返ると、開発の性質の違いとして以下の2点があったように思います。 実感した違い 1. サービス間の責務を慎重に取り扱う必要がある 異動前は基本的に単一ドメインとそれに紐づくシステムの開発が中心だったため、責務の境界をコードレベル以上に意識することはあまりありませんでした。自分のドメインの中か外かが自明で、外なら別のチームに相談すれば済んだためです。 一方で、共通基盤と各システムをまたぐ開発では、どちらに責務を持たせるべきか、依存はどの程度にとどめるべきかを、こちらが決める側に回ります。 象徴的だったのが、共通基盤側で起きた状態変化を各アプリケーションへ伝える仕組みを検討したときのことです。最初に着手したのは手段の比較でした。 双方向で通信できるようにし、共通基盤側からアプリケーション側のAPIを叩く 共通基盤が非同期のイベントとして流し、アプリケーションが受け取る アプリケーション側でポーリングする などいくつか手段を比較検討し、方式を決めかけていました。 途中で気づいたのは、比較していた案のいくつかが 「共通基盤が各アプリケーションのことを知っている」 形になっていたことでした。基盤側から各アプリケーションへ通信するには、少なくとも宛先のURL・認証情報など、個々のアプリケーションによって変わる情報を基盤が知っている必要があります。 ネットワーク的には、経路を用意すれば双方向の通信自体は実現できます。共通基盤化して間もない時期で、利用するアプリケーションもまだ少ない状況でした。それでもこの形を採らなかったのは、共通基盤は利用する側が増えていく前提のものなので、 利用側が1つ増えるたびに基盤が知るべきことが増える 構造は許容しないほうがよいと判断したためです。 最終的には要件の再定義により、リアルタイム性の要否を再検討した上で、共通基盤側で起きた状態変化をアプリケーション側が特定のトリガーで取得しに行く形に落ち着き、責務も依存もむやみに増やさずに済みました。 ただ、初手で実装の手段検討から入ってしまったぶん、時間のロスは大きかったように思います。 時間のロス以上に気にしていたのは、判断を誤ったまま進めてしまう可能性のほうでした。依存の形は、各アプリケーションがそれに乗ったあとで変えようとすると、相応のコストがかかる可能性が否定できません。誤った判断がそのまま負債として残り得ますし、問題として表面化するのは利用側が増えたあとになりがちです。責務や依存を慎重に取り扱う必要があると感じたのは、この後戻りのしにくさがあるためでした。 2. 「利用者」として理解していたつもりの環境を、「提供者」としては理解できていなかった エンドユーザー向けの開発を行っていた際は、自身が「利用者」として開発環境を利用しており、その特徴は十分に把握しているつもりでした。「提供者」の目線で見ると、まったく足りていませんでした。 開発用のテストデータの修正をメンバーと進めていたときのことです。利用者としては「夜間の複数のデータ処理バッチによって、テストデータが投入されたサンドボックス環境が作られ、始業時には利用可能になる」という理解でした。しかし実際には、環境ごとのデータ反映条件に差分があることが、事前検証で明らかになりました。 提供者としては、そのデータがどのようなワークフローで作られるのか、どの環境には自動で投入されてどの環境には投入されないのか、参照元が環境ごとにどう切り替わるのかまでを把握している必要があります。どこに手を加えるとどこに副作用が出るのかも、そこが分かっていなければ判断できません。これらが十分でなかったため、協業していたメンバーからの問題提起を理解するのに時間を要してしまいました。 利用者としての習熟は、提供者としての理解の代わりにはならない というのが率直な実感でした。「一つ一つの理解に時間がかかる」と感じていた原因の多くは、必要な理解の種類が変わっていたことに気づけなかったことにありました。 この一件をきっかけに、提供側の視点で環境全体のワークフローを把握し直しました。利用者と提供者の違いは、同じプロダクトを触っていても気付きにくいものだと思います。 おわりに 異動前は「早く出して、早くフィードバックを得る」体制を作ることを優先していました。可逆性のあるものは出す、という判断軸で見込みを立てていたということです。 一方で、上記のような経験から、現在は事前の調査・検討・理解にリソースを割いた上で判断することを重視するよう、軸が変わってきています。 今回の異動で2つの立場を経験したことは、開発における判断軸が場所によって変わるものだと知る良い機会になりました。同じようにプラットフォームエンジニアへの転身を控えている方の参考になれば幸いです。 We’re hiring メドレーでは、SREをはじめ「医療ヘルスケアの未来をつくる」ことに取り組むエンジニアを募集しています。ご興味をお持ちいただけましたら、ぜひご応募ください。 ※カジュアル面談も大歓迎です！ご希望の際は、「その他の項目（希望記入欄）」にてその旨をご記載ください。 メドレーで働く｜株式会社メドレー メドレーでの働き方や人事制度、求人情報など、採用に関する情報をご紹介します。 www.medley.jp MEDLEY Summer Tech Blog Relay 18日目の記事は牧さんです！お楽しみに！！