地図を捨ててコンパスを頼りに進め 楽天株式会社 藤原大

@daipresents藤原 大•楽天株式会社 開発ユニット アジャイルグループ マネージャ•プロジェクトファシリテーター、トレーナー•趣味は沖縄離島巡り•実家は箕面市牧落

http://daipresents.com/

Agile Conference

Agile Conferenceには2010年から参加しています。記事を書いたりFacebookページを作ったりして、ちょっとでも自分が好きになった雰囲気が届けばなぁと。今年書いた記事はこちら => ManasLink - EM ONLINE http://bit.ly/QlZy9N

集え、日本の活動家たちよ。

Ultimate Agilist Tokyo 11/17 開催！

http://ultimateagilist.doorkeeper.jp/events/1823

集え、日本の活動家たちよ。

Ultimate Agilist Tokyo 11/17 開催！

http://ultimateagilist.doorkeeper.jp/events/1823

宝探しAgileゲーム - 安井 力 氏アジャイルプログラマの定義は俺たちが決める。そして、最速でそうなってみる - 牛尾 剛 氏アジャイル×テスト開発を考える - 細谷 泰夫 氏TDDと組織文化 - 天野 勝 氏家電商品を開発してみると目からウロコなAgileの本質 - 前川 直也 氏Ruby on Railsによるアジャイル開発事例と注意点 - 川端 光義 氏The Art Of Agile ProjectManager - 市谷 聡啓 氏Can you keep doing that? - 原田 騎郎 氏アジャイル開発における、システムテストの自動化 - 小井土 亨 氏リアルウェア - 濱 勝巳 氏アジャイルに対する見方の変化 - 太田 健一郎 氏これまでの開発から、これからの開発へのチェンジ - 倉貫 義人 氏テストを支える。テストを育てる。 - 井芹 洋輝 氏「ふりかえり」をふりかえってみよう。 - 串田幸江 女史

http://www.flickr.com/photos/lombre/3052877393/

SIerでした•Javaエンジニア•業務向けWebアプリ•二次受け•一人でドナドナ•ほとんど滝

上記以外にもサービスはあります。これだけいろいろなサービスがあると開発方法も様々です。

アジャイル支援歴•リプレイス6ヶ月•リプレイス3ヶ月•若いサービス10ヶ月

私のチームごとサービスを担当するチームに合流し、席を並べて働きます。週1回とかじゃなくて、毎日一緒です。

登場人物プロデューサー

エンジニア 私

開発の流れ

•PROがアイデアを練って•ENGが実現する•この回転を支援

朝礼の風景

はじめは私がファシリテーターとして運営し、徐々に周りに移譲していく形が多いです。

12

今日のおはなしl 開発のチェンジl マインドセットのチェンジl 変化から習慣へ

今日のおはなしl 開発のチェンジl マインドセットのチェンジl 変化から習慣へ

すぐ見えた壁•なぜかWF•開発スキル低（若者多）•一体感の無さ

考えなおしたこと

計画と仕様

問い

仕様書は正しいのか？

photo - http://www.flickr.com/photos/richardvignola/4566774290/

こういう意見が多数

”仕様がないと作れないから早く決めてほしい”

一方で

”仕様どおりつくるだけだとつまらない”

もーわがままなんだからぁ

”ソフトウェア開発とは、ユーザーのニーズやマーケティング上の目標をソフトウェア製品に変換する作業である。”

ソフトウェア開発 - Wikipedia http://bit.ly/A63xPS

違った使い方されたPublicにメッセージが飛び合う事を想定していたのに、Closedなメッセージ交換に使われていた

仕様がゴールか？

サービス開発だとこの考え方はリスクがあります。サービス開発だけなんですかね？ソフトウェア開発全般に当てはめてもいい気がします。

photo - http://www.flickr.com/photos/druclimb/480108350/

今の答え

仕様は仮説でしかない

