デブサミ2008（アジャイルとか）

残念ながら急用が入って初日の昼過ぎまでしか居られなかった。でもJoelのサインはもらったよ。
結局、アジャイルとかの話しか聞けんかった。
以下メモです。

デベロッパーズサミット2008 2008/2/13

＊TPSに学びアジャイルを実践する
和田(富士通),
Toyota Production System: 成功事例
それをソフト開発に取り入れることによって開発し方が進化してくる
「越境」
ITの外である製造業のことを伝えたいと思って企画した

「エンジニア魂」

TPSとアジャイルの本質は同じ
価値観と原則は同じ
とくにXPとか。

世界的なアジャイル動向
見所：
社内でトヨタ生産方式をホワイトカラーに適用するのを推進している
わかってきたのはIT技術者にトヨタのことを知ってもらうと
いろいろ気づきがでてくる
こう変えていけばいい、こううまくいく、という気づき
2)の「TPSの本質」で片山さんというトヨタの人に
なかなかトヨタの人の話を聞く機会がない
それが一番楽しみ

13:10巨大、、がそれに相当する

3)は東芝の人にアジャイル開発の秀逸事例として話してもらう
７年前からアジャイル開発に取り組んでいる。
日本で一番じゃないか

4) 「TPSで進化するアジャイル開発」　1-3)の人のパネルディスカッション

開発者はアジャイル開発に興味が、上位職位の人はTPSなど他の性恋事例に
興味がある。その２つをつなげて上位職位の人が開発者を応援できるような
IT業界に。
開発者は、アジャイル開発として、TPSという燃料を投下してPDCAをまわしていくように
してほしい

＊海外におけるアジャイルの現在 / チェンジビジョン　平鍋氏
最初オブジェクト指向おたくだった
なかなか品質があがらなかった
デザインパターンとか色いろなソフト作り方が出てきた
ところが、いい技術を使っていいプロセスで作ってもいいものができない

2000 XPプログラミング
一緒に居る人がいいものを届けたいという気持ちがないといいものができない

いいものを作ることを１０とするとそのうち半分はいいものを作りたい
という気持ちが重要になる

・アジャイルの現状　Agile2007
・TPS/Leanとアジャイルの関係
・リーダーシップの役割
　人のことに言及しているのがアジャイルの特徴
　チームの方に向いていた。チームとコーチ。ファシリテータ型
　実際に新製品開発だとコンセプトやひとりの人の能力がクローズアップされる
　ひとりの人に焦点があたっているのがリーン開発
・価値で分割する
・リーン開発

・www.agile2007.com
プログラム
アジャイルの話を一週間している

Google, Yahoo, Salesforce
ユーザ企業、内部にITを持っている　が自分のビジネスでITが競争力として
重要なら自分たちのリソースで人を育てていこうとしている。
日本だとSIerが来て自分で下請けとかに適用している
みんなでいいものを作ろうという場をつくりにくくなっている。

アジャイルの現在位置
2000年のXPがきっかけ
2001年、FDD, Crystal, DSDM, ASD, SCRUM...
それをまとめて2002年ごろAgile。Agile宣言

テスト駆動開発
 AgileとLean（≒TPS）とが交わってムーブメントになってマネージメント
と一緒になって顧客価値に注目してそれをスタートから出荷まで早く流す
やりかたを考える

・Lean: TPSに端を発している
「世界を変える機械」
LeanがXP, SCRUM, TDDに影響をおよぼしている

2007年で注目されているのは、
・Enterprise：どうやって大きな企業でやっていくか
・People: ソフト開発ってエンジニアリングとマネージメントってな流れが
90年代にあった、いかに管理し、未来を予測し、ガイドラインを作るか、てな
流れになってしまいがちだった。
それをpeopleという視点でソフトを考えないといけないというのがAgileが発見したこと
・Test-Driven
ユーザの受け入れテストなんかも自動化
TDDの流れがあって、TDDD データベースもテストベースで作っていこう
テストもそもそも仕様。Behaviorをコードで書くことでコードをデザインしよう
・Lean and Agile

