※ 2021年8月ごろの組織体制や考えを記載したものです、最新の状況とは異なることがあります。
almaの共同創業メンバーのkenjiです。エンジニアからデザイナー、プロダクトマネージャーを経て、現在はプロダクトデザイナーという役割を担っています。
先日、alma社の採用ページをオープンしました。
ここでは募集要項だけでなく、会社のミッションや組織図、カルチャーを知れるようになっています。
中でも組織図は、一風変わったものになっており、いわゆる「開発部」「XX事業部」といった分け方ではなく、もっと踏み込むと「エンジニア」「UIデザイナー」といった職種の分け方も現状はありません。
今回は、なぜこのような組織設計にしているのかについて、組織設計を通して解決したかった課題とともにお伝えします。
- プロダクトや事業の目線で動けるチームにしたい
- カルチャーを維持したまま組織を拡大していきたい
などの想いを持つ方に参考になると嬉しいです。
先ほどの画像のように、almaでは4つのチームに分かれています。
Product Design ... プロダクトのロードマップに基づき、ユーザー課題の発見から、解決策への落とし込み、UIデザイン、実装と、柔軟に動いていきます。
Product Research ... プロダクトの使われ方やデータなどを見ながら、プロダクトロードマップの改定、成長の方向性検証、UIデザイン、実装、ダッシュボード整備などを行っていきます。
Communication Design ... 事業のロードマップに基づき、ターゲット層の認知拡大からプロダクトの利用、ファンになっていくまでの一連のタッチポイントを設計します。
Market Research ... ターゲットの定義や、必要なプロダクトの定義をしながら、事業ロードマップを策定し、ターゲットの検証、価値・課題の検証などを行なっていきます。
(各チームの詳細な動き方はこちらに順次まとめていく予定)
そのため、組織図に補助線を引いていくならこのような感じです。
扱う対象がプロダクト or サービス全体 (市場) でまずは切り分けています。
さらに、仕事の仕方 (ワークフロー) を軸に補助線を加えてみます (見やすさのためにチームカラーを変更していますが、順番は一緒です)。
大まかに言えば、以下のようなイメージです。
1. Product DesignとCommunication Designは、ロードマップをユーザーにフィットする形で具体アウトプットに落としていく
2. Product ResearchとMarket Researchは具体アウトプットからユーザーの行動や反応を見ながらロードマップに落としていく
そして、各チームごとに役割や四半期の目標、チームを表すカラーコードなどを独自に決めています。
例えばProduct Designでは、このように定めており、水をテーマにチームカラーを決めています。
チームごとにnotionページを持っており、いつでもチームの状態や目指している部分をキャッチアップ可能です。
なぜ持っているプロダクト (Cocoda / Cocoda Board) ごとにチームをつくらなかったのか、なぜエンジニアチームのような職種に分けたチームをつくらなかったのか。
これらのアンサーとともに、今の組織図で解決したかったポイントをまとめてみます。
※ 組織図には絶対的な正解があるわけではなく、事業が位置する市場と、組織を構成するメンバー/カルチャーによって決まると考えています。なので、一つのパターンとして見ていただけると嬉しいです。
2020年ごろは、以下のような組織図にしていました (組織図は全てfigmaで管理してます)。
対象とする顧客 (企業 or 個人) で分けたものを、toBチーム/toCチームとし、課題発見に注力していました。
そして、両チームが見つけた課題を、さまざまなスキルで解決するプロフェッショナルチームといったものをつくっていました。
ただ、この分け方では「ユーザーと企業の課題両方とも解決するような解決策」や「そもそもプロダクトのコアな価値を変えるような発見・アイデア」はなかなか出てきにくく、どんどん小さいレベルでの最適化に走っていってしまいました。
チームメンバー個人単位で見ると、そのようなアイデアが出てきうるメンバーもいたのですが、チーム構成、組織構造的に根本的な改善や意思決定がやりにくくなっていたのです。
まだまだ価値を模索し、PMFを探索する局面では、この組織図ではまずいと思い、組織の構造から変えることにしました。
次に試したものが、プロジェクトベースの組織図でした。
プロフェッショナルチームはそのままに、事業で解くべき課題ごとにプロジェクトをつくっていき、より流動的な組織にしていきました。
大きな変更でもあったので、オンボーディングとして (当時からハマっていたスプラトゥーンをモチーフに) クイズ大会をしていました笑。
非常に盛り上がり、うまく目線が揃った場になりました。
組織図が変わることは、メンバーにとっても少なからず負担はありますし、経営がトップダウンで決めて終わり、というのも創業期の私たちとしてはよしとしなかったので、全員の納得度や認識のすり合わせを重視していました。
👆締めのスライド
このプロジェクトベースの組織図は、比較的うまく回ったのですが、1つだけ大きな問題がありました。
それは、「リリースしたら終わり」という状態になってしまって、結果の計測や新たな仮説出しがおざなりになってしまっていたのです。
リリースしてから結果が出るまである程度時間差はあるので、プロジェクトとしては一旦終了して、他のプロジェクトに入る形でやっていたのですが、それだと結果の計測は個人の努力で行うしかありませんでした。
また、プロジェクトのスコープを計測まで入れると非常に時間がかかり、検証のスピードが落ちてしまうこともあり、悩ましい問題でした...。
そのため、「どんな流れが理想か」から考え直しました。
当時似た問題として「商談が売って終わり」問題も同じく合ったので、組織全体を見直そうと経営チームで話し合いを進めていきました (👇当時の議事録の一部)。
理想のワークフローを可視化。
ワークフローに基づいて、組織図を発散。
名前もさまざま発散していました。
そうして、最初にお伝えしたような組織図になっていきました。
現状は、この組織図に加えて、以下のような権限のイメージで運用しています。
almaが運営しているCocodaやCocoda Boardは、まだまだ未開拓の市場なため、メンバー一人一人が「事業の価値を大きくする神の一手」を打てるような組織にしていくことが重要だと思っています。
そのため、組織構造も生産性よりインパクト重視、マネジメントよりも自立/自走重視な構造になるように試みています (よりスタートアップネイティブな言葉に寄せるならラーニングアニマルでい続けられることを重視しています)。
一方、少し触れたように、組織図を変えることはメンバーの負担も伴います。
スタートアップに変化はつきものですが、人間にとって変化はストレスにもなりえます。
そのストレスを楽しめるカルチャーはもちろん大事ですが、組織図などのカルチャーをも揺るがすレベルの意思決定には以下のポイントに気をつけないといけないと思っています。
1. 想定通りに新しい組織図が機能するには時間がかかる (小さな組織だと2, 3ヶ月以上はかかるイメージ) ので、前もって慎重に意思決定をする必要がある
2. 新しい組織図や体制への移行は、必ず納得感を重視する。納得感が一番ではないが、それが無いと意図しない認識の齟齬や、メンバーの離反が生まれる。
総じて組織全体の意思決定は、遠心力のように、決めてもすぐには変わらず、突然新しい方向には動かしづらいものだと学習してきました。
今後も改善を続けていくので、中で一緒に「価値の探索に真っ直ぐな組織」をつくっていきたい方はぜひこちらからお話させて下さい。