[&] Joi * Ian McFarland

なんかもう、毎日ブログ更新〜じゃなくって、毎月かろうじて書いてます〜
ぐらいになってしまったんだが。

MIT Media Lab新所長、伊藤穰一とPivotalのCTO,Ian McFarlandが語る「アジャイルスタートアップ」に行ってきました。

偶然SFCで僕の授業を受けてくれていた教え子も参加していて
声をかけてくれました。こういうのって凄くうれしい。

今日のお題は「アジャイル」で、Pivotal というアジャイルコンサルティングを生業とする Ian との対談。
Ian の名刺を見ると SFの局番+JIT+JAVA という電話番号で笑った。

joi * Ian McFarland (Pivotal)
--------------------------------------------------------
j: たったさっき通訳がいないことに気がついて。。。
日本語で説明して、ian が英語でしゃべったのを、日本語で説明します。
アジャイルプログラミングしている人は？ペアプログラミングまでしている人は？

彼がやっていることを紹介して。ご存知の方も多々いると思うので。
アジャイル開発はもともと日本からアイデアが出ている。
日本はとっても進んでいるというイメージがある。
それは製造ばかりでソフトウェアはまだまだ。
ウォーターフォール形式は、パワポで仕様つくって、外注先になげて、
外注先がつくって、テストして、運営して、
バージョンアップするときは、
切り替えミスして、SIer が訴えられて。。。。。。

アジャイルは根本的に考え方が違って、
日本ではやりにくくって、日本だと外注してしまう。
ビジネスを作る人たちと開発する人が違う。
アジャイルは自分たちでつくる。もしくはビジネスオーナーと開発が一緒になってつくる。
プロジェクトマネージャーは居ない。
アジャイルでのストーリー、ひとつひとつのフィーチャーをユーザー側から
ビジネス側、
企画を一緒になって考える。もうひとつ重要なのは、
最終目的はきちっと決めないで、なんとなく方向性を決めて、
フィードバックを得ながら。
アジャイルというのは基本的な方向性を決めるが、
一週間２週間単位で見直す。みんなで開発して、開発した結果、次どうしようかを見直す。

Pivotal は方向性を修正する。
シリコンバレーのベンチャーはビボットが激しい。
YouTube も最初は、動画つきデートサイトだった。
少しすると、動画用フリッカーという売り込みをしていた。
最終的にどうするのかは、仕様書をつくるわけではない。
フリッカーももともとはゲームサイト。

プロセストしては、ストーリーという単位でいろいろ考える。
私はユーザーとしてログインできるようにして欲しいとか、
ショッピングカートがいっぱいになったら、どうして欲しいとか。
Ruby on Rails の中で「テスト」というコンセプトがある。
ユーザーとしてログインできるようにしたい。
Ruby それと同じような英語で書くとコードになる。
コードを書かないうちに動かすと、テストが通らない。
テストがパスするように、コードを書いていく。
常にテストを走らせておく。
テストを書く方がソフトを書くよりもエネルギーがかかる。
何がパスで、何が fail なのかでパラメーターを決めていく。

プログラマは朝くると、ストーリーが順番に並べ替えられているのを
テストを書いて、コードを書いて、テストがパスしてグリーンの状態になる。
壊れることもあるが、テストが全グリーンになるまで繰り返す。
常にバグ出しをしている。
ビジネスオーナーが「今出そう」と言ったときにすぐだせる。

一個のチームがいくつストーリーをこなすのか数が分かる。
何週目にどこまでいくのかが予想できる。
このスピードでいけば、いついつまでにどこに到達するのかが分かる。

あるフィーチャーを抜くと、いついつまでにできるかというのが分かる。
締め切りに向かって働くのではなく、
普通に働けば、いつまでにできるのかが分かる。
ビジネスオーナーが、機能のありなしをコントロールできる。

ビジネスオーナーと開発者で、いつでもリリースできる状態にある。

ペアプログラミング 4-6 のチーム
必ずペアで座る。ひとつの画面を２人で見る。
何かに止まっていることが多い。
もう一人見ていると間違いが見つけやすい。
実は、ぼーっとしている時間が多い。
２人で休みをとる。
ペアプログラミングは疲れるけど効率は良い。
プログラマは何カ所を開発を作る、全員で作るのはむずかしい。
ペアを増やすと、セクションの効率はあがる。
スループットをあげる。ペアリングすると技が磨ける。
技もコードも覚える。
まったく新しい人が参加した場合もキャッチアップに時間がかかるが、
すぐに参加できる。最終的に全員が情報を共有できる。
この人しか分からないというケースが無い。
初心者が入っていても、教育を繰り返して、人を増やすことができる。
何人かが始めればよい。

朝来て、休みを一緒にとらないといけない「ピンポン」
８：４５に朝ご飯を食べる。そうすると、同じ時間におなかが減るので良い。
技術者はプログラミングしているときはイノベーションしてはいけない。
ストーリーを考えるときはイノベーションだけど、
プログラムを書いているときは複雑にしてはいけない。

i:
体を動かすと３割頭が良くなる。
125人居て、アジャイル開発の先生。宗教に近い。

