どこにでもいるSEの備忘録

たぶん動くと思うからリリースしようぜ

「ユニコーン企業ではスクラムをやっていない」について考える

こちらの本が面白そうだったので、買ってみました。

この本を読むきっかけは、下記の内容が書かれていたからです。

スラムマスターがいないのは、ユニコーン企業ではスクラムをやっていないからだ。 ユニコーン企業のひみつ ―Spotifyで学んだソフトウェアづくりと働き方

この一文が個人的に非常に衝撃的で、この本を読んでみようと思った理由です。

今回はこちらの本を読んで個人的に思ったこと・考えたことのメモです。

ユニコーン企業はスクラムをやっていない?

昨今の日本では

  • 古き良きウォーターフォールではなく、スクラムにすべき
  • これからのプロダクト開発はスクラム開発でやっていく

といった論調が様々なところで見られます。 日本でこれだけ受け入れられているスクラムですが、当然海外でもその傾向は強く、本書でも

日本では読者によってまだアジャイルソフトウェア開発の需要に温度差があろうかと思いますが、原著で想定されている北米のソフトウェア開発では今やアジャイルソフトウェア開発プロセス(具体的にはスクラム)が主流です。 ユニコーン企業のひみつ ―Spotifyで学んだソフトウェアづくりと働き方

と紹介されています。 また、State of Agile Surveyによれば、調査に回答したうち58%がスクラムを採用しているとのことです。

stateofagile.com

そんなわけで、世界的に見ても今の主流はスクラムだという点は紛れもない事実のように思われます。

スクラムが採用される理由

なぜスクラムがこれだけ受け入れられているかについて考えてみると、それはアジャイルの数ある開発プロセスに関するプラクティスの中でも、スクラムは非常にわかりやすく、ある程度の実績・歴史がある点が考えられます。

スクラムはウォーターフォールに比べ、そのプロセスは簡素でわかりやすく、柔軟・高速に開発・学習を行うのに適応した形です。 スクラムでの開発では、いくつかのイベントやロールが定義・形式化されており、その進め方はさまざまなところに書籍や記事があるほど情報源が多く存在します。 こうした形式化された開発手法は、大人数で開発手法に関する認識をあわせる上で非常に重要で、全員が開発プロセスについて共通認識を持ちやすいという明確なメリットがあると思います。

特に、アジャイル開発をやったことがない組織がアジャイル開発に挑戦する際に、過去の情報が多く手に入るということは非常に心強く、不確実性に対して柔軟に対応する際に、先人の知恵を享受することが出来るため、比較的スムーズに導入できるかもしれません。 また、こうした実績がある手法は、それなりの規模の組織において、上層部に対して説明しやすい事からも好まれる傾向があるように思います。

なぜスクラムをやらない?

これだけのメリットが考えられるにも関わらず冒頭に示したように、なぜユニコーン企業がスクラムをやらない*1のかという点について考えてみたいと思います。 この理由については本書には特に明記されてないように見受けられましたが、個人的には「型が決まりすぎている」からだと思っています。

上で書いたように、スクラムにはいくつかのイベントとロールが定義されています。 これらは、基本的には必要最低限の取り決めに収まっているように思いますが、ユニコーン企業にとってはこの型に縛られることすら不自由に感じるから、スクラムを行わないのだと思ってます。

ユニコーン企業を始めとするスタートアップ企業が他のエンタープライズ企業と大きく異なる点は、顧客基盤も資金も持たず、資金が尽きる前に(あるいは投資家の支援が打ち切られる前に)プロダクトマーケットフィットを達成することが求められる点だと思います。 そのため、他のどんなことよりも優先してプロダクトマーケットフィットを達成することが優先され、結果としてそれぞれの組織で最も高速にフィードバックループを回せる独自のやり方になるのだと思います。

ここで一点補足すると、スクラムを採用しないだけで、アジャイルではあるということです。 本当の意味でのアジャイルを追求した結果、スクラムではない方法に落ち着いたという方が正しいと思います。

