見出し画像

「Chatwork」の運用保守を支える、PMの守備フォーメーションと挑戦

はじめましてこんにちは!後藤です。株式会社kubellで認証領域のプロダクトマネージャー(以下PM)を担当しています。

PMの仕事は多岐にわたり、会社や事業のフェーズによっても様々です。今回は普段あまり日の当たらない運用・保守業務について、「Chatwork」におけるPMの役割や体制を紹介したいと思います。

この記事は、kubell Advent Calendar 2024 (シリーズ3) 12月17日分の記事です。


運用・保守の大切さ

「Chatwork」は10年以上にわたって提供されているSaaSであり、日々100万人以上(※)のユーザーに利用いただいています。あらゆる業種、職種の方が日常的に使うコミュニケーションツールであり、24時間365日止めることのできない、”インフラ”となるサービスです。
PMの役割として、プロダクトと事業の成長のため、機能追加や改善を通して新たな価値提供をし続けることが重要です。また、それと同等かあるいはそれ以上に、サービスを安定して提供し続け提供価値を維持する運用・保守の活動も非常に大切です。

※ 116.3万DAU(1日あたりのサービス利用者数の土日祝日を除く平日の中央値)。 2024年9月末時点

「Chatwork」における運用・保守のPM体制と問題点

これまで運用・保守に関するPMの業務は、社歴が長く「Chatwork」全体の知識が豊富なPMが中心となり担ってきました。障害発生時の対応など迅速な対応や判断が求められる場合でも、エキスパートが対応にあたるので安心感がありました。しかし、この体制には以下の問題がありました。

  • 特定のメンバーへの負荷の集中

  • 知識や業務理解の属人化

担当メンバーは、運用・保守の業務以外にも当然グロースや専門領域のプロダクトマネジメントを担当しています。
①障害対応など、不定期に発生し迅速な対応が求められる業務を他のメンバーがカバーできない
 →②経験を積めず、他のメンバーの業務理解が進まない
  →③負荷分散ができず、担当メンバーが不在の場合のリスクが増大する

という悪循環になっていました。

組織全体で取り組む体制へ転換

これらの問題を解決するために、運用・保守関連の業務は特定の個人数名ではなくPM組織全体で対応する体制に変更しました。
この記事では、以下の2つの業務について紹介します。

1. 障害対応

まず、障害対応のための体制です。24時間365日発生する可能性があり、即時対応が必要な場合が多いのが特徴です。

PMの体制:

  • 週単位で障害担当PMを二人配置: その期間に発生した障害の対応を持ち回りで担当します。経験の浅いメンバーもいたため、対応マニュアルに沿ってリハーサルを行い、「困ったらすぐ声を上げ、みなで助ける」マインドで対応にあたっています。

  • 知見の共有と振り返り: 発生した障害の対応内容の共有と振り返りを行うことで、知見の共有と対応マニュアルのブラッシュアップを行っています。具体的には、判断に迷ったケースについて、観点や困ったことを言語化し、判断基準をアップデートするなどしています。

週単位で割り当てがあるため、自動で週の担当を投稿するようにしています

PMの役割:

  • 情報収集と状況把握: エンジニアから障害に関する情報を収集し、ユーザー影響や復旧作業の状況を把握します。また、関係者への周知を行います。

  • ユーザーへの情報発信: 広報やカスタマーサポートと連携し、ユーザーへの情報発信を行います。障害状況の発信のほか、運用回避策の案内や想定問い合わせの回答案の作成を行う場合もあります。

2. 運用・保守業務

次に、障害対応以外の運用・保守業務についてです。

PMの体制:

  • クライアントサイドとサーバーサイドに分かれて対応: それぞれ2名ずつの体制で対応に当たっています。私はクライアントサイド(ブラウザ版画面やデスクトップ版/モバイル版アプリ)を担当しています。

PMの役割:

  • 対応方針の決定: サービスを安定して提供し続けるために必要な、プロダクトの仕様や動作要件の変更に関して、ユーザー影響を踏まえた対応優先度と仕様の決定、ユーザーへの告知方針の検討などを行います。

  • 業務の例: 一例として、システム動作要件の見直しがあります。具体的には、モバイル版アプリのOSバージョンのサポート範囲の見直しなどです。モバイルOSは年に一回メジャーバージョンアップが行われます。機械的に年に一度サポートOSの範囲を切り上げるのではなく、実際にユーザーに利用されているOSバージョンの推移をデータで確認し、影響を見極めた上で告知期間や変更日を決定しています。「Chatwork」は法人の利用者も多く、社用スマートフォンの買い替えなどの対応も必要となります。一斉告知するだけでなく、影響の大きい法人顧客についてはカスタマーサクセス経由で事前にご連絡するといった考慮も必要です。

利用端末のデータ分析の例

「Chatwork」におけるデータドリブンなプロダクトマネジメントについては、以下の記事も参照ください。

組織全体での対応が生むポジティブな変化

運用・保守業務を作業分担することは、大きく3つのメリットがありました。

負荷分散:
特に障害対応については、物理的な負荷以上に、精神的な負荷軽減への影響が大きいです。チームで対応する体制を取ったことで、特定のメンバーに過度な負荷がかかることを防ぎ、「もし自分が動けなくてもカバーできるメンバーがいる」安心感につながっています。

チームワークの向上:
みなさまの組織では、「自分の担当領域のチーム(エンジニアやデザイナー)とは密なコミュニケーションがあるが、意外とPMの横のコミュニケーションが少ない」ということはないでしょうか?普段関わりの少なめなPMとも協業する機会があることで、お互いの強みや仕事のスタイルの理解が進みました。私自身も困ったときに相談しやすくなり、助け合い精神がより磨かれたように感じます。

業務プロセスと対応品質の標準化:
誰が担当しても同じ対応ができるよう、業務プロセスの標準化が図れます。ここはまさに今トライ中なのですが、判断や対応に迷ったケースを共有し改善していくことで、業務の一貫性と効率の向上が期待できます。私一人では解決が困難で目をつぶっていた痛いところを突かれたことも。自分では気づかなかった視点やアイデアがもらえるので、同業種間のコラボも面白いです。

最後に

今回は、PM組織全体で対応している「Chatwork」の運用・保守業務についてご紹介しました。
それぞれのPMメンバーが、アサインされたドメインのエキスパートとしてバリューを出すことが大切です。一方で、運用・保守の業務のような広範囲なドメインで突発的な対応も発生する業務については、複数名で対応できる体制が取れていることで、組織として対応力が上がりました。
また、今回の記事を書いてみて、「体制構築や業務プロセス設計」と「プロダクトマネジメント」の共通点が多いことを再発見し(課題設定から継続的な改善など)、両方を経験することで良い相互作用があることに気がつきました。
「Chatwork」のPM組織での取り組みが参考になれば幸いです。

この記事を読んで「Chatwork」のプロダクトマネージャーに興味を持っていただけた方は、是非採用情報をご確認ください!


いいなと思ったら応援しよう!