いいアジャイルと悪いアジャイル

スクラムはラグビーにおいて最も危険な段階であり、それというのも、潰れたり不適切なかみ合い方をすると、前列のプレーヤーが怪我をしたり、首の骨を折る危険すらあるからだ。—Wikipedia

私が子供の頃には、コレステロールは体に悪いものだった。これは覚えやすかった。脂肪は悪い。コレステロールは悪い。塩分は悪い。みんな悪い。しかし近頃では、コレステロールが「いい」コレステロールと「悪い」コレステロールに分かれている。私たちがこの2つをどうにかして見分けられるとでもいうように。そしてその切り替わりは奇妙なものだった。FDAが突然プレスリリースを発表して、殺鼠剤には2種類、いい殺鼠剤と悪い殺鼠剤があり、いい方はたくさん摂って悪い方は摂ってはならず、そして決して2つを混ぜたりしてはいけないのだと言ったかのようだった。

一年くらい前まで、私はいわゆる「アジャイル」プログラミングに対して、ごく一次元的な見方をしていた。すなわち、それはマーケティングのペテン師によるばかげた一時的ダイエットであり、「銀の弾丸はない」を読んだことのないうぶなプログラマや、延長保証や自己啓発本を買ってボスは自分のことを人として心から気にかけてくれると信じているようなプログラマや、友達を作ろうとカンファレンスに参加し、空港でチラシを配っている狂信者とアイコンタクトを避ける方法を知らず、インデックスカードに書き散らすことでソフトウェア開発が突如として易しくなると信じているようなプログラマに、また新たなテクノロジーウィルスを植え付けているのだと思っていた。

ああ、間抜け。それが私が探している言葉だ。私の悪いコレステロール観は、アジャイル方法論は間抜けのためのものというものだった。

しかし私は最近、実践されているアジャイル主義の様々な変種を観察する機会があり、今では自分は90%くらいしか正しくなかったと思うようになった。いい種類のアジャイルもあるということが分ったのだ。スクラムやそのほかのものをめぐるあらゆるハイプとへつらいと熱にうかされた呻きにまぎれ、はっきりと見極められるようになるのにずいぶんと時間がかかった。しかし今ではすごくはっきりとわかるようになった。

そしてあなたは私のセミナーに大特価の499.95ドルで参加できる! ハッハッハッ。間抜け!

冗談だよ。見つかるのは悪い種類のアジャイルのセミナーばかりだ。もし私がいつかアジャイルコンサルタントとして講演してまわって、私のアジャイル開発に対する深い知恵と洞察を聞こうという聴衆からお金を取っているのを見かけたら、私のタマを切り落としていい。あれは冗談だったと私が言ったなら、私がそう言うだろうと言ったと言えばいい。それに対して私が自分はタイラー・ダーデンで、私のタマを切り落とすなと命ずると言ったなら、私がそう言うだろうと私が確かに言ったと言って、即座に切り落としてかまわない。

私はすぐに話を進めて、いい方についての話をタダで教えてあげる。

いいアジャイルと悪いアジャイルを切り離して話すのはちょっと難しい。だから一緒に話すことにしよう。いい方には幸せなネズミ、悪い方には惨めな死んだようなネズミで印をつけておくので、いつでもどちらの話をしているのかわかるはずだ。

悪い方の話

かつては、ほとんどの会社がソフトウェア開発に次のようなアプローチを取っていた。

- たくさんのエンジニアを雇い、それからさらに雇う。
- プロジェクトを考えつく。
- リリースしたい日を設定する。
- エンジニアをそのプロジェクトに割り当てる。
- 彼らが死ぬか、プロジェクトが完成するか、あるいはその両方となるまで、彼らをむち打つ。
- ちゃちでつまらない打ち上げをする(かもしれない)。このステップは省略可能だ。
- 最初に戻る。

そういうのがあなたの会社で、今起きていないなら感謝することだ。やれやれ!

面白いことに、これは非技術系の会社(たとえば、クライスラーとか)がソフトウェア開発を処理していた方法でもある。違うのは、彼らはエンジニアを雇わなかったということだ。かわりにソフトウェアコンサルタントと契約し、そのコンサルタントに2年間のプロジェクトの仕様書を渡し、すべてを期限までに終わらせ、かつ、顧客が投げ込んできたクズと、契約後にした変更をすべてやることを要求した。それからプロジェクトは破綻し、請け負った人たちは支払ってもらえず、みんな本当に腹を立てることになった。

そのためコンサルタントたちはこんな風に考え始めた。「なあ、企業が子供みたいに振舞い続けるというのなら、連中を子供として扱おうじゃないか」。そしてそれを実行した。企業が「機能AからZまでがほしい」と言うと、コンサルタントたちは例の大きなインデックスカードを取り出し、最初の1枚にAと書き、2枚目にはBと書き、と言う具合に、機能を見積もり付きで書き込んでいく。そうしてそれを壁に貼り出す。そうすると顧客が何か追加したいと言ったときに、コンサルタントは壁を指差して、「OK、じゃあどのカードと交換しようかな、僕?」と言うことができる。

