Qiitaの作り方 〜Incrementsのチーム開発とプロダクトマネージメント〜
•
25 likes•9,029 views
2016年8月30日行われたIBM Cloud Community勉強会での講演です。
Recommended
More Related Content
Viewers also liked
Viewers also liked (18)
More from Takuya Oikawa
More from Takuya Oikawa (15)
Qiitaの作り方 〜Incrementsのチーム開発とプロダクトマネージメント〜
- 2. 氏名 及川卓也 メール takoratta@qiita.com Twitter @takoratta Facebook takoratta Qiita takoratta GitHub takoratta 経歴 DEC → Microsoft → Google → Increments
- 8. すみません
- 9. Agenda - QiitaとQiita:Team - Incrementsのチーム開発
- 10. QiitaとQiita:Team
- 14. 編集リクエスト GitHubのPR (Pull Request) のよう に、変更を直接行い、それを提案とし て、作者に送ることが出来る。 作者は送られた編集リクエストを差分 の形でレビューすることができ、内容 を確認の後、採用・不採用を決める。 採用された編集リクエストより、その 後に付与されたストック数の相分の Contributionを得ることができる。
- 15. Contribution Contributionとは Contribution (コントリビューション) とは貢献度を 意味し、投稿した記事がストックがされることや編 集リクエストが受け入れられた記事がその後ス トックされることで数値が上がっていきます。編集 リクエストによる貢献は投稿した記事の貢献の 10 分の1とし、10を最大としています。
- 18. Incrementsのチーム開発
- 19. 私たちが大切にしていること 作業は意識的に自動化する Incrementsでは様々なレイヤーで自動化を推し進めています。 自動化できる作業は自動化することで、ユーザーヒアリングや設 計など自動化できない創造的な仕事により多くの時間を充てら れるようにしています。また自動化して作業がコード化されると、 作業内容が可視化されるため作業フローを改善しやすくなりま す。効率化のための改善は継続的に行っています。 重要な価値に集中する Incrementsは「本当に必要かどうか」を考えることをとても大事 にしています。リーン・スタートアップを元とした開発フローを構築 しており、実装する前に価値仮説を立てて、提供したい価値や解 決したい課題を明確にすることに時間をかけています。またユー ザーヒアリングを非常に大事にしています。エンジニアでも直接 ユーザーからフィードバックを受ける機会が多いので、自分の考 えだけに寄らずユーザーのニーズに沿った開発を無駄なく行え ます。そのため、エンジニアでもユーザー体験を重要視していま す。 情報共有で属人性を減らす ミーティングの議事録はもちろん、口頭で話したようなことも価値 がありそうならば Qiita:Teamへすべてきちんと残し、特定の人達 しか知らないという状況を防いでいます。困ったことはデイリース クラム(朝会)や日報などでこまめに共有、チームみんなで解決し ていくことを徹底している環境です。 HRTを大切にしたコミュニケーション HRTとは「Team Geek ―Googleのギークたちは いかにしてチームを作るのか」という本にある考 え方で、Humility(謙遜)、Respect(尊敬)、 Trust(信頼)の3つを意味しています。「驕り高ぶら ないようにしよう」「相手を尊敬しよう」「人を信頼 してまかせよう」といった HRTの概念を意識する ことで、コミュニケーションの衝突が避けられるよ うになりました。また導入した結果、元々気をつ けている文化だったことに気づくことができまし た。
- 20. 自動化 開発フローはすでに一般的となったGitHubのPull Requestを用 いた手法 各レポジトリのmasterブランチから分岐して実装し、実装終了後 にGitHubでPull Requestを投げて、Circle CIによるCIを走らせる とともに、他のエンジニアにコードレビューしてもらい、コードレ ビューとCIが無事終了したならば、masterブランチにマージしてデ プロイ
- 21. テスト Circle CIが走る際に自動的にテストが実行される。 ● Linterによる文法チェック（静的コード解析） ○ Linterによる文法チェックはYAMLとSCSS、Rubyに対して 行われるようになっている。SCSSはscss-lintをRubyは Rubocopを使っている。 ● RSpecによる機能テスト
- 22. Circle.ymlからの抜粋 test: override: - bash script/circleci/lint_yaml.sh - bash script/circleci/lint_scss.sh: parallel: true files: - app/assets/stylesheets/**/*.scss - bash script/circleci/lint_ruby.sh: parallel: true files: - app/**/*.rb - lib/**/*.rb - spec/**/*.rb - bash script/circleci/test_rails.sh: parallel: true files: - spec/**/*_spec.rb - bash script/circleci/test_javascript.sh
- 23. bundle update Gemパッケージの更新をCIに組み込む。 ● Circle CIのNightly Buildsの機能を利用。 ○ 外部から環境変数を設定した上で、特定のブ ランチのビルドを行う ○ 環境変数BUNDLE_UPDATEがtrueのときに bundle updateが起動される ○ そのスクリプトをcronで毎日実行
- 24. Circle.ymlからの抜粋 test: post: - > if [ -n "${BUNDLE_UPDATE}" -a "${CIRCLE_BRANCH}" = 'master' ] ; then bundle update fi
- 25. Cron サーバー Circle CI master ブランチの サーバー GitHub スクリプト実行でCircle CIを 起動 環境変数 BUNDLE_UPDATEを付加 してCIを実行 $ bundle update git pushおよびPull Requestの作成 hook CI
- 27. Qiitan c.f ) Ruby製HubotクローンのRubotyをSlackで動かす - Qiita
- 33. なんでも自動化＆省力化 例）某勤怠管理サービスを導入 → 勤怠（出社および 退勤）を入力するWebシステムがイケてない（良くあ る）→ ブラウザとWeb間の通信を解析 → Qiitanで 入力可能に
- 36. PM ENG ● What ● When ● Why ● How
- 37. IncrementsのProduct Management PM×2 ● 及川: Qiita ● 海野（CEO）: Qiita:Team ○ しゃちょ〜 がPMやってちゃいけないので、Qiita:Teamの PMを大募集中！
- 39. PRD (Product Requirements Document)
- 40. OKR (Objectives and Key Results)
- 41. KPIツリー
- 42. おまけ 本当はやりたかったこと
- 46. 心意気だけでも買ってください