オブラブ夏イベント 2009 に参加しました。

平鍋さんの90分、t-wadaさんの90分、どちらもすごく良かったです。
(午後2はすみませんちょっと気が抜けてしまってLT準備してました。)
moroさんのRSpec/Cucumberはt-wadaさんとkakutaniさんと瀧内さんの熱い議論(内容理解できず)がすごかったす。

懇親会は世界の平鍋さんにおごっていただきました!!
ごちそうさまでした!

ライトニングトークしてきました!
参加賞のPokenいただきました!(もっていたのでuedaasakoさんに進呈!)
資料貼っておきます。

関さんの dRuby本をいただきました!
(持っていたような気がするのですが、読んだ記憶がおぼろなので読み直します!いつかサインしてもらうんだ!)

- - -

平鍋さんの講演を聞きながら取ったノートです。
たぶんPDFが公開されますのでそっちを参照していただく方が良いと思います。

* 今日はガチにアジャイルの話をします
* オブジェクト指向を現場でちゃんとやる、というのを強く念じてプロジェクトに取り組んだ
* しかし、技術をいくら突き詰めても問題の半分も片付かない
* ほとんどの問題が、人のコミュニケーションだったり、モチベーションであったり。技術というものでは語れないものに
* XPに出会った。
* Kent Beck: social engineering 人と人との関係、コミュニケーション、チームをどう作るか。
* ヤコブソン
* 日本のソフトウェア開発に入ってくる若い人たち、ここにいる人たち、現場の人たち、をより生産的にするために
* プロセスとしてのAgile
* Waterfall (Royce 1970)
* ロイスが提案したときには、「後戻りしなさい」
* Agile (Beck 2000)
* 短いサイクルで、分析、設計、実装、テストを並列に行う
* 作るものがわからないので、動くものを確認しながらすすめる (リスクの回避)
* 日本の現場で多いのは、分析-設計 までは調子良く、実装もうまくいく、で、テストで火が噴く。火のついた爆弾をまわしているようなもの。Agileは爆弾を小分けにして、どんどんまわす。一回目失敗してもだんだんうまくなる。
* Agileの価値観 => Agile Manifesto
* ミッション・リスク分割型ビジネスとウォーターフォール型開発
* 市場 -> ビジネス -> IT -> ビジネス -> 市場
* ターンアラウンドタイム: 半年から3年
* そんなに待てない
* 契約が発生: 言われたものを作れば達成される
* ビジネスとITで、ミッションとビジネスのリスクが共有されない
* 使われない機能が増える (要求の劣化)
* 契約期間が決まっているので、できるだけ多くの仕様を入れる
* やっているうちに、ビジネスが変化する
* 要求をうまく理解できていないのに作ってしまう
* ミッションリスク共有型ビジネスとAgile開発
* [[[IT] ビジネス] 市場]
* ビジネスとITが一体になった「One Team」を作り、ミッションとリスクを共有する。
* 反復・漸進開発 = Agile
* 昔の開発環境ではAgile開発が難しかった。機能A-機能Bが絡むために、作りながら内部を変える必要がある。これはオブジェクト指向技術、リファクタリングIDEの進歩の結果。
* オブジェクト指向技術が、再利用技術ではなく、変更のための技術として再認識された
* 米国のAgile市場の特徴
* ユーザ企業が戦略的にITを利用している
* Yahoo!, Google, Salesforce, PatientKeeper
* 日本のようにSIerに開発丸投げということはない
* コンサルタント、コーチ(現場に入って人を指導)が多く、導入支援。
* 日本でもコンサルタントが増えれば
* Agileは本では伝わらない。現場や文化を知っているマネージャと合意形成して、そこに会うようにしなければ
* それえも、メインストリームにはまだなっていない
* 採用率25%程度か (2008年)
* Agile現状調査 (VersionOne: 世界80か国)
* Agile の支持層: VP / Director of Development (25%)
* 使っているAgile方法論は
* Scrum 49%
* Scrum / XP hybrid
* 使っている方法は: プランニング、朝会、ユニットテスト...
* Agileの成功率
* Agileの成功/失敗原因
* Agileの不安
* 生産性、品質、TTM(time to market)、コスト
* コストについて改善した例は少ない
* リスク、変化への対応性、可視性
* リスク : 最後までわからないWaterfall
* 変化への対応性 : 途中から変更できないWaterfall
* 可視性 : 途中の可視性が低い(丸投げ) Waterfall
* 可視性を高めるためには、受け入れ側のコミットメントが必要。デモに出てもらうとか
* Salesforce
* Everyone jumped in together (トップダウン)
* Create a dediated, cross-functional rollout team
* どんどんリリース間隔が短くなった
* IT部門に発注する、というモデルではもう間に合わない
* Mike Cohn がコンサルタントとして入っている (フルタイム)
* Scrum
* 日本のAgile市場の特徴
* 小規模が多い
* ユーザ企業主導になっていない
* SIerが一部トライしている
* 中規模受託開発会社も一部トライしている
* パッケージ開発に多い (ステークホルダが少ない)
* 事例
* 富士通
* リクルート: SWAT
* 要件確認会議: 意思決定
* 持ち帰り禁止。70%の確率で
* とにかくいったん決める
* 良品計画
* スピードがすべてを駆逐する
* 試作して、観てもらって、フィードバックを入れて、完成する
* 一回使ってもらうことで使う気になる
* フィードバックを入れることで「俺が言ったことがちゃんと入っているじゃないか」
* 聞いてみるとアジャイルに近いやり方が多い。
* コミュニケーションが重要
* 伝言ゲームが一番うまくいくのは、会って話す
* 要求仕様を100ページ書いても伝わらない
* ユーザが欲しいなと思ったものを作ってあげる
* Agileのスケール方向
* 米国の構造: ユーザ企業がシステム部門を持っている。世界分散
* 日本の構造: システム部門 -> SIer -> 中堅ソフトハウス (多段下請け構造)
* この中でどうやってミッションを共有できるか
* どうやって、Win-Winになれるように契約するか
* みんなで話すことから始める
* Scrum vs Kanban (Henrik Kniberg)
* Scrumban (Corey Ladas)
* MMV (Minimum Market Value)
* 小分けにした爆弾
* ユーザの言葉で表現
* ヤマハモーターソリューション
* これとか、こことか
* 指差せるようになるカンバンの力
* 企業価値につなげるAgile/Lean
* トヨタから学び、アメリカで思考フレームワークとして作られた (りーんソフトウェア開発)
* プロセスさえも変えながらソフトウェアを作る
* 投資効果のある、ちゃんと動くソフトウェアを、期待された期間内に、ムダなく作り、維持・変更し続ける。
* ソフトウェアは、人が人のために作っている。
* Lean Kanbann Conference (UK)
* ソフトウェア・クリエイティビティ
* 七夕:
* 上司と対立した。受け入れられないことがあった。
* => コツ
* 開発者、管理者、お客様... 役割でもって話をするとうまくいかない
* 人の名前(お客様の田中さん)で考え、その人と話す
* なぜこの職場にこの人はいるか?生身の人間として理解する
* 対立事項で話さない。もう一個上位の目的は合意ができる。納得できる最下層の上位目的まであがって、合意する。
* 人生。その人と話をする。
* あたりまえのことをやるために、近い人といっしょに始める。自分の周りから。