More Related Content
Similar to プランナーがPR駆動してみた話 (20)
プランナーがPR駆動してみた話
- 2. 自己紹介
• 大村理乃
• 株式会社マイネット
• ゲーム運営部門プロデューサー
(という立て付けのなんでもやる人)
• 2012年10月入社
• ソシャゲ作ってます
• ごめん若くないよ…
- 3. 内容
• 今日のLTに向いている方
– 「プランナーがGitHub使うようになるとこん
なメリットがあるよ」とチームを説得したい
エンジニアの方
– 「プランナーがGitHubを使うためにはどのよ
うな準備が必要なのか」と考えているエンジ
ニアの方
– 実際にプランナーがGitHubを使用したらどう
なるのかイメージしてみたい方
- 6. GitHub導入後
• アラートメール到着
→masterブランチのコードを確認(プラン
ナーでも安全に見られるので)
→どのあたりに問題があるのかアタリを
つける
→原因にアタリをつけて、プランナー側
で修正できる部分は修正する
→殆どの場合、それで解決。はっぴー。
- 7. 問題解決が早くなった
• ちょっとした疑問点はプランナーでも聞くよ
りコード見たほうが早いことが多い
• 「この画像って既に取り込んでるんだっ
け?」というのをエンジニアに確認せずとも
自己解決できる
• 自分で安全に確認できる手段があったほうが
圧倒的にスムーズだし早い
• 何か問題が発生したとき、原因がわからず問
題の切り分けができないのはとてもつらい
- 10. メリット
• プランナーが使うためにはメリットを説
く必要アリ
– 各職種でGitHubを使うようになる
→無駄な作業の軽減
→エンジニアの工数が減る
→その分を新規開発に充てられる!
– やりたい施策いっぱいあるよね
→よろしい、ならば(ry
- 14. 新機能開発の時にも役立つ
<今まで>
1. SpreadSheetに仕様を書く
2. エンジニアに依頼(chatworkとかで)
3. 実装&仕様上足りない部分はchatworkや
口頭で確認の上詰めていく
4. 完成&プランナー側に「こんなtable作っ
たのでここにデータ入れといてくださ
い」的なシートを作る
- 15. 情報分散してない?
• 追加機能開発の際に、当時の仕様書を探すの
が大変
• その仕様書も正しいかどうかがわからない
• そもそもプランナー⇔エンジニア間で使用す
るコミュニケーションツールとGitHub上とで
最新の情報が分散されていて何が最新なのか
よくわからない問題
• その仕様に落ち着いた過程がわからず苦しむ
のは未来の誰か
- 21. 障壁
• 最初の学習コストがかかる問題
– まずは開発用リポジトリとは別のリポジトリ
を立てて慣れてもらう
– ブランチの概念がわかりづらいので丁寧に教
えてあげる
– 1時間程度の部内勉強会開くといいかも
- 23. 安全に運用するために
• プランナーが確認して問題ないと判断し
たもの以外はマージしない
– マージさえしなければ何とでもなるから安全
• プランナーでも安全に使える環境を
– 最初にエンジニアがきちんとしたブランチ戦
略を提示してあげるとハッピー
– featureブランチはエンジニアが切って、それ
以下のブランチはプランナーが切るなど
- 25. 今抱えてる問題
• GitHub for Windows(or Mac)が使いづらい
問題
– ローカルブランチ増えすぎて間違えてブラン
チ消してしまった問題
– Syncが遅くて使い物にならないときもある
– でもGUIじゃないと使いづらいし…
– 結局Git Shell開いて手動でgit pullしてる
– 現在進行形でつらみ感じてる