• 株式会社Gunosy
  • ニュースパス開発部 エンジニア
  • 大曽根 圭輔

リモートワークは敢えて取り入れない。Gunosyデータ分析部「情報共有」の仕組みとは

〜Jupyter Notebook・GitHub・Slackなど、様々なツールや手法を駆使して情報共有を行い、チームを強化している事例〜

チームを強くするには、「情報共有」が不可欠だ。情報を共有し、蓄積していくことで、メンバーは過去の成功例を模倣することができ、新しいメンバーのキャッチアップもスムーズになる。

1,400万DLを超えるニュースアプリ「グノシー」に加え、2016年にはKDDI株式会社と共同で「ニュースパス」の配信も開始した、株式会社Gunosy。

▼ニュースアプリ「グノシー」のトップページ

同社の中核に位置する「データ分析部」では、チャットツールの「Slack(スラック)」、リポジトリ管理サービスの「GitHub(ギットハブ)」に加え、データ分析の結果を蓄積できる「Jupyter Notebook(ジュピター・ノートブック)」なども活用して、情報の共有と蓄積を徹底している。

今回は、データ分析部と協調して業務を行う、ニュースパス開発部エンジニアの大曽根 圭輔さんに、同社での情報共有とコミュニケーションについて、幅広くお話を伺った。

「データ分析」がコアになる会社を探して、Gunosyに入社

僕は、大学の博士課程で、ゲームにおける人工知能の応用について研究していました。今になっては「人工知能」はバズワードなので、こう言うのは少し恥ずかしいのですが(笑)。

卒業後は、ソーシャルゲームを開発・運営する会社に入社し、エンジニアをしていました。その後、2012年くらいに、ソーシャルゲームの世界に「データ分析ブーム」がきまして。そこから、ログなどのデータ分析を始めました。

そのうち、ログを分析するだけでなく、分析自体がプロダクトに大きく影響するような会社で働きたいと思うようになりました。グノシーは、分析のアルゴリズムが重要な役割を占めますし、データドリブンな意思決定をしている印象があったので、2015年の11月に入社しました。

現在は主に、データ分析エンジニアとして、KDDI株式会社と共同で提供している「ニュースパス」に携わっています。

データ分析の情報共有は「Jupyter Notebook」で

今は、「グノシー」と「ニュースパス」の開発メンバーは席が離れているため、チーム間の情報共有には気を使っています。

グノシーの開発で蓄積されたナレッジを、ニュースパスに転用したり、逆に、ニュースパスの開発で得られたものを、グノシーにも使ってみたり。密に連携をしています。

データ分析の情報共有には、「Jupyter Notebook(ジュピター・ノートブック)」を活用しています。PythonやR言語で書いた分析のプログラムと、わかりやすく視覚化された実行結果を、ノートの形にまとめてくれるOSSです

▼「Jupyter Notebook」の画面イメージ

研究者が使うノートのように、試行錯誤の過程もすべて記録できるので、重宝していますね。Jupyter Notebookのリンクを共有して、データ分析結果の報告にも使っています。また、以前のノートブックを引っ張り出してきて、他の人の分析に対するアドバイスもできます

こうして情報を蓄積していくことで、後から入ったメンバーも、情報をキャッチアップしやすくなります

「GitHub」「Qiita:Team」などを組み合わせ、ナレッジを蓄積

データ分析関係のナレッジはJupyter Notebookに蓄積し、より広い範囲での情報共有には、「GitHub(ギットハブ)」の「Issues(イシュー)」と「Googleスプレッドシート」を使っています。

Issuesを日々のタスクにひもづけて、仮説・実行・検証のログを残していきます。そうしてナレッジをストックすることで、何かわからないことがあれば、GitHubのIssuesを検索することで、以前の試行錯誤の結果を確かめることができるんです

また、Issuesを「カンバン」の形で管理できる「ZenHub(ゼンハブ)」も利用しています。以前は「Trello(トレロ)」をよく使っていたのですが、やはりGitHubと連動していたほうがいいと思い、今ではZenHubを使っています。

他にも、エンジニアの情報共有には「Qiita:Team(キータチーム)」、コーポレートとのやりとりは「Yammer(ヤマー)」、日々のコミュニケーションには「Slack(スラック)」を使っています。自由にいろいろなツールを導入しているので、少々乱立気味ではありますね(笑)。

Slackの「分報」を利用し、情報共有を促進

チャットツールのSlackでは、「分報」を取り入れています。

メンバー全員が、「times_名前」という個人用のチャンネルを作ります。そしてそこに、メンバー全員が招待されます。

その自分のtimesチャンネルに、Twitterのように自分の状況をつぶやいていきます。「今日は◯◯をやる」「××のところで詰まっている」「△△には思ったより時間がかかった」といった内容ですね。

▼ 実際の「times_osone」の画像

こうすることで、誰が何をしているのか、メンバー全員がいつも把握できます。また、つぶやく方としても、他の人がすぐにアドバイスをくれるので、とても助かります。特に、部長は「常時オンライン」なので、レスポンスがとても速いですね(笑)。

「リモートワーク」は取り入れず、コミュニケーションを強化

コミュニケーションはオンラインだけでなく、オフラインでも活発です。弊社では、基本的にリモートワークは取り入れておらず、全員オフィスに出社するようにしています。

やはり、エンジニアでも、「どうやってユーザーを獲得したのか」「そのユーザーに使い続けてもらうためにはどうするか」という話をするなら、マーケティングの人と話す必要がありますよね。分析の話をするときも、「こういう結果になるよね」というグラフをホワイトボードに書くことが多いので、オフラインのコミュニケーションは重要です

また、社内の勉強会も盛んですね。エンジニアが知見を共有する勉強会や、ある書籍を1章ずつ、担当を分けて読んでいく「輪読会」、最新の国際会議の論文をみんなで読む会など、いろいろな会が開催されています。

「データドリブンであろう」とする姿勢を大切にしていく

入社して、「データドリブンであろう」という姿勢が凄いなと感じます。何かのデータを見るときの、突き詰めていこうという姿勢が大きいですね。

というのも、サービスを改善する人と、数値を見る人が一緒なので、適当な分析結果を出すだけじゃダメなんですよね

よくある話ですが、例えばコールセンターのKPIを「電話にどれだけ出たか」に設定すると、顧客と話している途中で電話を切るオペレーターが出てきてしまうんですね。そのKPIで自分の給料が決まるため、同じ行動をし続けて、結果的に利益が下がってしまう。

KPIを決めたら、単純にその数字を追うだけではダメなんです。「顧客満足度」という見えないものを考えて、「本当に重要なのは何なのか」というのを、常に考えるようにしたいですね。(了)

;