Agile Japan 初参加でしたが、行って良かったです。
現場に持ち帰るヒントを整理するために、エントリ書きます。
togetter:
http://togetter.com/li/685350
http://togetter.com/li/685351
以下、私が参加したものをご紹介。
基調講演：ソフトウェア開発者に問う ～日本人のモノづくりの本質とは～
元日産GT-R開発総責任者の水野和敏さんが登壇。
ご本人も講演中何度かYoutube上に過去の講演の動画があるから観てくれたら良い、とおっしゃっていたので、リンクを：
https://www.youtube.com/watch?v=DR36d-JrKvY
https://www.youtube.com/watch?v=bUHNE_Ki3yw
https://www.youtube.com/watch?v=jzxuxtQf0ok
https://www.youtube.com/watch?v=_rR9MyLpgy8
https://www.youtube.com/watch?v=m1ND2etacQw
https://www.youtube.com/watch?v=WnsVZnbJtXQ
https://www.youtube.com/watch?v=HMWQg-YodlM
(これはあとで自分で観るためのメモ http://www.ustream.tv/recorded/18772394)
まとめ系
http://matome.naver.jp/odai/2136887988617560701
今回の講演も、基本の流れはYoutubeのものと同じでした。
しかもいい感じにまとまっている過去の講演の記事も発見...何か書く元気が失せて来たw
http://monoist.atmarkit.co.jp/mn/articles/1402/19/news024.html
以下、講演の順序をちょっと入れ替えています。
レース監督時代
スカイラインとかプリメーラとか作ってたのに左遷させられて、しかもタイトルを取らないとチームは解散と言われた。
会社の考えは海外の一流の会社に車作らせて、日産のレーシングチームで走れば世界一が取れるというものだったが、実際は文化、距離、お互いのプライドから、チームになれていない状況だった。
そこで水野さんは以下の様な手法を採用した：
- チーム編成では、人数を250名から50名に削減。
- 現場に権限を委譲、さらに分業体制から兼業体制へ。
- 予算も大幅に削減。
- データ分析を重視し、レース全体でどこを改善すべきかを事前に洗い出した。曰く「レースはサーキットでやるもんじゃない。ホームワークでやるもの」
で、全戦全勝したら、レース自体が無くなった。
水野さんの「リソースを制限した方が良い物ができる」という考えは、本質に素早く辿り着くための凄い劇薬ですね。
プロダクトビジョン
GT-Rでは、日産自動車の枠を外れて、「日本のものづくり」を提案したかったとのこと。
リーマンショックで高級車が売れたが、当時日本は、良い商品を持っていなかったので、東南アジアで安い車を売る戦略になった。このままでは、日本が安物商品を作る途上国向けの生産国になってしまう。今こそ価値ある物をつくるべき、と考えた。
プロダクトデザイン
スポーツカーにはアートの側面がある。GT-Rはどう見てもセダン。でもそれが日本らしさと考えた。
- 「スーパーカーじゃないものがスーパーカーぶち抜いたら凄い」
- 普通の人が不可能だと思っている物を作るのが日本人
ストーリーも大事にした。ストーリーを大事にすると、細かい属性は自ずと定まる。
- 欧州のお金持ちはお気に入りの車で保養地までビューン。でも荷物が載らないから奥様は別途飛行機で移動していた。荷物もロストするかもしれない。仲の良いお金持ち夫婦が、夫のドライブで保養地へ行けるようにならないか。
こういうストーリーを、共有する作業を徹底した。
チームづくり
普通のプロジェクト標準でやりたくなかったから先行開発に逃げていたら、全部やれと言われた→権限はいらないが、全責任を下さいと言った。
(当時は1プロダクト3トップ制だったそうですが、結果、水野さんは特別に全権を得たそうです)
良いものづくりのためには、企画、設計、販売、サービスが一体となっていることが重要で、コンテキストが揃えやすい日本ならそれができると考えた。
- 例えば、GT-Rは6店舗でしか取り扱っていない。セールスもメカニックも直接教育で、故に水野さん（プロダクトオーナー）の代弁者となりえている
生産性について
未来の目標を共有化すると、最高の仕事ができる。
単なるトライアンドエラーはダメ。無駄なだけじゃなく人が死ぬ。予測してOKなことをやる。
何故効率が良いか？エラーが無いから。
- 例えば一人一人の業務分析をして、改善する。厳しいけど、頑張ってね、では経営層は仕事しているとは言えない。
コストについて
技術開発で原価を下げるか、現地開発に投資して原価を下げるか。
現地開発に投資すると、技術はある時点の妥協点を探ることになる。つまり低きに流れ、結果として、日本の質が落ちる。
技術を高めて行くべき。
品質について
ドイツ車がリコール少ないのは、国が素晴らしいテストコースを提供して、さらに開発車ナンバーで公道を走れるようにしていることで、様々な条件下で試験できることが一つ。
もう一つ大事なのは、テストドライバーはマイスターとして国から評価されるということ。ものをつくることに希望があり。技術者は会社を変わっても怖くない。
設計について
ものづくりで一番重要なのは現場。現場が最上流。車で言えば工場の能力が設計を決める。
JIS、ISOの基準よりも良い物を作り出そうとする時、重要になるのは現場との共通認識になる。おっちゃんの腕を活かし、現場の技術開発とパラで進めて行く。
部品メーカーはどこの会社にも同じ物を出す。しかしそこで終わっていてはいけない。実際には車の出来は会社によって違う。アセンブリメーカーの腕の見せ所がある。
新規事業のリーダーシップ
合宿は重要だが、何事もまず最初に一人で考えること。
ユーザーストーリーが重要。言葉ではなく、イメージを共有しよう。
やったことのないことをすれば、現場は当然失敗する。そのためにどんな責任を取れる様にするかだけを考える。
働き方
職業を社会的使命（こういう仕事をしよう）で選んだ事を忘れてはいけない。会社は実現手段でしかない。
趣味で仕事をするのではなく、人のために仕事をすべき。人のためなら、目標を共有する事ができる。己を捨てないと人が入って来ない。
人のためになら、アイデアが出る。そば屋さんは一番のそばを客に食べてもらいたい。自分はまかない。
落ち着いて失敗すること。責任は採用した側にある。
自分が見えなくなるとキャパを越えて無駄な時間を失う。
エンタープライズでもデキるアジャイル開発
最初に平鍋さんによるCI&Tの紹介があって、メインはCI&Tの上田さんの講演でした。
平鍋さんパート
ソフトウェア開発あるある
受託側
- この詳細設計書意味あるの?
- 俺この機能絶対使われないと思うんだ...
受託側（マネジメント）
- それは別途お見積もりです
- 仕様書に書かれておりません
委託側
- 書かれてないけど、普通、考えたら分かるでしょ（行間仕様）
- できるって言いましたよね？死んでもやってもらわないと困ります
CI&T紹介
CI&T Pacific はブラジルが本社でアジャイル100%の受託開発。
- 2007年まではCMMI Lv5の企業。
- 2007年からAgile 100%に。「LEAN IT」
- 40%が海外からの受託。
- タスクはredmineで管理し、1week分だけ壁に貼り出す。
- 受託している企業の看板や商品をチームの近くに配置する。
- お客様とあけたシャンパンの蓋をためている。
- 英語教師に常駐してもらい、困ったら相談できる様にしている。
上田さんパート
資料が公開されています：
http://www.slideshare.net/yoshiyukiueda/agile-japan-2014-cit-deck
以下、大事だなと思った事。
重要な前提
- 結果としてアジャイルになっているだけ
- 無理な計画は、何やっても無理
見積もり技法
結局チームの規模見積もりが根底にあるので、そこにPERT法をするにせよ、過去の成績から初速の調整をするにせよ、「開発前に契約できる程に高精度」ということに対しては慎重に受け取らないとな、と思いました。開発前に見積もれる＝請負できる程度ににチームに経験が揃っているという事で、それってWFでもできるよねって話になりそうです。
やはり定期的に見積もりを修正することしか近道はなく、
つまり請負でやるときは、どうしてもしっかり安全マージンをかぶせないと死ねるのは変わらないと思いました。
上田さんも、請負で進捗が悪くなったら、会社としてリカバリする、とおっしゃってましたし、請負でアジャイルできますよ、マジで？と食いついた人は、肩透かしだったのかもな、と（→重要な前提の２に戻る）。
あとスプリント１の初速が85%って、スゲー！と思いました。開発のための基盤がしっかり整っていて、過去チャレンジしたネタと似た仕事をどんどん受託しているケースに限られそう...そしてそれってWFでも...と無限ループしそうw
アジャイル開発の4つの誤解と4つの落とし穴
藤井さんパート
古い常識にも背景や狙いはあるので、古い常識を身につけている方々とどのような信頼関係を結ぶかが大事という話でした。特に、
- 専門家として巻き込む
- インセプションデッキなどでわかりやすく関係者とリスク管理する
ことが挙げられていました。
川口さんパート
会場の参加者を、
- イノベーター
- サポーター
- エヴァンジェリスト
- 推進者
に分けて、それぞれの課題を付箋にかいて、それを藤井さん、平鍋さん、川口さんが読んでアドバイスする、というワークショップ？でした。
鉄板アイスブレイク良かったです。
アジャイルすると、コストが下がるの？
- 帳簿上の金は変わらない。時には寧ろ多めにかかったりする。
- 一方、与えられた時間の中で無駄な事を徹底してやらないように活動するのは明らかなので、「良い金の使い方をしている」と言う事ができる。
継続的デリバリーの実現へ！〜最新クラウド型アプリケーション開発〜
IBMの江木さん
後半は製品紹介でしたが、前半のDADとSAFeの説明が分かりやすかったです。
エンタープライズのコンテキスト
いろんなことを考えることになる：
- コンプライアンス
- 大規模
- 地理的分散
- 企業のルール
- 組織の関係（縦割り、硬直）
- ドメイン
- 技術
DAD
Scrumを時間軸で拡張したもの。
- 方向付け＋Scrum＋カットオーバー、移行
- 分散チーム(Scrum of Scrum)は考慮されていない。
SAFe
Scrumを組織階層の軸で拡張したもの。
- 複数のチームで協働する事を前提としている。(Scrum of Scrum の実装の一つ)
- ポートフォリオのScrum+プロダクトのScrum+開発チームのScrum
- DADの方向付けはプロダクトのScrumに入る感じ。
クラウド型アプリケーション開発を支える技術
クラウド型アプリケーションの様に、分野によっては、開発環境や動作環境、開発人員が簡単に調達できるようになったので、必要になった時点で必要なリソースを必要なだけ調達するpull型の開発がやりやすくなってきている。
そこで製品紹介へ！（完）
Embrace Change for Unchangeability. 〜エンタープライズのためのアジャイル〜
グロースエクスパートナーズ株式会社の関さん、和智さんの発表。
個人的には生和智さんが観られて大変満足。
関さんパート
新規系の受託アジャイル開発について
品質モデル
SO/IEC 9126-1の品質モデル、利用品質の所が複数あるところがミソ。
リリースを繰り返して利用品質の検証を繰り返す事で、他の品質との内部矛盾を解消して行かないといけない。
UX設計
以下の４つに分類できる:
- インタラクションデザイン
- ビジュアルデザイン
- ラピッドプロトタイピング
- ユーザビリティテスト
(IAとかアクセシとかはどこに位置づけられるのかな..)
アジャイルとスタートアップ
- イテレーションが2,3日のレベルになるから、Scrumとか向かない。
- Scrumは管理工数がかかるので、その工数も計上しないと赤くなる。
- イテレーションが始まる前に要件の確定は無理。要件決めも課題として存在していたりする。
最後に。プロジェクトを回している関さん自身への負荷のかかり具合が、全然うらやましくなかった...
和智さんパート
リプレース系の受託アジャイル開発について
前提
リプレースなので、基本的には期限までに全部作らないといけない。
- 外的要因
- 競合
- 技術
- エンドユーザ
- 内的要因
- 人のいれかわり
要因が変化しても、変わらないためのリプレース
計画
大きく構築して細かく調整が基本。そのために：
- 決めすぎない、投げ出さない
- 手広く（将棋の用語だそうです）、選択肢を残す
アーキテクチャ
実際のアーキテクチャは、採用する技術に理解があり、応用できるエンジニアがどれくらいいるかで決まる。ほぼ人数比が、採用できるコード比率になる。
（このへん、水野さんの話に繋がるな...）
- 固定変動設計
- DDD(キター)
- 野球のグラブ。基本分厚いけど、柔軟性が必要な所はちゃんと柔らかい。
プロセス
WFからショートリリースへ移れるか？
- タイムボックスができるようになるとスムーズ（リズムができているということ）。
- 過渡期のコントロールが一番難しい。
一言
個人的には、水野さんの話を聞けたのが一番の収穫でした。
異業種のトップエンジニアの話を聞くというのは、得られる学びが沢山ありました。
これからもいろんな業種の人の話を伺ってみたいです。