エピック型プロジェクト管理をGithubで行う方法 + 定例のテクニック
プロジェクトの成否やスピードはマネジメントによるところが大きいですが、その構成要素の一つにプロジェクト管理があります。
今回は、私たちがプロダクト開発の現場とデザインチームの現場で実践しているプロジェクト管理の手法をご紹介します。
JIRA式のプロジェクト管理を、JIRAほど複雑じゃないやり方で実現するというのが大まかな方針です。
また、開発、デザイン、マーケティングなど各部署のタスクを1つのプロダクト(Github)で管理する方針です。
JIRA式のプロジェクト管理
JIRAは言わずと知れた超多機能な統合的プロジェクト管理ツールです。
JIRAでのプロジェクト管理には1つ大きな特徴が存在します。それは「エピック」です(他にもたくさんの機能がありますが、今回は触れません)。
エピックはチケットよりも粒度の高い項目で、機能や改善項目の名前を付けて運用します。
そしてチケット(タスク)をエピックに紐づけることで、そのチケットが何のためのタスクなのか、口頭のコミュニケーションを介さず理解できるようになります。
また、エピック自体に優先順位を付けられることで、リリーススケジュールが自然と整理されます。
粒度の小さいタスクとプロジェクト全体の大きなリリース項目を相関する形で全員に見える形で管理できる優秀な様式と言えます。
しかしJIRAは非常に使いづらく余分な機能が多いため、近いことをGithubで実現し運用しています。明らかにすることは出来ませんが、導入現場では一定の効果を生んでいます。
Organizationを作る
ここからは、Githubでエピック型のプロジェクト管理を出来るようセッティングしていきます。
まずはOrganizationを作りチームであるという体裁を整えます。メニューからCreate Organizationを選び、必要な情報を入力すればOrganizationが作られます。
基本は職能ごとにレポジトリを作る
Organizationが出来たら、次はその中にレポジトリを作りましょう(エンジニアにとっては慣れた作業です)。
作るレポジトリは、開発ならFrontend（iOS等）・APIなどで分けるといいでしょう。プロダクトが増えればその分を増やすことになるので、最初は最小限に。
開発以外は1つのレポジトリで十分なことが多いと思います。
たとえばデザインなら「デザイン」1つ。マーケなら「マーケティング」1つ。といった具合です。
エピックをマイルストーンで表す
GithubにはJIRAで言うエピック機能はありません。その代わりに使うのがマイルストーン機能です。
優先順位はDue Dateで管理します。3ヶ月先くらいまでのエピックを作っておくとプロジェクトがスムーズに進む気がします。
エピックの内容は、リリースする機能やサイト、カイゼン概要などにしておくのがオススメです。
Projectsでレポジトリ横断のカンバンを作る
レポジトリを横断するOrganizationのProjects(カンバン)を作り、各レポジトリの全issueを必ずこのProjectsに紐づけます。
これだけで、そこだけ見ておけばエピックを除く全てを把握できる場所の出来上がりです。
この時、間違えてレポジトリ内のProjectsを使わないようにしましょう。
これはディレクトリ構造的に誤っているので理解しづらくなるためです(レポジトリ内のProjectsもOrganization内のProjectsも、どちらもissueから自由に紐付けることは出来ますが)。
また、レポジトリが増えた時に全体のカンバンがどれだったのか見失いやすくなってしまいます。
Slackに通知が来るようにしておく
Slackを導入している現場なら、GithubをSlackと連携させておきましょう。
下記のような時に通知を飛ばすことができ、Githubでのディスカッションを促進してくれます。
issueが作られた時
issueにコメントが付いた時
issueがCloseした時
プルリクエストが作られた時
プルリクエストがマージされた時
週1回30分の定例を行う
アジェンダを次の3つにすれば、5人いるチームで約30分のミーティングで済みます。
【追記】エピックとそのスケジュールを全員で確認する
今週リリースしたものをリリース済みに移す
作業中のissueの進捗共有
来週の定例までにやろうと思うものに各々アサインを付ける
注意点としては、最後のアサイン付けの際に全員がエピックのスケジュールを見ながら付けることです。そうでなければ、スケジュールに関係なく自分が無理なく出来る範囲でのissueを取る時間になってしまい、プロジェクト遅延の原因になります(経験談)。
後述しますが、エンジニアにアサインを強制しないのが基本ですので、その分メンバー全員が自分でスケジュールと自分の進めるissueを見比べて進めてもらうことが重要です。
なお、これ以外のものは日々のコミュニケーションの中で済ませておきます。
たとえば「新しいissueを作る」という作業は定例では行いません。自由なタイミングでissueは生成するのがおすすめです(もちろん関係者に共有しつつ)。
当該issueの関係者以外もいる定例で、issue作成や定例と定例の間に出来たissue情報の共有に時間を割く必要はありません。
最初はそれでもいいのですが、issueや人数が増える度に定例も延び、30分どころか1時間にも収まらなくなっていきます。
issueをリリース済みに移すのは、定例でのみ行う
issueをクローズもしくはリリース済みカラムに移すのは、作業が終わった時に1人で行うのではなく、定例でみんなが見ている場で行います。
何がリリースされたかを全員が把握できたり、難易度が高くなかなか進まなかったissueを片付けた際「お疲れさま！」と喜びを分かち合うことができます。
自分の仕事やアウトプットが注目されたり賞賛されることは心理的安全性を向上させるので、バカにできません。
リリース済み絡むに移し終えたら、次はWIPのissueの情報を共有し、最後にバックログの話に移っていきましょう。
バックログの中で次の定例までにやるものにだけアサインを付ける
issueを作るとついついアサインを付けたくなりますが、それは好ましくありません。
あらかじめアサインを付けることは予測できない未来に担当issueを預けることになるので、リソース配分の柔軟さを損ないます。
また、職能を少し超える機会(=メンバーの成長機会)を奪います。それは属人化と同義です。
つまり、「これは俺が得意だからやろうかな」「やってみたいからやろうかな」「アイツ大変そうだから手伝うか」といったことが起きず、総じて特定の部署や職能がボトルネック化しやすくなります。
この時外の人からは「あの人(部署)は仕事早いけど、この人(部署)は遅いな」となりますが、それは間違った認識です。
実際には、担当箇所にかかるコストに差があるだけというケースがほとんどです。(能力差の寄与度は低いということ)
バックログのissueを優先順位順に並べておく
宣言したissueをこなした後や作業に詰まったりブロックされた時、毎回「次何やればいいですか？」と聞かなければならない状態は望ましくありません。
バックログは必ず優先順位順に並べておき、メンバーが上からissueを取っていけばいいようにしておきましょう。
もし優先順位がエピックと同期しておらずちんぷんかんぷんな順番でissueがこなされてしまったとしたら、それはPMの責任です。
責任を負ってあげることで、メンバーは余計な心配をせず作業に集中できます。
あれもこれもやって、と頼まない
メンバーが自分でアサインを付けた以上に頼むのは避けましょう。心理的安全性を損ねます。心理的安全性を損ねた人間は、恐怖政治のケースを除きパフォーマンスを落とします。
心理的安全性を守るための基本は「強制しない」「賞賛する」「無能扱いしない」「心理的安全性を損ねるメンバーを排除する」「私生活や悩み・弱みを共有する」です。
ちなみに「心理的安全性を損ねるメンバー」とは、他人の悪口や陰口を言う人・渡された責任を明らかに果たしていない人などを指します。
まとめ
・ Organizeを作る
・ 基本、職能ごとにレポジトリを作る
・ エピックをマイルストーンで表す
・ Projectsでレポジトリ横断のカンバンを作る
・ Slackに通知が来るようにしておく
・ 週1回30分の定例を行う
・ issueをリリース済みに移すのは定例でのみ行う
・ 次の定例までにやるissueにだけアサインを付ける
・ バックログのissueを優先順位順に並べておく
・ あれもこれもやって、と頼まない
Q. Trelloでいいのでは？
Trelloではダメです。
何故なら、エピックを管理出来ません。
ラベルの使い方を工夫すればエピックとチケットを紐付けること自体は可能ですが、エピックの期限や優先順位を管理することができません。
基本的にはタスクしか管理出来ないため、メンバーは時折「この仕事は何のための仕事なのか」「何を優先してリリースすべきなのか」を見失ってしまいます。
Q. JIRAでいいのでは？
もちろんJIRAは大アリです。Bitbucketと併用すればJIRAの方が安くなるので合理的だと思います。1
ただ正直なところ、個人的にはおすすめしません。後述の2つの理由から、JIRAは使っていてテンションが下がります。
まず、その多機能さを使いこなすのがとても難しいインターフェースになっています。
複雑な統合アプリケーションですので、プロジェクト管理が目的であれば8割方の機能は使わずに終わるでしょう。インターフェースの悪さも相まって、すぐに使いたくなくなること請け合いです(本当に、信じられないほど複雑です。そしてその原因は「使わない機能」なのです)。
また、Atlassian製品は世界観がクローズドです。カッチリした「製品」という扱いのものが多い。
JIRAはアカウント単位がほぼプロジェクトですし、Bitbucketも個人で使っている人は少ないですよね(一方でGithubはオープンな世界観で、個々人がアカウントを持っています)。
これにはGithubの持つSNS的な(あるいはアイデンティティ的とも言える)魅力が理由として考えられますが、今回は割愛。
インターフェースや世界観よりも予算が優先されるのであれば、JIRA(とBitbucket)を検討すべきでしょう。