じゃあ、どうやってるか?

ユニコーン企業が、通常のエンタープライズ企業とは異なりスクラムを採用しないのには理由があるはずで、 本題のそちらについて考えてみたいと思います。

Spotifyで特徴的な話として組織の話がありますが、こちらの記事がわかりやすいのでこちらをご参照いただければと思います。

qiita.com

lean-trenches.com

なにを重視するか

Spotifyで特に重視されていたのは、スピードと学習です。 そして、これはSpotifyに限らず、他のTech企業でも同様でしょう。

「速く学習する」ということに対する価値観が強く、そのために意思決定が極端に短くなったり、組織構造がフラットになったりしているだけです。 とにかくスピードと学習を重視し、それらを最大限実現出来るように組織・制度が整備されていくわけです。

自律・権限・信頼

スピードと学習、これらを実現する際に、自律・権限・信頼がメンバーに与えられ、同時に求められます。 トップダウン的な意思決定ではなく、全員が共通の目標に向かい、それぞれのスクワッドのミッションを果たすためにボトムアップ的に意思決定がなされることが良しとされます。 そのために、個人・スクワッドには非常に大きな権限が与えられます。 それは、個人やスクワッドに対する信頼によって実現されているわけです。

こうして、ボトムアップ主導で組織が運営されることで、スクワッドが高速に学習していくわけです。 そこにはスクラムマスターは必ずしも必要なく、その役割をエンジニアが担っても良いわけです。 優先されるスピードと学習のために、最適と思われる形を取れば良いわけです。

仕組みは変わるもの

あとがきにもありますが、Spotifyの決まったやり方はありません。 そこにあるのは、スピードと学習を優先し、チームを最大限尊重し、個人を信頼し助け合うように、着実に醸成していった文化だと思います。

その文化を実現するために、組織構造や制度が変化していっただけのことです。 組織運営の仕組みや組織構造が変化していっているだけで、それらの根底にある文化は常に一貫しているように思います。 その時々で、ベストだと思われる形で組織運営をしているだけです。

結局のところ…

結局、ユニコーン企業だけが持っている、スクラムに代わる銀の弾丸があるわけではないということです。 そこにあるのは、それぞれの企業で醸成された明確な企業文化と、それを体現するために柔軟にカスタマイズされたアジャイルなやり方なんでしょう。 そして、そのやり方は現在であっても進化を続け、今もなお個別最適化されているわけですね。

言われてみれば、アジャイルには守破離の考え方があり、最終的には「離」にたどり着くので、個別の企業で独自の進化を遂げていると考えれば納得がいきます。 そうした背景から、学習が十分に進んで個別の企業に最適化する過程でスクラムから逸脱したやり方になっていった結果、「ユニコーン企業ではスクラムをやっていない」という状態になっているんだと思います。

感想

とてもおもしろい本でした。

Spotifyの企業文化・考え方から、それを実現するためにどのような組織を作って、それをどう運営しているかがわかりやすく描かれています。 今回は、こちらの本を読んで色々考えてみたことの頭の整理を記事にしてみた次第です。

なにはともあれ、まだ読んでいないという方はGWの読書にいかがでしょう?

Spotifyという企業の文化は、GAFAやNetflixといった企業ともまた違うように感じました。 社員を最大限に信頼し、スクワッドの意思決定を尊重する、社員全員でスクワッドや社員のサポートをする、そういった文化が根付いているように思いました。

また、こういった独自の開発スタイルをとっていく際には、人材戦略は非常に重要になるのかなと思います。 特に、価値観が共通化されていることが大前提だと思われ、その上で信頼や責任と権限の移譲によって開発が進んでいくと思います。 エンジニアにはスキルもそうですが、個人の考え方が組織に合っているかなどが、これからさらに重要視されていくだろうなと思いました。

いろいろ考えさせられることが多く、非常に勉強になりました。

*1:本書で言及されている、スクラムをやっていない企業は主にSpotifyであり、その他のテック企業が本当にスクラムを行っていないかの正確なところはよくわかりません