全社ワークスペースにGitHubを選んだROUTE06の開発生産性

2023年7月13日、ファインディ株式会社が主催するイベント「開発生産性Conference」が開催されました。本記事では、オンラインでも配信されたセッションのうち、株式会社ROUTE06のCTOを務める重岡正さんによるセッション「全社ワークスペースにGitHubを選んだROUTE06の開発生産性」の内容をお届けします。

ROUTE06が全社ワークスペースにGitHubを採用した理由をはじめ、GitHub採用後の成果や、採用から運用までの過程で遭遇した課題とその解決策などについてお話いただきました。

■プロフィール
重岡正（しげおかただし）/ @codenote_net　
株式会社ROUTE06 CTO
熊本大学大学院 CS 修士課程を卒業。WEBIMPACT, INC. でグルメ、不動産、ECなどの受託開発に従事。その後、Tokyo Otaku Mode Inc. の創業前期から参画、ソフトウェアエンジニアとして越境ECサービス開発などに従事、Engineering Manager を経て、ROUTE06を共同創業。2022年11月、CTOに就任。

全国に住む社員が、フルリモートワークで働くROUTE06
全社生産性を上げることが、開発生産性の向上に寄与する
ROUTE06が、GitHubの全社導入を決めた4つの理由
全社員が毎日アクセス、あらゆる職種でGitHubを活用
GitHub運用開始後の困りごとは、エンジニアがサポート
入社した初日から、実践入門的にGitHubに触れていく
さまざまな活用事例と、全社で使いこなすための工夫
プロダクト開発におけるGitHubの活用事例と工夫
全社員のさらなる活用のため、より充実したサポートを目指す
- アーカイブ動画も公開しております。併せてご覧ください。

全国に住む社員が、フルリモートワークで働くROUTE06

重岡：株式会社ROUTE06でCTOをしている、重岡正です。本日は、「全社ワークスペースにGitHubを選んだROUTE06の開発生産性」というタイトルで発表させていただきます。全社的にGitHubを使って、どのように開発生産性を上げているのかといった事例をご紹介しますので、何かしらの参考になれば幸いです。よろしくお願いいたします。

重岡：まずは改めて、自己紹介をさせていただきます。ROUTE06の取締役CTOで、会社の共同創業者でもある、重岡正と申します。ROUTE06の創業後、すぐに熊本にUターンしたので、普段は熊本からフルリモートワークしています。なので、本日は熊本からやってきました。

続いて、ROUTE06をまだご存知ない方も多いと思うので、簡単に会社紹介をさせてください。ROUTE06は2020年1月に創業し、今年で4年目。昨年6月に、シリーズAで15億円の資金調達をしています。事業としては、エンタープライズソフトウェアサービスと、プロフェッショナルサービスの2つを展開しています。

具体的には、ROUTE06が支援する企業様の複雑なビジネス課題を解決するため、自社でエンタープライズ向けのSaaSのプロダクト「Plain」を開発しています。この「Plain」の開発や提供と、大企業様向けの事業支援を行うプロフェッショナルサービスの2つを掛け合わせて、事業を行っています。

重岡：また、先ほど私が熊本からフルリモートワークをしているとお話しましたが、ROUTE06では全社フルリモートワークの働き方を採用しています。青森から沖縄まで、全国に従業員が住んでいて、首都圏外に約半数のメンバーが住んでいます。

オフィスは、情報管理やISMS取得などの兼ね合いから、WeWork丸の内北口に構えていますが、都内のメンバーも普段はフルリモートワークで働いています。現在の従業員数は50名で、このうち半数の25名ほどがソフトウェアエンジニア。プロダクトマネージャーやデザイナーまで含めると、組織の約70％がプロダクト開発に関わるメンバーです。

全社生産性を上げることが、開発生産性の向上に寄与する

重岡：ここからは、開発生産性の話に移りたいと思います。まずは、ROUTE06がどういった観点で開発生産性を向上させているかについて、『LeanとDevOpsの科学』の11章、変革型リーダーシップより引用させていただきました。下の写真の太字のところは、特に関連があると考えています。

