1. CRE の働き方のこれまでとこれから
こちらのTech Blogでは初めまして、こんにちは、みてねCREグループでEngineering Managerをしているmasartzです。
上記の記事において、CRE グループの基本的な部分、Vision や Value などを中心にご紹介しました。 本記事においては、そこからさらに一歩踏み込み、カジュアル面談や採用面接において頻出の「普段どのような働き方をしているか」の解像度がより高まることを期待した内容をご紹介します。
2. 働き方の全体像（半期 → Epic → 週次 → Daily）
半期目標の設計
CRE の業務は半期ごとの目標設定を起点に設計されています。目標設計には OKR のプラクティスを意識しています。 みてね全体では OKR を導入していないため、CRE でも「OKR で目標管理している」とは明言していません。OKR の目標設定は、レイヤを跨いでネストされた目標が管理される（上位レイヤの KR が下位レイヤの Objective になる）のがお作法だと考えているためです。これが成立しない状態で「OKR 導入している」と謳うのは、適切ではないと判断しています。
また、大事なポイントは OKR を用いること自体ではありません。「ストレッチな『ありたい状態』（= Objective）を置き、そこに到達できるかを定量的に計測する」という行動設計が、事業インパクトを出す上で有効であると考えています。その意味で CRE で最も大事にしていることは「不確実性を解く」ことだと言えます。
上記において「定量的に計測する」ことが狙いの一つであるとしましたが、実際には全ての目標が同一の基準で評価できるわけではありません。目標は（定性 / 定量）×（プロセス / 結果）の 4 象限に分布します。 2025 年 4 月から 9 月の半期において設定した例を参考にすると
- 定量結果目標
- 【CS 向け】2025 年 8 月末時点で、累計 x 件のお問い合わせが自動返信されている
- 定性結果目標
- 【マーケ向け】配信システムのどの機能がいつ・誰にどれだけ使われたかが明らかになっている
- 定量プロセス目標
- 【自グループ向け】採用面接を 5 件実施していること
- 定性プロセス目標
- 【マーケ向け】配信システムが掲載面に依らず共通の設計/インターフェースとなっている
などです。 評価指標が 4 象限に分割されるのは、「ありたい状態」の解像度の違いに依存します。解像度が高いほど、定量結果目標が設定しやすくなり、定性結果目標 → 定量プロセス目標 → 定性プロセス目標 の順で解像度は落ちていきます。CRE では複数の軸(CS 向け、マーケ向け、Customer 向け etc)のそれぞれに対する半期ゴール（= ありたい状態）を設定します。そのゴールに対する測定指標で解像度が低いものしか挙げられていない場合、それはゴールが曖昧であるかもしれない黄色信号と捉えています。 半期ゴールは、チーム全員参加の目標設定ミーティング（長時間のワークショップ形式）でベースを定めます。各軸（CS/マーケ/Customer 等）の「ありたい状態」を出し切り、4 象限に落としてから優先順位と指標を確定します。
図1. 目標の4象限モデル（定性 / 定量 × プロセス / 結果）
よりシンプルな4象限の分解事例
例えば今週末のプライベートの目標を考えるとします。
まず「子供が楽しく遊べる公園を3つリストアップする」などが思いつきそうです。これはなんのためのものでしょうか？それを考えると「でかけた公園で子供が楽しんで遊ぶ」という定性結果目標のための必要要件であることがわかります。であるならば「でかけた先で子供が楽しんで遊ぶ」ことを定量的に測るとどうなるでしょうか？などを検討した一つのサンプルが以下のようなものです。
- 定性プロセス目標
- 睡眠を十分に取り、体調を整える
- 定量プロセス目標
- 子供が楽しく遊べる公園を3つリストアップする
- 定性結果目標
- でかけた公園で子供が楽しんで遊ぶ
- 定量結果目標
- みてねに写真・動画を合わせて10枚uploadする
これを達成できれば、「家族で幸せな週末を過ごす」という「ありたい状態」が実現できていると言えます。
半期から日々のタスクまでのブレイクダウン
4象限モデルで「目標の質と解像度」を整理したら、次に見るべきは「時間軸の接続」です。CRE では、半期という長期のゴールと日々の開発サイクルをどのように一貫させているのかを、ライフタイムの構造から見ていきます。
図2. 半期目標から日次タスクまでのライフタイム構造
OKR では Key Result のための Action を定義することがあります。みてね CRE では、これは Epic ticket として管理されます。「ゴール」と「計測指標」のライフタイムが半期であるならば、Epic のライフタイムは数週から数ヶ月という単位になります。Epic は単なるタスクの寄せ集めではなく、計測指標を前進させるための主要アクション群です。その後、Epic から複数の Backlog Item が生まれ、各 Item を基本的に 1 Sprint（= 1 週間）で対応していくのが、CRE の日常業務となります。
日常業務は Scrum のプラクティスをベースにしていますが、正直に言って厳密な Scrum 運用はしていません。 Daily では Proactive Task（目標達成のための自発的な取り組み）と Reactive Task（お問い合わせ・運用）の両立を図ります。基本的に Backlog Item について話し合いますが、その内容は Sprint Review（スプリントレビュー）に近いものです。メンバーが少人数であることを活かし、短いサイクルで濃いコミュニケーションをしながら Item を完了させます。 チケットアサインの観点では、Epic（数週〜数か月のまとまり）単位で各個人にアサインがなされ、各個人にその Epic 完了の裁量があります。一方で、特定 Epic に紐づく Backlog Item は複数人にアサインされることが日常的です。結果として、Epic のオーナーシップは個人にありつつ、進捗させるのはチーム全員というコラボレーションが実現できています。
リソース配分は、Proactive が原則優先です。実績としては Proactive:Reactive がおおむね 7:3 程度で、タイミングによっては Reactive が 1 割未満となることもあります。 Weekly で Retrospective（= 振り返り）を実施し、シンプルな KPT（Keep/Problem/Try）を用いています。ここで上がってきた P は Weekly 実施という性質から直近で遭遇した短期で解ける Toil（反復的で付加価値の低い作業）であることがあります。こういった Toil を適切に消化しないと長期的なチームパフォーマンスに影響するため、意図的に即座に次のSprintに入れるようにしています。
このような形で半期の業務が進んでいくことを俯瞰すると、Product / Project / People / Technical の 4 種類の Management を横断的に担います。プロダクトの方向性、進行管理、チームのコラボレーション、技術的な検証と実装が、日々の実務の中で一体となって進みます。
3. 日々の開発作業と成果の出し方・測り方
Proactive Task(半期目標達成のためのタスク)
日々の開発は、実装前の計測設計から始まります。評価指標が定量である場合、その指標の現在値をまず最初に計測・可視化します。これをダッシュボードとして管理し、半期に渡って継続監視していくのが理想です。
次に、その計測指標の値を変化（＝多くの場合は、値を積み上げる）させるための仮説を立てます。この仮説の裏付けにおいてもやはりデータは必要で、その調査を実施し裏どりができることによって初めて価値提供（＝機能開発）の設計・実装に進めます。
実装においては、コラボレーションのしやすさと価値提供の速さを考慮して、できるかぎり小さい単位でPull Requestを作成しリリースを行います。Backlog Item とPull Requestの対比で言うと、1 対 N の関係性であることも日常茶飯事です。リリース後はデータの変化を観察し、仮説を更新。次の実験につなげます。
データ裏取りの実際とツール
分析は基本的に CRE 自身で行います。一方で、いざという時にはデータアナリストチームのサポートは受けられる体制もとてもありがたい環境です。可視化にはLookerを用いており、データアナリストチームには分析ロジックの考え方から、Lookerでの実現方法まで相談できる環境です。いずれにしても完璧さよりも最低限の計測・可視化から着手し、結果に応じて段階的に精緻化します。
Reactive Task(お問い合わせ対応や、プロモーション配信運用のためのタスク)
一方、Reactive Task としてお問い合わせやプロモーション配信運用に対応するものがあります。 これについては 過去の記事でも触れている通り、依頼内容そのままではなく、何を提案し提供することが本質的な課題解決につながるか、をとても大事にしています。
4. これまでのチームの変化・実績と、これから目指すこと
みてねCREはもともと Reactive な業務が中心のチームでした。社内では「管理画面開発」「問い合わせ対応」の色が濃く見えていた時期もあります。そこで Vision を定義し直し、半期ごとに挑戦的な目標を据え、Proactive Task に取り組む体制へと転換しました。以降は「不確実性を解く」ことを核に、活動の重心が明確になりました。
この転換の過程でいくつかの洞察が得られました。CS からお問い合わせ対応をエスカレーションされるだけだった状態から、Proactive にお問い合わせの解決に取り組もうとした結果、日々のお問い合わせ数、その分類などが明らかになりました。 次に、お問い合わせの全体像の解像度が上がったことで、お問い合わせ外の事象・ユーザーに目を向けることができるようになりました。それによって、ユーザーの自己解決に至るための手段の提供や、ユーザー自身が認識しきれていない潜在的な課題が朧げながら見えてきた段階です。これらの課題あるいは課題を解決した先にある「ユーザーが xxx である状態」というのは、CRE が持つべき重要な KPI 群になるであろうことです。そして、行き着く先には「顧客満足度」という状態があり、それを向上させることが KGI です。
これからは、KGI（顧客満足）に本当に効く KPI をどう設計し運用するか、という不確実性を解きにいきます。KGI を「顧客満足」と置くなら、KPI は“顧客が満足しうる数々の行動”と設計できると考えています。例えば、問題の自己解決率、失敗（残念）体験の少なさ、問い合わせからの回復時間などが候補です。KPI は複数を束ねてダッシュボード化し、相関を観察しながら“因果の可能性”を探索します。
みてねCRE の醍醐味は、課題設定からデータ裏取り、仮説検証、リリースまで自走できる裁量にあります。課題設定は誰の・どの行動に・どんな不確実性があるかを明文化する作業であり、データ裏取りでは偏り・規模感・期間を丁寧に吟味します。検証は小さく早く、検出力のある期間・閾値で評価することを徹底します。
5. まとめ
みてねCRE は「管理画面開発」「問い合わせ対応」に閉じない、顧客課題の不確実性を解き続けるエンジニアリング組織です。私たちは Reactive 中心から Proactive 中心へと転換し、半期 OKR から Daily までつなぐ運用と小さなリリース、計測先行の仮説検証で学習速度を高めてきました。関心のある方は、課題の共有や仮説検討からぜひご一緒できれば嬉しいです。
最後に、みてねCRE の成果は“静止画”ではなく“動画”で捉えるのが本質的です。単発の成功事例よりも、問題発見 → 問題定義 → 介入 → 学習 → 次の介入というサイクルが、どれだけ短く、どれだけ確度高く回っているか。その運用そのものがチームの資産です。
みてねCRE の求める人物像は「仮説思考と検証設計」「データ・ドリブンなコミュニケーションと合意形成」「小さく早く届ける実装力」です。もしご興味を持たれた方がいましたら、まずはカジュアルに課題や仮説の雑談からご一緒できれば嬉しいです。現場のドキュメントやダッシュボードの実例を見ながら、最初の“探索”を一緒に設計しましょう。
Discussion