肩書きより先に、オーナーシップを

XsollaのBusiness Accounts基盤では、複数のアプリに似たコードがあり、それぞれが変わる中で互換性を保つことが難しくなっていました。バージョン付きの共有パッケージに移すことで、改善の道筋が見えました。ただし、各チームに導入してもらうには、また別の作業が必要でした。

その経験で、オーナーシップという言葉が具体的になりました。解決策を実装するだけでなく、他の人が使い、保守できるようにするところまで、責任が続いていたのです。

プロジェクトエンジニアとして働いていたときにも、似たことがありました。設備の設置が終わっても、次のチームが進めるとは限りません。依存関係、調整、引き継ぎが必要です。ソフトウェアでは、それが違う形で現れました。

まず、課題を明確にする

基盤開発では、アプリの境界を越える問いが生まれました。複数アプリで振る舞いをどう共有するか、認証をどう整理するか、共有コードをどう届けるか、本番障害をどう調べるか、といった問いです。

そうした問いは、実装タスクが明確になる前に現れます。最初にできる貢献は、課題、制約、選択肢、決めるべきことを書き出すことです。

そこから、成果物として届けられる単位に分け、関係者と責任範囲を合意し、判断の理由を記録します。設計メモや移行ガイドがあれば、同じ話を何度も繰り返さずに、メンバーが判断できるようになります。

計画は出発点です。実装で新しい制約が見つかれば、見直す必要があります。何を前提としているのか、その理由は何か、何が未解決なのかを、チームが把握できることが大切です。

導入まで課題に関わり続ける

互換性への懸念は、早い段階で伝えていました。その後、基盤開発に戻った際に、問題が実際の摩擦につながっているのを見て、解決の責任を引き受けたいと申し出ました。

バージョン管理された共有パッケージと、明確な基盤の境界を中心に方針を設計しました。提案を文書化し、異なる拠点のエンジニアと議論し、懸念を整理しながら方向性をそろえました。そして、各アプリがバージョンを指定して利用できるパッケージへ、共通機能を移す作業を推進しました。

これによって、共有コードを進化させる仕組みが明確になりました。ただし、すべてのアプリが導入を終えたわけでも、互換性のための作業が不要になったわけでもありません。2026年9月時点で、計画対象の約25アカウントのうち6つが稼働しており、共有ライブラリの導入は継続中でした。これは基盤全体の数字であり、SDKへの移行完了数ではありません。

何を共有するかにも、トレードオフがありました。汎用的に見えるページを公開するとコピーは減りましたが、製品UIの修正が基盤のリリース待ちになることがありました。次の方向性として、共通の契約と機能はライブラリに残し、ページは製品側でより柔軟に管理できるようにすることを考えました。

一つのボトルネックを取り除くと、別のものが生まれることがあります。パッケージ構造が整理されても、利用するチームにとって使いやすいとは限りません。組み込みや更新を支え、妨げになる境界を見直すことも、仕事の一部だと学びました。

担当範囲と導入状況はBusiness Accountsのプロジェクトページにまとめています。技術的な方針はAIでひな形を同期し続けるのをやめ、ライブラリに切り出すで詳しく説明しています。

他の人も主体的に動ける余地をつくる

チームのテックリードが交代する間、約6か月の空白期間がありました。正式な肩書きは変わりませんでしたが、計画、技術方針、調整、レビュー、メンバーの障害解消などを担当しました。

その期間には、明確な計画、依存関係の解消、他のエンジニアが先に進むための判断が、役に立つ貢献になることがよくありました。

責任を持つことと、すべての細部が自分を経由しなければならない状態をつくることは違います。実装上の判断のたびに私が必要なら、情報が足りないのか、境界が曖昧なのか、もっと任せられる部分があるのかを考えます。

若手エンジニアやXsolla Schoolの卒業生5人へのメンタリングでも、その学びが深まりました。明確な担当領域、前に進むための支援、そして自分の判断力を育てる余地を渡すことを目指しています。

自分のコードの外まで、証拠を追う

本番環境での仕事では、オーナーシップが具体的な行動として現れます。変更がマージされても、利用者には不安定な体験が残っているかもしれません。

基盤開発では、Datadog RUMとOpenTelemetryを使ったフロントエンド・バックエンドの可観測性を担当しました。サポート調査では、証拠がフロントエンドの外を指していればバックエンドのスパンを追い、担当チームがインフラやデータベースの問題を特定する手助けをしました。

境界を越えて調査することは、別のチームのサービスを引き取ることではありません。何が失敗したか、トレースがどこを指すか、次に何を確認すべきか。引き継ぎを役立つものにするだけの証拠を集めることです。

各システムの担当を尊重しながら、利用者の問題を見失わないための、実践的な方法だと思います。

役立つ手順を、たどりやすくする

共通基盤に取り組む中で、開発者体験への考えも変わりました。文書は必要ですが、同じセットアップを繰り返しているなら、基盤そのものを改善する余地があります。

Business Accountsのひな形生成、設定検証、共通構造の生成、ローカライズの準備、更新・移行を支援するツールに取り組みました。手順を仕組みに組み込むことで、アプリをつくるたび、更新するたびに、同じ要件を再発見する負担を減らせます。

コミュニケーションにも同じ考えが当てはまります。移行は他チームの作業を生むので、目的、前提、トレードオフを見えるようにする必要があります。その判断と長く付き合うエンジニアが、変更コストが高くなる前に意見を言える状態をつくりたいと思います。

これからも育てたい習慣

解決策を決める前に、いくつかの問いを確認するようにしています。

• 誰が必要としていて、どの問題を解決するのか？
• 役に立つ成果とは、どのような状態か？
• 何が失敗し得て、どう気づけるか？
• リリース後は誰が保守するか？
• 後から別のエンジニアが判断の理由を理解できるか？

小さな修正でも基盤開発でも、この問いは今も役立っています。誰が使うのか、何を必要としているのか、マージ後にも何が未解決なのか。そこに議論を戻してくれるからです。