それでコンサルタントたちは、今度は主要な顧客を失うことになってしまい、バーでくだを巻いていたら、あるとき、彼らの1人(L・ロン・ハバードという名前の男)がこう言ったのだ。「この1行いくらという仕事は割に合わないよ。本当の金がどこにあるのか知っているだろう? 自分の宗教をはじめなきゃ」。そんなふうにしてエクストリームプログラミングとサイエントロジーは始まった。

人々はほどなくXPがごみの山であることを示すことになった。たとえばペアプログラミングだ。これはXPの中でも特にひどく失敗したもののひとつだ。アジャイル主義者もこれについてはあまり話したがらない。それを誰もやってないという事実から目をそむけないことだ。ペアプログラミングの論拠はこういうことだった。「端末の前に座る1人のプログラマが良いなら、10人はもっといいはずだ。多い方がいいに決まっている! しかし端末の前には2人のプログラマしか座れないから、これをペアプログラミングと呼ぶことにしよう!」

彼らを少し大目に見てやらなきゃいけない。彼らは幼稚園児同様の企業をずっと相手にしていたのであり、それは本当にわずらわしいことなのだ。

しかしそいつは、ウィルスというやつは殺すのが本当に難しく、ミームのたぐいは特にそうだ。みんながこのアジャイルというのに夢中になり(みんな間違いなく、より生産的になりたいと思っている)、失敗を認めることで面子を失う人がたくさん出た。それで別な種類のアジャイル「メソドロジー」が現れ、他のが全部駄目でも自分の方法はうまくいくのだとみんな主張していた。

そういう人たちのサイトを覗いてみるといい。インフォマーシャルじゃないのがあれば教えて欲しいものだ。ほら、試してごらん。見るのさえ気恥ずかしいよ。

そう、確かに彼らは大もうけしているが、それはちょうどサイエントロジーと同じことで、P・T・バーナムの法則のためなのだ。彼らを批判することはできない。ある人たちは、お金も尊厳も投げ出してどうしても入りたいと思う。

そういう人たちを別にすれば、アジャイル方法論がばかみたいだというのはみんな知っており、それは次の良く知られたマーケティングの法則を適用すればわかることだからだ。

- 一般論として、自ら「方法論」と称するものはすべて間抜けだ。
- 「エバンジェリスト」を必要とし、セミナーを提供しているものはすべて、もっぱら金儲けのために存在している。
- 競合や代替となるものについて決して触れることのないものは、私利的である疑いがある。
- 一般論として、ダイアグラムとお手軽な計算式を使うものは間抜けだ。

ここで「間抜け」と言っているのは、「間抜けな人たちをターゲットとする極めて優れたマーケティング」という意味だ。

いずれにせよコンサルタントたちはつやつやしたパンフレットを作って巡業し続けた。最初私は、彼らが企業を追いかけているのだと思っていた。「何でもいい」から「2週間」で作ればいい、というような融通の効く契約の兆候を探し、クライアントが破産するまでそれを繰り返すのだと。しかしそんな契約にサインするほどばかなクライアントは、そうたくさんは見つからないだろうとも思っていた。

そしてその時こそ、コンサルタントがその巡業先を開発者たち変える時だ。企業の中に入って行って開発者に売り込んだらどうだろう? 前に述べた鞭打ちサイクルで開発している企業はたくさんあり、ミドルマネージャやテクニカルリードの中には、その地獄のような境遇から抜け出せる安上がりな方法があるという話を素直に聞いてくれる人もいる可能性は十分にある。

そしてこれが、まさに彼らが「害のない馬鹿」から「潜在的な危険性」に変わった瞬間だ。以前は彼らは頭が悪くて自分のソフトウェアを開発できない企業から金を騙し取っていただけだが、今では廊下で私とすれ違うマネージャが影響を受けるかもしれないからだ。そして多くの場所では、この厄介な状況を隔離できるあまりいいメカニズムが存在しない。本来は頭のいいマネージャが「病気にかかり」、XPの本とインデックスカードを振り回し、この新発見になる余計な官僚主義で自分のチームがいかに生産的になったかとまくし立てるのだ。

より生産的になってはいないと、どうして言えるだろう? そう、これは扱いにくい問題なのだ。扱いにくい問題に違いなく、そうでなければ今頃はすっかり暴露されていたはずだ。しかしよく知られている様々な理由により、ソフトウェア開発の生産性の測定というのはきわめて難しい。ソフトウェア開発に対して有効な科学実験みたいなことをするのは、さらに難しい。同じプロジェクトを同じチームで2回行うことはできない。2回目のときには多くのことが変わってしまうからだ。2つのチームに同じプロジェクトをさせることもできない。あらゆる変数をコントロールするのはあまりに難しく、またそのような試みはどのような場合であれ高く付きすぎるからだ。同じチームが2つの異なるプロジェクトを続けて行う場合というのも、やはり実験にはならない。

