コドモンCREチームの改善活動の進め方

はじめに

こんにちは、コドモンでエンジニアリングマネージャーをしている堀口です。

GWが終わり少し寂しい気持ちですが、今年の夏は海や山にたくさん遊びに行きたいのですでにワクワクしています🌊⛰️

2025年12月のアドベントカレンダーで、最近EMとして取り組んでいることを紹介する記事を書きました。その中でCREチームの再始動について少しだけ触れていたのですが、今回はCREチームで実際にどう改善を進めているかを紹介したいと思います！

tech.codmon.com

CREチームは、ユーザーからの問い合わせ対応と、問い合わせを起点としたプロダクト改善を両方行っているチームです。改善活動の進め方は最近整えたばかりのものですが、この記事ではいまの運用をフラットに紹介していきます。

コドモンCREチームの構成

まず前提として、いまのCREチームの構成を簡単に紹介しておきます。

チームはEMの僕と数名のエンジニアで動いています。専任のPdMやデザイナーは所属しておらず、必要に応じて他チームのPdMやデザイナーに相談しながら進めています。

チームの活動は大きく2つに分かれています。

ユーザーからの問い合わせ対応
問い合わせを起点としたプロダクト改善

「問い合わせ対応は担当Aさん、改善は担当Bさん」のような分業はしておらず、できる人が日々の問い合わせ対応を行いながら、改善活動にも手を動かす、という形です。

エンジニアの多くは、もともと問い合わせ対応を中心にしてきたメンバーで、コドモンのプロダクト開発にはこれまであまり関わってきていませんでした。改善活動を進めるにあたり、他チームで開発を進めてきたメンバーも新たに加わっています。

改善を進めるうえで大事にしている2つのこと

CREチームで改善を進めるにあたって、方針として大事にしていることが2つあります。

定量でガチガチに判断しない。まずチームが自律的に動ける状態を作る。
何でもやるのではなく、まずは問い合わせ数の削減に繋がることに絞る。

並べてみると当たり前のように見えるかもしれませんが、最初に方針を考えたときは少し悩みました。

定量でガチガチに判断しない

改善を進めるにあたって、最初は「ROIの試算」や「どれくらい問い合わせが減りそうかの見積もり」など、きちんとした判断材料を揃えようとする発想もありました。ただ、そこまで厳密に定量で判断するのは一旦はやめることにしています。理由は3つあります。

1つ目は、チームの多くがリリース経験を持っていなかったことです。コドモンのコードをさわってリリースするという流れ自体が、多くのメンバーにとってはまだやったことのない領域でした。最初にやるべきは精緻な見積もりではなく、まずはチームで一度、開発からリリースを通して経験することだと考えました。

2つ目は、定量判断のためのデータ基盤が整えきれていないことです。効果を数値で測るにはそのための計測の仕組みが必要です。ただ、それを整備してから動き出すとなると、動き始めるまでにかなり時間がかかります。データが揃うのを待ってから動く、というのは今のフェーズには合わないと判断しました。まずは動くことを優先し、将来的にデータを活用できるようにデータを蓄積する仕組みの整備などを先に進めています。

3つ目は、アジャイルに小さく始めたかったからです。最初から精緻に判断しようとすると、どうしても計画が大きくなって一歩目が重くなります。そうではなく、小さく動いて、動いてから学んでいく方がいいと考えました。

問い合わせ削減に繋がることに絞る

もう1つ大事にしているのが、やることの軸を絞るということです。

CREという名前のチームなので、やれそうなことは無数にあります。UX全般の改善、技術負債の解消、新機能の開発など、どれも価値を生む可能性はあります。

ただ、スコープを広げすぎると、チームが「なんでも屋」のようになってしまいます。優先順位も曖昧になり、結局このチームは何のためのチームなのかが分かりにくくなってしまいます。それは避けたいと考えています。

そこで、まずは問い合わせ削減に繋がることに絞る、という軸を置いています。

この軸を選んだ理由はシンプルで、自分たちにとって一番分かりやすい指標だからです。CREチームは毎日問い合わせを受けている当事者なので、どの問い合わせが多いか、どれが重いか、どんな温度感で来ているかを肌感覚で知っています。そこに乗る形で「これは問い合わせを減らせるか」という問いで判断すれば、議論がズレにくく、判断もしやすいと感じています。

実際、アイデアを出し合う中で「これはやりたいけど、問い合わせ数には特に影響しないから今はやらないでおこう」という話になったこともあります。気になっている部分にすぐに手を入れられないもどかしさも生まれますが、軸がはっきりしているおかげで判断が止まらないのは大きいと感じています。

改善活動の進め方

改善対象を選ぶときの3つの観点

改善対象を選ぶときは、主に次の3つを見ています。

件数(定量)
対応の大変さ(定性)
温度感(定性)

件数は文字通り、その問い合わせがどれくらいの頻度で来ているかです。ここだけは数字で把握しています。前段で「定量でガチガチに判断しない」と書きましたが、件数はすぐに数えられるので、しっかりと見ています。