重岡：全社ワークスペースにGitHubを採用することは、高い信頼性と生産性を実現するための文化規範を、会社の組織レベルからサポートすることにつながります。また、全社員の生産性が向上することで、めぐりめぐって開発のデプロイまでのリードタイムを短縮し、信頼性の高いインフラをサポートできると考えています。

そして、最も大きなメリットとして、全社ワークスペースをGitHubにすることで、部署を超えた取り組みによって、戦略的な協力関係を築くことができます。これがまさに今、社内で身をもっていいなと感じているところです。

なので今回、開発生産性というタイトルになってはいますが、全社生産性を上げることで、めぐりめぐって開発生産性に寄与する、ということをお伝えしたいと思っています。

重岡：そんななか、全社の生産性が上がりにくくなる、よくあるエピソードを4つ考えてきました。これは実際に、我々の社内にもあった課題です。

1つ目は、情報の断片化ですね。GitHub管理下のコードと、それ以外のドキュメントが別のツールに存在していると、情報が分断されてしまいます。2つ目は、更新の遅延。情報が断片化されていると、コードが更新されたりドキュメントが上がったりしたときに、連動してアップデートすべきものが後回しになり、情報が古いままになりがちです。

3つ目は、コミュニケーションの非効率性。GitHubも別のドキュメントツールも使っていると、どちらでやり取りすればいいのか迷ってしまうシチュエーションが多くなります。最後の4つ目は、ツールの学習コストです。異なるツールが混在していると、その分ツールの学習コストがかかってしまい、組織が大きくなればなるほど影響が出てきます。

ROUTE06が、GitHubの全社導入を決めた4つの理由

重岡：こうした前提のもと、全社ワークスペースにGitHubを選んだ背景や理由についてお話させていただきます。ROUTE06はフルリモートワーク組織で、エンタープライズ向けの複雑なビジネス課題を解決していくことを目指しています。そのため、創業当初からドキュメントの作成・共有・管理の情報設計を大事にしてきました。

創業当初の数名から20名くらいまでのころは、社内に流通しているドキュメントや情報は追いきれる量でした。しかし、組織が大きくなるにつれてどんどん難しくなり、情報設計を見直す必要が出てきたという背景があります。

創業当初は、プロダクト開発にGitHubやFigmaを使用し、それ以外の社内ドキュメントやタスク管理は、主にNotionで行っていました。なので、2年分くらいの業務情報が、Notionに蓄積している状況でした。

当時は、例えばプロダクトバックログでReadyになるタイミングでIssueが作られて、初めて知るようなことが多々ありました。レビューにおいても、GitHubのようにレビュープロセスが体系立てられておらず、変更の経緯や承認プロセスのところに難しさがあったりとか。Slack連携もかゆいところに手が届かず、変更検知のしづらさも感じていました。

重岡：そんななか、GitHubの全社導入を決めた理由が4つあります。1つ目は、業務プロセスとドキュメンテーションの連続性です。ドキュメント作成がGitHubに一本化されることで、設計と実装のプロセスより前から情報が入ってくるようになり、情報共有がすごくスムーズになりました。

ちょうどタイミング良く、GitHubのDiscussions機能がプライベートリポジトリでも利用できるようになったので、議事録やアイディアメモなどもGitHub内で作成し、共有しています。そうした情報がみんなに見えることで、議論されていることや考えていることが、プロダクト開発に入る前の段階から自然と共有されるようになりました。

また、プロダクト開発以外のコーポレート部門などでもGitHubを活用していれば、他の部門とコラボレーションするときもツールをまたぐことなく、すべてGitHubで完結できるという利便性もあります。

2つ目は、Slack等への接続性および視認性です。SlackとGitHubは、すでに活用されている会社さんが多いと思いますが、GitHubはSlack連携における通知の粒度や塩梅が良く、とても視認性が高い。Slackのなかで流し読みするだけでも、改めてやはりGitHubが長けているなと感じます。

