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

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

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. ２．プロダクト体制の強化 - 以前は共有されていたプロダクトのビジョンが本当に伝わって いるか - いや、ドキュメント化はされているのだけど、浸透はしてい ないんではないか…とかの不安 - 各自がオーナーシップを取れる状態なのか - →プロダクトの体制も、もう一段階進化が必要
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-
44. 2. プロダクト体制の進化 - 上から下まで一貫した目標設定ができたことで、課題ドリブン の価値仮説だけでなく、プロダクトのゴールに向けたアクション として見通しが良くなった - OKRにひも付けてアクションプランを管理でき、メンバーも常 に意識する（ようにしていく） - Midpoint Checkを実施して細かく修正 - 何事も細かく考え過ぎないように！
45. 2. プロダクト体制の進化 ドキュメントの整備 - PRD (Product Requirements Document) の項目を統一 - Github Issuesにテンプレートを用意（Feature Request／Bug Report) プロダクトキックオフの手順書 - 価値仮説・LeanCanvasとの接続 - 価値仮説は要件定義の最小セット - ここはまだちょっと小慣れていない
46. まとめ：何を大事にしているか - メンバー・会社両方から、多様性を許容する努力をし続けるこ と - それを良しとする文化を自分たちは大事にしていると胸を 張って言えるようにする - 時には経験者にインストールしてもらうことも有効ｗ - 自分たちで咀嚼し、身につけていくフローは必須 - チームで考える体制を如何に作っていくか
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. かんたん・気軽に書ける、 チームを強くする為の社内向け情報共有サービス 導入企業一覧
58. 知見を共有しスキルを高めることができる プログラミングに特化したオープンな情報共有コミュニティ かんたんにわかりやすく 書ける タグやストックで 見たい記事がみつかる 編集リクエストで 知恵を分けあえる シンプルで使いやすい 専用エディタ