GitHubを使った「カンバン方式」の実践ナレッジ(多数の副業メンバーが参画）

プロダクト開発の全体的な流れは以下の記事に書いてありますので、今回はGitHubを活用したカンバン方式の詳細を書いて行こうと思います。

アンチパターン社における非同期的なプロダクト開発のナレッジ(202107スナップショット)

また、開発メンバーの半数以上が副業です。優秀な方々であれば豊富な知識と思考を持っているため、短時間でも十分な成果を出せます。

重要なのはいかに、そういった方々が働きやすい仕組みを作るか、となります。

ちょうどスポットインスタンスをいかにうまく使うかと似ていると思っています。活用にコツがいりますが、扱えれば絶大なパフォーマンスを得ることができること等。

私はこのメタファーが好きで時たま使っています。

メンバー構成

副業: 7名
※週10h ~ 30hと働く時間はそれぞれバラバラで、固定の曜日も設けてません
フルタイム: 2名

こだわりたい点

GitHubをできる限り使う。（いろんなツールを使って、情報を発散させたくない）
毎週の稼働時間のコミットを求めない
だれがいつ稼働しても良い状態にする
自分のタスクの状態管理をできる限り意識させないようにする
それぞれのタスクの状態がカンバンでわかるようにする

準備

GitHubのプロジェクトとリポジトリの紐付け

GitHubはプロジェクトを作成すると、このようなカンバンを作ることができます。

開発には

dev-env
API
Front✕3

と計5つのリポジトリが使われています。

よってプロジェクトを１つ作りこのような形で対象のリポジトリを紐付けます。こうすると複数のリポジトリのISSUEの情報が１つのカンバンで見ることができるようになります。

カンバンレーン

今、どのISSUEがどのステータスかひと目で分かるように以下のレーンを使用しています。

TODO
Priority List
Priority List for API
Priority List for Front
In Progress
In Review
In STG
Done

当初 Priority Listは、APIとFrontを一つのレーンで管理していましたが、現在は3レーンに分けています。

APIかFront、どちらのISSUEか判断する必要がなくなったためメンバーからも好評でした。

ISSUE(タスク)の移動の自動化

開発者がカンバンのレーンを動かすのは Priority List for x → In Progressのみです。自分が作業をする際に、ISSUEに自身をアサインします。

他は全て自動化させます。そのためのルールがこちら

また、作成したプルリクエストにプロジェクトとISSUEを紐付けるようにします。

こんな感じで、プルリクテンプレートでプルリクテンプレートを作りこれらの紐付け作業を忘れない用にしています。

これで、カンバン上からISSUEに紐づくプルリクがひと目で分かるようになります。

こうすることにより

ISSUEをPriority Listに移動 (POがISSUEを作成したり移動したりすることが多い）
作業を開始するさいに、ISSUEをIn Progressに移動（開発者)
プルリクを作成すると自動的に In Reviewに移動
Reviewerがマージ自動的にIn STGに移動 (マージされるとGitHub Actionsによってい自動的にStaging環境にデプロイされる)
Stagingでビジネスサイドが確認＆本番環境へデプロイするとDone 移動(POが基本的に移動、またDoneにはいっているISSUEは毎週月曜日にアーカイブしてます)

という流れを作ることができ、半自動化もされています。開発者は 2 のISSUEを取る際のみ動かせば良いという状態が作れています。　

ルールや約束ごとではなく、自動化、仕組み化によって意識しなくても良い状態になっていることが重要です。

ISSUEのサイズ

タスクの見積もりには、Tシャツサイズ見積もりを採用しています。我々が使っているサイズは S,M,Lの3つのみでXLは採用していません。Lよりも大きいものをつけようとする場合は、そもそもISSUEの粒度がでかすぎるとして、もう少し細かくし、L以下になるようにします。

例：〇〇という機能を作る → 〇〇という機能を作るための設計をする。

また、S=2h 未満という時間で見積もってはおらず、SサイズのISSUEの例を出しており、それを基準に

M : Sの3~5倍
L : Sの6~10倍

としています。

時間で見積もると人によって開発時間は異なるで、作成者によってのサイズばらつきが大きくなってしまいます。

ISSUEは作成者がS,M,Lのいずれかのlabelを貼ります。着手する前に大体の規模感がわかります。

ISSUEのとり方の工夫

基本的にはPriority Listの名前通り上から順に取っていきますが。その際に状態が3つ有ります。

誰かがアサインされている
anyone ラベルがついている
上記2つではない

それぞれから見て一番優先的に取ってほしいISSUEは自分がアサインされているものです。着手する際は、自分以外のassigneesを外してIn Progressに移動します。(開発に加わったばかりのメンバーや特定のISSUE、知識に依存がある場合はこの方法が使われます）

anyone ラベルがついているものは、その名の通り誰でも着手可能な状態となっているISSUEです。空いているときに自由に着手できます。

上記2つに当てはまらないISSUEはAPIが開発されていないなど別要因で、まだ着手不可なものとなります。

ちなみに、自分のiconやラベルでカンバン上でワンクリックで絞り込めるのでとても便利です。

スプリントの紐付け(Milestone)

弊社では1週間のスプリントを採用しています。

In STGにあるISSUEを毎週決まった曜日に現スプリントの数値がはいったMilestoreを紐付けます。(PO)

こうすることで、毎スプリントでの消化ポイント(Sを1ポイントとした)を図ることができます。

細かい工夫

リリースまでに必要なISSUEの把握

緊急度が高いISSUE(主に、次のリリースには1〜3くらいのISSUE実装完了が必要な場合）がある際は、「次のリリースまでに必要」カードより上においておきます。

ISSUE分割

開発者は開発をしている最中や、取り掛かる前にそのISSUEをコンフリクトがおきない（他の人が同時に取り掛かっても問題ない）単位に自由に分割することができます。特にLサイズのラベルがあるISSUEは積極的に分割することを推奨しています。

プルリクを常に更新する

稼働終了時に常に、しかかりを常にプルリクとしてあげておきます。こうすることにより、途中で他の人に気軽にバトンタッチすることができます。こちらは多々起きる現象ではないですが、これによりMやLサイズのISSUEにも気軽に取り組むことができますし、平日働いて土日に休んでいる間に他の人がしかかりのISSUEを終わらせてくれたりします。