重岡：3つ目は、バージョン管理と共同編集の利便性。これはROUTE06が、オープンソースソフトウェアの開発方法を組織運営に適用させていることが、大きな背景としてあります。ドキュメント類の管理や変更においても、レビューを経て更新され、プルリクエストベースで承認が行われています。

他のドキュメントツールでは、変更の経緯や過去の状態がわかりにくいことが多いですが、GitHubはそういった面で、BlameやHistoryを使えば把握しやすい。これによって、新たに入社した人にも、変更の経緯を含めた正確な情報を伝えられるというメリットがあります。

さらに、ROUTE06はエンタープライズ向けにビジネスをしているため、内部統制や監査などにおいて、変更の履歴がしっかり残っているということは、ガバナンス強化の観点からとてもメリットがあると感じています。

4点目は、システムの安定性およびセキュリティ水準。皆さんもご存知の通り、GitHubは2018年にMicrosoftグループに入り、エンタープライズ向けにサービスが強化されています。エンタープライズ向けにビジネスをしている我々としても、ドキュメントを委ねるにあたって、安心感があると感じて採用を決めました。

なお、現在ROUTE06ではGitHubを全社員が利用中で、プランは「GitHub Enterprise」。希望者に「GitHub Copilot」のライセンスを付与しています。「GitHub Copilot」はプロダクト開発だけでなく、ドキュメンテーションツールとしてもメリットが大きいと感じているので、希望者には全員ライセンスを付与しています。

全社員が毎日アクセス、あらゆる職種でGitHubを活用

重岡：続いて、GitHub採用後の成果についてご紹介します。まず、GitHubへのアクセス頻度は、全社員が毎日利用しているので100％。GitHubの利用年数については、プロダクト開発をしていて10年以上使っている人も多い一方で、ROUTE06に入って初めて利用した人も17%いました。そうした方々が感じた課題や、それを会社としてどう解決していったかについては、後ほどお話させていただきます。

重岡：下記のグラフは、昨年の会社全体のコントリビュート数です。グラフ左側のソフトウェアエンジニアや、プロダクト開発に関わるデザイナー、プロダクトマネージャーが利用していることはイメージしやすいと思いますが、特徴的なのはグラフの右側です。

コーポレートやHR、マーケティングといった職種の方も、遜色ないコントリビュート数になっています。後ほどくわしくご紹介しますが、こうした職種の方々も、GitHubのIssuesやProjectsをタスク管理として使いこなしていたり、GitHubをCMSとして利用して、コーポレートサイトの運用を行っていたりするので、結果としてこうした数字になっています。

重岡：また、採用後のワークフローの透明性とその効果について、実際に社員からのコメントとして「全社員がGitHubでドキュメンテーションすることになって、レビューが自然とプロセスに入り、コラボが生まれやすくなって、組織の情報流通が滑らかになった感がある」という声がありました。

GitHub運用開始後の困りごとは、エンジニアがサポート

重岡：とはいえ、良い話ばかりではありません。実際にGitHubを全社で使い始めて、運用までにどういった課題があり、それをどのように解決しているかについて、続けてお話したいと思います。

全社でGitHubを使い始めると、やはり初めて使う人にとっては、使い方や用語がよくわからないとか、突然エラーが出てきて困ったとか、そういった状態になっていました。なかでも、特に最初の課題になっていたのはプルリクエストです。

なので、社内のエンジニアが使い方についてオンライン勉強会を開催してくれて、今でも入社後にその録画を見て使い方を学べるようになっています。その後は、特にカリキュラムなどがあるわけではなく、実践入門を通じてスキルを習得できるようにしています。

重岡：また、プロダクト開発のチームとそれ以外の部門では、GitHubの使い方が全然違うため、まずチームでどう使っていくかの認識合わせをしながら使っています。それも一度決めたら終わりではなく、新しい取り組みがあるごとに、例えばどんな粒度でIssueを作成するかとか、そういった認識合わせをチームで行っています。

