はじめに
こんにちは。
Feature Dev1 グループでマネージャーをしている髙嶋です。
突然ですが、サービス運営するうえでユーザーからのお問い合わせ対応を無視することはできません。
そしていかに迅速かつ適切な内容で回答できるかどうかは、どこまでいってもゴールのない永遠の課題と言えるものでしょう。
ネットショップ作成サービス BASE に関するお問い合わせ対応についての運用に直近変化があったため、その経緯と効果（はある意味これからでもありますが）を共有させていただきたいと思います。
サマリとしては、概ね以下のような内容となります。
- お問い合わせ対応のうち、技術的な観点が要求されるものはエンジニアに対して調査依頼がきます
- BASE では特定の部署が対応する形ではなく、開発組織横断で対応にあたっています
- 具体的には通称 cs_q というチャンネルに調査依頼がくるので、基本的には依頼がなされた順に対応しています
- 担当プロジェクトなども各々抱える中で、cs_q 対応が特定のチームないし個人に偏ってしまう状況を避けるために、これまでは週次で当番を各チームからアサインする輪番制の運用としてきました
- この度、一部開発組織の改編も相まって、お問い合わせをいくつかのカテゴリ（プロダクト領域）に分割し、それを各チームにアサインして対応する運用に変更しました
- それに伴って運用全体としての輪番制は廃止し、具体的な運用方法については各チームに一任することにしました
- 元々は組織やプロダクトが大きくなってきたこともあって輪番制を導入したという背景もあったはずが、そこからさらなる成長を遂げたら今度はそれをやめることになったのが個人的には興味深いと感じています
輪番制導入の背景と根底にある考え方
以下は輪番制すなわち当番という考え方に基づく運用が導入された当時の記事であり、その背景などが記載されています。
冒頭で述べたような課題感も含めて、当時の状況をより詳細にうかがい知ることができるのではないかと思います。
そこから数年が経過し、もちろん改善を重ねてきた部分はありつつもベースにある輪番制という運用自体は2023年末まで維持されてきました。
また別の記事になりますが、プロダクトへの向き合い方という観点においても cs_q に触れたものがあります。
これらの記事を踏まえて大胆にまとめるなら、BASE にはプロダクトづくりにエンジニア全員で向き合おうという良い文化があると考えています。
普段の開発業務においてはドメイン分割して対応にあたることも現実的な解としてとっていますが、それでも結局は一つのプロダクトを全員で作っているという意識を持つという考え方が根底にあります。
そしてリリースしたらお終いではなくむしろ始まりであり、基本的にはリリースして初めてユーザーからのフィードバックを得られるようになります。
ユーザーからのお問い合わせもその一つと言えるでしょう。
効率性を考えるのであればお問い合わせ対応などを専属で行うような組織を作る選択肢もある中で、そうしないことには開発組織としての意志があると思っています。
輪番制の課題と開発組織としての課題
ここでいったん私自身について補足させていただくと、この2年程 cs_q 対応でエンジニアに調査依頼がなされてからの運用全般について、その取りまとめをするような役割を担ってきました。
その中で改善してきたこともたくさんあります。
バックログを導入して状況を可視化できるようにしたり、調査に行き詰まった際の相談先リストを作成したり、はたまた運用フローを整備したりするなど、そのときどきの課題に向き合って他者の協力も得ながら改善を図ってきました。
着実にそうした整備は進んでいるという手応えがある一方で、輪番制を念頭に置いた運用の限界を感じていたのもまた確かです。
一例として、当番時だけ対応すればよいという捉え方もできるため、当番が調査に行き詰まってもなかなか非当番メンバーとの協力体制を敷くのが状況的に難しかったりといったことが挙げられます。
また当番の中でも対応までのスピードや数にコントラストがついてしまい、輪番制にすることで期待していたはずの平準化や公平感というメリットがあまり感じられなくなってしまったりといったこともあります。
そして開発組織の変化についての話も避けては通れません。
この3年程はいわゆる目的別組織というキーワードの元、特に BASE というプロダクト開発に関わる開発組織は一定の目的ないし領域で区切られたような組織設計がなされてきました。
それ自体はチーム運営や開発プロセスを成熟させ、またそれぞれの領域に対する各メンバーの理解を深めることに繋がり、その結果としてプロジェクトの安定的なデリバリーを実現できるといったメリットがありました。
しかしながらチームの担当領域に対しては最適化されていく一方、その裏返しとしてマンネリ化が進んだり変化に対するハードルがあがって視野が内向きになったりという課題も目立ってくるようになりました。
そういった組織の硬直化を食い止めて組織と個人の成長をもう一度加速させるために、開発チームにおける領域という考え方は撤廃し、越境・成長・持続的な開発組織というコンセプトのもとにあえて同じ性質を持ったフィーチャーチームを複数作るような組織構造になりました。
その考え方に基づくなら cs_q もプロダクト領域を全チームが分け隔てなくみていこうということもできますが、さすがにそれは認知負荷が高すぎて効率性とのバランスが悪く結果としてユーザーに迷惑をかけることになるため、cs_q については各チームの守備範囲を決めて対応にあたることにしました。
その守備範囲はプロダクト領域をいくつかのカテゴリに分割したものではありますが、そのカテゴリ自体に大きな意味を持たせることはせず、あくまでも全体のバランスなどを考慮した割り振りになっています。
つまり各開発チームに対してカテゴリをアサインするような格好にはなりますが、それもずっと同じ組み合わせでやっていくことを前提にはしておらず、今回の組織改編のコンセプトに沿ったものとなるよう今後はカテゴリをローテーションしていくような案も検討しています。
逆にチームの中にいるメンバーがグループ間を動くことで知識を伝播していくようなパターンもあるでしょう。
改めて cs_q の運用が現状どうなったかをまとめると、大枠以下のようになります。
- エンジニアへの調査依頼はバックログ（Notion）に起票し、カンバン形式でステータス管理する
- 起票されると調査依頼内容のプロダクト領域（カテゴリ）に応じて Notion のオートメーション機能で紐付く担当チームが設定され、Slack でそのメンションが各人ないしチームに飛ぶ
- cs_q チャンネルに調査依頼内容が自動で通知され、担当チームのエンジニアはその対応にあたる
全体の運用としての決め事は極論これだけであり、このようにできる限りシンプルな状態まで削ぎ落としたからこそ、輪番制という座組みも廃止して具体の運用は各チームに任せる意思決定ができました。
輪番制をやめてどうなったか
結論、輪番制をとるチームもあればそうしないチームもあります。
ただしそれは各チームの状況も踏まえて適宜判断されていることであり、これまでのように全体で実施していたときとは少し意味合いが違うと思っています。
一律のルールを定めて徹底することによる全体最適を重視するのか、あえて余白を残すことで各チームの想像力による新しい何かが生まれるのを期待するのか、それぞれのメリデメがあることは理解しつつも今回の全体方針としては組織改編に込められた意思も踏まえたうえで後者に倒した形になります。
ちなみに私も Feature Dev1 グループという開発組織を預かる立場ですが、グループ方針として輪番制は敷かないという意思決定をしました。
上述した通り、私自身が元々輪番制に対する課題感を持っていたという背景もありますが、それを抜きにしてもチームメンバーに主体性を期待する形での運用に倒してみたらどうなるかを、成功するにせよ失敗するにせよちゃんと検証したかったということがあります。
運用開始から3ヶ月程が経過してどうなったかで言うと、現状期待通り、あるいは期待以上の状況になってくれていると感じます。
当番を置かないからこそチームメンバーの誰かが主体的かつスピーディーに調査依頼に反応する動きも多くなり、それは結果的に困っているユーザーをより早く助けることにも繋がっています。
良い意味で調査依頼に対応した数にもコントラストがつき、積極的に対応してくれるメンバーを素直に評価できる状態にもなりました。
またこれは私のチームに限った話ではありませんが、組織改編の影響もあってメンバー同士で持っている知識を交換し合いながら対応にあたったり、きたる担当カテゴリのローテーションに向けてもよりドキュメントに知見を整理して引き継いでいけるようなムーブメントも起こりつつあります。
まとめ
現時点では大きな混乱もなくポジティブにその経過を見ていますが、一方でより本質的な課題が出てくるのはこれからだと考えています。
ゆえに未来永劫ずっとこの運用を貫くということはおそらくなく、今回がらっと運用方法を変えたように、また新たな課題が出てきたらどうするかということを考え続けていくんだろうと思います。
本記事では弊社における事例紹介をさせていただきましたが、ウチではこういった取り組み方をしていますといった事例があればぜひ教えていただきたいと思っています。
最後に、BASE では絶賛採用活動中です。
本記事でご紹介させていただいたように、アプリケーションエンジニアとしてもただ機能開発をするだけではなく、プロダクトそして組織の成長を支えていくために裁量を持ってできることがたくさんあるのが BASE で開発する醍醐味です。
カジュアル面談からでも大歓迎ですので、一緒に BASE の未来を作っていく方をお待ちしています！
