営業 / マーケ / エンジニアが混在する10名規模のチームのタスク管理方法（≒プロジェクトマネジメント方法）を公開します

この記事は、以下のようなジョブを抱えている人向けに書きます。
・チームの誰がどんな仕事をしているか（していたか）見たい
・メンバーの仕事の進捗把握を口頭コミュニケーション以外で解決したい
・チームの生産性を測りたい

どのようにジョブを満たしていったのか具体的に書きます。
・「スクラム」という手法を利用しました。
・具体的にどんなツールを使い、どのように実施したのか記載します。
・わかりやすさのため、表現が語弊を含む場合があります🙇‍♂️

一方で以下のようなことはこの記事では記載しません。
・スクラムという手法の詳細
・ツールについての具体的な説明

この記事をどう使ってもらいたいか
・ありたい状況から逆算した計画に基づいたタスク管理の実施
・気合と根性という手段以外で「やりきる」を達成する
　・時には目標のために頑張りどきがあるが気合と根性だけだと疲弊する
　・生産性を上げることにも着目するきっかけとして使ってもらいたい
・他職種とのスムーズな連携づくり

スクラムにおけるキーワード
・Issue：タスクと同義だと思ってください。
・Sprint：計画から振り返りまでの期間です。2週間で実施しています。
・Sprint Planning：初日に実施する2週間の着手Issueを決定する場です。
・デイリースクラム：朝会です。今日はどのIssueに着手するか発表します。
・Sprint Retrospective：最終日に実施する2週間の振り返りの場です。
・ベロシティ：1Sprintに消化したポイントの合計のことです。
・ポイント：Issueの大きさの基準です。

ポイントの参考として…ビジネスサイドは以下を指標としています。

では…具体的にどのようにスクラムを実施しているかご紹介します！
Sprintの期間を2週間とし、月曜日から次の週の金曜日、基本的には10営業日を1つの期間として捉えて、チームが動いています。

初日にはSprint Planningを行い、今Sprintで何を着手するか全員で確認してセットします。
日々朝会でどのIssueをこの日実施するかを宣言し、夕会で今日は何をやったかを話します。
ミッドタームレビューと称して、1週目の金曜日にはIssueがどれくらいClose出来たか確認します。残り半分でどれくらいのIssueが残っているのか、それは終了出来るのか、終了出来ない場合は誰かにパスをするのか、次Sprintに移行するのかを判断します。
最終日にはSprint Retrospectiveを実施します。それぞれのSprintでのIssue完了状況の共有、チーム全体のベロシティ確認、KPTを実施します。

このスクラムを実行するために、僕たちはZenhubというGitHub Issueをチケットとしてカンバン方式で進捗を管理できるプロジェクト管理ツールを利用しています。

なぜこれかというと以下4点です。
・エンジニア・デザイナーがGithubとZenhubを使っていたから
・ビジネスサイドも同じツールを使えば業務がスムーズになると思ったから
・ビジネスサイドでも問題なく扱えるツールだったから
・ベロシティが測定できるから

Sprintの期間や始まりと終わりのタイミングもビジネス・エンジニア・デザイナーと全て統一しているので、次のSprintに対応してもらいたいIssueがあれば、次のSprintが始まる前にIssueを作成して渡したり、事前に打ち合わせをしておきます。
つまり、プロダクトにまつわることは全てこのカンバンに記載されています。

全員のIssueがこのカンバンにあります。逆を言えば、このカンバンにないことは誰もやらない、とも言えます。

カンバンには以下のフェーズがあります。
・Backlog：Sprintで取り組む予定だが、未着手のIssue
・In Progress：着手中のIssue
・Review/QA：レビュー依頼しているIssue
・Waiting Release：レビューは完了していて、リリース前のIssue
・Closed：完了 / リリースしたIssue

それぞれのIssueがどんな状況かが一目瞭然です。
例えばIn ProgressのIssueをクリックすると…

Issueの中にはスレッドが存在しており、Issueのオーナーがここで進捗を記載したり、このIssueに関するやりとりをメンバーと実施しています。

この「カンバンとフェーズ運用」・「Issueのスレッドに進捗を書く」ことで以下のジョブを満たすことができます。
・それぞれの仕事の進捗把握を口頭コミュニケーション以外で解決したい

