はじめに

こんにちは。夏のアドベントカレンダー21日目を担当する、バックエンドエンジニアの西野（@keppagruun）です。昨年9月にウォンテッドリーに入社したので、もうすぐ1年が経ちます。

私はこれまでにいくつかの会社に在籍していますが、たびたび課題になっていたのが『システムの属人化』と、それに伴う『担当者への過度な負担』でした。ある機能の保守作業が特定の担当者に依存しているために、その担当者が不在だと誰も対応することができない状況でした。そのため緊急の依頼の場合は、休暇中の担当者に連絡を取るということさえありました。

ウォンテッドリーに入社して、この長年の課題を解決するひとつの答えを見つけました。それがエンジニア全員で取り組むサポート体制です。これは普段の業務で見ている機能かどうかは関係なく、無作為に調査が割り振られる仕組みです。

サポート体制の設計思想

先にも触れた通り、ウォンテッドリーはエンジニア全員でシステム機能全般のサポート業務に取り組んでいますが、その背景にはウォンテッドリーの開発組織の特徴が関係しています。第一に専任のサポートエンジニアがいないということ、そして第二に機能を軸にしたチーム編成ではないということです。

ウォンテッドリーのチームはミッション単位で組まれており、複数のチームが並行して、同じ機能を対象に別の改修を加えているのも珍しくありません。ある機能に対してオーナーシップを持つ特定のチームというものが存在しないため、システムに関するユーザーサポートの依頼先が不明確になることがあります。

しかし、ユーザーサポートはサービスの信頼性を支える重要な役割であり、問い合わせ対応やシステム調査といった業務は、誰かが確実に担わなければなりません。この課題の解決のために、ウォンテッドリーではエンジニア全員がユーザーサポートに参加するというアプローチを取っています。

具体的には、ユーザーからの問い合わせが入ってシステム調査が必要と判断された場合、サポート窓口の担当者が GitHub 上に調査依頼の Issue を起票します。そして、その Issue はランダムに選ばれた2名のエンジニアに割り振られます。

エンジニア全員で取り組むサポート体制の理由

この仕組みは明確にサポートの担当者が決まりますが、乗り越えなければならない難しさも伴います。それは、自分が普段触れることのない機能、いわば「​領域」の調査を担当する可能性があるという点です。この一見すると困難な状況こそ、私たちの組織が「"unknown unknowns"（自分が何を知らないかさえ分かっていない状態）を減らす」ために、あえて取り入れています。ウォンテッドリーの主力プロダクトである Wantedly Visit（一般的に「Wantedly」と呼ばれています）は、複数のマイクロサービスから構成される大規模なシステムです。10年を超える歴史の中で継続的に機能が追加されてきており、全ての機能の仕様や実装の詳細を把握するには相応の時間がかかります。私自身、入社してもうすぐ1年経つというのに、まだ全容はつかめていません。問い合わせによって初めて存在を知った機能もあるくらいです。

システム調査を要する問い合わせの多くは、ユーザーの困りごとを解決するための依頼であり迅速な対応が求められます。つまり担当者の習熟度によっては「知らない機能を短時間で調査する」ということに直面します。緊急度が高い問い合わせの場合は有識者を探し出して対応を代わってもらうこともありますが、基本的には担当者としてアサインされた人が対応するルールです。

Wantedly Visit は機能の多さから関連するリポジトリの数も多く、どのリポジトリで管理されている機能なのか調べるところから調査が始まることもあります。これには時間がかかりますが、普段の業務ではプロジェクトタスクも進めているため、このサポート対応をいかに効率的に、かつ質を落とさずに行うかが重要なポイントになります。

知らない領域でも調査できる支援の仕組み

限られた時間の中でどのように「知らない領域​の調査に取り組んでいるのか。ここからは、私が実際に担当した調査案件を例に紹介したいと思います。

