こちらの記事は、アソビュー！ Advent Calendar 2025 の21日目（表面）です。
こんにちは。アソビューでエンジニアリングマネージャーをしている五十嵐です。
もうすぐ2025年も幕を閉じますね。
先日発表された今年の漢字は「熊」でしたが、みなさんはご自身の1年を漢字で表現すると何になりますか？
私も考えてみましたがあまり思い浮かばなかったので、1年間壁打ち相手になってくれたChatGPT君にお尋ねしたところ....... 「整」とのことでした！
派手さはないですが、「混沌をそのまま受け止め、壊さずに整える」 という難易度の高いフェーズにいる一年、という印象です。
というありがたいお言葉をいただきました... 😇
今回はその「整える」に纏わる話をご紹介します。
組織について
私がマネジメントしているプロダクト組織には開発チームが３チームあり、全体として18人ほどのエンジニアが所属しています。
それぞれの開発チームは日々開発ロードマップに向き合っていますが、それと同時にプロダクトの運用・保守も担っています。
プロダクト組織では、この運用・保守の文脈でプロダクトへのお問い合わせ対応をしています。
お問い合わせ対応
多様なお問い合わせ
アソビューではプロダクトの成長とともに機能や利用者も増え、プロダクトへのお問い合わせは多岐にわたっており、日々、Slackワークフローで依頼が届くようになっています。
問い合わせ内容としては、作業依頼、仕様確認、バグ報告、開発要望、等々... と、緊急度や難易度も様々です。
問い合わせフロー（before）
問い合わせ依頼者も適切な担当チームや担当者を把握しているわけではないので、私たちのプロダクトに関わる問い合わせについては、全体メンション宛に依頼が届き、自主性に任せて対応していました。
（PO：プロダクトオーナー、EM：エンジニアリングマネージャー）
graph TD
%% ノード定義
Requester([👤 依頼者])
PO[👑 PO]
Done([✅ タスク対応])
%% ▼▼▼ 開発者の苦しいゾーン ▼▼▼
subgraph DangerZone [😫 開発者の登場シーン]
direction TB
%% Step1
Step1[🔔 全体メンション通知<br>（全員の集中中断 ⚡️）]
%% Step2
Step2[🤔 誰が拾う？<br>（葛藤・お見合い）]
%% Step3
Step3[📝 内容確認]
%% Step4
Step4[⚖️ 実施要否・優先度調整]
end
%% ▲▲▲ ここまで ▲▲▲
%% メインの縦フロー
Requester -->|1.WF依頼| Step1
Step1 -->|2.誰かが反応| Step2
Step2 -->|3.担当決定| Step3
Step3 -->|5.整理完了| Step4
%% ★順序調整：POへの線を先に定義して左側に配置させ、Doneを後に定義
Step4 <-->|6.相談| PO
Step4 -->|7.タスク化| Done
%% 依頼者への戻り線
Step3 <-->|4.詳細確認| Requester
%% スタイル定義（背景黒対策・赤強調）
classDef default fill:#fff,stroke:#333,stroke-width:1px,color:#000;
%% 赤色強調クラス
classDef danger fill:#fff0f0,stroke:#ff0000,stroke-width:3px,color:#000;
class Step1,Step2,Step3,Step4 danger;
%% サブグラフのスタイル
style DangerZone fill:#ffeef0,stroke:#ffcccc,color:#cc0000
%% その他アイコンのスタイル
style Requester fill:#eee,stroke:#333,color:#000
style PO fill:#eee,stroke:#333,color:#000
課題と要因
これまでの問い合わせフローでは下記の課題が顕在化していました。
| 課題 | 要因 |
|---|---|
| 開発者のスイッチングコストの高さ | 常に全体メンション宛に問い合わせが届く |
| コミュニケーションコストの高さ | 依頼内容が不明瞭、プロダクトオーナーとの優先度調整 |
| 対応の属人化 | チームリーダーや責任感の強い人に対応が寄りがち |
| スクラム開発への弊害 | スプリント計画外の割り込みタスクの調整 |
新しい交通ルール
根本的な課題解決としては問い合わせを減らす・無くす、ということになりますが、短期的には対応が難しいため、まずは開発者の負担やスイッチングコストを減らすことで、より開発に向き合える環境を作ることを目指し、問い合わせフローの交通整理を行うことにしました。
問い合わせフロー（after）
フローを変更するうえで意識したポイントとしては下記になります。
1. 開発者への通知を減らす
2. 開発者が介入するポイントを減らす
（PO：プロダクトオーナー、EM：エンジニアリングマネージャー）
graph TD
%% ノード定義
Requester([👤 依頼者])
Manager[😎 EM / PO]
DevMember[開発者]
Done([✅ タスク対応])
%% 縦のフロー（上から下へ一直線）
Requester -->|1.EM/POへ通知| Manager
Manager <-->|2.内容整理| Requester
Manager -->|3.実施要否・優先度決定| Manager
Manager -->|4.開発チームへ依頼| DevMember
DevMember -->|5.タスク化| Done
%% 注釈
Note[💡ここから開発者が登場] -.-> DevMember
style Note fill:#ffffcc,stroke:#ebd62d,stroke-dasharray: 5 5,color:#000
%% スタイル定義
classDef default fill:#fff,stroke:#333,stroke-width:1px,color:#000;
style Manager fill:#e6f7ff,stroke:#0099ff,stroke-width:2px,color:#000
style DevMember fill:#f0fff0,stroke:#00cc66,stroke-width:2px,color:#000
style Requester fill:#eee,stroke:#333,color:#000
効果
運用前後でどういった効果があったか、定量的な数値で比較してみました。
問い合わせはSlack上で依頼されるため、旧運用と新運用で同時期（1ヶ月分）の問い合わせSlackスレッドを分析しました。
| 比較項目 | 旧運用 (Before) | 新運用 (After) |
|---|---|---|
| 全体への通知数 （開発チーム全体へのメンション） |
36 | 2 (📉 94%減) |
| 開発者の関与数 （スレッド内のコメント数） |
179 | 79 (📉 56%減) |
| EM/POの関与数 （スレッド内のコメント数） |
184 | 282 (📈 53%増) |
全体への通知数の激減
「1つの問い合わせの度に、開発者全員に通知が飛ぶことで思考を遮断する」という事態をほぼ撲滅しました。
関与数の増減
開発者の関与数は減っている分、EM/POの関与数が増えています。
コミュニケーション総量にあまり変化がないため、一見すると単に担当を委譲しただけで効果がないように見えますが、開発組織全体としての損失コストは圧倒的に低いと言えます。
ポール・グレアム氏が「Maker's Schedule, Manager's Schedule」でも言及していますが、マネージャーと開発者（Maker）の時間の使い方が異なります。
開発者（-100件の意味） 開発者にとっての1回のコメントは、単なる1回の投稿ではありません。コーディングという深い集中（フロー状態）からの「100回の強制中断」がなくなったことを意味します。これにより、機能開発の質とスピードが向上したと捉えることができます。
EM/PO（+100件の意味） マネージャーの業務は元々、細切れのタスクや調整を行う「割り込み型」のスケジュールです。私たちが100件余分に対応することは、開発者が100回中断されることに比べれば、組織全体としての損失コストは圧倒的に低いと言えます。
さいごに
今回行った交通整理は開発者が本来向き合うべき業務に注力できるようにするための改善でした。
今後は根本的に問い合わせを減らす・無くすことにフォーカスしつつ、それでも残る部分はAIを活用した自動化を推進していこうと考えています。
アソビュー！では「生きるに、遊びを。」を実現していくために、今後もサービスをさらに成長させていく必要があり、その仲間をまだまだ募集しております。少しでも興味を持っていただけた方は、ぜひエントリーを検討してみてください！
