「課題」とは何ぞやという課題

ソフトウェア開発の現場では、よく「課題管理」という言葉を目にする。筆者はソフトウェア開発（間接業務含む）以外の仕事をしたことが無いので、他の業種ではどうかわからないが、特にソフトウェア開発の世界では、「課題管理」という言葉が多用される、というか、安易に使われているような気がする。まるで、ソフトウェア開発というものは、計画通りの進捗を阻害する要因は全て「課題」であり、「課題」を見つけて１つ１つ「解決」していけばいいだけのもの、と言わんばかりである。実際、現場から離れて「プロジェクト管理」なる仕事をする者の中には、本人の業務はMS Projectなどを使って進捗をグラフィカルにするだけの「進捗管理」と、MS Excelなどを使って「課題管理表」に行を追加して「状態」列を「完了」にして行を灰色または非表示にするだけの「課題管理」の2つしかしない者も少なくない。

筆者はこれまでに10以上のプロジェクトを見てきたが、大体どこのプロジェクトにも開発計画と「課題管理表」があり、解決していない「課題」が残っていると上司に追及されるような、外部報告用の「課題管理表」に挙げられた「課題」はどんどん「解決」して行くのに、現場で管理する本当の課題管理表に挙げられた「課題」はどんどん溜まって行く、という傾向があるようである。

少し気の利いたプロジェクトなら、報告用でない現場の課題管理表は、解決方法がわかっている「課題」とそうでない「課題」とを分離して、さらに前者の内作業計画もされたものは計画に、計画無しで作業するものは「TODO」に移動するなど工夫するので、ある程度、何らかの似たような性質のある「課題」に分類されるのだが、それでも、感覚的に粒度や問題の次元が異なる「課題」が同じ管理表にあることがほとんどである。

筆者も一応プロジェクト管理の仕事をしていたことがあり、延々と課題管理表を作っていたある時、「課題」って一体何だろうと思って、相当思いふけったことがある。その時には自分なりの答えを出したのだが、先週、再び混乱することがあったので、もう一度自分なりの考えを整理する。

実際の仕事上で「課題管理」を目的とする時の「課題」の意味は結構広く、緊急のトラブルやバグを除くと、イレギュラーに発生する、計画通りの作業遂行の障害となり得る要因は全て「課題」と呼ばれることがあると思う。筆者が管理していた課題管理表はそのような状態だったので、それらの課題を、管理表上で以下のように分類した。


問題
解決案が想像もできていない課題。

テーマ
長期プランで対応する課題。

調整事項
外部と調整して対応する課題。

調査事項
内部で調査する課題。分析事項含む。

検討事項
内部で検討して対応する課題。決定事項含む。

ToDo
単なる作業、またはすることが明確な課題。

A.I.（アクションアイテム）
ToDoと同義。会議に関係する文脈において使用され、物事を一歩進める意味合いを強めるために使用される。または、会議したことによって明確になったこと、その会議をしたことに意義あったことを強調するために使用される。

リスク
課題となる可能性のあるもの。

mystery
不思議なこと、謎なこと。


もし、課題管理表とは別にToDoリストとリスク管理表があれば、上記の内、ToDoとA.I.とリスクはそちらに移動されていたであろう。

これは7年くらい前に考えたことだが、今見てもまあまあ的を射ていると思っている。しかし、世の中にはそれでは「課題管理」とは呼べない、それでは「課題管理」ができないと言う人々が居る。曰く、「次のアクションが明確になっていないものは『課題』ではなくて『問題』である」なのだそうだ。
課題表の「対策」欄に次に行うべきことを具体的に書けないのなら「課題」じゃないから課題管理表に書くな、課題管理表に記入するのならその対策を具体的な「アクション」に「落とし込」んでからにしろ、という訳である。

「次のアクションが明確になっていないものは『課題』ではなくて『問題』として区別する」という考え方が広く出回っていることは、筆者も知っている。大体、


リスク
まだ具体的な障害になっていないが、障害になり得るもの

問題
具体的に発生した障害

課題
対処すると決まり、対処方針が明確になった問題

ToDo
担当者と期日が明確になった課題


というような定義で、「リスク」の一部が「問題」になり、その一部が「課題」になり、その一部が「ToDo」になる（または、そのように「細分化」／「break down」する）というようにして、「リスク」と「課題」と「ToDo」の区別を明確にしようとか、解決できないままで残る「課題」を発生させないようにしようとする発想によるものだろう。

