Booklog - ユニコーン企業のひみつ Spotify で学んだソフトウェアづくりと働き方
Jonathan Rasmusson, 島田浩二, 角谷信太郎
最初から 1 章まで。薄いしこれまで見てきた企業のマネジメントとかと近そうなテーマだったので。 本書で言うユニコーン企業は投資的な意味でなくエンプラのような事業規模のスタートアップのような企業を指す。 本書ではスタートアップとエンプラのやり方を対比してるが、これは文中にもあるが解きたい問題に対する解法の違いやな。 これは TEAM OF TEAMS でも書かれてた不確定性に対するアプローチの違い。エンプラが予測可能でスタートアップが未知の領域に該当する。 学習する機会として解決すべき顧客の問題を探し高速に反復するのも、不確定性に対するアプローチがそうというだけ。 マネジメントの本を読んでかなり解像度上がったからより汎化した理解ができるようになった気がするわ。しらんけど。 次章以降目新しい気づきがなかったら驚きそうだが、でももしそうなら基礎的なマネジメントの原則が今でも通用するって風にも考えられるか。
2026-02-10, read count: 1, page: i ~ xix, 1 ~ 18, pages read: 37
2 章。 プロジェクトとミッション(プロダクト開発)の違いについて。プロジェクトは新規プロダクトの開発には向かない。 一応デマルコ本ではプロジェクトも反復開発できるように設計すればできるけど、不確定性が大きい時代に前もってマイルストンを置くのはリスクが有るというのがわたしの認識。 フィードバックを受けて発展させていくのはどちらでもできるが、期間の融通や作り上げるものの可塑性が違う印象。 ただ扱うものが違うのでこの差を取り上げてプロジェクトがだめというものでもないと思う。 あと経験上サ終とか EOL とか、期日が決まってて誰もやりたがらない仕事に関してはミッションはクソの役にも立たないので、使い分けが肝要よな。 個人的には、大きなミッションの元でプロジェクトを細分化して扱う、が今のところしっくり来てる。
2026-02-11, read count: 1, page: 19 ~ 32, pages read: 14
3 章。 小規模な職能横断チームが自律的にプロダクトに責任を持つから速い。計画でなくインパクト(成果かな)を重視する。 自律≒長期的視点を持ち、デリバリーにまつわる無数のトレードオフのバランスを取れる権限を持つ。権限を与え仕事を任せて口出ししないことが自律性を育む。 手を動かす人だけで構成され、プロジェクトマネージャーやスクラムマスターの役割が必要だとしても、誰かがその役割をうまくこなしているから、人は必要ない。 そのためにも継続的に学習していて当事者意識を持って取り組める良い仕事をしたいと思っている情熱のある人を探そう。 アーキテクチャに触れてる部分もあったがそれはコンウェイの法則の文脈と思われる。割と内容は端折ってまとめた。 というのも、この自律性を尊重することが最大の速度と成果を生む話はこれまでもマネジメント本で読んできた内容なので、特に驚きはなかったため。 むしろそれだけ方法論に縛られて原則を忘れた組織が多かったからこそ本書ですごいぞと触れられたいう話なんやろな。確かにバスに誰を乗せるかという点で実現は難しい。
2026-02-12, read count: 1, page: 33 ~ 56, pages read: 24
4 章。自立した小規模な職能横断チームをスケールさせる。 小規模チーム(スクアッド)が担うミッションの類似するものを集めてトライブとする。トライブもスクアッド同様にビジネス領域に責任を持つ。 チャプターはトライブ内の同じ専門性を持つ人々のコミュニティ。コミュニティとしての学習と成長を促進する。 ギルドはさらにトライブを超えた専門性に興味を持つ人々の全社的なコミュニティ。正式な組織構造ではなく、横断的に知識共有や学習を促進する。 働くトライブすらも自分たちで選ぶ。多少のビジネス的な事情による根回しはあれど。 メッシュ状の知識共有ネットワーク構造って話か。マトリクス組織と違うのは職能で集められた方はサポートとして機能しビジネス領域の方が本家なところ。 残念なのは自分の所属する組織が数十人規模のためこの規模感のエンジニア組織のスケーリングに関する悩みが身を以てわからない点やな。 とはいえ、こういう実装パターンがあるという形で覚えておく。
2026-02-13, read count: 1, page: 57 ~ 72, pages read: 16
5 章。社運を賭ける大規模プロジェクト。 小規模チームの自律性を維持しつつ、会社として注力したい重大なプロジェクトをカンパニーベット≒賭けとして示す。 ベットは Data,Insight,Belief,Bet の情報が示され、なぜ重要なのかが明確に示される。 ベットの選任のマネージャをつけ、関係者のコミュニケーションをオープンに保ち部外者感をなくす。 小規模チームは自分たちのミッションと照らし合わせ自律的にベットに協調するか、合わないならミッションを優先するか決める。あくまで小規模チームの自律性が最優先。 ベットはチームに高負荷を強いるため一度に複数は行わない。従来企業では話に上がらないような反直感的なベットこそがディスラプティブなイノベーションにつながる。 ベットは経営トップを起点に発するというのは GE のやつでも見たようなトップがリスクを負うことが現場を動きやすくさせるアレやな。ここは経営層が何を担うべきかも示していて、つながるね。
2026-02-14, read count: 1, page: 73 ~ 88, pages read: 16
6 ~ 7 章。 テック企業のマネジメントはフラットで何をすべきか誰かが指示することはない。スピードが得られるなら、金を使うべきだし信頼し権限を与える。 情報の透明性が高いほどチームの自律性が高まる。チーム同士が互いに助けあう。この自由さは責任とセットで、従来型企業に比べると責任は重い。 テック企業は技術を効果的に活用することで生産性に投資する。エンジニアリングチームの生産性を高めミッションを持つチームがある。インフラ等もセルフサービスで提供されブロックされない。 高い品質を要求されるからこそ質の高い仕事になる。フィーチャーフラグとリリーストレインでの素早いリリース。継続的な改善と学習の文化。 本書の内容は学んできた内容から外れることが 1 つもないんのでびっくりすることもないが、復習として、また実例としては役に立つな。 昔、自分でホテルや新幹線を予約できない、アバターの変更もできない会社にいたこともあるが窮屈で何の責任もなくて、全く面白くなかった。
2026-02-15, read count: 1, page: 89 ~ 116, pages read: 28
8 章。テック企業はデータを追う。 社内で直接話を聞けるようなものではないため計測して洞察を得る把握する。例えば画面の遷移やアプリをタップして MAU につながる物を探す。 A/B テストのような手法を通してより優れた改善策を選び改善していく。 A/B テストでもわからないような場合は顧客に直接聞くしかない。 データの意味を知り意義のある実験を実施するにはデータサイエンティストのような専門家の助けがいる。こういう分析力を小規模チームに与えることが大きな効果につながる。 これはせやなという感じ。自分の仕事で必要なイベントデータを適切に集められてるかというとそうでないのが悩ましいが。
2026-02-16, read count: 1, page: 117 ~ 128, pages read: 12
9 章。文化は勝手に育たない。テック企業は文化に投資する。会社も違えば文化も違う。 例えば Spotify は権限付与・信頼・安全・チームを重視し、良いチームが良いプロダクトを生むと考える。 この重視するものを落とし込んだ核となる信念が 1on1 などで度々出てくる。そうやって培われた文化は行動で示すことで初めて機能する。 あと Spotify のスウェーデンぽさの話。日本の企業然りどこも土地柄は反映されるだろうな。 「これはマラソンだ。短距離走じゃない。」はいいな。継続性を考えると特に重要なことだ。この章は好きやな。
2026-02-17, read count: 1, page: 129 ~ 152, pages read: 24
Years (3)
Books (39)
- Domain Modeling Made Functional 関数型ドメインモデリング ドメイン駆動設計と F# でソフトウェアの複雑さに立ち向かおう2024-08-19〜2024-09-06
- GE 巨人の復活 シリコンバレー式「デジタル製造業」への挑戦2026-01-21〜2026-01-29
- NO HARD WORK! 無駄ゼロで結果を出す僕らの働き方2025-12-23〜2025-12-31
- People Powered 「ビジネス」「ブランド」「チーム」を変革するコミュニティの原則 遠くへ行きたければ、みんなで行け2024-08-22〜2024-10-21
- Slack ゆとりの法則2025-10-17〜2025-10-30
- TEAM OF TEAMS 複雑化する世界で戦うための新原則2026-01-07〜2026-01-20
- The DevOps 勝利をつかめ! 技術的負債を一掃せよ2026-01-01〜2026-01-06
- なぜこの人はわかってくれないのか 対立を超える会話の技術2026-01-30〜2026-02-09
- アドレナリンジャンキー プロジェクトの現在と未来を映す 86 パターン2025-11-13〜2025-12-01
- エッセンシャル思考 最少の時間で成果を最大にする2025-12-03〜2025-12-12
- エフォートレス思考 努力を最小化して成果を最大化する2025-12-13〜2025-12-22
- サンダー・キャッツの発酵の旅 世界中を旅して見つけたレシピ、技術、そして伝統2025-05-20〜2025-06-22
- サンダー・キャッツの発酵教室2025-07-15〜2025-07-18
- スーパーエンジニアへの道 技術リーダーシップの人間学2025-07-19〜2025-08-15
- デッドライン ソフト開発を成功に導く 101 の法則2025-10-10〜2025-10-16
- ピアリング戦記 日本のインターネットを繋ぐ技術者たち2024-12-28〜2025-01-14
- ピクルスと漬物の歴史2025-02-24〜2025-03-04
- ピープルウエア ヤル気こそプロジェクト成功の鍵 第 3 版2025-09-17〜2025-10-09
- ファスト&スロー あなたの意思はどのように決まるか?2026-01-19〜2026-02-16
- プログラマーのための CPU 入門 CPU は如何にしてソフトウェアを高速に実行するか2025-01-15〜2025-03-19
- プログラマー脳 優れたプログラマーになるための認知科学に基づくアプローチ2024-09-28〜2024-10-15
- プログラミング F#2024-09-07〜2024-09-07
- プログラミングの心理学 25 周年記念版2025-08-16〜2025-09-16
- ユニコーン企業のひみつ Spotify で学んだソフトウェアづくりと働き方2026-02-10〜2026-02-17
- ユーザーの問題解決とプロダクトの成功を導く エンジニアのためのドキュメントライティング2024-09-15〜2024-09-27
- 世界の作りおき野菜 みんなに愛される味付けの魔法2025-02-22〜2025-02-23
- 世界の納豆をめぐる探検2025-12-02〜2025-12-02
- 世界一流エンジニアの思考法2024-09-08〜2024-09-14
- 入門・倫理学2024-10-21〜2024-12-09
- 分子調理の日本食2025-02-08〜2025-02-09
- 型システムのしくみ TypeScript で実装しながら学ぶ型とプログラミング言語2025-07-01〜2025-07-14
- 実践プロパティベーステスト PropEr と Erlang/Elixir ではじめよう2024-11-05〜2024-12-27
- 家庭の低温調理 完璧な食事のためのモダンなテクニックと肉、魚、野菜、デザートのレシピ 992025-02-10〜2025-02-16
- 本を読む本2024-10-13〜2024-11-04
- 演奏するプログラミング、ライブコーディングの思想と実践2025-06-23〜2025-06-30
- 熊とワルツを リスクを楽しむプロジェクト管理2025-10-31〜2025-11-12
- 男のスコッチウィスキー講座 100 蒸留所 巡礼試飲旅2024-10-26〜2025-06-01
- 習慣と脳の科学2025-04-06〜2025-05-19
- 魏武注孫子2024-11-25〜2025-04-05