[読書録]ユニコーン企業のひみつ

スタートアップにとってのソフトウェアデリバリーの目的

1. 実験して学ぶ
2. PMF(プロダクトマーケットフィット)に向けて調整する
3. 投資家に価値を示す
4. 自分たちが変な方向に進んでないことを自分たちで確かめる

スタートアップとエンタープライズ企業との間でのソフトウェアデリバリーに取り組む姿勢の違い

ユニコーン企業は、エンタープライズ企業での仕事の進め方の筆頭ともいえるプロジェクト方式を採用しない。代わりに彼らは、チームに権限と自律性を与える「なにか」を使う。その「なにか」は「ミッション」と呼ばれている。

本章での気づき

スタートアップ企業の進め方においては、権限と信頼がチームに与えられているということが重要な要素になっていると感じた。
予定を立てるプロジェクト型の進め方と異なり、未知に対する対応を柔軟に行っていくのがスタートアップ企業の進め方という理解をした。

この章を最後まで読むことで主に次の3つを理解できる。

1. ミッションとは何か
2. なぜプロダクト開発にはミッションの方が適切なのか
3. ミッションのどんな仕組みがテック企業を迅速に動けるようにしているのか

プロジェクトの問題点

1. 期間があまりにも短い
2. フィードバックの機会がない
3. プロジェクトはあまりにも融通が利かない
4. プロジェクトは力を奪う
5. プロジェクトは間違ったことにフォーカスしている

Googleにとっての「北極星」となる目標は「世界の情報を整理すること」

ミッションの予算とはチームの人数のことだ〜中略〜テック企業が追う支出はチームの人数だけだ

本章での気づき

ミッションで会社を運営するときの予算はチームの人数ということがわかったが、実際にどのように予算を決めているのかは書かれていなかった。
経理部門とやり取りを行うときに、部署ごとの予算やソフトウェアの資産化とかは決めてはいると思うので、そのあたりの調整はどのように行っているのかが気になった。

スクワッドとは、少人数で、職能横断の、自己組織化されたチーム（多くの場合、8名以下で構成される）

スクワッドでは見かけることのない役割が2つある。プロジェクトマネージャーとスクラムマスターだ

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

分離されたアーキテクチャの利点

1. 複数チームが並行して同じプロダクトに取り組める
2. リリースを分離できる
3. メンテナンスとデバッグが容易になる
4. 「爆発半径」を抑えられる

経営リーダーやマネージャー向けの簡単なヒント

1. チームに発憤興起してもらおう
2. チームに間違えてもらおう
3. 「間違い」に備えよう
4. 楽しい名前を選んでもらおう

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

本章での気づき

個人的にかなり面白いと感じられた章だった。
スクワッドの役割や動き方、経営側やマネージャーが意識しておくスタンスなどが書かれているので、組織内への説明にも使える章に感じた。
また、QAの項目でも「スクワッドと経営陣で意見が合わなかったらどうなる？」「誰がスクワッドをマネジメントする？」といったことまで書かれているので、複数のスクワッドが生まれても参考になる組織体制だと感じた。 分離されたアーキテクチャというのは、マイクロサービスのことを指しているのかなと思った。ここは原著の方を読んでみたい。

スケールさせることは、PMF（プロダクトマーケットフィット）を果たしたテック企業が直面する最大の課題のひとつだ

スケーリングの原則

1. スクワッドを第一に考える
2. サーバントリーダーを信じる
3. ミッションが肝心
4. ミッション特価のフルスタック編成
5. 人数は重要
6. トライブ内での移動を促進する

トライブとは、担当するミッションが類似、関連しているスクワッドがまとまったもの

多くの場合、トライブの人数は、150人程度までに収まっている

チャプターとは、同じ専門性を持つメンバーで構成される、トライブ内のグループ（例としては、テスター全員やWebエンジニア全体）

ギルドは、同じ専門分野に興味のあるメンバーからなるグループで、組織（トライブも）を横断して形成される（例としては、iOSギルド）

ギルドには誰が参加してもかまわない

ギルドでは、独自にアンカンファレンスが開催される

本章での気づき

ギルドの例でiOSギルドが挙げられていたが、組織を横断するということでは、もう少し広い範囲でのギルドがあるのかなと思った。
本章を読んだ感想としては、

• トライブ
  • ECサイト会社における、顧客向け機能開発本部、在庫管理システムの機能開発本部など
  • 特定機能の開発運用チームは、スクワッドとして機能開発を行う
