数日前に『ユニコーン企業のひみつ』という本が出版されました。 翻訳者の一人である角谷さん（@kakutani）のツイートでそのことを知って、興味が沸いたので早速読んでみました。
まだ一通り最後まで読んだだけですが、まずはとてもよかったです！ あまり書評とか書いたことないのですが、感じたことをつらつら書いてみます。
簡単に自己紹介
私は現在 クラッソーネ というスタートアップ企業に勤めていて、会社が運営するサービスの開発をするソフトウェアエンジニアです。
クラッソーネは最初こそ完全に外部に委託してアプリを開発していましたが、最近では段々と私のような正社員のエンジニアも増えてきました。 現在は業務委託の方も含めて12名ほどのチームで開発をしており、今後も幸いなことにエンジニアがどんどん増えていく予定です。
いわゆるスクラムを取り入れていますが熟練度は低く、中の人としては開発サイクルがうまく回っているとはあまり思っていません。
- プロダクトチームはスケールアップに耐えられる構造になっているか？
- 高速にサービスを磨き上げていく体制・開発プロセスになっているか？
みたいなことを（個人的にですが）ちょうど悩んでいるところでした。
「自律・権限・信頼」という話には共感しかなかった
第三章からはユニコーン企業が取り入れているチーム体制、特に「スクワッド」という仕組みについて説明されていきます。
- スクワッドとは自己組織化した職能横断チーム
- スクワッドへの権限付与と信頼が非常に重要視されているが、一方でスクワッドには自律が求められる
- 複数のスクワッドが同じ領域を扱わないよう、アーキテクチャ上の工夫が不可欠
- 言われたことを行う「野菜切り係」ではなく、ミッションの実現方法の検討から行う自己完結した組織
などの特徴があげられていました。
権限を持った小さな職能横断チームこそが、高速なプロダクト開発とイノベーションの基盤である
テック企業勤務の人たちがすぐれた仕事をしているのは、無料のラテやテーブルサッカー台のおかげなんかじゃない。権限が与えられ、信頼されているからこそ素晴らしい仕事をしているんだ。
ミッションを実現するための権限を全て与えること、またミッションの実現に全幅の信頼を寄せること。 これらを徹頭徹尾行っているのがテック企業であり、従来の組織づくり論とは一線を画している感があります。
権限を与えて信頼をするからこそポテンシャルを最大限に発揮できる、という話は以前も聞いたことがありました。 「リッツ・カールトン」のリーダーシップ戦略について書かれた『ゴールド・スタンダード』です。
信頼関係の不十分な職場では、現場の従業員は口癖のようにこういう。「マネジャーに聞いてみます」。リッツ・カールトンでは、他の人に判断を任せることはしない。...（中略）... また、経営陣は、サービスの提供や回復に、従業員が裁量を発揮できる手段を考え出した。その手段とは、必要であれば、お客様一人につき、１日に2000ドルまでを使うことができる権限を紳士淑女一人ひとりに認めたことである。
このように財務状の権限を与えることによって、リッツ・カールトンは従業員に対する信頼を示している。これを軽率だとか、無責任だと考える人もいるかもしれないが、リッツ・カールトンは、紳士淑女を十分に信頼しているのである。
- 自分が取り組む仕事をいかにして自分事として捉えるか
- 相手に取り組んでもらう仕事を以下にして自分事として捉えてもらうか
『ユニコーン企業のひみつ』により、エンジニア組織におけるこうした問いに対する有力な解が示されていたのではと感じています。
任されることは嬉しいもので、責任があることには前向きに一生懸命取り組むものです。 そしてそこに「失敗をゲームの一部として許容する」などの文化が組み合わさることで安全に取り組み続けることができますね。
クラッソーネもちょうど来月から新卒の子がエンジニアチームへとジョインします。 積極的な権限委譲と十分なサポートをすることで、確かな成長と大きな成果を出していってもらうのが今から楽しみです。
スタートアップではどのように導入するのだろう？
第四章以降は、スクワッドを軸にしたチーム運営をどのようにスケールさせていくかの話が続きます。 訳者あとがきに書かれている内容を踏まえると Spotify さんの中でもいろいろ形は変わり続けているようですが、それでも数千人規模のチームに適用できる仕組みというわけです。
一方で、これをプロダクトマーケットフィットすらしていない小さな組織に適用するにはどうすればいいのかについてはあまり書かれていません。 スケールダウンさせていったときにどのような姿になるのか、という話です。
- スクワッドが少ない分、スクワッドが担当する領域は広くなるのか？
- プロダクティビティスクワッドがいない分、生産性の向上はスクワッド自身が担うのか？
- スクワッドの日常業務にいわゆる「運用タスク」が含まれるのか？
- 資金に乏しい組織の場合はスピードを重視した貧弱な設計判断が受け入れられるのか？
こうしたそれぞれの問いについて、書籍だけを読んだ今の理解ではいずれも YES だと思っています。 そしてチームがスケールアップしていったときに、アーキテクチャーごとに分担したり生産性向上の専門チームが生まれたりするのだと。
スクワッドの本質は「自律・権限・信頼」であり、それはチームの人数に左右されるものではありません。 理想のスクワッド像になるには時間がかかるかもしれませんが、どんなチームでも今すぐ導入できるものだと理解しました。
スクワッドから運用タスクを引き離すために、Hey さんの「運用週」のような仕組みを導入するのは効果的かもしれません。 一週間などのきりのいい単位で、運用担当メンバーをぐるぐる変えていくのはちょうどいい塩梅な感じがしています。
読み応えのある訳者あとがきも最高でした
訳者である島田さんと角谷さんによるあとがきは Scrapbox にて公開されています。
そしてこのあとがきの内容がとてもよかったです。 特にいいなと思ったのがこちら。
プラクティスは「自分たちの職場で実践するためには、採用した取り組みを支える原則は守りながらも、独自の調整や適応が必要」なのです。これを踏まえなければ、「テック企業ではスクラムをやっていない」からといってスクワッド制に移行したところで、チームは依然として「ユーザーストーリーをバックログから取り出して実装するだけの機械」のままでしょう。
『７つの習慣』でいうところの「原則中心」という考え方にも通じますが、大切なのはスクワッド制にした目的や原則であり、書籍で紹介されている方法をそっくりそのまま導入するのは本末転倒です。
- 経営リーダーは本当の意味でスクワッドを信頼して権限を委譲できるのか。
- スクワッドのメンバーは自分たちの責任の重さを理解できるのか。
- スクワッドの考え方を企業文化として受け入れ、浸透させられるのか。
こうした問いに妥協なく考え抜いて、喧々諤諤議論をかわしあって、その上で自分たちだけのスクワッド制を考えられるか。 こうした取り組みなしにカジュアルに始めてはならないなと強く認識させられました。
おわりに
「自律・権限・信頼」を核としたスクワッドの仕組みにすっかり惚れてしまいました。 冒頭に紹介した、現職で抱えている色々なもやもやを一気に解決できそうな仕組みに、銀の弾丸らしさを感じています。
まずはもっともっとこの本がたくさん売れて、多くの人とこの本の言葉を共通言語にして話し合えるといいなと思っています。 布教活動しなくちゃ...！