ある時、Wantedly Visit における SAML ログインに関する問い合わせの調査を担当することになりました。その当時、私はその機能の実装についてまったく知識がありませんでした。一緒にペアとしてアサインされたメンバーも同様でした。こうした状況の中、Slack に用意されているサポート専用チャンネルに、調査を担当することになった旨を書き込んだところ、SAML の実装に関するドキュメントの場所や、実装に関わった経験者が誰なのかといった、初動に必要な情報がすぐに集まりました。

さらに、GitHub 上で過去の Issue を検索したところ、過去に似たような問い合わせがあったこともわかりました。その時の調査経緯や対応方針が記録として残っており、前例を参考にしながら調査を手早く進め、ユーザーへの回答につなげることができました。

ナレッジとして残す工夫

このようにして無事に調査を完了させることができた背景には、ウォンテッドリーに根付く文化があります。アドベントカレンダーの7日目に朴が書いた『「伝わる」GitHub PRと「育てる」レビューコメントの書き方』でも伝えている内容になりますが、ウォンテッドリーには他の人に伝えることを大切にする文化があります。

調査報告には Pull Request のような決まったフォーマットはありませんが、「Why（なぜ）」や「What（何を）」を丁寧に残すという意識で書くことに変わりはありません。調査報告はそこに「How（どのように）」も加えます。

具体的には以下のことを残すように心がけています。

• ログ調査
• • 対象のログテーブル名
  • 調査の際に使用したSQL
  • 抽出した結果
• ソースコード調査
• • 対象のソースコードの GitHub のパーマリンク
  • コードスニペットを用いた解説
• AWSの操作が必要なもの
• • 対象のマネジメントコンソールのURL
  • 対象のマネジメントコンソールの画面
  • 操作手順
  • 操作結果の画面
• 上記の調査結果をもとに調査結果の結論を書く
• • なぜ、そのような結論に至ったか
  • （データ修正が必要な場合は）何をどのように操作するか、したか

こうした記録は、類似の問い合わせや調査が発生した際に、後続の担当者が迅速に対応するためのナレッジベースとして機能します。実際に、SAML ログインに関する調査の際に残された記録は、後日別のメンバーによって参照されており、過去の知見が再利用された事例となりました。このように、調査の過程や対応内容を適切に記録することは、個人のためだけでなく、チーム全体の対応力を高めるうえでも重要です。

文化として根付く「One Team」の価値

Slack で活発に質問や情報共有が行われているのも、ウォンテッドリーの特徴です。先に述べたように「この機能に詳しいひとは誰なのか」という疑問は、チームが機能横断・ミッションベースで動いている以上、日常的に発生します。しかし、そうした質問が無視されることはほとんどありません。少しでも知識がある人が気にかけて答えてくれます。これは、質問する側にとって非常に心強いことです。

このような姿勢は、ウォンテッドリーのバリューの一つ『One Team』のまさに実践です。お互いの課題を自分ごととして捉え、組織として成果を出そうとする文化が、日々の Slack 上でのやりとりにも表れています。詳細な記録と知識を共有する文化は、「誰でも全体を支えられる」意識を生み出す土壌になり、全員で全機能を見るというサポートの仕組みを成立させます。この仕組みは、単なるサポートにとどまらず、組織全体の持続的な成長を支える力としても機能することになります。

まとめ

ウォンテッドリーのエンジニア全員で取り組むサポート体制は、一見すると非効率的に見えるかもしれません。そして「知らない機能の調査」は最初は大変です。しかし、過去の詳細な記録や Slack を通じた知識の共有、そしてそれらを活用した調査の実践によって、エンジニアひとりひとりが把握している機能の範囲は少しずつ広がっていきます。それは結果として、特定の個人に依存するような状況を作り出しにくくなります。

このように誰もが問題解決にあたれるようにする取り組みは、ITサービスマネジメントのベストプラクティスであるITIL（Information Technology Infrastructure Library）においても、「ナレッジ管理」として重要視されています。

本記事でご紹介したウォンテッドリーの取り組みが、皆様の組織における属人化の課題解決や、より良い開発文化を育む一助となれば幸いです。