最新情報をお届けします！
800万DLを突破したハンドメイドマーケットアプリ『ｍinne』や、レンタルサーバー『ロリポップ！』でおなじみのGMOペパボ。今回は社内コミュニケーション活性化について伺うべくCPOの柴田博志さんを直撃。GMOペパボはなぜ、全社員がGitHubを使うのか？！
エンジニア、企画、CS、人事、総務、広報、営業…
職種をまたいだコミュニケーションは、往々にして上手くいかないもの。多くの企業で課題になっているだろう。
こういった課題をユニークに解決しているのが、800万DL（*1）を突破したハンドメイドマーケットアプリ『ｍinne』で知られるGMOペパボだ。
全社でGitHub Enterprise（以下、GitHub）を導入し、全社員（以下、パートナー *2）がコミュニケーションツールとして活用する。エンジニア以外がGitHubをつかって、すべてプロジェクトベースで業務をする！？ これはなかなかないおもしろい事例だ。
322名のパートナー（*3）に対し、立てられる日別のIssue（*4）は200件ほど（月に約3800件！）。コメントにいたっては1日に1800件ほど（月に3万5000件）というから驚きだ。
なぜGitHubだったのか？エンジニア向けのツールとして広く認識されているGitHubを、どのように全社導入したのか？
執行役員 CPO(Chief Productivity Officer)で、業務プロセス革新室 室長を務める柴田博志さんにお話を伺った。
*1…出典：『minne』月次報告資料（2017年9月4日時点）
*2…GMOインターネットグループでは「社員」を「パートナー」と呼ぶ
*3…2016年12月末時点
*4…Issueとはスレッド形式で課題や議題を共有する機能。中でコメントのやりとりができる
[プロフィール] 柴田博志｜GMOペパボ株式会社 執行役員CPO兼業務プロセス革新室 室長
楽しさにはビジネス価値がある、を合言葉にGMOペパボの仲間が楽しく、「生産性」を発揮できるような環境を作ることをミッションとしている。同時に、プログラミング言語 Ruby の開発チームのメンバー。他にも rake、rdoc、psych、ruby-build などのメンテナ、ruby-lang.org の管理者をしている。
― エンジニアだけではなく、社員みんなでGitHubをつかっていると伺いました。
そうですね。ペパボだとパートナー全員がGitHubのアカウントを持っています。それぞれの職種で利用方法ははさまざまですが、エンジニア以外のメンバーに関しては「Issue機能」をメインで使っていることが多いです。
たとえば、カスタマーサービス（CS）を例にお話すると、「お客様サポート」のページを通じてお問い合わせを受けたとき。まずは「Zendesk（*5）」にあるナレッジや情報で対応していきます。基本的には、その場でCS自身が回答できるのですが、どうしてもCSグループ内では解決できないこともある。他のグループに意見を求めたいシーンも当然あります。
そんなとき、GitHubに「Issue」を立てて、「いつ、どのようなお客様が、どのようなことで困っている」という旨を記載し、ZendeskのURLを添えて投稿していくんです。
そしたら、エンジニアやディレクターなど、この問題に詳しい人が具体的な解決方法を回答する。それをCSがまたお客様にお伝えする、という流れです。
ペパボで運営しているほとんどのサービスは、GitHub上でソースコードを管理しているので、「そのお客様が困っている原因はこのソースコードにある」とか。アップデートのリリース情報も管理しているので、「あの日にリリースした内容が問題になっている」とか、情報がどんどんGitHubに集約されてくるんです。
つまり、社内で職種を超えたいろんなメンバーの行なったことの一連の流れや気づきが、GitHubの「Issue」としてストックされていくというということですね。
*5…Zendeskとは、クラウド型カスタマーサポートツール。さまざまな窓口からの問い合わせを一元管理できる
― 職種をまたぐとIssueを作成するときの「粒度」にも迷いがありそうです。どれくらいの粒度なら「Issue」を立てていいかなどルールはありますか？
基本的にルールはないですね。むしろ、とにかく気軽にIssueを立ててほしいとみんなにお願いしています。たとえば「BBQやりたい」と社長が投げかけて、新卒メンバーが「いいじゃん！」とコメントで応戦したり（笑）こういうことがフラットに行われていますね。
この取材の依頼をいただいたときも、もちろんIssueが作成されています。広報担当者がIssueを立ててくれて、@をつけるとメンションが飛んでくるので「なんだなんだ？」と見にいくと「なんかきてる！」となるわけです。Issueをみれば背景から一気に知ることができます。
当取材が検討された、実際のやりとり
― まさか取材のお話もGitHubでやり取りされていたとは（笑）
続いて、ペパボ社内でGitHubが導入されいった経緯について伺ってもよろしいでしょうか？
元々 ペパボではサービスやプロジェクト単位で「redmine」や「trac」などを自由に選択使用していたんですよね。2012年、GitHub (github.com) が便利らしいということで、とあるプロジェクトチーム一つで利用し始まりでした。ペパボはとりあえず使ってみようという文化が大きいため、新しいツールはどこかしらで誰かが試験的に使っています。
その後、他のサービスや事業部も「便利そう」「うちでも使ってみよう！」とどんどん利用が広がっていきました。
一部セキュリティ上の問題でGitHubを利用できない大きめのサービスにおいて GitHubの Enterprise版を使いはじめました。この時点でほぼ全てがGitHub（github.com）を使っていたので「これはもう全社で導入した方がいいよね」と、2013年には、ほぼ全てのサービスで GitHub Enterpriseに切り替えた…という経緯ですね。
[取材メモ]
ペパボでは GitHub は github.com と GitHub Enterprise の二つを使い分けている。会社として外部に公開することにメリットがあるソフトウェアについては積極的に github.com/pepabo で公開。これはソフトウェアをペパボ以外の企業やエンジニアにも利用してもらうことで、フィードバックを得ることを目的とする。
GitHub Enterprise では、サービスのコードそのものをリポジトリとして保存。開発からテスト、リリースまでの一連の開発のワークフローの中心として使用する。その他、コードに限らず、事業部ごとのアイデアやバージョニングした方が良い資料やチームごとのワークフローの手順書などを保存しているという。
GitHub は単なるコードやデータの保存場所ではなく、仕事を回していく上でのコラボレーションの場となっている。
― 人事をはじめ、コードに触れない方など、馴染みないサービスの導入には戸惑うと思います。導入を疑問視する声があったりは…？
知ってる限りでは、聞いたことないですね。
ペパボはインターネットの会社ということもあって、新しいサービスや海外のサービスに対して親しみや慣れを持っている人が多いです。確かにGitHubは日本語UIではなかったり、仕様上、日本語が対応していない部分もあります。そういった小さな問題はありましたが、だから導入しないと判断するほどのことはなかったです。
たとえエンジニアだとしてもはじめて使うものはうまく使えないことがあって当然。もしIssueの立て方が間違っていたとしても、エンジニアのようなわかる人が自然とサポートする雰囲気があります。
― はじめての人でも、GitHubに馴染みやすいよう、行なったことはありますか？
とにかくGitHubは便利なものなんだと気づいてもらう工夫をしました。これは今も気をつけていることでもあって。
たとえば、新卒入社者向けの研修でGitHub講座を行なっているんですよ。Issueの作成方法や、メンションの飛ばし方から教えています。
大学時代にやってたこととか、自己紹介レジュメを作成してみる。それをPull Request(*6)する。コードを管理するツールだということもPull Requestは英語じゃないとダメだよみたいなことも、一旦置いておいて、まずは自分が慣れ親しんでいる日本語テキストで使ってみる。そうするとみんな「便利じゃん！」っていうことを自ら体験してくれるんです。その研修が終わったあと、事業部などの配属先でGitHub本来の使い方を習います。
結果的に、その研修を経た人はGitHubをガンガン活用していっていますね。GitHubに対する認識が「ソフトウェア開発のためのツール」ではなく、仕事上で発生した「自分では解決できない課題を解決するツール」だと認識しているみたいなんです。GitHubへの抵抗はない状態で入れるから飲み込みが断然違うんですよね。
「GitHubって日報を書くツールですよね？」とかいう人もいて「いやいや、ソースコード管理するツールだよｗ」とエンジニアからツッコミをもらってたり。GitHubを自分好みに使うくらいがちょうど良いと考えてます。
*6…Pull Requestとは、コードやドキュメントの変更した内容を、事前にレビューしてもらうために、他のメンバーへ知らせ、レビュー完了後に変更を反映させる機能
― ちなみに…すごい些細なことなのですが、アイコン画像を「人以外」にしちゃう人いませんか？そういった細かいところが食い違うだけでもやりづらくなってしまったり…。
GitHubに限らず、全ての社内ツールについては、「顔写真を登録する」という必須ルールを設けていますね。弊社のような300人規模の会社になると全員が全員の顔を把握するのは難しくなってきます。やはり”人となり”が見えたほうがいい。ただ顔写真といっても証明写真みたいのではなく、みんないろいろと工夫をしていて。面白いアイコンで会話がなされているとほんわかしますよね。怒られてても、なんだか和やかな雰囲気になりますね（笑）
― もう、これだけGitHubを活用されていたら…これ1つでなんでもできちゃいそうですね。
それがそうでもないんですよね。「GitHubには出来ないな」と思うことももちろんあるんですよ。GitHubだけに集約できたら便利だとは思いますが…そうはいかないですよね。
たとえば、大量の画像をアップロードすると重くなるからGoogle Driveを使うとか、やっぱりタスク管理はTrelloが良いとか。一旦GitHubを使うんですけど足りないところは別のツールを使って広げていく。そしてこれが便利だと気づいたら、またみんながそっちに移っていって、また収束する。それを繰り返して変動しながら、現在のベストツールを編み出していけばいい。
要するに私たちが求めていることは、スピードなんです。インターネットの事業会社は、良いプロダクトを作るのが役目です。そのためにはプロダクトを作って、マーケットに出して、ユーザーの評価を獲得しながら改善して…。というサイクルをとにかく早く回さないといけない。
さらにいえば、エンジニアが３分の１以上の会社はエンジニアの力が会社の競争力に直結している、そのときの選択肢がGitHubだった。今のペパボにはGitHubがマッチしている、というだけなんです。なので手段に縛られないことは大切だと考えています。もっといろいろな方法やツール、自分たちにあったやり方を模索していければいいですね。
（おわり）
文 ＝ 大塚康平
4月から新社会人となるみなさんに、仕事にとって大切なこと、役立つ体験談などをお届けします。どんなに活躍している人もはじめはみんな新人。新たなスタートラインに立つ時、壁にぶつかったとき、ぜひこれらの記事を参考にしてみてください！
経営者たちの「現在に至るまでの困難＝ハードシングス」をテーマにした連載特集。HARD THINGS STORY（リーダーたちの迷いと決断）と題し、経営者たちが経験したさまざまな壁、困難、そして試練に迫ります。
Notionナシでは生きられない！そんなNotionを愛する人々、チームのケースをお届け。
