TECHNOLOGY
- OTHERS

2023.07.21

2023.09.20

Notion × Github Projectsを活用したスクラムの取り組み事例 Vol.1

こんにちは、タロウです。

弊社で行っているプロジェクトの一つを、

Github Projects
Notion

を使用してスクラムで進めており、
スプリントを数回まわしてみたので、取り組みの紹介をします！

このブログで紹介すること

マーベリックスが行なっているスクラムチームについて
Github Projectsを使用した運営方法
Notionの活用方法

細かなルールやあるべき姿などは触れていませんので、
他社はこういう運用しているんだ〜のような視点でご覧いただければと思います。

Github Projectsの活用

コード、開発タスクはGithubで
ぐるなびさんのブログで紹介されていたGitFeatureFlowで運用しています。

PullReqestとissueを紐づけており、Merge後は自動で完成に移動します。

プロダクトバックログは全てIssueで管理しており、
全員が参加するスプリントプランニングで、スプリントバックログを決定しています。

カンバンボードで表現し、現時点でどのタスクがどの状態なのかを、メンバー誰もがわかる状態を常に維持しています。

リファインメントされたissueを、スプリントプランニングでプロダクトバックログからスプリントバックログへ移動し、それらのissueをスプリントで取り組む流れとなります。

ワンポイント

完了と完成

issueの終了後に移動する先は完成としています。
完了と完成は少し意味が違い、issueを終えた後の心持ちも変わってくると考えからあえて完成と表現しています。

「完成」は、完全に出来上がること、すっかり仕上げること、を意味します。
ものごとにおいて、完全に出来上がることを「完成」と言い、様々なものに対し用いることが可能です。

「完了」は、ものごとが完全に終ること、終えること、といった意味があります。

---
「完成」は、ものごとが出来上がった状態を意味し、「完了」は、作業などが完全に終了したことを意味します。
このように、完全に出来上がることが「完成」で、完全に終了することが「完了」といった違いとなります。

(参考)
https://meaning-difference.com/?p=32120

issueは終わったから終了、作ったあとは知りません。とならないように、
完成としてまだまだ改善の余地がでる可能性もあり、他人事とならない工夫をしています。

誰が作成しても同じ粒度となるissue

いざissueを着手しようとした時に、

何が問題か分かりずらい
人によって書き方、レベル感が違いすぎていて把握しにくい
書いた人に聞かないと詳細がわからない

そのような事象に出会した方多いかと思います。

該当プロジェクトにおいては、気がついたこと・修正や改善が必要なことは各々issueを作成しており、人による差異を極力出ないよう工夫をしています。
(※優先度は作成後に見直します。)

issueのテンプレートが3種類あり、内容により使い分けています。
不具合の場合用、機能追加用があり、それ以外は汎用的なテンプレートを使用します。

不具合用のテンプレートでは、

どこで
どんな
再現方法
発生時のキャプチャ
どうなっていれば正常か
ソース修正以外に気を付けるポイント
修正時に参考になるサイト

の情報を記入します。
これらの情報があれば聞かずともissueを読むだけで全容を把握することができます。

ワンポイント

書いてある内容を改めて聞くのは善か悪か

issueの内容だけで理解が難しい場合は、積極的に口頭・チャット・コメントなどで補足を受けるべきと考えています。話して解決することも大切な行動です。
※よく聞く15分悩んだら聞こう！など明確なルールは設けてませんが、足踏みするなら聞いて進めたほうが早いので、とにかくアクションを起こします。

ただ、お互いの時間は有限であり、お互いが都合の良いタイミングであることは稀なので、
極力issueに詳細を記載するなり、チャットで投げておくなり非同期に動きやすいよう雰囲気作りに力を入れています。

issueのテンプレート化

リポジトリのプロジェクト直下に.githubフォルダを作成し、その配下にテンプレートファイルを配置します。

[リポジトリ]/.github/ISSUE_TEMPLATE/-----.md

任意のmark downファイルを作成し、テンプレ化したい内容を記入します。
前述で紹介したissue例では下記のような内容になります。

---
name: 不具合報告
about: フロントエンドに関するバグなど
title: ''
labels: ''
assignees: ''

---

# 該当箇所


# どんな不具合？


# 不具合の再現方法


## キャプチャなどあれば


# 正しい動作方法


# ソースコード以外の修正要否(DB、env、DDB設定周りなど)


## 参考サイト

作成したテンプレートをPushすると、issue作成画面にテンプレート作成画面が表示されるようになるので、各メンバーはテンプレートに沿ったissueを作成するフローで運用することができます。

テンプレ内の項目は都度、より明確に、より意思疎通しやすく、しかし書きにくさが増えないように改善を繰り返していきます。

書きたくなるissueを目指す

