ユニコーン企業のひみつ|Spotifyで学んだソフトウェアづくりと働き方

1章|スタートアップはどこが違うのか

この章では、スタートアップにはどんな違いがあるのか、プロダクトでスタートアップと競いたければ、従来型企業は何を再発見する必要があるのか、なぜ両者でソフトウェアの目的の捉え方が大きく違っているのかを見ていく。

そこから新規プロダクト開発に取り組むためのプラクティスを学べるのはもちろんだが、この章の内容はそこに留まらず、スタートアップみたいな働き方をするのに欠かせない、文化や姿勢を変えていく足がかりにもなるはずだ。

1.1|スタートアップは「火星」から来た

スタートアップのソフトウェア開発では、スケジュールや納期、予算は関心事の中心ではない、彼らが重視するのは、顧客、インパクト、学習だ。


スタートアップはプロダクトがすべてだ。デモで見せるのはプロダクトだ。新しい顧客をひきつけるのもプロダクトだ。資金調達するのもプロダクトだし、学習するのもプロダクトを通じてだ。

だから、スタートアップはプロダクトがすべてだ。スタートアップは実験とイテレーションを繰り返し、学習を続けていくことでプロダクトマーケットフィット(Product/Market Fit、PMF)の達成を目指す。

1.2|「学習する機械」

スタートアップのプロダクト開発ではひたすらイテレーションを重ねる。プロダクトを一度だけ構築して勝利を宣言するのではなく、計測、分析、テストの結果から得られた知見をプロダクトに何度も何度もフィードバックする。(〜中略〜)そして度重なる調整の果てに、顧客が本当に求めているところに近づいていく。

  • スタートアップにとっての、ソフトウェアデリバリーの目的:
    • 実験して学ぶ
    • プロダクトマーケットフィットに向けて調整する
    • 投資家に価値を示す
    • 自分たちが変な方向に進んでいないことを自分たちで確かめる

1.3|エンタープライズ企業は「金星」から来た

1.4|「期待に応じる機械」

  • エンタープライズ企業では「計画通り」であることこそが成功
  • スタートアップとエンタープライズ企業との間でのソフトウェアデリバリーに取り組む姿勢の違い:
    • エンタープライズ:内向き、計画に従う、既存業務の自動化、未知が少ない、プロジェクト駆動、一回限り、納期と予算、トップダウン、計画に忠実
    • スタートアップ:外向き、学習する、新規プロダクト開発、未知が多い、プロダクト駆動、リリースを重ねていく、顧客とインパクト、ボトムアップ、計画を生み出す

ここがエンタープライズ企業の苦戦しているところだ。身軽になって競争力を高めようにもうまくいかない。エンタープライズ企業はソフトウェアデリバリーを単なる社内業務の自動化と捉えるのをやめなきゃだめだ。

1.5|つまり、こういうことだ

成功とはもはや計画に従うことじゃない。プロダクト開発における成功とは「発見と学習」だ。最初のプロダクトをとにかく早く世に出すのもそのためだ。そしてこれを素早く、何度も何度も繰り返す。失策をおかすこともあるだろう。だが、リリースを重ねるごとにプロダクトは良くなっていく。なぜ良くなっているのかがわかるのかというと、あらゆる段階でトラクションを追い求めており、それぞれの過程でインパクトと価値を計測しているからだ。

プロダクト開発では失敗はゲームの一部だ。失敗したら「罰を与える」ような会社では、本当に必要な人材の採用に苦労することになるろう。だから、失敗してはいけないという思い込みを払拭すること。チームにも会社にも、物事がまともに進むようになるまでには幾度もの失敗が予想されることを理解してもらおう。プロダクト開発は一発勝負じゃない。初回のリリースは始まりに過ぎない。

陳腐な言い回しにはなるが、大抵の企業は従業員をまったく信頼していない(少なくともテック企業のようには信頼していない)。すごいプロダクトを作るのは、強い権限が与えられている、信頼されたチームだ。

状況は良い方向に変わりつつある。従来型企業も度重なる挑戦を受け、ディスラプトを経験した結果、これはいよいよ選択肢が無くなりつつあると気づきはじめた。生き残るには、もっと新規プロダクト開発を上手くならないと。