Enterprise：Agileをどうスケールさせるかがテーマ
アジャイルとxxxは矛盾しない！　というトーン

People
Leadershipは大きい。fascilitation, education,
trust building
Collaboration

Test-Driven:
BDD, TDDD
Rails and Agile

AgileをスケールさせるKanbanの可能性
Conference within the conference：勝手カンファレンス
Kanbanを使ってsustaining engineeringというのがあった
Kanbanはひとつ波になりそう
後工程を引き取りさせるための作業指示、在庫指示
フローが起こっていることがわかる。
それで見える化しようという考え

Mary Poppendieckのリーダーシップ
InfoQ ?
TPSのおおのたいちさんなんかの話をしたいいスピーチ
標準は現場作らないと、標準は今やることのベースライン
それが変わることは意味がある。
それが変わらないのはマネージメントになっていない

InfoQに２つ記事を書いた
Kanbanについて

・Agile/Leanとは何か
価値流をつくって無駄をなくす
価値を定義したら、製造から出荷までの流れを作る。
その間に在庫をもたせない、スムーズに流す
waterfallはLeanとあいいれない

対応するAgileのキーワード
ビジネス価値
テスト駆動
タイムボックス
価値(MMF)を流す
　Minimum Marketable Feature
　これだけで嬉しいという価値
繰り返し型開発

価値から無駄をとっていくところは人間が気づいたことを
改善の提案としてやっていく。

TPSとソフト開発のコンセプトマップ

必要なリーダーシップの種類
官僚的管理者
グループファシリテータ
作業管理者
学習する組織のリーダー

ソフトで一番求められるのは
学習する組織のリーダーではないか。

自分が長くやって自身があある。他の人を考えて動かすような人が
これからのソフト開発に必要ではないか。

受託ベースではなかなか難しいけど
作業管理と作る人が基本的に分断されてしまう

製品開発になるといいものを作るのが難しい
トヨタはチーフエンジニアという制度があって
その人がコンセプトから全権限を持っている

ビジネスの理解と技術の理解は別だけど、それを
二人が話するのだとうまくいかない。
それを一つの脳でするのを一人連れてきてそれを中心のプロジェクト組み立てなさい

価値を流すという話

Agile開発のよさ：
機能が
A,b,C
それぞれを別々に作ってサービスをする

よこに並べると反復的
縦に並べるとincremental

昔は別々にわけて作るのが難しかった
今は投資自身が個々の機能ごとの市場価値を知りたい
出来るだけ早くリリースする要求がある

これができるようになったのはAgileが流行った理由
リファクタリングがagileを支えている

テスト容易性、変更容易性がソフト開発に重要なのではないか
…オブジェクト指向的

機能ごとの開発ができれば、価値を一つずつ無駄なく製品まで流せるようになる。

「リーン開発の本質」
人が中心
ソフト開発の特徴
　変更を予後なくされる。それはソフトの宿命。
　それが開発、生産ではなない。きまった仕様で作るのではなく、考えながら改善する
エンジニアは大きな絵に参加しないといけない
　自分が関わっている小さな絵だけ見るのではなく
　
Agile, Agile言っている人はアジャイルサイロ、周りと遮断して立っているだけ
周辺とつながっていかないと

価値を引っ張り出す企業の手法がリーンであり、アジャイル

＊新車開発―巨大プロジェクトマネージメント / 日立片山氏
自己紹介、新車開発
18年トヨタで設計ばかりしていた
モータースポーツ、WRC 4年間
その後10年間
トヨタがシェアを落としたとき、
同じような車しかない若い人向けのがない、というのに対して
開発のチーフエンジニア
アルテッサ
 レクサスIS
　その前半でも
チーフエンジニアが海外に行って試験に参加したり

