GREE - Shinji

[インタビュアー] 仕事の内容についてちょっと話して下さい

堀口 真司と申します

GREE では 私はインフラの管理をしていまして－

インフラサーバーのメンテナンス－

または そのインフラサーバーのメンテナンスを
する人たちのためのツールを作っております

私がソフトウェアに興味を持ったきっかけは－

まずはその家庭用ゲームをよくプレイしてまして－

家庭用ゲームをプレイしていくうちに－

こう私も そういうゲームを作りたいな ということで
コード プログラミングの勉強を始めて－

そのままずっと こう仕事になっています

私がGREEに入ったきっかけは－

GREEのエンジニアさんたちと
他のカンファレンスなどで会うことが ありまして

そこで こう GREEの人たちと話しているうちに－

GREEのエンジニアリングスキルの
高さにすごい惹かれて－

私も こうなれたらいいなと思って
GREEに入っています

[インタビュアー] ワークフローをちょっと話していただけますか

GitHub 導入前は
普通のGitコマンドの方を使っていまして－

そのときは 自分たちで Git のサーバー
リモートサーバーを立てて－

Origin サーバーも立てて
バグトラッキングシステムを作って－

で パッチができあがったら
リモートにプッシュして－

Request Pull コマンドを使って－

他の人にフェッチしてもらう
ということを やってました

GitHub Enterprise を導入してからは
まず 自分たちでリモートを立てることがなくなって

元々あるオリジナルのところをFork するだけ

またあと 今まではRequest Pull コマンドを使って
他の人たちにフェッチしてもらっていたところを－

プッシュして Pull Request を送るだけで
他の人たちにレビューしてもらえるので－

バグトラッキングシステムは使わなくなったし－

コミュニケーションツールとして
GitHub Enterprise を中心に使うことになっています

[インタビュアー] Pull Request のおかげで
バグトラッキングシステムを使わないことになったんですか？

そうですね はい

[インタビュアー] Pull Requestだけで？

だいたいPull Request だけで
ま、他もあるんですけども

[インタビュアー] 中心は？

ま だいたい Pull Request だけで我々は やっております

GitHub Enterpriseで 特に気に入っている機能とは
ネットワークグラフが見やすいので－

乱れたコミットがないか とか－

コミットツリーおかしいところの発見に
すごい役立っていますし－

あと ハッシュがどこにでも出ているので－

こう 自分たちで 分散開発をすごい意識するようになって
開発を進めています

たとえば ネットワークグラフを使うことで－

Pull して Push するだけだと
こう どんどんどんどんマージされていってしまって－

こう グラフが乱れていくんですけれども－

そこをこう 事前に察知することができて－

このコミットはちょっと この 依存関係がおかしいっていうのが
目で見て分かるようになったのが素晴らしい

ゲームの魅力的なところとしては－

やっぱりこう 日頃得られない体験が
得られるところにあると思っていて－

たとえば 私は FPS が大好きなんですけれども－

まあ そのFPSのような超人的な動きはできないですし

あとは RTS も好きでして－

RTSの自分が司令官になっているような
雰囲気にもなれないので－

そういうところに私はすごい魅力を感じています

GREEのゲームは コンソールゲーム機のように
こう 没頭して 集中してやるというよりは－

すきま時間で できるところが
こう 大変良いポイントだと思っていて－

たとえば その家庭用ゲームの場合は－

こう テレビをつけて 電源を入れて
コントローラーを握って－

こう何時間も遊ばなければ いけないけれど－

GREEのゲームは こう スマートフォンをいじるだけで
遊べるので

うーん なんかちょっと違うな
ちょっと待って下さい

十年前は まずモバイル端末がなかったので
事実上そこでゲームを遊ぶことはできないので

こう みんな家に帰るか
家に帰ってテレビをつけてゲームを遊ぶか－

PC でゲームを遊ぶんですけれども

今は それが外に持ち出せるというのが
大きな違い ではないですかね

GitHub だったり まあGit もそうなんですけれども
最も大切なのは－

分散開発を意識して行うということが
大切だと思っていて

