Wantedlyのインフラチームは「挑戦を続けるための」開発・運用基盤をどう築いてきた？：マイクロサービス化から生成AI活用まで（1/2 ページ）

ビジネスSNS「Wantedly」を提供するウォンテッドリーは、コンテナやKubernetes、マイクロサービスなど新しい技術を早くから取り入れ、サービス開発のスピードを高めてきた。開発者が開発に集中できる環境と、安定したユーザー体験を支える仕組みをどう構築してきたのか。取り組みの背景と狙いを聞いた。

[齋藤公二, 編集：遠藤文康，＠IT]

　ソフトウェアがビジネスの中核となる今、サービスの品質は競争力そのものと言える。しかしその品質を保つことは、システムの構成が複雑になったり、生成AIがシステムに組み込まれたりする中で一段と容易ではなくなる。

　採用・人材マッチングなどのビジネスSNS「Wantedly」（旧Wantedly Visit）を提供するウォンテッドリーも、システム基盤の変更やサービスの拡張を続ける中で、そうした課題に向き合ってきた。開発生産性やユーザー体験までを見据え、サービスの品質を向上させる仕組みを進化させてきた。2012年に事業を開始した同社は、2026年現在は採用から従業員エンゲージメントまで「シゴト」にまつわるサービスを提供する。サービスの導入社数は4万社を超え、登録ユーザー数は450万人規模となった。

　社員120人のうち約50人をエンジニアが占め、サービスの開発から運用までを自社で担う。エンジニアの裁量が大きく、自律的な開発を重視する社風だという同社。「サービスを安定して提供しながら新しい価値も継続的に届ける」ために、早くからビジネス目線でサービスの品質を管理・改善する仕組みづくりに取り組んできた。その実践は、現在ではSRE（サイト信頼性エンジニアリング）やオブザーバビリティー（可観測性）の考え方として広がりつつあるものだ。

　同社では2014年、サービス基盤をPaaS（Platform as a Service）からIaaS（Infrastructure as a Service）へ移行して以降、システム構成や開発スタイルの変化に合わせて、運用の仕組みや品質管理の考え方を見直してきた。その取り組みや狙いを聞いた。

「開発者はコードに集中すればいい」――それを支えるインフラの移行

　「プロダクトチームが開発と運用を担ってDevOpsを実践する中で、インフラチームは開発者の生産性、システム基盤の信頼性にコミットしています」。ウォンテッドリーの開発部門でインフラチームのリーダーを務める田中篤志氏は、同チームのミッションについてこう話す。単にツールやサービスを導入するだけでなく、「エンジニアやユーザーにどう使ってもらいたいかを設計して価値を最大化することが重要」だと捉えている。近年は、インフラや開発運用に関わる機能をプラクティスやプラットフォームとして提供することにも力を入れているという。

ウォンテッドリーの田中篤志氏

　SREやオブザーバビリティーを推進するきっかけの一つとなったのが、2014年にシステム基盤を移行したことだ。同社がサービスを開始した2012年当時は、PaaS型のアプリケーション実行基盤「Heroku」を利用していた。「開発者はインフラを意識せず、コードを書くことに集中すればいい」という考え方を重視していたウォンテッドリーにとって、Herokuは同社の開発スタイルとの相性が良かったという。一方で、Wantedlyのユーザー数の増加、さらにはモバイル展開に伴い、当時米国にサーバがあったHerokuではネットワーク遅延などが課題となりつつあったため、2014年に「Amazon Web Services」（AWS）への移行を決断した形だ。

　この移行によって必要になったのがインフラモニタリングだ。「コンテナベースのHerokuの良さを維持するためにAWSでもDockerによるコンテナ環境を構築していましたが、当時AWSの標準機能では監視が難しいという事情がありました」と田中氏は説明する。

　Dockerがオープンソースソフトウェア（OSS）として公開されたのが2013年3月で、当時まだ普及し始めた時期だった。コンテナ環境の監視に対応したツールもまだ限られていた中で、ウォンテッドリーでは当時からDocker環境の監視に対応していたDatadogの監視ツールを導入し、まずはインフラ監視の仕組みを整備した。その後の機能拡充に歩調を合わせるように、ウォンテッドリーでもオブザーバビリティーの取り組みを進化させてきた。

「新しいチャレンジ」を止めない　マイクロサービス化とKubernetes

　こうしてAWSへ移行した後、次の大きなテーマとなったのがマイクロサービス化だった。当時は、名刺管理アプリ「Wantedly People」やその前身となるサービスなど、さまざまな新規事業を模索していた時期でもあった。しかし、新しいサービスを立ち上げるたびにインフラエンジニアが環境構築や運用支援に関わり、一つのプロジェクトに付きっきりになる場面も少なくなかった。そうなると、他のプロジェクトや新たな挑戦を十分に動かせず、開発全体のスピードにも影響が及ぶ可能性があることが問題になったという。

　そうした同社の開発を支える基盤として選んだのがマイクロサービスだった。田中氏は「新しいチャレンジをどんどんやっていく会社ですし、その方針とマイクロサービスとの親和性もあり、取り組み始めることになりました」と振り返る。

　マイクロサービス化を進めるに当たり、同社はその実行基盤についても試行錯誤を重ねた。当時はコンテナ技術が普及し始めた時期で、複数のコンテナ管理ツールを検証しながら、不足する機能は自社で実装するといった対応もしていたという。

　そうした中で「Kubernetes」が登場し、2016年ごろから本格的に検証を始め、一部のサービスで導入を進めた。その後「Amazon Elastic Compute Cloud」（EC2）上で稼働していたDocker環境からKubernetesへ移行しながら、2018年までに全サービスのマイクロサービス化を進めた。

　Kubernetesへの移行によって、開発者がインフラエンジニアを介さずにアプリケーションをデプロイ、リリースできるようになった効果は大きかったという。田中氏は「新しいサービスを作るときに既存サービスとは独立して開発できるので、そのライフサイクルを生かしやすくなりました」と振り返る。その結果、マイクロサービスによる開発スタイルは徐々に社内へと広がっていった。監視基盤もKubernetes環境に合わせて整備し、Datadogを活用してマイクロサービス全体の状態を継続的に把握できるようにした。