できることと言えば、たくさんのプロジェクトをやっているたくさんのチームについて統計的なデータを集め、類似性の同定を試み、ある種の回帰分析を行って、何らかの意味のある相関関係が見出されることを期待するくらいのものだ。しかしデータはどこから持ってくるのか? 企業は、仮にそのようなデータを持っていたとしても、内部データを提供しようとはしない。およそありそうにないことだ。彼らはスケジュールの失敗を隠し、どこまでも楽観的に進み続ける。

実験することができず、証明することもできないなら、あまり科学的とは言えない。それが扱いにくい問題だという理由だ。一時的なダイエットにすごく人気があるのも同じ理由だ。人々は一時的なダイエットに効果があることを期待する。そのはずで、私だって効果があって欲しいと思う。そしてあの統計的に意味のない「ジョーはこの方法で35ポンド痩せました」という事例を取り上げることができ、どうしても痩せたいと思っている人たちは、「なに、別に害があるわけじゃなし、ちょっとやってみよう」と思うのだ。

これはまさに開発チームがアジャイル方法論を試してみようという話をするときにみんなの言っていることだ。別に偶然ではないのだ。

しかし悪いアジャイルについてばかり書いているのは効果的ではないだろう。サイエントロジーがいかに説得力がないかとか、一時的なダイエットがいかに効果がないかと書いたところで、それで誰かの気持ちを変えられるかはわからない。バイラルミームをやめるのは、タバコをやめるのより難しいのだ。私はどちらもやり遂げたが。適切なインパクトを与えるためには代替案を示す必要がある。しかし私ははっきりと示せるようなものを、以前には持っていなかった。

悪いアジャイルの(たくさんある)問題の1つは、彼らが非アジャイル開発をすべて見下して、ウォーターフォールとカウボーイの2種類に分類していることだ。ウォーターフォールが悪いことはよく知られている。このことは今日では自明の理と認めてもらえることを期待したい。しかし、いわゆるカウボーイプログラミングについてはどうだろう? アジャイルの人たちはこれを「チームのメンバがそれぞれ自分で一番良いと思うやり方でやること」と定義している。

他に開発プロセスはこれしかないというのは本当なのだろうか? そしてカウボーイプログラミングは実際悪いものなのだろうか? アジャイルの人たちは明らかに悪いかのように言っているが、それがなぜ、どのように悪いのかははっきりとは説明しておらず、ただそれは「カオス」なのだと決めつけている。

前に言ったように、この一年私は悪いアジャイルといいアジャイルの両方について、実践されているところを観察し、チームやテクニカルリードから(いい方法と悪い方法のどちらも使い)いろいろ聞く機会に恵まれた。どんな風にやっているのか、どんな風に感じているのか、プロセスはどう機能しているのか。私は本当に興味を持っていたのだが、それはある部分では、去年のクリスマスにそれを試してみることに同意し(「別に害はないって!」)、インデックスカードに書くメタデータが正確に何であるべきかチームメートと議論になり、うんざりしてやめてしまったという経験をしたためだ。これはまた、デスマーチと見えるプロジェクトで憔悴しているチームに友達がいたためでもある。そのようなことはGoogleではあまり起こらないように見える。

だから猛烈に勉強し始め、この一年の間に観察し、学んできた。

いい方の話

Googleのソフトウェア開発プロセスについて少し話そうと思う。これはもちろん全体像というわけではないが、今日のところはこれで十分だと思う。私はGoogleに来てほぼ1年半になり、少し時間がかかったが、今では分かるようになった気がする。だいたいのところは。私はまだ学んでいる最中だ。しかしこれまでにわかったところをお教えしよう。

高いレベルでは、Googleのプロセスは、もっと伝統的なソフトウェア開発会社の人から見ると、たぶんカオスのように見えるだろう。新しく入ってきた人には、次のようなことが目に付く。

- 一種のマネージャはいるが、彼らのほとんどは少なくとも時間の半分はコードを書くのに使っており、テクニカルリードに近い。

- 開発者は、自分のチームやプロジェクトを、いつでも好きなときに、何も聞かれることなく変えることができる。ただそうすると言えば、運送屋がやってきて翌日には新しいオフィスで新しいチームと働くことになる。

- Googleには開発者に何をやれと言わない哲学があり、開発者たちはそのことをとても重く受け止めている。

- 開発者は20%の時間(これは週末や個人の時間にということではなく、月-金、8-5時の間でということだ)を、自分のメインのプロジェクト以外でやりたいことに使うよう強く促されている。

- ミーティングがあまりない。平均的な開発者はたぶん週に3回くらいのミーティングに参加し、これには自分のチームのリーダーとの1対1のものも含まれる。

- 静かである。エンジニアは1人で、あるいは2-5人の小さなグループで、静かに自分の仕事に集中している。

- ガントチャートや、日/タスク/担当者が書かれたスプレッドシートや、そのほか何であれ、目に見えるプロジェクト管理を示すものは見たことがない。

- 比較的まれなクランチ期間においてさえ、みんなランチとディナーは食べにいき、それは(良く知られている通り)いつも無料で美味だ。そして自分でそうしたいというのでない限り、ばかげたくらい長時間働くようなことはない。

