リーガルテック・カンパニーMNTSQ（モンテスキュー）を創業して1年と9ヶ月が経ちました。

今日はMNTSQ（モンテスキュー）のプロダクト開発チームでは日々どんな流れで仕事が行われているのか、特にカンバン運営に焦点を当てて紹介しようと思います。

MNTSQのプロダクト開発の全体像としては、OCRやアルゴリズム開発やリーガルナレッジの再定義など様々なことをやっていますが、今回は特にユーザが触るソフトウェア面の開発（Rails + Vue.js + Elasticsearch）での運営を紹介します。

開発チーム構成

# こんな感じ
・PM & Designer & フロントエンドエンジニア: 1人（私）
・遊撃隊: 1人
・バックエンドエンジニア: 2名
・検索エンジニア: 1名
・週2~3業務委託エンジニアチーム: 4名

見ての通りまだまだ小さいチームです。

特に業務委託チームはフルリモートで別動的に動いてもらっているので、普段の開発は5人でオフィスやslackでコミュニケーションを取りながら進めています。

社員全員がGitHubを使います

MNTSQ社では、ソースコードやissue管理にGitHubを使っています。これはエンジニア系メンバーだけではなく、リーガル系メンバーもビジネス系メンバーも全員です。

ソフトウェアで世の中を便利にしていく会社として、みんながGitHubを使ってissueを管理し、publicな場でディスカッションしながら改善を積み重ねていくことを大事にしています。

いろんなrepositoryがありますが、プロダクトとしてはまだ1つの大きなrepositoryで運営しています。そのため、たくさん作られるissueを分類するためにラベルも使われています。

# 代表的なラベル例
1. design, rails, search, frontend, Legal, ML/OCRのようなドメインを表すラベル
2. ★, ★★, ★★★のようなPriorityを表すラベル
3. WIP, pendingのようなstatusを表すラベル

カンバン運営

GitHubのprojects機能を使ってカンバンを作っています。
issueはとてもたくさんあがっているので、プロダクト開発チームに関連のあるissueだけをprojectsに登録し、レーンを使ってステータスを可視化しています。

日本語の公式ドキュメントはこちら

我々のチームがどういうレーンを使っているかというと...

「Backlog」
新しいissueはとりあえずBacklogに入ります。
Priorityが高いと判断され、assigneeが決まったらレーンに移されます。

「ToDo」
assigneeが決まったissueはToDoレーンに入り、実際に着手するタイミングでWIPレーンに移っていきます。
ToDoレーンは定期的にPMが見直して、長期間手が付いていないissueについてはPriorityを引き上げるかBacklogに戻す等の対応が必要か検討します。

「WIP」
進行中のissueがWIPレーンに入ります。
Pull Requestが出たらReviewレーンに移っていきます。

「Review」
Pull Requestのレビュー中あるいはレビュー指摘事項への対応中がReviewレーンに入ります。
PMは必ずざっとレビューしたうえで、適切なReviewerをアサインしてエンジニア間でピアレビューのような形にしています（もう少し人数が増えてきたらReviewerが自動的に満遍なくアサインされる形に移行することも検討しています）。
Approveが付いてマージreadyになった場合、そのままマージしてissueがcloseされればDeployingに移ります。
API開発の場合は、API側の開発が完了したらそのブランチ上でFrontendの開発を足してしまうことも多いので、そういう場合はDesign/Frontend待ちレーンに移すこともあります。

「Design/Frontend待ち」
このレーンは本来は必要ないものなのですが、Designerやフロントエンジニアとしての私が実装の時間をタイムリーに取れないことがあるのと、PMを兼ねているのもあり私がassigneeのissueが多くてカンバンを汚してしまうため、カンバンを見やすくするために導入されたレーンです。

「Deploying」
解決が終わり、2週間に1回のDeployを待っているissueがDeployingレーンに入ります。
Deploy作業が終わったあとに、実際にDeployされたものはDoneレーンに移っていきます。

「Done」
Deployが終わったissueがDoneレーンに入っています。毎週行っている全体のMTGでDoneレーンのissueを眺めて残がないか認識合わせをしてからArchiveします。

日々のコミュニケーション

毎日15:00前後に、プロダクト開発チームで15分くらいの共有会（syncと呼んでいます）を行っています。

最初にMilestoneを踏まえた今の全体感をPMからシェアしたあと、各メンバーと今日の動き方や担当issueの進め方をすり合わせます。

# 大体こういう会話をしています
・Reviewレーンに来ているものの扱いを相談
・WIPレーンにある着手中のものの状況や完了見込みをシェア
・次に着手すべきものの順位付けをすりあわせ
・緊急の何かが見つかった時の状況シェア

sync以外の時間でも、1番効率的なコミュニケーションを各自が選択することを意識しており、issue上のコメントでやりとりをすれば十分か、話した方がいいかを各自が判断して、必要ならさっさと2~3分話す（quick callと呼んでいます）ことを推奨しています。

また、callや口頭で話した内容のうちissueに残すべきものや何らかの決定事項は必ず簡単にログを残すことを徹底しているので、各自が自律的かつ非同期に動きながら全体で統制が取れている状態を実現しています。

ちょっとした可視化

工夫というほどの工夫ではありませんが、情報共有を効率化する目的で、以下の2つを導入しています。

1. Activityログ
GitHub上のissueやPull Requestのステータス更新やコメントはslackに流れてくるようになっており、これを眺めておくだけでチーム全体の動きや「困ってそう」とかに気付くことができます。

2. レビュー通知
Pull Requestのレビュアーに自分がアサインされたときはslackに通知が来るようになっています（レビュータスクを放置している場合にはremind通知も来ます）。

最後に、カンバン運営のルール設計より大切なこと

こんな感じで、今回はMNTSQプロダクト開発チームのカンバン運営（レーン設計）と日々の仕事の流れを紹介しました！

こういった運営ルールやAutomationの設定とかは、凝ろうと思えばたくさん磨き込むことが出来るのですが、

正直に言えば、そこをがんばるよりも、各メンバーが事業やプロダクトのことを理解していて、仕様じゃなくて実現したいことベースでコミュニケーション取って仕事を進められる状態を実現する方が大事だと思うので、凝るのもほどほどに今後ともチーム作りを頑張っていきたいと思います。

興味を持ってくださった方は、是非プロダクト開発チームや事業そのものについて、お話を聞きに来てください！

こちらからカジュアル面談にエントリーできます