対応の大変さというのは、1件あたりの対応にかかる負荷のことです。調査の工数、回答の工数、それから対応そのもの(たとえばデータの修正作業など)まで含めて、どれくらい重いかを感覚で見ています。

温度感は、ユーザーの問い合わせ時の感情と社内の対応メンバー側の感情の二つの意味を含んでいます。ユーザーの気持ちも大事にしつつ、問い合わせを直接受けているのはCREチームなので、その当事者の「なんとかしたい」という感覚も、改善対象を選ぶうえで大事な情報だと考えています。

このうち件数だけが定量で残り2つは定性ですが、問い合わせを毎日受けているメンバー同士で話せば、この2つは感覚で十分揃います。

また、カスタマーサポートチームの意見も取り入れるためにヒアリングを実施したり、日々の問い合わせ対応のコミュニケーションの中で温度感についてやりとりしたりして、改善対象の選定に反映させています。

カンバンで改善タスクを管理する

改善タスクは、問い合わせ対応のカンバンとは別に、改善活動専用のカンバンで管理しています。カラムは「バックログ」「TODO」「DOING」「WAITING」「DONE」などの構成にしていて、課題の状態ごとに並べています。

ふせんにはタイトルだけを書く、というシンプルな運用です。詳細はメンバー同士の会話のなかで共有しています。

進捗の確認はデイリーの場で行っています。プランニングの場は月1程度の頻度で、問い合わせ対応が立て込んでいるときは無理に開かず、残っているタスクの状況も見ながらタイミングを調整するようにしています。

優先順位を決めるのもこのプランニングの場で、カンバンに並ぶ付箋を並べ替えながら話し合って決めていきます。

プロトタイプを起点にした他チームとの連携

CREチームには専任のPdMもデザイナーもいません。とはいえ、改善対象が決まってからのプロセスは、チーム内で完結させているわけではなく、他チームの力を借りながら進めています。

まずはエンジニア自身がプロトタイプを作る

改善の方向性が決まると、その改善を担当するエンジニア自身が、まずプロトタイプを作ることが多いです。

作り方の特徴として、最初から実装レベルのコードで作ったりすることもあります。Figmaなどのデザインツールで絵を起こすのではなく、実際のコードでワイヤーフレーム相当のものを組み上げていく、という進め方をしています。

この作り方で進めていると、画面の挙動や遷移を含めた議論がしやすいですし、合意が取れたものはそのまま実装に繋げやすいという利点も感じています。

PdMやデザイナーへの確認

プロトタイプができたタイミング、もしくは進める前の方針段階で、PdMやデザイナーに相談します。タイミングは改善内容の性質次第で、毎回どちらかに決まっているわけではありません。

相談相手は役割によって分かれています。

PdM: CREチーム向けに相談に乗ってくれる固定メンバー
デザイナー: 横断UXチーム(社内のUI/UXを横断的に支援するチーム)に相談
特定機能に手を入れる場合: その機能を管理している担当チームのPdMやデザイナーにも確認

体験やUIに変更が入る案件については、基本的にすべて相談しています。確認の重さとしては、軽いフィードバックというよりは承認プロセスに近い運用です。専任のメンバーはいないけれど、変更の品質は他チームと一緒に担保している、という形です。

横断UXチームについては、コドモンのデザインチームが発信しているnoteで紹介記事が出ています。コドモン社内でUXをどう支えているかが分かる内容なので、合わせて読んでいただけると雰囲気が伝わるかもしれません。

note.com

感じているメリットと課題

感じているメリット

実際にやってみて感じているメリットとしては、まず意思決定が速いことが挙げられます。チーム内でデイリーなどで方針を話してそのまま決めて動けます。PdMやデザイナーへの相談は並行で進められるので、全体のスピード感は損なわれにくいです。

もう1つは、当事者意識が自然と生まれやすい構造になっていると感じています。問い合わせを毎日受けている本人たちが改善を進めているので、「なぜそれをやるのか」の温度が最初から共有されています。議論の出発点が揃っているので、優先順位の議論も早いですし、手を動かすときのモチベーションも自然と出やすいと考えています。

さらに、問題の本質的な原因を迅速に特定し、シームレスに修正まで繋げられる点も挙げられます。CREチームのメンバーはこれまでコドモンの広い範囲の機能の問い合わせ対応をしてきており、各機能の仕様やデータ構造への理解があるためです。

感じている課題

一方で、いまの進め方にはまだ課題もあります。

1つは、少しずつ定量のデータを追っていきたいという点です。いまは件数くらいしか数字では把握できていません。「定量でガチガチに判断しない」という方針自体はまだ変えるつもりはありませんが、改善の効果を数値でも見られるようにしていくと、判断の精度は上げていけるはずだと考えています。

もう1つは、問い合わせ対応と改善活動のバランスの取り方です。同じメンバーで両方を進めているので、問い合わせが立て込む時期は改善が止まりがちになったり、問い合わせ対応と改善活動でスイッチングコストがかかってしまいます。このあたりは一定仕方ない要素もありますが、より良い進め方を探りながら、少しずつ改善していきたい部分です。