MIT Media Labの新所長になられた伊藤穰一さん(@joi)とアジャイルで開発しているPivotalのCEOのIan McFarlandさんのアジャイルスタートアップについての講演に参加してきました。
伊藤穰一とPivotalのIan McFarlandが語る「アジャイルスタートアップ」
http://www.ustream.tv/recorded/14985986
感想
現状のWeb界隈のスピードの速さを見るとアジャイル開発の重要性は明らかに感じられます。これまでの１年かかるようなものづくりのやり方では絶対勝てません。
ただペアプログラミングまで必要かは議論がわかれるとは思いますが、ストーリーベースでテストを行いContinuous Releasabilityを確保するのは必須だと思います。
アジャイルといっても今よりずっと前から言われていますが、うまく普及していないのは、これまでの考え方を捨てて、発想を転換しなければならないということだと思っています。
特に経営レベルでは、これまでの仕様と納期ありきから脱却しなければならないわけですから。エンジニアを信用して投資するなんてことは、リスクの高い責任を背負うことになるので到底今の日本の大企業ではできないでしょう。
アジャイルを本気でやるにはトップダウンで決定し、宗教的に信じこんでやるのが一番な気がします。そういう点でPivotalはうまくいっているんだろうなと。
また我々組み込み業界だと度々ソフトを更新ってわけにもいかないわけで、この先生き残っていくには、「ソフトの更新がバリバリできる環境」をつくることが肝なのではないかと思います。国としてもものづくり日本とか言っているのであれば、こういったところのインフラを作ってほしいものです。
メモ
・アジャイルは元々は日本の製造業のやり方から来ている
・基本的な方向性は決めるが最終目的をあまり決めず、数日から２週間のスプリント毎にユーザのフィードバックももとに、なにをやるか見直す
・例えばYouTubeはもともと出会い系の動画サイトを目指していたり、Flickerはもともとはゲームだったりとやっているうちにゴールは大きく変わっている
・プロセスは、ストーリー単位（ストーリーは文書で書きだす）⇒テストを書く⇒コーディングする⇒テストをパスする
・ソースコード：テストコードの割合は１：１．５くらい
・朝きてストーリーカードをみてみんなでどれをやるか決める
・PMはいらない
・いつまでに何をではなく、このスピードでいけばここまでできるというスタイル
・締切りに向かってガッとやるのではなく無理のないペースで
・４〜６人のチームで必ずペアプログラミング
・プログラミングのうち８割くらいは悩んでたりするので２人でやったほうが効率的
・技もコードも覚えられるので新しい人が入ってきた場合にも育てやすく入れやすい、新人を入れるサイクルを回せる
・コードはシンプルに書く。コードでイノベーションを起こそうとしてはならない。それはストーリーでやるべき
・絶対にプロトタイプは製品化しない。つくり直す
・テストドリブンで常にリリースできるものをつくり、短いサイクルでストーリーを実現していくので、常に新しいものがリアルタイムに出すことができる
・FacebookやTwitterは大きい会社になってもほぼ毎週のようにころころ機能が変わっているので、うまくプロセスをまわしている。
・ソースコードや特許はアジャイルにとっては負債。捨て難いから。
・プロセスの一員としてデザイナーを入れる。デザインもカリスマデザイナーが作ったものをそのまま作るようなやり方ではなく、常に仮説としてユーザーの意見を取り入れて変更する。
・日本のモノづくりは仕様を決めてから作り始めできあがるのに１年くらいかかるが、それでは遅い。世の中は毎日めまぐるしく変わっているのに１年後にユーザーが何がほしいのかはわからない。
・経営レベルで発想を変えないといけない。その点ではベンチャーのほうがやりやすい。
・アメリカではとてもデータドリブン。ユーザの動きといったデータを細かく分析して仮説を検証している。
・データに頼りすぎてもだめだが、データを無視して同じ失敗を繰り返すのもだめ。そのバランスが重要
その他
講演とは関係ないですがアジャイルつながりで。
今日見つけた記事でScrumやXPなどのアジャイルプラクティスをミックスしてやるといったことについて書かれています。
本では、こちらの本の前半部分にアジャイルプラクティス(extreme programing)の説明がわかりやすく書いてあります。
