私が仕事でWeb制作をするさい、プロジェクトメンバーで共有するタスク管理ツールは、主にBacklogを活用しています。
日々使っているからこそ、「こういう使い方は良くないな」「こんな失敗、あるあるだな」という事例が見えてきます。
今日はそんな中でも、絶対にやってはいけないことをピックアップしました。自分の使い方と照らし合わせてみて、「できてないな」と思うところがあれば改善しましょう！
担当者は必ず変更しなければいけない
「ワイヤーフレーム作りましたので、ご確認をお願いします！」と、チケットを更新したのに、チケットの担当者を変更していないケースが、たまにあります。
これは絶対にやってはいけません。
自分の持っているタスクを調べるとき、ほとんどの場合、「担当者：自分」でタスクを絞り込みます。自分の持っているタスクを確認したいときは、担当者が自分になっているタスクを見て判断するわけです。
チケットの進捗が更新されているのに、担当者が変わっていないと、そのタスクは宙ぶらりんになり、気づかれないまま時間が過ぎていってしまいます。
それが後々の爆弾になることも少なくありません！チケットを更新したら、チケットの担当者も必ず設定しましょう。
ステータスが「完了」になる条件を決めなければいけない
「なんか、いつまでも完了にならないチケットがある」って状態、たまにありませんか？その原因は、チケットが完了になる条件を決めていないからです。
このチケットは、誰でも完了にしても良いのか。それとも完了にする人が決まっているのか。
どういう状態になったらチケットを完了にしていいのか。「処理済み」との違いって何なのか。
チケットの状態に関するルールを決めておかないと、使っている人が迷ってしまいます。状態変更のルールは決めておきましょう。
たとえば、以下のようなルールはオーソドックスで使いやすいかと思います。
【未処理】
↓
作業を開始したら「作業者」が状態を変更
↓
【処理中】
↓
作業が完了したら担当を「依頼者」に戻す
↓
【処理済み】
↓
依頼者が確認後、完了理由を設定し、状態を完了にする。
差し戻しの場合、状態を処理中にする。
↓
【完了】
ひとつのチケットにふたつ以上の議題を盛り込んではいけない
原則として、ひとつのチケットに対して、やらなければならないタスクはひとつです。
たとえばWebページのデザインを作るチケットを立てたとして。デザインの制作を進めていく中で「図」を作る必要が出てきた。
この場合、
・ページのデザインを作る
・図のデザインを作る
というふたつのタスクが発生したわけです。これを、同じチケットで議論することはできません。「完了」のタイミングがズレてしまうからです。
「ページのデザインは出来上がっているのに、図のデザインが完了していないから、チケットを完了にできない」という状態は非常に不健全。
タスクを進行している最中に、新しい課題やタスクが発生したら、新しいチケットを立てるようにしましょう。
元となるチケットに関係するものであれば、親子関係に設定しておくと、その関連性が明確になるのでおすすめです。
「このチケットに関係ない話題が盛り上がってしまった」って状態は、意外と頻繁に起こります。プロジェクトマネジャーがきちんと整理して、話題を切り離すようにしましょう。
Backlog以外のツールで進捗を更新してはいけない
最近はリモートワークも盛んになってきたので、Slackなどの別のコミュニケーションツールとの併用するケースも少なくありません。
私もそう。プロジェクトのタスク管理はBacklogで行いつつ、細かいコミュニケーションはSlackで行っています。
ツールを使い分けるのは悪いことではありません。しかし用途をきちんと切り分けなければなりません。
一番よくないのが、ミーティングやSlackで議論した内容が、Backlogに反映されないこと。
プロジェクトの進行はBacklogに集約すべきです。「状態の変化や決定事項は、Backlogを見れば確認できる」という状態は厳守しなければなりません。
「●●ってどうなってましたっけ？」
「○○の資料、どこかにアップロードしてありますか？」
「ここの仕様を教えてください」
こうした細かい話はSlackで展開しても良いでしょう。
しかし、
「○○やりました！」
「●●の資料、記入しておきましたので、確認お願いします」
「デザイン確認しておきました！」
という "行動の結果" は、Slackで報告すべきではありません。結果はすべてBacklogに集約するようにしましょう。
守ってもらいたいルールは共有しなければいけない
私は今まで言った内容を含め、Backlogの使い方は、話さなければ共有されません。
みんなが当然のようにこのルールを知っているわけではないですし、なんなら、プロジェクト単位で運用のルールは違ってきます。
Backlogの使い方・運用のルールについて、話し合いをする場を設けましょう。特に忘れてはいけないのが、クライアントへの周知です。
これらのルールは、制作メンバーだけでなく、クライアントにも守ってもらわなくては、正しいプロジェクト管理はできません。
一番良いのは、プロジェクトメンバーみんなでルールを作ること。誰かが作ったルールに従うより、みんなで作ったルールのほうが、一体感が生まれます。
棚卸しの定例ミーティングを設けなければいけない
「Backlogでプロジェクト管理をしているのだから、チームメンバーのタスク状況はツールから確認できる！ミーティングなんかいらないよ」
そう思っているなら、それは大きな間違いです。
プロジェクトを管理するのはツールですが、プロジェクトを動かしているのは "人" です。人のやることですから、予定通りに進まないこともあります。
「思ったように作業が進まない」
「実は最近、体調があんまりよくない」
「他の案件でトラブルが起きた」
「正直、全然進んでない」
などなど。
気分やテンション、モチベーションなど、目に見えない負のステータスが、なかなかタスクに対して前向きに取り組めないこともあるでしょう。
Backlogのタスクだけでは把握できないものはたくさんあります。
目に見えないリスクをいち早くキャッチして、スケジュールを流動的に調整して、プロジェクトが円滑に回るようにする。これこそが、プロジェクトの進行には必要不可欠。
そのためにも、定期的にチームメンバーで顔を合わせて、Backlogのチケットを見ながらそれぞれの状況の共有をする。これは必ず行いましょう。
あとがき
Backlogの良いところは、ラフに使ってもそこそこ管理できてしまうところ。"なんとなく" って感覚で、意外とうまくできてしまいます。
マイルストーンやカテゴリなどの、こだわった使い方もできますが、それらは設定しなくても意外と運用できたりするんですよね。
でも、今回お話しした内容は、ラフな使う方をする上でも、絶対に守らなければならないルールです。メンバー全員がきちんと守れるようにしておきましょう。
