技術力向上とオーナーシップ醸成の鍵となるNew Relic
技術力向上のための取り組みとして、定期的にライトニングトーク形式の発表会や輪読会などを開催している。開発スキルはこのような勉強会で身につけることができるが、運用監視や観測のスキルはエンジニアでも獲得しづらい。そこでNew Relicを導入し、そのベストプラクティスに従うことで監視・観測の技術的ハードルを下げている。
さらに、エンジニアとプロダクトマネージャー双方の技術力向上を目指し、New Relicをプロダクトマネージャーとエンジニアの共通言語基盤として活用している。サービス障害対応やサービスレベルに関する議論の際、プロダクトマネージャーもメトリクスやNew Relicのダッシュボードを見ることでサービスの状況を理解できるようになっている。プロダクトマネージャーにもNew Relicの積極的な利用を促すことで、その技術力向上にも取り組んでいる。
コミュニケーションツールとしてSlackを使用し、New Relicからのアラート専用チャンネルを設定している。アラートが発報されると、Slackに自動的にスレッドが作成され、そのスレッド上でエンジニアとプロダクトマネージャーが役割に応じたコミュニケーションを取る仕組みになっている。エンジニアは主に障害調査と対応に注力し、プロダクトマネージャーはサイトの生存確認、関係者への連絡、メンテナンス判断などを担当する。
吉田氏は「New RelicのリンクをSlackのスレッドに貼ることで、プロダクトマネージャーにも状況が伝わるような仕組みを整えています。これにより、エンジニアが迅速に障害対応に入れる体制ができています」と話した。
プロダクト志向の4要素のうち、特に不足しているのが「オーナーシップ」だ。その原因として、開発から運用までを複数のチームで担当しているため、責任の境界があいまいになりやすいことが挙げられる。例えば、障害対応時に「誰かがやってくれるだろう」という考えに陥りやすい状況がある。
吉田氏は、オーナーシップがそがれる要因として「複雑な組織と複雑な設計」を挙げた。現在、システムのアーキテクチャはモノリシックだが、開発組織にはA、B、Cの複数のチームが存在しており、そのため意思決定が難しいという課題もある。機能開発においてチーム同士でコンフリクトが発生することや、同じファイルに対して修正が必要になることが頻繁に起こり、それが調整の負担となっている。これらがオーナーシップの欠如につながる要因だと考えているのだ。
そこで、「逆コンウェイ戦略」を取り入れた組織開発体制を目指している。米国のコンピューターエンジニアであるメルヴィン・コンウェイが示した格言「システムのアーキテクチャーは、おのずと組織構造を反映させたものになる」で知られる「コンウェイの法則」を逆手にとった組織戦略だ。
そのため、engageというプロダクトを、境界を明確にした「コンテキスト」という単位に分割し、各チームが担当する領域を持つことで、開発から運用監視まで一貫して対応できる体制を作ることを目標としている。各開発チームで担当コンテキストのマイクロサービス化を進めているが、混乱を招かないように技術品質チームのメンバーも割り当てながら着実に進めていく方針だ。
この開発体制の再構築について、吉田氏は次のようにコメントした。
「少人数の開発チームで、開発から運用まですべてを担当することになるため、自動化（CI/CD）を駆使して、開発に専念できる環境を整えることが必要だと思っています。New Relicのような便利なツールを活用することで、開発の妨げになるノイズを減らしていくことが大事だと考えています」
