この記事は、.NetRocksの1160話 No Estimates with Woody Zuillの書き取りと、日本語訳です。2015年7月2日放送。
- 使ったもの (tools used)：Express Scribe & Music to Code by
- 翻訳にあたってCarl Franklin氏の了承は頂きました。
- リスナーの投稿とか、CarlとRichardのBetter Know Frameworkは飛ばして、ゲストインタビューのみ。
- 日本語化してない、英語音声書き取りメモは、まんまここにおいてます。
- 太字は訳者が、声の大きさとかスピードから、特に強調されていると思ったところです。これは主観なので、そう感じない人がいたらごめんなさい。
Carl Franklin（以下C）Woody は30年以上プログラミングやっていて、ハンター・インダストリーでアジャイル手法のコーチやアプリケーション開発のマネージャーをしている。ハンターインダストリーは、革新的な灌漑システムを作っている会社だ。彼のチームはモブ・プログラミングを最初に始めたチームだよ。チームワークとソフトウェア開発の分野では、ウディはTwitterでの「見積りしません」運動の創始者といわれている。15年以上もアジャイル手法のコーチや、アプリケーション開発、教師や、エクストリームプログラミング手法ををやってきた。彼の信条は「コードはシンプルで、維持しやすなければいけない」。
アジャイル手法がそれを実現する方法で、開発者は常にコードを見て、それにかなったアジャイルを取り入れていかないといけない、と信じている。また、彼はブルーズギターのフラットピッキングがうまいんだ。って、僕は知っているよ！ Woody、また会えてうれしいよ。
Woody Zuill: （以下W）こちらこそ君のギターをみれてうれしいよ。言うの忘れてたんだけど、転職したんだ。今はインダストリアル・ロジックで働いている。エクストリームプログラミングのトレーニングをやっている会社でJosh Kerievskyが創始者だ。
C: バイオ、変えておくね。
W: ハンターインダストリーで働いた時間はとても貴重だったと思っているよ。チームにどのように働いたら一番いいかを探求する時間をもらえたらからね。これってとてもパワフルなことだと思う。
R: ハンターはTechの会社じゃないよね
W: じゃないよ。Techの会社じゃないけど、Techと関わる製造業だ。灌漑とかスプリンクラーとか、照明とかね。「革新技術を基盤とした建築」ってのが、スローガンだよ。彼らは「革新」に重点を置いている。
R: ハンターインダストリーがいいところは、開発においていろいろ実験する余裕をあたえるところだよね。彼らが使うソフトウェアの開発でね。
W: そう。いろいろな技術を使っているよ。僕のチームはソフトウェアをやってたんだけど、素晴らしいチームメイトに恵まれたよ。けっこう大きなリリースを年に数回やってて、様々なプロジェクトに関わってて、僕でもいくつだかわからないくらいだよ。10か、もうちょっと多くのプロジェクトだったかな。
小さなところからすぐにリリース
W:プロジェクトの計画を立てるとき、僕らは普通どのような機能があるべきか、を考えるよね。そこで僕好きなやり方ってのがあって、最初に何か価値のあるものはその中でどこだろう、と考える。その小さな部分をすぐにリリースする。こうやっていくとすばらしい結果になるよ。だって、皆が価値のあるものに向かって常に開発しているんだ。プロジェクトのことを知らないまま、誰かが最初に思い込んだことに、開発者が振り回されないですむ。プロジェクトの最初の頃は、誰だってそのプロジェクトのことは知らない。それなのに、いつも大きな決断をするように迫られてしまっている。
期待が一定で変えられない
C:そういえば・・・どう言ったら元顧客に失礼にならないように言えるかな？
W:ははは。
C:とある顧客がいたんだけど、その顧客はプロジェクトのアップデートをしばらくしてなかった。かなり保守的な人たちで、誰を信用したらいいか分からないって感じだった。だから、よく知っている人で信頼できる人を探していたんだね。その人たちのために、最初にできる簡単なことをみつけて、家に帰ってすぐにやっちゃったんだ。ちゃちゃっとね。で、その顧客に渡したら、大パニック起こしてね。結局ひどい結果に終わったよ。
W:ははは。そりゃ悲しいな。
C:「こんなに早くにできるわけない」って。信頼を失ったらしい。
W:おもしろいね。期待してる頭って変えられないってことを示している。僕たち人間は一定ものが一定であることを期待する。それで、物事がその通りで無いと、それを受け入れるのがとても難しいんだね。
C&R:うん。
W:こういうの何回か見たことあるけど、ある程度騙さないといけないんだよね。似たような状況で、ちゃちゃっと仕事終わらせた。
でも「１－２週間後に終わります」って返したよ。
C&R:ははは。
W: だって、すぐにできたよっていったら、彼らにとって信じられないと思ったからね。魔法でもなんでもないのに。
C:「どっかでダウンロードしてズルしたんだろ」って思われる。
W: だから顧客が期待することよりも、あまりにも多くのものを返してしまうと、ショックが強すぎるんだ。Carlがその顧客との関係がうまくいかなかったと聞いて残念だよ。だってこれからずいぶんいい関係になれたかもしれないのに。
C: 彼らによってはね。僕はいいや。
W: ほらね。
R: 傷ついちゃって（笑）。
W: こういうのが「見積もりしない手法」ってのと関連しているんだよ。あまりに早いサイクルで開発してしまうと、見積もりすること自体が意味なくなってしまうんだ、で、逆方向に期待がいく。で、あまりに早く終わってしまうと、次に何をしたらいいのか考えないといけない。車の運転と同じだよ。あまりに早く方向転換をすると事故を起こしてしまうだろう？すこしずつこっちかあっち、と普通は調整をするもんだ。でも、時々完全に方向を変えないといけない時もある。
プランによる束縛
C:うん。
W:でも、そういうことはできないよね。時間を6か月費やしてしまったことは、そうそう後に戻れない。
R:プランを作ると、そこから逃れられなくなるっていう副作用じゃないか？
W:そこが根本的な問題だね。アイデアはもう既に・・・
R:プランにあるという。
W:そう。プランにあるって考え方で、もう決めたことだ！という。最初にこういう風に決めたから、進めるうちに皆の成果は最初に決めたことによって決まってしまう。
R:計画以外のことができない。
W:そう。
R:早くできるところも、遅くいかないといけない。
W:自分で実現してみせる予言だよね。ちょっと6か月より上回るかもしれないし、それよりちょっとだけ早いかもしれない。でも大幅に6か月より早く終わってしまうと、ダメなんだよね。
どの種の見積もりから無くしていけばいいのか
C:僕はこの０見積もりって考え方にすごく興味そそられるんだけど、一方で絶対無理じゃないかとも思っている。
何か商談相手にあげないとさ・・・雇ってくれないだろ？
W:じゃあ、これははっきりさせておかないといけないね。ここで言っている見積もりは、小さな特化したものだよ。ソフトウェアを作る仕事に関したもので、（０見積もり手法は）ここから始められる思う。
プロジェクトにどのくらいかかるとか、この機能やこの仕事の塊をやるのにどのくらいかかるか、2週間以内にこれをやろうとか。そういった見積もりのことを話しているんだ。
でも、大きな見積もりで、どのくらいの経費がかかるとか、そういった大きな見積もりは、ゼロ見積もりの話にはかかわってこない。
たとえば、よく繰り返しやる、次の年の予算が決まって、6人のチーム内で、どのくらいのコストがかかるかとか、誰かを雇うとか誰かが辞めるだろうとか、そういった見積もりはできるよ。どんなコンピューターを買わないといけないとか、何が一番適したコンピュータだろうとか、OSのアップグレードはあるだろうかとか、そういったことは過去5年の例で見積もりができる。
R:見積もりはほぼ人件費の見積もりだよね
W:今の例では、実行可能性の話だから、そうだね。賃金だね。
R:それも調整させられるよ。見積もりを出せば、どのくらい出せるか教えるよ。みたいな。
W:そうだね。どのくらいのソフトウェアが書けるかというのとは別問題だ。
C:ほぼ同じだよ。
「ソフトウェア開発は、発見の連続なんだよ。」
W:でもね、ソフトウェア開発は、発見の連続なんだよ。
R&C: うん。
W:で、発見の連続は、「どのくらい机の数が必要か」ってほど、はっきりと分かりやすいものではない。
C:そうだね。一つのものをこっちからあっちに動かしているだけじゃ、発見とはいえない。
W:ウェブサイトもさ、今は設定だけでちゃちゃっと作れるだろう？でも昔はウェブサイトを作るだけでもHTMLを書いたりして、それがもし動的なものだったりしたら大きなプロジェクトだった。それってもう、解決したよね。だから同じコードをいつまでも繰り返し書く必要はないんだ。一度、何かをそうやってうまくまとめてしまえば、もう見積もりは必要ない。
R:鍵になるのは、速く顧客の手元に届けられるのだから、見積もりは時間の無駄だと？
W:そう。つまりそういうことだね。その仕事をはじめるまえにその仕事について知っていることを基にして
仕事の見積もっているのであれば、その仕事について一番知識がないときにその知識を使って見積もっているんだ。
じゃあその見積もりはどのくらい役に立つものなの？っていう。
R&C:だね。
W:もっと拡大していうと、たとえば3か月の何かがあって、元々これだけのことをやらないといけない、と考えてたとする、けど、やっているうちに、そのうちどのくらいの仕事が実際やらないといけないのか、どのくらいの新しい仕事をやるようになったとか、いくら正確な見積もりをやっても、実際に仕事に手を付けてみたら、最初の見積もり時のアイデアはどんどん変わっていってしまうものなんだ。
C:そうだね。まったくだ。
全体から非結合した部分の価値を証明する
R:これって、開発チームがどれだけ業務を知ってるっているか、によるんじゃない？その固有の業界ならではの知識とか。
W:ああ良い洞察するね。僕が好きなやり方は、たとえば、十分小さい仕事かどうか、ということではなく、どのくらい理解できるか、というところを重要視することなんだ。あともうひとつは、この部分はほかの部分と非結合できるか？というところ。この部分的な仕事はそれのみでできるのか？もうやってしまったところからの非結合、ではなく、これからやりたいところからの非結合、という意味で。
R:そうすれば、それだけの部分での価値を証明できるから？
W:そう。その価値を証明できるから。この部分的な仕事は、その価値を証明できるか？ もしそうだったら、そのままその部分だけでも顧客の手に渡せる。
これが動画だったら僕が笑っていることが見えてしまうね。そうなんだ。皆、見積もりができると思っているところが、ほとんど滑稽だよ。見積もりの価値の話をしているんじゃなくて、この問題では、見積もりの次の話をしているんだ。
R&C:そうだね。
ソフトウェアの価値
R:面白いことに、いつも見積もりを欲しがるのは、開発者じゃない。
C:そうそう。僕たちにはどうでもいい。
W:ソフトウェアの価値はあまりに誇大評価されていることが多い。資金を得るためにね。で、後になってそのソフトがちゃんと使われてから、コストをコントロールしようとする。それでソフトウェアの価値を本当に提供できているのだろうか。
R:むしろ ウェブのeCommerceなんかだと、収入モデルを作りやすいかもね。サイトを作れば2倍プロセスが速くなったりするから、そのまま2倍の収入として反映できる。速さが重要な場面では、顧客はもっと買う。こんな場合は価値を証明しやすい。そうすると予算もとりやすい。でなければ完全な成長停滞をみたりするんだから。そりゃ、3か月ぐらいは導入後からの影響を待つ必要はあるだろうけど、それは最初の変化の兆候だけで、本当に元が取れるまでは6か月くらいかかるのかな・・・。
W:ソフトウェアがすべてそれくらい簡単に価値が分かるといいよね。なかなかそうはいかないのだけど。
R:いやもちろん。そうはうまくいかない。
W:価値を測るのが難しいんだ。Russel Acuffだったかが言ってたことには、「管理者たちは彼らが測りたいものを測れないので、測れるものに限定して欲しいと考えることを覚えた。」
でもって、人生自体がそういうもんじゃないか？人の一生で素晴らしいものというのは、測れるものではない。
C:それは全くその通りだ。
W:で、これってもっと拡大できないかな？ 僕たちは感覚で素晴らしい価値を感じるべきで、素晴らしい価値を測るべきではないと。それってできるかな？ けっこう多くの会社が実践していることだと思うよ？
R:そうだね。
ここでStackify の宣伝
せっかく書いたのに使われないのって凹む
R:ソフトウェアのInstrumentationとかって、今感覚でわかる価値がどのように動いているかってことを分からせてくれるものなんだね。
W:それで思い出したことがある。実際に何か動いている状態になっていないソフトウェアでは、何かの価値を測ることはできないんだ。僕がいたプロジェクトの中で、3か月か6か月で顧客に渡ったし、トラッキングもできていると、使用法もわかると。でも誰も使っていない。
R:わかる。
C:誰がこのソフト作れって決定したの？
R:書くとかの以前の問題で。
C:これがどうなるかとか考えて。
R:それってホントに開発者のメンタルに影響するんだよね。
W:うん。
R:(使われるかどうかは）大事なところだから。
W:そうだね。
R:書いたんだから、生かしてもらいたいよね。
一スプリント後の見積もりなら、どう？
C:いい点だと思うよ。「どのくらい作るのにかかるか？」って聞いてきたら、「一週間後に聞いてくれ」って返すとかどう？
W:ああそうか。
C:単純にさ、スプリント一周終わったと、これだけのことが残ってます。これだけのことをやりました、と、でここから大きな計画に持っていくと。そうするとより良い見積もりを得られて、スプリントを重ねるごとにその正確さが増すんじゃないかな。これってどうだろう？
W:それも一つの方法でいろいろな人が使っているよ。僕のアプローチとは違うけど。なぜこの方法使わないのかというと、最初も言ったけど、ソフトウェアにおいてはどのくらいの仕事がなされるか、分からないからなんだ。たとえばこの50の仕事をするとする、2つを一週間でできる。でそこから、どのくらいの時間でできるかを割り出せる。でも僕が本当に狙っているのは、一番小さな単位の仕事で、価値を出せるものを探し出したいんだ。そうなれば、そこから更なる予算を貰うことができるから、プロジェクト自体が自家資産で動くことができる。理論的にはこの段階でもっとたくさんの開発力を増強できるんだ。その小さい単位がすぐにみあたらなければ、その結果を得るのは難しい。
未来はコントロールできない
W:見積もりは、未来を定義しようとする行為だ。どのくらいのお金が必要か、どのくらいの人を雇用しないといけないか、いつ顧客の手に渡るか、そういったことは本当には制御できないことろなんだ。正直言って、そういったことを今だに制御できると思っている人がいるなんて、恥ずかしいよ。何年もやってきて、この業界としてそういうことはコントロール外だって、僕たちが証明したことじゃないか。（笑）もしかしたら、こういうことが制御できると思っているから、もっといいことが制御できるってことに気づかない人が多いんじゃないかと思う。皆、もっといいものをコントロールするべきだと思う。
R: たとえば何をコントロールするの？
W: たとえばね。僕たちは素晴らしいものを生み出せる環境にいる。システムの中に住むのではなく、システムを作る。どのように僕たちは働くのか、どのようにしたらもっといいものを作れるのか。こういうことだよ。もし僕たちがシステムを作り上げて、その環境を組み上げて、環境の中で皆が素晴らしいものを作れ出すようにする。だって、皆、素晴らしいものを作りたいと思っているのだから。
R: そうだね。
日々の正気を保つ為に、創造性を使い果たしてはいけない
W: でも。そういった環境にいなければ、もしくはそういう環境の存在を許されてなければ、皆ただ、毎日をやり過ごすことだけで一杯一杯になってしまう。
C: そのとおり。
W: 正気を保つだけの為にエネルギーを使うべきではない。僕たちは正気かどうかなんか、気にしなくていいところで働かなければいけないんだ。プロジェクトがどれだけのプレッシャーの下にいるかどうかは関係なく、心穏やかさと人生の豊かさとともに働かなければ、結果的にひどいことになる。
R: デスマーチだね。
W: そう。デスマーチだ。すでにプレッシャーがかかっているシステムにさらにプレッシャーをかけたとして、何が得られると思う？ でもそれを、この業界はずっとやってきてるんだ！
R: ずっとやってりゃ士気があがるってか（笑）？
W: そう！ それで何かいいことあったっけ？ それでもみんなやり続けるんだ。
R: 僕は6か月デスマーチやってる所に、切り札として雇われたことがあってね。彼らは週末もずっと返上して働き続けたんだ。で、皆に挨拶して、でその人たちがが「どう思う?今週末は休んでもいいと思う？」て聞くから「ステップ１．皆家に帰り、このドアには鍵をかける。（今週末は）誰も働いてはいけない。」
W: そう。
C: 正しいよ。
R:「そうしても良いと言っているのではなく、そうしないといけない、と言っている！」
W: パワフルなメッセージだね。
R:「そこから再スタートだ」ってね。これはクリエイティブな仕事なんだ。自分にムチ打ってクリエイティブになんて、なれやしないよ。
W:まったくだ。活力と人生のエナジーをもって仕事に臨まないと。結構皆、エネルギーを無駄に失っている。これは見逃しがちなことだよ。 僕が見たプロジェクトでは、最強チームか何かを名乗らされて、そのチームは週末はないし、眠くなったら床で寝ろと。そしてそのチームメンバーは眠くなるべきではない、と信じ込んでいる。ねえ、そんな状況で何ができるんだい？何か大きな問題を解決しようとしているなら、それは問題解決する状況じゃない。
ゴールが近くなるほど、ゴールが遠くなる現象
R:このあたりの話をすると、たとえば、問題解決のゴールに近くなると、実はゴールから遠くなるよね。
W: そう。
R:すべての仕事がゴールに向けるために有意義にもたらされるわけではないから。誰かが書いたコードが、進行を遅らせることもある。で、ほかの誰かが時間をとって、そのコードを取り除かないといけない。
W: ああそうだね。いい点だ。
R: ひどい罠になりうるわけだ。
W: プロジェクトに書き加えられたすべての行が問題で、まったく誰も仕事ができない状態になる。何回かそういうプロジェクトも見たよ。それでリリースもされなかったりした。
R: 違う言語の共存するプロジェクトだったりしてね。「あのRuby on Rails書いている奴がいけない！」とか（笑）
W: そういうことも、もしかしたらあるかもしれないけど、コードがそういう状況に陥ってほしくないよね。
R: どうしてこうなったみたいな。
皆で理解する
R: この（見積もりしない）アイデアはすごくいいと思うんだけど、いくつか気になることがあってね。
まずグループの全員がビジネスの何が大切か、プロジェクトの底力を分かっていないといけない。僕がかかわった組織の中ではやっぱりいるんだよ。「俺がただ一人の価値評価する人間だ、他のチームメンバーは歯車の歯だから、お前はこれをつくって、そっちはこれを作って。なぜかは聞くな。ただ作ればいい！」という人。これって価値の初期値っから、ひどいダメージを与えるよ。 誰もが皆、価値あるものを生み出したいと思っているのに。
C: でもさ、俺らは皆コントロール狂だろ？ ある程度は偏執屋じゃないとじゃなきゃ開発者になろうなんて、思わないと思うよ。
R: それがもう一つの問題だよ。そろそろ、コントロールしたいと思う気持ちを、コントロールするべきじゃないのか？
C: まったくだ。がんばらないと。
コントロールできない恐怖は現実的に迫る
W: 難しいかもしれないね。だってほぼ皆が開発にかかわっているのだから。どうしても、こもってしまう傾向にあるだろ？だれもどう考えるべきかなんて教えてくれない。それぞれの思考のしかたはユニークなんだ。だから、どうしてもほっといてもらって自分で解決するよ、って言って、ひきこもってしまう。
R: ここにいる皆そうだよね。
W: それでいいこともあるかもしれないけど、悪いことにもなりうるんだよね。
C: 結果がよいかもしれないし、悪いことになっても、楽しいからそれでいいってね。だって、それだけ自分でコントロールできることがあったから。
W: まあ、そうであるといいね。ここノルウェー出身のBuautexness（？）というの言ったことには「制御を失うことを恐れれば、変化が難しくなる。しかし制御は幻想で、恐怖は現実だ。」とね。
C: 全くだね。
W: ちょっと引用が正しくないかもしれないかもしれないけど、大体そんな感じ。制御できないことに対する恐怖は本当にそこにあるけど、制御できるってことが幻想だとは思わないんだ。そこから始めないとだめだね。
C: もしかしたら恐怖も幻想だね。
W: たぶんそうだね。
C: 現実的に感じるかもしれないけど。恐怖って元々そういう性質のものだから。
上司の偏執に付き合わない
W: ソフトウェア開発について、分からないことのうちの一つにこれがあって、もちろんそういうものだと受け入れなければならないこともあるのかもしれないけど、これはしっかり言える。メンバーが働く方法をダメにしていることは、見積もりについて話すことだよ。見積もりがシステムの中に入り込んでいると、必ず問題が起こる。問題は、なぜ見積もりが必要かということ。なにを見たいのか。その話をメンバーがしようとすると、いやいや、ただやればいいんだよ！となる。
以前あたったマネージャーで、「君の見積もりが欲しい」と言ってきたので「その見積もりは何も意味をなさない。僕はこのプロジェクトについてまだわかってないから」と言ったら、「でも欲しい」と。「それをシステムに入力しなければいけないから。それで計画を立てるから。」と。
R:「私は不正確なデータが欲しい。そうしたらでっち上げを作れるから。憶測できるから！」
C: ところでリチャード、今何時だと思う？
R: ハッピータイムだね
C: そろそろおおよそどのくらいの時間がかかるか見積もりを立てて、その見積もりがいくつあれば正しい見積もりになるのか、見積もりを立てる頃だ。
R: 回帰主義な見積もりだね（笑）
W: これ、よく聞くよ。見積もりが欲しいからどのくらいでできるか教えてくれ。→ 2週間です → 2週間ちょうど？ → いや2~3日プラマイして。それから発展してさ「どのくらい自信持って言える？」「75％くらい？」
R: 3レイヤに分かれた見積もりだね。（笑）
ここで読者プレゼントコーナー。Woddyさんは、5000ドルあったら大きなモニターが欲しいそう。
モブ・プログラミング（箸休め）
C: ところでモブ・プログラミングはどう？ 何年か前にモブ・プログラミングの話で来てもらったよね。
W: 2年前だね。ハンター（インダストリー）は離れたんだけど。そのころは、僕は毎日3inｘ5inのカードを持ち歩いてて、そこにやらなければいけないことを書いていって、マグネットの板に次々に張り付けていた。皆がいつも何かアイデアをもっていて、それを次々と終らせていったんだ。やることはいつもあった。ある日彼らが来て、ボードに行って僕に何をしたらいいかな、と行って、カードを見て、じゃあこれを最初にやろう、そろそろ整理した方がいいよね、なんて仕事を始めてた。ある日、3時間彼らは何も僕に聞かないで、自主的に働いてたんだ。そのとき思ったんだ。少し悔しいけど、皆は僕のことが必要というわけではないんだ！と分かったんだ。
R: ははは。
W: ランチに連れてって、毎日やってたんだけど、その日も行って、もしかしたら僕はもうここを離れた方がいいかもしれないって言ったんだ。それから彼らはインターンを集めて、2つのモブを作って、再グループしたりとかした。うまくやっていると思うよ彼らは。
R: いいじゃん！
リモートでもモブ・プログラミング（箸休め）
C: 2年前の話だから、聞いたかどうか覚えてないんだけど。その環境をリモートで作ることできる？
W: リモートでやったよ。
C: ほんと？すごいね。
W: それでより有利に働いたこともあったよ。いいツールをつかって、いわゆるキーボードを変わりばんこに使う機能がないとだめなんだけど、あと、集中しないとだめだよね。ある程度の時間を準備して互いにリモートで深く関わりあってないといけない。10分とかの単位じゃできないよね。
R: そりゃそうだよね。
C: GOTO Meetingだとさ、結構簡単に他のメンバーのキーボードを奪うことができるんだよね。
W: だね。
C: 知ってたんだ？
W: うん。いろいろなツールがそんな感じだよ。多分それは克服しなければいけないことだよね。ルールをつくってさ。だって環境を皆で使っているんだから、誰か一人が壊してしまうこともある。Pat Maddox知ってる？Ruby Stepsってのやってるんだけど、あんな感じかな？ 実際に遠隔で、教える仕事しているんだ。彼は素晴らしいよ。まだインタビューしてないなら、したほうがいい。とてもいい仕事をする。
C: いいね。リモートとか、共同作業のツールとかのトピックでやりたいね。
閑話休題
C: 見積もりしない開発法に話をもどしたいんだけど、顧客の手に渡るのが早いからこれがいらないって話だったよね。
W: うん。
R: で、チームを組んだら、主なるチームのできることの価値を皆で理解する。そしてなにをするか、何がタスクか、何を最初にやるべきか、を見る。
W: うん。
R: そして、時間と合わせてみてみる。
W: そう。
労力と価値のバランス→非カップル化が鍵
R: で、すごく価値にあることで、時間がかかることがあるとする。一方でその10%ぐらいの価値くらいしか生み出さないけど、1%くらいの労力で終わるとする。これを最初にやるべきか。僕たちは一番価値のあることを最初にやりがちで、どのくらいの労力がそれにかかるかをあまり見ていないんじゃないか？
W: どんな労力が、一番大変かを知ることで・・・
R: それって見積もりなんじゃないか？
W: ああ、そういうこともあるね。よくわかるよ。そのパーツがどのくらい非カップル化できるかなんだ。もし、それがどうしても一緒にしなければいけないことであるなら、先に取り掛かってしまって、あまりに大きすぎるものであるなら、そこから小さなものに分ければいい。でもここで見積もるというわけではない。だせる価値を判断しないといけないんだ。
R: うん。
W: よく言ったのは、「もしこの大きな仕事をしたら、大きな価値が出るぞ。この遅い仕事をすると、小さな価値しかない」そいういうことはもう判断しなくてもいいんだ。もっと見なければいけないのは品質で、だからいつも何か小さなものにしてから、取り掛からないといけない。
C: たいていどのくらいの仕事になるかという見積もりを作ろうという時に問題になるのは、その価値の部分だよ。必要になる労力と、技術的な分からないこととか、ほら、これは初めて見るものだから、リサーチしないといけない、とか。僕がよくやるのは、そのリサーチにどのくらいかかるかを見て、一週間だとすると、その一週間後には、どのぐらいの仕事か最初の時点よりは、よく見えてきている。
プロトタイピングと、全体でないと渡せないプロジェクト
W: プロトタイピングだね。とてもとても小さいプロトタイプでいいんだ。おもしろいのは、ソフトウェアはよくプロトタイプで作られるものなんだ。それでいい品質のものができたら、そのプロトタイプを見てみる。必要な品質はここにあるか？もしそうなら、先に進める。そのプロトタイプをやることによって、時間を投資する際のリスクは減らせるね。それで価値ある仕事はもうできているものね。何か潜在的な価値のあるものがあるといい。それがあれば顧客の手に渡せる。
でも、この例はよく出されるんだけど、飛行機をつくるとして、翼だけは顧客に渡せない、エンジンだけでも顧客に渡せない。そういうプロジェクトもあることは認めるよ。
R: 全体でないといけない。
W: そういうこと。
R: でも最初に作る飛行機が757型で有る必要はない。
W: そうそう。
R: 小さい飛行機でいいよね。
W: もちろんそうだよ。何かほかのモデルでもいいブロックがないか探せるね。この分かりやすい例では、見積もりは、どうしても必要になってしまうケースもあるということ。それは分かっているよ。でも、新しい飛行機をデザインするとして、その間エンジンを改善されたり、現在作っている飛行機の型が変わったりする。いつもイノベーションは起こっているから。これって複雑な話で、これだけで何時間にもなってしまうのだけど。
見積もりオバケのお祓い
R: いいよ。でもさ、いつもプレッシャーはあるよね。それはどうやって取り除くの？ただデリバリ続けるだけ？見積もりをしたがる人はいるはずだよ。
W: 10年くらい前のことなんだけど、あるプロジェクトが全くの失敗で、これが何年も本番にに移れないでいるんだ。その人たちはそれでも新しい機能を作りだして、そのフィックスを本番にマージさせ続けている。それでどんどん壊れていって、しかもバージョン管理もあまりいいものではなかった。
ここで見逃せないのは、こうなると見積もりはどうでもよくなってしまっているということ。まだデリバリすらできてないんだから。
僕は彼らに、一番小さなところでいいから、僕がわかるようなところを見せて。こういうこと言うと混乱する人がいるんだけど、小さく見積もって、ことではないんだ。小さなもので、見れるものが見たい、と言ったよ。すると彼らはコードをリバートを始めた。直近のビルドが通るものまでね。それって、1年前のものだったんだ。
R&C: ひでえ。
W: だって沢山の動かないものばかりが積み上げられていたんだから。これをすべてバグフィックスしたい？それとも何か動いているところまで戻りたい？別にバグフィックスの方とってもいいんだ。僕は彼らに聞いたよ。「今持っているものが、君らが欲しかったもので、今同じものを欲しがれば、未来に同じものを持つことになる。」
R: 未来のバグフィックスだね。
W: 彼らはすべてに見積もりをつけてたんだ。「今週末までににこれがあればいいよね。」
C: だよね。僕がいつもぶちあたる問題と一緒だ。
低い所の果実からデリバリ→信用
W: それで、小さなものを見てから、アイテムごとに比べるんだ。5つあったら1つ1つ始める。一番小さな、僕たちのできることは何だろう？これは80&20ルールだね。
C: 低いところになっている果実ってやつだね。
W: それと似ているよ。でもどれが低いところになっている果実なのか、判断することを学ぶことまでするんだ。それを顧客の手に渡すところまでできたら、見積もりつきでもなんでもさ、それを顧客のもとに手渡せたら、次に行ける。それで5つやれば、おのずと見積もりなんか聞いてこなくなる。
R: 信用を得るということなのかい？このプロセスでは。
W: プロセスに対する信用だね。少しづつ手渡して、最終的に本番にする。
見積もりはイジメツール
R: この話はいつも出てくると思うけど、実際見積もりは何のためにあるの？ これって、できなかったときに誰かをいじめるためにあるんじゃない？
W: それは一番悪い見積もりの使い方だね。見積もりとは何かって、色々な人に書いてもらったことあったんだけど、"誰かをクビにするため"って書いた人がいたよ。
R: そうそう。
C: うわ。
W: で、その人の話を聞いたさ。どうやって、うまくクビにするための武器を用意するのか。
R: そう。できないような見積もりを、うまく導き出してわざと提出させる。
W: そうそう。
R: すっごく高い空に届くお見積もりをね。
C: それ以降誰も見積もりださなくなるね。こうやって、見積もり世界から無くすこともできるね！（笑）
W: でもそうやっていると、僕が始めたことじゃないんだけど、プロジェクトを回すことには見積もりはもういらないんだ。
C: 「どのくらいで見積もりを切り捨てられるか見積もりをくれ！」
W: 小さいものを引き受けるよりはね、品質を見て、それは理にかなったものか見て、他に影響を与えずに非カップル化できるか見る。その上、皆にわかりやすいもので、（その小さなものが）お互いに特徴が属しあっているもの、を成果として出す必要があるよ。
解決法がコードではない
R: そういうのって、結構コードがどうの、じゃないところで解決するんだよね。
W: いいポイントだね。
R: 君は価値のあるものを顧客に届けると言うけど、彼らの問題を理解してくると、結構ほかの方法で解決できることに気付く。これってすでに解決してない？ ってこと。例えば報告システム。「どのくらいでこのシステムは作れる？」っていわれて考えると、ツールがあるから、コード書かずに実現できるんだ。そもそもどうして報告システム作るのにコード書かないといけないの？どうしてそれで見積もりが必要なんだ？
あるパフォーマンス向上の依頼に僕は連れてこられて、何か月かかる？って聞かれたんだ。僕はCDNをウェブサイトに導入して、パフォーマンス向上させたよ。どうしてコードを書かないといけないんだ。サイトを早くしたかったら、方法にこだわんなくていいじゃないか。
W: 問題定義したい場面で、もし彼らがすでにコードを求めているなら、彼らはもう解決法を知っていることになるよ。そういうのにはこう聞かないと。「あなたは問題解決をしたいのですか、それとも、あなたが考える解決法を私たちに導入してもらいたいのですか」と。普通、解決法は最初っから目の前にはない。
R: 期待される回答ってやつだね。
C: ちょっとまって。アジャイルですべて解決するんじゃなかったっけ？
W: ここはアジャイルのいい点だよ。僕たちが考えるべきガイドラインだ。どうやって仕事するべきか。顧客が要求できるところではないよね。僕たちは色々なこと特別な方法でやる。いくつか関わってくるところあると思うよ。特にデリバリーの部分だよね。いろいろな方法ができる。
このコンファレンス（NDC Oslo:このインタビューが行われている場所）ではいろいろなことを話されているけど、特に継続的なデリバリとか、導入とか、すごくすごく重要なセキュリティとか、僕たちが解決しないといけない、大きな問題だよね。僕は継続的なデリバリが好きなんだけど、それがあるだけでいろいろな問題を解決できる。ボタンクリックするだけで、導入できるんだから、他のことをする時間ができるようになるしね。
ここから先は、コンファレンスについての井戸端会議になってしまったので、ここまで。