ユニコーン企業のひみつ
https://gyazo.com/92c0bbd818e4ce3b95f505234178fde7
読書メモ
本書への推薦の言葉
日本の読者の皆さんへ
誰もアジャイルを倒せませんでした。誰もがアジャイルでやってます。
彼らはプロジェクトをやっていません。
彼らは従来型の予算編成をやっていません。
彼らは従業員に何をすべきかを指示しません。代わりに、みんなを導き、信頼し、権限を与えます。
お目にかかれて光栄です
本書においてスタートアップとは、50 名未満の小さな企業を想定している。
本書で「ユニコーン企業」と言うとき、それは評価額が 10 億ドル規模の企業でありながら、スタートアップみたいに運営されている企業のことだと思ってほしい。
1章 スタートアップはどこが違うのか
1.1 スタートアップは「火星」から来た
スタートアップのソフトウェア開発では、スケジュールや納期、予算は関心事の中心ではない。彼らが重視するのは、顧客、インパクト、学習だ。
なぜなら、スタートアップの本質とは「学習する機械」であることだからだ。
1.2 「学習する機械」
1.3 エンタープライズ企業は「金星」から来た
1.4 「期待に応じる機械」
1.5 つまり、こういうことだ
成功とはもはや計画に従うことじゃない。プロダクト開発における成功とは「発見と学習」だ。
1.6 "Think Different"
このやり方でプロダクトを開発するには、未知の世界で働くことに慣れていくことが求められる。成功の定義も見直す必要がある。新規プロダクト開発では、失敗が悪いことだという思い込みを払拭しなければならない。
2章 ミッションで目的を与える
テック企業はプロジェクトで仕事を進めない。ミッションで進める。この章ではその理由を学ぶ。
2.1 プロジェクトの問題点
2.2 これが「ミッション」だ
2.3 ミッションはチームの自発性を高める
2.4 ミッションは目的を意識させる
2.5 ミッションは仕事そのものにフォーカスさせる
https://gyazo.com/651f3deef1dc1dee7d35fc05ed16dec6
ミッションは OKR の Objective に似た説明をされているな。 2.6 ミッションの例
2.7 目的を与えよう
3章 スクワッドに権限を与える
この章では、テック企業でプロダクトを開発するエンジンとなる存在である、少人数の、自律した、必要な権限を持ったチームを扱う。Spotify ではそういうチームをスクワッド(Squad)と呼んでいる。
テック企業ではチーム編成が成功を左右する。エンタープライズ企業によくあるアジャイルチームとスクワッドとを比較することで、「権限付与と信頼」という考え方がどれだけ有効なのかを理解してもらえると思う。
3.1 スクワッドとは?
スクワッドとは、少人数で、職能横断(Cross-Function)の、自己組織化されたチームだ(多くの場合、8 名以下で編成される)。スクワッドは同じオフィスに席を並べて、自分たちが作ったプロダクトの隅々まですべてに責任を持つ。
3.2 スクワッドはどこが違うのか?
自律せよ。だが局所最適に陥るな
ってのはメルカリさんの組織構造のお話の中で見かけたことのあるフレーズだ。
デザインの際の原則としてはSpotifyのSquadモデルを参考にし「自律的に動けるようにするが部分最適は避ける (be autonomous but don’t suboptimize)」を意識しました.
3.3 プロダクトマネージャー
3.4 データサイエンティスト
3.5 分離されたアーキテクチャ
3.6 自律、権限、信頼
テック企業勤務の人たちがすぐれた仕事をしているのは、無料のラテやテーブルサッカー台のおかげなんかじゃない。権限が与えられ、信頼されているからこそ素晴らしい仕事をしているんだ。
3.7 経営リーダーのためのヒント
3.8 Q&A
3.9 権限を与える
4章 トライブでスケールさせる
4.1 スケーリングの課題
4.2 スケーリングの原則
過去の実績からわかったのは、トライブの理想的な人数は、下限を 40 人、上限を 150 人程度(ダンバー数† 2)とした区間のどこかにあるということだ。
トライブは、ぼくの知っている「部署」みたいなものなのかな〜。
4.3 トライブ、チャプター、ギルド
4.4 トライブ
トライブとは、担当するミッションが類似、関連しているスクワッドがまとまったものだ。
4.5 チャプター
チャプターとは、同じ専門性を持つメンバーで構成される、トライブ内のグループだ。たとえば、トライブ内のテスター全員で品質保証チャプターを形成したり、Web エンジニア全員でまた別のチャプターを形成したり、といった具合だ。
トライブ内の同じ専門性を持つメンバーのマネージャーが「チャプターリード」だ。チャプターリードの仕事には、現場を支援することに加えて、採用、給与、キャリア開発など、一般的なマネージャー業務のすべてが含まれる。
チャプターの利点はさまざまだが、チャプターが組織にもたらす一番の利点はコミュニティだ。特定の専門性のグループがあることで、コミュニティの状況やニュースを共有する場を持てるし、定期的に顔を合わせて新しい技術やすぐれたプラクティスについて話し合うこともできる。
4.6 ギルド
ギルドは、同じ専門分野に興味のあるメンバーからなるグループで、組織を横断して形成される。
ギルドは有志の活動でもあるので、ギルドのミーティングに毎回参加する義務はない。とはいえ、ギルドはいつでもあなたが顔を見せてくれることを心待ちにしている。
ギルドでは独自に「アンカンファレンス」が開催される。
4.7 どこで働きたい?
この一連の流れが特筆に値すると思ったのは、テック企業の本気を目のあたりにしたからだ。テック企業は意思決定を現場に任せて、メンバーの自己組織化を促すためなら、どこまでも突き進む。従業員に所属するチームを選ばせて、仕事を引き受けさせている従来型企業の事例を、私は寡聞にして知らない。
4.8 Q&A
4.9 スケールは大きく、チームは小さく
5章 ベットで方向を揃える
この章では、テック企業がカンパニーベット(Company Bet)を活用して、全社を横断するコラボレーションを可能にしている様子を見ていく。本当に必要な仕事から着実に完成させていきながらも、日々の業務でチームに与えられている裁量や自律性はそこなわれない。
5.1 しおれた百の花
5.2 カンパニーベットとは
カンパニーベットは、会社が取り組みたい重要事項を、終わらせたい順に並べたリストのことだ。
会社の Objective みたいなものかねぇ。
5.3 カンパニーベットの仕組み
DIBBとは、データ(Data)、インサイト(Insight)、確信(Belief)、ベット(Bet)それぞれの頭文字だ。SpotifyではDIBBを活用して、音楽業界での成功に向けてどのように投資すべきかを議論し、意思決定していた。DIBBの本質は意思決定フレームワークだ。DIBBを使うことで、なぜそのベットが必要なのかを系統立てて説明したり、議論できるようになる。
5.4 この働き方の見事なところ
5.5 やり抜くためのコツ
カンパニーベットは勝手に進んでいくようなものではない。動かしていくには手間暇がかかる。そのためのスキルも必要だ。カンパニーベットの担当者は「ロードマネージャー(Road Manager)」と呼ばれ、ベットをやり遂げることに責任を持つ。ロードマネージャーがベットを動かす。
拠点の異なる複数チームが協働する場合、組織全体をつなぐ、明快でオープンなコミュニケーションチャネルが必要になる。仕事の中心となる拠点に着任していない人たちは、どうしても自分たちは排除されているとか、「二級市民」扱いされていると感じてしまいがちだ。
この視点と具体的な取り組みに感心してしまった
Spotify が苦労の末に学んだのは「大きなベットを 2 つ同時進行させると高くつく」ということだ。
シンプルに大事なことを言っていて、しっかりやっていこう…という気持ちにさせられる
5.6 ベットに賭けろ
6章 テック企業で働くということ
6.1 フラット化する世界
この運命の朝、後に「8 人の反逆者」として知られるようになったはみ出し者のグループはShockley Semiconductorを去り、自分たちで会社を立ち上げた。これがシリコンバレー初のスタートアップの誕生だった。
へぇ、このお話は知らなかった
Fairchild Semiconductorは、新しい働き方のお手本になった企業だ。たとえばFairchildはオプションや株式といった形で、従業員に直接的な企業の所有権を渡すことを始めた企業の 1 つだ。8 人の創業者のうちのひとりであるRobert Noyceは、立派なコーナーオフィスは使わずに、他の社員と同じように普通のキュービクルで働いていたことでも知られている。
6.2 「何をすべきかを指示するつもりはないよ」
テック企業、少なくとも Spotify は従業員が自分で決めることを好む。従業員に何をすべきかを直接指示することは好まない。これは私のような北米大陸出身の者、コマンド&コントロール型の社会構造の影響下にある者からすると、最初はすごく奇妙に思える。意思決定者はひとりにしたほうが話も単純だし速くなる。みんなに何をすべきかをただ伝えればいい!
6.3 お金の使い方が違う
6.4 「信頼してないの?」
6.5 すべての情報は基本的にオープン
あらゆるデータにアクセスできるとき、人はすぐれた意思決定を下せる
6.6 「手伝おうか?」
6.7 テック企業流の人の動かし方
7章 生産性向上に投資する
テック企業がとても得意なことの一つが「速く進めるようにすること」、つまり生産性向上への投資だ。エンタープライズ企業だったら馬鹿馬鹿しくなるほど苦労すること(生産性向上や開発基盤への投資)が、テック企業ではやすやすと実現されている。
7.1 プロダクティビティスクワッドを編成する
7.2 セルフサービスモデルを採用する
7.3 ハックウィークを開催する
そのまま製品化されるようなハックはごくわずかだったが、ハックウィークで達成されたことにはもっと大きな成果があった。
大きな成果が「ものすごく楽しかった」で締められているのが最高
7.4 技術に明るいプロダクトオーナーを活用する
7.5 品質に高い期待を持つ
7.6 社内オープンソースを活用する
テック企業のソフトウェア開発におけるもう一つの重要なプラクティスは、社内オープンソースモデルの採用だ。社内オープンソースでは、社内の誰でもいつでも他のメンバーのコードをチェックアウトできる。
7.7 あらゆるレベルでの継続的な改善
他社はともかく「継続的に改善すること」というマントラは間違いなく Spotify の DNA に焼きつけられており、組織の中心部にまで深く浸透していた。
7.8 フィーチャーフラグを活用する
7.9 リリーストレインでリリースする
7.10 技術を「一級市民」として扱う
テック企業は技術に手を抜かない
それゆえに「テック企業」ということなのだろう
8章 データから学ぶ
8.1 どこにでもデータがある
8.2 プロダクトを計測する
8.3 A/Bテストで実験する
8.4 そこでデータサイエンティストですよ
8.5 データを活用する
9章 文化によって強くなる
テック企業において文化とは勝手に育つものとされていたが、そんな時代は終わった。文化は放任しておくにはあまりにも重要な役割を担っている。だからこそ、多くのテック企業では文化に直接投資している。文化によって望ましいことを推し進めつつ、望ましくないことを止めさせる。
9.1 会社が違えば文化も違う
9.2 Spotifyの文化
9.3 良い文化ってどんな感じ?
9.4 核となる信念
テック企業のやることはすべて、スピードと学習にかかっている。テック企業が従来型企業よりも特別にすぐれた人材を採用しているわけではない。単にテック企業の方が、チームに与えている権限と寄せている信頼が強いだけだ。それに、テック 企業がそうしている理由も、彼らの方が「根が良い人たち」だからではない。信頼して権限を与えたほうが良い結果を生むからそうしているまでだ。テック企業は可能な限り速く動こうとしており、その過程でなるべくたくさん学ぼうと努めている。
こういう話がとても好き
「優秀な人間」とか「いい人」って話ではなく「うまくいくやり方」にフォーカスしている
9.5 行動は言葉に勝る
このやりとりが私のスウェーデン文化との初遭遇の瞬間だった(Spotify はスウェーデンに本拠地を置く会社だ)。トップダウンの意思決定者を特別視する北米とは異なり、スウェーデンはボトムアップの合意形成による意思決定をもっと大切にしている。私のようなマネジメントスタイルはこの地では通用しなかった。
これを「スウェーデン文化」と評しているのがおもしろいな、と思った
9.6 スウェーデンっぽさ
チームを基礎とした合意で仕事や問題解決を進めていくのはスウェーデン人好みの働き方だ。アジャイルなソフトウェアデリバリーをスウェーデン人が自然に受け入れているのもそのためだ。もともとスウェーデン人はそうやって仕事をしていたんだ。
へぇ〜
スウェーデン人は職場でみんなが仲良くすることをとても大切にしている。スウェーデン語にはその様子を表す「bra stämning」という言葉もあるぐらいだ。スウェーデンの人たちが職場での交流を深めるのに活用している習慣は「フィーカ(Fika)」と呼ばれており、スウェーデン名物になっている。
フィーカには誰もが参加する(参加しないのは文化的には非礼にあたる)。参加者は好きな話題を自由に話してかまわないが、政治のことや、クロスカントリーでノルウェーの優位が続いていることのようなセンシティブな話題は、普段は避けられる。
ぼくはけっこう北米文化の影響を強く受けているように感じていて、こうしたスウェーデン文化のお話はおもしろいなあ
日本人的には「こっちの方が共感できる」ってポイントもあるかもしれないね
スウェーデン人には自分たちの生活様式を表す言葉がある。それを「ラーゴム(Lagom)」という。ラーゴムとは「多すぎず、少なすぎず。ちょうどいい」という意味だ。
9.7 文化が重要
10章 レベルを上げる:ゆきてかえりし物語
10.1 目的で動機づける
10.2 思考は戦略的に、行動は局所的に
10.3 プロジェクトではなくチームに投資する
10.4 技術を「一級市民」として扱う
10.5 もっとスタートアップみたいに振る舞う
10.6 自律した小さなチームとともに
10.7 コンテキストもあわせて取り入れる
10.8 率先垂範のリーダーシップ
10.9 権限を与え、信頼する
10.10 「言い訳」を取り除く
10.11 最後に
訳者あとがき