2章|ミッションで目的を与える

この章を読むことで主に次の3つを理解できる。ミッションとは何か。なぜプロダクト開発にはミッションの方が適切なのか。ミッションのどんな仕組みがテック企業を迅速に動けるようにしているのか。

2.1|プロジェクトの問題点

プロジェクトでは、チームは直感に従うこともできないし、納期や予算のせいで学んだことを取り入れることもできない。これはチームに考えることも、気にかけることもやめさせてしまう。こんな状況はプロダクト開発で求められているものとはまったく逆だ。

2.2|これが「ミッション」だ

ミッションとは、チームに与えられる、抽象度が高めの目標だ。ミッションの役割は、チームの仕事を企業レベルの大きな目的の達成に向けて方向づけることにある。

2.4|ミッションは目的を意識させる

目的はものすごく大事だ。今日出社してこなす仕事が誰かの暮らしを楽にすると思えるなら、それはあなたの「帆」に吹く風となるだろう。仕事を有意義に感じられる。関わりたくなる。全力を尽くす。一日が終わる。また仕事のできる明日が待ち遠しくなる。次の日も。その次の日も。

2.5|ミッションは仕事そのものにフォーカスさせる

  • プロジェクトとミッションの違い:
    • プロジェクト:予算がある、終りがある、短期間、プロジェクトマネージャーがいる、開発だけして引き継ぐ、完成したら解散する、計画にフォーカス、期待に応じることが価値、トップダウン
    • ミッション:チームの人数が予算、期間に定めがない、長期間、プロジェクトマネージャーがいない、開発もメンテナンスする、チームは一緒のまま、顧客にフォーカス、インパクトが価値、ボトムアップ


3章|スクワッドに権限を与える

この章では、テック企業でプロダクトを開発するエンジンとなる存在である、少人数の、自律した、必要な権限を持ったチームを扱う。Spotifyではそういうチームをスクワッド(Squad)と呼んでいる。

テック企業ではチーム編成が成功を左右する。エンタープライズ企業によくあるアジャイルチームとスクワッドとを比較することで、「権限付与と信頼」という考え方がどれだけ有効なのかを理解してもらえると思う。

3.1|スクワッドとは?

スクワッドとは、少人数で、職能横断の、自己組織化されたチームだ(多くの場合、8名以下で編成される)。スクワッドは同じオフィスに席を並べて、自分たちが作ったプロダクトの隅々まですべてに責任を持つ。


権限を持った小さな職能横断チームこそが、高速なプロダクト開発とイノベーションの基盤である

3.2|スクワッドはどこが違うのか?

エンタープライズ企業のアジャイルチームが仕事をプロジェクトという形で渡されるのとは異なり、スクワッドは顧客の問題に対する解決策を自分たちで考えて、自分たちで仕事を生み出す。到達すべきミッションがあり、仕事をやり遂げるのに必要な人員も配置されている。何をどう開発するかはスクワッドが決める。スクワッドはミッションを果たすために自分たちに必要だと思う仕事を自分たちで生み出す。

これは責任のありかが根本的に異なる。事前に仕事は用意されていて、解決策があることを前提とする(プロジェクト方式のアプローチがこれだ)のとは異なり、テック企業ではスクワッドにミッションを与えて、自分たちで解決することを促す。社内業務システムのデリバリーではこんなやり方はしない。だが、プロダクト開発をうまくやりたいのなら、責任というものへの態度と考え方を実際に変えなきゃだめだ。


テック企業が何よりも大切にしているのはインパクトだ。インパクトとは、仕事の結果が何らかの形で顧客の役に立ったという具体的な証拠のことだ。

インパクトはさまざまな方法で計測できるが、大抵はビジネスの成功と結びつくような指標にする。鍵となる指標にフォーカスすることで、余計な心配事を減らす。見積り通りか。予算通りか。計画通りか。典型的なプロジェクトでありがちな揉め事をテック企業は取り除く。みんなの労力と集中力をできる限り仕事そのものや顧客へと向けられるようにする。


今後あなたが職場でスクワッドを編成することになった場合に備えて、肝に銘じておいてほしいことがある。それは、スクワッドは「無慈悲で苛烈なデリバリー精鋭部隊」だということだ。スクワッドのメンバーは実際に手を動かす人たちにしよう。デリバリーに直接貢献するメンバーだけで編成して、そうじゃない人たちは外すんだ。

