そろそろ、スクラムの先に進んでも良い - ユニコーン企業のひみつ を読んで
各所で話題の『ユニコーン企業のひみつ』（以下、本書）を読んで考えたことの言語化 note です。要約とかではないので、文脈が伝わりづらければ是非本書を読んでみて下さい。
大前提として、この記事で言及しているのは「僕のやってきたスクラム開発」であって、「みんなのスクラム開発」ではない。この記事は「僕のやってきた」ことに対する課題感や反省点を元にしたもので、スクラム一般に対する否定や批判ではないことを明記しておきたい。
ユニコーン企業のひみつを読んだ感想
読んだ感想はこんな感じ。
・アジャイルサムライに続く定番書になる予感
・ユニコーン企業の話しではなく Spotify の話し（副題にはそう書いてある）
・Google の事例じゃない、というだけで価値があるかも
・「1. エンタープライズはすでにウォーターフォールからスクラムに移行している」「2. エンタープライズはアジャイルといいながらプロジェクト型のマネジメントをしている」という2つを前提にしないと論旨が読み解けない部分がいくつかある。この前提に違和感を感じたとしても、本書の大まかな主旨は崩れないと思う
・『トライブの理想的な人数は、下限を40人』（本書 60ページ）とあるように、そもそもの規模が大きいし、優秀な人が集まっているからこそできる、という面は否定しきれないと感じる
・自立性と信頼については、鶏が先か卵が先かということを感じてしまう（本書の主旨としては信頼という鶏から自立性という卵が生まれる）
こんな感想を抱いた本書を読んで、僕は「もうスクラムの先に進もう」という決意を固めました。
「先に進もう」と思った理由
本書（あるいはこの記事）は「アンチ・スクラム」について書かれたものではないことをくれぐれもお伝えしたい。もしもそのように受け取られるとすると、おそらく本書の訳者後書きにある『ユニコーン企業ではスクラムをやっていない』（本書171ページ）という見出しが一人歩きしてしまう所為だろう。
ではスクラムをやらずにユニコーン企業はどうやって「なんだかうまいことやっている」のか。鍵は「自律、権限、信頼」であり、それらを可能にする組織文化こそが「ユニコーン企業のひみつ」だというのが著者の主張です。ということはスクラムはもう古くて、新しいやり方に変えていかねばならないのかというと、そう単純な話でもありません。
（171ページ）
それを踏まえても、僕は以下のように感じ、考えた。
・2014年に Certified ScrumMaster の資格をとってから試行錯誤したうえでの課題感が本書をつうじて言語化され、一定の解が自分の中で得られた気持ち。
・僕の個人的なライフワークとして、スクラムに変わる何かを実践して提示していきたいと思っていたし、今も思っているところに良い本に出会えた
・歴史あるものという点において学ぶべきことはいまでも多いけれど、2021年に原理主義的に適用するべきものではない、と改めて思った
・あくまで僕が自発的に「これはいいものだ」と広めることがないというだけで、僕が将来加わるかも知れないチームがスクラムをやっていて（かつ機能していれば）意を唱えるようなことはしないつもり
・スクラムをやるなら決められたフレームワークをしっかり守るという原理主義的な立場だったけど、もっとアレンジして良いんだよ派に改宗した、ということなのかも知れない
ベロシティという呪縛
スクラム開発の運用における KPI のひとつはベロシティ計測にあると思うけれど、Key Performance Indicator と呼ぶほど Key じゃないというか、ベロシティはあくまで中間指標であって、一番大事なのはユーザーに価値を提供できているかどうか。「ユーザーに価値を提供できたかどうか」を直接測定するのはすごく難しいのだけれど、「サービスを契約してくれるか」「お金を払ってまで使いたいと思ってくれているか」「長く・頻繁に使ってくれているか」「人に勧めたいと思ってくれているか」などなどの間接指標によって類推することはできる。スクラムにおけるベロシティはいずれにも遠すぎる。開発プロセスというユーザーに見えないところにあるものなので当然なのだが、中間指標の中間指標の中間指標、というくらいのポジションだろう。
ベロシティは中間指標であっても指標の一つであるし、そこからさまざまな情報を得られるので有用である、という見方もできなくはない。できなくはないが、サーバー監視におけるメモリ使用率のモニタリング程度の位置づけで、それは時として重要なのだけれど、僕たちはスワップがどのくらい発生しているか、ということを知りたいがために生きているのだろうか？ ベロシティの安定に心血を注ぐのは、まるで「何も起きていない凪こそがあるべき姿である」という無風主義者のそれみたいだ。
プロダクトオーナーは事業上の KPI を、スクラムチームはそれ以外の何か（例えばベロシティ）に責任を持つという構造も良くない。Accountability の所在としてはそれでいいけれど、Responsibility はチーム全員で持つ。本書では、事業上のKPIを「インパクト」としている。
スクワッドも計画を立てる。だが、計画そのものはゴールじゃない。テック企業が何よりも大切にしているのはインパクトだ。インパクトとは、仕事の結果が何らかの形で顧客の役に立ったという具体的な証拠のことだ。
（本書 38ページ）
ちなみに本書では「ベロシティはだめ」みたいなことは一切書かれていないのでこれはあくまで僕が独自に受け取ったことだ。基本的にエンタープライズのプロジェクトに対してスクワッドはこのように違う、という対比が本書には散りばめられている。（そしてどうやらエンタープライズ・プロジェクトはアジャイルによって実践されているらしい、というあたりが、冒頭に書いた留意するべき前提事項にあたる。この点はいまだに腹落ちしていない）
余談だけど、中間指標にしても、定期的に価値をデリバリーできているかに隣接しそうなデプロイメント頻度をメトリクスとするというのは良い筋なのではないかと感じる。『エンジニアリングのスピードを測る3つの重要な指標』とか。
コップから水が溢れていることを伝えるための手段
僕がスタートアップの成長フェーズにおいてスクラムが有効だと思っていたのは「ステイクホルダーに対して、開発者のリソースが限界に達していること」を伝えられると考えていたためだ。書いていて悲しくなってくる。数値で根拠を示さないとチームがサボっていないことを証明できないのだろうか？ PCの操作時間を記録して監視するディストピアのようだ。
実際、ステイクホルダーとの調整にベロシティは有効である。チームが毎週こなせるのは60ポイントで、このところベロシティは安定している。顧客からの要望で、2週間以内に追加機能を開発しないといけなくなったとする、どうやらその機能には5ポイントのコストがかかりそうだ。来週5ポイントを差し込むと、別の5ポイントは溢れることになる。ではなにをトレードオフにしよう？
ベロシティがないと、開発チームは65ポイントのタスクをこなすことになるだろう。深夜や週末の時間を使って。ベロシティは、コップから水が溢れていることを伝える手段として活用できる。結果的に溢れることを選んだとしても、溢れていることは伝えられる。つまり自衛手段であり、エビデンスでもある。いったいなにと闘って、何の裁判に備えて証拠集めをしているのだろうか。
スプリントよりも速く
しばしば、スプリント・サイクルはどのくらいが適切かということが議論にあげられる。チームよって1週間だったり2週間だったりする。本書ではリリース・サイクルについて「リリーストレイン」という説明がある。
リリーストレインとは、完成した機能のまとまり（バッチ）を、あらかじめ決められた間隔で定期的にリリースするプラクティスだ。頻度は毎日でも、隔週でも、毎分でも好きにしてかまわない。考え方の基本は、完成した機能はどんどんリリースしていくというものだ。あるリリースを終えたらすぐに、次の「列車」は駅を出発する準備を整え始める。
（113ページ）
これ自体は特に新しい概念ではないし、リリーストレインとは呼ばずに実践しているところも少なくないだろう。スクラムにおいてもスプリントの単位 = デプロイメントの単位 では必ずしもないのだけれど、「完成した機能はどんどんリリース」という考え方と「スプリントに定められた期間がある」という設計は相性が良くないと思っている。スプリントはあくまでレトロスペクティブの単位であるとすることもできるのだけれど。
専門性が細分化された世界で
スクラムの課題として、チーム全員が概ね同じ量・難易度のタスクをこなせることがある程度前提になっている、というものがある。優先順位づけられたバックログに対してメンバーによって対応可能・不可能があると優先順位がねじ曲げられてしまう。また、Aさんにとっては3ポイントだけどBさんにとっては12ポイント、ということが常態化すると、プランニングポーカーも意味を成さなくなってしまう。結果としてポイントの消化率にこれだけ差があるという事実を突きつけるには良いかもしれないが...。過去何度も、この前提をどのように実現するか、ということに苦心してきた。
とにかく、スクラムをやるうえでチームに均一性があったほうがベロシティが安定するということが起きるわけだけれど、バックエンド、フロントエンド、ネイティブアプリ、デザイン、データ分析... 単一の分野だけでも必要な知識が膨大になった今、市場に競争優位を生みだすのは均一なチームではなく、プロフェッショナルの協働である、と思う。領域ごとにスクラムチームをつくる、というプラクティスもあり得るのだろうが（Webチームとネイティブアプリチームとか）、スクラムの初期設計段階でこのようなことが想定されていたとは到底思えない。時代が変わったこと、変化したことを受け入れよう。
計画に従うことよりも変化への対応を、価値とする。
（アジャイルソフトウェア開発宣言）
おわりに : スクラムのその先で
この記事ではスクラムとの決別宣言みたいなタイトルを付けてしまったようにも感じるが、アジャイルやスクラムの世界の人々は僕の人生を間違いなく良いほうに変えてくれた。スクラムをやるべきではないかと問題提起してれた当時の同僚、 Certified ScrumMaster 研修の講師や同期生、それから出会ったアジャイルを愛する人々との関わりがなければ今の僕はないといっても過言ではないです。そうした出会いに感謝をしつつ、これからは提示されたプラクティスのない世界で、自分たちの型を見付けていこうと思いました。また会いましょう。
Cover Photo by KAL VISUALS
お読みいただいてありがとうございます。