外注から内製へ：エン・ジャパンのプロダクト開発組織の進化
エン・ジャパンでは、求人サービス「engage（エンゲージ）」などを展開している。engageには、企業が求人ページを作成し、応募者を管理するサービスと、企業が作成した求人情報を求職者が検索し、応募できるサービスがある。
エン・ジャパンでエンジニアリンググループのマネージャーを務める吉田氏は以前、EC業界でバックエンドエンジニアとして働き、ベンチャー企業でエンジニア組織の立ち上げにも関わっていた。エン・ジャパンには開発エンジニアとして入社し、engageの開発や、オブザーバビリティプラットフォームの「New Relic」を使ったオブザーバビリティ基盤の導入、アーキテクチャの再設計、ユニットテストの導入などを通じて基盤作りを進めた。現在は主にマネジメント業務に従事している。
エン・ジャパン株式会社 デジタルプロダクト開発本部 エンジニアリンググループ
エンジニアリングマネージャー 吉田健人氏
吉田氏は、エン・ジャパンのプロダクト開発組織の歴史について説明を始めた。もともと「engage」の開発は完全に外注しており、開発会社A社に開発から障害対応まですべてを委託していた。社内にはプロダクトマネージャーしかおらず、企画だけを行い、その後の開発はすべてA社に任せていた状態だった。
その後、方針を転換し、内製開発チームを立ち上げたことで、社内にプロダクトマネージャー数名とエンジニア10名の体制が整った。同時に、A社からも数名のエンジニアが参加し、社内のエンジニアチームではスクラム開発を導入して、一つのチームとして開発を進めた。A社のメンバーは主にプルリクエストのレビューなど、サポート的な役割を担う形で分担していた。
監視や障害対応については、経験に依存する部分が多く、社内への引き継ぎが難しい課題だったが、これを解決するために前述のNew Relicを導入し、引き継ぎのハードルを下げることに成功した。現在では、プロダクトマネージャー数名とエンジニア約100名の組織に拡大し、企画、開発、リリース、監視、障害対応のすべてを自社で行っている。
エン・ジャパンにおけるプロダクト志向の定義と実践
続いて吉田氏は、エン・ジャパンにおける「プロダクト志向」の定義について説明を始めた。同社ではプロダクト志向は「情熱」「オーナーシップ」「ドメイン理解」「技術力」の4つの要素から成り立っており、これらが重要であると考えている。
まず「情熱」については、エンジニアやプロダクトマネージャーが持つ成長意欲やプロダクトを成長させるためのエネルギー、そして組織カルチャー全体に影響するもの。
次に「オーナーシップ」は、プロダクト開発における意思決定権が開発チームにあること、そしてプロダクト開発を自分の責任として捉える姿勢を指している。
「ドメイン理解」については、開発しているプロダクトであるengageやその関連業界である人材業界、競合サービスの理解が重要であり、これをドメイン理解としている。
最後に「技術力」だが、エンジニアに求められるのは設計、実装、テストを独力で完遂する力と、運用監視をデザインする能力だ。開発だけでなく運用監視も含め、すべてを内製で行うことを目指している。
プロダクトマネージャーには、エンジニア視点が求められる。吉田氏は「エンジニアと共通の言語を持つことや、非機能要件を理解する力をつけることで、エンジニアとのコミュニケーションが円滑になり、エンジニアも働きやすくなります」と説明した。
吉田氏は、エン・ジャパンのエンジニア組織において、プロダクト志向の4要素のうち「情熱」「ドメイン理解」「技術力」についてはすでに達成しており、それぞれどのように取り組んできたかを説明した。
「情熱」の醸成に関しては、自社の理念を基にプロダクト作りを進めながら、理念の発信を継続的に行うことで共感者を増やすことに注力してきた。サービス理念と会社の理念を一体化させ、その発信を続けることで、より多くの共感を得ることができている。また、互いに賞賛し合う文化作りを推進している。例えば、売上達成時の祝賀会を全員で行い、自分たちが優れたプロダクト作りに関わっているという熱狂を共有している。さらに、新しい取り組みを奨励し、挑戦を歓迎する文化や仕組み作りにも力を入れている。
吉田氏は、「エンジニアとして新しい技術や挑戦に向き合うことが求められるため、心理的安全性を確保し、チャレンジしやすい環境を整えています」と加えた。
「ドメイン理解」のために、プロダクトマネージャーであるドメインエキスパートがエンジニア向けに説明会を開いている。内製開発チームはまだ立ち上げから2年半ほどで、中途採用のメンバーが中心となっているため、新たに参加したメンバーがプロダクトの理解を深めるための取り組みとして行っている。不定期ではあるが、engageの生みの親である取締役 寺田輝之氏とエンジニアが交流し、engageに込められた思いやビジョンを共有し、理解を深める場も設けられている。
また、スクラム開発を採用し、プロダクトマネージャーとエンジニアが同じチームで連携する体制を取っており、その結果、プロダクトに関するコミュニケーションが非常に活発に行われている。吉田氏は「ユーザーストーリーについての理解や共有を行うスクラムのイベントも行っています。エンジニアは、要件をどう実現するか（How）に注目しがちなので、意識的に、なぜ（Why）、何を（What）議論するようにしています」と述べた。
技術力向上とオーナーシップ醸成の鍵となる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のような便利なツールを活用することで、開発の妨げになるノイズを減らしていくことが大事だと考えています」
