初期段階で供給側を備えた急速なスケールアップを実現するには、高いダイナミクスと少ないリソースでの成長が求められます。スケールアップ中の運用ミスは、莫大なコストを伴いかねません。
私たちがこの問題に直面したのは、エドテックに参入し、オンライン チャットで何百万人もの学生のリクエストにほぼ瞬時に答えられる機能を専門家に提供することを目的とした教育アプリを立ち上げようと決めたときでした。
当初は20名ほどのチームでスタートしましたが、初期段階では需要を満たすには十分でした。しかし、事業を収益化するには、真の競争が始まりました。マーケティングチームはユーザー数を拡大する必要があり、オペレーションチームはそのペースに合わせて供給側を拡大する必要がありました。
チームのリソースを考慮せずに需要を拡大しました。
私たちはすぐに軌道に乗りました。120人以上の専門家が毎日3,000以上の数学問題を解いていました。市場で生き残るためにこのハイペースに賭け、運用チームはサプライサイドを飛躍的に拡大しました。
マーケティングは急速に拡大し、これは良い兆候でした。ユーザーからの需要増加に間に合うように対応する必要に迫られたため、チームは供給側を1ヶ月半で3倍、2ヶ月後にさらに2倍に拡大しました。最終的に、300人以上の数学エキスパートが集まり、毎日1万件以上のタスクを解決できるようになりました。私は誇りに思うと同時に、興奮と不安でいっぱいでした。
過去5ヶ月間、私たちの供給体制は需要への対応、サービス提供の迅速化、そしてソリューションの品質向上に注力してきたことに気づきました。私たちは事業拡大に集中し、チームのリソースがこれほどのスピードで事業を継続できるかどうかを考える余裕などありませんでした。
テッククランチイベント
サンフランシスコ | 2025年10月27日～29日
リーダーとして、私は立ち止まって全体像を把握する必要がありました。
迫りくる「大惨事」を防ぐために私が考案した5段階の計画
1. 主要なプロセスをすべて「そのまま」記録する
これは見逃してはならない最初のステップです。
プロセス表記がない場合、よくある問題となります。作業ペースが速い場合、現在のプロセスを記述するよりも、タスクをすぐに実行して問題を解決しなければならないことがあります。
その時のプロセスをありのままに描写しました。そうすることで、私たちがその瞬間にどこにいたのかを真に理解することができました。何が制御不能になり、近いうちに大きな問題を引き起こす可能性があるのかを把握することができました。
その後、すべてのプロセスは次のフレームワークに従って更新されました。
2. すべてのボトルネックを特定
私は 2 種類のボトルネックに気づきました。
1 つ目は、スケーリング中に主要プロセスに自発的に追加されたサブプロセスです。
アップデートの回数が多すぎて、チームメンバーがこれまで気づかなかった追加作業をあまりにも多く行わなければならないことに気づきました。そこで、これまでの取り組みを見直し、プロセス全体を簡素化しました。結果に最も影響を与える「必須」の作業にのみ焦点を当て、他の「できればやっておきたい」タスクは保留にしました。
2番目:タスクを時間どおりに委任せず、膨大な数のタスクを抱え込んだマネージャー。
残念ながら、私もその一人でした。あまりにも多くのことを同時にこなしすぎていて、どれも最後までやり遂げられませんでした。私の場合、主な原因は採用ミスで、それが最も大きな損失となったようです。
そのことに気づいた後、私は期待通りの成果を上げられない人材を解雇することを決意し、説明や追加指示、そして二度目のチャンスを与えることに時間を浪費することをやめました。そして、チームを強化してくれる、実績のある適切な人材を採用することに注力しました。
3. 「重大1」および「重大2」の問題のリストをまとめた
私は、最も重要な問題から最も小さな問題へと、優先順位に従って行動することにしました。
私たちの主要なプロセスは、サプライ部門において、数学の専門家の大量採用、オンボーディング、そしてパフォーマンストラッキングという3つの領域を中心に構築されています。専門家のオンボーディングが行き詰まり、採用プロセスが停滞し、パフォーマンストラッキングにも支障をきたしていた時期がありました。オンボーディングに関する重大な問題を解決し、新たな専門家がサプライ部門に加わったことで、新たに採用すべき専門家の数と、パフォーマンストラッキングの対象となる専門家の総数を把握することができました。
4. すべての運用プロセスを見直し、最適化計画を策定
すべてのプロセスを 2 つの最適化タイプに分けました。
まず、チームの構造、役割、機能、ワークフローを再設計しました。
私のチームメンバーのほとんどは、異なるプロセスを参照する複数のタスクを実行していました。
サプライサイドを立ち上げたばかりの頃は問題ありませんでしたが、サプライヤーの数が増えるにつれて、チームメンバー一人ひとりの業務を一つの大きなプロセスに沿って構築し、最終的な結果に責任を持つ必要が生じました。
2 つ目:最適化の余地がなくなったため、自動化が始まりました。
プロセスの自動化には、「何を」「どのように」「なぜ」行うのかという明確な理解が必要です。人為的なミスによるコストが開発者の時間コストよりも高くなるため、自動化を導入しました。自動化が完了した後、運用チームの作業時間を数時間節約し、迅速に成果を上げられるようになり、次に行うべき重要な作業に集中する時間を確保できました。
5. 最適化のタイムラインを作成した
これにより、複数のチームを同時に追跡し、最新情報を把握してプロセスをすぐに再開できるようになりました。また、コミュニケーションを増やし、短いステータス確認ミーティングの回数を増やすことで、お互いの状況を把握し、チームの結束をより強固なものにしました。
災害は回避されました!
すべての対策が効果的であることが証明されました。サービスは継続して運用され、製品はテストを継続し、マーケティングは需要の拡大に対応していました。数ヶ月にわたる狂ったような作業の後、私たちは安堵のため息をつきました。振り返ると、運用チームには8人の新しいメンバーが加わり、プロセスは最適化・自動化されていました。
熱意は評価基準ではないことに気づきました。リーダーは皆、新たな目標に熱心に取り組みながらも、チームのリソースを考慮に入れるべきです。
「私たちは新たなレベルへの準備ができているだろうか？」そして「チームが新たな成果に備え、新たな成果を達成した直後に全員が失敗しないようにするために、私は何をしただろうか？」これらは、私が今日、運用チームの業務を計画する際に常に自問自答している質問です。
