ユニコーン企業のひみつ

「ユニコーン企業のひみつ」という本を読んだ。

本旨は、成功したスタートアップ企業、所謂ユニコーンの開発手法や組織は、エンタープライズ系開発を主としている企業とは違うものですよ、という話である。そしてそれらの企業が具体的にどういうやり方で彼らのプロダクトを開発しているのかを書いている。

ちなみにタイトルにユニコーン企業とあるけれど、別にユニコーン（評価額10億ドル以上の未上場企業）に限った話ではなく小さなスタートアップからGoogleのような既に上場して随分経っている巨大企業まで共通した話だと思う。著者もとくに区別しているわけではなく単にSpotifyで働いた経験から書いたからそのようなタイトルにしたというだけみたいだ（Spotifyもすでに上場しているので厳密にはユニコーンではない）。まあスタートアップは立ち上げのタイミングでは組織も何もないので、タイトルにあるユニコーンというのは、一応ある程度の組織作りに成功したスタートアップ企業、もしくはそのようなスタートアップが巨大化して尚且スタートアップ文化を残しているような大企業のことを指している、というくらいの認識でいいのだと思う。

そうした「ユニコーン」のやり方について個別に掘り下げて書いてあるんだけれど、書いてあることはそれほど目新しいことでもなく、スタートアップで働いている人間からしたら当たり前のことばかりである。勿論やれていることもあれば、やりたいけどそこまでやれてないという事例もあるし、すべての事例がすべての企業で正解になるわけでもない。まあそれでも共通認識として大体こういう方向が正しいよねという認識はスタートアップで働いている開発者なら皆持っているんじゃないだろうか。著者はアジャイルサムライの著者でもあるのでわりとエンタープライズ系開発の方でキャリアを積んできた人なので目新しく映ったんだろうと想像した。

おそらくこの本が対象にしているのは従来型の大企業（本書ではエンタープライズ企業と呼ばれる）でアジャイル開発を推進している人たち向けに、スタートアップではアジャイル開発なんてやってないよという「驚きの事実」を伝えることを目的として書かれたんだろう。

そのこと自体はとても有り難い。ただ自分がスタートアップで働いていて常々苦々しく思っているのは、そもそもそれに驚くこと自体がおかしいのだ。「エンタープライズ企業」の人たちがアジャイル開発をスタートアップ的な開発スタイルと見なしている風潮は一体どこから来たのだろう？彼らが重厚長大なウォーターフォールにうんざりしているのは分かる。そのカウンターとしてアジャイルが勃興してきたのも理解できる。でもそれはエンタープライズ企業の中での話だ。スタートアップは無関係なはずである。

スタートアップ的なやり方としてアジャイルを紹介して、スタートアップのやり方を真似るべきだと言っているのは常にエンタープライズ企業やその周辺の人たちだ。スタートアップのやり方を肌で知っている人ではないのだ。そして勝手にイケてるスタートアップのイメージを膨らませて理想化して自分たちの開発フローを「アジャイル」にしようとする。

そこまではまだいい。問題なのはそうしたエンタープライズ企業出身の人達が「アジャイル」の手法をスタートアップに持ち込みたがることである。スタートアップに転職してきた人たちが「ここではアジャイルはやらないの？せっかくのスタートアップなのに？イケてないね」と言い出すことが問題なのである。

上でスタートアップではアジャイルなんてやっていないと書いたし本書でもそのように書かれているけれど、実はスタートアップでもアジャイルは随分侵食してきている。アジャイル開発を好む人達の宣伝能力は驚くべきほどである。だから、スタートアップならアジャイルをやるべき、という変なイメージへのカウンターに本書がなってくれるなら歓迎したい。だけど2021年にもなって今更こういう話をしないといけないのか、という辛さがある。

ちなみに自分がスタートアップにアジャイル開発は向いていないと考える理由のほとんどは、Steve Yegge（元Googleの開発者）の書いた、「いいアジャイルと悪いアジャイル」というアーティクルに影響されている。これが出たのは2006年の話だ。このアーティクルに書いてあるGoogleのような企業がどのように開発しているかという話と「ユニコーン企業のひみつ」に書いていることとは、具体的な方法論を詳細に書いているかどうかを別にすればほとんど同じである。