新車開発
Phase1 企画、先行開発
Phase2 実車開発
Phase3 生産・販売促進

作るほうでいろいろ言われているけど、それに
負けず劣らず、Phase1にとても力を入れている
そこで性能や収益やアピールポイントがきまる

Phase3では販売の支援

Phase1で早くて１年、レクサスだと２−３年、いいコンセプトで次に渡す
Phase2は１年
６年ぐらいのサイクルで製品開発

Phase1: 企画・先行開発
1) 車両コンセプト
　客に聞いても自分に都合のいいことしか言わない
　グローバルだと混乱するばかり
　実際には、1),2)をチーフエンジニアを中心に決め、それを社内で何度も議論
　確認をしにマーケットリサーチをする
2) スタイル(エクステリア、インテリア)の決定
3) マーケットリサーチ
4) ユニットの先行開発
5) 原価・利益の目標設定
　営業サイドが第三者の目で決める
6) 開発費、必要工数、設備投資の目標設定

コンセプト：
アグレッシブで洗練された内部デザイン
言葉だけをA4に並べて、次のコンセプトはこうです、というのをやっていた
でも同じような車ばっかりできてしまう
マインドを自分の作りたい車にあわせてもらう
バックグラウンドを共有するための映像イメージをデザイナーと決める
品質面でも自分のメッセージを関係者にしっかり伝える
言葉だけでなく

デザインは？
初代のアルプレッサ
フロントのデザインの最初の発想は高級時計、意匠開発もそこから

Phase2: 実車開発
設計試作評価：近年は１サイクル、超短期開発
設計
CAD アイデアだしは手書き、

レーンチェンジしたときのボディーの変形をシミュレーション解析
車はテストコースだけでなく。日本では認可が大変なので海外に行って
いろんなところを走って。

Phase1
企画先行開発
出発点　仕込み、感性、Creation
複数チーム異なる環境、合格するまで
Phase2&3　実射開発、生産、販売
単独チーム、短期集中、大日程(マイルストーン)管理

Phase3
1)生産
2)認証
3)販売促進
4)初期市場調査
　商品・品質についてリサーチ

・巨大プロジェクトのマネージャー
＠企画コンセプトマネージャー
プロジェクトのバックボーン
明確なアピールポイントの設定
満足いくまで練りこみ
　完璧なコンセプトを目指す
　何回もやりなおし
　多くの人が納得いくまで
　スタートがしっかりしていないと負けてしまう
広い視野から複数案を検討
全体を　スルーで　○△×評価
見切り発車をさせないルール
先輩など第三者を入れた冷静な検証
　各国の意見も聞いて

＠開発進行マネージャー
強力な専任リーダの設定
　尊重する組織体制
　多くの会社は役職の加太が着がおおくて
　経理、営業、製造で壁をつくってしまいがち
　リーダは調整する役にしかなっていない
　２４時間考えられるような形になれば、みんながそれをリスペクトするようになる
　　そのためにはそのように人間がならないといけないのだけど。
明確なマイルストーンの設定
　クリアーさせる支援体制
　クリアーしないと行かせないルール
手遅れにさせない体質作り
　第三者トリガー
　本音のコミュニケーション
　悪いことほどすぐ報告する体制
早期の確実なバックアップ案検討

＠リソーセスマネージャー
１）人
自転車操業に落ち込まない、見える化　管理
実力値を下敷きにした個別割り振り計画
人数管理からの脱却（個人から組織管理）
　ユーザの要求が昔よりずっと多くなっている
　スピードも求められる
トヨタでは全部のプロジェクトを時間管理している
　前までのデータに基づいて時間で管理
2) 金
実力値を下敷き
　個別割付、個別目標化　見える化　管理
リーダーがバッファを持ちリスク対応
　実績値から割付　やらされ感の解消　達成感
　
＠製品コストマネージャー
原価低減＝収益確保　会社が成長できない
グローバル競争、前者・全員で共有化
見える化、聖域なし、どんなときも誰も
弱音は言わなく　強力する環境つくり
2) 原価の過去・現在のデータを解析、整理
　下敷き化　こべつ　目標設定・割付
　一歩一歩の積み重ねを図る
3) Value Engieeringは会社の技術力そのもの
　性能・品質・価格競争力はどれも同じぐらい重要、全部が必要
4) 原価の責任分担（実務と責任がリンクしない限りできない）
　全体目標を全員で割付・個別目標を設定
　全体で達成　リーダーは割付・調整に責任

