MIT Media Lab新所長、伊藤穰一とPivotalのCTO,Ian McFarlandが語る「アジャイルスタートアップ」

感想文

MIT Media Lab新所長、伊藤穰一とPivotalのCTO,Ian McFarlandが語る「アジャイルスタートアップ」
http://atnd.org/events/16029

■感想
　・アジャイルについて
　　　開発手法・業務手法と言うよりは、思想の域まで昇華している。
　　　もはや欧米ではビジネスの手法として認識になりつつあるような話し方だった。
　
　・TEFCASに似ている
　　　→TEFCASをご存じない人へ
　　　　　マインドマップで有名なトニー・ブザン提唱の思考・行動モデル
　　　　　http://www.kanda-office.com/html/pdca2tefcas.html
　　　　　http://listfreak.com/list/1717
　　　　　http://newhabits.blog33.fc2.com/blog-entry-624.html
　
　・自社（開発の話だけではなく、組織の話）は見事にウォーターフォールに当てはまると思った。
　　　運営の考え方をアジャイルから学ぶものは多くありそう（スクラム、エクストリームプログラミング、テスト駆動開発 ）
　　　しかし、そうなると開発会社が自社に深く食い込むことが必要となるため、パートナーとの関係の持ち方が日本だとなかなか難しい
　
　・方針・戦略が短い期間で変化するのはWEBの企業では珍しいことではないので、
　　その変化に対応できる組織を作りあげるのがこれからの新しい経営のありかたではないか。
　　　ウォーターフォール形式だと意思決定のプロセスが見えない。

　・結局1時間ではさわりの部分しか聞けなかった。
　　アジャイルプロセスの中の振り返りの部分をどういった手法で行うのかが聞けなかった。


-----------------------------------------------------

アジャイルソフトウェア開発宣言
http://agilemanifesto.org/iso/ja/

アジャイルソフトウェア開発とは？
http://d.hatena.ne.jp/keyword/%A5%A2%A5%B8%A5%E3%A5%A4%A5%EB
http://japan.zdnet.com/sp/sp_06sp0130/20248727/

-----------------------------------------------------
以下、講演内容メモ

■アジャイルソフトウェア開発を開始するにあたって
　・製品に付けたいひとつひとつの機能を書き出す

■テストの重要性
　・test driven development（テスト駆動開発 ）
　　　テストを書く方が開発よりも大変
　　　ストーリーの起票と同時にテストを書く
　　　でもテストだけだとクリエイティビティが足りない
　　　　→pivotal trackerの話は直接出て無いが、pivotal trackerの使い方に沿った行動をしていることが分かる

　・continue as release ability
　　　開発=テスト　開発とテストを同時に進める
　　　ビジネスオーナーがリリースしようと言ったらすぐリリースできる状態がアジャイル体制の完成系

■期間を決めるとだいたいうまくいかない
　・締切に向かって進めるのとは違う
　・このスピードでいけばいつまでに何かができるという考えかた
　・ビジネスオーナーがストーリーのプロセスを追う

■ペアプログラミング（エクストリームプログラミング）について
　・プログラマーの8-9割の時間はどっかでひっかかってる
　　　→隣に人がいるとすぐわかる
　　　→ただボーっとしてる時間って結構おおい
　★プログラマーが増えても開発効率は上がらない
　・人を増やすのではなく、効率を上げる
　・いろいろな人とペアを組むと技や行動を覚える
　・新しく人が入ってもすぐ仕様のキャッチアップをしやすい

■アジャイルを進めるための環境づくり（pivotal labsでの取組）
　・会社で朝ごはんをたべる
　　　→エンジニアの生活サイクルを揃える
　・卓球などの2人で遊べるゲームなどのリフレッシュ環境を置く
　　　→ペアで休みを取りやすい環境を作る
　・メール見る場所が作業デスクとは別に置く
　　
■プログラマー・エンジニアはイノベーションを考えてはいけない
　・複雑にしてはいけない。シンプルを追う。
　・メンテナンス性を考える

■アジャイル（pivotal lab）は宗教に近い
　・pibotal labsはプログラミングのコンサルみたいな感じ

■チームにデザイナーをどう入れるか
　・基本的にテストなしでコードは書かない
　★プロトタイプのコードは必ず捨てる、製品にしない（デザインはいいけどね）
　・そのあとテスト付きで書き直す→仕様が全部わかる→リファクタリングしてシンプルにしていく
　　　→バグも含めて書き換える→何がどう壊れるかわかる

■アジャイルはリアクション（機能追加がはやい）
　・日本は遅い。世界と競争できるわけがない。

★ソースコードの長さは資産ではなく、負債
　・アジャイルは小さなパーツをちょこちょこ書く→思い入れがそんなに無い
　・金額がでかくなると捨てにくくなる
　・ソフトウェアを資産として帳簿上計上するのはおかしい
　・今まではソフトウェアを資産として考えていたが、アジャイルは負債と考える

★デザインが決まるとパラメーターが多く決まるのでウォーターフォールになりやすい
　・昔はデザインありきで、それをエンジニアがつくるという感じだった。アジャイルは違う
　・デザインはプロセスの一つ
　・技術者とデザインは一緒に考える
　★デザインは仮説
　・ユーザーを中心としたデザインを考える
　・デザイナーもビジネスオーナーも一緒にテストしていく

Q1：アジャイルはカスタマーからするといつまでに何がいくらかできないと判断できない
A ：アジャイルはいつまでに何ができるかという話はしない
　　　　→常に経営者と話しながら決めていく
　　　・自分のユーザーにいかに素早く近づくかがアジャイル
　　　・世の中どんどん変わる中で、普通の発注の仕方では間に合うわけがない
　　　・彼ら（海外の事業家、アジャイルのスタイルを取っている人たち）は毎週考え直してる
　　　・経営レベルで変わらないとだめ
　　　・SIerというコンセプトが存在しなくなる

Q2：お客さんが言った通りに作るのか、自分たちがクリエイティブに作るのか？
A ：pivotal labsはお客さんの言うとおりにしかやんないよ
　　　・コードを書く部分はイノベーションしてはいけない
　　　・海外のプロジェクトマネージャーは超SQL書ける
　　　　　→常にデータの分析を行っている
　　　・日本が海外のサイトを真似する場合、海外のサイトが消そうと思っているものも真似している
　　　　　→日本ってデータ使ってないんだねって思われてる
　　　★クリエイティブなアイディアはどんどんだしてもいいけど、残すかどうかはテストしなけりゃいけない
　　　★アートとサイエンスがちゃんとつながっている
　　　　　→デザイナーも技術の話ができるよ
　　　・データ寄りすぎるとクリエイティブなことできないし、データ見なさすぎると学習できないよ
　　　　　→バランス考えろ

----------------------------------------------------------------------

Pivotal labs
http://pivotallabs.com/

Pivotal Tracker
http://www.pivotaltracker.com/

Pivotal Trackerのはじめかた
http://agile.esm.co.jp/pivotaltracker/help/gettingstarted_ja

伊藤譲一
http://ja.wikipedia.org/wiki/%E4%BC%8A%E8%97%A4%E7%A9%B0%E4%B8%80

----------------------------------------------------------------------