Backlogで行う課題管理の10のコツと、クライアントに伝えるべきこと

スポンサードリンク

Qを観る前にネタバレ見てしまったYO（挨拶）！

どもども、ブルーです。

Web制作を生業にしていると、当然チームを組んで受託案件をこなすことがあるかと思います。会社員でもフリーランスでも同じでしょう。その様なとき、案件でこなすべきタスクの可視化や進捗管理にプロジェクト管理ツールを導入することも多いかと思います。今回は、その様なプロジェクト管理ツールのなかでも、WordPressコミュニティではWordCamp Osaka 2012やWordCamp KOBE 2011でもスポンサーとしてお馴染みのnulabさんのBacklogを題材に、Web制作の現場に即したタスク登録のコツについてご紹介したいと思います。

ちなみに、この記事はディレクションの立場も指示を受けて作業をこなす立場も両方を業務で経験する中で得た、自分なりの考えで、現在もアップデート中のノウハウです。これが正しいプロジェクト管理だ、と講釈を垂れるつもりもありません。実際、今年もプロジェクトの進め方がマズかったなぁと反省することばかりです。そんな実際の反省から悩みながら生まれたBacklogの使い方を10個にまとめてみました。また、いわゆるWeb制作の現場を想定していますので、バリバリの開発案件では、また違ったものになると思います。

Backlogとは？

まず、Backlogについて、どういうサービスなのかを少しご紹介します。Backlogは、オンラインのサービスで、アカウントさえ取得すれば誰でもかんたんにプロジェクト管理がスタートできます。10ユーザーまでは無料なので、まずプロジェクト管理を試してみるという用途には最適かと思います。また、Backlogにはガントチャートやバーンダウンチャート、Wiki、バージョン管理（Gitも対応）などの機能がありますが、今回はこのなかで課題管理を中心に取り上げたいと思います。

Backlogでの課題の追加

Backlogでは、個々のタスクを「課題」と呼びます。他のシステムではイシューとかToDoとかの言い方もあると思いますが、課題という呼称はなかなか分かりやすく汎用的なのではないかなと思います。プロジェクトの立ちあげからリリース＆納品、運用まで、あらゆる課題を登録していきます。

課題の追加画面はこのようになっています。件名、種別、優先度の3つが必須項目になっていますが、詳細の欄でその課題の内容を書かないと分かりにくいでしょう。他にも、カテゴリー、発生バージョン、マイルストーン、担当者、予定時間、開始日、終了日が設定できます（利用プランによって異なります）。また、添付ファイルをアップロードすることもできます。

Backlogで課題を追加する画面

Backlogの使い方はこのくらいにして、さっそくこの課題の立て方のコツを10個ご紹介しようと思います。

1: 案件の概要やゴールをWikiやファイルで共有する

いきなり課題を追加する前の話ですが、プロジェクトの全体像を共有することはとても大事です。プロジェクト全体のなかでその課題がどこに位置するのか、を見える化するにはマイルストーンやバーンダウンチャートという機能を使うこともできるのですが、これらの機能ってウォーターフォール型のソフトウェア開発の現場では有効だと思いますが、Web制作にとってはいまいち親和性がないのかなぁと思います。これは個人の感想ですが。

また、Web制作では提案依頼書（RFP）や提案書、スケジュールをテキストドキュメントやスプレッドシートでクライアントと共有することが多いと思います。せっかくこれらの資料を作成したのであれば、それをプロジェクトのファイルにアップロードしておくのがいちばん楽でしょう。情報のシェアはスピードが命ですしね。ただし、案件の全体像がひと目で分かるまとめはWikiに1ページで書いておくとより良いかなと思います。また、クライアントと受託側の両方の担当者の連絡先も書いておくとより良いでしょう…。いま思いつきました。次からそうします。

2: 優先度や状態の意味を共有する

それぞれの課題には、優先度と状態を設定できます。ただ、その表現の意味するニュアンスは、人によって捉え方が異なると思います。例えば優先度は高・中・低の3段階があり、それぞれの課題に振り分ければ相対的な優先度は指定できますが、優先度高がじゃあどれくらいの急ぎなのか、優先度低はどれくらいあとまわしにして良いのかの絶対的な評価は高中低の言葉だけでは分かりません。そこで、それぞれの意味を、少なくとも受託側のメンバーは全員、できればクライアント側の担当者にもルールとして共有しておくのが良いと思います。これはあくまでルールなので、それぞれのチームで決めてください。たとえば、自分は以下の様なルールで優先度や状態の意味を定義しています。