分散開発を意識しないと
たとえばGitHub Enterprise を使っていても－

そのSubversion 時代の頃のように
上手くワークフローが回らないで－

自分の意図した思い通りの修正ができなかったり
はしますね

私はこう GREEに来る GREEにJoinする頃に
大体GitHub Enterprise も導入されたんですけれども－

そこで こう 他のスタッフの働き方を見てると－

GitHub Enterprise を使ってるんですけれど
分散開発が上手く回っていなくて－

そこでこう 折角 良い道具を使っているのに－

これでは今までのSubversion 時代の頃の集中開発を
していた時代よりも非効率的だと思っていたので－

こう 私は なるべく GitHub Enterprise の
正しい使い方みたいなのを広めていこうと－

そういう活動もしております

そうですね 分散開発を上手くやることで－

たとえば 自分が修正したいポイントに戻って
そこにコミットして－

そのコミットを複数のブランチに
Pull Request を出すことによって－

集中開発時代ではできなかったような
パッチの当て方もできますし

たとえば 自分が歴史を書き換えたいときに
昔の失敗なんかを修正したいときも－

他の人に影響をなるべく与えずに
自分のリモートだけで作業できて－

まずはレビューしてもらって－

その後に えー Pull Request んー
ちょっとこれは無しだな

Git のワークフローを まず正しく回すことによって
他人をブロッキングすることがなくなるのと－

まああと 間違ったコミットをしにくくなる

間違ったコミットをしても
プロダクトに影響を与えないように作れたり

まああとは テストをするための
テストのコミットなんかも手軽に使えるようになる

ここら辺がGit のワークフローを上手く回す上で
すごい大切だとは思ってます

[インタビュアー] その編集する目的ってなんですか 短く言うと

Git を使って歴史を書き換えてしまうところには
こういろいろ問題点もあるんですけれども－

私が一番重視しているのは 美しくするという所が
ものすごく大切だと思っていて

ネットワークグラフを見られている歴史っていうのは
そもそも良くない歴史である可能性が高いので－

そこをきれいにしてしまおうと

もちろんきれいにする前には
いろいろ合意を取らなければいけないんですけれども－

ま そこで チーム内で上手く合意を取って
これから歴史をきれいにしますということを－

上手く回すと
これからもチームが健全に育っていくというか

汚いコミットをしなくなっていく

というところがすごい大切だと思っています

[インタビュアー] どういう風に役に立っていると？

GitHubを使わない場合は－

まず自分たちでテスト用のリモートサーバー－

自分のリモートサーバー 他にもリモートのサーバー
リモートのリポジトリを作らなければいけないんですけれども

そこのコストが全然かからなくなる

あと 普通のGit であれば コミュニケーションツールを
別途用意しなければいけないんですけれども－

そのコミュニケーションツールを用意して
他のツールを使ってコミュニケーションをするっていう－

ロスがなくなる

そこで時間的なロスが
時間的なコストがかからなくなるので－

GitHub Enterprise を使うことで
チーム内のプロダクトを そこにかけるコストがなくなるので－

本業のプロダクトを作るために
多くの時間をかけることができます

そうですね
今まで普通のGit を使っていたんですけれども－

Git っていうのはLinux のカーネル開発から
生まれたツールなので

すごい堅苦しいことが多かったんですけれども

それが GitHub Enterpriseを使うことで
すごいカジュアルに使えるようになって－

そこにすごい 私は GitHub Enterprise の魅力を
感じています

そうですね GitHub Enterprise は
すごい簡単に使えるんですけれども－

そこが良くないのかなと思っていて－

それまでは自分たちでリモートを作って
そこにコミットをして－

自分たちで レビューしてもらう
手探りで ワークフローを回していたんですけれども

GitHub Enterprise を導入してしまうと
ものすごい手軽に できてしまうので－

分散開発ってのを 分散開発のワークフローを回さずに
開発に入っていくことができてしまう

スキルの低い人たちが
すごい疑問無しに使ってしまうところが－

私はちょっと良くないなと思って

なので こう 分散開発に対するアプローチを
もう少し増やして欲しい

具体的にはないんですけど