課題整理やタスクなどテンプレート化されているプロジェクトを多く見てきましたが、
簡潔に分かりやすく、でも背景と詳細も把握できる内容で書こうと思える場面は多くなかったように感じます。

一次解析結果や根本原因、画像添付など四字熟語のように書かれていると、どうしても硬いイメージがあり、徐々に書くのがめんどくさい・・と思うことが多くなると思っています。(内心思ってしまう)

各項目を柔らかい表現で、内容によっては問いかけてあげるような文面で表現してあげると、
書き手のハードルを下げることに繋がると考えています。

issueを作成するのはベテラン〜新人、プロジェクト参画年数に関わらず誰でも書くことがあるため、ハードルを上げず書くことができる状態を目指しています。

Notionの活用

社内ではドキュメント管理にNotionを使用しています。

社内のリソースやノウハウ、インフォメーションも全てNotionを中心に管理することで、プロジェクトで必要な情報をまとめることに対して若干ハードルを下げることができます。

あの資料はこのツール・・この資料はあのツール・・などドキュメントが散在してしまうのを防ぎ、異なるプロジェクトでも運用ページ自体をテンプレート化することで、社内で行うどのプロジェクトにおいても、同じレベル感・同じ使用感を生み出すことができています。

全部で9つのブロックに分けており、

要件定義・設計
動作環境
運用ルール
Frontend
Backend
Design
リリースメモ
内部ミーティング
クライアント議事録

としています。
※プロジェクトによっては技術スタックのスコープが異なるケースがありますが、項目は状況に合わせてカスタマイズしています。

各項目について使い勝手を紹介します。

要件定義・設計

プロジェクト開始時や提案時にいただくことの多い、要求事項書や構想の資料などを添付します。
新規参画メンバー、他メンバーからみた時に仕様についての情報を集約しておきます。

動作環境

検証環境・本番商用環境の情報やアーキテクチャ、ローカル環境構築手順など動作環境に関わるすべての情報を集約しておきます。
アップデートが入った際も修正箇所が最小限で済むよう情報が重複しないページ構成で作成します。

運用ルール

新規参画メンバーが迷わずにルールを把握するために、デプロイやGit運用に関わるルールからSlackのチャンネルルールまで、プロジェクトで生活する上で必要なルールを集約しておきます。

Frontend / Backend

それぞれの環境に対する環境構築手順やコーディング規約、デザインパターンなどを記載します。
新規開発でコードを追加する場合に困らないようアーキテクチャにも触れた情報を載せ、後続フェーズの開発をスムーズにする工夫を行なっています。

Design

イラストレーターのaiファイルやFigmaのリンクを集約しています。
複数の開発フェーズで様々なデザイナーさんに参画していただいている場合、全て同じツールで作成されないこともあり、デザイン関連が散らばらないよう集約します。

リリースメモ

リリース作業を行う際の手順やリリースされる機能を記載します。

タイムスケジュール、リリース対象機能、データパッチ、環境変数の設定、リリース後のチェックリストまで、リリース当日はこのリリース予定を見ながら作業を行います。

また、過去のリリース作業についても全て一覧で残しているので、
問題が発生した時の原因究明もスムーズに行うことができる工夫をしています。

経験が浅いうちはリリースに触れることが少ない？

会社、プロジェクトや商流によって違いはありますが、なかなか若手のうちは“リリースは遠い存在”だと思いがちです。手順やリリース中の雰囲気、どうすれば安全に運用できるかを触れる機会は多いことに越したことはありません。

自分も若手の頃はリリースは上司がやるものと思い込んでいたので、どこかで他人事のように感じていました。

リリースに触れること、次のリリースでは何が使えるようになるのか、
自分が担当した機能以外も知る機会を増やすことで
運用の改善やもっとこういう機能があったらいいななどのアイデアを増やすことができると感じています。

ミーティング・クライアント議事録

クライアントミーティング、レトロスペクティブ・プランニングなどのイベントの議事録を都度残し、すぐに見ることができる運用を行っています。

Googleドキュメントやスプレットシートでの運用も行ったことがありますが、

ドライブ上に散らばってしまう
フォルダを追わないと辿り着くことができない
(=一瞬でどこにあるかが把握しにくい)
そして振り返ることのない資料となる・・

となることが多くありました。

案件のポータルサイトのようにNotionで管理することで、メンバー誰もがどこに何があるかを把握することができる状態を作り出すことができ、数ヶ月運用してみて新しく参画したメンバーも資料で迷うことが少なくなったと感じています。

さいごに

スクラムにてNotion、Githubを活用した例のご紹介でした。
Github ProjectsがNotionで取得できる状態であれば、バックログの管理もNotionのみで全て管理することができそうです。
(2023/07/20時点ではGithub Projectsの状態を取得はまだのようでした。)

安定したプロジェクト運営では、