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

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

At Agile Japan 2014

3e77f9dbec6a87756d1dbdddab283aee?s=128

Nulab Inc.

June 27, 2014
Tweet

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