効果的に試行錯誤を行うための仕組みづくり〜失敗はおはやめに、プロダクトの成長は着実に〜

At Agile Japan 2014

Transcript

1. 効果的に試⾏行行錯誤を⾏行行うための仕組みづくり 〜～失敗はおはやめに、プロダクトの成⻑⾧長は着実に〜～ Agile  Japan  2014 2014/06/27(⾦金金)
2. 染⽥田  貴志 SOMEDA  Takashi @tksmd 株式会社ヌーラボ テックエバンジェリスト
3. http://tatsu-‐‑‒zine.com/books/genba10things
4. http://santo2014.jaws-‐‑‒ug.jp/
6. JAWS  Days  2013 国内を中⼼心に  約2500クライアント  が利利⽤用するプロジェクト管理理ツール タスク管理理機能に加え、 •  WebDAVによるファイル共有 •  GitやSubversionのリポジトリホスティング などを提供。 http://www.backlog.jp
7. 全世界  約120万ユーザ  が利利⽤用するオンラインのドローツール 基本的なドローツールの機能に加え •  複数のユーザで同時に編集出来るリアルタイムコラボレーション •  Google+  Hangouts  と連携して、ビデオチャットとあわせて利利⽤用可能 といった、コラボレーション機能が充実。 http://cacoo.com/
8. 今年年正式版をリリースしたばかりの新しいチャットサービス •  ヌーラボの各サービスとの連携 •  豊富で使いやすい  API  の提供 http://typetalk.in/
9. Backlog  成⻑⾧長の軌跡 0 50000 100000 150000 200000 250000 300000 350000 2011 2012 2013 2014 ユーザ数 スペース数
10. Backlog  成⻑⾧長の軌跡 0 50000 100000 150000 200000 250000 300000 350000 2011 2012 2013 2014 ユーザ数 スペース数 ビッグリリース に失敗
11. Backlog  成⻑⾧長の軌跡 0 50000 100000 150000 200000 250000 300000 350000 2011 2012 2013 2014 ユーザ数 スペース数 プロセス カイゼンの 取り組み
12. Backlog  成⻑⾧長の軌跡 0 50000 100000 150000 200000 250000 300000 350000 2011 2012 2013 2014 ユーザ数 スペース数 確信をもって リリース
13. 普段、 どんなお仕事を されていますか？
14. お⼿手元のポストイット •  印象に残ったこと •  ⾃自分たちが抱えている問題 •  ⾃自分たちで取り組んだこと
15. 本⽇日のお話 1.  ソフトウェア開発の「イマ」 2.  UI  設計にコストをかける 3.  失敗できる環境づくり 4.  すばやく届けるプロセス 5.  コミュニケーション
16. 1.ソフトウェア開発の「イマ」 http://www.flickr.com/photos/ancientsword/2856148716/
17. リーンスタートアップ
18. アジャイル(スクラム)
19. アジャイル(スクラム)
20. アジャイル  x  リーン
21. ⼿手早く作り、素早く届ける
22. http://www.flickr.com/photos/nicmcphee/2558167768/ 2.UI設計にコストをかける
23. 「誰のためのデザイン？」 毎⽇日使っている道具を使おうと思って、 うまく使えなかったとしよう。 何が悪いのだろう？ 私の使い⽅方だろうか。 それともその道具が悪いのだろうか？ 私たちは⾃自分⾃自⾝身を責めがちである。 「誰のためのデザイン？」 　 D・A・ノーマン
24. UIドリブンな開発
25. 図でパターンを考える
26. モックで動作確認
27.  Chrome  Extension Chrome  Extension  で実験
28. ディレクタ 開発者 デザイナ オーナー UI チーム全員で  UI  を考える
29. http://www.flickr.com/photos/alexmartin81/5883645329/ 3.  失敗できる環境づくり
30. 三つの運⽤用環境
31. 本気でつかう
32. 1.バーチャルホスト
33. 2.クッキーディスパッチ
34. 3.リソーススイッチ
35. 4.アプリケーションフラグ
36. パターン毎のまとめ アプリ インフラ 特徴 バーチャルホスト 対応不不要 専⽤用の環境が必要 ホスト名に従って振り分 けサーバを変更更 認証不不要 ベータ環境の追加に柔軟 に対応可能 適⽤用できるアプリに制限 あり クッキーディスパッチ ユーザの属性に従って クッキーを付与する 専⽤用の環境が必要 クッキーに従って振り分 けサーバを変更更 認証が必要 ⼤大抵のアプリで適⽤用可能 リソーススイッチ ユーザの属性に従って リソースを切切り替える 対応不不要 認証が必要 ⼤大抵のアプリで適⽤用可能 アプリケーションフラグ ユーザの属性に従って 機能を切切り替える 対応不不要 認証が必要 ⼤大抵のアプリで適⽤用可能
37. https://www.flickr.com/photos/kamshots/468265643/ 4.すばやく届けるプロセス
38. ベータ環境に求められること
39. 継続的デリバリ
40. Infrastructure  as  Code
41. ヌーラボでの例例
42. ベータデリバリのポイント
43. デモ
44. https://www.flickr.com/photos/twosevenoneonenineeightthreesevenatenzerosix/8187732414/ 5.コミュニケーション
45. フィードバック
46. 「ツッコミビリティの確保」 また、作るものが⼤大きくなってくるにつれ、⼀一⼈人の⼈人間が全 てを把握することは不不可能になっていきます。 これを認めた上でチームを作らないといけませんが、ここで カギになるのがチームとしてのみんなの⽬目の存在です。 みんなが⾒見見ていれば誰かが間違っていると気付くはずですが、 その気づきを顕在化できるかどうかは組織の問題です。   h"ps://aiming-­‐inc.com/ja/developer-­‐credo/problem-­‐vs-­‐us/
47. 情報の透明性
48. 課題 担当者 ツッコミの構造  -‐‑‒  なりがち
49. 課題 ツッコミの構造  –  あるべき姿
50. 課題 担当者 でもやっぱり感情的には
51. 気持ちよいツッコミ作法 •  するとき •  ポジティブフィードバックを⼼心がける •  指摘ではなく提案にする •  欲しいとき •  みて欲しいところを明確にする •  ⼿手軽なフィードバックの場を作る
52. http://www.flickr.com/photos/munaz/2498380666/ まとめ
53. 本⽇日のお話 1.  ソフトウェア開発の「イマ」 2.  UI設計にコストをかける 3.  失敗できる環境づくり 4.  すばやく届けるプロセス 5.  コミュニケーション
54. 定着するまでの期間 0 5 10 15 20 25 30 35 40 45 50 2012年年10⽉月 2012年年11⽉月 2012年年12⽉月 2013年年1⽉月 2013年年2⽉月 2013年年3⽉月 2013年年4⽉月 2013年年5⽉月 2013年年6⽉月 2013年年7⽉月 2013年年8⽉月 2013年年9⽉月 2013年年10⽉月 2013年年11⽉月 2013年年12⽉月 2014年年1⽉月 2014年年2⽉月 2014年年3⽉月 2014年年4⽉月 2014年年5⽉月 2014年年6⽉月
55. お⼿手元のポストイット •  印象に残ったこと •  ⾃自分たちが抱えている問題 •  ⾃自分たちで取り組んだこと
56. 最後にもう⼀一⾔言
57. ご清聴ありがとうございました @nulabjp