• GMOペパボ株式会社
  • 執行役員 CTO
  • 栗林 健太郎

情報過多の状態を「スーパーリセット」?職種を超えたツール活用の弊害を解決する方法

今回のソリューション:【GitHub Enterprise/ギットハブ・エンタープライズ】

〜全社で「GitHub」や「Slack」を活用して、情報共有を進めつつも、その弊害としての情報過多を避けるために、ツールの利用を辞める「スーパーリセット」を実施した事例〜

レンタルサーバー「ロリポップ!」や国内最大のハンドメイドマーケット「minne」を始めとする、15ものサービスを展開している、GMOペパボ株式会社。

同社では、ソースコード管理サービス「GitHub Enterprise(ギットハブ・エンタープライズ)」やチャットツール「Slack(スラック)」を、エンジニアだけでなく、デザイナーや、バックオフィスなど、全スタッフが活用している。

社内で使用するツールを統一することで、コミュニケーションのコストは下がり、業務生産性の向上にも役立っているという。

しかし、そういったツールは便利な一方、あらゆる人が書き込むことで、情報過多になりやすいという弊害もある。そこで、同社では、活用しているツールやチャットのチャンネルを全社一斉に停止する、「スーパーリセット」を実施したそうだ。

今回は、CTOの栗林 健太郎さん、シニアデザイナーの佐藤 咲さんの2人に、エンジニアとデザイナーの「GitHub」活用、そして「スーパーリセット」に至るまでの考えをお聞きした。

「minne」のデザインプロセスにおけるGitHubの活用事例の記事はこちらです

15ものサービスを運営しながらも、横のつながりを意識する

佐藤 私は、新卒でGMOペパボ(以下、ペパボ)に、デザイナーとして入社しました。今は、「PEPABO WiMAX」や「ロリポップ!」のサービスデザインを担当しながら、シニアデザイナーとして、全社的なデザイナーの力を上げていくプロジェクトも担当しています。

栗林 私は、技術基盤整備エンジニアとしてペパボに入社し、今はCTOをしています。技術的な舵取りはもちろん、社内の生産性を上げるための技術的な課題に対しても、責任の範囲だと捉えて取り組んでいます。

弊社は15のサービスを運営しており(2016年8月現在)、それぞれのサービスが、いわばひとつの会社のような事業部制の組織体制になっています。

そういったサービスごとの組織体制は意思決定が早いというメリットがある一方で、他サービスとのコミュニケーションが取りづらくなるというデメリットもあります。しかし、やっぱり同じ会社なので、横のつながりは大事にしたいと思っています。

実際に、ストック型(情報蓄積)のコミュニケーションには「GitHub Enterprise」を、フロー型(リアルタイムの情報共有)には「Slack」を全社で使っています

そういったツールを導入するときは、基本的にチーム全員で使っていくようにしています。

エンジニアやデザイナー、カスタマーサポートの人たちも、「GitHub」上でIssue を立てて、その上でコミュニケーションを取っています。職種ごとに別の何かで管理するとなると、お互いコミュニケーションが取れなくなって、仕事が回らなくなりますからね。

デザイナーも活用を進める「GitHub」

佐藤 デザイナーも「GitHub」と「GitHub Enterprise」を使っているのですが、もともとエンジニア向けのツールなので、最初はどう使ったらいいのかわからなかったですし、「黒い画面」と言われているターミナルに、苦手意識がありました(笑)。

実際に「GitHub」を使ってみると、ソースコードの変更履歴がこんなに分かりやすく見えるんだと、驚きました。そこで便利さに気付き、Issueも使い始めました。

最初は、使い方に悩んでいたところもあったのですが、まずは「思いつきレベルのことを書いていいよ」と言われ、実際にIssueを立ててみました。

そこから、アイデアをIssue内で議論してクローズするという作業が、タスク管理に使えることに気付きました

例えば、カスタマーサポートの方から「このデザインお願いします」と言われたことをIssueに立てて、関係者である「デザイナー」のラベルを付けたり、実際の担当者にアサインして、という使い方をしていきました。

すると、Issueに対していろいろな人がコメントをくれるので、そのページ内で会話も完結するし、意思決定もできるということで、みんなが便利さに気がついてどんどん活用されるようになりました

エンジニアとデザイナーの「協業」にも効果的

佐藤 サービスにもよりますが、エンジニアとデザイナーの仕事が明確に分かれていないチームも多いです。私のサービスだと、デザイナー1人、エンジニア1人というチーム構成なので、フロント周りのコーディングも私が見ています。場合によっては、Rubyのコードを触るデザイナーもいます。