彼のアジャイルに関しての意見にもっと興味があるなら、「Egomania Itself」と「全部取り消すから金をくれ!」も含めて読むといい。

だいたいのアジャイル批判はそっちを読んでもらえればいいと思うけれど、自分がひとつ加えるなら、「スタートアップには反復型開発は向いていない」ということを挙げたい。大体のアジャイル開発手法は反復型開発を含んでいるため事実上「スタートアップにはアジャイル開発は向いていない」とも言えると思う。

なぜ反復型開発はスタートアップには向いていないのか。それはスタートアップが本質的に価値を置くのはプロダクトではなくサービスだからだ。つまり企業として何かを提供している「状態にある」ことがその企業の目的だからである。プロダクト開発を主とする企業であっても、成果物を提供し続けることが目的である。だからスタートアップにおいてこれを達成すれば終わりというゴールはない。成功するのではなく成功し続けることが目的なのである。

この違いを本書では「プロジェクト」と「ミッション」という言葉で区別している。

プロジェクトにはその定義により、始まりと終わりがある。だから、終わりがくれば、プロジェクトはそこまでだ。

テック企業では、プロジェクトが予定の±10%に収まったかなんて誰も気にしない。そんな質問に意味はないからだ。

ミッションとは、チームに与えられる、抽象度が高めの目標だ。ミッションの役割は、チームの仕事を企業レベルの大きな目的の達成に向けて方向づけることにある。

本書ではプロジェクトは反復プロセスを回さない、ミッションではイテレーションをし続けると書いてある。著者としてはミッションでやっていることもアジャイル開発のやり方と同じですよと言いたいのかもしれない。しかしここで言う「イテレーション」とは反復型開発のそれとは決定的に違う。反復型開発では必ずゴールが設定されるからだ。そして定まったゴールに対して工程を立て、それを分解してイテレーションにする。イテレーション中に設計を修正することがあってもそれはゴールに近づいているかどうかで判断され、ゴール自体が動かされることはない。

一方スタートアップの開発にはこれを達成したら終わりというゴールはない。サービスが成功し続ける限り、改善のサイクルを回していく。その過程でサービスの定義や価値も動的に変わっていく。本書においてミッションの目標として例示されているのは以下のようなものだ。

テック企業はプロジェクトではなくミッションを使って仕事を定義する。

たとえば、Spotifyではこんなミッションがあった。

● 新しい音楽を簡単に見つけられるようにする

● リビングルームを制する

● 朝の通勤のお供になる

これらはゴールではない。つまりそれを達成したら開発は終わり、チームは解散してプロダクトはメンテナンスモードに入る、というようなものではない。だからそもそも反復型開発のように（あるいはウォーターフォールのように）ゴールが設定されていることが前提の開発手法は使えないのである。

ただし、現実的にはスタートアップでもプロジェクトが組まれるときはある。つまり、大きめのタスク、例えばある新機能を開発する必要があるが、その工数がスタートアップとしてはとても大きくて例えば複数メンバーをアサインして半年とか2年とかかかる、といったときには例外的に反復型開発が機能するかもしれない。

ただしそのような場合に反復型開発を導入したとしてもアジャイル開発のようなスタイルにするのは無理だろう。つまりその反復型開発フローは大きなタスクを消化するために一時的に導入されるものだからだ。だからプロジェクトメンバーは固定ではないし、プロジェクトが終わればそのやり方は継承されない。そもそもチームとその大きなプロジェクトの従事者は一致してないかもしれないし途中で抜けたり入ったりするかもしれない。

