はじめに

株式会社メドレー人材プラットフォーム本部でエンジニアをしています、佐藤です。

直近の7月にエンドユーザー向けの開発担当チームのリーダーから、プラットフォーム開発担当のチームへリーダーとして異動しました。1ヶ月半ほど経ちましたので、異動後のマインドセットの変化や学びを記載させていただければと思います。

プラットフォームチームについて

弊社人材プラットフォーム本部でのプラットフォームチームでは、開発者体験の向上やプロダクト開発のスピード・品質の持続的な向上を目的とし、現状以下のような取り組みを実施しています。

システムとして必須のサブドメインを共通基盤として切り出し・MSA化
Ruby on Railsをはじめとした利用ライブラリのバージョンアップの仕組み化
CI/CD・監視アラート等の最適化
AIを利用したバグ検出→自動解消の仕組み化
AIでの開発を前提とした開発環境の整備　など

※メドレーでは生成AI利用のガイドラインが社内で展開されており、各部門の業務ではそのガイドラインに沿って利用をしています。

異動前にやっていたこと

エンドユーザー向けの開発を行っていたときは、当然ですが担当ドメイン領域においての価値の最大化を目的としていました。PdMと協力しながら、比較的短期のプロジェクトや改善施策を継続的にリリースする体制を作る、という動きです。

品質問題がない状況で、早く出し、早くフィードバックを得て、KPIに対し効果が出ればそのまま継続、悪影響が出たら切り戻し、という形でフィードバックサイクルを高速に回すことを主眼においていました。

いち開発者としてのペインも感じる場面が多かったため、プラットフォームチームへの異動後はそういったものを高速で解消していこうというマインドセットでいました。

異動後の戸惑い

異動後は、チームの現状の取り組みを把握しつつ、以下のような業務を実施していました。

共通基盤への機能追加
既存コードの管理体制とCDの整備
運用業務の定義と対応計画の立案
開発環境の整備

実施する中で、「1〜2日程度で終わると思っていたものが思ったよりかかる」「一つ一つの理解に時間がかかる」といった、自分の中の見込みとのズレを感じるようになり、想定よりスピードが出せないことに焦りと戸惑いを感じていました。

技術スタック自体は異動前と大きく変わっていないのにうまくいかない。この違和感の正体を振り返ると、開発の性質の違いとして以下の2点があったように思います。

実感した違い

1. サービス間の責務を慎重に取り扱う必要がある

異動前は基本的に単一ドメインとそれに紐づくシステムの開発が中心だったため、責務の境界をコードレベル以上に意識することはあまりありませんでした。自分のドメインの中か外かが自明で、外なら別のチームに相談すれば済んだためです。

一方で、共通基盤と各システムをまたぐ開発では、どちらに責務を持たせるべきか、依存はどの程度にとどめるべきかを、こちらが決める側に回ります。

象徴的だったのが、共通基盤側で起きた状態変化を各アプリケーションへ伝える仕組みを検討したときのことです。最初に着手したのは手段の比較でした。

双方向で通信できるようにし、共通基盤側からアプリケーション側のAPIを叩く
共通基盤が非同期のイベントとして流し、アプリケーションが受け取る
アプリケーション側でポーリングする

などいくつか手段を比較検討し、方式を決めかけていました。

途中で気づいたのは、比較していた案のいくつかが 「共通基盤が各アプリケーションのことを知っている」 形になっていたことでした。基盤側から各アプリケーションへ通信するには、少なくとも宛先のURL・認証情報など、個々のアプリケーションによって変わる情報を基盤が知っている必要があります。

ネットワーク的には、経路を用意すれば双方向の通信自体は実現できます。共通基盤化して間もない時期で、利用するアプリケーションもまだ少ない状況でした。それでもこの形を採らなかったのは、共通基盤は利用する側が増えていく前提のものなので、利用側が1つ増えるたびに基盤が知るべきことが増える構造は許容しないほうがよいと判断したためです。

最終的には要件の再定義により、リアルタイム性の要否を再検討した上で、共通基盤側で起きた状態変化をアプリケーション側が特定のトリガーで取得しに行く形に落ち着き、責務も依存もむやみに増やさずに済みました。

ただ、初手で実装の手段検討から入ってしまったぶん、時間のロスは大きかったように思います。

時間のロス以上に気にしていたのは、判断を誤ったまま進めてしまう可能性のほうでした。依存の形は、各アプリケーションがそれに乗ったあとで変えようとすると、相応のコストがかかる可能性が否定できません。誤った判断がそのまま負債として残り得ますし、問題として表面化するのは利用側が増えたあとになりがちです。責務や依存を慎重に取り扱う必要があると感じたのは、この後戻りのしにくさがあるためでした。

2. 「利用者」として理解していたつもりの環境を、「提供者」としては理解できていなかった

エンドユーザー向けの開発を行っていた際は、自身が「利用者」として開発環境を利用しており、その特徴は十分に把握しているつもりでした。「提供者」の目線で見ると、まったく足りていませんでした。

開発用のテストデータの修正をメンバーと進めていたときのことです。利用者としては「夜間の複数のデータ処理バッチによって、テストデータが投入されたサンドボックス環境が作られ、始業時には利用可能になる」という理解でした。しかし実際には、環境ごとのデータ反映条件に差分があることが、事前検証で明らかになりました。

提供者としては、そのデータがどのようなワークフローで作られるのか、どの環境には自動で投入されてどの環境には投入されないのか、参照元が環境ごとにどう切り替わるのかまでを把握している必要があります。どこに手を加えるとどこに副作用が出るのかも、そこが分かっていなければ判断できません。これらが十分でなかったため、協業していたメンバーからの問題提起を理解するのに時間を要してしまいました。

利用者としての習熟は、提供者としての理解の代わりにはならないというのが率直な実感でした。「一つ一つの理解に時間がかかる」と感じていた原因の多くは、必要な理解の種類が変わっていたことに気づけなかったことにありました。

この一件をきっかけに、提供側の視点で環境全体のワークフローを把握し直しました。利用者と提供者の違いは、同じプロダクトを触っていても気付きにくいものだと思います。