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

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/

5. None

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