この記事は「株式会社ビットキー Advent Calendar 2022」の4日目の記事です。
今回は、Workspace&Experience事業部（以下W&E事業部）プロダクトデザイナーのmariko.satoが担当します！
これはなに？
ビットキーのデザインチームで実際に行っているタスク管理方法について紹介します。
これは主にスクラム開発チームで取り入れられている方法をもとにしています。
次のような方に参考になれば！と思っています。
課題
この管理方法を始める前の2020年ごろは、デザインチームでタスク管理をしていたものの、特に決まった運用はなく、個々で好き好きにタスクを作成していました。
当時、次のような課題がありました。
😨 誰が何をやっているかよく分からない
朝会で情報共有をしてタスクのタイトルだけ聞いて何となく把握するものの、実際何をやっているのか分かりませんでした。
タスクの実行はその人任せになっており、担当者から相談の声が上がらない限り適切な手助けができない状態でした。
😨 進捗が見えない
タスクは個人のセンスで切っているため、タスクが大きすぎる場合は「そのタスクの中で何をやっているのか」を把握する必要があり進捗が見えづらい状態でした。
進捗を把握するコストが高く、本人に状況を逐一聞かなければ実態が分かりませんでした。
😨 常にタスクが溢れている
週頭には現実的なタスク量を積んでいるつもりが、週を終えてみると完了したタスクが半分程度と「なんでわたしたちタスクが終わらないんだろう…？」と毎週疑問でした。
そのため、タスクの現実的な完了見込みが読めず「終わる..と思います！（終わらせます）」とパワーで解決しがちでした。
つまり、具体的に次のような問題がありそうです。
- チームで共通の方法で、タスクの分解ができていない
- チームで共通の方法で、タスクの大きさが見積もれていない
- チームのキャパシティが不明でどのくらいタスクが消化できるか分かっていない
こうしたい
このような課題を踏まえ、次のような状態にしたいと思っていました。
- タスクの分解を行うことで、チーム全員が誰が何をやっているのか把握し、相談・アドバイスをしやすい状態にする
- タスクが溢れていそうな人をキャッチでき、自発的にフォローできる状態にする
- 現実的なタスク量におさえ、安定してこなしていけるようにする
そこで、次のような対策を行い、タスク管理の方法を改善していきました。
（今回は深く触れません）
- タスクのテンプレートを導入し、タスクのゴールや前提などの必要事項をわざわざ説明しなくても把握できるようにした。
- ストーリーポイントやプランニングポーカーの仕組みを取り入れて、タスクの大きさの認識合わせを行なった。
- タスク管理で困ったポイントは、随時話し合い共通のルールを決めていった。
前提： 開発チーム体制
具体的な話に移る前に、わたしたちデザインチームが置かれている状況について前提をお話しします。
- ビットキーのプロダクト開発チームは、Home事業部、W&E事業部の2つに分かれています。デザイナーはこの事業部単位で配属されています。
- さらに、W&E事業部は5程度のプロダクト開発チームに分かれています。各開発チームは、2週間に1度のリリースサイクルでアジャイル開発を採用しています。
- 今回はW&E事業部のデザインチームの事例をお話しします。W&E事業部のデザイナーはそれぞれメインのプロダクト担当があるものの、それに捉われず互いにフォローしあうこともあります。また、一貫した「workhub」プロダクトの体験のために常に情報共有や相談が欠かせません。
管理方法
それでは、どのようにタスクを管理しているか？についてご紹介します。
これは2年程度運用していて少しずつ改善を重ねたものになります。
使用ツール
- ツールは 「Jira」 を使用しています。もともとプロダクトチーム全体でJiraを使用していたため、それに合わせました。
- Jiraのプロジェクトは開発チームとは別に立てています。
- 開発チームはリリースを前提にしたスプリント管理をしていますが、デザインチームはプロダクト開発以外のタスクが発生することがあるためです。
- また、弊社デザイナーは開発チームに専属ではないので、デザイナーのタスクを横断して管理・把握できる方が都合がよいためです。
- Jiraのスプリント機能を使用し、1週間のスプリントで運用しています。2週間で運用していた時期もありましたが、事業や開発サイクルの目まぐるしさゆえ、日々状況が変わり結局見積り直すことになるので1週間に落ち着きました。
運用プロセス
1️⃣ ざっくりプランニング（前の金曜）
金曜日にチームで「ざっくりプランニング」を行います。
ここでは次週どんなTODOやイベントがあるかを風呂敷を広げ、優先度が高く確実に終わらせるべきタスクは何か、この時点で明らかに無理そうなものはないか、リスクのあるもの（期日が迫っているが他チームの何某で詰まっているなど）について話し合います。
ここで仮で担当者を決めて、プランニングに備えます。
もともとはこの会は行っていませんでしたが、人が増えた・タスクの複雑性が増したためこの会を設置しました。
2️⃣ プランニング前（各自）
プランニングの前に、各自以下の作業をしておきます。
タスクを切る
- 「ざっくりプランニング」で担当になったタスクについて、Jiraにチケットを切ります。
- タスクはプロセスごとに切ることが多いです。
- 例：「方針検討」「〇〇の情報整理」「ワイヤーフレーム」「UI作成」
- プロセスごとに切ってもタスクが大きい場合は、都合のいい単位で分解します。
- 例：「UI作成（〇〇メニュー）」「UI作成（モバイル）」
優先度を付ける
- タスクは優先度が高い順に上から並べておきます。
- 以下の基準でJiraの「優先度」欄を更新しておきます。
- 「高」 - 何が何でも完了させる必要あり
- 「低」 - 次週に回してもOK
3️⃣ プランニング（月曜）
週の頭にプランニングを行い、以下のような内容を話し・確認し合います。
タスク内容の確認
タスク担当者から、タスク内容の共有をします。
他のメンバーは気になることがあれば質問します。例えば以下のような内容です。
- タスクの目的や内容について不明点を質問
- 参考情報の提供（「前に似たタスクや検討をしたことがある」場合など）
- こういうことも検討しておいた方がいい、といったリスクの指摘
- もっとタスクを分解した方がよさそうだ、といったアドバイス
各タスクのストーリーポイントを確認
- フィボナッチ数列でポイントをつけていきます。
- ポイントの付け方は、スクラム開発チームの考え方をもとにしています。
参考：ストーリーポイントで見積もる現実的な方法 - Qiita
- ポイントの付け方は、スクラム開発チームの考え方をもとにしています。
- 各タスクが大きくなりすぎていないか確認します。
- タスクが大きいと進捗が見えづらくなってしまうためなるべく小さくします。
- 大きいタスクを1つ完了させるよりも、小さいタスク4つを少しずつ完了させていく方が達成感があり精神衛生上よいのもあります。
- 具体的には、ストーリーポイントが3以下になるくらいに分解します。（1日ちょっとで終わるくらいの大きさ）
- あまり細かくしすぎると、今度は管理が大変（タスクを作ったり更新するのが面倒）になるので自分が辛くならない程度にします。
補足：プランニングポーカー
- 初期はプランニングにて全員でプランニングポーカーを行っていましたが、投票と合意形成に時間かかる & ポイントの付け方の認識が揃ってきたため現在は行っていません。
- 現在は「自分でポイントが見積もれない/不安がある」場合に相談したり、「このポイントでは終わらないのでは？」があれば他の人から指摘します。
- プランニングポーカーをすると、タスクの認識ずれが露呈します。各自の想定するポイントがずれているということは、タスクの内容が正しく伝わっていない場合が多いです。
- 新チームの場合は、認識を揃えるという意味でプランニングポーカーを積極的に行うとよさそうです。
優先度の確認
各人が事前につけておいた優先度が問題なさそうか？を確認します。
各メンバーの今週の合計ポイントを確認・担当者の調整
- 各人にポイントを積みすぎていないか？少なすぎないか？を確認します。
- 私たちのチームでは、週に1人12.5ポイント（2.5ポイント/日）を基準にしています。基準のポイントはチームによって異なりますが、私たちのチームでは何回かスプリントを回した結果、この数値に落ち着きました。
- ポイントが基準よりも多い場合は、余裕のあるメンバーへ移すか急ぎでないなら次週へ下げます。
- もし休みや会社のイベントがある場合は、それを考慮して積むべきポイントを減らします。
（例：今週は祝日があり4日稼働なので合計10ポイントになるように積む）
4️⃣ 朝会
朝会はJiraの「スプリント」ボードのカンバンを見て行います。
各自、昨日やったこと、今日やること、相談事項について話します。
随時、進め方や成果物に対して気になることああれば話し合い、お互いにフォローします。
こんなときどうする？
運用をするにつれて、いくつか困ったことが出てきました。
毎週の振り返りMTGで改善方法を話し合い、以下のように運用することにしました。
想定よりも大変だった
タスクに着手してみたら「こんな検討も必要だった…！」と気づくことも多いです。
この場合は、タスクのポイントを増やすか、別のタスクを改めて切ります。
期日に影響がある場合は、開発チームに共有します。
想定よりもラクだった
タスクの完了時にポイントを減らします。
Jiraでは計画時のポイントと終了時のポイントの差分が確認できるので、気にせずポイントを編集してしまいます。
ポイントが減った分、来週やる予定だったタスクや改善タスクなどを見繕います。
差し込みがきた
週頭のプランニング時に想定してなかったタスクが発生することも、もちろんあるでしょう。
この場合は新しいタスクを作成します。
その分着手できないタスクが出てくるので、優先度の低いタスクを次週に回します。
どうしても今週終わらせなければいけない場合は、他のメンバーにお願いできないか検討します。
今までやったことがないタスクなので見積もれない
未知のタスクは「何に・どれくらいかかるのか」が分からないため、まず「調査・検討」のチケットを積みます。
その中でプロセスやゴールを検討し、具体的なタスクに落とし込みます。
今週着手はしたが終わらなかった
今週のタスクはDoneとして、来週分のタスクを改めて切ります。
いつタスクを「完了」にすればいいの？
「自分の作業が終わったら」完了にします。
以前はタスクを完了にする基準が決まっておらず、レビューが終わったら完了にする、など人によって様々に捉えていました。
しかし、レビュー完了を待たないといけないとなると、いつまで経っても「完了」にできず「Paused（停止中）」のレーンにタスクが溜まります。
その週のうちに都合よくレビューを完了してもらえないことも多いため、「自分の作業は終わっているがいつまでもボードに常駐している」状態になり、自分が本当にやるべきタスクがぼやけてしまっていました。
そのため、わたしたちのチームでは「自分の作業が終わったら」タスクを完了にし、レビュー後の修正が発生すれば別タスクを切る運用としました。
結果と効果
このような運用をしてみて、次のような効果がありました。
- ✅ 各人が何をやってるか把握しやすくなった
- タスクがフェーズごとに切ってある、かつタスクについて話す場が毎日あるため、各人が何をしているか把握しやすくなりました。
- ✅ 進捗が把握しやすく、お互いにフォローしやすくなった
- タスクを程よく小さく切っているので、他のメンバーが進捗が把握しやすくなりました。
- 「タスク溢れていそうだけど大丈夫？」「ずっと進行中だけど大丈夫？」などと声かけがしやすくなりました。
- ✅ 現実的なタスク量を詰めるようになった
- 今週取り組むべきタスクが現実的な量で積まれているため、溢れづらくなりました。
- 溢れたとしても、その対処方法がチームで共通認識が取れているので毎回対処に困らなくなりました。
- 「完了」タスク率が上がりすっきり終えられる週が増え、精神衛生的にもよかったです。
さいごに
- 企業にはタスクが溢れかえっています。仕事は無限にあります。その中で「今やるべきこと」を選択し、それをチームで確実に終わらせていくための仕組みが重要です。
- 今回の内容はあくまでもわたしたちの例であり、みなさんにとっての最適解とは限りません。チームにとってやりやすい方法を納得した形で見つけることが大事だと考えます。わたしたちもこれが最終系ではなく日々改善を重ねていきます！
ここまでお読みいただきありがとうございました！
明日・5日目の「株式会社ビットキー Advent Calendar 2022」は @_otakakot_ が担当します。