栗林 どのチームも、基本はスクラムをベースにして、カンバンを使って開発を進めています。朝会や夕会で吸収できない細かい内容を、「GitHub Enterprise」のIssue等のタスク管理ツールを使ってコミュニケーションしています。

エンジニアも仕様についてコメントしますし、デザイナーはプロトタイプの画像をどんどん載せて、意思疎通を図りながら作っていきます。

佐藤 デザイナーがJavaScriptを書いて、これで良いかなと思って載せても、エンジニアの突っ込みの細かさは凄いですね(笑)。

正しいことを言っているから受け入れようという気持ちの反面、嫌になってしまう場合もあるんです(笑)。そこはやっぱり、お互いに受け入れつつ、少しずつ譲歩し合うのが良いのかなと思います。

お互いに譲り合って、「どうしたら相手にわかってもらえるか」を考えながら進めていくことで、うまく回っています

運営しているサービスのすべてのコードが「GitHub」上にあるので、他のサービスのコードを参考にするために検索することもあります。コードを探して、実際にそれを書いた人に話を聞いてみることで、学びになっています

ツールよりも、まずは「企業文化」が重要

栗林 弊社では、「大切にしてほしい3つのこと」というものを掲げています。「みんなと仲良くすること」、「ファンを増やすこと」、「アウトプットすること」の3つです

「仲良くしましょう」と言っているだけでは仲良くしないのと同じで、まずは、コミュニケーションが取れる共通の場所を提供することが大事なんですね。つまり、「GitHub Enterprise」のようなツールも、ただ入れるだけではダメ。技術的・環境的にバックアップして、「あとはここに書けばいいから」という場を提供するのが大事です。

「アウトプットをすること」も同じで、たとえ思いつきのアイデア、意見、苦情でも、どんどん言える文化が必要です。

そういった企業文化がまずあって、それを現代的な方法で、よりレベルの高いアウトプットにできる方法を用意しているだけなんですね。お客様に良いものを届けるために、「僕らはこういう人でありたい」という理念があるので、それを達成するためにはこういうツールが良いよね、という観点で選んでいます。

情報過多になった社内を「スーパーリセット」!?

栗林 ツール導入は良いことだけではなく、弊害もあります。13年も会社が続いていると、どうしても情報過多になってしまうんです。

例えば、なんとなくノリで入った「Slack」のチャンネルや、そのときには必要だったメーリングリストとか、そういうものが放置されて増えていきます。たまたまある時期に流行っていたトピックのチャンネルに入ったあと、もう全然興味が無くなってるのに、まだ残っていたり(笑)。

興味が無くても、通知が来て「未読」になっていると、見ちゃうじゃないですか。そういうのが増えてきて、みんなで情報共有しましょうというのが良いところだったのに、弊害として情報過多になる。

そこで「断捨離」が必要だという話になり、「スーパーリセット」というプロジェクトを実施しました

「Slack」も社内SNSも日報も、全員であらゆるものをやめて、更地になったところに、「やっぱりここに家を建てた方がいいよね」「ここに橋架けたほうがいいよね」というのを、1つひとつ作り直していく方が、より生産性が上がるんじゃないかなと。

なので、情報共有の大切さを認識しつつ、1回ぽんっと全部やめてしまおうというプロジェクトを実施しました。

佐藤 それを聞いた時に、これで本当に業務が回るんだろうかと、不安にはなりましたね(笑)。ただ、私も「未読」がすごい気になるタイプだったので…。一旦全部抜けたことで「Slack」を見る時間も減りましたし、通知に気を取られる事もなくなりました

やっぱり思い切って全員で「捨てる」ということは、良いのではないかなと徐々に思ってきています。

「式年遷宮」を繰り返し、歴史を作っていく

栗林 社内SNSも日報も、代替案を作る前に止めてしまったので、今後、どうしていこうかなと思っていますが、次はこれが良いんじゃないかと考えている人はたぶんいるので、またその人が布教していくうちに全員に広がると考えています。自然に良い物が広まっていけば良いのかなと思います。

サービスの活用は、個人が勝手に止めたらいいというものではないと思っています。結局他の人が止めなければ、止められないんですね。個々人の判断にまかせるとデッドロックが起こってしまう。全員一気に止めないと、例えば自分だけいなくなったLINEのグループチャットで、何言われているか気になるじゃないですか(笑)。

エンジニアの間では「式年遷宮」などと言いますけど、定期的にものを作っては捨てて、捨てては作ってとしたほうが、結局良いよねと。そういうことを繰り返していくシステムが、それだけ歴史を作ると思っているので、今後も続けていければな、と思っています。(了)

「minne」のデザインプロセスにおけるGitHubの活用事例の記事はこちらです

;