優先度高：なる早対応、期日の意味は「最悪この日までに終わらせる」
優先度中：期日までに終わればOK
優先度低：期日は目安程度で、優先度の高いものを先にやる、期日を過ぎたら延ばす

未対応：未着手
処理中：着手したら必ず処理中に変える（逆に未着手の間は担当が他のメンバーに変更されることもあると考える）
処理済み：タスクを達成、クライアント、またはプロジェクトマネージャー（PM）の確認待ち
完了：クライアント、またはPMの確認済み

3: カテゴリーの運用方法を共有する

それぞれの課題にはカテゴリーを設定でき、課題の一覧ではカテゴリーで絞り込んで課題を表示することができます。このカテゴリーは必須項目ではありませんので、少人数の組織では設定する必要はないと思っています。カテゴリーに何を設定すべきかを考えた場合、一覧でのカテゴリーによる絞り込みを活かすには、関係する人間をカテゴリーに設定するのが良いと思います。

ウェブ制作のプロジェクトは、企画、デザイン、開発、検収、保守とおおまかに分けられ、関係する人間がそれぞれ異なることが多いかと思いますので、これらをカテゴリーに登録しておくと、課題がたくさん積み上がっていても、プロジェクトの関係者は自分が見ておくべき課題だけを抽出して一覧することができます。ただし、このようにカテゴリー分けする場合は、課題の登録の際に必ずカテゴリーを登録するように気をつけましょう。登録漏れが頻繁にあるようだと、絞り込んで自分に関係する課題だけを見る…というメリットが活かせません。nulabさん、プロジェクトごとに必須項目を変更できるようにしてくれないかしら。

4: 終われない課題を登録しない

プロジェクト管理に慣れていないとやってしまいがちなことです。終われない課題とは、要するに何をしたら終わるかがはっきりしていない課題ということです。終われない課題が積み上がると、プロジェクトの見通しが悪くなってしまいます。

よくある終われない課題の例：

「ご相談」…一番ダメなパターンです。終われないどころか、内容も分からない。
「デザイン」「デザインについて」…デザインをどうするのかが全くわかりません。提案なのか？コンセプトデザインなのか？開発フェイズならどのページのデザインなのか？
「○○機能」…これも、その機能をどうすると完了なのか全くわかりません。

良い例：

「WordPressのインストールと動作確認」…WordPressの動作確認が終われば完了できます。
「○○機能の仕様を決定する」…仕様が決まれば完了できます。設計や開発、テストは別の課題を立てましょう。
「セカンドページのデザイン作成」…少しあいまいですね。対象ページは必ず詳細欄に書きましょう。
「○○で△△が発生する不具合の修正」…バグ修正の場合も、課題の件名でおおまかに内容が分かるほうが良いと思います。

5: できるだけ寿命の短い課題を登録する

4と近い内容ですが、ひとつの課題にいくつかやることが混じっていると、課題の担当者は終わったつもりになっていても、課題を登録した人からしたらアレが終わってないよ、という思い違いが起こり、行うべきタスクが放置されるケースが発生します。また、「開発」みたいなざっくりしすぎている課題を登録してしまうと、途中で思いついたタスクを全てその課題のコメント欄に書いてしまい、これまた「3つ前のコメントで指摘したアレ終わってないんやけどどうなってる？」「おお、やってない。確認不足やったわ。」というやり取りが発生してしまいます。忘れてた担当者をなじるのではなく、課題の登録のしかたがマズイと考えましょう。

ひとつの課題に複数のタスクを混ぜないコツは、できるだけ早く終われる課題にすることです。数週間かかりそうなものは、複数の細かい課題に分けて登録してみましょう。

6: 課題に関係ないコメントをしない

4、5と関連しますが、課題に関係ないコメントは避け、新しい話題は課題を追加しましょう。小規模な案件でも、課題ごとに担当がわかれていて、各担当者が常にすべての課題の内容を把握しているわけではありません。読まれているはずと思ってコメントしたのに、読んで欲しい人に読まれていないということはよく起こります。開発の現場を知らないお客様の場合はそのあたりの事情もシェアしておいたほうがよいかもしれませんね。

もし課題があるのに気づいていないで新しい課題を立ててしまったとしても、気にしないでください。気づいていなかったということがプロジェクトで共有されることに意味があります。その場合は、プロジェクトマネージャーは重複している課題があることを指摘し、完了理由を「重複」にして新しい課題を完了しましょう。

7: PM以外が期限日を変更しない