しかし、このような考え方は机上の空論だと筆者は考えている。その理由は以下である。


  • 大抵、「課題」ではなく「問題」だとして「課題管理表」から除外されたものをどのようにして管理するのかについて言及されない。
    そもそも、「問題管理」などという言葉は見たことも聞いたこともない。課題管理において解決困難な課題が存在するからと言って、難しい課題への対策を考えるのではなく、難しい課題を「問題」と言い換えることによって、「課題管理」だけをやりやすくしようとしているだけである。
    もし「問題管理表」が別に作られたら、それらが「課題管理表」にあった時と同じ問題が「問題管理表」に生じるだけである。

  • リスクマネジメント上のリスクが現実の問題となっても、リスクは依然リスクである。
    あるリスク要因が現実の問題となるのが１度きりとは限らないし、実際には発生しなければそれがリスクでは無かったことにはならない。リスクは課題の確率事象であり、リスクかどうかと実際に発生したかどうかは関係がない。
    リスクが課題管理表やToDoリストに（コピーされたのではなく）移されたのなど見たことがない。もし「リスク」が「問題」にbreakdownできてしまうなら、「リスク」はゼロにできるということになってしまい、リスク管理というものが意味を失うだろう。

  • 次のアクションが明確でなければ「課題管理表」に書くべきでないというのは、上司が部下に対して、問題を報告するなら解決方法も一緒に持って来い、と言ってるようなものである。
    それはつまり、解決方法がわからないなら問題を報告するなということであり、解決方法を考える責任を自分で負いたくないということである。

  • そもそも、通常の会話で、「課題」とか「問題」とかいう言葉を次のアクションが明確になっているかどうかで使い分けることは考えられない。「それは今後の課題だ」「難しい課題だ」と言う場合、対応方針が明確になっていることは稀であるし、「それは問題だ」と言うのは、不正や否定のニュアンスを含むこともある。
    もしアクションが明確かどうかで用語を変えたいのなら、「課題」や「問題」という単語を使うべきではないと思う。（そのような呼び分けに興味が無いので、それらに代わる造語を考える気もしない。）

  • 次のアクションが明確になっているかどうかは、人による。
    能力や権限がある人ならすぐに何らかの行動が起こせる課題でも、人によっては他人に依頼するか、行動を起こす前の準備が必要な場合がある。
    対処できる人に対処する暇があるかどうかで「課題」か「問題」かが異なるのでは、「課題」の定義として適当だとは到底思えない。

例えば、「仕様書の完成が遅れているため、詳細設計に手戻りが生じている」というのは、次のアクションが明確でないから、それは（課題表に書くべき）「課題」ではなくて「問題」であり、「仕様書の完成が遅れている原因を分析してボトルネックを特定する」や「仕様書の完成を急ぐ為、誰々に応援を要請する」は次のアクションが明確だから「課題」だと言う。
しかし、「ボトルネックを特定する」は明確なアクションと言えるのだろうか？なぜ原因を分析する前にボトルネックの存在がわかるのだろうか。単純に担当者の作業量が増加しているのかも知れない。分析してみないとわからないのではないか。もし「ボトルネック」の定義の違いだ、作業遅延の原因となり得るものは全て「ボトルネック」と呼ぶことが可能なのだ、と言うのなら、「ボトルネックを特定する」は「分析する」と同じ意味になり、その文に意味が無くなってしまう。
そして、「仕様書の完成が遅れている」のが課題なら、自動的にその原因の分析が次のアクションに含まれるのではないだろうか。つまり、課題管理表に「仕様書の完成が遅れている原因を分析してボトルネックを特定する」と書かれていても「仕様書の完成が遅れている」と書かれていても、何ら変わりはない。
課題を表す文章が「すること」を表していないから問題、とかいう国語的な話は興味が無いが、日本語の語尾が「〜する」だったら次のアクションが明確だとは限らないし、「〜が無い」とかでも十分に明確なこともあるだろう。むしろ、「課題」管理表に「すること」が並んでる方が、筆者にとっては遥かに日本語として気持ち悪い。

もし、具体的な次のアクションが決まらない限り課題管理表に挙げられないのなら、それまではその「問題」はどのようにして管理する（最低、記録しておく）のだろうか。
ひょっとして、どんな課題でも、即座に次のアクションを決めながら課題管理表に記入できるという前提があるのだろうか。
「課題」は解決の仕方、対処方法が1つとは限らないし、解決するコストが高ければ回避するしかないこともある。そんな場合、その課題は回避すると決まるまで課題管理表に書かないのだろうか。
課題というのは、対策をこれから考えるために、対策が空欄のままでも存在するのが当たり前だと思う。次のアクションが決まっていなくても、課題が報告、管理されないよりは報告、管理される方が良いと考えるのが普通であろう。
それに、次のアクションが明確になっていれば、それは課題ではなくてToDoなのではなかろうか。

という訳で、次のアクションが明確でなければ「課題」ではなくて「問題」だとか言うのは問題のすり替え、問題の先送りでしかないと思うのである。

ちなみに、手元の辞書で「課題」の英訳を探すと、subject（議題）, issue（緊急の問題）, problem（問題）, exercise（練習問題）, assignment（研究課題、宿題）, challenge（やりがいのある課題）, proposition（命題）が出てきたが、筆者が理解した限り、上記のToDo, A.I., リスク以外は全て"problem"に含まれる。つまり、日本語の「問題」と「課題」は英語では区別が無さそうである。