これはもちろん一般化している。長くいる人は若干違った見方をしているだろう。私のAmazonに対する見方が、それがまったく狂った場所であった1998年にそこにいたということによって若干バイアスがかかっているのと同じことだ。しかしGooglerたちの多くは、私の一般化がごく正確なものだと認めてくれると思う。

私は何度もそう聞かれた。私自身聞いてみた。エンジニアがみんなトラブルプロジェクトやバグだらけのシステムの運用の悪夢から逃げ出すのを止めるのは何か? 何でも好きなことをやれるというときに、会社のゴールに向かってエンジニアを働き続けさせるものは何なのか? どうやって最重要プロジェクトが適切に人員を確保できるようにしているのか? エンジニアが太りすぎて戸口に引っかかり、消防隊に救出してもらう羽目にならないのはなぜか?

最後の疑問に簡単に答え、それから他の疑問に答えることにしよう。簡単に言うと、私たちにはNoogler^*1 Fifteenと呼ばれるものがあり、これはFrosh^*2 Fifteenをもじったものだ。多くの大学一年生は、ストレスとピザの国に降り立つと15ポンド太る。Googleは戸口に油を塗ることでこの問題を解決している。

そのほかの疑問については、少数の同じことが答えになっていると思う。

最初に、そしておそらく最も重要なのは、Googleがインセンティブで行動を促しているということだ。重要なプロジェクトで働くエンジニアは、平均では、重要性の低いプロジェクトで働くエンジニアよりも多くの報酬をもらう。誰のためにも実用となりそうにない突飛で研究的な類のプロジェクトで働くことを選ぶこともできるが、その場合仕事は自分で報酬を生み出す必要がある。あなたが正しくて他のみんなが間違っていたことが分ったなら(これはスタートアップの夢だ)、あなたの小さなプロジェクトはすごく大きなインパクトを持つようになり、あなたはそのことで報われることになるだろう。間違いなく。

報酬とインセンティブは、ここで話すにはあまりにたくさんあるが、金銭的なインセンティブということで言うと、商品券やマッサージクーポンから巨大なボーナスと無償増資まであって、「巨大」を正確には定義しないが、Googleのスケールを考えれて、想像を少たくましくしてみれば、それほど大きくはずすことにはならないだろう。

他の種類のインセンティブもある。1つはGoogleがピアレビュー指向の文化であり、ここでは同僚の尊敬が大きな意味を持っているということがある。他のどこよりもそうだと思う。これはある部分では単にそういう文化だからとしか説明できない。早い時期に生まれ、根付いたのだ。それにまた同僚たちがまったくもって頭のいい連中なので、彼らの尊敬を勝ち得るというのはすごく大きなことなのだ。そして勤務評定もほとんどピアレビューに基づいてなされるため、間接的な金銭上のインパクトがあるのも事実だ。

もうひとつのインセンティブとして、四半期ごとに欠かすことなく行われている全員参加のイベントがあり、そこではローンチされたプロジェクトの1つひとつが全員に紹介され、そのローンチを行った(常に小さい)チームのメンバの顔と名前が映し出されて、みんなから喝采を受けることになっている。私は考えただけでもぞくぞくする。Googleはローンチを重要なものと考えており、何かクールなものをローンチしたと認められることは、この会社で最も強いインセンティブなのではないかと思う。少なくとも私はそう感じている。

さらに他のインセンティブもある。このリストはどこまでも続いていく。臨時手当は過度であり、報酬は過度であり、そこにあるすべてがおかしなくらい過度で、部外者にはリクルーターの言うことが真っ赤な嘘にしか聞こえず、それは一個の会社がすべての社員に対してそんなに気前よくできる方法があるとは思えないからだ。すべての社員というのは、マイクロキッチンの掃除をする契約社員まで含めてということで、彼らはすごくかっこいい「Googleマイクロキッチンスタッフ」シャツとフリースをもらえる。

そんな場所はこの地上に他にない。Googleで働くことがどれほど驚くべきことか話し出したら、何時間、何日話し続けても止まらないだろう。そして彼らも止まることがない。毎週のように、新しい手当や、特典や、改善や、それにGoogleでの生活をよりよくできる方法が何かないかと全員に聞くアンケートがある。

私は実のところ間違っていたかもしれない。四半期の終わりに大きなスクリーンに自分の名前と写真が表示されるのは最大のインセンティブでないかもしれない。Googleで適切な行動を駆り立てるのは、他の何よりも、他のすべてを組み合わせたよりも大きいのは、感謝の念だ。Googleのために最善を尽くそうとせずにはいられない。それほどまでに気遣ってくれる相手に対し、借りがあるように感じるのだ。

