GitLabのプロダクト開発プロセス

2022-02-05

Untitled

プロダクトを開発する上で他の会社がどのように開発していて成功しているか、その成功をどのように自社の成功に結び付けれるか気になるところです。

今回は開発プロセスについてドキュメントが豊富にあるGitLabを取り上げGitLabのソフトウエアがどのように開発されているか概要を紹介します。

GitLabはDevOpsのプラットフォームです。ソフトウエア開発をしたことがあれば名前を聞いたり使ったことがあるかもしれません。GitLabと名前にgitがついていることからもわかる通り、ソースコードをgitでホスティングしておりそれに付随して開発にまつわる様々な問題を解決します。

GitLabは会社運営にまつわるほぼすべてのことをHandbookとして公開しています。そのページ数は2000ページ以上。ソフトウエアの開発プロセスはProduct Development Flowとしてまとまっています。

開発プロセス概要

https://about.gitlab.com/handbook/product-development-flow/#workflow-summary

開発プロセス概要は上記のようになっています。大きく以下の2つのパートにわかれています。

Validation Track: 解決しようとしている問題とその解法がProduct KPIsにいい影響を与えるか検証する
Build Track: Validation Trackで出した解法を開発しデプロイし結果を検証する

一連の流れをIssueを通じてコミュニケーションしています。Issueは解決したい問題(Title)と背景や解決方法(Description)が記載されています(その他にラベルなど多数の属性が追加できます)。開発プロセスの中でそれぞれのステップで検証したことを記載します。メンバがIssueにコメントして問題や解決方法に対して議論することもできます。

GitLabはこのIssueをSSOT(Single Source Of Truth)、ただ１つの正しい場所として扱っています。同じことが2つ別々に書いてあったり、このIssue以外のところにこのIssueについてのことの仕様などが書かれないようにしています。複数の場所に散らばっているとメンテナスが大変(実際はメンテされなくなる)だからです。GitLabはこのSSOTということと、ドキュメントにするということを非常に大切にしている会社です。

また開発プロセスは小さなバグなど問題を検証する場合がない場合は、適宜スキップしてもいいとかいてありました。実際上の効率を重視しているからです。

Validation Trackでは何をしているか

解くべき問題を定義し、その問題の解法として適切なものを選択し、優先順位をつけます。この問題と解法の理解のり具合によって以下のように分類できるとしています。

https://about.gitlab.com/handbook/product-development-flow/#validation-spectrum

各場合で、さまざまなUX Researchを行っているところが印象的です。UX Researchで使っているツールは知らなかったものもたくさんあり参考になります。

Validation Trackの各ステップの簡単な説明は以下です。

Validation backlog

PdM(Product Manager)が責任者となりバックログ(すべてのIssueのまとまり)を整理し優先度をつけます。優先順位をつけるためにRICE(Reach, Impact, Confidence, Effort)をつかっています。

Problem validation

PdMが責任者となり解こうとしている問題が正しい問題なのかを検証します。よくあるのは解法だけ先走って実装したが実は的はずれな問題を解決していたということがあります。それを防ぐために何が本当に問題なのかを検証するのです。PdMとUX Researcherが一緒になってOpportunity canvasなど様々な手法をつかって検証しています。

Design

解こうとしている問題が明らかになったらその解法を探ります。ここではProduct Designerが責任者となってUX、顧客価値、ビジネス価値、開発コストのバランスのいい解決策を模索します。

Solution validation

Product Designerが責任者となり実際にユーザなどにヒアリングやプロトタイプを使ってもらって本当に解法が問題を解決するのか検証します。

Build Trackでは何をしているか

Validation Trackでは問題と解法が定義されたので、開発する前にその問題がKPIを改善するであろうことがわかっています。開発チームはバックログ優先度にそって開発していきます。

一言でBuild Trackといっても以下のような様々な種類の開発するものがあります。開発するものによっては柔軟に後から説明するステップを飛ばすことができます。

MVCs (Minimum Viable Change): 価値を提供する最小のもの。無駄なものを作りすぎて時間を無駄にしないように価値を提供できているか確かめれる最小限のものをデプロイする
fixing detects: 不具合修正
patching security: セキュリティパッチ
vulnerabilities: 脆弱性対応
enhancing user experience: UXの改善
improving performance: パフォーマンスの改善

Build Trackの各ステップの簡単な説明は以下です。

Plan

Validation Trackの作業で、問題の定義と解決策が定義されているIssueができあがります。それに対して次の取り掛かるマイルストーンで達成できるMVCのIssueを整理して開発できるようにします。Issueに対するテストプランもこの時点で計画されます。

Develop & Test

ここでは実際に機能を実装してリリースする前にテストします。Issueは優先順位順に処理されます。そのIssueはDefinition of Doneが完了しない限りは次のフェーズにはいきません。つまり終わっているか終わっていないかの状態だけで中途半端な状態で次のフェーズにはいかないようになっています。

Launch

機能がリリースされたらPdMがリリース記事などを準備したり、自分達で機能を試したりします。

Improve

リリースされた機能がKPIにたいしていい影響を及ぼしているか検証します。

まとめ

この記事ではGitLabの開発プロセスをみてきました。ValidationとBuildという2つのフェーズにはっきりわかれており問題と解法をしっかり検証してからリリースしているところが特徴的でした。またそのプロセス自体もドキュメントに落としてありSSOT(Single Sourth of Truth)としてのドキュメントに強いこだわりをもっているのが伺えました。

あとがき1

Handbookを読んでいると共感できるところが多くあったのでそれを紹介します。

Issue descriptions shall always be maintained as the single source of truth.

Issue descriptions as the SSOTにありますが、Issue descriptionだけ読めばすべてを理解できるようにすべきだということですね。Issueにはコメントが書かれて議論されるわけですが、Description、コメントすべて読まないと理解できないというのは時間の無駄です。

Every part of GitLab has Key Performance Indicators (KPIs) linked to the company OKRs.

KPIsにこれでもかというほど多くのKPIがあります。各チームはOKRにそった計測可能なKPIを向上させることに力をそそいでいます。

あとがき2

Issueに対するラベルを使って多くのワークフローを区別したり自動化したりしていて参考になりました。ラベルもworkflow::planning breakdownのように階層を区切って使えるScoped labelsがGitLabでは使えました。