• チャプター
  • フロントエンドエンジニアチーム、バックエンドエンジニアチーム、マーケティングチームなど
• ギルド
  • オムニチャンネル勉強会、iOSアプリ開発勉強会、ビジネス本読書会など

みたいなイメージでよいのだろうか。

カンパニーベットとは、会社が取り組みたい重要事項を、終わらせたい順に並べたリストのこと

全社リソースの30%は常にカンパニーベットに取り組んでいる状態にしておく

四半期ごとに戦略チームが集まって、全社で次に取り組むべき「巨大で大胆かつ困難」な目標について議論する

ベットにはそれぞれ2ページの概要がある

• 1ページ
  • ロードマネージャー
  • ステークホルダー
  • 成功指標
• 2ページ（DIBB）
  • データ
    • イテレーションの対象となるプロダクトやコンテンツ、ビジネスモデル、あるいは世の中の状況等と自分たちとの関連を示す具体的なデータ
  • インサイト
    • 現実のデータから導き出された見解や結論、または学んだこと
  • 確信
    • チームに対して向かうべき方向を示す、単独または複数のインサイトにもとづく仮説
  • ベット
    • 実際にテストすることに決めた確信（単打奥または関連する一連のもの）。具体的に目標を定めてリソースを投入することでその実現を目指す

カンパニーベットの利点

• 重要なことから終わらせていく
• 社内メンバーの流動性を高める
• フォーカスを強制する
• 全社横断の連携を可能にする

カンパニーベットをやり抜くためのコツ

• 専任のロードマネージャーをアサインする
• 自分の部署よりも広い視野で考える
• コミュニケーションプランを考える
• 早いうちから統合する
• 大掛かりな取り組みは時間をずらす

Spotifyも最初からベットの数を絞れていたわけではなかった。初期バージョンのベットには65もの取り組みが載っていた

Spotifyが苦労の末に学んだのは「大きなベットを2つ同時進行させると高くつく」ということだ

本章での気づき

全社のタスク優先度を決めるのは経営側の責務だと思っていたが、カンパニーベットという制度を使って、経営側とスクワッドの意見を合わせているということがわかった。
本文の中で四半期ごとに戦略チームが集まるということだったが、次の四半期におけるカンパニーベットの内容を決めるのに四半期もかけられる筈はないし、そこでの議論はどのように行われているのかが気になった。
Spotifyも最初からカンパニーベットを絞って運用できていた訳ではないということが書かれていたので、地道に改善を行っていっているのだろうと思った。

多くのテック企業でマネジメントスタイルの転換が起きているが、なかでも最も重要なのは、「具体的に何をすべきかが指示されない」ことだ

ユニコーン企業ではすべての情報は基本的にオープンにしている

情報を基本的にオープンにすることは、次の3つを可能にする

1. すぐれた意思決定
2. 「信頼していますよ」というシグナルの発信
3. 物事を進めやすく、しかも速くする

Appleのエンジニアは、GoogleやFacebookのエンジニアのようには仕事についてのブログを書いたり、執筆したりすことはまだできない

テック企業の働きかたのまとめ

• とても自律している
• とても自由度が高い
• 責任は重い
• 何をすべきかを直接指示する人はいない
• すべての情報は基本的にオープン

本章での気づき

SIerだった会社とテック企業の働き方を体感してみて、本章で書かれていることはかなり共感できる内容だと感じた。
Appleのエンジニアは、世の中にインパクトを与えるプロダクトを作っていて、社外秘の動きが多いため、なかなか社外向けの活動ができないというのが書いてあり、今の御時世では転職する際にどのような動きをしたかが見えづらく、Appleのエンジニアは転職時に実は困っていたのかもしれないと感じた。

「プロダクティビティスクワッド」は、他のエンジニアリングチームを速く進めるようにすることをミッションとしたチーム

「ハックウィーク」とは、エンジニアが通常業務を脇において、自分の好きなことをなんでもやれるイベントだ。Spotifyでは期間を1週間として年に2回開催される。

ハックウィークの最終日には必ずステージ上に上がって、自分の時間をどう使ったのかをみんなに示さねばならない。このルールは「リリースする責任」に加えて「自分の行動に責任を取る」とはどういうことなのかという感覚も養える

ハックウィークの成果

• 各拠点の従業員が一堂に会することができた
• 普段は一緒に仕事をする機会がないメンバーとコラボレーションできた
• 全社にわたって強い絆を生み育てることに寄与した
• 従業員ひとりひとりのユニークな才能と創意工夫に触れる機会になった
• 学習の手段として役に立った
• ものすごく楽しかった

