みんなで進める「権限委譲」
こんにちは、英語アプリmikanを運営する株式会社mikanの溝口です。
英語アプリmikanの責任者をしています。
mikan Advent Calendar 2024 24日目の記事を担当します。
23日目はiOSチームの @satoshin21 から「mikan iOS 2024年の技術的構成について」でした。 2022年にもiOS開発の全体像が見える記事を書いてくれてたのですが、2年間の変化がわかりやすくまとめられているのでぜひご覧ください！
はじめに
スタートアップの課題あるある、委譲。
する側も、される側もどちらにとっても難しいものです。
今後のビジョンから考えると確実に必要な委譲でも、現実では目の前に緊急性の高いタスクが山ほどあり、それらをさばくのが最優先で、意思決定権を得ていく、渡していくことは相対的に優先順位が落ちやすい構造にあります。
このnoteでは1つのケーススタディとして、900万人のユーザーを抱える英語学習アプリmikanのディスカバリーフェーズを例にどのように委譲を進めてきたか紹介します。
どうフィードバックをもらうべきか悩みがちな方、なかなか委譲をすすめられなくて困っている方に向けた記事ですので、よかったらご覧ください。
※この記事は、失敗経験も含めてその対応をケーススタディとして共有するものです。
委譲というテーマも相まって、私自身読んでいて「なんてえらっそうなんだ…」と感じますが、色んなものを守りすぎて意図が伝わらないなんてことにならないよう、このようにしています。
正解を述べるものではなく、同じような課題に向き合う方々の改善のきっかけになれば幸いです。
前提ときっかけ
今回 例としてお伝えするのはプロダクトチームです。
構成としてはマネージャーの私、事業企画1名、PM2名、デザイナー2名の、合計6人のチームです。
実は、今回お伝えする委譲例は、狙って進んだものではありません。
mikanでは毎週全メンバーが参加できる企画会議があるのですが、そこで起票される内容にまとまりがなく、各人のアタマの中で考えてることが揃っていないぞ…と感じたのが最初で、それを解決していったら結果的に委譲が進んだというものでした。委譲しようと意気込んで進んだわけではなかったのです。
今になってみると、これはあくまで氷山の一角で、デザインレビューをはじめとする色んなシーンで実は日常的に起きており、自分が参照点を作れていなかったと反省していますし、タイトルの通り、委譲はみんなで進めるものなんだと気づくきっかけにもなりました。
委譲を進めるためにやったこと
やったこととしては大きく3つです。
1.参照点をつくる
2.参照点を一緒に育てる
3.参照点をベースに対話する
ひとことで言ってしまえば、指針をつくろうという話ではあるのですが、つくった指針が日々の行動レベルまで自然と繋がっていく、運用まで含めた設計がキモです。
1.参照点をつくる
参照点とは、言葉のまま みんなで参照するところ、コンパスのようなものです。mikanでは下記の4つを参照点にし、事業成長と日々のアウトプットが繋がるようにしていきました。
それぞれがどんなものか、ここでの説明は割愛しますが、気になる方は私に連絡いただくか、事業企画のsakuさんのnoteをご覧ください。
2.参照点を一緒に育てる
参照点を作っていくのは中々骨が折れる仕事ですが、本当に大事なのは、作った後もこの参照点が更新され続けていくこと。企画や分析といった普段から必ずやっているタスクを通して、意識せずとも自然に触れ続け、みんなで育てていくことが肝要です。
今回のプロダクトチームの例では、企画およびその具現化フローを変えました。具体的な内容紹介は本題から逸れるので省略しますが、変わったのは大きく2点です。
1. 責務の一部をデザイナーからPMに。
いろいろ狙いはありますが、このnoteの文脈で言うと、参照点にフィードバックががかかりやすいよう、ペアになってディスカバリーする体制になりました。
2.レビューポイントを3つに分けて、フィードバック機会を定点化。
デザインの5段階モデルをベースに自社の解釈も踏まえて「構造・骨格フェーズ」「要件決定フェーズ」「表層フェーズ」と分けました。
(ここも面白いので紹介したい..)
どちらも意識せずとも毎日自然に触れ続けられる機会であることが、仕組みとして非常に重要なポイントです。
3.参照点をベースに対話する
参照点と、それらに触れる機会ができたので、実際の活用フェーズに入ります。
具体的にはレビュー(稟議)、壁打ちなどの日々のワークフローにおいて、フィードバックする際に参照点を経由することで、自然に触れる回数を増やしました。レビュアー側もレビュイー側もそれを背景に考えるので、話していっても個人の趣向・感想による着地で終わらず、参照点の修正に帰着します。
また、それだけではレビュー頻度減っていきません 。(= 実質的に委譲が進んでいきません。)
少しずつでも実現するために、どう考えればレビュイー自身でこの結論に至ることができたかを一緒に考えていきます。
実際に進める際は、要因を以下の4つにパターンを分けて、内容ごとにフィードバック→次のレビューに向けて改善というサイクルを回していきました。
1. 自分で決め切るスタンスがなかった
2. 決め切るにあたって必要な情報がなかった
3. 決め切るための時間がなかった
4. 決め切るための自信がなかった
このプロセスを経ることで、参照点自体のアップデート、個々人のスキルや目標のアップデート の2つに改善がかかります。マンパワーだけで解決するのではなく、仕組み側も解決し、両輪のサイクルが回ることようにしました。
実際この記事に書いてある参照点は4つありますが、1発完成ではなくどれも段階的に1つずつ作られていったものです。
最近で言えばプロダクトバリューの策定もその一例として育てているところです。まだまだ詰めるところはあるのですが、こちらもぜひご覧ください！
1年経った今
このフローで進むようになって1年ほど経ちました。
定性感覚ではありますが、以前よりも認識統一が進み、企画会議でのレビュー内容も減りました。都度のコミュニケーションではなく、組織内の参照点として残るようになったことで今後の拡大に耐えうるレバレッジがかかる仕組みを作れていると思います。
理想はポジションごとドカっと渡していくことですが、そんな綺麗に切り替えられないのが現実。委譲はする側、される側、双方にとって難しいので、現実的に少しずつ渡していくHowの一例として参考になれば幸いです。
mikanでは絶賛採用中です！
こんなふうに書いてきたのですが、正直なところまだまだ課題だらけです・・・！
ここから数年でコア導線が何度も大きく変わり、プロダクトとして大きな進化を遂げていくタイミング。
自分たちが欲しかったものをつくっていける刺激的なタイミングですので、気になった方はぜひお気軽にご連絡ください！
toC事業
toB事業 (学校・塾向け)
少しでも気になった方はぜひご連絡ください！
メリークリスマス！！🎄
いいなと思ったら応援しよう！
