見出し画像

GitHub ProjectがSREのタスク管理に適していた話

グロービス・デジタル・プラットフォーム

SREチームの沼田（@chroju）です。

GitHub ProjectsがGAしてから 、まもなく1年になろうとしています。Betaが外れてからしばらくは様子を見ていましたが、今年度に入って「そろそろ機が熟したのでは」と思い使い始めたところ、SREチームのタスク管理にとてもマッチしたので、そんな話を書きます。

SREチームの開発プロセス

いわゆる機能開発をしているチームではないので、「開発プロセス」と言っていいのかわかりませんが、便宜的にそう書きます。

グロービスの開発チームでは「スクラム」を採用しているチームが多いですが、SREチームではスクラムを導入していません。機能開発が中心的タスクになるとは限らず、また緊急対応や他チームからの依頼 = トイルも多いため、スプリントゴールを設けるなどのスクラムのプラクティスをそのまま活用するのが困難だと判断しているためです。

ただ、スクラムのエッセンスはいくらか取り入れています。イテレーションを重ねて定期的な振り返りを行ったり、ベロシティを計測したりすることは、SREにおいても有益だと捉えています。「ゆるいスプリントサイクル」のような形で、現在は以下のようなルールの下で仕事をしています。

  • 2週間のスプリントを設けて、プランニング、振り返り、デイリーイベント、リファインメントなどはチームに適した形で実施する

  • チケットのポイント見積は行う

    • チケットサイズが過度に大きくならないようにしてフロー効率を高める

    • プランニングポーカーを通じて、チケットに対する目線をメンバー間で揃える

    • ベロシティを計測し、そのなかでトイルの割合も観測する

  • 各種の「ゴール」は設けず、レビューも必ずしも実施しない

  • スクラムマスターも配置しない

RoadmapによるEOLや期限の管理

上記のプロセスで仕事を進めていたなかでの大きな課題として、期限管理がありました。

SREは自チームの計画以外で「期限」が発生することがよくあります。他チームからの依頼もそうですし、Kubernetesなどの社内共通基盤で利用しているソフトウェア、サービスのEOLやサポート終了もあります。しかし、チームとしての中期的なマイルストーンと、直近のスプリントばかりに目が向いていた結果、EOLに対してはかなり近づいてから対応をしてしまうなど、いわゆる「重要度は高いが緊急度が低い」タスクに向き合えていない課題意識がありました。

GitHub Projects導入の大きな理由の1つが、この期限管理の課題を解決するためでした。Projectsではカスタムフィールドを設けることができ、そのなかにDate型のフィールドを設けることができます。さらに、その値を元として Roadmap の形で表示する機能も2023年になって登場しました。これによって期限のあるタスクに、かなり向き合いやすくなりました。

Insightsを活用したトイル計測

先ほど記載した「トイルの計測」では、GitHub ProjectsのInsightsを活用しています。「Task Type」というフィールドを作成し、その種類ごとに、スプリントごとの完了ポイントを積み上げるグラフを作成しています。

なお、OKRに向き合えているかを確認するため、Task Typeには「OKR」というものも設けています。（諸事情でグラフが妙にガタガタですがご容赦ください）。

Insightsは非常に柔軟性が高く、カスタムフィールドを使って集計したり、積み上げ型のグラフを作ったりすることができます。運用作業とエンジニアリングのバランスを取り、開発効率を高めることが求められるSREにとって、いろんな角度からタスク状況を分析できるのは、非常に有用な機能です。現在は開発チームごとの依頼タスク数を計測するようなグラフを設けているぐらいですが、アイデア次第で他にも活用ができそうです。

チケットの棚卸しがしやすい

依頼があったり、自分たちの改善アイデアを起票していたりすると、それなりにチケットが溜まりがちです。他チームから「こうなるといいな」という優先度がそこまで高くはない要望が来たり、ということもあります。

GitHub Projectsはチケットを一覧化するViewを自由につくることができ、フィルタリングができるのはもちろん、カスタムフィールドを指定してグルーピングした表示も作ることが可能です。

例えば複数のissueをサブタスク的にまとめる「Track」ごとにグルーピングし、それぞれの進捗を一目でわかるようにもできます。また、一定期間更新のないチケットに「Stale」ラベルを自動で付与するような運用もありますが、Projectsのフィルタリングでは、"last-updated:<N>days" の形で、最終更新がN日前以前のものをピックアップすることも可能です。集計やチケットの整理目的だけに一時的にViewを作り、その後すぐに破棄する、という運用もよく行っています。

GitHub Projectsは程よい柔軟性と閲覧性を備えている

チームのタスク管理ツールは、好みが非常に分かれやすいところです。それなりにチーム文化に合わせられる柔軟性は欲しいですが、あまりに何でも出来ると学習コストが高すぎたり、メンバー間で使い方を巡った議論が発生しやすくなります。

この点、GitHub Projectsは「程よい」と捉えています。デフォルトの状態だとGitHub Issuesのあくまで延長上にあり、チケットごとのフィールド数も多くなく、シンプルに扱うことができます。それでいて柔軟性はそこそこ高く、自分なりのカスタムフィールドやViewが欲しければ、どんどん増やしていくことができます。また、開発者なら慣れている人が多いGitHub上でシームレスに扱えることも、様々なチームとのコラボレーションが発生するSREにとっては大事なことです。それでいて自分たちなりのカスタムを重ねられる、というのは、非常に良いバランスだと考えています。

We are hiring!

グロービスの開発組織では、一緒に働けるエンジニアを探しています！
まずは、カジュアル面談を通して、あなたに合う組織かどうか確かめてみませんか？
https://recruiting-tech-globis.wraptas.site/

この記事が気に入ったらサポートをしてみませんか？