一方、ここまでとは逆の話もある。ユニコーン企業ではとても頼りにされているのに、エンタープライズ企業ではそうでもない役割が2つある。それは、プロダクトマネージャーとデータサイエンティストだ。

3.3|プロダクトマネージャー

プロダクトマネージャー(「プロジェクト」マネージャーと混同しないこと)は、スクワッドが「何をするのか」を導くことに責任を持つ。スクラムのプロダクトオーナーと同様に、プロダクトマネージャーはスクワッドの進む方向を決める。その方向はプロダクト全体や会社の戦略と結びついている。プロダクトマネージャーは極めて重要な役割なので、テック企業ではとても大切にされている。プロダクトマネージャーは新規プロダクトや新規サービスを世に出すにあたって、鍵となる役割を果たす。

3.4|データサイエンティスト

データサイエンティストは数学者でありエンジニアだ。チームがデータを使ってプロダクトの意思決定を下せるように支援する。企業は膨大な量のデータを収集しているが、意思決定に活用するには、収集したデータの処理、クリーンアップ、フィルタリングが必要だ。

3.5|分離されたアーキテクチャ

巨大で複雑なプロダクトを、小さく独立した要素へと分解していく。こうすれば各チーム同士がお互いの邪魔になるような事態を防げる。複数チームが並行して同じプロダクトに取り組めるようになるのだ。


スクワッドに独立して動いてもらいたければ、他チームへの依存を最小限に抑える方法を見つけ出す必要がある。複数チームで同じプロダクトに取り組む場合、お互いが邪魔にならずに済む確実な方法は、アーキテクチャを分離することだ。

3.6|自律、権限、信頼

だが私から言えるのは、これがテック企業のやり方だということだけだ。こうやってテック企業はスケールさせている。だから、部下に権限を与えて信頼してみよう。そうした場合の彼らの働きぶりに、良い意味でびっくりさせられるかもしれない。

何を根拠に言っているのかって?すごいテック企業ですごいプロダクトを作っている従業員の多くは、従来型企業の出身者だ。つまり、みんなかつてはあなたのような上司の下で働いていた人たちじゃないか!

いまはテック企業で働いているとはいえ、彼らもかつては従来型の大企業で働いていたエンジニアやプロダクトマネージャー、テスターやデザイナーだったわけで、勤め人という意味では変わらない。違う働き方に惹かれて転職したに過ぎない。テック企業で彼らが良い働きをみせているのは、権限付与と信頼の度合いが違うからだ。

テック企業は単に優秀な人材を雇っているんじゃない。優秀な人材を作っているんだ。手ごわくてやりがいのある仕事を与えて、それを遂行できるだけの権限を与える。失敗したらサポートする。そうやって人を育てている。

テック企業の人たちがすぐれた仕事をしているのは、無料のラテやテーブルサッカー台のおかげなんかじゃない。権限が与えられ、信頼されているからこそ素晴らしい仕事をしているんだ。

3.7|経営リーダーのためのヒント

ミスにつまずいてしまったチームを地面から立ち上がらせよう。埃を払って、再び挑戦するように伝えよう。

これには2つの効果がある。1つ目。「間違えたって大丈夫」というメッセージになる。間違えることはゲームの一部なんだ。2つ目。「チームを信頼してますよ」というメッセージになる。あなたがチームへの信頼を示せば、チームもあなたを信頼してくれるようになる。

こうすれば、今後チームが間違いをしでかしたとしても、チームはあなたのことをチームを支えるための存在だと理解しているので、あなたのアドバイスに対して心を開いてくれるはずだ。

3.9|権限を与える

ミッション(何をするか)を定めるのは経営リーダーの仕事で、解決策(どうやるか)を編み出すのはスクワッドの仕事だ。


4章|トライブでスケールさせる

自律した小さなチームは素晴らしい。けれど、彼らにもできないことがひとつある。それは、スケールすることだ。小さなチームでうまくいっていることをどうやって全社レベルにスケールさせるのか?それがこの章のテーマだ。

4.1|スケーリングの課題