エンタープライズ企業でなら予算や納期の名の下に容認されていたような貧弱な設計判断は、テック企業では受け入れられない

新機能なしの2年間。「Spotifyは来年まで新機能を一切追加するつもりはない。その代わり、インフラストラクチャとスケーリングに取り組むことにする」

テック企業のリリースでは、フィーチャーフラグとリリーストレインの2つが定番のプラクティスとなっている

定期的なリリースをとにかく継続していくことには2つの重要な効果がある

• 期日に間に合わせるために期限ギリギリまで機能を詰め込もうとするストレスから解放される
• チームはプロダクトを小さなバッチで継続的に改善できるようになり、テストやデバッグも容易になる

本章での気づき

フィーチャーフラグなど、最近のモダンな開発手法も掲載されつつ、Googleの20%ルールに近い、Spotifyのハックウィークのようなカルチャーを見ることができた。
設計時点での妥協結果は、「新機能なしの2年間」の項目を読むと、どのような事態になったかがわかりやすく、自分自身でも経験はしているので、すごく納得できた内容だった。

Spotifyのような音楽ストリーミングサービスではあれば、MAU（月間アクティブユーザー）、日々の登録者数、有料プレミアムユーザー数を追う。そこから大きなカンパニーベットが生まれる

A/Bテストとは、どのデザインがより効果的かを確かめるために、テック企業がプロダクトを使って実施している実験のことだ

データサイエンティストの支援内容

• 収集するメトリクスを決定する
• さまざまな形式のデータをフォーマットしてクリーンアップする
• タグ付けとコレクションのための命名規則を考える
• 仮説と検証を立案する
• どの結果が統計的に有意であるかを判断する
• 探索的にデータを分析する
• レポート、サマリー、ダッシュボードを用意する

本章での気づき

テック企業で働いてみて、自分たちが運用しているプロダクトのデータを分析することの重要性はとても実感していたので、本章での内容は改めて納得を得られたという感じだった。

テック企業一般に共通する働き方の特徴はある。けれども、テック企業それぞれの間でそのニュアンスには違いがある

Spotifyが大事にしているのは、権限付与、信頼、安全、そしてチームだ

チームについての信念

• 何者であるかよりも、何者になれるか
• 最も速く学んだ者が勝つ
• これはマラソンだ。短距離走じゃない
• 強いチームは強い個人を凌駕する
• 異なる観点の衝突が大きな躍進を起こす

エンジニアリングについての信念

• 慎重で思慮深い要件収集よりも学習と実行のスピードを重視する
• イテレーションを短くするほど学習は速くなり、価値は早く実現し、品質も高まる
• 世界に誇る技術は少ないほうが、速く進める
• 権限の与えられた小さな職能横断チームが素早いプロダクト開発の基盤だ
• 強いチームは常にロックスターを打ち負かす
• 知識や実績、経験よりも、学習能力と適応能力が重要だ
• あらゆるデータにアクセスできれば、人はすぐれた意思決定を下せる

本章での気づき

文章メモには記載していないが、Shopify内の実際に起きたストーリーが書かれており、本書の中ではかなり力をいれて伝えたかった内容だったのかなと感じた。
AmazonのOLPは有名な話だが、Spotifyのストーリーも有名になると思うので、本章は読んでおいて損はないと思う。
個人的には、本番環境が壊れた際の「壊したのはあなたが最初ではありませんし、最後にもならないはずです」というやり取りがすごく素敵なやり取りに感じた。

スタートアップは、少なくとも最初のうちは、金銭では人を惹きつけられない。しかしスタートアップ企業があり余るほどに持っているものがある。それは、目的だ。

チームに目的が備わったら、経営リーダーに抽象度が高めの目標を設定してもらおう。それを自分たちのベットのリストにするんだ

「スタートアップみたいに振る舞う」とは、予算編成やプロジェクトみたいな無駄をぜんぶやめてしまうことでもある

本書で心から伝えたいことは2つだけだ。「権限を与えること」「信頼すること」

本章での気づき

スタートアップみたいに振る舞うにはどうすればよいかの動き方のヒントが書かれていた印象だった。
目的というのは、ミッションと読み替えてもよさそうに感じた。
ただ、言い訳にするなという鼓舞する文章もあったのだが、この目的が何かを改めて整理する動きには、経営側の意識が必要になりそうに感じたので、本書は文化を作っている経営側にこそ読んでみてほしいと思えたまとめであった。