💬

生産性高くプロダクト開発に関与するためにトドケールで採用している Notion と GitHub の運用法について

2023/02/04に公開

GitHub

Notion

Todoker

tech

はじめに

こんにちは。@hayata-yamamotoです。

今回は、弊社で採用している Notion と GitHub を用いたイシュー管理方法について紹介しながら、その過程でどのような意思決定を行ってきたかを紹介したいと考えています。なお、弊社のプロダクト開発、特にプロジェクトカルチャーについては、note でも詳細に説明されています。合わせてご覧ください。

どんな風に課題を管理しているか？

弊社では重要な機能や改善についてはプロジェクトを組成し、プロジェクトチームで議論・検討を繰り返したのち、ユーザーに新しい体験を提供していくスタイルを取っています。このプロセスを効率的かつ効果的に実施していくため、Notion と GitHub を用いて課題の管理を行なっています。要点を整理すると以下のようになります。

ざっくりと可視化すると以下のようなイメージです。

どうしてこのような管理方法になったのか？

大きく３つのフェーズを経て、会社に関わるステークホルダーがなるべくプロダクト開発に関わりやすく、かつプロダクト開発に関わるエンジニアも開発の生産性を高く維持できる管理方法を模索し、今の形に落ち着きました。後述する、３つのステップを経て、現在は Notion と GitHub を併用しています。

エンジニアに寄りすぎた課題管理ツールを使うことによる痛み

弊社では、当初プロダクトの機能要望やストーリー、各種設計に関する記録を Atlassian 製品を用いて管理していました。主に、Jira, Bitbucket, Confluence を活用し、プロダクトの要件整理や仕様検討、プロダクト開発、リリースまでを全て総合的に行う形式でした。

その当時は、コードベースやチケット管理が既に Bitbucket や Jira で行われていたこともあり、ツールはなるべく統一的なものが良いという判断で Confluence をドキュメントツールとして採用し、プロダクト関連の議事録や一部ビジネスサイドの議事録を取っていました。

しかし、非エンジニアから見ると、特に Confluence はお世辞にも使いやすいとはいえず、使い方を学ぶところから始めなくてはならないメンバーもいたため、キャッチアップの負担が大きくなってしまい、結果としてなかなかドキュメントをまとめる文化が醸成されにくく、Confluence が十分に活用されていかない課題感を抱えていました。

それゆえに、Google ドキュメントなど、より手軽で使いやすく非エンジニアにも馴染みがあるツールの方に、顧客のヒアリングや重要なインサイトが記録されていく状況となり、次第に Confluence の存在感も薄れていくことになりました。

Notion で全ての情報を管理できる状態を目指して

Confluence が形骸化してきており、さらにエンジニアからも Bitbucket がどうも使いにくいと不満が噴出するようになった頃、Notion のスタートアップ向けクレジットポイントがあることを知りました。^[1] ちょうど、コードベースを GitHub に移行してしまおうと考えていたこともあり、Jira や Confluence を残すよりも別のドキュメント管理ツールやタスク管理ツールを導入する方が様々な面でチームの生産性が上がるだろうと予想しており、Notion は有力なツールであると考えていました。

クレジットの話を聞いた後、Notion の公式ページに紹介されている『チームの全アクションを把握できる、エンジニア向けプロジェクト管理システム』^[2] を読み、「これなら Notion で Jira と Confluence どちらの役割も担えるな」と感じ、Notion への移行を決めました。実は、Confluence から Notion への移行はめちゃくちゃ簡単で、データを Confluence から吐き出して Notion にインポートするだけで済みます。^[3]

その頃から既に Notion は、Google Drive のドキュメントや Figma ファイルの埋め込みなど、Jira でやれていたことは Notion でもほぼ全てできる状態にあり、開発用のドキュメントが適切に移行できさえすれば、大きな問題にはならない状況でした。サクサクと移行を進め、Atlassian 製品の利用をやめたのがこのタイミングでした。

ユースケースに応じて最適なツールを使いながら、Notion に情報を集約する管理方法に

Notion にドキュメントとタスク管理の役割を移した後に、何も問題が起きなかったわけではありません。最も顕著に出た課題感が、GitHub の状態と Notion の状態を同期させるのがめんどくさい というものでした。Notion で開発のタスク管理を行っていくと、GitHub の PR はクローズしたけど、Notion の方のステータスを変更し忘れる状況が多発していました。ある一定、仕方ないこととは思いつつ、Pull Request のテンプレートを用意したり、リリース前にリリース担当者が棚卸ししている状況でした。

さらにはイシューを分解したり、対応するタスクを細かく合意形成しながら進めようとすると、開発バックログが溢れ、結果としてエンジニア以外が見てもタスクがどのように進んでいるのか把握しにくい状況となっていました。アイテムが増えるに従って、スプリントを運用したり、開発の状況を把握するのが難しくなっていく実感がありました。

その頃、Notion が同期データベース^[4]のリリースを発表し、弊社も採用することに決めました。同期データベースは、GitHub の Issue や Pull Request の情報を Notion 側に自動で取り込んでくれる機能で、Issue や PR 上に Notion のリンクを貼っておくと、自動で関連付けしてくれるかなり便利な機能です。

Notion にアイテムを作成したら自動で GitHub に作成してくれる機能は現時点で提供されていないため、（よくあるパターンですが）make を活用して、所定の条件に当てはまるデータを GitHub 上に同期する工夫を入れています。

これにより、Notion で必要なユーザーストーリーまで定義が終われば、自動的に GitHub にユーザーストーリーの Issue が作成されるようになります。さらに、Notion のアイテムと紐づく、GitHub Issue の完了状態を追いかければ、「このストーリーが完了しているのかどうか？」を Notion 上から追いかけることができ、かつエンジニア間で共有されておくべき設計や仕様、具体的な開発タスクは全て GitHub を見ていれば把握できる状態になります

GitHub 上では、GitHub のプロジェクト機能を用いてアジリティ高く開発しやすい用に工夫しています。GitHub Projects のベストプラクティス^[5]に従いつつ、プロジェクトの性質に応じてカンバン＋マイルストーン形式で開発するのか、スプリントを設定してベロシティを計測しながら開発するのかを決定しています。

また、GitHub は標準で PR にリンクした Issue を閉じてくれる機能^[6]や Issue に記載したタスクリストから Issue を作成してくれる機能^[7] を持っており、それらを活用すると issue に PR を紐づけてマージするだけで、コードと Issue の状態をスムーズに同期できています。

終わりに

今回は、弊社で採用している Notion と GitHub を用いたイシュー管理方法について紹介しながら、その過程でどのような意思決定を行ってきたかを紹介しました。まだまだ改善点はあるのですが、紆余曲折を経ながら学びつつ進めてきたことで、チームの中で何が重要でどういう運用だとうまくいくのかが明確に見えてきています。

この記事や弊社に少しでもご興味持っていただけたら、是非カジュアル面談などにお越しください！

参考

脚注