インセンティブについてはいいだろう。どんなものか分ったと思う。いくらかは。つまり、その概観はつかめただろうということだ。Googleで働いていない友人にGoogleで働くのはどんなかと聞かれたなら——これは私が働いたことのある会社に限らず、Google以外の会社にいるすべての友人たちにも同じように当てはまるのだが——私はこんな風に感じる。刑務所からちょうど出所したところで、刑務所の中で友達になった、10代のはじめから服役している人たちが手紙をくれて、彼らは「外の生活」はどんなかと聞いている。あなたなら、そういうときに何と答えるだろう?

私ならこんな風に言うだろう。そんなに悪くないよ。まあ文句は言えない。全体としてすごくまともだと思う。

インセンティブに基づく文化というのが、Googleを動かす上で大きな要因となっているのは確かだが、それはどうやってエンジニアに「適切」なことをさせるかということに関わっているだけだ。いかにしてそれを効率的に、効果的に行うかというのは別な話だ。だから彼らのプロジェクトへのアプローチの仕方について少し話すことにしよう。

創発性対ムチ

プロジェクト管理の基本的なアイデアは、プロジェクトを完結に向けて推し進めるということだ。これは顕在的なプロセスであり指導ということだ。リーダーシップの力と、組織力と、全くの意志の力によって、自然には起らない何かを起こすということだ。

プロジェクト管理には、軽量のものから重量のものまで、様々な趣のものがあるが、共通しているのは、組織に対して働く外部的な力だということだ。

Googleでプロジェクトが立ち上がるのは、それがシステムにとってもっとも低いエネルギー状態だからだ。

先に進む前に、これが甚だ大胆な主張で、完全に正しいわけではないことを認めておこう。私たちのところにもプロジェクトマネージャや、プロダクトマネージャや、人事マネージャや、テクニカルリードそのほかの人たちはいる。しかし彼らがシステムに与えなければならないエネルギー量は、私たちの業界で通常必要とされるものよりはるかに少ない。継続的に全力で押し続けるというよりは、ときたま突っついて合図するというのに近い。時にはチームにもっと大きな突っつきが必要になり、そういうときは、他の組織と同様、上級のマネジメントがやってきて突っついてやることになる。しかし押されたりすることはない。

ついでながら、Googleは礼儀正しい会社で、怒鳴ることはなく、泣き叫んで歯ぎしりすることもなく、エスカレートして指さし合うこともなく、上級マネジメントがよく怒鳴っているような会社に見られるものは何もない。ホッブスが組織はリーダーを反映すると言っている。私たちは皆そのことを知っている。Googleのトップにいる人たちは礼儀正しく、だから他のみんなもそうなるのだ。

ともかく、プロジェクトを立ち上げることはGoogleの内部的なエコシステムにおいては自然な状態なのであり、それはプロジェクトが1つの方向を示して多くのエネルギーがそこに注ぎ込まれるようにするからだ。開発者に必要なのは、プロジェクトに集中できるように面倒を見てやることだけであり、前に言ったように、Googleが気に入ることに集中することへのインセンティブはたくさんあるからだ。

だからこのシステムではプロジェクトは自然に発生するようになる。

このことにより、標準的なプロジェクト管理におけるアイデアや方法の多くは必要でなくなる。怠け者の扱いとか、はったりの見積りの実行を迫るとか、共有デザイン上の問題にコンセンサスを求めるとかいったことは必要なくなるのだ。「戦争チームミーティング」は必要なくなり、状況報告も必要なくなる。それが必要ないのは、彼らがすでに適切なことをし、共同して働くことに対するインセンティブを持っているためだ。

Googleのやっているプロジェクト管理のテクニックは、燃料よりはオイルに近い。プロジェクトを前に推し進めるための強制力ではなく、プロジェクトがスムーズに動き続けられるようにするものということだ。ミーティングルームはたくさんあり、おしゃべりができるオープンスペースもたくさんある。チームは金魚鉢スタイルの自由席で集まって作業しており、ペアプログラミングはまさに必要なとき(5%くらいの時間)に行われ、必要がなければ行われない。

Googleでは、静かな会社であっても1日の真ん中あたりの時間帯には邪魔が入りがちなものであると一般に認識されていて、多くのエンジニアは稼働時間をずらし、とても早く来るか、あるいは遅くまでいることで、プログラミングに本当に集中できる時間を確保できるようにしている。だからミーティングは1日の中間の時間帯にしか行われない。午前10時前に始まるミーティングや、午後4時半以降に始まるミーティングというのは滅多にない。この時間帯の外にミーティングをスケジュールすると、そのミーティングの対象となっているものをエンジニアが実際に作る時間に食い込んでしまうので、そうしないのだ。

Googleがプロジェクトをこのような仕方で運営している唯一の場所というわけではない。Googleのアプローチを考えるとき、私の頭に浮かぶ他の組織が2種類ある。スタートアップと大学院だ。Googleはスタートアップと大学院のメンタリティを融合したものと思っていい。一方には、さあ急ごう、何かを世に出そう、できるだけシンプルに動くものを作り、後で成長させよう、というスタートアップスタイルがある。もう一方には、我々は誰も解いたことのない難しい問題に取り組んでおり、それは短距離走よりもマラソンに近く、激したミーティングではなく深い集中が必要になるという、比較的リラックスして抑えた雰囲気がある。そしてこれら2つに共通しているのは、スタートアップも大学院も豊かなイノベーションの下地を持っており、参加者が結果に対して大きな個人的責任を負っているということだ。

