• 株式会社ookami
  • CTO
  • 中村 文哉

継続的なプロダクト改善には情報共有が命 GitHubを全メンバーに浸透させた理由

今回のソリューション:【GitHub(ギットハブ)】

〜GitHubを社内ポータルのように活用し、プロダクト改善にとって最適な情報共有の体制を構築した事例〜

スタートアップなどで新しいプロダクトを開発する場合には、一度リリースしたものを市場の反応に合わせて変化させることが多い。そのためには「変化に強い」チームを作り、スピード感を持ってプロダクトを変えていくことが重要だ。

スマホでスポーツを楽しめるアプリ「Player!」を開発する株式会社ookamiでは、変化に強いチームを作るために、ビジネスサイド、エンジニア、デザイナー、全員が情報共有にバージョン管理ツール「GitHub(ギットハブ)」を使っている。本来エンジニアの開発フローに組み込まれているGitHubを全社に拡大するために、プロジェクト管理ツール「Zenhub」を活用したり、定期的に使い方の勉強会を開催するなど、さまざまな工夫を凝らしている。

開発責任者である中村 文哉さんが、なぜGitHubを全メンバーに導入しようと思ったのか。そしてそれをどのように浸透させていったのか。中村さんと、同社の創業メンバーである尾形 太陽さんに詳しくお話を聞いた。

継続的インテグレーションを導入し、「変化に強い」開発体制を作った同社のストーリーはこちら
仕様変更もポジティブになる?!大学生エンジニアがチームにCIを導入した理由

▼Githubの使い方についてはGithub入門の連載記事をご覧ください。

チーム開発を変える「GitHub」とは?導入方法・使い方を徹底解説!【第1回】【導入編】

スクラムで、スポーツをリアルタイムで観戦できるアプリを開発

尾形 ookamiではスマホでスポーツを楽しめる「Player!」というアプリを開発しています。開発体制はスクラムです。チームは、プロダクトオーナー1名、スクラムマスター、デザイナー1名、エンジニア2名+α、で構成されています。

スタートアップでのプロダクト開発は、変化を前提に考える

中村 僕は2011年からプログラミングをはじめ、独学でiOSやサーバーサイドの技術を学びました。その後は、オンラインも含め様々な人から刺激を受け、技術を身につけていきました。技術を学ぶ時は、見たり聞いたりしただけで分かった気にならず、自分で実行するように心がけています。
ookamiに入る前は、新規事業だけではなく、メンテナンス業務やコンサルティングなど幅広く開発に携わっていました。

そういった経験を通して、スタートアップのプロダクトは「1回作って終わり」ではなく、プロダクトを市場に出してみて反応を見ながら、ユーザーが求めるものを継続的に開拓していくことが重要だと痛感しました。これは、すでにリーンスタートアップとして広まっている考え方ですが。

ユーザーが求めるものを継続的に開拓していくためには、すべて「変化」を前提に考えなければなりません。つまりチーム自体が、変化に強くなければいけないと考えています。

変化をポジティブに捉えるための鍵は、情報共有にあり

中村 変化に強いチームを作るためには、情報共有が最も重要だと考えています。と言うのも、市場に合わせてどんどんプロダクトを変えていく時は、全員が同じ情報を持っていないと「なぜ変えるのか」「どう変えるのか」という部分でどうしても納得感が生まれづらくなるからです。できる限り、ビジネスサイドとデザイナー、そしてエンジニアが持っている情報を同じレベルにする努力が重要だと思います。

そこで、その状態を実現するために、各役割を持ったメンバーが使う情報共有ツールを統一することにしました。それぞれ使うツールが異なると、どうしても情報共有がなされず溝が生まれてしまうからです。そこで使うことにしたのは、バージョン管理ツールの「GitHub」でした。

ビジネスサイドも含め、全員がGitHubを使って情報共有

中村 現在はプロダクトオーナーを含めたビジネスサイドもデザイナーも、GitHubを使って情報共有をしています。GitHubを使おうと思ったのは、我々のプロダクトはソフトウェアなので、ソフトウェア開発を中心とした環境を構築したいという思いがあったからです。
エンジニアは開発で必ずGitHubを使いますし、シンプルなプロダクトなので、ビジネスサイドのメンバーでも使うことが可能だと考えました。

使い方としては、プロダクトへの意見などをGitHubのIssues(イシュー)にどんどんあげていきます。例えば、ビジネスサイドのメンバーがイベントでユーザーにもらった意見なども上がってきますね。ユーザーや外部の人の意見に触れるのはビジネスサイドが多いと思いますが、そこで得た情報を自分達で完結せず、エンジニアやデザイナーにもGitHub上でしっかりと共有しています。結果的に情報格差がなくなり、プロダクトをピボットする理由や方向性への納得感が増し、変化をポジティブに捉えられるようになりました。

ZenHubで優先順位を見える化 開発が無限に続く不安を払拭

中村 GitHubのIssuesは、ZenHubというプロジェクト管理サービスを活用して、カンバン方式で管理しています。

▼ZenhubでIssuesの進捗を管理(イメージ)

※実際の優先順位とは異なります。

プロダクトオーナーが定例ミーティングなどでIssuesに開発優先度をつけ、ZenHub上で整理して表示します。開発メンバーは積まれているイシューを上から順番につぶしていくことで「何を開発したら良いかわからない」「開発が無限に続くのではないか」といった不安を感じずにすみます。
「何を達成すればいいか」がチーム全体に共有され、納得感がある状態でプロダクト開発が進んでいくという方針です。

月一の社内勉強会で、GitHubの使い方をサポート

中村 GitHubは通常エンジニアが使うものなので、導入時には「Issuesってこうやって作るんですよ」といった感じで使い方をしっかり説明しました。

また、月一で社内勉強会を開催し、しっかり使いこなせるようにサポートをしています。Issuesの効率的な検索の方法や、引用の付け方といった便利な使い方をビジネスサイドやデザイナーに共有しています。

GitHubは検索がすごく充実していて、GitHub上で見られる項目はほとんど検索がかけられます。「作られた日時から検索」「コメント数◯個以上で検索」「誰がコメントしたかで検索」「誰が作ったかで検索」など、検索方法を知っていれば、欲しい情報へすぐにたどり着くことができます。

開発以外の情報もGitHubで共有

尾形 中村がGitHubを浸透させてくれたおかげで、今では社内のほとんどの情報をGitHubで管理しています。ミーティングの議事録、ファイナンス関連、採用状況、といった情報もあがっています。

最近では、ファイル、画像、PDFも共有出来るようになったのでGitHubに全部上げていますね。GitHubに上がっていないことを急に言い始めたら、そいつが怒られるっていう(笑)。今ではチーム全員が最重要ツールとしてGithubを使いこなしていて、社内ポータルのような存在になっています。

良いプロダクトを作るために習熟度の差もフォローする

中村 ツールの習熟度は人によって差が出てきます。例えば検索をする場合にも、自分だったら数秒で出てくるものが、人によっては一生かかっても出てこないんじゃないかっていうこともあります(笑)。

ただ、そこは定期的な勉強会で使えるようになるまでしっかりとフォローすることが重要です。「GitHubを使うこと」が目的ではなく、あくまでも「良いプロダクトを作る上で情報共有をすること」が目的なので、エンジニア目線でできることは何でもやっていきたいと思います。(了)

;