TL;DR
- GitLabにはValue Stream Analyticsという、各工程の作業にかかった時間を可視化する機能がある
- 作業の開始と終了の記録にはIssueへのLabelの付与＆剥がしを設定することができ、これにはIssue boardを有効に活用することができる
- これらの機能はプロセス全体のボトルネックを見つけることに役立てることができる
はじめに
私 @naoharu と @dada617 は2019年からPodcast「jamming.fm」を運営していて、その管理にGitLabを使っています。Podcastではなるべく旬なテーマを取り扱えるようにするため、Podcastで話したいネタを普段からGitLab Issueとして管理し、収録時はそのネタのストックの中からピックアップして録音するという運用を行なっています。
Issue boardの「話したいネタ」に日々思いついたネタを溜めて、収録の際には「本日のネタ」に移して収録していきます。収録が終わった後は「編集待ち」に移して、Podcastの音声リリースやWebサイトの更新が終わったらIssueをCloseに移して終了させます。
Podcast運営で感じた課題
しかし、実際にはPodcastで話せるネタができた（例: 新発売のガジェットを買った）としても、そこから次の収録に時間が空いてしまったり、収録したは良いけど、編集・リリースをする時間が忙しくてとれず、結局Podcastで扱う話題としての旬の時期を逃してしまうことが多々ありました。
課題に対するソリューション仮説
そこで、せっかくネタのストックからリリースまでをGitLabで管理しているので、GitLabのValue Stream Analyticsを使ってプロセス内の各工程にかかっている時間を計測・可視化・改善できる点を見つけ、よりタイムリーなPodcast運営ができないかを検討することにしました。
計測のために必要な作業
プロセス内の各工程を（「ステージ」と言います）にかかっている時間を計測するためには、GitLabで事前に定義されたステージを使うか、カスタムのステージを定義して使用するかを選ぶ必要があります。
GitLabで事前に定義されたステージを使用する場合
GitLabで事前に定義されたステージには例として下記などがあります。
| ステージ名 | 測定方法 |
|---|---|
| Issue | Issueが作成されてからラベルが付与されるかマイルストーンに登録されるまでの時間 |
| Plan | Issueステージが終わってから、最初のコミットがされるまでの時間 |
| Code | Planステージが終わってから、Merge Requestが設定されるまでの時間 |
| など | ・・・ |
より厳密な定義は公式サイトをご確認ください。
独自に作業フローを定義する場合
自分たちのPodcast運営の作業フローは上記のデフォルト設定とは異なっていたため、自分たちで独自のステージを作成することにしました。
| ステージ名 | 測定方法 | Podcast運用上で該当する期間 |
|---|---|---|
| ネタ出し | 「話したいネタ」ラベルが付与されて、外されるまでの時間 | 話すネタを思いついて登録してから、実際に次の収録で話すと決定されるまでの時間 |
| 収録待ち | 「本日のネタ」ラベルが付与されて、外されるまでの時間 | 次の収録で話す、と決定されてから、実際に話し終えて編集に入るまでの時間 |
| 編集待ち | 「編集待ち」ラベルが付与されて、外されるまでの時間 | 編集待ちに入ってから、実際に編集され、最終的にリリースされるまでの時間 |
このようにLabelの付与・外しなどのカスタマイズされたステージはGitLabのUI上で簡単に定義することができます。
結果
過去180日間を分析した結果、あるトピックが話したいネタとして候補に上がってから実際にそれがリリースされるまで3週間程度かかっていることがわかりました。また、3ステージで1週間程度かかっているといくことがわかりました。
これらのデータはすべて公開しているためGitLabのアカウントを持っていない方でも見ることができますので、興味があるかたはぜひ見てみていただければと思います。
（マンションの管理組合理事会役員をやった話、話したいネタに入れて200日経過してるし。一生話すことないなコレ。）
感想
Podcast運営者としての感想
やはり、3週間も経つと技術系カンファレンス話や、新たなガジェットみたいな話も、若干乗り遅れた感がありますよね。ここは「毎回リリースタイミングがちょっと乗り遅れてるなー」という肌感がきっちり可視化された感じがして、納得のデータが得られた感じがしました。
改善としては、今は週一回まとめて撮っているので、基本的に1週間くらい世間のニュースから遅延するのは仕方ないなと思うのと、一方で、収録して音声データもあるのにそこから1週間のリリースまでのリードタイムがかかっているのは、単純にサボっているか、いまいち腰が重い状態で着手できていない可能性があるので、そこはうまくショウノートをAI文字起こしで省力化するとか、作業の自動化などで改善ができそうです。
Value Stream Analytics機能への感想
今回の「話したいトピックを思いついてから、それを収録し、世にリリースしていくまでの改善」に利用しましたが、これはいわゆるソフトウェア開発でのDevOpsの「ソフトウェア開発の企画から開発、リリースしてフィードバックを集め、次の企画に繋げていく」といった流れに類似しており、実際の開発の現場の可視化・改善にも役立てることができると思いました。
一方で、GitLabが事前に定義しているステージがそのままマッチして開発のワークフローに適用できるかどうかは組織に依存し、多くの場合はカスタムのステージ（Labelの付与など）を活用してく必要があるのではないかと思いました。
その場合には、Scoped LabelとIssue boardを活用して、Issueをボード上のレーンを動かすとScoped Labelが貼り変わる機能を活用することで、うまく実際の現場の状況をデータ取得に利用できると思いました。