そういったことは今までにもなされてきたことだが、Googleの本当に驚くべきところは、それをスケールさせているということだ。

このスケールしているということは偶然ではない。Googleはこの問題に実に熱心に取り組んでおり、ここまでスケールしてこられたということが、この先もスケールし続けられることを保証しないのをわかっている。だから彼らは用心深い。これは褒め言葉だ。彼らは自分たちの成長とともに、社内の生活のあり方や、全体の生産性のレベルが保たれているか(あるいはいっそう向上しているか)、常に目を配っている。

Googleは、ソフトウェアエンジニアの視点から見たとき、際立って統制のとれた会社だ。彼らはユニットテストや設計ドキュメントやコードレビューといったことを、私が聞いたことのあるどの会社よりも真剣にやっている。彼らは自分たちの環境が常に整理されているよう熱心に働いており、どこかのエンジニアやチームが自分勝手な方法でやらないようにする厳格なルールやガイドラインが実施されている。結果として、コードベース全体が同じように書かれ、チームを変えたりコードを共有したりすることが、他の会社でよりもずっと簡単なことになっている。

エンジニアはもちろん優れたツールを必要とするので、Googleは自分で使うツールを作るために優れた人々を雇っている。彼らはエンジニアたちに、その方面への興味があればツール作りに協力するように(インセンティブを使って)奨めている。結果として、Googleは世界でもトップクラスの優れたツールを手にしており、それは改善されつづけている。

このリストはどこまでもつづく。Googleのソフトウェアエンジニアリングへのアプローチの背後にある驚くほどの厳しさについてなら何日でも話せる。しかし一番言いたいのは、彼らが(技術的にも組織的にも)スケールしているのは偶然でないということだ。そしてひとたびGoogleのやり方に慣れたなら、すべて苦もなく進めていけるようになる——再び、平均として、他の多くの会社におけるソフトウェア開発と比べればということだ。

カレンダーの専横

話はほとんど済んだ。最後に話しておきたいと思うのは日程についてだ。伝統的なソフトウェア開発は、ほとんど例外なく、日程指向プログラミングと呼べるだろう。

スタートアップには投資家と予算によって定められる時計がある。大きな顧客企業はコンサルタントに目標とする日を設定する。セールスの人たちとプロダクトマネージャはマーケットの状況の評価に基づいて定めた目標日を設定する。エンジニアは以前にやった似た作業から導いた見積によって日程を設定する。見積りはすべてバラ色の眼鏡を通して行われ、前にやったときどれくらい苦労したかをみんな忘れている。

みんな日程を何もないところから持ってくる。「これは3週間くらいであるべきだという気がする」「第4四半期の始めまでに顧客に届けられれば都合がいい」「がんばって明日までにやろう」

私たちの業界ではほとんどの人が日程ドリブンで動いている。常に次のマイルストーンがあり、常に締め切りがあり、常に日程ベースのゴールがある。

1) オープンソースソフトウェアプロジェクト
2)大学院のプロジェクト
3) Google

日程を決めるのは当たり前のことだとほとんどの人は思っている。私のお気に入りのソフトウェアプロジェクトマネジメントの本である「人月の神話」でさえ、スケジュールの見積りが必要であることを前提としている。

作っているソフトウェアについて前もってアナウンスする習慣があるなら、一般の人々はそれがいつ頃になるのかを知りたいと思い、それは日付ということになる。私の考えでは、これがGoogleが前もってアナウンスをしないことが多い理由なのだ。いい料理を手早く作ることはできず、赤ちゃんを手早く産むことはできず、そしてソフトウェア開発を手早くやることはできないということを彼らは知っているのだ。

これらの3つの例外が日程によって駆動されているのでないなら、何が彼らを駆動しているのか? ある部分では、それは創造への欲求であり、何かを作りたいという欲求だ。すぐれたエンジニアがみんな持っているものだ。(私たちの業界には、この仕事を「生活のため」にやっており、家に帰ったら次の日まで考えもしないという人たちが多い。オープンソースソフトウェアは、それよりましな人たちがいるからこそ存在している。)

しかし注意しよう。創造への欲求がすべてではない。それは必ずしも十分な方向付けがなく、必ずしも十分なインセンティブとならない。Googleも間違いなく時間によって駆動されているが、それは彼らが「可能な限り早く」ものごとを成し遂げたいと思っているという意味でだ。彼らにはたくさんの恐ろしい、頭の切れる競合がおり、成長を求める投資家たちの渇きをいやす必要もある。そして私たちの1人ひとりにも、人生の時間の中で達成したいと思っている長期的なプランや成果がある。