ただ、GitHubの使い方に慣れてきたとしても、その後何も問題がないわけではありません。そのため、困ったことがあれば、Slackの個人timesチャンネルに書くようにしていて、それにエンジニアが適宜回答しています。これによって、社内からは「困ったことがあっても、聞けば解決できる人がいて心強い」という声が挙がっています。

現状、組織として体系立てたマニュアルやオンボーディング、サポート体制ができているわけではないのですが、ワークアラウンド的に課題を解決しつつ、運用できているという状況です。

入社した初日から、実践入門的にGitHubに触れていく

重岡：次に、全社でのGitHub活用事例についてお話していきます。具体的な事例の前に、まずはドキュメンテーションツールとしてGitHubを使う際、CodeとDiscussionsとIssuesの3つの機能をどう使い分けているかを、下記の表に整理しました。

まずCodeでは、基本情報やガイドライン、ルール、規定など、変更のプロセスとしてレビューや承認を経てマージされるような、正確性が求められるストック情報を管理しています。Discussionsでは、先ほどもご紹介したように、メモや日報、ミーティングの議事録などを作成していて、複数人で共有したりコメントを付けたり、議論したりして活用しています。

Issuesは、よりタイムラインが短いものというイメージで、タスク管理のためのIssueを作って、プロジェクトで管理したりしています。頻繁に作成や更新が行われて、進捗管理されるフロー情報を扱っているという形ですね。

重岡：ここから、具体的な活用事例をご紹介します。まず、ROUTE06では入社初日のオンボーディングが、GitHubのIssuesから始まります。GitHubを使ったことがない人も、そこでチェックリストを埋めたり、コメントを書いたりして、実践入門的にGitHubに触れていきます。余談ですが、入社オンボーディングはIssue templateを活用していて、新しい人が入ったらすぐにオンボーディングできるように効率化されています。

そして、入社から数日以内に自己紹介ページを作り、社内のハンドブックにプルリクエストを作成します。これがプルリクエストの実践入門になっています。社内ハンドブックに利用している技術は、GitHub、GitHub Pages、Docusaurusの3つ。社内のメンバーだけがアクセスでき、自己紹介ページのほか、ナレッジやブログなどいろいろ書けるようになっています。

さまざまな活用事例と、全社で使いこなすための工夫

重岡：それから、先ほどご紹介した通り、議事録やアイディアメモにDiscussionsを活用しています。これについては少し開発的な工夫もしていて、毎週の定例などではGitHub Actionsでアジェンダを自動作成しています。それによって、ミーティングまでにアジェンダを埋めたり、もしくは事前にDiscussions上で議論して解決したりできるようにしました。

なお、DiscussionsはSlack連携できるのですが、まだ正規のインテグレーションでは、コメントへのリプライが通知されません。なので、そこだけ自作してSlackで通知するようにしています。ここさえクリアできれば最高だと思っているので、公式の対応も待ちたいと思っています。

さらに、もう1つの活用事例は、先ほど成果のところで触れた、会社のコーポレートサイトのCMSとしての活用です。このサイトではGitHubのほか、Cloudflare Pages、Next.jsといった技術を使っています。

掲載される記事やプレスリリースは、広報やマーケティングの担当者が、GitHubのブラウザ上からテキストをMarkdownファイルで書きます。そして、プルリクエストを出して、レビュープロセスを経てマージされたら、コーポレートサイトにデプロイされます。

一般的にCMSというと、WordPressなどをイメージされると思うのですが、CMS上でテキストのレビューをすることができません。ですが、GitHubではプルリクエストを作って、そこで内容を議論し、レビュープロセスを経てリリースできるので、体験としてすごく良いなと思っています。

加えて、ホスティングしているコードと掲載されているコンテンツが、同じリポジトリに溜まっています。このコーポレートサイトはフルスクラッチしているのですが、そういった点で、デベロッパーと記事の書き手とのコラボレーションも、やりやすくなっていると思います。