5. ベンチマーク活動
1) 敵の戦略を知り、それに勝る商品を開発するため
　他者の技術をコピーする、との意識は卒業
　負けているところに注目、その上を行く製品を開発
2) 時間差を加味し開発品の性能目標を設定
　購入品は2-3年前の設計品
　開発は1-2年後の製品　3-5年の時間差を考慮
3) 継続的な優位性の確保のための戦略策定

OBとして一言
＠できるまでやるvs 時間までやる
この業務は彼がやりました、と言われるようになっていただきたい
＠大学ノートvs提案書
若い人が何を言ってるのかわからない提案書や報告書を出すことが多い
＠どんなこともあるレベルを越えればきっと役立つ
中途半端は何も残らない
やればやるほどきちっとやれば何かが残る
＠戦争をやる人vs見る人
何人も私をモータースポーツに入れてくれという人がきた
実際に戦うとずっと大変
なかなか勝てない、するといさかいが起きる
＠気分転換、健康
１−２年のプロジェクトに全精力をそそぐことはつらい
新たなマインド、チャレンジ精神を生むために
忙しいからこそやる　意識的な気分のリフレッシュ

＊Accelerate Software Delivery with cotuluous Integfuration adn Testing
Agiter soft Kevin Lawrence

Contunuous Integration (CI)
・What is CI
・CI Practice
・Impact of CI
・Toolset

What is CI
featureを作った-> test
Ckeck in -> Source Repos.
CIがないと、チェックインそのものに使用まで時間がかかるかも
ミスがあるのを知るのもずっと先になる
CIサーバはチェックインした段階で自動チェックする
結果をe-mailで開発者に伝えられる
開発者はすぐにfixにとりかかれる

Reducing cost of mistakes
・Manual CI
・Automated CI
どちらも不具合によるコストを減らすことが目的

テストにかける時間が２分
バグが見つかって、調査、レポートするのに１０分
バグが見つかるほどテストの時間が減ってしまう

90分のセッションだと
バグが見つかれなければ45回テストができるだろう。
１つバグが見つかると10分→9つバグがあればそれで90分かかることに

CI practice
テストを最大活用するにあたってCIをどう使うか
フィードバックを削減するために複数のビルド、フィードバック

テストの回数が多いほどバグは見つかる
完全なテストよりも。

ビルドのデザインをすることはとても重要
quick build
< 10分
system test
＜ 1時間
nightly test
official build

Agiterでは
14台のサーバがCIに使われている
106の buildが定義されている
1モジュールについて1日ごとに平均7つの
定期的にQAにリリース

バグの発生状況を見える化
Lavaランプ
誰もが見えるバグ状況モニタ

Detailed Analysis
JSP reporting application
Managed testing

IEEEの調査で36%のバグの低減
agiterの客の声から
QAに届いた時点でのバグが90%減った
バグのコストが95%減った

開発者側のメリットとして
より早くマーケットに投入できる
ソフトをリリースする上で自信を持てるようになる

toolset
・CruiseControl sourceforge.net
CIのオープンソース
柔軟性が高い
・CruiseControlの拡張
3rd party
in-house script
・AgitarOne integration
ant task
reporting

cruisecontrol.sourceforge.net
www.junit.org JUnit
www.junitfactory.com JUnitFactory
www.stickyminds.com
www.martinfowler.com CIを開発した人のブログ
developertesting.com Agitarのブログ