違うのは、Googleは物事にどれくらいかかるか分っていると主張するほどばかでも傲慢でもないということだ。会社全体にかかわる日程として私が気付くものとしては、四半期の終わりがあるだけだ。あの大きな画面に出て、喝采と贈物とボーナスとチーム旅行そのほか、Googleにとって大きなインパクトのある何かをローンチすることに伴ういいものを手に入れようと、みんなが先を争う。

間にあるのは、ただ日々の連続だ。その間みんな、それぞれにとっての最適な生産性で働いている。私たちは仕事と生活のバランスを自分で選択することができる。Googleは理にかなった選択は受け入れられ、報いられるような場所なのだ。最適な生産性はまた、トレーニングの賜でもある。Googleはトレーニングを山ほど提供しており、毎週内外の講演者によるテクニカルトークが何ダースも行われている。それらはすべて恒久的にアーカイブされており、いつでも好きなときに見られるようになっている。Googleでは仕事を成し遂げたり、仕事の仕方を学ぶために必要なリソースは何にでもアクセスできる。それから最適な生産性は作業するマシンやコンテキストにも依存する。コードベース、ツール、ドキュメンテーション、コンピューティングプラットフォーム、チームメートのクオリティ、それに1日に過ごす時間のクオリティさえ、生産性に影響する。そのために食事の提供や多くの時間を邪魔されずにいられることが必要になる。

あとあなたに必要なのは作業キューだけということになる。それで全部だ。何か気の利いた計算式が欲しい? 私は以前待ち行列理論でモデル化されたソフトウェア開発というのを勉強したことがある。そんなに的はずれでもなかったが。私たちの業界の人の多くは、組織モデルがソフトウェアモデルに似ていることに気付いている。

作業キュー(もちろん優先度つきだ)さえあれば、アジャイル方法論の魔法の利点だとされていることの多くは即座に達成できる。そして間違わないで欲しいのは、それはインデックスカードの山ではなく、ソフトウェアに入れた方がいいということだ。納得できないというなら、あなたのインデックスカードを取ってしまうから。

優先度つきキューは、プロジェクトが進むにつれて人々から出てくるあらゆるアイデア(それにバグ)を投げ込むゴミ捨て場のような場所だ。このキューが空(これは定義により、プロジェクトが完了されたことを意味する)にならない限り、どのエンジニアもアイドル状態になることはない。タスクを保留したり再開したりするには、単に適当なメモやドキュメントをつけてキューに戻すだけだ。どれだけの作業が残っているのかいつでも分かり、望むなら残っているタスクに基づいて時間を見積ることもできる。クローズされた作業アイテムを調べてバグの回帰率から(望むなら)個々人の生産性まで、様々なことを推定できる。何のタスクがよく見送られるかわかり、これは組織における苦痛の原因を見つける役に立つ。作業キューは完全に透明なものであり、作業がだぶって行われるリスクはほとんどない。

残念ながら、作業キューはセミナーやカンファレンスで人を呼べるいいマーケティングツールにはならない。あんまり見栄えがしない。それは作業の山のようにしか見えないのだが、それは実際その通りだからだ。

悪いアジャイルについてもっと詳しい話

私は高いレベルでの概要について説明した。ある会社のソフトウェア開発へのアプローチは、アジャイル方法論でもウォーターフォールサイクルでもなく、カウボーイプログラミングでもない。それは小文字のaではじまるアジャイル(agile: 素早い)だ。Googleは早く動き、早く反応する。

私が言ってなかったのは、良いソフトウェア開発プロセスの上に大文字のアジャイル方法論を被せたらどうなるかということだ。あなたはこう考えるかもしれない。「まあ、別に害はないだろう!」私自身、去年ちょっと試してみたくらいだ。

手短に言うと、それは害になる。もっとも苦痛な部分は、自分のチームにアジャイルを選ぶテクニカルリードやマネージャが、状況の現実に盲目になるということだ。悪いアジャイルはいくつかの仕方でチームに害を与える。

第一に、悪いアジャイルは最悪な仕方で日程に集中するものだ。短いサイクル、短期の成果物、頻繁な見積りと再見積り。サイクルの間隔はひと月(これはまだ許容範囲だ)から、最悪の場合1日にまでになりうる。そういうのは理想主義的な世界の見方だ。

現実世界においては、プロジェクト関係者の1人ひとりが人間であるということがわかる。私たちには調子のいい日も悪い日もある。ときにはエネルギーが満ちあふれ、18時間ぶっ通しでコードを書けると感じる。ある日には、エネルギーはあるが、コーディングに集中する気にならないということもある。ある日にはすっかり疲れ切っている。みんな生物時計とバイオリズムを持っており、それについて自分ではほとんどコントロールすることができない。そしてその時計は、チームの時計が日とか1週間の半分といった単位で動いている場合には、チームの時計とずれがちなものなのだ。

個人的な時計については言うまでもない。仕事以外の生活でも様々な出来事が起り、仕事時間中に注意を向ける必要が出ることもある。

これらはどれも悪いアジャイルでは問題とされない。大きな納品のあと、気持ちが高揚していても、狂ったようにコーディングしようとはしないだろう。次の大きな全力疾走に備えてエネルギーを貯めておく必要があるので、少し安静にしていようと思うのだ。このインピーダンスミスマッチにより、優れたエンジニアが並の働きしかできなくなる。

