http://connpass.com/event/10347/ これのLTです。 若手じゃないです。つらい。

1. プランナーがPR駆動
してみた話
若手エンジニアが語るGitHub社内活用勉強会

2. 自己紹介
• 大村理乃
• 株式会社マイネット
• ゲーム運営部門プロデューサー
(という立て付けのなんでもやる人)
• 2012年10月入社
• ソシャゲ作ってます
• ごめん若くないよ…

3. 内容
• 今日のLTに向いている方
– 「プランナーがGitHub使うようになるとこん
なメリットがあるよ」とチームを説得したい
エンジニアの方
– 「プランナーがGitHubを使うためにはどのよ
うな準備が必要なのか」と考えているエンジ
ニアの方
– 実際にプランナーがGitHubを使用したらどう
なるのかイメージしてみたい方

4. 導入して良かった点
• 安全にコードを見ることができる
– 何らかの障害が発生した際に原因の切り分け
がしやすく、自分で対応できる範囲が増えた
• エンジニアに聞かずとも自分で確認でき
る範囲が増えたので仕事捗る

5. コードを見れる幸せ
• 障害発生時(インフラ以外)のフロー
– アラートメール届く(帰宅後とかに)
– どこに問題があるかわからずエンジニアの確
認を仰ぐ(返答までやきもきする)
– その間にもアラートメールはガンガン来る
– とてもつらい

6. GitHub導入後
• アラートメール到着
→masterブランチのコードを確認(プラン
ナーでも安全に見られるので)
→どのあたりに問題があるのかアタリを
つける
→原因にアタリをつけて、プランナー側
で修正できる部分は修正する
→殆どの場合、それで解決。はっぴー。

7. 問題解決が早くなった
• ちょっとした疑問点はプランナーでも聞くよ
りコード見たほうが早いことが多い
• 「この画像って既に取り込んでるんだっ
け？」というのをエンジニアに確認せずとも
自己解決できる
• 自分で安全に確認できる手段があったほうが
圧倒的にスムーズだし早い
• 何か問題が発生したとき、原因がわからず問
題の切り分けができないのはとてもつらい

8. とはいえ
• それなりに学習コストがかかる
→学習コスト以上のメリットを提示しな
いといけないよね

9. 浸透させるために
• プランナー&デザイナーにGitHubを使用し
てもらうためには
– まずGitHubというツールを利用するメリット
を説くこと
– SIerばりのマニュアルも必要かも
– チーム内にGitHubおじさんがいること
– 導入当初のエンジニアの忍耐力超大事

10. メリット
• プランナーが使うためにはメリットを説
く必要アリ
– 各職種でGitHubを使うようになる
→無駄な作業の軽減
→エンジニアの工数が減る
→その分を新規開発に充てられる！
– やりたい施策いっぱいあるよね
→よろしい、ならば(ry

11. 最大のメリット
• プランナーがやりたい施策は非常に多い
＆細々としたものが多い
• けれどもやりたい施策に対してエンジニ
アの工数が圧倒的に足りない
• エンジニアの仕事をスムーズにすること
こそが、やりたい施策実現に近づける
よ！

12. よさげ
• エンジニアから無駄な工数を省いて開発
に集中できる環境を作ること
→プランナーがやりたいことを実現でき
る可能性が高くなる

13. 導入するために
• 使用するメリットを説くこと
• SIerばりのマニュアル
• チーム内にGitHubおじさんがいること
• 導入当初のエンジニアの忍耐力

14. 新機能開発の時にも役立つ
<今まで＞
1. SpreadSheetに仕様を書く
2. エンジニアに依頼(chatworkとかで)
3. 実装&仕様上足りない部分はchatworkや
口頭で確認の上詰めていく
4. 完成&プランナー側に「こんなtable作っ
たのでここにデータ入れといてくださ
い」的なシートを作る

15. 情報分散してない？
• 追加機能開発の際に、当時の仕様書を探すの
が大変
• その仕様書も正しいかどうかがわからない
• そもそもプランナー⇔エンジニア間で使用す
るコミュニケーションツールとGitHub上とで
最新の情報が分散されていて何が最新なのか
よくわからない問題
• その仕様に落ち着いた過程がわからず苦しむ
のは未来の誰か

16. シンプルにしよう
• やりたいことや仕様を記載したissuesを立
てる
• そこからエンジニアがmilestoneを設定し、
開発をはじめる
• 仕様の変更等ある場合はコメントに残す
(残してないのもありますごめんなさい)
• 出来上がったらプランナーに連絡

17. issues例

18. issues例

19. 連絡もシンプルに
• 実装完了したらエンジニアがプランナーにissues
かコードのURLを共有
• それを見つつプランナーが必要そうなドキュメン
トを整備したり、データを整備したりする
• プランナー⇔エンジニア間で発生しうる諸雑務が
軽減される

20. シンプル&わかりやすく
• エンジニアへの依頼はとりあえずissuesを
立てる
• 疑問点はコメントで解消
• 途中経過が可視化されるので後からPJに
入ってきた人でもわかりやすい。
• 立てたissuesが気づいたら消化されて
closeされてることもある。うれしい。

21. 障壁
• 最初の学習コストがかかる問題
– まずは開発用リポジトリとは別のリポジトリ
を立てて慣れてもらう
– ブランチの概念がわかりづらいので丁寧に教
えてあげる
– 1時間程度の部内勉強会開くといいかも

22. プランナーはデリケート
• イレギュラーなエラーやコンフリクトは
必ず起きる
– GitHubおじさんが優しく対応してくれると捗
る
– 同じミスを2回くらい繰り返すと知見がた
まってくるのでミスしづらくなってくる
– それまでどうか根気よく教えてください

23. 安全に運用するために
• プランナーが確認して問題ないと判断し
たもの以外はマージしない
– マージさえしなければ何とでもなるから安全
• プランナーでも安全に使える環境を
– 最初にエンジニアがきちんとしたブランチ戦
略を提示してあげるとハッピー
– featureブランチはエンジニアが切って、それ
以下のブランチはプランナーが切るなど

24. おすすめ本
• 非常にわかりやすく、プラ
ンナーにもおすすめ
• Gitとは？を教える本は多く
あれどGitHubとは？を教え
てくれる本は結構少ない

25. 今抱えてる問題
• GitHub for Windows(or Mac)が使いづらい
問題
– ローカルブランチ増えすぎて間違えてブラン
チ消してしまった問題
– Syncが遅くて使い物にならないときもある
– でもGUIじゃないと使いづらいし…
– 結局Git Shell開いて手動でgit pullしてる
– 現在進行形でつらみ感じてる

26. それでも使ったほうがいい
• 新しいことを覚えるのはやっぱり楽しい
• ソシャゲや小規模なWeb開発チーム特に、
エンジニアのテンションが上がったほう
がいいもの作れる
もちろんプランナーやデザイナーのテンションが上がるのも超大事だけどね
• ツール1つでテンションが上がるなら導入
すべき

27. ご清聴ありがとうございました