Save 37% off PRO during our Black Friday Sale! »

Qiita:Teamの開発を通して見つけてきた、Incrementsの文化を作る方法

 Qiita:Teamの開発を通して見つけてきた、Incrementsの文化を作る方法

dotsカンファレンス2016で発表した資料です。

0e8fbeb3dc2da3e502483edea80be7d6?s=128

Hiroyuki Tomine

March 31, 2016
Tweet

Transcript

  1. Qiita/Qiita:Teamの開発を通して見つけてきた、 Incrementsの文化を作る方法 Increments株式会社 東峰 裕之 @htomine

  2. @htomine とみね - Increments株式会社 - デザイナ、ユーザーコミュニケーショ ン、アシスタントPOっぽいことなど - その他の属性 -

    ex サイボウズ社 - ex はてなインターン - コミケット準備会 自己紹介
  3. 目次 1. ++ってどんなチーム? 2. 何を大事にしているか a. Back to 2014 i.

    何を大事にしていたか b. そして現在 i. 何を大事にしているか 3. Qiita:Team開発から得た ヒント
  4. 1. ++ ってどんなチーム?

  5. 設立:2012-02-29 ㊗ 4年目! サービス:     Mac / Win 人数:14名 ソフトウェア開発を良くすることで、

    世界の進化を加速させる
  6. 14名の内訳

  7. 14名の内訳 = PM/PO

  8. ファウンダー3人の共同創業 エンジニア・ビジネス・デザイナとバランスがよい。 この3人が合議して進めていくスタイル。

  9. エンジニア vs デザイナ エンジニア:6名 Qiita 2名、Team 2名、Kobito 1名、インフラ 1名 デザイナ:

    3名(マネジメント+2名) 人数の割にはプロダクトが多い。 デザイナはプロダクト横断で 随時プロジェクトに参加。 仮説検証〜設計〜実装まで 全員が参加する。
  10. 2. 何を大事にしていたか

  11. Back to 2014

  12. 当時のメンバー:6名

  13. 実質開発チーム:3名+1名… この状況で大切にしていたこと

  14. この状況で大切にしていたこと 1. 何を作るかより、何を作らないか 2. ユーザーヒアリングをしまくる 3. 属人性の排除・自動化

  15. 1. 何をつくるかより、何をつくらないか - 考えざるをえない… 重要な価値に集中する - Running Leanを実践実践実践 - 「価値仮説」ベースのコミュニケーション

    - MVPで検証し、すぐ捨てる - ムダな作り込みは悪! - デザイナって仮説検証する人でしょ?
  16. 1. 何をつくるかより、何をつくらないか 価値仮説テンプレート - 価値仮説でコミュニケーショ ンすることで、素早くブレなく 共有できる。 - 効率的にアナも見つけられ る。

    - 「この欲求本当にブレ ない?」など議論が明 確になりやすい。 https://speakerdeck.com/katsuma/service-development-for-users?slide=36
  17. 2. ユーザーヒアリングしまくる - 内部に声はないと思え - 他企業経験者も少ない、社会人経験も浅い - どんどん外に聞くしかない - エンジニアもデザイナもヒアリングする

    - CTOがひとりで10件20件ヒアリングしてたことも
  18. 2. ユーザーヒアリングしまくる ヒアリング 266件 300人以上に会ってる 1アクションで5件〜10件ぐらい。 ただし、言っていることを文字通り解釈するのではなく、何を意図しているか理解する

  19. 3. 属人性の排除・自動化 - 手でやってたらまわらない! - 適切な粒度・量・相手を判断して、自ら情報を共有する - 自動化(面倒なルーチンワークを疑う)

  20. 3. 属人性の排除・自動化 - ちゃんとシェアしよう、という動き - 「それTeamに書いとこうよ」「それまとまってないのはよくな いね」→ドキュメント化 - 日報の所感を活用 -

    他で拾いづらい情報を非同期で得られる - Qiita:Teamに書いてあれば、誰でも再現・再利用 可能
  21. 3. 属人性の排除・自動化 面倒なルーチンワークは常に疑う 例)某勤怠管理サービスを導入 → 勤怠(出社および退勤)を入力す るWebシステムがイケてない(良く ある)→ ブラウザとWeb間の通信 を解析

    → Qiitanで入力可能に
  22. 自動化の例:ChatOps チャットサービス上で • 開発チームの情報を集約 • 高機能Botにより各種自動 化ツールを操作

  23. Qiitan c.f ) Ruby製HubotクローンのRubotyをSlackで動かす - Qiita

  24. Qiitan 画像検索

  25. Qiitan 天気予報 渋谷ランチ情報 rubyコード実行

  26. Qiitan 掃除時間と当番の割り当ての通知

  27. Qiitan GitHubへのIssue登録 Deploy & Mergeリクエスト

  28. Qiitan #from_twitterでQiitaについてのツイートを収集

  29. まとめ:何を大事にしてきたか - Lean Startupの徹底的な実践 - 素早い意思決定で少ないリソースを補う - 価値仮説テンプレート - 足で稼ぐヒアリング力

    - 属人性の排除・自動化 - どんどん自動化する - これを強くモチベートするハッカー文化 - それが期待できる人材の採用
  30. そして現在

  31. 14名に増えた(だいたい倍)

  32. 新しい状況、新しい課題 1. 多様化への対応 2. プロダクト体制の強化

  33. 1. 多様化への対応

  34. 1. 多様化への対応 - 多様化してきた、しかも尖った人ばっかりだ! - 文化は合ってる。ただし趣向は違う。 - 多様であり、かつ同じ文化に共鳴する集団であることは、今の 強みでもある。 -

    暗黙の認知を元にした気持ちの良いコミュニケーション。 ハッカー文化への信頼・信望が支えている。 - チームとしては、この状況を支えたい
  35. 1. 多様化への対応 個々の働きやすさの担保 - 我々の信望する文化というのは、そんなこ とぐらい許容できるはずだ! - →フレックス&リモートワークの導入 他人に強要しない文化 -

    飲み会、遊び - やきそばを焼く - やりたい人がやる、やりたくない人はやらな い
  36. 1. 多様化への対応 社長⇔各社員での月イチ1on1 - 業務の面だけでなく、「会社について期待すること、不満に思う こと、社内で気になっている噂などはないか」という話題 - 会社:社員を知ることを諦めない - メンバー:会社が「よくしてくれるはず」という期待を捨てない

  37. 2. プロダクト体制の強化

  38. 2.プロダクト体制の強化 - 以前は共有されていたプロダクトのビジョンが本当に伝わって いるか - いや、ドキュメント化はされているのだけど、浸透はしてい ないんではないか…とかの不安 - 各自がオーナーシップを取れる状態なのか -

    →プロダクトの体制も、もう一段階進化が必要
  39. 2. プロダクト体制の進化 - POを置き直す - 売上や会社の体制まで含めて意思決定できるよう、社長 に一旦POを戻す(Qiita:Team) - 開発メンバーとの対話もよりしやすくなった -

    PO経験者を採用する - 未経験のなか模索してきたのがこれまで。 - よりレベルをあげるために、経験値の高いメンバーにJoin してもらう - ていうかプロダクトの数と PMの人数合ってないし!
  40. 2. プロダクト体制の進化 - 『及川ショック』?! - 長年のPM経験のある及川さんを採用

  41. 2. プロダクト体制の進化 - OKR の導入 - Objectives and Key Results

    - 目標とその結果の定義と達成のためのメソッド 詳細はこの辺へ: http://hiromaeda.com/2015/01/19/okr/ http://yaotti.hatenablog.com/entry/2015/02/15/001352
  42. http://www.slideshare.net/jaymeh13/object-

  43. None
  44. 2. プロダクト体制の進化 - 上から下まで一貫した目標設定ができたことで、課題ドリブン の価値仮説だけでなく、プロダクトのゴールに向けたアクション として見通しが良くなった - OKRにひも付けてアクションプランを管理でき、メンバーも常 に意識する(ようにしていく) -

    Midpoint Checkを実施して細かく修正 - 何事も細かく考え過ぎないように!
  45. 2. プロダクト体制の進化 ドキュメントの整備 - PRD (Product Requirements Document) の項目を統一 -

    Github Issuesにテンプレートを用意(Feature Request/Bug Report) プロダクトキックオフの手順書 - 価値仮説・LeanCanvasとの接続 - 価値仮説は要件定義の最小セット - ここはまだちょっと小慣れていない
  46. まとめ:何を大事にしているか - メンバー・会社両方から、多様性を許容する努力をし続けるこ と - それを良しとする文化を自分たちは大事にしていると胸を 張って言えるようにする - 時には経験者にインストールしてもらうことも有効w -

    自分たちで咀嚼し、身につけていくフローは必須 - チームで考える体制を如何に作っていくか
  47. 3. Qiita:Teamから学んだこと

  48. Qiita:Teamから学んだこと - 2014年〜2015年まではTeamに注力した年でもあった。 - 自チームのあれこれを試行錯誤する時、常にQiita:Teamの ユーザーとしてのチームの姿を考えてきた。

  49. Qiita:Teamでよくある課題 - 「導入したのにメンバーが使ってくれない!」 - 「なんでこのツールが必要か上司が分かってくれない!自分 でもうまく言語化できない…」 →チームを変えるアクションは、常に人と人との関わりの中 で生 まれる。そのため常に複雑で、常に難しい。あまつさ え、答えも ない。

  50. 良いチームを考えていかねばならない どうすれば良いチームになれるか。 良いチームとはなんだろうか? Objective: ++を最高のチームにする KeyResults: 最高のチームの条件を考える このKRへのアクションとして行っているのが、 ある本の輪読会。

  51. TEAMING 輪読会 - 複雑化する現代のチームで、成果を出すにはど ういうアプローチが必要か書かれている - 「学習する組織」づくり - それにはコミュニケーションと協調がいる -

    意見の相違の乗り越え - 解決策が生まれるまで 議論できる関係性 - 安心して率直に述べられる環境 - 質問したり、共有することを後押しするリーダー
  52. 最高のチーム? - 意見の相違が乗り越えられ - 解決策が生まれるまで議論できる関係性があり - 安心して率直に意見を述べられる環境である これが出来る組織でなら、困難を乗り越えていけそうに感じられる。 しかし実現するのはすごく難しそう …。

    と、いう事が書いてある本をみんなで読んでいる。 チーム全員で考えることにつながっていると思う。
  53. まとめ:Qiita:Teamから学んだこと - 感情的な部分を乗り越えてチームを変えていくことはとても困 難 - ただ、その努力は放棄してはいけない - 超えるために必要なことは何か、リーダー・メンバーともに出来 ることがある -

    チームで考えていくことが必要。輪読して意見を交わすこと はその貴重な機会になっている。
  54. まとめ

  55. Incrementsの開発チーム - 少人数から徐々に大きくなり、新たな課題も出ているが進む方 向性は見えてきた。 - チームを作る難しさ、文化を作る難しさはQiita:Teamサービス からも感じているが、それを乗り越える方法は存在しそう。 - 試行錯誤しながら進んできたことが、「不可能に見えることに チャレンジし続ける」文化を醸成している。

  56. かんたん・気軽に書ける、 チームを強くする為の社内向け情報共有サービス 導入企業一覧

  57. 知見を共有しスキルを高めることができる プログラミングに特化したオープンな情報共有コミュニティ かんたんにわかりやすく 書ける タグやストックで 見たい記事がみつかる 編集リクエストで 知恵を分けあえる シンプルで使いやすい 専用エディタ