こういった形で、全社でしっかりとGitHubを使い始めると、デフォルトでは通知が来すぎて情報の洪水に溺れてしまい、必要な情報を受け取れないということが起きます。なので、社内のエンジニアがテックブログに、おすすめの通知設定をまとめてくれています。

例えば、不要な通知を受け取らない設定や、通知を処理するスピードを上げる方法について。それから、リアルタイムで見るべき重要な通知と、後で見ても問題ない通知を分ける設定などですね。これをしていないと、全社でGitHubを使っても活かしきれなくなってしまうので、重要なところかなと思います。

そのほかに活用しているのは、GitHub Projects。プロジェクト情報管理においては、役割によって見たい情報が違うので、見るべき人に見るべき情報を確実に届けることを重視しています。なので、Table、Board、Roadmapなどのレイアウトを活用し、見るべき人に合わせた情報の粒度になるよう、うまくコントロールしながら使っています。

GitHub Projectsに関しても、エンジニアが勉強会を開いてくれて、社内でテンプレートも用意しました。最初は、プロダクト開発での活用を想定していたのですが、それを見たマーケティングチームが「自分たちはこう使っていこう」と案を出したりと、社内で良い広がりが生まれています。

プロダクト開発におけるGitHubの活用事例と工夫

重岡：続いて、プロダクト開発においての活用事例も、一般的な内容を省いて、特徴的な工夫だけご紹介したいと思います。まずは、GitHub Actions経由でのオンボーディングIssueの作成です。

開発のオンボーディングでは、最初に見てほしいドキュメントや開発のセットアップなど、やるべきタスクがたくさんありますよね。それをIssue templateにしてもいいと思うのですが、Github Actionsを使うことで、トリガーしたらIssueがどんどん作成されて、オンボーディングに必要なものがすべて得られるようにしています。

また、全社でGitHubを導入しても、すべてがGitHubのみで完結するわけではなく、もちろんそれ以外の周辺ツールが必要な場面もあると思います。よくある例は、Excelやスプレッドシートなどの形式で、お客様に仕様書を共有する必要があるケース。この場合、プロダクトマネージャーが仕様書を更新したのに、エンジニアが把握しておらず、後に認識齟齬が起きてしまうことがあります。

それを防ぐために、変更された差分を定期的に検知して、プルリクエストを作成し、diffを確認してマージするようにしています。こういった形で、周辺ツールとも情報が同期できる仕組みを社内で整えています。

全社員のさらなる活用のため、より充実したサポートを目指す

重岡：それでは最後に、結論と今後のROUTE06のワークスペースについて、お話させていただきます。全社ワークスペースにGitHubを選定したことによる総合的な影響として、全社生産性、プロダクトチームの生産性、そして開発生産性の3つの観点から、お話したいと思います。

まず全社生産性の観点では、GitHubで情報を共有する文化が広まって、情報のアクセシビリティが大きく向上しました。情報にすぐキャッチアップできることで、とても生産性が高まったと感じます。

プロダクトチームの生産性としては、デザイナーやプロダクトマネージャーなど、プロダクト開発に関わる方々がGitHubを活用することで、コミュニケーションが円滑になり、プロダクト開発のスピードが上がったと感じています。

また、開発生産性としては、これまでいろんなツールで参照したり、はたまた直接聞きに行ったりしていた情報が、GitHubに溜まるようになったことで、情報を検索する時間がすごく短縮されました。結果的に、開発に専念できる時間が増加して、開発生産性が高まったと感じます。

重岡：今後の展望や改善策については、ROUTE06の全社員が十分にGitHubを使いこなしているかという点で、まだ伸びしろがあると思っています。直近も、やはりGitHubを使いこなすためのサポートが必要だということで、社内のエンジニアが有志で #help-github というSlackチャンネルを作って、そこでサポートしていこうという取り組みが出てきました。

我々エンジニアとしては、自分たちの開発生産性を上げるためにも、GitHubの体験を向上する社内サポートを、より充実させていかねばならないと思っています。以上、本日の発表が皆様の開発生産性向上に、何かしら貢献できたら幸いです。ありがとうございました。