Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
Qiita:Teamの開発を通して見つけてきた、Incrementsの文化を作る方法
Search
Hiroyuki Tomine
March 31, 2016
Technology
30
8.7k
Qiita:Teamの開発を通して見つけてきた、Incrementsの文化を作る方法
dotsカンファレンス2016で発表した資料です。
Hiroyuki Tomine
March 31, 2016
Tweet
Share
More Decks by Hiroyuki Tomine
See All by Hiroyuki Tomine
【3/31】Hello Cluster イベントレポート/20210331-hellocluster
htomine
0
340
【3/16】Hello Cluster /20210316-hellocluster
htomine
0
370
2021/03/09 Hello Cluster 本編
htomine
0
350
2021/3/1 Hello Cluster
htomine
0
390
2021/03/02 Hello Cluster 本編
htomine
0
360
バーチャルSNS cluster の楽しみ方 @UIT meetup vol.8 online / uitmeetup-cluster
htomine
0
380
Qiita x Slack
htomine
0
1k
Qiita x 機械学習/ Machine Learning on Qiita
htomine
0
47k
及川卓也からの伝言 「PMの心得3条」
htomine
48
19k
Other Decks in Technology
See All in Technology
Amazon CloudWatchで小さく始めるWebサービスのオブザーバビリティ / How to start Observability for Web Sevices with Amazon CloudWatch
sms_tech
3
110
トークナイザー入門
payanotty
2
1k
The People First Approach to Engineering Success - DevNot 2024
zikriyeurkmez
0
180
スタサプ ForSCHOOLアプリのシンプルな設計
recruitengineers
PRO
3
720
不要なリソースを自動で定期的に整理する方法 ~Sandboxアカウントのコストを削減しよう!~
amixedcolor
3
140
データ分析基盤のためにS3を深堀りする~アーキテクチャ設計の考え方のヒントに~
nrinetcom
PRO
1
180
From naive to advanced RAG: the complete guide
glaforge
0
350
RAG: from dumb implementation to serious results
glaforge
0
350
Castor - Le Task Runner PHP qui simplifie votre Workflow
lyrixx
1
320
普通の Web エンジニアのための様相論理入門 #yapcjapan / YAPC Hakodate 2024
ytaka23
7
1.6k
テクニカルライターのチームで「目標」をどう決めたか / MVV for a Team of Technical Writers
lycorptech_jp
PRO
3
130
Unlearn Modularity
lemiorhan
6
200
Featured
See All Featured
The Straight Up "How To Draw Better" Workshop
denniskardys
232
130k
Designing with Data
zakiwarfel
98
5.1k
GraphQLとの向き合い方2022年版
quramy
43
13k
Reflections from 52 weeks, 52 projects
jeffersonlam
346
20k
How GitHub (no longer) Works
holman
311
140k
Practical Orchestrator
shlominoach
186
10k
How to name files
jennybc
77
99k
The Art of Delivering Value - GDevCon NA Keynote
reverentgeek
4
120
Scaling GitHub
holman
458
140k
Responsive Adventures: Dirty Tricks From The Dark Corners of Front-End
smashingmag
249
21k
4 Signs Your Business is Dying
shpigford
180
21k
Clear Off the Table
cherdarchuk
91
320k
Transcript
Qiita/Qiita:Teamの開発を通して見つけてきた、 Incrementsの文化を作る方法 Increments株式会社 東峰 裕之 @htomine
@htomine とみね - Increments株式会社 - デザイナ、ユーザーコミュニケーショ ン、アシスタントPOっぽいことなど - その他の属性 -
ex サイボウズ社 - ex はてなインターン - コミケット準備会 自己紹介
目次 1. ++ってどんなチーム? 2. 何を大事にしているか a. Back to 2014 i.
何を大事にしていたか b. そして現在 i. 何を大事にしているか 3. Qiita:Team開発から得た ヒント
1. ++ ってどんなチーム?
設立:2012-02-29 ㊗ 4年目! サービス: Mac / Win 人数:14名 ソフトウェア開発を良くすることで、
世界の進化を加速させる
14名の内訳
14名の内訳 = PM/PO
ファウンダー3人の共同創業 エンジニア・ビジネス・デザイナとバランスがよい。 この3人が合議して進めていくスタイル。
エンジニア vs デザイナ エンジニア:6名 Qiita 2名、Team 2名、Kobito 1名、インフラ 1名 デザイナ:
3名(マネジメント+2名) 人数の割にはプロダクトが多い。 デザイナはプロダクト横断で 随時プロジェクトに参加。 仮説検証〜設計〜実装まで 全員が参加する。
2. 何を大事にしていたか
Back to 2014
当時のメンバー:6名
実質開発チーム:3名+1名… この状況で大切にしていたこと
この状況で大切にしていたこと 1. 何を作るかより、何を作らないか 2. ユーザーヒアリングをしまくる 3. 属人性の排除・自動化
1. 何をつくるかより、何をつくらないか - 考えざるをえない… 重要な価値に集中する - Running Leanを実践実践実践 - 「価値仮説」ベースのコミュニケーション
- MVPで検証し、すぐ捨てる - ムダな作り込みは悪! - デザイナって仮説検証する人でしょ?
1. 何をつくるかより、何をつくらないか 価値仮説テンプレート - 価値仮説でコミュニケーショ ンすることで、素早くブレなく 共有できる。 - 効率的にアナも見つけられ る。
- 「この欲求本当にブレ ない?」など議論が明 確になりやすい。 https://speakerdeck.com/katsuma/service-development-for-users?slide=36
2. ユーザーヒアリングしまくる - 内部に声はないと思え - 他企業経験者も少ない、社会人経験も浅い - どんどん外に聞くしかない - エンジニアもデザイナもヒアリングする
- CTOがひとりで10件20件ヒアリングしてたことも
2. ユーザーヒアリングしまくる ヒアリング 266件 300人以上に会ってる 1アクションで5件〜10件ぐらい。 ただし、言っていることを文字通り解釈するのではなく、何を意図しているか理解する
3. 属人性の排除・自動化 - 手でやってたらまわらない! - 適切な粒度・量・相手を判断して、自ら情報を共有する - 自動化(面倒なルーチンワークを疑う)
3. 属人性の排除・自動化 - ちゃんとシェアしよう、という動き - 「それTeamに書いとこうよ」「それまとまってないのはよくな いね」→ドキュメント化 - 日報の所感を活用 -
他で拾いづらい情報を非同期で得られる - Qiita:Teamに書いてあれば、誰でも再現・再利用 可能
3. 属人性の排除・自動化 面倒なルーチンワークは常に疑う 例)某勤怠管理サービスを導入 → 勤怠(出社および退勤)を入力す るWebシステムがイケてない(良く ある)→ ブラウザとWeb間の通信 を解析
→ Qiitanで入力可能に
自動化の例:ChatOps チャットサービス上で • 開発チームの情報を集約 • 高機能Botにより各種自動 化ツールを操作
Qiitan c.f ) Ruby製HubotクローンのRubotyをSlackで動かす - Qiita
Qiitan 画像検索
Qiitan 天気予報 渋谷ランチ情報 rubyコード実行
Qiitan 掃除時間と当番の割り当ての通知
Qiitan GitHubへのIssue登録 Deploy & Mergeリクエスト
Qiitan #from_twitterでQiitaについてのツイートを収集
まとめ:何を大事にしてきたか - Lean Startupの徹底的な実践 - 素早い意思決定で少ないリソースを補う - 価値仮説テンプレート - 足で稼ぐヒアリング力
- 属人性の排除・自動化 - どんどん自動化する - これを強くモチベートするハッカー文化 - それが期待できる人材の採用
そして現在
14名に増えた(だいたい倍)
新しい状況、新しい課題 1. 多様化への対応 2. プロダクト体制の強化
1. 多様化への対応
1. 多様化への対応 - 多様化してきた、しかも尖った人ばっかりだ! - 文化は合ってる。ただし趣向は違う。 - 多様であり、かつ同じ文化に共鳴する集団であることは、今の 強みでもある。 -
暗黙の認知を元にした気持ちの良いコミュニケーション。 ハッカー文化への信頼・信望が支えている。 - チームとしては、この状況を支えたい
1. 多様化への対応 個々の働きやすさの担保 - 我々の信望する文化というのは、そんなこ とぐらい許容できるはずだ! - →フレックス&リモートワークの導入 他人に強要しない文化 -
飲み会、遊び - やきそばを焼く - やりたい人がやる、やりたくない人はやらな い
1. 多様化への対応 社長⇔各社員での月イチ1on1 - 業務の面だけでなく、「会社について期待すること、不満に思う こと、社内で気になっている噂などはないか」という話題 - 会社:社員を知ることを諦めない - メンバー:会社が「よくしてくれるはず」という期待を捨てない
2. プロダクト体制の強化
2.プロダクト体制の強化 - 以前は共有されていたプロダクトのビジョンが本当に伝わって いるか - いや、ドキュメント化はされているのだけど、浸透はしてい ないんではないか…とかの不安 - 各自がオーナーシップを取れる状態なのか -
→プロダクトの体制も、もう一段階進化が必要
2. プロダクト体制の進化 - POを置き直す - 売上や会社の体制まで含めて意思決定できるよう、社長 に一旦POを戻す(Qiita:Team) - 開発メンバーとの対話もよりしやすくなった -
PO経験者を採用する - 未経験のなか模索してきたのがこれまで。 - よりレベルをあげるために、経験値の高いメンバーにJoin してもらう - ていうかプロダクトの数と PMの人数合ってないし!
2. プロダクト体制の進化 - 『及川ショック』?! - 長年のPM経験のある及川さんを採用
2. プロダクト体制の進化 - OKR の導入 - Objectives and Key Results
- 目標とその結果の定義と達成のためのメソッド 詳細はこの辺へ: http://hiromaeda.com/2015/01/19/okr/ http://yaotti.hatenablog.com/entry/2015/02/15/001352
http://www.slideshare.net/jaymeh13/object-
None
2. プロダクト体制の進化 - 上から下まで一貫した目標設定ができたことで、課題ドリブン の価値仮説だけでなく、プロダクトのゴールに向けたアクション として見通しが良くなった - OKRにひも付けてアクションプランを管理でき、メンバーも常 に意識する(ようにしていく) -
Midpoint Checkを実施して細かく修正 - 何事も細かく考え過ぎないように!
2. プロダクト体制の進化 ドキュメントの整備 - PRD (Product Requirements Document) の項目を統一 -
Github Issuesにテンプレートを用意(Feature Request/Bug Report) プロダクトキックオフの手順書 - 価値仮説・LeanCanvasとの接続 - 価値仮説は要件定義の最小セット - ここはまだちょっと小慣れていない
まとめ:何を大事にしているか - メンバー・会社両方から、多様性を許容する努力をし続けるこ と - それを良しとする文化を自分たちは大事にしていると胸を 張って言えるようにする - 時には経験者にインストールしてもらうことも有効w -
自分たちで咀嚼し、身につけていくフローは必須 - チームで考える体制を如何に作っていくか
3. Qiita:Teamから学んだこと
Qiita:Teamから学んだこと - 2014年〜2015年まではTeamに注力した年でもあった。 - 自チームのあれこれを試行錯誤する時、常にQiita:Teamの ユーザーとしてのチームの姿を考えてきた。
Qiita:Teamでよくある課題 - 「導入したのにメンバーが使ってくれない!」 - 「なんでこのツールが必要か上司が分かってくれない!自分 でもうまく言語化できない…」 →チームを変えるアクションは、常に人と人との関わりの中 で生 まれる。そのため常に複雑で、常に難しい。あまつさ え、答えも ない。
良いチームを考えていかねばならない どうすれば良いチームになれるか。 良いチームとはなんだろうか? Objective: ++を最高のチームにする KeyResults: 最高のチームの条件を考える このKRへのアクションとして行っているのが、 ある本の輪読会。
TEAMING 輪読会 - 複雑化する現代のチームで、成果を出すにはど ういうアプローチが必要か書かれている - 「学習する組織」づくり - それにはコミュニケーションと協調がいる -
意見の相違の乗り越え - 解決策が生まれるまで 議論できる関係性 - 安心して率直に述べられる環境 - 質問したり、共有することを後押しするリーダー
最高のチーム? - 意見の相違が乗り越えられ - 解決策が生まれるまで議論できる関係性があり - 安心して率直に意見を述べられる環境である これが出来る組織でなら、困難を乗り越えていけそうに感じられる。 しかし実現するのはすごく難しそう …。
と、いう事が書いてある本をみんなで読んでいる。 チーム全員で考えることにつながっていると思う。
まとめ:Qiita:Teamから学んだこと - 感情的な部分を乗り越えてチームを変えていくことはとても困 難 - ただ、その努力は放棄してはいけない - 超えるために必要なことは何か、リーダー・メンバーともに出来 ることがある -
チームで考えていくことが必要。輪読して意見を交わすこと はその貴重な機会になっている。
まとめ
Incrementsの開発チーム - 少人数から徐々に大きくなり、新たな課題も出ているが進む方 向性は見えてきた。 - チームを作る難しさ、文化を作る難しさはQiita:Teamサービス からも感じているが、それを乗り越える方法は存在しそう。 - 試行錯誤しながら進んできたことが、「不可能に見えることに チャレンジし続ける」文化を醸成している。
終
かんたん・気軽に書ける、 チームを強くする為の社内向け情報共有サービス 導入企業一覧
知見を共有しスキルを高めることができる プログラミングに特化したオープンな情報共有コミュニティ かんたんにわかりやすく 書ける タグやストックで 見たい記事がみつかる 編集リクエストで 知恵を分けあえる シンプルで使いやすい 専用エディタ