はじめに
http://www.agilejapan.org/ 行ってきました。
遅ればせながら報告を...
基調講演1 アジャイル・テスティング〜チーム全体のためにテストとテスターができることを学ぶ旅
Janet Gregory さんの講演。先日アジャイルテスティングの研修があったんだよなー、行きたかったなー。
- p9-11:「砂場で仲良く遊ぶためのルール」＋「信頼をベースにした対話」が、複数の組織が協調して働く上でとても重要になってくる、という流れかなと理解した。
- p12,13:会場の参加者がペアになって、ひとりが絵を見て、もうひとりに絵の内容を説明するということをやった。うん、伝わらないものです。
- p18:自分たちも離れたチームの様子をWebカメラとディスプレイで共有して見たことがあるんだけど、うまくいかなかった。でもこの発表での例は、「○○さんといつも一緒に働いているんだよ」というメッセージをしっかり形にしていると思った。やるならここまでやる必要があると思う。
基調講演2 デジタル革命にはアジャイルがよく似合う
横塚 裕志 さん
- 競争優位は続かなくて、常にイノベーションを起こしていかないといけない。
- 大事な事：顧客、コラボレーション、見えること、漸進的に。
- 俺はトップダウンでやる、みんなはゲリラ的に下から突き上げてくれ。やろうぜ！
- 例えば、http://www.cefil.jp/ で経営者向けデザインシンキングのワークショップやったりしてます。
- http://www.cefil.jp/event/Design_Thinking_Workshop.html
この基調講演で大事なことは、これを横塚さんのようなキャリアを積んだ人が発しているということ。多くの人が勇気付けられたのではないかな。
C-1a ざんねんスクラムに立ち向かえ！スクラムマスター奮闘記〜エンタープライズでwaterfallな若手がスクラムを始めたら〜
内藤 優介 さん
む、これは、SPI Japan 2014の再演なのかな。とても素晴らしいスクラムマスターの事例発表だった。
- チームメンバーにとってプロダクトやプロジェクトが「ひとごと」になっちゃう問題は本当に根深くて、「引き出す」ための様々な「暗躍」は、自分の体験を重ねてみても、共感が持てるものばかりだった。
ご近所さんとのざんねんな部分がどう解決されていくのか、次回作を聞いてみたい。
C-1b 組織とスクラムチームのあいだ
椎葉 光行 さん、 絹川 達也 さん
http://www.agilejapan.org/2015/image/ConquerCIServer_AgileJapan2015_c-2b.pdf
http://bufferings.hatenablog.com/entry/2015/04/16/174742
Regional Scrum Gathering では、聞けなかったので、楽しみだった。
- 「僕がエンジニアとして働きたいチームを作る」目頭が..
- 目先の効率じゃなくてチームの成長を考えてアクションを選択するってのも、チームの中で影響力を持つメンバーが、チームの成長に温かな眼差しを持ってるということで、そういう関係性が素晴らしい。
- 全員でやる組織運営に関するもやもや出し会、いいなあ。
あるグループで実施されてたスクラムが、全チームに展開する流れ、知りたいと思った。
C-2a アジャイルな現場になっていく時の越えなければいけない3つのハードル
中村 洋 さん
-
導入の壁
-
「目線を上げる」ってのがグッときた。どうしたって自分を越える範囲のことを自分ごととしてコミットしていかないとまわらないわけで。
-
あーここで「期待マネジメント」かー。スクラムならDONE条件に落としていく感じ。
-
定着の壁
-
「慣れると腐る」も、「不安定を意図的に作り出す」も、とっても共感出来る。
-
拡大の壁
-
開発チームがうまく回せるようになるとボトルネックが企画チームに移る。Whyを考えるのは本当に難しいから、ボトルネックが移るからといって逆に強いプレッシャーをかけると良いプロダクトバックログができない。
-
でも実際ボトルネックが移ると、「ボロボロのアイデア」が出てくるので、結果として作ったものがビジネス貢献できなくて、まわりまわって仕事が減る。
結局ビジネスにも関わらないとよくならない、ということで「越境せよ」となって、中村さんの場合、越境していくため、コーチという形で開発とビジネス両方に関わるために企業した、って流れなんだろうか。現場が越境していくために泥臭くあがくあたりの話も聞いてみたくなった。
C-2b CIサーバを制圧せよ！-プロジェクトメトリクスと自動化技術の活用による、混乱の収拾と「最強」の組織の育成-
伊藤 宏幸 さん、直井 和久 さん
- 複数の機能型スクラムチームが共用してるCIのメンテどうすんの問題について。
- チーム提案して対応することにしました、という話。
- インフラチームにCIシステム導入を提案するときに、将来像も含めて進め方の合意を取るといいよ、というのはそうだよな。
B-3 クラウド時代のエンタープライズDevOps-ITがビジネスの足を引っ張らない。ビジネス・スピードを牽引するIT-
http://www.agilejapan.org/2015/image/B-3_DevOps_AgileJapan.pdf
戸田 孝一郎 さん
- スクラム/アジャイルやってたらTPSに行き着いたってのもすごいなあ。
- ITILでは、開発と運用は内部統制上しっかり分けましょう、となっていて、ここに断絶がある。
- 開発スプリントの大事なところが、ベロシティを安定させるところ、というのが、納得できなかった。実際は成長の中で変わってくるところだし、安定させるバイアスは、QCDを外部から設定する行為と全く変わらないと思う。
全体としてITILの文脈で生きている世界にどう引き継いでいくか、みたいな観点で、ちょっとDevOpsのイメージとは違った。
C-4 組み込みでもアジャイル開発
蛸島 昭之 さん
- DONEの定義はチームの成長やプロジェクトの段階に応じて変わってくるものだけど、そこに「ロードマップ」の概念を入れるのは素晴らしいと思った。
- アジャイルとは言えど、関連区はWFで、見積もりのばらつきを「見積もりをふかす」ことで抑制するという行為に出ざるを得ず、というところが「越境してない現場」という感じで苦しそうだった。
- Readyづくりは本当に難しくて、開発チームが見切り発車して、結果Readyも曖昧みたいなことがよくある。発表の事例では受入テストを書くという落としにしていて、徹底されてるけどコスト高そうな印象。テストとか、カバレッジとかもそうだけど、特定の観点だけで徹底するとコスト跳ね上がると思うので。
- 発表の事例では、受入＋単体でやりたいテストをカバーするという割り切りだった。プロジェクトの性質によって、ROIの高いテストのステージというのがあると思うので、納得。
- また、同じ単体テストでも、TDDで書いたテストと、品質保証するためのテストを分類して管理しているところが素晴らしいと思った。開発効率も落とさず、品質保証を自動化していくうまいやり方だと思う。
組み込みの人が沢山聞きに来ていらしたけど、どうだっただろうか。
所感
- 2014と違って、ひたすらセッション聞き続けるみたいな感じで疲れたけど、良い話たくさん聞けて、元気をもらった。
- 長丁場だったので、会場に飲み物とお菓子がたっぷり置いてあって助かりました。
- 参加者の大半がスクラム知ってたりして、なんかもう私達が取り組んでいることにアジャイルって名前つけなくてもいいんじゃないかな、という気がした1日でした。