こんにちは、キノトロープアカデミーです。
「キノトロープアカデミー」は、Web業界のトップランナーである株式会社キノトロープの社員が講師を務めるオンラインアカデミーです。リモートワーク時代に不可欠な「個のスキル」を高め、職人のような「匠」を目指す人を増やしたい。そんな願いを込め、基礎から経営判断、業務フローまで、一生モノのナレッジを惜しみなく公開していきます。
＜初級編 第19回＞
Backlogによる課題管理術
についてお伝えします。
担当は濱田です。
プロジェクト管理ツール「Backlog」は課題管理を効率化する優れたUIを持っていますが、導入するだけで自動的に課題が解決するわけではありません。
運用を形骸化させず有効に機能させるためには、タスクのボールを誰が持っているかを示す”担当者”、直近の完了予定日をこまめに更新する”期限日”、そして顧客の最終確認OKまで見届ける”課題のゴール”の3点を常に明確に定義し、ルール化することが不可欠です。
ツールを使いこなすための正しい運用ルールをチームやクライアント間で定着させてこそ、停滞や見落としを防ぎ、プロジェクトをクリアに推進し続けることが可能となります。
”Backlogによる課題管理術”をテーマに、
今日お伝えしたいことは3つあります。
Backlogは、株式会社ヌーラボが提供しているプロジェクト管理ツールです。
ASPとしてサービス提供しているほか、パッケージ版の販売も行われています。
2018年には利用者数が100万人を突破し、日本国内におけるプロジェクト管理ツールとしては最大規模のサービスといわれています。
Backlogの主な機能として、
・課題管理（ボード / 各種チャート）
・バージョン管理（Git / Subversion）
・Wiki
の3つがあります。
課題管理は、各プロジェクトにおける細かい課題を起票し、社内メンバー・取引先・代理店担当者と作業やプロジェクトの進捗状況についてコメントを送り合う機能です。
インターネット掲示板で言うところの、スレッドに似た感覚で課題を立て、メンバー間で進捗の報告、連絡、相談ができます。
バージョン管理では、Backlog をSubversionとGitリポジトリとして利用できます。差分の表示とインラインコメントの挿入、チームメンバーへのプルリクエスト・マージリクエストなど開発タスクの補助機能が備えられています。
Backlogで立てる各プロジェクトには、あらかじめ Wiki が搭載されています。プロジェクトに関する覚書、会議の議事録、作業マニュアル、仕様書などチームメンバーに向けた共通情報を書き留めておくことができます。
近年、WEBに関わる業務が一般化したことで、WEBの担当者でも新しいツールやアプリケーションの使い方が馴染まず、戸惑うケースが多いと思います。Backlogはそのようなユーザーに最適のツールと言えます。
たとえば、課題を立てる際は、
1.「課題の追加」メニューをクリック
2.件名、内容を入力
3.追加ボタンで作成
なんと、最低3ステップで手軽にできます。
インターネットさえあれば、どこからでもアクセスできるので、専用のソフトをインストールしたり、面倒なセットアップをしたりする必要もありません。スマートフォンにも対応しているため、外出先からBacklogにアクセスすることもできます。
こちらのBacklogですが、キノトロープでは運用サポート窓口として活用しています。
サポート窓口というと、Eメール・電話によるやりとりが一般的ですが、いくつかの短所があります。
1.電話のやりとりは、目に見える記録に残らない
2.メールでのやりとりは、過去の返信を見返しづらい
3.受信ボックスでタグ付け・フォルダ分けをするのが面倒
4.宛先に複数人の担当者を追加するのが面倒
5.各課題、問い合わせの進捗が把握しづらい
などが挙げられるでしょう。
キノトロープではBacklogによって、これらの短所をクリアしています。
こちらが、Backlogを利用したサポートの流れです。
1.クライアント様がWEBサイトの運用に関する問い合わせ・相談をBacklogで課題として追加します。
2.課題の内容をキノトロープで確認し、課題にコメント欄から返信します。サイトの障害や不具合の対応など、作業が発生するものは問い合わせを受け付けた旨をとりあえずコメントします。
3.問い合わせの詳細確認が必要な際も、同様に課題のコメントで質問を追記します。
4.対応作業を進め、終わり次第、完了のコメントを残します。
では、さきほどの短所と照らし合わせてみましょう。
このように、課題ごとにコメントがまとまるので、他の課題と混同することはありません。それぞれの課題内で、過去にどのようなやりとりをしたかを簡単に振り返ることができます。
Backlogの課題には【種別】【カテゴリー】というラベルをつけることができます。
プロジェクトごとにカスタマイズ可能で、例えば「問い合わせ」「見積依頼」「作業依頼」「システム障害」「不具合対応」と、内容に応じたラベル分け、クライアント様の部署名でラベル分け、といったことが可能です。
この【種別】と【カテゴリー】によって、課題のカテゴライズ、整理が簡単にできます。
Backlogでは、課題の起票時・更新時に、プロジェクトメンバーへ自動的に通知メールが配信されます。この機能によって返信の見落とし、連絡漏れを防ぐことができます。
Backlogには、【状態欄】というラベルがあります。各課題を「未対応」「処理中」「処理済み」「完了」の4つのステータスに振り分ける機能です。
課題の状況に応じて状態欄を切り替えることで、進捗を確認することが可能です。
クライアント様の中には、コンプライアンスの関係でBacklogをはじめとした外部のサービスを利用できない、というケースもあります。
そのようなときは、電話やメールベースでやりとりを進めつつ社内での作業進捗の管理、報告、電話メモとしてBacklogを活用するようにしています。
Backlogのメリットについて説明しましたが、逆に、Backlogを導入したにもかかわらず、運用が立ち行かず結局利用をやめてしまった、というケースもあると思います。
課題が次々に溜まる一方で、いっこうに減らない、課題に誰も着手しない、課題が多すぎて、何から手をつけたらいいか分からなというケースは、Backlogに限らずどのツールでも起こり得ることです。
そこで、キノトロープでは特に【担当者】と【期限日】に着目して運用しています。Backlogに搭載されている【担当者】【期限日】の機能について説明します。
まず、【担当者】欄は今、その課題に「誰が」着手しているかを示すものです。
・修正作業を進めている最中である
・不具合や障害の状況確認中
・質問を受け付け
・回答に向けて調査を行っている
これらのタスクを進めている人を、【担当者】として割り当てましょう。
キノトロープでは、比喩として「ボールを持っている、投げる」と表現することがあります。
進行中のタスクのボールを誰が持っているか、
それを明示するのが【担当者】欄です。
受け持ったタスクが完了し、別の人にボールを投げるときは
【担当者】欄を次のタスクの実施者に変更します。
次に、【期限日】は、課題のタスクを「いつまでに」終わらせるかを示します。
ボールを投げる、つまり、タスクを別の人に引き渡すと同時に【期限日】もこまめに変更しましょう。
【期限日】は、課題全体の納期と思われがちですがキノトロープでは、直近のタスクの完了予定日を都度入力しています。
依頼された修正作業を終えたとき、
「〇〇の修正が完了しました。●月●日までにご確認をお願いいたします。」
とコメントを添え、
【担当者】を、次の確認する人に変更し【期限日】に、確認期限の日付を入力します。
【担当者】と【期限日】を常にセットで入力することで、次のタスクは「誰が」「いつまでに」実施すべきか一目で分かります。
課題が減らない、誰も着手しない、
何から手をつけたらいいか分からない。
これらのケースは、
「誰が」＝【担当者】
「いつまでに」＝【期限日】
をそれぞれの課題で明確にしないと、陥りやすくなります。
Backlogのダッシュボードでは、自分が担当者として割り当てられた課題が一覧できます。課題が多い場合、まず期限日の近いものから着手し、ひとつひとつタスクをこなしていけば、おのずと数は減ってゆくはずです。
【期限日】を過ぎた課題は、【期限日】を更新するまでメールで毎日通知されるのでBacklogからの通知も常にチェックしましょう。
【担当者】と【期限日】を入力するというルールが定着すると、それらが空欄となっている課題をチェックし、未着手である、停滞している、ということに気付き、課題が溜まらないように常にクリアし続けることができます。
さらに、【課題のゴール】が何かを常に意識してください。
例として、WEBサイトの改修依頼をシミュレーションしてみましょう。
まず、Backlog課題の【状態欄】を「未対応」から「処理中」に変更します。
改修対応のお見積り、スケジュールの策定、改修内容の詳細確認を行います。
そして、本番環境へリリースを行い、お客様へリリース完了の旨を連絡します。
この時にありがちなのは、改修作業・リリースが終わった、つまり「課題の対応が終わった」と見なして【状態欄】を「完了」に変えてしまうことです。
Backlogでは、課題が「完了」になってしまうと、以降の更新通知がストップします。
プロジェクトの中の課題一覧や、ダッシュボードの「自分の課題」にも表示されなくなります。
もし、この状態でWEBサイトを確認したお客様からリリースの影響で思わぬ不具合が起こっている、反映漏れの箇所があるというコメントが追記されても、すぐに気づかず対応が遅れる可能性があるのです。
また、お客様も「完了」した課題を見逃し、最終チェックを後回しにしてしまうことがあり得ます。このような事態を防ぎにはどうしたらいいでしょうか。
そこで、この課題の【ゴール】が何かを改めて考えてください。
先ほどの例で言うと、リリースが終わった時点で課題の【状態欄】を「完了」にしていました。
これでは課題の【ゴール】と「完了」の地点が揃わず手戻りが発生した後の対応がスムーズに進行できません。この課題は終わっているのか、まだ続いているのか一目では分からなくなってしまいます。
実際は、「完了」の一歩手前「処理済み」が適切です。
その上で、リリース済みのWEBサイトをお客様に確認頂き、手戻りがない、問題ない、と判断されたときに【状態欄】を「完了」とするべきです。
もし、手戻りがあった場合は「処理済み」を「対応中」に戻し対応を継続してください。
このように、課題の【ゴール】が何か、何をもって課題を「完了」とするか、を明確にしていないと、お互いに「すでに終わったつもりでいた」と見過ごされてしまうことがあります。
課題は、【ゴール】に近づいたときほどより慎重に【状態欄】を管理してください。
最後に、お伝えしたいのは「ツールそのものが勝手に課題を解決してくれるわけではない」ということです。
Backlogは課題管理を助けるツールです。しかし、当然ながら自動的にBacklogが課題を減らすことはないということを忘れてはいけません。
課題管理において重要なのは、「だれが、いつまでに」そして課題のゴールを常に明確にすることです。
Backlogはそれらを、【担当者】【期限日】【状態欄】などのラベルで把握しやすくしているにすぎません。
ツールを導入して終わり、ではなくその運用ルールを、社内やクライアント様との間で定め、有効に動かすためには、どの機能をどんなふうに活用すればいいのか常に意識しながら使いこなしていきましょう。
最後までご覧いただきありがとうございました。
の３点についての内容でした。