詳細を決めすぎない•小さなプロトタイプを作る•どこまでも考え過ぎない•大事なら時間をかける

25僕も実際に開発をやっていて違いを感じたのですが、こういうビルを建てるような開発じゃない雰囲気です。

photo - http://www.flickr.com/photos/nknh/2447013697/

26ちょっとずつリリースを繰り替えいしているとこういう街のようなシステムを作っている気分になってきます。この中に赤いビルを建てようとは思わないですよね。そういう統一性は設計時に考えます。

photo - http://www.flickr.com/photos/brucehh/7627194894/

メアリーさん ”なぜ全部計測しないの？”

社内トレーニングでお招きしたときの話。言われて悔しい思いをしました。

効果測定の強化•リリース後に勝負が始まる•効果測定で見える化•使われているか？•想定した使われ方か？

デモ、見える化•デモは途中で止めた•そのかわりにできたら集合•レビューとしてリリース後のKPIを共有

photo - http://www.flickr.com/photos/maurymccown/1614878016/

再度、今の答え

リリースは出口じゃなく入り口だろう？

参考：AKB48 “GIVE ME FIVE!” http://bit.ly/TEH2sh

問い計画は

守らなければならないのか？

photo - http://www.flickr.com/photos/richardvignola/4566774290/

こういう意見が多数

“間に合うようにがんばってて欲しい”

一方で

•丸投げはがんばれない•開発だけでがんばれない•いつまでもがんばれないただ、年に2～3回がんばらざるをえない時期はありますよね。

不可能な計画を可能にするのがエンジニアの仕事ではない！

プロゴルファー猿Complete BOX-Vol.1 [DVD]: 頓宮恭子, 高木早苗, 峰あつ子: DVDhttp://amzn.to/R0jxNj

がんばりを続けるとつかれるリスクがあるってことです。参考：「不可能を可能にする男」Wikipedia http://goo.gl/Riu6V

こういう意見も

“今の見積りは余裕やゆとりがあるように見える”

見積もりで会話

見積りは正確に測定しないで、「間違ってたら気がついた時にフィードバックする」意識を持ってもらっています。正解か不正解は重要ではなく、はやく気がつくことを重要視しているからです。

楽天ブックス: アジャイルな見積りと計画づくり - マイク・コーン http://bit.ly/RhGkCO

“見積りは確率だが、コミットメントは確率で

はない”

今の答え

ちゃんと計画する計画は変更する

計画l 1～2週間のタイムボックスl 比較的柔軟なリリース日l フェーズをやめる

photo - http://www.flickr.com/photos/eesti/276022325/

ビジョン、マイルストーンは作る

大体の方向性とそこまでの距離は知っておきたいですよね。そのためのマイルストーンです。

41

マイルストーン的なカード

こういう意見も

“今回はサービスの手触りまで考える余裕がなかった”

DONEの定義は？l 作った、動いたl レビュー終わった、UT終わったl システムテスト終わったl 手触りの良いサービスにしあげた

http://corp.rakuten.co.jp/company/message.html

今日のおはなしl 開発のチェンジl マインドセットのチェンジl 変化から習慣へ

考えなおしたこと

成功と品質

問い

成功とはなんだ？

photo - http://www.flickr.com/photos/richardvignola/4566774290/

成功とは？•リリースが成功する•バグがない•トラブルがない

今の成功とは•仕様どおり•ビジネス価値が正しかった•これを”安定”して”継続的に”繰り返すこと

変更のコスト

時間

デリバリスピード

ユーザの信頼

技術的負債によるコスト肥大

理想のコスト

最悪の選択・なにもしない・リプレイス・お金をかけ続ける

ギャップ

作らないへ

•大抵作ることができる•いかに必要な物だけ作るか？

問い

品質とはなんだ？

photo - http://www.flickr.com/photos/richardvignola/4566774290/

品質とは？•仕様書通り•バグがないこと

