こんにちは。VPoEの 安西 です。
先週、取締役の天辰からあすけん全体、取締役兼CPOの道江がプロダクトマネジメントチームのお話をポストさせていただきました。続きまして私からは、プロダクト開発組織の視点でお話してみようと思います。
タイトルにも書きました通り、4月よりプロダクト開発組織を大きく変えさせていただきました。まずその背景から整理していきます。
50人の壁を超え、組織化が必要になった
50人の壁という言葉がありますが、まさにあすけんの社員数がその人数を突破しました。
数年前までは少人数で開発していたので、役割を超えた会話も容易で、意識的に組織化や情報共有をしなくても、作業の目的や施策の効果などを全員が理解しながら開発ができました。
少しずつ人が増え、これまでのような情報共有が難しくなり、なにもしないと役割別に分断したり、自分が開発しているものがなんのためにやっているかわからない、みたいなことが起こるようになってきます。そのため、そろそろある程度組織化をしないと、全員が同じ目的やゴールに向けて進みにくい状態になってきました （とはいえまだ50人程度なので、やり過ぎ危険ではあるのですが）。
また、数年前までは取締役の道江が多くの意思決定を行いスピードを出せていましたが、組織が大きくなるにつれより全体や上位のレイヤーを見る必要があり、現場を見られる時間が減った結果、権限委譲が必要になりました。これも理由の一つです。
全員でユーザ価値に向き合える組織を目指して
ある程度組織化するとはいえ、手段が目的化しないように目指す姿をイメージしておいたほうが良いと考えました。その時に道江と私で考えた目指すイメージ像はこれです。少し抽象度が高めなのですが、まずはここにピン留めした上でどうするかを整理しました。
プロダクトを中心にとらえ、全員でユーザ価値に向き合える組織になる
目的はユーザ価値です。これを目指さないと、自分たちがなんのためにやっているかわからなくなり、（アウトプットが出たとしても）アウトカムが出ず、モチベーションも上がらない。ユーザのためにも我々のためにもなるような方向性をイメージしています。
その上で、このように組織とチームを整理しました。
①機能別組織から目的別組織（事業部制）へ
これまでは会社全体が機能別組織でした。つまり、エンジニアだけで部門になっていたわけです。今後は、人数が増えたとしても役割を超えてユーザ価値に一丸になる必要があります。そこで、プロダクト開発に必要な複数の役割がプロダクト別に集め、目的別組織（事業部制）にしました。
一般的にはどちらの組織の形が良いというわけではなく、どちらにもメリットとデメリットがあるのですが、現時点でのあすけんは目的別組織を選択しました。
②プロダクトマネージャーの役割をつくる
これまで道江が中心にプロダクトを見ていたため、プロダクトマネージャーというような役割を明確にせずとも問題ありませんでした。今回組織で開発するということで、4人がプロダクトマネージャーになりました。そのうち2人が、エンジニア出身のPdMです。
③目的別のプロダクトチーム組成
図に書いたとおり、4つの役割が一つのチームとなり、一眼となってユーザ価値に向かえるような形にしました。チームは最大でも6人程度で、複数の目的別チームがあります。
珍しいのはドメインエキスパートである栄養士さんがチームにいるところです。後日、このブログになにをやっているかを書いてもらおうと思っていますので、是非ご期待ください。
不確実性に向き合い、チームで学習し続ける
次に、上記組織でどうやるかを整理してみようと思います。
プロダクト開発はユーザ価値の創出からデリバリー後まで不確実性が高く、わかりやすい答えを出すことができません。常に正解がわからない前提で前に進む必要があります。そのためにどうすればよいかというと、
- 仮説検証のプロセスを回す
- 具体と抽象を行ったり来たりする
この2つを常にやり続けることが必要だと考えています。
①仮説検証プロセスを回す
明確な答えがわからないため、大小仮説を立て、検証を重ねていきます。上手く行けば次のフェーズへ、上手く行かなければ改善して再度検証を重ねます。
具体的には、上期はこの3つのポイントを重視しました。
- ユーザ価値の仮説検証プロセスを回す
- 開発プロセスはスクラムを採用する
- アーキテクチャの刷新もPoCをして検証期間つくる
このように、プロダクト開発に関係する全ての要素で可能な限り仮説検証のプロセスを回せるように工夫を重ねています。
②具体と抽象を行ったり来たりする
意外に難しいのがこれです。仮説検証を回したり、スクラムで期間をスプリントとして区切るとしても、目の前のことにフォーカスするだけでなく、全体像の中でどんな意味があるのか、それを繰り返したとして数カ月後にどうなるのかなど、全体を俯瞰しながら進める必要があります。そうしないと、手段が目的化したり、アウトプットは出ても本来のアウトカムに繋がらなかったりしてしまうことがあります。
具体的には、以下のとおりです。
- 目的/ゴールをチーム自ら設定し、認識を合わせた上で目の前の開発を行う
- プロダクトマネージャーは、プロダクトの4階層（書籍「プロダクトマネジメントのすべて」より）の上から下を行ったり来たりする
- 機能開発だけでなく、全体俯瞰でアーキテクチャ刷新やインフラの設計も全体方針として行う
ということを行ってきました。
半年やってみた
ちょうど半年経ったので、9月にふりかえりを行ったのですが、うまくいったこともうまくいかなかったこともたくさんありました。半年前を思い出すと大きく変化し、良くなったと感じますが、まだまだ道半ばだなと思っています。
反省としては「欲張ってしまった」ことです。人数も増え、チーム体制も整理したので、たくさんのことをやろうとしてしまいました。特に価値探索プロセスが片手間になりPdMたちはとても大変でした。
ただ、おかげでやるべきことの優先順位は見えてきたので、下期はもっとやるべきことにフォーカスし、チームが動きやすく、アウトカムに向かいやすい状態にしたいなと思っています。
冒険はまだまだ続く…
ユーザに価値を出せるよう、それによって関わっている仲間たちが充実して開発ができるよう、本当の課題に目を向け（これはつらい部分もありますが…）、どんどん改善していい環境を作りたいと思っています。
まだまだ人数も足りていません。是非一緒にやっていただける仲間を増やしたいです。ご興味があれば是非お気軽にご連絡ください。
