Qiita:Teamの開発を通して見つけてきた、Incrementsの文化を作る方法
•
1 like•1,383 views
Dots カンファレンス 2016 の資料です。
More Related Content
Viewers also liked
Similar to Qiita:Teamの開発を通して見つけてきた、Incrementsの文化を作る方法
Similar to Qiita:Teamの開発を通して見つけてきた、Incrementsの文化を作る方法 (20)
Recently uploaded
Recently uploaded (10)
Qiita:Teamの開発を通して見つけてきた、Incrementsの文化を作る方法
- 2. @htomine とみね - Increments株式会社 - デザイナ、ユーザーコミュニケーショ ン、アシスタントPOっぽいことなど - その他の属性 - ex サイボウズ社 - ex はてなインターン - コミケット準備会 自己紹介
- 3. 目次 1. ++ってどんなチーム？ 2. 何を大事にしているか a. Back to 2014 i. 何を大事にしていたか b. そして現在 i. 何を大事にしているか 3. Qiita:Team開発から得た ヒント
- 5. 設立：2012-02-29 ㊗ 4年目! サービス： Mac / Win 人数：14名 ソフトウェア開発を良くすることで、 世界の進化を加速させる
- 6. 14名の内訳
- 9. エンジニア vs デザイナ エンジニア：6名 Qiita 2名、Team 2名、Kobito 1名、インフラ 1名 デザイナ： 3名（マネジメント＋2名） 人数の割にはプロダクトが多い。 デザイナはプロダクト横断で 随時プロジェクトに参加。 仮説検証〜設計〜実装まで 全員が参加する。
- 10. 2. 何を大事にしていたか
- 11. Back to 2014
- 12. 当時のメンバー：6名
- 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で入力可能に
- 23. Qiitan c.f ) Ruby製HubotクローンのRubotyをSlackで動かす - Qiita
- 24. Qiitan 画像検索
- 29. まとめ：何を大事にしてきたか - Lean Startupの徹底的な実践 - 素早い意思決定で少ないリソースを補う - 価値仮説テンプレート - 足で稼ぐヒアリング力 - 属人性の排除・自動化 - どんどん自動化する - これを強くモチベートするハッカー文化 - それが期待できる人材の採用
- 30. そして現在
- 31. 14名に増えた（だいたい倍）
- 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
- 44. 2. プロダクト体制の進化 - 上から下まで一貫した目標設定ができたことで、課題ドリブン の価値仮説だけでなく、プロダクトのゴールに向けたアクション として見通しが良くなった - OKRにひも付けてアクションプランを管理でき、メンバーも常 に意識する（ようにしていく） - Midpoint Checkを実施して細かく修正 - 何事も細かく考え過ぎないように！
- 45. 2. プロダクト体制の進化 ドキュメントの整備 - PRD (Product Requirements Document) の項目を統一 - Github Issuesにテンプレートを用意（Feature Request／Bug Report) プロダクトキックオフの手順書 - 価値仮説・LeanCanvasとの接続 - 価値仮説は要件定義の最小セット - ここはまだちょっと小慣れていない
- 46. まとめ：何を大事にしているか - メンバー・会社両方から、多様性を許容する努力をし続けるこ と - それを良しとする文化を自分たちは大事にしていると胸を 張って言えるようにする - 時には経験者にインストールしてもらうことも有効ｗ - 自分たちで咀嚼し、身につけていくフローは必須 - チームで考える体制を如何に作っていくか
- 51. TEAMING 輪読会 - 複雑化する現代のチームで、成果を出すにはど ういうアプローチが必要か書かれている - 「学習する組織」づくり - それにはコミュニケーションと協調がいる - 意見の相違の乗り越え - 解決策が生まれるまで 議論できる関係性 - 安心して率直に述べられる環境 - 質問したり、共有することを後押しするリーダー
- 52. 最高のチーム？ - 意見の相違が乗り越えられ - 解決策が生まれるまで議論できる関係性があり - 安心して率直に意見を述べられる環境である これが出来る組織でなら、困難を乗り越えていけそうに感じられる。 しかし実現するのはすごく難しそう …。 と、いう事が書いてある本をみんなで読んでいる。 チーム全員で考えることにつながっていると思う。
- 53. まとめ：Qiita:Teamから学んだこと - 感情的な部分を乗り越えてチームを変えていくことはとても困 難 - ただ、その努力は放棄してはいけない - 超えるために必要なことは何か、リーダー・メンバーともに出来 ることがある - チームで考えていくことが必要。輪読して意見を交わすこと はその貴重な機会になっている。
- 54. まとめ
- 55. Incrementsの開発チーム - 少人数から徐々に大きくなり、新たな課題も出ているが進む方 向性は見えてきた。 - チームを作る難しさ、文化を作る難しさはQiita:Teamサービス からも感じているが、それを乗り越える方法は存在しそう。 - 試行錯誤しながら進んできたことが、「不可能に見えることに チャレンジし続ける」文化を醸成している。
- 56. 終