見出し画像

事業とプロダクトをつくる組織作り

Happy Holidays! エンジニアリングマネージャーをしている @dskst9 です。

この記事はShowcase Gig Advent Calendar 24日目の記事です。 本エントリは、Showcase Gigのプロダクトをつくる組織がどのようになっているのかを紹介します!

事業を行う組織

Showcase Gigには2つの事業本部があります。 私は、O:der事業本部に所属しており、O:derのプロダクト開発に携わっています。

O:derとは、BtoBtoCのSaaSモデルのプロダクトであり、オンラインとオフラインを融合したサービスを提供しています。 SaaSのバリューチェインについては諸説ありますが、O:derでは マーケティング -> セールス -> オンボーディング -> CS へとチェインが続きます。

BtoBtoC SaaS のバリューチェイン

O:der事業を行う組織は、O:derのバリューチェインそのものになります。 プロダクト開発は、バリューチェインにおける支援活動になるでしょう。

私たちは、これらを1つの事業部として編成することで、事業部戦略を実現しています。

プロダクトをつくる組織

Showcase Gigのプロダクト組織には、PM/エンジニア/サポートなど、さまざまなロールがあります。 それらを、次の2つのチームタイプと織り交ぜて、組織を構成しています。

  • フィーチャーチーム ー 顧客のフィーチャーを1つずつ完成させる長寿命のチーム

  • コンポーネントチーム ー 特定の専門領域での役割を果たすことを目的としたチーム

アジャイルの時流では、組織の既存の枠や特定のコンポーネントにとらわれないフィーチャーチームが重宝されますが、コンポーネントチームも組織には必要です。 コンポーネントチームは、組織に対して特定の専門性で、横串を通すことができます。 よって、組織として専門性を高めたい、ないしはコンポーネントの目的を達成するためには最適なチームとなります。

フィーチャーチームかコンポーネントチームか

これは、どちらが優れているという話ではなく、トレードオフがあることを理解して、組織に合わせてバランスを取りながら、組織デザインをしなければなりません。

しかし、この判断は意外に難しいものです。 たとえば、スマートフォンアプリケーションエンジニアが1つのチームに集まった方がよい時もあれば、フィーチャーチームにいた方がよい時など、今までも幾度となく悩んできました。

あるいは、マトリックス組織のように、フィーチャーとコンポーネントをクロスさせることもできますが、組織の複雑さが増してしまいます。 行と列でそれぞれの指揮系統を持つことで、意思決定者が複数人になり混乱が起きやすく、「命令の一元性」や「指揮の一元性」という経営管理の原則にも反する可能性もあります。何にしてもシンプルではありません。

これに対してどうするべきでしょうか。 それには、前提にある「プロダクトのマーケット」と「組織の職能」の関係を理解する必要があります。

マーケットと職能と組織の関係

組織デザインは、職能とマーケットへの適応度を選択するということにもなります。 コンポーネントチームほど職能(あるいは、システム)の適応度が高くなり、フィーチャーチームほどマーケットへの適応度が高くなります。 職能への適応度を取るのか、マーケットへの適応度を取るのか。それとも、マトリックスチームでバランスを取るのかを、総合的に判断しなければなりません。

プロダクト開発チームの役割分担

O:derというプロダクトは、次のようなプロダクトによって構成されています。 このプロダクトを、フィーチャーチームとコンポーネントチームが協力して運用開発をしています。

フィーチャーチームは、それぞれ担当のプロダクトに対して責任を持ち、PMとともにプロダクトをつくります。 コンポーネントチームは、すべてのプロダクトに対する活動を支援します。 先の説明の通り、今のQAとSREは職能の適応度を優先しています。

フィーチャーチームとコンポーネントチームが連携することで、プロダクトを高速にデリバリしながら、プロダクト価値を最大化しています。

Showcase Gigのシステムについては、きくちの書いたエントリを参照ください。

チームは事業と共にある

プロダクト組織のチームは事業と共にあります。 チームは事業の成功のためにあり、チームは任せられた役割において、成果を最大化できるように努めています。

そして、最終的には「自律的に目標を達成する組織」になることを目指しています。 そのために、次のような取り組みを行っています。

  • チームのミッション ー チームはミッションを持ち、その使命を理解している。

  • チームのOKR ー チームが目標を持ち、チームメンバーが一丸となって目標達成を目指す。

  • チームリーダーの責務 ー O:der事業全体とプロダクトをチームの中で一番理解していなければならない。経営戦略を、自らの言葉でチームに説明して一人一人の理解を促す。

チームとは、時間をかけて成長するものです。 成長したチームは、組成時に比べて何倍もの成果をあげることができます。 そのため、長期的にチーム作りに取り組めるように、組織としてもサポートをしています。

たとえば、チーム自身でチーム名を命名するという文化があるのですが、しっかりと組織図に反映させて、オフィシャルなチーム名として扱っています。 チーム名は、調理器具や料理に関する名前が付けられており、楽しみながらチームビルディングをしています。

いつか成長したチームが、自律的に目標を達成できるようになれば、とても強い組織になるはずです。

これからの組織

ここまで、プロダクトをつくる組織について書いてきましたが、これから先も組織の形は変わっていくはずです。

それは、O:derのプラットフォーム戦略が具体的に進むことで、プラットフォームの「提供」と「利用」が始まるためです。 これにより、多様な「利用者」が登場し、エコシステムが形成され、コミュニティが生まれてくるでしょう。

たとえば、社内の別事業部からもプラットフォームが利用され始めました。

このコミュニティが社内外に増える時、新たな組織へとアップデートが必要になります。 その時は、新しいエントリにてまとめていきます。

それでは、本日はここまでにして、みなさま Happy Holidays!
明日は、CTOによるエントリになります。お楽しみに!

この記事が気に入ったらサポートをしてみませんか?