ソフトウェアエンジニアとしてコードを書くことはもちろん楽しいですが、組織が大きくなり、システムが複雑になるほど、技術そのものと同じくらい「人」や「組織」との調整が重要になると感じています。
どれほど優れた設計も、関係者全員の合意がなければ絵に描いた餅になってしまいます。私はこれまで、異なる専門性を持つチーム間の懸念や要件を解きほぐし、共通のゴールに向けて調整する、いわば「翻訳家」のような役割を担ってきました。
今日は、私が実際に経験した組織横断的な調整のエピソードを抜粋してお話しします。
私が関わった中で特に調整が難しかったのは下記です。
- 既存の巨大な基幹システムから特定の機能を安全に切り出し新しいマイクロサービスとして独立させるプロジェクト
- システムのコア機能に大きな変更を加えるプロジェクト
1. リスクを分離するためのマイクロサービス化
このプロジェクトの発端は、既存の機能に、大規模な関連データを扱う新しい仕組みを追加することでした。しかし、そのデータは非常に数が多く、そのまま既存の基幹システムのデータベースに追加すると、性能が劣化し、最悪の場合、システム全体の障害につながるという重大な懸念がありました。
さらに、そのデータは複数の異なるドメインのシステムから参照される性質を持っており、そもそも基幹システムのDBに存在すること自体が不自然な状態でした。
これらの課題を解決するため、私はこのデータ参照機能を独立したマイクロサービスとして切り出す旗振り役を務めました。
基盤チームとの密な連携
- インフラ構築の合意形成：
- 設計書を基にSREチームと議論し、サービスの要件や想定負荷を伝えました。当初、既存のDBを間借りする案も出ましたが、DBREの助言を受け、リスクを避けるために独立したDBを新たに構築することで合意しました。
- 認証基盤：
- サービス間の通信を安全に行うため、社内の認証基盤を利用する必要がありました。担当の基盤チームと協力して設定を進めました。
- 運用の自動化：
2. コア機能における意思決定とトレードオフ
次に、基幹システムの中核となるデータに対する一括操作機能を開発した際も、多くの調整が必要でした。
データ整合性のための排他制御
一括操作では、データの整合性を保つことが最重要です。そのため、処理中に他のユーザーが対象のデータを更新できないように、悲観的ロックを採用しました。この仕様はモバイルアプリや公開APIなど、あらゆるクライアントに影響を与えるため、事前に設計書で仕様を明確にし、関係チームと影響範囲の確認を徹底しました。
非同期処理の実行環境に関するトレードオフ
一括処理はサーバー負荷を考慮し、非同期で実行します。その実行環境をどうするかで、大きな議論がありました。
私は当初、ドメインの独立性、運用・調査の容易性、そして将来の機能拡張を見据え、「一括処理専用のWorkerを新設すべき」と主張しました。しかし、他チームのリードエンジニアからは、コスト面を理由に既存の共用環境を利用すべき、という反対意見も出ました。
ここで安易に妥協するのではなく、私は改めてプロダクトSREに直接相談を持ちかけました。技術的な観点からWorkerを分離するメリットと、将来的なリスクを丁寧に説明した結果、最終的に専用Workerを新設するという、当初の理想案で合意を得ることができました。
技術的な正しさだけでは、プロジェクトは前に進まない
振り返ると、これらのプロジェクトの遂行は、コードそのものよりも、人と人との対話によってもたらされた部分が大きいと感じます。
設計書は、単に仕様を記すものではなく、異なる背景を持つ専門家たちの「共通言語」として機能しました。性能、コスト、セキュリティ、ユーザーインターフェース、それぞれの立場からの懸念や要求を丁寧に「翻訳」し、ときには粘り強く議論を重ねることで、ようやく組織としての最適解にたどり着くことができます。
技術的な正しさの追求と、組織の複雑さを理解した立ち回り。その両方を持つことこそが、大規模なプロダクト開発をリードする上で不可欠なスキルなのだと、この経験を通じて改めて学びました。
