背景・前提
※この記事は、社内で『ユニコーン企業のひみつ』を薦めるために書いた記事の転載です。mediumに書いていましたが、テックの話でもあるのでQiitaにも書きます。
「ユニコーン企業は書籍に書かれているようなアジャイルなんてやってない」の記事を読み、『ユニコーン企業のひみつ』という本が気になり、読んだ。
エンタープライズ企業の開発手法（アジャイル）と、Spotifyなどのユニコーン企業（※この本の独自定義なので注意）の開発手法や文化を比較するような内容だ。しかし、実際には上記のブログタイトルはややミスリードで、アジャイルと全く異なるわけではなく、実際には次のような内容である。
- （本の中では明言されていないが）アジャイルソフトウェア開発宣言にあるような価値観は踏襲しているので、アジャイルの発展型の一つだと思う。「チームや開発者に権限を！」というモチベーションで、XPに近い雰囲気がある
- しかし、一般的なアジャイル開発（特にスクラム）には即していない
- 開発手法の本ではなく、組織文化や制度についての言及も多い
- 従来のアジャイル開発を否定するものではなく、自律したメンバーが多い場合の発展型の一つで、使い分けが重要だと見たほうがよさそう
ただ、この本ではエンタープライズ企業でどういう文化が想定されているのかが明示されておらず、「え？結局どう違うの？」と思う箇所も多い。そのため一般的なアジャイル開発（主にスクラムガイド）と対比し、本の内容を整理し直し、最短で概要を共有することを目指す。
チーム体制の比較
開発チーム→スクワッド
開発チームはスクワッドと呼ばれている。強い権限が与えられており、「ミッションを与えて何をするかは自分たちで考える」という自律したチームのようだ。
よくあるアジャイルチームとの差分として、例えば以下のような差分が紹介されていた。
- スクワッドは自分たちで仕事を生み出す
- スクワッドは自分たちで作ったものをメンテナンスする
- スクワッドは自分たちで優先順位をつける
- スクワッドは自律している
- スクワッドは手を動かす人だけで編成される
トライブ、チャプター、ギルド（マトリックス組織に近い発想）で、チームのスケーリングの問題に対処している（が、この記事では詳しく触れない）。
プロダクトオーナー
スクラムのプロダクトオーナーと同じく、スクワッドの進む方向を決める。方向はプロダクト全体や会社の戦略と結びついており、「このプロダクトは何をすべきか」について、信頼のおける情報源になる。
- 技術に明るい（多くは元エンジニア）
- 「プロダクトセンス」にすぐれている
- 強いリーダーシップと交渉スキルを備えている
SpotifyにはPOTLACというマネージャーのグループがあり、スクワッドが「健やかであること」に責任を負っていた。POTLACはチャプターリード、アジャイルコーチ、スクワッドのプロダクトオーナーが所属している。ただし、訳者あとがきによると、プロダクトオーナーはスクワッド内に編入されたらしい。
スクラムガイドでは「（意思決定の）最終的な責任はプロダクトオーナーが持つ」と最終的にはトップダウンであるのに対して、Spotifyではスウェーデンらしい合意形成の文化で、「単独のリーダーを重んじる風潮がはびこらないように努めている」「時間がかかろうとも皆が納得するまで議論する」というサーバントリーダーの文化のようだ。
スクラムマスター→アジャイルコーチ
スクラムではないのでスクラムマスターはいないが、チームのアジリティ向上をコーチする目的のアジャイルコーチという似た立場の役割がいる。
かつてはチームに欠かせないコアメンバーで、社内の「文化大使」として重要な役割を果たし、編成されたばかりのチームの支援もしていた。ただ現在は相対的に重要度が減ったのか、チームのコアメンバーから外れ、チーム外部（POTLAC）に置かれているようだ。
プロジェクトマネージャー→なし
プロジェクト単位で仕事していないので存在しない。ただ、この役割の重要性が減ったわけではなく、プロダクトオーナーが担当している。
（特になし）→データサイエンティスト
一般的な企業に比べてかなり重要視されており、チームがデータを使ってプロダクトの意思決定を下せるように支援する。上級管理職に限らず、誰でもこうしたツールを使ってインサイトを得ることができる。
Spotifyでは具体的には次のようにしてチームを支援している。
- 収集するメトリクスを決める
- さまざまな形式のデータフォーマットを揃えてクリーンアップする
- ベストプラクティスを適用したり命名規則を整える
- 何を検証すべきかについての仮説を立てる
- 結果が統計的に有意であるかを判断する
- データを分析する
- レポート、サマリー、ダッシュボードなど、可視化の設定をする
イベントやツールの比較
プロジェクト→ミッション
そもそもプロジェクトで仕事を進めない。プロジェクトには以下のような欠点がある。
- 期間があまりに短い
- フィードバックの機会がない
- プロジェクトはあまりに融通が利かず、途中で新しい知見を取り入れる余地は多くない
- プロジェクトはチームが考える力を奪う
- プロジェクトが予定内に収まったかは重要ではなく、本当は価値のあるものに進んでいるかにフォーカスすべきである
その代わり、チームにミッションを与え、反復的に機能をリリース・メンテナンスする。例えば、Spotifyでは以下のようなミッションがあった。
- 新しい音楽を簡単に見つけられるようにする
- リビングルームを制する
- 朝の通勤のお供になる
また、予算（経費支出）については、プロジェクト単位で管理されておらず、強い権限をスクワッドが持っているようだ。
スプリント、タイムボックス→？？？
スプリントやタイムボックスについては触れられていない。「準備ができ次第すぐリリースする」とあるので、おそらく明確なスプリントタイムボックスが存在せず、（厳密な）カンバン方式に近いのではないかと思う。
本の中に「イテレーション」という単語が出てくるが、リリースする単位のことであってスプリントのことではない。
計画
スクワッドは計画を立てるが、計画そのものはゴールではなく、インパクトを重視する。インパクトとは、仕事の結果が何らかの形で顧客の役に立ったという具体的な証拠（新規登録数、MAUなどが挙げられていた）だ。
ふりかえり
Spotifyでは「継続的に改善すること」が重視されていた。構造化されたイベントはあり、アジャイルコーチは定期的にスクワッドのヘルスチェックやふりかえりを実施していた。
また、カンパニーベットやDIBBを参照することで、利己的な部分最適に陥ってないか点検する。
成果物レビュー
リリース前に「リリースに値するのか」とスクワッド自身が判断する。
バックログ(?)→カンパニーベット
カンパニーベット（Company Bet）という意思決定のツールがある。
2014年当時、Spotifyは会社が大きくなるにつれて、たくさんのメンバーが数多くの物事を進めているのに、重要な仕事が進んでいなかった。このため、「全社レベルでフォーカスを絞って、一度に取り組むことを少なくする」という方針を取った。
カンパニーベットとは、会社が取り組みたい重要事項を、終わらせたい順に並べたリストのことで、四半期ごとに設定される。ベットにはそれぞれ2ページの概要が説明されており、その1枚にはDIBBフレームワークが書かれている。
- Data（データ）: デスクトップよりスマホで音楽を聞く人が増えている
- Insight（インサイト）: 携帯端末がデスクトップを追い越しつつある。社内にはモバイル開発者がほとんどいない
- Belief（確信）: 全社的に「来たるべき状況」への最適化ができていない。この先、生き残れるかは「モバイルファースト企業」になれるかにかかっている。
- Bet（ベット）: モバイル開発者の採用を強化する。デスクトップ開発者向けにモバイル開発のトレーニングを始める。モバイルアプリの開発インフラへの投資を始める。
これにより全社で優先度を付けられ協力する話や、具体的な運用やコツも面白いが、引用するには多すぎるのでその目で確かめてほしい。
まとめ・考察
従来のアジャイルチームと違う箇所をまとめる。
- チームに強い権限が与えられており、各メンバーが自律している
- チームの合意を重要視しており、サーバントリーダーシップが求められている。ただしこれはスウェーデン文化の影響が強そう
- スプリントが（おそらく）無い
私の推測も入っているが、開発手法ではなく組織制度でカバーしている点もありそうである。
実はスクラムのスプリントで管理するのは、「プロジェクトを期間内で終わらせるのかチェックする」という意味合いがあり、そこを別の制度でカバーできれば必要ないと主張できるように感じる。つまり、以下のような設計思想があるのではないか;
- プロジェクト単位で組織を運営しない
- プロジェクトを期間内に終了させることを重視しないので、明確な見積もりやスプリントが必要ない
- 代わりにデータを使ったインパクトの計測や、カンパニーベットによる全社目標を使った見直しが発達している
この点が私にとっては衝撃だった。
また、組織文化としては以下のような点が印象に残った。
- 実験指向が強く、「データを重んじる文化」「失敗を受け入れて学ぶ文化」がある
- プロダクトマーケットフィットを目指す
- 技術が一級市民として扱われている
ただ、チーム体制はスクラムに近い部分も多く（アジャイルコーチとプロダクトオーナーがおり、かつてはアジャイルコーチがチーム内にいた）、組織としての熟練度が上がって変容していったようだ。
また、サーバントリーダーシップを重視する点はスウェーデンの文化を引き継いでいることが示唆されており、他の（特にトップダウン文化を持つ北米の）ユニコーン企業ではまた異なるようだ。そのため何の開発手法を採用しても、組織体制やチームの熟練度、プロダクトによって工夫・修正していく必要があり、ましてやSpotifyの方法が単純にスクラム開発を置き換えるものではないといえるだろう。
そして、開発手法も会社制度・文化の一部であり、どちらか片方ではなく、一緒に考えて作り上げなければならないものだと思う。
最後に”らしく”いきましょを添えて（開発手法を会社の文化に合わせて書きかえてるので）