そこでアジャイル推進者がやりがちなのは「チームがやること」を一つのプロジェクトにしてしまおうと言い出すことだ。これは最悪でチームが持っているばらばらのタスクをアジャイル開発のフローに乗せるためだけの擬似的なプロジェクトを作り出すからだ。しかしチームのバックログは常に更新され追加されるので反復型開発のための定まったゴールは持ちようがない。そこで往々にしてでっち上げられるのが季節目標というプロジェクトである。つまり今季達成すべきタスクの束をバックログから引っ張り出してそれを「プロジェクト」と呼び出すのである。当然プロジェクトの目標はプロジェクトに含まれるタスクを消化することになる。そして作られたプロジェクトバックログの山からチームメンバーが各々タスクを消化してフィードバックではどれだけタスクを消化出来たかを（あるいはなぜ消化できなかったかを）振り返るのだ。これはもはやアジャイル開発ですらなく、形だけそれに似せるための何かである。

そもそもの間違いはゴールのない開発にむりやりゴールを設定しようとしたことにある。

僕は別に反復型開発が間違いだと言うつもりはない。ただそれが適している開発プロセスとしていないプロセスがあり、スタートアップ的な開発はほとんどが適していない方に入ると言いたいのである。だからスタートアップで反復型開発をやろうとしている人は上のような問題点がないかをよく考えてほしい。

スタートアップでアジャイル開発をやってうまく行っているという話を僕はあまり聞いたことがない。例外的なケースとしては、スクラムのようなフルのアジャイル開発は諦めて、「アジャイル的な」要素を部分的に導入するといったケースだ。

しかしそれは本当に「アジャイル的」なのだろうか？開発プロセスにおいて自分が重要だと考えているのは、バックログ管理とPDCAサイクルを小さく早く回すことである（他にもあるが話が発散してしまうので省く）。これらはアジャイル開発でも重要かもしれないがアジャイル開発に特有というわけではない。アジャイルという宗教には明確な教義がないのでアジャイル開発から邪魔なものをいくら抜いても残ったものをアジャイルだと言い張ることができる。

YeggeのEgomania Itselfに以下のようなくだりがある。

私が十代の頃、父と兄のマイクがホームメイドのチリを作ろうと決めた。私はチリを作っているところを見たことがなかったので、彼らが牛肉や豆や野菜やスパイスや、そのほかの材料を加えていくのを、強い興味を持って眺めていた。父は味見して、もっと材料を付け加え、少し待って、また味見した。父はあるすごくいいレシピを持っているのだ。父が戸棚を開けて、ホーメルのチリソースの缶を2つ取り出して、ふたを開けてぶっ込んだのを見たときに、私がどれくらい困惑したか想像できるだろう。

私はしばらく間を置いてから、なんでチリに缶詰のチリを加えたのか聞いてみた。父も兄もひどい味だったからと答えた。今や有名になった父の発見は、「犬の糞から始めても十分なチリを加えればチリになる」ということだ。

同様に、アジャイルメソドロジーから始めても、十分な努力を注げば、多くの仕事をやり遂げられるのだ。考えてみて。

これはこれで見事な比喩だ。しかし自分はもう一つ例を付け加えてみようと思う。それは、チリソースに水を足して無限に薄めていけばいつか真水になる、ということだ。同様にアジャイルも無限に薄めていけばいつか失敗する要素はなくなり「成功したアジャイル」にすることが出来る。しかしそれはアジャイルの成功例にカウントすべきだろうか？

ここまで結構アジャイル開発に対して辛辣な意見を述べてきたかもしれないけれど、自分はアジャイル開発があらゆる点で駄目だとは思っていない（そう言い切れるだけの経験がない）。ただスタートアップ的な開発には適していない可能性が高いと言いたいだけである。エンタープライズの人たちがアジャイル開発で盛り上がっていることについては、それが遠い世界の話である限り否定すべきでないと考えている。

だから「ユニコーン企業のひみつ」が成功したスタートアップ発の企業たちがそのような開発をしていないと示してくれただけでもすごく嬉しいし、また別の開発プロセスを用いて彼らが成功していることにはすごく勇気づけられるのである。いままで自分はあまり公の場でアジャイル批判をしたことはないのだけれど、この本が後押ししてくれたのでこの記事を書くことができた。そのことには感謝したい。