マニアックなSQLに続き2回目の登場、COOの achiku です。
これは
カンムでは GitHub Projects (Beta) を利用してプロダクト改善を推進している。Private Betaの時点から使い始めてから約4ヶ月、今の運用に落ち着いてから約2ヶ月程度経過したため、導入の目的、目的を鑑みた運用方法、現時点での状態をまとめる。誰かの参考になれば嬉しい。
※以降断りのない場合はGitHub ProjectsもしくはProjectsはGitHub Projects (Beta)を指す ※同様に以降断りのない場合はprはGitHub上のPull Requestを指す
前提(2022/03時点)
まずは前提の共有から。ぱっと見ても分かるように、小さくはないがとんでもないサイズでもない、という状況のチームの話であるという前提がある。
- 作っているもの
- 2016年ローンチ当時からGitHubを利用して開発している
- アプリと通信するVandle API、決済処理を担うProcessor、ネイティブアプリのリポジトリは別れている
- プロダクトのサイズ感が分かりそうな情報(as of 2022/03)
- バンドルカードチーム構成: 約15名
- ソフトウェアエンジニア(バックエンド/インフラ): 4
- ソフトウェアエンジニア(モバイル): 1.5
- データサイエンティスト/アナリスト: 2
- デザイナー: 2.5
- マーケター(広告運用含む): 3
- PM: 1
- 何でもやる人(achiku): 1
- (0.5=poolという新プロダクト兼務)
2021/06に Introducing new GitHub issue が公開された。その3ヶ月後の2021/09のThe new GitHub Issues – September 29th updateにて、Workflowsが導入された事が確認できた。これで複数リポジトリを跨いでソフトウェアエンジニアは通常通りissue/prを中心に仕事をしていれば進捗がProjects上に反映される基礎が整った。
導入の目的
Projects、なんとなく良さそうとはいえ目的を明確にしなければ情報の設計、運用の設計、チームの納得感の醸成を行うことは出来ない。サービスありきで導入したが結局使われないというのは悲しい。よってまずは以下2点に絞って導入の目的を明確化した。
1. 進捗の把握/報告という行動を撲滅する
- 普通に仕事をしていたら勝手に進捗が記録されて欲しい(or 最小限の手数で記録されて欲しい)
- 進捗を報告するのも確認するのも極力緊急事態発生時のみにし、普段は誰が見てもサクッと分かるようにすることでより生産的な仕事に時間を使いたい
- 誰がどの程度のボリュームの仕事に取り組んでおり、どのタイミングで次の大きめのタスクに取り組めそうか/今ちょっとお願い毎出来るのかを"全員"が確認する術を持ちたい
- 一人が優先順位とチームの稼働状況をリアルタイムに把握して差配する形式だと、チームメンバーが5人を超えたあたりから非効率の方が大きいと感じている
2. チームが自律的に改善に取り組めるような情報の通り道を作る
- 優先順位が明確になっており且つチームがその優先順位に納得感を持つことで自律的に動きを取りやすくする
- あくまでも情報の通り道なのでGitHub Projectsを導入するだけで自律的に改善が出来るわけではないが、"最新情報が常にメンテされ続けている場所"として活用可能と考える
- 優先順位によって事業インパクトが出る確率を上げる工夫、その優先順位が現時点で最善であるという思考プロセスの伝達の工夫は別途必要
- プロダクトが提供する価値の言語化、事業計画とプロダクトが提供する価値の中間表現、プロダクト会議体の設計、優先順位の明示とその背景ストーリー、学習した事とその共有、全てのあわせ技
優先度は1の方を高く設定した。仕組みで解決可能っぽいが人数が増えれば増えるほど全体としての無駄が大きくなる性質を持っているからだ。1と比較して2はかなり複雑で、あわせ技と継続的努力で改善していく類のもの。ただし、GitHub Projectsの中でもissue/prに優先順位を分かりやすく付ける事ができる為一旦目標の中に入れた。あわせ技である「プロダクトが提供する価値の言語化」「事業計画とプロダクトが提供する価値の中間表現」「事業計画の四半期計画策定プロセス改善」等も同時に進めていたので、それらの情報の通り道としての役割を担ってもらえないかなぁという期待があった。
導入前の実験
まずは優先度を高く設定した「進捗の把握/報告という行動を撲滅する」という目的を、GitHub Projects導入で解決できそうなのかを小さく実験することにした。vandleというProjectsを作成し、既存のissue/prをachikuが勝手にProjectsに登録しViewを作りながら動作確認していくという流れ。今各チームが沿っているフローの変更は最小限にして本当に目的が達成できるのかを見たかった。
余談だがProjectsをissue/prに紐付けるというのはよく出来た設計だなと思った。issue/prが適切に運用できているチームであればという前提はつくが、それぞれに対してメタデータを付与し一覧化/グループ化を試しながら小さく実践投入出来る。そしてそこまで大きなプロダクトでなければ1名GitHubに慣れた人が本気出せばいける(と思う)。ここで小さく価値を感じてもらえれば、まずは開発チーム内部での運用、ひいてはプロダクトチーム全体での運用につなげていける。そしてそれは開発者のみが参加するGitHubのシート数という市場を拡張することにつながる。実験が軽いのは本当に正義だし、市場をズラして拡大するのは大正義だなと思う。
この実験の中でやったことは以下。
Workflowsを設定する
いつもの仕事してたら勝手に進捗が記録されるようにする為には必要な設定。カンムではissue/prを中心として開発になっているのでこれらがclose/mergeされたら自動的にProjects側にも反映される。もちろん、issue/prに現れない仕事や大きなissue/prになると正確に記録し続ける事は難しい。限界はあるし、詳細にやろうとしすぎると効用が逓減していく類のものと認識しているので最初はおおらかな気持ちで良いんじゃないかと考えている。2022/03現在Default workflowsは "Code review approved" 以外全てEnabledにしている。
StatusとViewを作る
カンムではBoard/Priority/Milestone/Archived/NoPriorityの5つのViewを作っている。Status属性はToDo/Planning/In Progress/In Review/Done/Archivedの6つに増やした。ToDo/In Progress/Done/Archivedだけでスタートしたが、機能の検討も入れたいよね(=Planningの追加)、レビュー依頼まで終わってるものは分かりたいよね(=In Review)を追加している。が、最初はシンプルに始めるのが良いと思う。
BoardはStatus属性でGroup Byしているだけなので飛ばして、Priority/NoPriority/Milestone/ArchiveというViewの役割とどうやってフィルタしているかを以下で解説する。
Priority/NoPriority
まず以下のような形でザクッとPriorityを定義した。あまり言い回しにこだわらず、この段階ではなんとなくこんなもんかなくらいで良いと思う。後で精緻化すれば良い。
- Priorityの定義
- P0🔥
- ユーザー影響が出ている障害/影響が出かねない事案/セキュリティ関連の緊急対応はP0とする
- P1💨
- 四半期で定めた注力事項、事業計画上の必達事項、パートナーとの依存関係がありリリースの期限が存在はP1とする
- P2😗
- ユーザー/チーム/会社に取ってやった方が良い事は分かりきっているがP1ではないものはP2とする
- P3🌴
- 出来たらやりたいがそこまでインパクトなさそうなものはP3とする
- P0🔥
Priority ViewはTable View、Priority属性でGroup ByしPriority属性昇順でソートし -status:Done -status:Archived とフィルタをかけてDone/Archivedなものを除外する。こうすることで今Q抱えている注力項目(P1)は何か、P1がブロックされているのであれば手をつけれるP2は何か、という事を常時更新し続けられているリストを見ながら考える事が出来る。
NoPriority ViewはTable View、 no:priority とフィルタをかけてPriorityがついていないものを表示する。Group Byやソートは設定していない。暫定運用時はこのViewを定期的に確認し、登録されたissue/prの優先度を一旦achikuが判断することにしていた。このViewがあることで「一応Priorityの定義はあるが最初は難しい事を考えずにProjectsに放り込んでほしい！」というお願いが可能になる。
Milestone
以前はIssueのMilestoneを利用して複数リポジトリを跨いだリリース時期定義をしていたが、現在はProjects内で定義しリポジトリ跨いで付与できる属性であるIterationという概念を利用している。(The new GitHub Issues – October 14th update Milestoneでgroup byするのはまぁまぁ面倒だったのでこのリリースノートを読んで小躍りして喜んだ事を覚えている。)
現在のMilestone ViewはTable View、Iteration属性でGroup ByしPriority属性でソートし -status:Archived というフィルタをかけてArchivedなものを除外する。自分はこのViewを最も頻繁に見ている。既存の流れを踏襲して1 Iteration = 1 weekとして運用しており、金曜の段階で全てがクリアされていると爽快な気分になる。
Archive
Archive ViewはTable View、Iteration属性でGroup ByしIteration属性を降順でソートし status:Archived -no:iteration とフィルタを掛けてStatus属性がArchivedでIteration属性が付与されているものだけ表示する。もちろん登録しDoneまで遷移したissue/prをProjectsから外すこともできるが、過去の振り返りも行いたい為このViewを作っている。前週あるいは前Q単位で振り返るのにもこのArchive Viewは便利だと思う。
実験中のコミュニケーション
なるべくチームに負担を掛けないように、ただし「何やってんのか分からんな」とならない程度にやっている事を共有しつつフィードバックをもらい、「それ便利じゃん」となってもらえるように微調整していった。この辺はあまり言語化できることはなく、自分は今までの信頼貯金的な部分に助けられたと思う。各位自分のポジションを鑑みていい塩梅でよろしくやっていって欲しい。
実験中の学び
実験中は結構学び多かった。あまり客観的数値と共に示せるものがなく心苦しいが重要だなと思った学びをいくつか挙げる。各位割引ながら読んでほしい。
モメンタムが視えるッ！
毎週少しずつプロダクトが提供する価値が上がっていく、実験を通して分からない事が減っていく、というのを実感できる。また、チーム全体のスループットは大体これくらいなんだなというのが確認できる。それはかなり基礎的な事では？という指摘はそうなんだけど、一部の開発メンバーだけでなくプロダクトチーム全体が上記を認識できるようになったのは良かったと思う(Projectsを利用したプロダクト定例のあわせ技的な側面もあるが)。
P0/P1が分かるからP2/P3がやりやすい
実験していた時期は自分もバックエンドの開発に参加しており、優先順位が明確になっていると細かい改善もやりやすいと感じた。「このP1は一旦フロントエンド側待ちなのでこっちのサクッと片付きそうなP2/P3やるかな」や「休憩の仕事としてのP2/P3」みたいな動きがやりやすくなっている(※休憩の仕事は自分の造語なのでチーム内で特に使われているわけではないが雰囲気伝わるかな...)。
同時にArchive Viewを振り返りながら「今回のIterationがP1だけになってしまっているのでP2/P3もう少し入れれないか」「このIterationのP1/P2/P3割合はいい塩梅」「このIterationはP0結構入ってしまったので他あまり出来なかったな...」等、どういう優先度の割合でタスクに取り組んでいるのかを見返せるのは良いなと思う。
もちろん、P1をしっかりとプロダクトが提供する価値の増大に紐付ける為の事前調査や実験設計はとても重要。だが往々にしてP1仕事は不確実性が高く複雑で、1週間やったら即時結果が出る類のものではない。そういう難しい問題をチームで解くためにもフォーカスを保つことは、事前調査や実験設計と同様に重要。ただ、これは個人的な話ではあるが、少しでも、しかし確実に良くなる改善があるのであれば、時間を見つけてサッとやる、しかも品質も高い、それが腕前だろうという思いがある。「"要はバランスおじさん"をしない為に腕磨いとるんじゃこちとらよォォ」と、心の野山に住んでいる山賊が言っているのだ。今回実施した優先順位付けのProjects登録はこの心の野山に住まう山賊の性に合っており自分は気に入っている。
システム的な改善を四半期注力事項にどうやって入れていくか
これは実験の振り返りをしていく中でソフトウェアエンジニア側から上った指摘。実験時に策定したP1は、事業計画を四半期に割った際に目指すべき事業の結果とプロダクトがユーザーに提供する価値向上を合わせて決めていく方式を取った。この際、システム的な安定性/開発容易性は事業計画上に現れにくい為、あまり考慮出来ていなかった。が、しっかりと商売していく為にはBS/PL双方が重要であるように、プロダクトが提供し続ける価値とプロダクト内部のシステム的/オペレーション的品質にも目を配り、適切にメンテナンスし続けていく事は重要だ。この部分はまだ決定打と言えるような解決策は練れていないが、以前から四半期単位で運用しているOKR運用に載せ、そこでプロダクトマネージャー(achiku)とソフトウェアエンジニアチームの議論を経て決めた四半期注力項目をソフトウェアエンジニアチームのP1とする、という形を取っている(OKR、2019年から運用しているんだけどその話は別途)。
今のところObjectiveとKey Resultの形に落とす事でリファクタをするにもパフォーマンスチューニングをするにも監視強化するにも地に足のついた議論が出来るので、結構良い気はしている。
Qの最後に2週間ほど開発は手を止めて細かい改善を行うのは良いリズムを作るかもしれない
以前 Shape Up を読んだ際にソフトウェアエンジニアは6週間で作りその後の2週間で作る際に荒れてしまった部分、作っていたら見つけた改善可能なポイント、リファクタをやるという話があった。自分はShape Upの「アイディア/機能を考える人」と「作る人」を明確に分けるスタンスにはそこまで共感できていないのだけど、このサイクル自体は良いなと思っていた。最初から内部的な品質には固定割合の労力を割く事を決めておき、対応が後手になるのをルールでカバーするというか。また、deeeet氏と話した際に彼のチームでも6週間+2週間のサイクルで回していて調子良いと言っていたので、まずフロントエンドチームで実験。2週間で細かいライブラリの更新、やろうと思って積み残していたリファクタ、CI/リリースプロセスの改善、等を経てみて話を聞いたが好評だった。
もちろんプロダクトの内部品質で重要な部分はOKRに載せてP1として対応するんだけど、どうしてもそこに載せるまでもない細かい改善ポイントは残ってしまう。よって、こういう時間を固定で定義して早めに倒しておくのは費用対効果としても良いのかもしれないと今は考えている。この辺みんなどうやって運用しているのか知りたい。
まとめ
再度目的をまとめる。
- 進捗の把握/報告という行動を撲滅する
- チームが自律的に改善に取り組めるような情報の通り道を作る
「進捗の把握/報告という行動を撲滅する」はProjects導入し、チームに便利さを体感してもらい、運用方法を周知し、振り返りを行い、今後もこのフローを改善しながらやっていこうという流れは作れている。もちろんこれで完成というわけではなく、プロダクトチームがより一体となって提供する価値を向上させる為に改善していきたい。
「チームが自律的に改善に取り組めるような情報の通り道を作る」に関してはPriorityで進む方向の大枠を示し、Iterationでリズム良く改善をしていける形は整った。再度になるが、この目的の中でProjectsが貢献できる部分は比較的小さな一部であり、プロダクトが提供する価値をより大きくしていく為にはより包括的な活動が必要になる。その部分に関しての工夫や学びもいつか共有できるようにしたいと考えている。
カンムにおけるGitHub Projects (Beta)の導入方法、運用方法、1周回してみての学びを書いた。プロダクトやチームのサイズによるが、GitHubを利用してさえいれば上記のViewを作りとりあえず始められる。すでに利用しているチームがあれば是非どうやっているのか教えてほしいし議論したいと思っているので achiku まで気軽に話しかけて欲しい。Meety もあるので是非！
