MIT Media Lab新所長、伊藤穰一とPivotalのCTO,Ian McFarlandが語る会に行った

勉強 技術 agile

27日(金)にこのイベントに行ってきたので、内容のメモ。
http://atnd.org/events/16029

スライドがあって云々ではなく、ほぼ伊藤さんのフリートークで、時々、Ianが回答するという形式だったので箇条書き形式にて。

  • アジャイル全般
    • スクラムなど、日本から出てきたコンセプトも幾つかあり、海外のエンジニアには、日本がアジャイル先進国だと思っている(勘違いしている？)人も多い。
    • 外注方式ではアジャイルを実践することは不可。ビジネスオーナーと作成者が同じ組織にいなければならない。
    • 基本的な方向性は決まっているけど、最終的なアウトプットは決まっていない状態で実装が進められていく。このため、プロジェクトマネージャーという役割は存在しない。
    • １〜２週間に１回、ピボットと呼ばれるタイミングを設け、これまでのアウトプットや各フィードバック(数字の話、他社の新機能の話など)を元に次の進め方を決める。YouTubeなんかも最初の頃はころころとコンセプトを変えていた。
  • TDDに関して
    • テキストなどでリストアップされた機能（フィーチャー）→ 機能毎のテスト → 機能毎の実装 のフロー(=TDD)による開発。パワポなどは存在しない。
    • 常にテストは動いているので、不意に今リリースしよう！ってなっても、実装済みの機能に関しては動くことが保証されている。
    • 動作的な部分だけでなく、ページのロード時間や色の比率などをテストする場合もある。
    • 「いつまでに○○をする。」ではなく、「いつまでに○○まで終わる」という形式での仕事の進め方。機能単位で実装されていくため、進捗のペースがつかみやすく、予測も立てやすい。
    • これまでの実績に基づいて工程が組み立てられるため、無理な工程を引かれることが少なく、プログラマにとってハッピー。
  • ペアプログラミングに関して
    • 実装の７〜８割の時間は何かに詰まっていたり、何か違うこと(メール,ネット)をしていたりする。ペアプロだと、これができない。
    • 全ての実装をペアプロで行う。
    • ピボタルラボ(Ianの会社)では、開発用のスペースとメールを見たりするスペースが物理的に分かれている。
    • 新しい人が来たときも、一人でコードを読んでキャッチアップということをする必要がない。
    • 定期的に技術力や実績をベースにチームを入れ直す。
    • 休憩時間も一緒にする必要があるため、朝ごはんを会社で準備して皆で食べるようにして、同じ頃にお腹がすいてお昼をとるようにしたりすることもある。
  • プロトタイプはどうしているか
    • コードを書いている時に技術者がイノベーション(=機能を足してみたり、変更したり)してはいけない。あくまでもリストアップされた機能のテストコード → 機能の実装 という作業のみを行う。
    • コードでイノベーションするのはスパイクと呼ばれる時間に行う。
    • スパイクの時間に作成されたコードは絶対に製品コードとはしないという約束がある。
  • その他
    • ピボタルが開発のコンサルティングとして入る時、まずは既存のコードを全てストーリー付きの形でそのまま書きなおす。バグ等もそのまま。数か月単位の作業になることも。。
    • こうしておくことで、他社の動向に応じて、新しい機能追加などが容易になる。
    • コードは資産ではなくて負債という側面もある。一回書いてしまうと捨てられない。。
    • 機能追加や機能のドロップを話し合うプロダクトMTGの場には、技術者を入れない会社もある。
    • デザインベースで始めると、どうしてもウォータフォールに近い流れになってしまうので、デザインも巻き込んでのPDCAにする必要がある。昔は有名デザイナーが作ったサイトをバーンと作れば良かったが、そういう時代ではなくなった。
  • QAその１ アジャイルは将来のアウトプットに関して何も約束しないという話でしたが、発注者としてはいついつまでにこれができるという約束が欲しいのではないか？
    • 何らかの企画を立てた段階で一年後、三ヶ月後にユーザが欲しているものを予測できていると考えるのは、今の世の中では無謀な考え。TwitterやFacebookなどなど、今の勝ち組企業の多くはアジャイルを採用しているけど、それでもあなたの会社のやり方が正しいと言えるのかい？と聞いてみればいい！？
  • QAその２ プロダクトMTGでは技術者を呼ばないこともあると言っていたが、プロダクトの出し入れの意思決定はどのように行われるのか？
    • シリコンバレーのプロダクトマネージャーはめちゃくちゃデータドリブン。会議はチャートだらけだし、自分でがんがんSQLを叩いて必要なデータを引っ張ってくる。ダメな機能をどんどん落とすと共に、全てがデータに残っているので、同じ失敗は繰り返さない。ただし、あまりにデータに寄り過ぎるとイノベーションしないし、データを見なさすぎると過去と同じ失敗を繰り返してしまうこともあるので、そのバランス感が大事。


対談は一時間ほどで終わってしまいましたが、もっともっと聞いていたい内容でした。聞いていて凄くワクワクすると共に、身の引き締まる感じ。というか、是非一回そういう仕事の進め方を経験してみたい。若いうちに。まだ、若いかどうかはあれですが、、

テストコードはそれなりに書いたことはあるし、TDDやらペアプロなどのアジャイル系の単語は知ってはいたけど、実はアジャイルのアの字も理解できていなかったのだな、、と痛感。ものづくり業界ではTOYOTAの圧倒的な強さを支えているかんばん方式が色んな所に輸出されているという話を聞いたことがありますが、アジャイル手法もどんどんと輸出されてくる、、というか、最近の勝ち組企業達の多くがこの手法を採用しているということで、自然淘汰的にこの手法が残っていくのかなと思ったりもしました。