ITエンジニア/デザイナ向けにオープンソースを毎日紹介

今回は課題管理を取り上げたいと思います。課題(Issue)というと、タスク管理と混同されることが多いのですが実際には分けて考えるべきものです。その辺りの違いと、課題を適切に管理するためのソフトウェアについて取り上げていきます。

課題とは

コトバンクによると解決しなければならない問題とされています。その意味ではタスクにも似ていますが、個人的にはタスクは個人レベルまで落とし込んだもの、課題は企業や部署、プロジェクトといったグループ単位で捉えるべき問題として考えています。つまり課題を解決するためにタスクに落とし込んでいくと言った具合です。

そして各自が抱えている、またはクライアントから報告されてくる問題は単なる問題であって課題ではありません。例えば請求書の送付が期日に間に合っていないのは問題であって課題ではありません。課題としては請求書の送付を2日早めるといった具体的にいかにすべきかを考えられるものであるべきです。

同様にシステムのバグも不具合であって課題とは異なると考えています。

ここから先はプレミアム専用となります。

課題は議論できる

課題は言わば主題です。そこから議論し、どのように問題を解決していくべきか考えていかなければなりません。その意味においてはタスクに落とし込んだ後も議論が続くとすれば、それはまだ粒度や精度が甘いのかも知れません。個人的にはRedmineでは課題もタスクもチケットと呼ばれる単位に統合されており、それぞれにコメントがついていくことで話がどんどん逸れてしまう傾向があるのが好きではありません。

チャットを使っている場合は特に必要

Skypeやチャットワークなどグループチャットを使って議論しながら仕事を進めている場合、課題管理は特に大事です。デジタルで記録されているからと、日常会話から大事な議論まで同じ土俵で行ってしまうとすぐに流れていってしまいます。後になってからあの件はどうなったか、なんて確認したりするハメになります。

そうならないためにもストックしておける場を用意しておきましょう。まず起きている問題を記録し、その後でどう解決するか(課題にするか)考えれば良いと思います。

要望とユーザストーリー、課題を分けよう

最もやってはいけないのは課題と要望を混ぜ返すことです。要望は曖昧で結果も見えづらく、骨折り損にもなりかねません。課題は少なくとも解決することでプロジェクトや企業として前進が見込めます。ユーザストーリーは仕様レベルなので、優先順位によってそもそも実装する、しないといった選択肢が考えられます。

さも重要な課題であるかのように言いつつ、よくよく聞いてみると担当者の要望でしかなかったというケースは多々あります。取り扱いを間違えるとプロジェクト推進に問題が出てくるのでくれぐれも注意しましょう。

期日を設ける

個人的には課題やタスクの優先度というのは大した意味がないと考えています。結局のところ、期日が未定の課題というのはそもそも取り組む必要性すら感じられません。逆に優先度が低くとも期日が近いものは解決しなければならないのです。ということで課題については期日、または再確認する日付を設けるべきです。

 

MOONGIFTの関連記事

コメント

  • DevRel
  • Com2