彼らは Twitter などに、そのスタイルを持ち込んでいる。
そういう手法を覚えてもらったら、撤退していく、プログラミングのコンサルタント集団。
プログラミングの進化を考えている。
いくつかポイントがあって。デザイナーはどうやっていれる？
もうひとつはテスト書いてストーリードリブンだと、
クリエイティビティが無い。
一人でがっと書いて「スパイク」というんだけど、イノベーションプロセスを求めてもいいのかも。

i:
クリエイティビティは？
紙の段階でユーザーテスティングをする。
「スパイク」はテスト書かないで、がっと書く。
製品コードではなく、プロトタイプのコード。
絶対コードを捨てるの前提。
触ってみて初めて分かるというもの。そういうときには「スパイク」する。
デザインのフェーズでは「スパイク」する
プロトタイプのコードは製品コードを使ってはいけない。
ベンチャーでは使いたがるが、それはダメ。
バグもそのまま、いままであったものと同じものをテストつきで全部書き直す。
リファクタリングもする。ストーリー、テスト、どんどんコードをシンプルにしていく。
コードを Java から Ruby に書き直したときに新しい機能をついつい足してしまう。
バグも含めて、一度書き換えて、書き換えて同じにしてから手を入れていく。

i:
「リーン」というのは、やせているとか、ローコストとか。
ユーザーに対してのアイデアを最短の時間と最短のコストで試せるのが重要。
プロダクションテストでユーザー５％でやるかもしれない。
紙のプロトタイプでやるかもしれないが。
アイデアだして、テストしてどうするのかを考える。

ウォーターフォールとは違い、アジャイルだと会社の考えが変わってくる。
Twitter にあたらしい機能が加わったとか、
機能を増やしつつ、動き続ける。
新しい機能にすぐにリアクションがくる。
普通の日本企業だと、新しい機能に半年かかったりする。
Facebook のサイズになっても毎週あたらしい機能が出せるのは、
アジャイルの力。

i:
もうひとつ、ソースコードが何行ありますというのは、
資産ではなく、負債である。書いたコードは捨てられない。
プロダクトミーティングには技術者を入れない。
徹夜で書いたものを捨てる必要があるときもある。
アジャイルだと、小さいかたまりを書いているので、思い入れが少ない。
数人が大量に書いたコードを捨てることをしにくい。
帳簿上ソフトウェア資産として計上されている。

特許とってしまうと、特許使ってなにかしようとする。
いままでソフトウエアを資産として考えたが、実は負債である。

i:
デザインをどうやって巻き込むか？
だいたいはデザイン会社がきっかけでアジャイルになることもある。
デザイン会社がつくったアジャイルは、デザインでパラメータが
決まってしまうので、ウォーターフォールのようになってしまう。
IDEOでユーザーセントリックデザインといっている。
昔は天才デザイナーが考えたものをみんなで実装していた。
最近はリサーチしながら、プロセスのひとつとしてデザイナーを巻き込むのが大切。
デザインは常に仮説。
ホワイトボードでプロトタイプを作るのかもしれないが、
ユーザー中心、常に一緒にテストしてくのが重要なプロセス。
実際に IDEOと一緒に仕事して良い関係になっている。

Q&A
Q: クライアントに理解してもらうには？

A:
カスタマーからすると、いつ何ができるのか分からないのに発注できない。
トータルコストがわからない。
何ができるのかわからない。常にユーザーのフィードバックを受けながら、
常に一番正しい方向に向かって動いている。常にメリットがある方向にむかえる。
今、１年後に何が欲しいのか分かるわけがない。
今この企画書がユーザーに求められるものか分からない。
企画書について発注して、つくって納品するのはベストではない。

Facebook や Twitter は毎週考え直しているから、勝ち組。
勝ち組はみんなアジャイル。経営レベルで発想をかえないと変わらない。
日本でも事例を作っていく。経理から、根本から考えが違う。
RFP つくって、相見積もりとって発注するのは間違っている。
ベンチャーとかの方が発注しやすい。アメリカだと大企業でも発注している。
日本は SIer の力が強いから、なかなかむずかしい。
全体ができなくてもあるある一部分やいちチームでやる手もある。

Q: カスタマーが求めるものを作るのか？自分が求めるものを作るのか？

A:　

基本的には、全くのお客さんのとおりにしかやらない。
お客さんがクリエイティビティが発揮できるように。
またクリエイティビティを発揮してはいけないときもある。
コードはクリーンなプロセスで、zynga とか成功している会社は
むちゃくちゃデータドリブン。プロジェクトマネージャーは SQLたたいて、
解析できる人たち。
コンバージョンレート、SEO, むちゃくちゃデータを解析しながら、
変化させていく。
アメリカのサービスを日本でまねしても意味が無い。
だめな機能はどんどん外していく。データに従って解析していく。
ページビューくらいは見ているけど、データドリブンじゃない。
機能を残すとかはテストしなければいけない。ABテストする。
プロダクトミーティングはワイヤーフレームで見ているのではなく、
チャートだらけ。ストーリを作って機能を考え、
機能をどうテストするのかを考える。
そこがアートとサイエンスがちゃんとつながっている。
デザイナーは数字が読めないといけない。
データとデザインのバランスが重要。

Ian の所属するのは Pivotal Labs

Ian McFarland, Pivotal Labs

View more presentations from TheLeanStartup