Upgrade to Pro — share decks privately, control downloads, hide ads and more …

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

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

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

Hiroyuki Tomine

March 31, 2016
Tweet

More Decks by Hiroyuki Tomine

Other Decks in Technology

Transcript

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

    View Slide

  2. @htomine
    とみね
    - Increments株式会社
    - デザイナ、ユーザーコミュニケーショ
    ン、アシスタントPOっぽいことなど
    - その他の属性
    - ex サイボウズ社
    - ex はてなインターン
    - コミケット準備会
    自己紹介

    View Slide

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

    View Slide

  4. 1. ++ ってどんなチーム?

    View Slide

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

    View Slide

  6. 14名の内訳

    View Slide

  7. 14名の内訳
    = PM/PO

    View Slide

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

    View Slide

  9. エンジニア vs
    デザイナ
    エンジニア:6名
    Qiita 2名、Team 2名、Kobito
    1名、インフラ 1名
    デザイナ:
    3名(マネジメント+2名)
    人数の割にはプロダクトが多い。
    デザイナはプロダクト横断で
    随時プロジェクトに参加。
    仮説検証〜設計〜実装まで
    全員が参加する。

    View Slide

  10. 2. 何を大事にしていたか

    View Slide

  11. Back to 2014

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

  15. 1. 何をつくるかより、何をつくらないか
    - 考えざるをえない…
    重要な価値に集中する
    - Running Leanを実践実践実践
    - 「価値仮説」ベースのコミュニケーション
    - MVPで検証し、すぐ捨てる
    - ムダな作り込みは悪!
    - デザイナって仮説検証する人でしょ?

    View Slide

  16. 1. 何をつくるかより、何をつくらないか
    価値仮説テンプレート
    - 価値仮説でコミュニケーショ
    ンすることで、素早くブレなく
    共有できる。
    - 効率的にアナも見つけられ
    る。
    - 「この欲求本当にブレ
    ない?」など議論が明
    確になりやすい。
    https://speakerdeck.com/katsuma/service-development-for-users?slide=36

    View Slide

  17. 2. ユーザーヒアリングしまくる
    - 内部に声はないと思え
    - 他企業経験者も少ない、社会人経験も浅い
    - どんどん外に聞くしかない
    - エンジニアもデザイナもヒアリングする
    - CTOがひとりで10件20件ヒアリングしてたことも

    View Slide

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

    View Slide

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

    View Slide

  20. 3. 属人性の排除・自動化
    - ちゃんとシェアしよう、という動き
    - 「それTeamに書いとこうよ」「それまとまってないのはよくな
    いね」→ドキュメント化
    - 日報の所感を活用
    - 他で拾いづらい情報を非同期で得られる
    - Qiita:Teamに書いてあれば、誰でも再現・再利用
    可能

    View Slide

  21. 3. 属人性の排除・自動化
    面倒なルーチンワークは常に疑う
    例)某勤怠管理サービスを導入 →
    勤怠(出社および退勤)を入力す
    るWebシステムがイケてない(良く
    ある)→ ブラウザとWeb間の通信
    を解析
    → Qiitanで入力可能に

    View Slide

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

    View Slide

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

    View Slide

  24. Qiitan 画像検索

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

  29. まとめ:何を大事にしてきたか
    - Lean Startupの徹底的な実践
    - 素早い意思決定で少ないリソースを補う
    - 価値仮説テンプレート
    - 足で稼ぐヒアリング力
    - 属人性の排除・自動化
    - どんどん自動化する
    - これを強くモチベートするハッカー文化
    - それが期待できる人材の採用

    View Slide

  30. そして現在

    View Slide

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

    View Slide

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

    View Slide

  33. 1. 多様化への対応

    View Slide

  34. 1. 多様化への対応
    - 多様化してきた、しかも尖った人ばっかりだ!
    - 文化は合ってる。ただし趣向は違う。
    - 多様であり、かつ同じ文化に共鳴する集団であることは、今の
    強みでもある。
    - 暗黙の認知を元にした気持ちの良いコミュニケーション。
    ハッカー文化への信頼・信望が支えている。
    - チームとしては、この状況を支えたい

    View Slide

  35. 1. 多様化への対応
    個々の働きやすさの担保
    - 我々の信望する文化というのは、そんなこ
    とぐらい許容できるはずだ!
    - →フレックス&リモートワークの導入
    他人に強要しない文化
    - 飲み会、遊び
    - やきそばを焼く
    - やりたい人がやる、やりたくない人はやらな

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

  39. 2. プロダクト体制の進化
    - POを置き直す
    - 売上や会社の体制まで含めて意思決定できるよう、社長
    に一旦POを戻す(Qiita:Team)
    - 開発メンバーとの対話もよりしやすくなった
    - PO経験者を採用する
    - 未経験のなか模索してきたのがこれまで。
    - よりレベルをあげるために、経験値の高いメンバーにJoin
    してもらう
    - ていうかプロダクトの数と PMの人数合ってないし!

    View Slide

  40. 2. プロダクト体制の進化
    - 『及川ショック』?!
    - 長年のPM経験のある及川さんを採用

    View Slide

  41. 2. プロダクト体制の進化
    - OKR の導入
    - Objectives and Key Results
    - 目標とその結果の定義と達成のためのメソッド
    詳細はこの辺へ:
    http://hiromaeda.com/2015/01/19/okr/
    http://yaotti.hatenablog.com/entry/2015/02/15/001352

    View Slide

  42. http://www.slideshare.net/jaymeh13/object-

    View Slide

  43. View Slide

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

    View Slide

  45. 2. プロダクト体制の進化
    ドキュメントの整備
    - PRD (Product Requirements Document) の項目を統一
    - Github Issuesにテンプレートを用意(Feature Request/Bug Report)
    プロダクトキックオフの手順書
    - 価値仮説・LeanCanvasとの接続
    - 価値仮説は要件定義の最小セット
    - ここはまだちょっと小慣れていない

    View Slide

  46. まとめ:何を大事にしているか
    - メンバー・会社両方から、多様性を許容する努力をし続けるこ

    - それを良しとする文化を自分たちは大事にしていると胸を
    張って言えるようにする
    - 時には経験者にインストールしてもらうことも有効w
    - 自分たちで咀嚼し、身につけていくフローは必須
    - チームで考える体制を如何に作っていくか

    View Slide

  47. 3. Qiita:Teamから学んだこと

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

  51. TEAMING 輪読会
    - 複雑化する現代のチームで、成果を出すにはど
    ういうアプローチが必要か書かれている
    - 「学習する組織」づくり
    - それにはコミュニケーションと協調がいる
    - 意見の相違の乗り越え
    - 解決策が生まれるまで 議論できる関係性
    - 安心して率直に述べられる環境
    - 質問したり、共有することを後押しするリーダー

    View Slide

  52. 最高のチーム?
    - 意見の相違が乗り越えられ
    - 解決策が生まれるまで議論できる関係性があり
    - 安心して率直に意見を述べられる環境である
    これが出来る組織でなら、困難を乗り越えていけそうに感じられる。
    しかし実現するのはすごく難しそう …。
    と、いう事が書いてある本をみんなで読んでいる。
    チーム全員で考えることにつながっていると思う。

    View Slide

  53. まとめ:Qiita:Teamから学んだこと
    - 感情的な部分を乗り越えてチームを変えていくことはとても困

    - ただ、その努力は放棄してはいけない
    - 超えるために必要なことは何か、リーダー・メンバーともに出来
    ることがある
    - チームで考えていくことが必要。輪読して意見を交わすこと
    はその貴重な機会になっている。

    View Slide

  54. まとめ

    View Slide

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

    View Slide


  56. View Slide

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

    View Slide

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

    View Slide