例えば•レガシーシステム

•単体テストなんてない状態

•どう改善するか？

55

テスト計画書

アジャイルテストの4象限

単体テストコンポーネントテスト

機能テスト 例として ストーリーテスト プロトタイプ シミュレーション

探索的テストシナリオユーザビリティテストユーザ受け入れテストアルファ / ベータ

パフォーマンス / 負荷テストセキュリティテスト「～性」テスト

自動と手動

自動 ツール

手動

”我々のやり方には合わない”

自分たち用に整理

単体テスト（UT）

ユーザ受け入れテスト（UAT）

探索的テストユーザビリティテスト

パフォーマンスツールセキュリティツール

自動

自動 ツール

手動

58

テストのトレードオフシンプルな機能

複雑な機能

メジャーな機能マイナーな機能

超重要

重要

このへんは日々の画面チェックでカバーされてた

このへんは日々の画面チェックでカバーされてた

あきらめ対象

選択と集中

単体テスト（UT）

ユーザ受け入れテスト（UAT）

探索的テストユーザビリティテスト

パフォーマンスツールセキュリティツール

自動

自動 ツール

手動

注力

時間削減 時間削減

時間削減

価値のある手作業へ•画面デザインは人の目を使う

•手動で操作して触り心地を確かめる

•「気づき」をFBにつなげる

「こうなっていたらいいのに」もここで洗い出し、受け入れ担当者に仕様変更か無視かの判断をしてもらう。開発者全員で時間をあわせ、せーのでテストしていくと盛り上がる

ユーザ受け入れテスト(UAT)

•117 ケース•356 クリック•347 チェック

•30min 環境作成•30min ペアプロレクチャー•2days + リファクタリング

コスト

生まれた価値•QA前に125バグ•デグレード阻止多数•QAでのバグ率0.2%

品質とは誰かにとっての価値である

“Quality is value to some person”

スーパーエンジニアへの道 - 技術リ-ダ-シップの人間学ジェラルド・Ｍ．ワインバ-グ http://bit.ly/Qf2SUk

by Gerald Weinberg

今の品質ユーザの価値ビジネスの価値個人の価値

どれが一つだけだと食べていけなくなっちゃう

今日のおはなしl 開発のチェンジl マインドセットのチェンジl 変化から習慣へ

価値

原則

プラクティス

クラフトマンシップ？

サービス開発を

アジャイルに

ゴール

マインド

技術力

1

地図を捨ててコンパスを頼りに進め

photo- http://www.flickr.com/photos/pedrobelleza/6255124245/

リーンスタートアップ 解説より

地図を捨てる•地図は作るし時間もかける•地図は変更する•正しいを疑う

コンパスを頼りに•ユーザのフィードバック•問題に俊敏に気がづく•少しだけ、少しづつ

71

大体、まっすぐ進む

ちょっとぐらいのずれは気にしないで、大体まっすぐに進んでいること。半歩でも前に進んでいることを重視しています。

ふりかえりを活用•週1回1時間•課題を掘り下げる•リリースの効果も確認

Velocity

タスクの統計

スピードの安定

初めてアジャイル開発に取り組んだチームが、数カ月間でユーザーストーリーをDoneできた割合

DONE率 .410

半分もDoneできないという気づきを得た。ただ、イチローより高い打率。

効果はモチベーションに繋がり、次のアクションが明確になる。

20％のKPI向上

1

Typhoon #14 "Nabi" | Flickr - Photo Sharing! http://bit.ly/x60eXR

地図を捨ててコンパスを頼りに進め

理想の開発をしよう

photo - http://www.flickr.com/photos/usfwssoutheast/7644512048/

地図を捨ててコンパスを頼りに進め

誰かがやってくれると思うな

photo - http://www.flickr.com/photos/jannem/2079422115/

地図を捨ててコンパスを頼りに進め

これまでの当たり前を変化させよう

習慣よ変われ