Your SlideShare is downloading. ×
地図を捨ててコンパスを頼りに進め
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×

Introducing the official SlideShare app

Stunning, full-screen experience for iPhone and Android

Text the download link to your phone

Standard text messaging rates apply

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

7,231
views

Published on

Throw away the map and let's go with the help of your compass. …

Throw away the map and let's go with the help of your compass.
Agile Tour Osaka 2012 ( http://bit.ly/Tm3MNc )発表資料です。若手エンジニアとサービス開発を通して考えてきた「なぜ?」。その探求の旅の紹介です。

Published in: Technology

0 Comments
16 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total Views
7,231
On Slideshare
0
From Embeds
0
Number of Embeds
7
Actions
Shares
0
Downloads
31
Comments
0
Likes
16
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

Transcript

  • 1. 地図を捨ててコンパスを頼りに進め 楽天株式会社 藤原大
  • 2. 藤原 大@daipresents• 楽天株式会社 開発ユニット アジャイルグループ マネージャ• プロジェクトファシリテー ター、トレーナー• 趣味は沖縄離島巡り• 実家は箕面市牧落http://daipresents.com/
  • 3. Agile ConferenceAgile Conferenceには2010年から参加しています。記事を書いたりFacebookページを作ったりして、ちょっとでも自分が好きになった雰囲気が届けばなぁと。今年書いた記事はこちら => ManasLink - EM ONLINE http://bit.ly/QlZy9N
  • 4. 集え、日本の活動家たちよ。http://ultimateagilist.doorkeeper.jp/events/1823 Ultimate Agilist Tokyo 11/17 開催!
  • 5. 集え、日本の活動家たちよ。 宝探しAgileゲーム - 安井 力 氏 アジャイルプログラマの定義は俺たちが決める。そして、最速でそう なってみる - 牛尾 剛 氏 アジャイル テスト開発を考える - 細谷 泰夫 氏 TDDと組織文化 - 天野 勝 氏 家電商品を開発してみると目からウロコなAgileの本質 - 前川 直也 氏 Ruby on Railsによるアジャイル開発事例と注意点 - 川端 光義 氏 The Art Of Agile ProjectManager - 市谷 聡啓 氏http://ultimateagilist.doorkeeper.jp/events/1823 Can you keep doing that? - 原田 騎郎 氏 アジャイル開発における、システムテストの自動化 - 小井土 亨 氏 リアルウェア - 濱 勝巳 氏 アジャイルに対する見方の変化 - 太田 健一郎 氏 これまでの開発から、これからの開発へのチェンジ - 倉貫 義人 氏 Ultimate Agilist Tokyo テストを支える。テストを育てる。 - 井芹 洋輝 氏 11/17 開催! 「ふりかえり」をふりかえってみよう。 - 串田幸江 女史
  • 6. SIerでした •Javaエンジニア •業務向けWebアプリ •二次受け •一人でドナドナ •ほとんど滝http://www.flickr.com/photos/lombre/3052877393/
  • 7. 上記以外にもサービスはあります。これだけいろいろなサービスがあると開発方法も様々です。
  • 8. アジャイル支援歴•リプレイス6ヶ月•リプレイス3ヶ月•若いサービス10ヶ月 私のチームごとサービスを担当するチームに合流し、席を並べて働きます。 週1回とかじゃなくて、毎日一緒です。
  • 9. プロデューサー 登場人物エンジニア 私
  • 10. 開発の流れ•PROがアイデアを練って•ENGが実現する•この回転を支援
  • 11. 朝礼の 風景はじめは私がファシリテーターとして運営し、徐々に周りに移譲していく形が多いです。
  • 12. 12
  • 13. 今日のおはなしl 開発のチェンジl マインドセットのチェンジl 変化から習慣へ
  • 14. 今日のおはなしl 開発のチェンジl マインドセットのチェンジl 変化から習慣へ
  • 15. すぐ見えた壁•なぜかWF•開発スキル低(若者多)•一体感の無さ
  • 16. 考えなおしたこと計画と仕様
  • 17. 問い 仕様書は 正しいのか?photo - http://www.flickr.com/photos/richardvignola/4566774290/
  • 18. こういう意見が多数 仕様がないと作れないから早く決めてほしい
  • 19. 一方で 仕様どおりつくるだけだとつまらない もーわがままなんだからぁ
  • 20. ソフトウェア開発とは、ユーザーのニーズやマーケティング上の目標をソフトウェア製品に変換する作業である。 ソフトウェア開発 - Wikipedia http://bit.ly/A63xPS
  • 21. 違った使い方されたPublicにメッセージが飛び合う事を想定していたのに、Closedなメッセージ交換に使われていた
  • 22. 仕様がゴールか?サービス開発だとこの考え方はリスクがあります。サービス開発だけなんですかね? ソフトウェア開発全般に当てはめてもいい気がします。 photo - http://www.flickr.com/photos/druclimb/480108350/
  • 23. 今の答え仕様は仮説でしかない
  • 24. 詳細を決めすぎない• 小さなプロトタイプを作る• どこまでも考え過ぎない• 大事なら時間をかける
  • 25. 25僕も実際に開発をやっていて違いを感じたのですが、こういうビルを建てるような開発じゃない雰囲気です。 photo - http://www.flickr.com/photos/nknh/2447013697/
  • 26. ちょっとずつリリースを繰り替えいしているとこういう街のようなシステムを作っている気分になってきます。 26この中に赤いビルを建てようとは思わないですよね。そういう統一性は設計時に考えます。 photo - http://www.flickr.com/photos/brucehh/7627194894/
  • 27. メアリーさん なぜ全部計測しないの? 社内トレーニングでお招きしたときの話。言われて悔しい思いをしました。
  • 28. 効果測定の強化•リリース後に勝負が始まる•効果測定で見える化•使われているか?•想定した使われ方か?
  • 29. デモ、見える化•デモは途中で止めた•そのかわりにできたら集合•レビューとしてリリース後のKPIを共有
  • 30. 再度、今の答えリリースは出口じゃなく 入り口だろう? 参考:AKB48 “GIVE ME FIVE!” http://bit.ly/TEH2sh photo - http://www.flickr.com/photos/maurymccown/1614878016/
  • 31. 問い 計画は 守らなければ ならないのか?photo - http://www.flickr.com/photos/richardvignola/4566774290/
  • 32. こういう意見が多数 間に合うようにがんばってて欲しい
  • 33. 一方で•丸投げはがんばれない•開発だけでがんばれない•いつまでもがんばれない ただ、年に2∼3回がんばらざるをえない時期はありますよね。
  • 34. 不可能な計画を可能にするのがエンジニアの仕事ではない! がんばりを続けるとつかれるリスクがあるってことです。 参考:「不可能を可能にする男」Wikipedia http://goo.gl/Riu6Vプロゴルファー猿Complete BOX-Vol.1 [DVD]: 頓宮恭子, 高木早苗, 峰あつ子: DVDhttp://amzn.to/R0jxNj
  • 35. こういう意見も 今の見積りは余裕やゆとりがあるように見える
  • 36. 見積もりで会話見積りは正確に測定しないで、「間違ってたら気がついた時にフィードバックする」意識を持ってもらっています。正解か不正解は重要ではなく、はやく気がつくことを重要視しているからです。
  • 37. 見積りは確率 だが、コミット メントは確率で はない楽天ブックス: アジャイルな見積りと計画づくり - マイク・コーン http://bit.ly/RhGkCO
  • 38. 今の答えちゃんと計画する計画は変更する
  • 39. 計画l 1∼2週間のタイムボックスl 比較的柔軟なリリース日l フェーズをやめる
  • 40. ビジョン、マイルストーンは作る大体の方向性とそこまでの距離は知っておきたいですよね。そのためのマイルストーンです。 photo - http://www.flickr.com/photos/eesti/276022325/
  • 41. マイルストーン的なカード 41
  • 42. こういう意見も 今回はサービスの手触りまで考える余裕がなかった
  • 43. DONEの定義は?l 作った、動いたl レビュー終わった、UT終わったl システムテスト終わったl 手触りの良いサービスにしあげた
  • 44. http://corp.rakuten.co.jp/company/message.html
  • 45. 今日のおはなしl 開発のチェンジl マインドセットのチェンジl 変化から習慣へ
  • 46. 考えなおしたこと成功と品質
  • 47. 問い 成功とは なんだ?photo - http://www.flickr.com/photos/richardvignola/4566774290/
  • 48. 成功とは?•リリースが成功する•バグがない•トラブルがない
  • 49. 今の成功とは•仕様どおり•ビジネス価値が正しかった•これを 安定 して 継続的に 繰り返すこと
  • 50. ユーザの信頼 最悪の選択変 ・なにもしない デリバリスピード ・リプレイス更 ・お金をかけ続けるの 技術的負債によるコ コスト肥大ス ギャップト 理想のコスト 時間
  • 51. 作らないへ•大抵作ることができる•いかに必要な物だけ作るか?
  • 52. 問い 品質とは なんだ?photo - http://www.flickr.com/photos/richardvignola/4566774290/
  • 53. 品質とは?•仕様書通り•バグがないこと
  • 54. 例えば•レガシーシステム•単体テストなんてない状態•どう改善するか?
  • 55. テスト計画書 55
  • 56. アジャイルテストの4象限自動と手動 手動 探索的テスト 機能テスト 例として シナリオ ストーリーテスト ユーザビリティテスト ユーザ受け入れテスト 我々のやり方には合わない プロトタイプ シミュレーション アルファ / ベータ 単体テスト パフォーマンス / 負荷テスト コンポーネントテスト セキュリティテスト 「∼性」テスト 自動 ツール
  • 57. 自分たち用に整理自動 手動ユーザ受け入れテスト 探索的テスト(UAT) ユーザビリティテスト単体テスト(UT) パフォーマンスツール セキュリティツール自動 ツール
  • 58. テストのトレードオフ シンプルな機能 このへんは日々の画面チェック でカバーされてた 超重要 マイナーな機能 メジャーな機能 このへんは日々の画面チェック でカバーされてた 重要58あきらめ対象 複雑な機能
  • 59. 選択と集中自動 手動時間削減ユーザ受け入れテスト(UAT) 注力 探索的テスト ユーザビリティテスト単体テスト(UT) パフォーマンスツール時間削減 時間削減自動 セキュリティツール ツール
  • 60. 価値のある手作業へ• 画面デザインは人の目を使う• 手動で操作して触り心地を確かめる• 「気づき」をFBにつなげる 「こうなっていたらいいのに」もここで洗い出し、受け入れ担当者に仕様変更か無視かの判断をしてもらう。 開発者全員で時間をあわせ、せーのでテストしていくと盛り上がる
  • 61. ユーザ受け入れテスト (UAT)•117 ケース•356 クリック•347 チェック
  • 62. コスト•30min 環境作成•30min ペアプロレクチャー•2days + リファクタリング
  • 63. 生まれた価値•QA前に125バグ•デグレード阻止多数•QAでのバグ率0.2%
  • 64. “Quality is value to some person” 品質とは誰かにとっての価値である by Gerald Weinbergスーパーエンジニアへの道 - 技術リ-ダ-シップの人間学 ジェラルド・M.ワインバ-グ http://bit.ly/Qf2SUk
  • 65. 今の品質ユーザの価値ビジネスの価値 個人の価値 どれが一つだけだと食べていけなくなっちゃう
  • 66. 今日のおはなしl 開発のチェンジl マインドセットのチェンジl 変化から習慣へ
  • 67. サービス開発をプラクティス ゴール 原則 マインド 価値 技術力アジャイルに クラフトマンシップ?
  • 68. 地図を捨てて コンパスを 頼りに進め リーンスタートアップ 解説より 1 photo- http://www.flickr.com/photos/pedrobelleza/6255124245/
  • 69. 地図を捨てる•地図は作るし時間もかける•地図は変更する•正しいを疑う
  • 70. コンパスを頼りに•ユーザのフィードバック•問題に俊敏に気がづく•少しだけ、少しづつ
  • 71. 大体、まっすぐ進む 71ちょっとぐらいのずれは気にしないで、大体まっすぐに進んでいること。半歩でも前に進んでいることを重視しています。
  • 72. ふりかえりを活用•週1回1時間•課題を掘り下げる•リリースの効果も確認
  • 73. Velocity
  • 74. タスクの統計
  • 75. スピードの安定
  • 76. DONE率 .410初めてアジャイル開発に取り組んだチームが、数カ月間でユーザーストーリーをDoneできた割合 半分もDoneできないという気づきを得た。ただ、イチローより高い打率。
  • 77. 20%のKPI向上効果はモチベーションに繋がり、次のアクションが明確になる。
  • 78. 地図を捨てて コンパスを 頼りに進め 1Typhoon #14 "Nabi" ¦ Flickr - Photo Sharing! http://bit.ly/x60eXR
  • 79. 理想の開発を しよう
  • 80. 地図を捨てて コンパスを 頼りに進めphoto - http://www.flickr.com/photos/usfwssoutheast/7644512048/
  • 81. 誰かがやってくれ ると思うな
  • 82. 地図を捨てて コンパスを 頼りに進めphoto - http://www.flickr.com/photos/jannem/2079422115/
  • 83. これまでの当たり前 を変化させよう
  • 84. 習慣よ変われ