ユニコーン企業のひみつ/訳者あとがき
この「訳者あとがき」のライセンスはクリエイティブ・コモンズの表示-非営利- 継承です。この「訳者あとがき」は「角谷信太郎と島田 浩二」によって変更されています。変更前の原著作者は「オライリー・ジャパン」です。このページの内容はこのクリエイティブ・コモンズライセンスの範囲内において自由に利用できます。
hr.icon
そもそもなぜextreme(究極)という単語が名称に含まれているのか。XPは常識を原理とし、極限まで実践するからである。
『XPエクストリーム・プログラミング入門』Kent Beck、ピアソン・エデュケーション
本書は、"Jonathan Rasmusson. Competing with Unicorns: How the World's Best Companies Ship Software and Work Differently. The Pragmatic Programmers, LLC, 2019. 978-1-68050-723-2"の全訳です。著者の訳書は『アジャイルサムライ』(オーム社、2010年)、『初めての自動テスト』(オライリー・ジャパン、2016年)に続く3作目です。
本文中では明示されていませんが、本書の対象読者について、著者は出版後のインタビュー記事で次のように語っています。「業務としてソフトウェアデリバリーに関わっている人たち(開発者、テスター、デザイナー、マネージャーなど)なら誰でもだけど、本当の対象読者は経営リーダーを始めとした、チームをプロダクトやソフトウェアのデリバリーにフォーカスさせる組織づくりの担当者なんだ(引用者訳)」と。これは組織として文化を育てることこそが、ハイパフォーマンスなテック企業として成功するための「大統一理論」だと本文中で述べていることと対応します。本書のテーマはテック企業の「組織文化」です。
「ユニコーン企業ではスクラムをやっていない」
冒頭の「ユニコーン企業のひみつ/日本の読者の皆さんへ」で著者は「アジャイルは今や『ふつう』となりました」と、私たち日本の読者にメッセージを伝えています。日本では読者によってまだアジャイルソフトウェア開発の受容に温度差があろうかと思いますが、原著で想定されている北米のソフトウェア開発では今やアジャイルソフトウェア開発プロセス(具体的にはスクラム)が主流です(註1:ユニコーン企業のひみつ/訳者あとがき#608778457797210000f0ac97)。
原書の公式サイトでは本書の対象読者に求める前提知識を「なし」としていますが、著者が述べる対象読者層からもわかる通り、実際にはある程度のソフトウェアデリバリー(アイデアを機能するソフトウェアに変換して、本番の動作環境でユーザーに届ける)の知識や経験が前提とされています。そして、その知識や経験とは、いわゆる「アジャイルソフトウェア開発」のことです。アジャイルソフトウェア開発に馴染みがなければ、著者の前著『アジャイルサムライ』や2020年11月の改訂(スクラムガイド_2020年11月)でコンパクトになって読みやすくなった「スクラムガイド」を参照しておくとよいでしょう。
本書では全編を通じてユニコーン企業(テック企業)とエンタープライズ企業が対比されます。前著『アジャイルサムライ』の本文と似たような説明になっている箇所もあり、読者によっては多少混乱しそうなので補足しておきます。ここで時流に合わなくなった姿として描かれている、エンタープライズ企業におけるプロジェクトベースのソフトウェア開発の進め方は、ウォーターフォール開発ではありません。アジャイル開発、具体的にはスクラムのことです。「ユニコーン企業ではスクラムをやっていない」のです。
ではスクラムをやらずにユニコーン企業はどうやって「なんだかうまいことやっている」のか。鍵は「自律、権限、信頼」であり、それらを可能にする組織文化こそが「ユニコーン企業のひみつ」だというのが著者の主張です。ということはスクラムはもう古くて、新しいやり方に変えていかねばならないのかというと、そう単純な話でもありません。Edger H.Scheinの『企業文化 改訂版:ダイバーシティと文化の仕組み』によれば「文化とは共有された暗黙の仮定のパターン」です。暗黙的な「企業の文化を説明 するのは難しい。その真髄やニュアンスは日々の仕事でしか体感できないので、 うまく捉えられない」ので、本書では著者自身が 3 年間在籍したSpotifyでの経験をもとにその説明を試みます。
註1: "The 14th annual State of Agile Report"(2020)では「アジャイル開発の経験あり」と95%の企業が回答している(北米と欧州が回答組織の74%を占める)。https://stateofagile.com/#ufh-i-615706098-14th-annual-state-of-agile-report/7027494
"There is No Spotify Model"
Spotifyは2006年にスウェーデンで創業されたテック企業です。音楽配信サービスを開始したのは2008年。日本でも2016年からサービスを提供しています。2020年末時点で世界170のマーケットに展開し、月間アクティブユーザーは3億4500万ユーザーです。フルタイムの従業員が5,584名、うちReseach and Developmentが2,624名。エンジニアリングに関わっていそうなメンバーの比率は半数弱という構成です。著者がSpotifyに在籍していたのは2014年から2017年頃で、その3年間でも組織規模は1,300名から3,000名規模へと急拡大していたようです。ちなみに、Spotifyは2018年にニューヨーク証券取引所に上場しているため、原著出版時点で既に書名の由来である「ユニコーン企業」(評価額1億ドル以上で未上場のテック企業)ではなくなっています。著者がSpotifyに在籍し、本書の執筆対象としていた当時のSpotifyは確かにユニコーン企業だった、ということで納得してもらえればと思います。
Spotifyでのスクワッドやトライブ、チャプターにギルドといった少し変わった名前のエ ンジニアリング組織編成、いわゆる「Spotifyモデル」は、アジャイルコーチのHenrik Knibergらの記事や動画をきっかけに英語圏のアジャイル界隈では 広く認知されました。本文での説明も、初出である"Scaling@Spotify"(2012年)、"Spotify Engineering Culture"(2014 年)、"Spotify Rythm"(2016 年)を踏まえたものになっています。とはいえこれも、あくまで著者の在籍時の経験にもとづいたスナップショットです。この点については、"Scaling@Spotify" でも断り書きがされています。
私たちがこのモデルを発明したわけではない。Spotifyは(良いアジャイル企業がそうであるように)進化が速い。この記事は執筆時点の働き方のスナップショットでしかない。道程はまだ半ばだ。ここは旅路の果てではない。これを読んだときにはもう物事は変わっていることだろう。
事実、「Spotifyモデル」はそれ以後も変化していったようです。本書の説明との主な差分を簡単に紹介しておきます。
「プロダクトオーナーとスクワッド(チーム)」という構成から、プロダクトオーナーもスクワッドの一員という位置づけになった
トライブをまとめるリーダーチームとして「TPD Trio」が編成されるようになった(TPDはTribe Lead、Product Lead、Design Leadの頭字語)
トライブ同士が連携するさらに大きな枠組みとして「アライアンス(Alliance)」という枠組みが導入された
本文ではプロダクトオーナーはスクワッドの外にいるような説明がされていましたが、プロダクトオーナーはスクワッドに編入されたようです。これはスクラムガイドが2020年の改訂で「プロダクトオーナーと開発チーム」から「ひとつのスクラムチーム」へと変更されたことを想起させます。トライブが向かう先のアラインメントを「TPD Trio」が職能横断チームとして担うようになったのは、規模の拡大や複雑性の増大への対応だと考えられます。「アライアンス」でトライブ同士を連携させるというのも、組織規模の急速な拡大を踏まえれば自然な成り行きに思えます。
このように、Spotify は自身の置かれた状況の変化に適応していったようなのですが、一方で「Spotify モデル」の認知が高まるにつれて「Spotifyモデルをコピーするな」や「Spotify は Spotify モデルをコピーして『実装』していないのに、どうして他社はSpotifyをコピーすることでSpotifyモデルを『実装』できると考えてしまうのか?」、「Spotifyモデルはうまくいってない(FailedSquadGoals)」とSpotifyモデルへの――というよりはSpotifyモデルの受け止められ方をめぐる毀誉褒貶も激しくなりました。結果として、Spotifyはその後、Spotifyモデルについての情報発信をやめてしまいます。この時期はちょうど著者が離職した頃とも重なります。
価値、原則、プラクティス
本文でも繰り返し述べられているように、他所でうまくいっていること(プラクティス)をただコピーしてもうまくいきません。これは逆も然りです。たとえば、本書ではデリバリープラクティスとして「リリーストレイン」が紹介されています。ThoughtWorks社が定期的に発行している技術トレンドの解説記事"Technology Radar"では、少し前からリリーストレインはHOLD(取扱注意)とされています。遅いチームのスピードアップにはいくらか有効ではあるものの、より速く動けるチームに制約を課すことになりがちだからです。
Spotifyでは自律したスクワッドにリリースの権限があり、アーキテクチャが分離されています。これにより「デプロイ時結合」( 『モノリスからマイクロサービスへ』を参照)を回避できます。そのおかげでスクワッドレベルではリリーストレインという名前で機能しているのでしょう。これはプロダクト全体の実態として見れば「リリースオンデマンド方式」であり、フィーチャーフラグも活用しているわけですから、実質的には継続的デリバリーを実現しているといえます。
ここで思い起こされるのは、アジャイル開発のフレームワークです。たとえば、エクストリームプログラミングの価値、原則、プラクティス。スクラムの価値基準、三本柱(原則)、イベントと作成物(プラクティス)。チームにしても組織にしても、プラクティスを支える原則や、それを生みだす価値観のあり方が組織の文化だといえます。
プラクティスは「自分たちの職場で実践するためには、採用した取り組みを支える原則は守りながらも、独自の調整や適応が必要」なのです。これを踏まえなければ、「テック企業ではスクラムをやっていない」からといってスクワッド制に移行したところで、チームは依然として「ユーザーストーリーをバックログから取り出して実装するだけの機械」のままでしょう。
組織文化の重要性は、プラクティスとしての「Spotifyモデル」の発信をやめたSpotifyの、その後の動きからもうかがうことができます。
バンドマニフェスト
2020年2月7日、SpotifyのHR(Human Resources)Blogで"Our Band Manifesto"と題された記事が公開されました。署名はChief Human Resources OfficerのKatarina Bergです。少し長くなりますが引用します。
ここ1年ほどの間で気づいたことがあります。私たちはよく「Spotify流」という物言いをするのですが、それが具体的に何なのかをきちんと定義したことはありませんでした。その結果、他所の人たちが私たちのために定義を試みてくれたのですが、その成果はまちまちでした。オンラインで"Spotify culture"と検索すると、私たちのアジャイルプラクティスについての時代遅れの動画や、外部の視点から書かれたニュース記事が見つかります。私たちには自分たちなりの仕事の進め方があります。ですが、なぜそうなっているのか、なぜこれが重要なのかということをうまく説明できていませんでした。(中略)そこで私たちは先週「バンドマニ フェスト(The Band Manifesto)」を公開しました。(訳文と強調は引用者による)
「バンドマニフェスト ]」は「ここSpotifyでは、私たちは自分たちをバンドであると考えます」と冒頭に宣言し、Spotifyのミッションと5つのバリューを解説しています。その内容は、上記引用のブログ記述(Spotifyモデルの周囲への受容に対する当てこすり)から受ける印象とは異なります。Spotifyモデルを上書きして無かったことにするというよりは、むしろ本書での著者の主張をさらに推し進めたような内容になっています。上記のブログでもこのように述べられています。
急激な成長に向かう私たちにとって、自分たちの文化とバリューが何であり、社員にとって何を意味するのかを理解することがこれまで以上に重要になっています。これは私たちがフォーカスすること、モチベーションを保つこと、毎日の出社を楽しみすることに大きく貢献しています。(訳文は引用者による)
バンドマニフェストによれば、Spotifyのミッションとは「Spotifyは目的駆動の企業であり、強力なバリューと信念が私の戦略と日々の意思決定を導く」ことで、それを支えるバリューは次の5つです。
Innovate(革新する)
Sincere(誠実である)
Passionate(情熱を持つ)
Collaborative(協調する)
Playful(遊び心を持つ)
このマニフェストがHR(日本でいえば人事部に相当します)から組織の見解として公式にアナウンスされていることの意義も大きいと思います。テック企業は「テクノロジーとビジネスとを人為的に分断して悩んだりはしない」、ハイパフォーマンスなテック企業として成功するための「大統一理論」は「組織文化」である、といった本書のメッセージを裏付けているとも考えられるからです。
繰り返しますが、大切なのはスクラムかSpotifyモデルかというプラクティスではありません。重要なのはプラクティスを支える原則や、それを生みだす価値観のあり方、すなわち文化です。「文化が重要」なのです。
「会社の文化を変えるというのは手ごわい仕事だ」
「文化とは共有された暗黙の仮定のパターン」であるとScheinが『企業文化 改訂版:ダイバーシティと文化の仕組み』で定義していることを紹介しました。この定義は「暗黙の仮定とは、外部に適応したり、内部を調整したりといった問題を解決する際に組織が学習した方法である」と続きます。適応のために学習した結果が文化であり、そのおかげでその組織は存続している、ということです。つまり、組織の文化とはそもそも変えづらいものなのです。本文でも著者は「会社の文化を変えるというのは手ごわい仕事だ」と述べていますし、訳者たちも自分たちの経験からこれに同意します。
「自律、権限、信頼」やSpotifyモデルの運用、「いい感じの職場」といった組織文化のあり方を、本書では豊富な例をともにいきいきと描写してくれます。ですが、そこに到達する方法については、いくつかヒントを示しはするものの、具体的な進め方については「近道はない。でもやるしかないんだ」と身も蓋もありません。私たち組織文化の専門家でもない、ふつうのソフトウェア開発者にとっては、もう少し手がかりが欲しいところです。
そもそも組織の文化は変えられるものなのでしょうか。これについては『リーンエンタープライズ』の「11章 イノベーション文化を育てる」が参考になります(リーンエンタープライズ/ch11。結論からいえば、組織の文化を変えていくことは理論的には可能だそうです。この「訳者あとがき」でも引用したScheinを始めとした複数の識者の議論を紹介しながら、ハイパフォーマンス組織へと変容するためのフレームワークをまとめてくれており、心強いです。
組織文化の変容を進めていく具体的な手がかりとしては、本書のコラムで紹介されている書籍が取っかかりとしては良さそうです。マルケ艦長の『米海軍で屈指の潜水艦艦長による「最強組織」の作り方』は、権限を与え、自分たちで判断してもらうための取り組みの実際の姿が描かれています。考え方の変容を行動に移すことの難しさ、自律したチームを作る過程で感じるもどかしさがよく伝わってきます。本文で「こんなに恐ろしいことはない」と説明されている意味がよくわかりました。
ダニエル・ピンクの『モチベーション3.0 持続する「やる気!」をいかに引き出すか』は今や定番の一冊ですが、本書の読了後に改めて通読すると「自律、熟達、目的」をどう位置づけるかがテック企業の組織文化のあり方を左右することを確認できます(註2:ユニコーン企業のひみつ/訳者あとがき#60878cfa779721000001d484)。
つまり、結論としては「近道はない。でもやるしか」ありません。重要なのは「あらゆる『言い訳』を取り除くこと」だと著者は主張していますから、これもその一環なのかもしれません。その一方で著者は「私の予想では、従来型の職場であっても、スタートアップっぽい働き方はどんどん増えていくだろう。とにかく多くの人に求められているんだ」と楽観的でもあります。
ますますソフトウェアが重要になっていく時代です。著者が述べるように、本書を参考に日本でも「毎朝、仕事に行きたくなるような、全力を尽くしたくなるような、自分らしくいられるような、一日の終わりには満足して家路につけるような、そんな職場づくりにひとりでも多くの人が成功」してくれたら、いきいきと働けるテック企業が1社でも増えてくれたら、訳者としてこれ以上の喜びはありません。
註2: 訳者のkakutaniと著者とモチベーション3.0の関連をモチベーション3.0#60878c7b77972100002859bfに補足した。リンク先の動画も参考にしてほしい。
謝辞
編集をいただいたオライリー・ジャパンの高恵子さんに感謝します。原稿の遅い訳者のことを最後の最後まで辛抱強く見守っていただき、ありがとうございました。翻訳原稿のレビューに参加いただいた次の皆さんに深く感謝します(敬称略)。1syo、imaz、@katsuhisa__、okuzawats、TAZAWA AYAKA、yucao24hours、新井正貴、飯田勇人、伊藤いづみ、梅本祥平、かたぎり えいと、川崎真素実、北村大助、白土慧、杉村文美、新田智啓、濱口恭平(@tnzk)、濱崎健吾、平田守幸、増田謙太郎、三好秀徳、諸橋恭介、矢部剛嗣。皆さんからいただいたポジティブなフィードバック、指摘、そして半ば読書会のようにして行われていた本書の内容についての対話がなければ、本書はこのような形には仕上がっていませんでした。心から感謝します。
著者Jonathan Rasmussonに。素敵な日本語版まえがきや、翻訳中の訳者からの質問に迅速に答えてくれたことに感謝します。
2021年4月
島田 浩二
角谷信太郎
hr.icon
主な変更点
2021/5/20:
https://twitter.com/kakutani/status/1395195433056571392 言葉足らずだったので加筆
2021/04/27:
ユニコーン企業のひみつ/Errataの誤りの修正を反映(第1刷ぶん)
Scrapboxの記法に適応。引用を強調したり、脚注をリンクにしたり別ページにしたりした
本文からの引用である見出しをカッコでくくった
#『ユニコーン企業のひみつ』
hr.icon
https://gyazo.com/d6453a455cb93da90d05c7e64369f7ce
(画像はOGP用です。書誌は『ユニコーン企業のひみつ』を参照)