『ユニコーン企業のひみつ ―Spotify で学んだソフトウェアづくりと働き方』を読んだ。
いつも読んだら読みっぱなしで本の内容を忘れてしまうのでブログで学んだことをアウトプットしていこうと思う。
この記事はその第一弾ということで。
「ユニコーン企業の秘密」はどんな本か
まずはこの本のテーマとどんな人におすすめかについて。
この本のテーマ
ユニコーン企業とはなんなのかというと、「創業から10年以内で、企業の評価額が10億ドル以上の未上場ベンチャー」のことを指す。
10年という短い期間で10億ドルという評価額がつく企業はとても珍しい。
こういう理由から、ユニコーン企業と呼ばれるようになったらしい。
この本はそんなユニコーン企業がどのようにプロダクトを開発しているかについて書かれた本だ。
著者は世界最大手の音楽ストリーミングサービスのSpotifyで働いていた（今も働いているのかな？）Jonathan Rasumussonさん。
彼のSpotifyでの経験が簡潔にまとめられている。
ページ数も200ページくらいで読みやすかった。
どんな人におすすめか
- プロダクト開発にゴリゴリ関わっている人
- これからのスタートアップに転職する人
にぴったりな本だと思う。
「ユニコーン企業の秘密」から学んだこと
ここからは仕事に活かしたいなと思ったことを書き連ねていく。
とにかく早くプロダクトを世に出そう
スタートアップのプロダクト開発は1度作って終わりではない。
データを計測・分析して、その結果から得られた知見をプロダクトに繰り返しフィードバックしてプロダクトを洗練させていく。
この繰り返しが、ユーザーの求めているサービスに近づいていくことにつながる。
新規事業の場合「とにかく早くプロダクトを世に出せ」と言われるけど、改めてこれの大切さを痛感した。
「ぼくのかんがえたさいきょうのプロダクト」は、ほとんどの場合ぜんぜん最強でもなんでもない。
「ユーザーからのフィードバック⇨改善」のサイクルを何度も何度も繰り返し、プロダクトを改善していくことが最強のプロダクトにつながるのである。
だからこそ、プロダクトは早く世に出さなければならない。
僕は「この機能も大事だし、あの機能も大事だな」と付け加えがちなので、「これってユーザーに価値提供する上で本当に必要なんだっけ？」というのは何度も自分に問いかけねばと改めて思った。
失敗してはいけないという思い込みを捨てる
「プロダクト開発では失敗もゲームの一部」と書かれてあって、「ホントそれな」と思うのと同時にチームメンバーにも理解してもらいたいなと思った。
先ほども書いた通り、プロダクト開発は一発勝負ではない。
何度も何度も改善を繰り返す。
この過程では、どこかで何かしらの失敗を経験するはずだ。
自分はいま新規事業のPdMをやっているので、「失敗したらダメ」みたいな文化は作らないようにしたいなと思った。
ただ失敗を許容する文化を醸成するのは、口で言うのは簡単だけどけっこう難しい気がしている。
例えば「失敗を許容する文化」=「失敗前提でのリリースOK」と勘違いされてしまったりとかはありそう。
個人的には失敗を許容する文化と失敗前提のリリースOKは全く違うものだと考えていて、どのリリースも「成功するんだ」という意気込みでやらないといつまでも良いプロダクトにならないと思っている。
「これなら上手くいくはず」というリリースをして、それに対するフィードバックをもらう。
このサイクルを繰り返すことには意味があるだろう。
しかし、失敗前提のゴミプロダクトを早く世に出したところで意味がない。
ゴミクズプロダクトはどこまでいってもゴミクズなのである。
ヒットを打つという意気込みで打席に立って失敗するなら仕方ないけど、最初から失敗するつもりで打席に立ってもまるで意味がないと僕は思う。
こういった最初から失敗前提のマインドにはならないように気をつけたい。
チームが早く進めるならお金を使おう
「チームに夕食が必要なら手配すればいい。それで 実際、チームが速く進むなら、お金を使うんだ!」とこの本に書かれていて、確かにスピード命のスタートアップ企業には重要な考え方だなと思った。
最近、僕が責任者をやっているプロジェクトでまさにこういう場面があって、ちょっと割高のサービスだけどこのサービスを使うことによって仮説検証を早くできるようになるので、このサービスに対してお金を使うという意思決定をした。
この意思決定によって少なくとも1ヶ月以上は検証の開始を巻けたと思う。
絶対に必要なものではなかったとしても、「それがスピードにつながるならお金を使う」という視点は忘れないようにしたい。
ちなみに、お金によるショートカットは仕事だけではなく、個人についても言えると思う。
自分が成長すればするほど、自分が出せるスピードも速くなっていくので、同じ時間でもどこまで遠くに行けるかが変わってくる。
「お金を使うことによって、短期間でより遠くへ行ける」と判断したのなら、どんどんお金を使った方が良い。
もちろんお金は有限なので、「これにお金を使うことによってどれくらいスピードが変わるんだろう？」というのは考えないといけないけど。
ハックウィークが楽しそう
Spotifyでは通常業務を脇に置いて、自分の好きなことをなんでもやれるハックウィークというのがあるらしい。
このイベントは新しいプロダクトのアイディアや機能が生まれることを目的としていて、Spotifyでは年2回開催しているそうだ。
こういったイベントを通してSpotifyでは
- 共有プレイリスト
- 不安定なテストを把握するためのダッシュボード
- 会議室の地図(Spotify には所在がわかりづらい会議室がある)
- ものすごく大規模なプロジェクトのコンパイル時間の短縮
なのが作られたとのこと。
部門間でチーム編成して、新しい機能を作るのは楽しそうだなと思った。
会社が大きくなってくると他部門の人の顔も見えづらくなるし、こういう機会があると部門関連系が円滑になったりしないだろうか。
信頼して権限を与えよう
ユニコーン企業の秘密を読んでいると、信頼して権限を与えようという話が何度も出てくる。
この本を通して筆者が伝えたいことは、これに尽きるのだろう。
Spotifyではスクワッドと呼ばれる、少人数で職能横断(Cross-Function)の自己組織化されたチームでプロダクト開発をしているそうだ。（最大でも8人くらい）
このスクワッドがプロダクトの隅々まで責任を持つことになる。
スクワッドが自分で仕事を生み出し、自分たちで作ったものをメンテナンスし、自分たちでやるべきことの優先順位をつける。
このようにスクワッドという少数のチームに権限どかっと渡されているので、プロダクト開発にスピードが出るというわけだ。
で、このスクワッドを機能させるのに必要なのが、「信頼すること」と「権限委譲」である。
信頼して権限委譲をすることはチームに対してだけではなく、メンバーに対しても重要だと思う。
信頼して権限委譲することによってスクワッドが自律的に機能するのと同様に、メンバーも信頼されているという実感があって権限委譲されていることによって、自律的に動けるようになると思うからだ。
信頼されていないと感じていて権限もなければ、ただ指示を待つだけになってしまうだろう。
僕は人に何かを任せるのが苦手なのだけど（自分でやろうと思ってしまう節がある）、自律的なチームを作るには自律的に動けるメンバーが大事だと思うので、みんなのことを信頼しているしあなたにはこういうことを期待しているというのはどんどん発信していきたいなと思った。
まとめ
PdMをやっている自分にはタイムリーな内容だったのでとても参考になった。
また時間を空けて読み返したいと思う。