「今あのIssueってどういう状況だろう？In Progressにあるな、詳細をスレッドで見てみよう」
みたいな感じで、このカンバンを活用出来ます。タスク進捗共有会、みたいなMTGをしなくてもOKです。

もちろん以下のように、Issueの担当者やSprintの期間で絞り込みも可能です。

これにより、以下のジョブを満たすことができます。
・誰が今どんな仕事をしているか、過去どんな仕事をしていたか見たい

Sprint Planningの際に、それぞれがどれくらいのPointを持つかもきちんと確認します。また、そのPointが妥当かどうかを確認すべく、10営業日＝80時間＝30ptをMAXとし、MTG等を除いた稼働可能時間（率）を算出し、上限Pointを決定します。そのPointに基づいてそれに合わせたIssueを持ちます（もちろん優先度の高さが最優先です）。

Issue作成時のUIはこちらです。

Issueのタイトルを決定するだけでなく、Issueに対しての詳細を記載します。

## What
<!-- どんな状況でどんなアクションを取るのかを書く -->
### Goals
<!-- 何を達成したらこのissueはcloseできるのかを書く -->
### Non-Goals
<!-- このissueではやらないことを書く -->
## Why
<!-- なぜこれをするのかを書く -->
## References
<!-- 関連する issue、発端となった Slack メッセージ、議論の参考になるページなどの URL を貼る -->

これが重要で「このIssueってなんでやってるんだっけ？」「どこまでやれば完了？」みたいな迷いや混乱をなくすべく、Issue作成時にきちんとセットします。

Issueの絞り込みも想定して、ラベルをつけたり

誰がこのIssueを担当するか、作成者じゃない人をアサインすることも可能です。

このIssueのPointもIssueの詳細を見て、想像してつけます（プランニングポーカーという、関係者でIssueのPointを見積もる方法もありますが、ビジネスサイドは自分たちでつけてしまっています）。

Milestone（Sprint）も実施する期間を指定すれば…

Issueの完成です！

最後にベロシティについて。
Zenhubの機能に「Velocity tracking」があります。以下のようにSprintで消化したIssueのPointをSprintごとに見ることができます。

さらには、Sprint中に日々どんなペースでPointを消化したかが見れる「Burndown report」という機能もあります。

ラベルで調べれば、職種ごとにも見れますし、土日を除いた理想的なBurn down chartが点線で書かれているので、日々朝会で確認しています。
（チーム全体で見るとなかなかこれ通りにいかないですが…エンジニアはこれ通りに進めていてすごいなと思います。）

この機能によって、以下のジョブを満たすことができます。
・チームの生産性を測りたい

なんでもかんでも「いつまでにこれよろしくね！」とつい頼んでしまったり、それを受けた人が「最近忙しいし、あれもこれもやらなきゃいけないけど、頼まれたからにはやらなきゃ…」と考えて気合でやりきる、みたいなシーンは良くあるんじゃないでしょうか。

それが、このスクラムを始めてから以下のような会話になりました。
A：「いつまでにこれをお願いしたいんだけど、対応出来る？Pointとしては2Pointと見積もってるんだよね。」
B：「なるほど、このSprintは20Point分のIssueが対応出来て、現在Point分ぱんぱんにIssueが入っているんですが、Issueを入れ替えるか、2週間のうち4時間の残業をすればその期日には間に合います」
A：「であれば、何かIssueを入れ替えようか。入れ替えたIssueは次のSprintに回そう。一緒にZenhub見よう。」

他にも紹介したいこと
・IssueをまとめたEpic活用の話
・PlanningやRetrospectiveのフォーマットの話
・KPTやWLT（ Win / Learn / Try ）の運用
などなどいくつもあるのですが、長くなってしまうので、今回はこれくらいにします！

この記事がプロジェクトマネジメントの課題解決になれば嬉しいです。
スクラムはエンジニア界隈では有名です。僕は同じプロダクトを作っているエンジニアの教えを受け、夏まではビジネスサイドだけのチームでしたが、そこで運用し始めました。
今ではエンジニアとも同じチームとなり、毎Sprintごとに改善内容が出てきて、スクラムが進化しています。ありがとうございます。

そして、スムーズにこの手法に適用し、活用してくれているチームメンバーにも感謝します。手段にフォーカスしすぎることはよくありませんが、成果を出すために手段を疎かにせず、成果を出すための最適な手段を今後も求めていきたいと思います。