「リスク、課題、ToDo」の使い分けを今更ながら、あるいは課題のメタモルフォーゼ
13年くらい前、社外勉強会みたいなものに参加していた事がある。会社も年もバラバラな、やる気だけはある人々が集まって、毎回一つのテーマについて色々と議論した。今思えば、そこで勉強したこと自体よりも、「世の中のサラリーマンってこんな感じかー」を体感できたことが有意義だった気がする。僕は小さい会社にしか勤めたことがないので。
そこで一緒に勉強していたおじさま（と言っても今の僕くらいの年かな？）があるとき、こんなことを言い出してびっくりした。「コーチングを受けているコンサルタントから、リスク、という言葉は使用禁止！と言われてるんですよ～」と。
言うまでもなく、ビジネスでも社会でも人生でも、何か未来のことを考える時に、リスクという概念は極めて大事だ。リスクという言葉を禁じるということは、リスクについて考えるなということかな？ずいぶん大胆なことを指導するなぁ、そのコーチ。
ただ、議論していて分かったのだが、その人は「なにか嫌なこと」をなんでもかんでも「リスク」と呼んでいた（禁止されていたはずだが、頻繁にリスクという言葉を使うので、すぐに分かった）。そして「それはリスクですよねー」と言えば、そこで思考停止してもいいみたいな自分ルールがその人にはあるみたいで、確かにこれでは、プロジェクトや事業の計画を立てるのはちょっと厳しいな・・と感じたのを覚えている。
さて、プロジェクトの現場でこういった言葉を適切に使うのは本当に大事だ。リスクや課題みたいに大事な言葉は共通認識を全員で持ち、それに従って粛々と仕事を進める。そうしないと中身に集中できない。言語学的に正解かどうかはどうでも良くて、全員が一致していることが重要。
僕が参加するプロジェクトでは、基本的に僕らの用法に合わせてもらうことにしている。たいていの会社には「スタンダードな用法」がないから、僕らに乗っかってもらうのが手っ取り早いからだ。
僕らの用法を簡単に紹介しよう。
★リスク
定義：将来起こるかもしれない、不都合なこと
将来のことだから、起こるかもしれないし、起こらないかもしれない。でも備える必要があるようなこと。
別途「将来起こるかもしれない好都合なこと」ももちろんある。オポチュニティですかね。良い方についてはあまり事前に備える必要がないので、それほど真剣には議論しない。事業立ち上げみたいな要素が強いプロジェクトなら、オポチュニティを迅速に捉えたいので、明示的に議論するときもある。
リスクにどう対応するかはプロジェクトの肝なので、これまでも何回か記事を書いたし、今後も書くと思うので、ここでは割愛。キーワードだけ書いておく。
・まずは洗い出しはしておきたい
・発生確率×影響度で分類する
・リスク対策1：防止（起こらないようにする）
・リスク対策2：対応（起こった時に慌てないようにしておく）
・リスク対策3：許容（起きたらその時に考える）
・どうでもいいリスクは積極的に許容しよう
・大きなリスクはコンティンジェンシープランを立て、偉い人と共有
・発生確率×影響度は変わるので、たまに見直す
・プロジェクトの稼動前後はリスク管理を綿密に
（稼動判定をリスクベースでやる）
・プロジェクトをやる/やらないの議論では「やらないリスク」も
★課題
定義：解決すべき厄介なこと、意思決定すべき未決事項
リスクが顕在化すると課題になる。また、単にプロジェクトが進捗し、その時点で意思決定すべきことが浮かび上がる時もある。どちらにせよ、その時にプロジェクトで結論をださないといけない事だ。それを課題と呼んでいる。
プロジェクトにとって、課題は極めて重要だ。そもそもプロジェクトは「会社にとって、今、解決すべき課題」を探すところから始まる。例えば「在庫が過剰だ」とか「案件ごとに儲かっているのかどうか分からない」とか。
そういう「プロジェクトにとっての最大の課題≒プロジェクトゴール」が見え、それを解決するための方法（施策）を定める。その施策を詳細化し、実行することこそが、プロジェクトだ。
プロジェクトを実行していく時も、次々と新しい課題が湧いて出る。やったことがない仕事をやるのがプロジェクトなのだから、進むほどに決めるべきこと、厄介なことが出てくるのは当然で、僕らはこれを「課題の1000本ノック」と呼ぶ。課題は嫌がるべきものではなく、積極的に見出し、どんどん解決すべきものだ。
プロジェクトが中盤に差し掛かると、プロジェクトのスピードは事実上、課題が発見され、解決されるスピードと等しくなる。
課題が早い段階できちんと表面に出てこないと、後のほうで爆発する。
課題が未解決のまま積み上がるとプロジェクトは停滞する。
だから、課題リストを作り、ひたすら収集し、解決し、クローズするというサイクルを回しまくる。もちろん課題の件数や解決スピードは監視する。
僕らがファシリテーションを重視しているのは、このサイクルを回すにはファシリテーションという技術が最適だからだ。そしてファシリテーションによってサイクルを高速化できれば、それだけプロジェクトのスピードが上がる。
★ToDo
定義：やること。
課題を議論し、会社として、プロジェクトとしての方向性が決まれば、解決策を明確にできる。それを個々人の仕事までにブレイクダウンしたものがToDoだ。
課題を議論して方向性が固まっても、それをToDoまで落とし込まないと、仕事は進まないものだ。課題の解決策を議論する場に参加していた人でも「あれ、結局あれってわたしがやることになってたんでしたっけ？」みたいな話が起きてしまうからだ。
だから必ず、期限とオーナー（実行に責任を持つ人）を明確にする。
「新会計基準への切り替えについて、経理部から合意を得る。6月末。Aさん」みたいな感じだ。
★ToDo⇒課題
ToDoを決めて順調にそれが実行されていけば楽なのだが、たいていは「ToDoをやろうとしたけど、また問題が持ち上がって進みません！」ということが起きる。そしたらもう一度、課題リストに新しい課題を追加する所からはじめよう。一見、同じ所をグルグル回っているのだが、大丈夫。より小さく、扱いやすい課題になっているはずだから。
こうして、「要件定義フェーズ中に潰しておくべき課題」が全て潰れれば、要件定義フェーズは終了できる。「業務プロトタイプフェーズ中に潰しておくべき課題」が全て潰れれば、業務プロトタイプフェーズは終了できる。稼働前に潰しておくべき課題が全て潰れれば、プロジェクトをGo Liveにできる。
その頃には「将来起こるかもしれない厄介なこと」つまりリスクはほとんどなくなっているはずだ。起きなかったのかもしれないし、起きた上で課題としてぶっ潰し終わっているのかもしれない。どちらにせよ、もう「将来」ではないのだ。
※余談
たまに「課題」と「問題」は意味が違うので、厳密に使い分けるべし！みたいな話を聞きます。僕はプロジェクトでは「問題」という言葉を使わないですね。
「問題の解決策を考えると課題になる」みたいな定義もあるみたいですが、僕は、
解決したい「課題」がある。それを解決する方法が「施策」である。
という用法が好きです。分かりやすいから。これまで全ての現場でこの用法でしたが、混乱したことないです。
問題と課題みたいに、ほとんどの人が正確に区別していない言葉の使い分けを強いるのは混乱の元なので、どっちかを使わないですむなら、そっちの方がいいです。