こんにちは、Webサイト運用チームの栗原です。
普段は色々なお客様のWebサイト運用業務に携わっておりますが、突発的なご依頼があるのが運用の本分です。そんなご依頼に柔軟に対応するべく毎日奮闘した日々を送っております。

今回は、Webサイト運用を行う上で課題となるタスク管理に関するお役立ちツールの紹介をさせてもらいます。

自社のWebサイトの管理業務は、
主業務のかたわらでこなしている方が非常に多い

BtoBの業態の会社様へアンケートをしてみた結果※1、自社のWebサイトの管理者は専任で担当なされている方の割合としては非常に少なく、主業務のかたわらWebサイトの担当もなさっている方が非常に多い結果となりました。
※1 弊社がBtoB企業様にお伺いし、運用やリニューアルの実態をヒアリングしたものをレポート「コーポレートサイト運用実態レポート」p44_p45参照

主業務を行いながら、色々な部署や上司から「ここを直してくれ」、「ここのページが見にくいから直してくれ」、「◯△□の情報を追加してくれ」との依頼が多方面からきていると思います。

日々優先順位を付けてWebサイトの更新を空いた時間に行い、忙しい日々を送っている中、どうしても優先順位が低い依頼などは忘れ去られてしまうことがあるのではないでしょうか？

メールの文中に、
主題とは別件の依頼が紛れ込んでいたら要注意

例えばメールの文中に、主題とは異なるWebサイトの更新依頼が、（ついでに？）ちょろっと書かれていたりした場合、優先順位が低いと思ってその依頼への対応を後にまわすと、手遅れになることがあります。

なぜならそのメール、探すのに時間がかかります。すぐに対応しない限り通常の２倍は時間がかかってしまいます。（おおげさですかね・・・。）

メールにおいてもきちんと件名ルールや本文内の記載ルール（誰が何をいつまでに）を定め、ルールを決めて行えば上記のようなことは起こらないと思いますが、もっと直感的で便利なツールがあるんです。
それが「Backlog」。タスクを一元管理できるツールです。

Backlogの特徴

このBacklogを使うメリットとしては、1つ1つのタスクを明確にすることができます。

Backlogでは、1つのタスクを「課題」と呼ぶのですが、１つのタスクごとに課題を作成し、その課題の中で、

・課題名
・更新内容
・優先度
・テストアップ日
・本番アップ日
・担当者

などを指定します。

こうする事で、誰が、いつまでに、何をしなければいけないかを明確にすることができ、検索機能も充実しているため、担当者別に表示したり、カテゴリ別で表示できたりしますので非常に便利です。
ちなみに、カテゴリは自由にカスタマイズ可能ですので、案件ごとに使い分けたりします。

その課題の中は、1つのタスクの話題が絞られているため、後々読み返した際に、経緯を確認できたり、課題に紐付いた関連ファイルも一目でわかります。

BackLogの使い方等は、別途オフシャルページを見ていただくとし、以降はBacklogを使用する際に特に気をつけていることを紹介させていただきます。
 

〜Backlogで注意すべき３つのポイント〜

1. 更新依頼はBacklogにて行うルールを徹底するべし

更新依頼方法がメールからだったり、Backlogからだったりと色々なツールを使用して行われた場合、かえって手間となってしまいます。

そのため、必ず更新依頼はBacklogを使用するように、関係各所に協力をしてもらう必要があります。

新たにBacklogの使い方、ルールを覚えるもらう事となるため、導入時はやはり、普段と比べ負荷は高くはなりますが、後々のフローの効率化を考え、無理を言ってBacklogでのやりとりを推奨させてもらっています。

2. 「担当者」は必ず変更するべし

課題の項目の中にそのプロジェクトに従事しているメンバーがお客様も含め登録をします。
その複数人いる中で、誰がボールを持っているのかを明確にする必要があります。

例えば、デザインの作成段階では弊社デザイナーの名前を登録しておき、デザイン完成後、お客様担当者様へ確認出しを行ったタイミングで弊社デザイナーがお客様担当者様へ担当者を変更し、今現在のボールはお客様にあることを明確にする必要があります。

その後、デザインに問題がなければ、問題ない旨を連絡いただき担当者を弊社デザイナーもしくは、弊社コーダーへ担当者を変更してもらいます。

すごく些細なことですが、これをやることで、誰がいまどのボールを持っているかを複数ある課題の中から担当者でソートをかけることで、自分がもっている課題を明確に把握することができます。

3. 「状態」（進捗）はこまめに更新すべし

課題ごとに状態といったカテゴリがあります。これは課題がいまどの状況にあるのかを示すステータスとなっており、未対応 / 処理中 / 処理済み / 完了があり、進捗状況に応じ適宜変更する必要があります。

案件によりけりではありますが、新規課題の作成をお客様にしてもらう場合は新規課題ができたタイミングにて、担当ディレクターが受領の意も込め、担当者への割振りと「状態」を「未対応→処理中」へ変更をしましょう。

「状態」が変更されておらず、「未対応」のままですと課題の担当者様が心配になるケースがありますので、先のリリース課題であっても確認を行った段階でステータスを変更しましょう。

また、「完了」とするルールを事前にお客様も含めたプロジェクトメンバー全員で明確にしておきましょう。

例えば、
・本番アップ完了後、お客様が確認し問題がなかった場合
・HTMLファイル一式をファイル納品が完了し、その後お客様にて本番公開した段階

と案件によって弊社にて請け負う部分が異なるため、何をもって課題を完了とするべきなのか明確にする必要があります。

また、「処理中」→「完了」へ変更できる人を案件担当者様のみが本番公開されているページを確認後「完了」へ変更できるなど、課題を「完了」できる人を限定した方がよいでしょう。

当たり前のことですが、事前にこのようなルールを決めているのといないのでは、課題に対する重みが異なってきます。

BackLogを使用する上で、正しいやり方はありません。案件ごとに運用フローを明確にし、案件に合った設定を行うことが大切です。また、運用開始時に運用フローに沿いルール化し、プロジェクトメンバーに共有することで、スムーズなやりとりができると思います。

最後になりますが、Backlogの使い方はWebにおけるタスク管理だけではなく、個人のタスク管理に使ってもOKです。長期的な人生の課題にマイルストーンを置き、計画を立ててみるのはいかがでしょうか？（笑）