”テック企業はアジャイルなんてやっていない”とは（「ユニコーン企業のひみつ」読書メモ）
タイトル通り、前から読みたかった「ユニコーン企業のひみつ」をようやく読んだので、気になった部分をメモがてら残しておく。
脈絡もなく引用しつつ取り上げていくだけなのでまとまりが悪いことを先に断っておく。
気になったところメモ
以下、本書の前から順に読んで気になった、印象に残った部分を取り上げていく。 たくさんあるので逐次更新。
1章 スタートアップはどこが違うのか
1.1 スタートアップは「火星」から来た
- スタートアップは他人から時間を借りて生きている。
- 金を借りている場合もあるだろうが、調達した資金が尽きる前までの間に迅速に価値を出すというプレッシャーの方が強く感じるのだと伝わる表現。
1.2 「学習する機械」
- テック企業は従業員に財務情報を公開する。あらゆるデータを信じてゆだねる。開発者に自分のマシンへの管理者アクセス権限を与える。そして常にチームにこう問い続ける。「どんな支援があればもっと速く進める？」
- 開発者全員に初日から本番環境へのadmin権限を与えるということの意図が伝わる背景。
- 当然、チームの成熟度は考慮すべきでエンタープライズ系企業が明日からやってうまくいくわけじゃない。
1.6 "Think Different"
2章 ミッションで目的を与える
2.1 プロジェクトの問題点
ユニコーン企業がプロジェクト方式を採用しない理由として、プロジェクトの問題点が挙げられている。
- 期間があまりにも短い
- フィードバックの機会がない
- プロジェクトはあまりにも融通が利かない
- プロジェクトは力を奪う
- プロジェクトは間違ったことにフォーカスしている
特に4つ目の「力を奪う」で説明されているこの一文が強い。
プロジェクトは考えることをやめさせてしまう。
2.2 これが「ミッション」だ
2.6 ミッションの例
ミッションの原則に従うと、ミッションの予算とはチームの人数のことだ。以上。
- トップダウン的な施策で「見積もりは？必要な人員は？」と言われることに対して絵にかいた餅で説明して承認をとるのは違うよ、と。
- 決まった人数＝予算でミッションを進めるので実現時期も今年度中とコミットできるようなものではないと言える。
ミッションを設定するのは経営リーダーだが、そこにどうやって到達するのかを決めるのはチームだ。（略）
チームは自分たちで自分たちの仕事を生み出す。何を作る必要があるのかを決めるのはチームだ。チームに渡すミッションは...
- 会社にとって必要なものにしよう
- そのチームで責任を果たせるものにしよう（他への依存を少なくしよう）
- どうやって達成するかの計画はチームが協力して考えられるものにしよう
- 表現はシンプルだが、すごく難しい。
3章 スクワッドに権限を与える
3.1 スクワッドとは？
- スクワッドとは、少人数で、職能横断（Cross-Function）の、自己組織化されたチームだ（多くの場合、8名以下で編成される）。スクワッドは同じオフィスに席を並べて、自分たちが作ったプロダクトの隅々まですべてに責任を持つ。
- ちいとぽでいうところのストリームアラインドチームに近い定義。
- 「自律した小さなテックチーム」
3.2 スクワッドはどこが違うのか？
- スクワッドは（略）普段から、MVPを出来るだけ早くリリースすることが奨励されている。どうしてかって？スクワッドは最初のバージョンは「正しくない」と心得ているからだ。だから顧客からフィードバックを得たい。しかしフィードバックを得るにはリリースしなければならない。
3.8 Q&A
- 「結論を出す」という行為自体はチーム自身にやってもらうことが望ましい。なぜなら、あなたがチームの領域に踏み込んで何をすべきかを指示すればするほど、チームに与えられている権限や信頼は減ってしまうからだ。
4章 トライブでスケールさせる
（特になし）
5章 ベットで方向を揃える
5.2 カンパニーベットとは
- カンパニーベットとは、会社が取り組みたい重要事項を、終わらせたい順に並べたリストのことだ。
- 通常、小さい目標はカンパニーベットにはならない。ベットは「大きな岩」だ。
- 全社リソースの30%は常にカンパニーベットに取り組んでいる状態にしておく
- カンパニーベットはチームが常に取り組むべきものを示す指針にもなる。
5.3 カンパニーベットの仕組み
- DIBBはやるべきだと考えているを系統立てて検証するための意思決定フレームワークである
- Data, Insight, Belief, Bet のそれぞれの頭文字
5.5 やり抜くためのコツ
- 反直感的ベットとは、当初は誰も信じてくれないのだが、後から考えると実に見事で明白に思えるようなベットのことだ。コーヒー１杯で７ドルも取ろうなんて正気か？誰がお金を払って私のソファで寝たいと思うわけ？
- 念を押しておくが、自分たちの時間を何に費やすべきかの最終的な決定権はあくまでスクワッドにある。
6章 テック企業で働くということ
6.2「何をすべきかを指示するつもりはないよ」
- （スクワッド解散に伴い既存プロダクトの所有者がいなくなり）新しい2つのスクワッドは、どちらが既存のプロダクトを引き継ぐのかを合意できなかった。そこで彼らは、トライブリードである私の上司に決めてもらおうとやって来たというわけだ。ところが上司はそれを拒否した。
- 「情報が足りないとか、文脈がわからないとか、全体像に疑問があるとか、そんなときは私のところに来てほしい。だけど、これはあなた方が自力で解決すべき問題だ。」
- 本当に現場でよくある話で、決まらないものはトップダウンで決めるしかないのだと思っているが、これはあくまでも「よく話し合って両チームで決めてほしい」という回答を出すのだということ。これができる組織の強さよ。
6.3 お金の使い方が違う
- これまでの職業人生で、スピードのためにお金を使えなんて言われたことは一度もなかった。
- もし「資金を投入すれば競争に勝てる」というのなら、喜んでそうする。細かいことにこだわっている場合じゃない。
6.4 「信頼してないの？」
- 従来型企業は従業員を信頼していない。そのため、数え切れないほどの手段を用いて、あらゆる物事の進みをものすごく遅くさせている。
- （大手テック企業の場合）開発者は自分のマシンへのフルアクセス権限がある、すべてのチームが本番環境にアクセスできる
- テック企業ならこれはせめて同じ水準にしたい...が、そんなチームに所属していた経験は未だにない。
7章 生産性向上に投資する
7.3 ハックウィークを開催する
- 「ハックウィーク」とは、エンジニアが通常業務を脇に置いて、自分の好きなことをなんでもやれるイベントだ。（略）Googleはこれを「20%ルール」として実践して、同種の発想の有名な先駆者となった。
- ハックウィークに参加するのは単独でもいいし、チームを組んでもいい。内容は基本的に、やりたいことなら何でもいい。ただし一つだけルールがある、ハックウィークの最終日には必ずステージに上がって、自分の時間をどう使ったのかをみんなに示さねばならない。
- ハックウィークでは何かをリリースすること、何かをデモすることが強く推奨されている。
7.5 品質に高い期待を持つ
（コラム）新機能なしの2年間
- SpotifyのCEOであるDaniel Ekは取締役会で、CEOなら誰もやりたくないメッセージを伝えた。（略）「Spotifyは来年まで新機能を一切追加するつもりはない。その代わり、インフラストラクチャとスケーリングに取り組むことにする」
- CEOがこれを宣言するというのはどのような心境なのだろうか。想像を絶する。。
7.8 フィーチャーフラグを活用する
- フィーチャーフラグは（略）ソフトウェアの特定機能を本番環境上でオンにしたりオフにしたりできる。（略）理由は2つある。未完成の作業の統合と、実験だ。
- （フィーチャーフラグは）チームが未完成の作業をコードベースにマージしても、それをフィーチャーフラグで隠せるのだ。ソフトウェアの実際の利用者には影響を与えることなく、開発を続けられる。
- これはインテグレーションプロセスをシンプルにするので、マージが後回しになっているせいで修正が遅れているバグの数を最小限にできる。
7.9 リリーストレインでリリースする
- リリーストレインとは、完成した機能のまとまり（バッチ）を、あらかじめ決められた間隔で定期的にリリースするプラクティスだ。
（定期的なリリース継続の2つの重要な効果）
- 期日に間に合わせるために期限ギリギリまで機能を詰め込もうとするストレスから解放される
- プロダクトを小さなバッチで継続的に改善できるようになる
- バッチが小さくなれば、テストやデバッグも容易になる
リリーストレインとフィーチャーフラグを組み合わせると、継続的にリリースできる実に見事な仕組みが実現する。
8章 データから学ぶ
8.3 A/Bテストで実験する
- こうした疑問に直面したとき、テック企業はどちらかを選ぶようなことはしない。どちらも試す。
9章 文化によって強くなる
9.4 核となる信念
- 慎重で思慮深い要件収集よりも、学習と実行のスピードを重視する
（エンジニアリングについての信念）
9.5 行動は言葉に勝る
- （重要なシステムを壊してしまいトライブ全体に向けて謝罪のメールを出したメンバーに対して上司がかけた言葉）
「気にしなくて大丈夫です。よくあることですから。（略）壊したのはあなたが最初ではありませんし、最後にもならないはずです。それに、あなたに壊せてしまうような本番環境だという事実は、私たちのシステムにはまだ改善の余地があることの証拠です。」- これを一片の曇りもなく伝えることができる責任者はどれだけいるだろうか...
- 自分にも多分できない（言いながら表情が濁ってしまう気がする）。。
10章 レベルを上げる：ゆきてかえりし物語
10.10 「言い訳」を取り除く
- こんな奇抜なアーキテクチャにしたのは私じゃないし。他の誰かの仕業だし。
- すでに運用中のプロダクトを引き継いで障害が起きたりすると喉元まで出かかる言葉。これを乗り越えるのが第一歩。