ウェブ制作プロジェクトの場合は複数のタスクを並行してスケジュール通りにこなすため、プロジェクトを管理するプロジェクトマネージャーが全体の課題を管理すると思います。しかし、Backlogではプロジェクトの参加者はだれでも課題の期限日を変更できてしまいます。しかし、期限日の変更は非常に気づきにくいです。課題の担当者が、期日までに終わらなさそうだからといって自分の判断で期限日を伸ばしてしまったりすると、プロジェクトが混乱する元です。いったんプロジェクトが走りはじめたら、期限日の変更はプロジェクトマネージャーに相談して、勝手に変えないようにしましょう。nulabさん、これもシステム的に対応してくれないかな…。

8: PM以外が課題を完了しない

7と同じ理由ですが、課題の担当者が課題を完了させることができますが、自分では終わったと思っていても、課題を登録した人がやってほしかったこととずれている可能性がありますので、勝手に完了しないようにしましょう。課題の担当者は処理済みに変更するのみとし、課題の完了はプロジェクトマネージャーのみが行うようにすると混乱しません。

また、話題が関連しているからといってむやみに完了したタスクを復活させるのも混乱のもとですのでやめましょう。

9: 課題を立てずにコミットしない

これはBacklogでソース管理も行なっている場合ですが、コミットメッセージに課題のIDを含めるとリンクできる機能があります。コミットメッセージにはできるだけ課題のIDを入れるようにしましょう。逆に言うと、課題を立てないとコミットできないということです。その理由は、プロジェクトマネージャーやお客さんはGitのコミットログまでいちいちチェックしていないということです。何の作業をしたのかプロジェクト全体で共有するためには、コミットログを見てくれよ、ではなく、必ず課題を立てるようにした方が良いと思います。

10: 進められない状況の時は自分を担当者から外す

他の案件のスケジュールが押している、保守案件で緊急対応が入った、体調不良で休む、など、自分が担当になっている課題を進めることができない状況の時は、自分を担当から外すようにしましょう。プロジェクトマネージャーは課題の担当者がその課題を進めていると解釈しますし、何も言われなければ期日通りに終わると解釈します。間に合わなくなってから間に合いません、と報告するのが一番マズイパターンですので、もしその課題を自分が進められない、と判断したら、担当を変更しましょう。新しい担当者の判断がつかない場合はプロジェクトマネージャーを担当者に変更し、進められないことを報告します。こうすると、新しい担当者を探す仕事がプロジェクトマネージャーの仕事になります。

クライアントに伝えておくべきこと

以上、課題管理の10のコツをご紹介してきました。プロジェクト管理ツールは、うまく使えばプロジェクトの見通しがよくなり、メールやチャットで連絡を行うより格段にコミュニケーションコストを抑えて本来行うべき業務に集中することができます。チーム内だけでなく、クライアントもプロジェクトに招待しすべての課題を共有すれば、クライアントとの連絡がとてもスムーズに進みますし、クライアントにとってもきちんと開発が進んでいることが見て取れて安心できます。

一方では、こういうプロジェクト管理ツールに慣れていないクライアントであれば、ツールの違いが分からずついメールやチャットのように使ってしまうということも起こりがちです。特にチャットはスピード感のあるコミュニケーションが可能な反面、完了条件や期限日などはありませんので、タスクを管理するには向いていないツールです。ですが、重要なのは、どちらもただのツールだということです。そしてコミュニケーションには、ルールも必要です。ツールによって異なるルールを理解してもらい、活用してもらうのが実は一番大変だったりします。Backlogが助けてくれるのは、このコミュニケーションルールの共有をしやすくすることで、コミュニケーションにかかるコストを抑えることです。そしてそれは、制作コストの低下となって、クライアントのメリットにもなります。プロジェクト管理ツールを導入しクライアントと共有する場合は、このクライアントのメリット、そしてプロジェクト管理には特有のコミュニケーションルールがあり、それを守ってほしいということは、先に伝えておくとスムーズなのではないかと思います。

とはいえ、冒頭にも書いた通り筆者自身もプロジェクト管理には毎度苦労しており、この記事の内容が完璧だとも思っていません。こういう工夫をしているよ、というアイディアがありましたら、ぜひコメントいただければ嬉しいです。あなたもプロジェクト管理ツールをうまく使ってコミュニケーションルールを明確化し、余計な衝突を避けてプロジェクトをハッピーに終わらせてみませんか。

著者情報

WPD-Blue: 辛口トークでお馴染みの不健康男子です