課外活動時計というのもある。それは自分のメインプロジェクトとは別に成し遂げたいと思うことで、たとえばソースのクリーンアップやその他のことだ。これは最終的にはチーム全体の生産性を向上させる。悪いアジャイルはこれの扱いがはなはだまずく、大きなマイルストーンの後にみんながサイドプロジェクトの作業ができるように時間を取るのをやめてしまう。彼らがクリエイティブに感じるか感じないかにお構いなしに。悪いアジャイルの連中はいつもゴールを見続けており、それはイノベーションを損なうことになる。確かに、彼らも各自が自分のコードベースをクリーンアップするための時間は取っておくかもしれないが、みんな会社の他の人を助けようと思うほど利他的ではない。実質的に日々遅れている状況が永続するというときに、どうして他の人を助けるなんてことができるだろう。

悪いアジャイルは、何かの理由で早起きの人に歓迎されるようだ。「夜明け前に起きる」「静的型付けは好きだが、型推論は嫌い」「偏執的なほどに系統立っている」「チームミーティングが好き」といった性格傾向と、「悪いアジャイルが好き」だということの間には、何か神秘的な関連があるように思える。それが何なのかはっきり分らないが、そういうのを多く目にする気がする。

エンジニアのほとんどは早起きではない。週に少なくとも一度(通常数回)朝8時のミーティングに出なければならないチームというのを知っている。そのあと彼らは昼までメールを開いたままゾンビのように座っている。それから家に戻って居眠りをする。夜になって働きに出てくるのだが、充血した目をしており、いつも疲れ切っているように見える。彼らに話しかけると、通常十分に陽気なのだが、しかしいつも言葉を最後まで言い終わらない。

彼らに(個々に)、アジャイルアプローチが好きかと聞いてみると、彼らはこんな風に答える。「うまく行くように思えるけど、ある種のしきたりが破られているような気がする・・・」。「よくわからない。何かを試みようとしているんだとは思うけど、何の意味があるのかよく分らない」。すべて新しいものであり、はっきり意見を言うことを恐れており、問題を起こしているのがアジャイルなのか、あるいは会社のあり方なのかさえ、誰も確信を持っていない。

これは(小文字の)「アジャイル」ではない。ばかげているものの山にすぎない。そしてこれは、いつであれ、どこであれ、誰かマネージャが間抜けになろうと決めたときに手にするものなのだ。

いいアジャイルは、その名前を捨てるべきだ

- 「彼が説明したいい部分は、本当にアジャイルだ」
- 「彼が説明した悪い部分は、チームがプロセスの実施に失敗したのだ」

こういうのをよく耳にするだろう。私はアジャイルに関する本をたくさん読んでおり(自分が扱っているものが何なのかはっきり分るのに十分なだけ読んだ。それはウィルスだ)、そして他の人々のアジャイルに対する批判もたくさん読んだ。アジャイルが批判をかわすときには、上に挙げた2つのようなスタンダードな戦術を使う。何であれいいものは手柄にし、何であれ悪いものは認めないのだ。

あるプロセスに良いものである可能性があったとしても、90+%の場合に頭のいい善意を持った人たちが失敗するなら、それは悪いプロセスなのだ。本当はチームのミスではないのに、チームのミスなのだと言っているだけだ。

私は「アジャイル」という用語に懸念を感じるようになった。今や過剰に使われ過ぎている。いい開発者はこの言葉とその含むところをすっかり避けるようにした方がいいと思う。「アジャイルプログラミング」の2つの形態について話したが、(まったくちゃんとした)第三のものがあり、それはテクノロジーを使って生産性の向上(つまり「アジャイル性」)を達成しようとするものだ。「Ruby on Railsによるアジャイル開発」とか、「アジャイルAJAX」とか、あるいは「アジャイルC++」というのまである。これらは私の持っている本の中でもごくしっかりしたものなのだが、「アジャイル」という言葉の乱用に拍車をかけている。

そして巷にあふれるアジャイルの多くは、率直にいって悪いアジャイルだ。

だから私がもしあなただったら、履歴書からアジャイルという言葉は取るだろう。スクラムやXPの本は静かに閉じ、どこかにしまい込む。タスクはバグデータベースか、そのほかの作業キューソフトに入れて、インデックスカードはゴミ箱に捨てる。自分の組織からアジャイルを消すべく可能な限り速やかに動く。

しかしこれは単に私の意見だ。それにもう朝の4時になる。好きなように結論を引き出すといい。どちらにせよ、私は明日早起きはできそうにない。

そうだ、私は注意書きを書き忘れるところだった。私はGoogleを代表して話しているわけではない。これらの意見は私個人のもので、彼らが私のブログを見たら、あなた方同様に驚くことになると思う。それが「誕生日のサプライズ」のような驚きであって、「野生のサイがびっくりさせられた」というようなのではないことを願っている。ではまた!