McFarlandなんかもう、毎日ブログ更新〜じゃなくって、毎月かろうじて書いてます〜ぐらいになってしまったんだが。McFarlandが語る「アジャイルスタートアップ」に行ってきました。SFCで僕の授業を受けてくれていた教え子も参加していて声をかけてくれました。いうのって凄くうれしい。いう電話番号で笑った。さっき通訳がいないことに気がついて。英語でしゃべったのを、日本語で説明します。アジャイルプログラミングしている人は?ペアプログラミングまでしている人は?彼がやっていることを紹介して。ご存知の方も多々いると思うので。アジャイル開発はもともと日本からアイデアが出ている。日本はとっても進んでいるというイメージがある。それは製造ばかりでソフトウェアはまだまだ。日本ではやりにくくって、日本だと外注してしまう。ビジネスを作る人たちと開発する人が違う。アジャイルは自分たちでつくる。ビジネスオーナーと開発が一緒になってつくる。プロジェクトマネージャーは居ない。企画を一緒になって考える。最終目的はきちっと決めないで、なんとなく方向性を決めて、フィードバックを得ながら。一週間2週間単位で見直す。みんなで開発して、開発した結果、次どうしようかを見直す。シリコンバレーのベンチャーはビボットが激しい。最初は、動画つきデートサイトだった。すると、動画用フリッカーという売り込みをしていた。最終的にどうするのかは、仕様書をつくるわけではない。フリッカーももともとはゲームサイト。プロセストしては、ストーリーという単位でいろいろ考える。私はユーザーとしてログインできるようにして欲しいとか、ショッピングカートがいっぱいになったら、どうして欲しいとか。中で「テスト」というコンセプトがある。ユーザーとしてログインできるようにしたい。それと同じような英語で書くとコードになる。コードを書かないうちに動かすと、テストが通らない。テストがパスするように、コードを書いていく。常にテストを走らせておく。テストを書く方がソフトを書くよりもエネルギーがかかる。パラメーターを決めていく。プログラマは朝くると、ストーリーが順番に並べ替えられているのをテストを書いて、コードを書いて、テストがパスしてグリーンの状態になる。壊れることもあるが、テストが全グリーンになるまで繰り返す。常にバグ出しをしている。ビジネスオーナーが「今出そう」と言ったときにすぐだせる。一個のチームがいくつストーリーをこなすのか数が分かる。何週目にどこまでいくのかが予想できる。このスピードでいけば、いついつまでにどこに到達するのかが分かる。あるフィーチャーを抜くと、いついつまでにできるかというのが分かる。普通に働けば、いつまでにできるのかが分かる。ビジネスオーナーが、機能のありなしをコントロールできる。ビジネスオーナーと開発者で、いつでもリリースできる状態にある。チーム必ずペアで座る。ひとつの画面を2人で見る。何かに止まっていることが多い。一人見ていると間違いが見つけやすい。実は、ぼーっとしている時間が多い。ペアプログラミングは疲れるけど効率は良い。プログラマは何カ所を開発を作る、全員で作るのはむずかしい。ペアを増やすと、セクションの効率はあがる。スループットをあげる。ペアリングすると技が磨ける。新しい人が参加した場合もキャッチアップに時間がかかるが、すぐに参加できる。最終的に全員が情報を共有できる。この人しか分からないというケースが無い。初心者が入っていても、教育を繰り返して、人を増やすことができる。何人かが始めればよい。朝来て、休みを一緒にとらないといけない「ピンポン」8:45に朝ご飯を食べる。すると、同じ時間におなかが減るので良い。技術者はプログラミングしているときはイノベーションしてはいけない。ストーリーを考えるときはイノベーションだけど、プログラムを書いているときは複雑にしてはいけない。i:体を動かすと3割頭が良くなる。125人居て、アジャイル開発の先生。そのスタイルを持ち込んでいる。いう手法を覚えてもらったら、撤退していく、プログラミングのコンサルタント集団。プログラミングの進化を考えている。いくつかポイントがあって。デザイナーはどうやっていれる?もうひとつはテスト書いてストーリードリブンだと、クリエイティビティが無い。一人でがっと書いて「スパイク」というんだけど、イノベーションプロセスを求めてもいいのかも。i:クリエイティビティは?紙の段階でユーザーテスティングをする。「スパイク」はテスト書かないで、がっと書く。製品コードではなく、プロトタイプのコード。絶対コードを捨てるの前提。触ってみて初めて分かるというもの。いうときには「スパイク」する。デザインのフェーズでは「スパイク」するプロトタイプのコードは製品コードを使ってはいけない。ベンチャーでは使いたがるが、それはダメ。バグもそのまま、いままであったものと同じものをテストつきで全部書き直す。リファクタリングもする。ストーリー、テスト、どんどんコードをシンプルにしていく。書き直したときに新しい機能をついつい足してしまう。バグも含めて、一度書き換えて、書き換えて同じにしてから手を入れていく。i:「リーン」というのは、やせているとか、ローコストとか。ユーザーに対してのアイデアを最短の時間と最短のコストで試せるのが重要。プロダクションテストでユーザー5%でやるかもしれない。紙のプロトタイプでやるかもしれないが。アイデアだして、テストしてどうするのかを考える。ウォーターフォールとは違い、アジャイルだと会社の考えが変わってくる。機能を増やしつつ、動き続ける。新しい機能にすぐにリアクションがくる。普通の日本企業だと、新しい機能に半年かかったりする。サイズになっても毎週あたらしい機能が出せるのは、アジャイルの力。資産ではなく、負債である。書いたコードは捨てられない。プロダクトミーティングには技術者を入れない。徹夜で書いたものを捨てる必要があるときもある。アジャイルだと、小さいかたまりを書いているので、思い入れが少ない。数人が大量に書いたコードを捨てることをしにくい。帳簿上ソフトウェア資産として計上されている。特許とってしまうと、特許使ってなにかしようとする。いままでソフトウエアを資産として考えたが、実は負債である。i:デザインをどうやって巻き込むか?だいたいはデザイン会社がきっかけでアジャイルになることもある。デザイン会社がつくったアジャイルは、デザインでパラメータが決まってしまうので、ウォーターフォールのようになってしまう。IDEOでユーザーセントリックデザインといっている。昔は天才デザイナーが考えたものをみんなで実装していた。最近はリサーチしながら、プロセスのひとつとしてデザイナーを巻き込むのが大切。ホワイトボードでプロトタイプを作るのかもしれないが、ユーザー中心、常に一緒にテストしてくのが重要なプロセス。IDEOと一緒に仕事して良い関係になっている。クライアントに理解してもらうには?A:カスタマーからすると、いつ何ができるのか分からないのに発注できない。トータルコストがわからない。何ができるのかわからない。常に一番正しい方向に向かって動いている。常にメリットがある方向にむかえる。今、1年後に何が欲しいのか分かるわけがない。今この企画書がユーザーに求められるものか分からない。企画書について発注して、つくって納品するのはベストではない。毎週考え直しているから、勝ち組。勝ち組はみんなアジャイル。経営レベルで発想をかえないと変わらない。日本でも事例を作っていく。経理から、根本から考えが違う。つくって、相見積もりとって発注するのは間違っている。ベンチャーとかの方が発注しやすい。アメリカだと大企業でも発注している。力が強いから、なかなかむずかしい。全体ができなくてもあるある一部分やいちチームでやる手もある。基本的には、全くのお客さんのとおりにしかやらない。お客さんがクリエイティビティが発揮できるように。クリエイティビティを発揮してはいけないときもある。成功している会社はむちゃくちゃデータドリブン。