（この記事は約5分で読めます）

こんにちは、スタディサプリ TPM（Technical Product Manager）の@risa-hayashi です。

振り返りにGitHub Projects(beta)のInsightsという機能を利用してみたところ、振り返りが効果的にできるようになったのでその運用方法や効果を紹介したいと思います！

GitHub Projects(beta) Insightsとは？

とてもざっくり言うと、任意のGitHub Project(beta)に載せられたissueから、このようなチャートを作れる機能です。

しかもこのチャートの見た目（グラフの種類やX/Y軸の基準）は適宜カスタムすることができます。便利！

私の所属しているスタディサプリ合格特訓コース、個別指導コースの開発チームでは、この機能を利用して数ヶ月前から振り返りの運用を行っています。

なぜInsightsを使うようになったのか

スクラム開発を採用している弊チームでは、毎週のsprint retrospectiveに加え、毎月「月イチ振り返り」というセレモニーを実施しています。Insightsは後者のセレモニーで利用しており、「プロジェクトの進捗状況」や「各プロジェクトに適切な工数を割けているか」をチェックする目的で使っています。

元々私たちはタスク管理にGitHub Project(beta)のカンバンを愛用しており、タスク管理と振り返りをひとつのツールで完結できると便利なのでは？と考えInsightsの利用を始めました。

また、スタディサプリでは技術的な負債を可能な限り溜めない仕組みを作ろうという目的から、「新規/エンハンス案件」にかける開発工数と「負債解消」にかける開発工数のバランスをとる試みを行っています。

そのため、複数のプロジェクト（例えば「新規プロダクト立ち上げ」と「XX機能の大規模リファクタリング」等）にかけた工数を横断して比較する必要がありました。それを可能としたのがこのInsightsという機能でした。

Insightsを使った振り返りの方法

さて、本題です！弊チームでは、以下のようにInsightsを使って振り返りをしています。

ストーリーポイントをつける
issueをカテゴリ分けする
Insightsでチャートを生成する
チャートを見て議論する＆ロードマップへ議論結果を反映させる

順番に、手順を紹介します。

1.ストーリーポイントをつける / 2.issueをカテゴリ分けする

まず始めに、issueにストーリーポイントと、ストーリーポイントを適切なカテゴリに分けて集計するためのラベルづけをしていきます。

例えば、弊チームではこんな感じでラベルづけをしています。

3.Insightsのチャートを生成する

次に「Insights」のページでチャートを生成します。チャートは1つのProjectから複数作ることができるので、私たちは用途に応じて以下の2つを生成しています。

プロジェクトの進捗具合を確認するためのバーンアップチャート
種別ごとにかけた工数を可視化した棒グラフ

ひとつめのバーンアップチャートはstacked areaというレイアウトを使って表現しています。こんな感じのチャートが生成できます。

issueは進捗具合によって都度ステータスを変える運用（開発着手したらin Progressとする、完了したらDoneとする、など）にしているので、時系列で「どのくらいのポイントが消化できたか」が可視化でき、ベロシティが把握できるようになっています。

ふたつめの棒グラフの方では、Columnというレイアウトを使い、1ヶ月分のグラフを生成しています。（左が5月、右が6月のグラフです）

この棒グラフを見ることで、案件ごとのストーリーポイントの合計を一発で把握できます。グラフを見ると「5月と比べて6月は新規に工数を大きく振っている」ことがわかります。

このように、ひとつのカンバンから目的に沿っていろいろな形式のチャートを生成できるのがInsightsの魅力です。「チャートが見たい形式で可視化できない…」とモヤることもないですし、ましてや情報をエクスポートし別ツールでグラフ化する…なんてこともしなくていいのが、とってもストレスフリー。

4.チャートを見て議論する＆ロードマップへ議論結果を反映させる

チャートが生成できたら、チーム内でワイワイと議論をします。基本的にフリースタイル（特にアジェンダは作らず、気になったところを適宜突っ込むスタイル）です。普段はSlack Huddlesで会話をしています。

セレモニーの議事メモです。1ヶ月間のベロシティや、前月と比べて目立つ変化について話し合っています。

TPMとして一番大切にしているのは、この議論の結果を「ロードマップへ反映する」ことです。例えば、

「リリース日までに間に合わない」と判明したらリリース日を変更できるかステークホルダーと調整する
「過剰に注力している案件がある」と判明したらロードマップ上の案件内容を変更する

といったことを行っています。この回では「7月ではなく8月に負債解消に注力しよう」といったことが話されたため、ロードマップ上でもスケジュールを変更しました。

分析はあくまでも適切なアクションを打つためのものなので、「話しっぱなし」にせず、開発チームと事業企画者の橋渡しができるようなアクションを打つことを心がけています。

おわりに

Insightsを使った振り返りを数ヶ月運用してみて、感じた効果は2つあります。

チームで議論することで、エンジニア/TPM双方が納得感のあるアクションを打つことができた
体感ではなく定量的なデータを元に会話することで、議論を深めることができた

これらはInsights以外のツールを使ってもできることですが、やはり「ひとつのカンバンから複数のチャートが生成できる」「チャートが自分達の目的に沿ってカスタマイズできる」のはInsightsの特色であり、特に「複数プロジェクトをバランスよく進めたい」といった方にはフィットするのではないかと思います。

一方で、InsightsにはZenHubのように「自動で理想の進捗スピードを提示してくれる」ような機能（詳しくはこちらの記事へ）はありません。チャートを見る都度、自分達で考察をする必要があります。

そのため、より厳密にプロジェクトの進捗管理をしたい方や、考察する時間も取れないので結果だけ欲しい…という方には向かないかもしれません。

ただ、個人的には、あえてチームで手間をかけて議論することでチームビルディングにもなると感じているので、Insightsのシンプルさは「いい感じの余白」と捉えています。