プロジェクト計画やIT企画を進める中で、「まずは課題と対応方針を整理してください」と言われて、手が止まってしまったことはありませんか？？

いざ考え始めてみると、

何から考えればいいのかわからない
課題と対応方針の関係がうまく整理できない
どこまで具体的に書けばいいのか迷ってしまう

と、課題と対応方針を考えるところでつまずいてしまうケースは現場でも多いです。

やり方がよくわからないまま進めてしまうと、

ソリューションありきの整理になってしまう
困りごとを並べただけの資料になってしまう
レビューで「で、何が課題なんだっけ？」と聞き返される

といった状態になりがちです。「あるあるだな…」と思った方もいるかもしれません。

この記事では、「とりあえずこれを作れば、次の議論に進める」状態を目指して、課題と対応方針のまとめ方を、手順付きで解説します。

この記事でわかること

課題と対応方針の完成イメージ
課題と対応方針を考える手順
書きすぎ・書かなすぎのちょうどいい境界線

なぜ課題と対応方針を作るのか？

まず、プロジェクトを進めるにあたって、なぜ「課題と対応方針」を作る必要があるのでしょうか。

言い換えると、「課題と対応方針」は何のために作るものなのか？という話です。

結論から言うと、目的は大きく次の2つです。

プロジェクト計画時：ゴールイメージの INPUT にするため
プロジェクト開始後：要求定義の INPUT にするため

いずれもポイントは、「次の工程のINPUTにすること」が目的だという点です。

そして、作成するタイミングによって「何のINPUTにするのか」が変わります。

作るタイミングが2回あるので、少しややこしく感じるかもしれません。ただし、2回ゼロから作るというよりは、一度作ったものを段階的にブラッシュアップしていくと捉えると良いです。

① プロジェクト計画時に作るとき

プロジェクト計画書を作る過程で、「課題と対応方針」を整理するタスクがあります。

この段階では、大まかな課題と対応方針が整理できていればOKです。

後ほどブラッシュアップする前提なので、最初から細かく書きすぎる必要はありません。「こんな方向性のプロジェクトになりそうだな」が見えるレベルで、ざっくりまとめれば十分です。

ここで作る「課題と対応方針」は、プロジェクト計画書の「ゴールイメージ」を描くためのINPUTになります。

そのため、

どんな課題を解決するプロジェクトなのか
どんな方向性で解決しようとしているのか

が伝わる程度に整理できていれば問題ありません。

目安としては、PowerPointのスライド1枚に収まるくらいの情報量でまとめるイメージです。こんな感じです。

② プロジェクト開始後に作るとき

プロジェクトが動き出した後は、要件定義フェーズに入る前のタイミングで、あらためて「課題と対応方針」を整理します。

と言っても、プロジェクト計画時に作ったものをブラッシュアップするという位置づけです。

このタイミングで次に控えているのは要件定義（正確には要求定義）です。そのため、プロジェクト計画時よりも一段踏み込んだ粒度でまとめていきます。

スライド1枚では少し足りない
Excelなどで一覧化する

といったボリューム感になることが多いです。こんなイメージです。

フォーマットはこちらからダウンロードできます。

ここで整理した「課題」を解決するために、プロジェクトは具体的に動いていきます。また、ここで整理した「対応方針」をもとに、要件定義を進めていくことになります。

STEP1：背景から課題を具体化する

課題と対応方針を作るタイミングは2回あるとお伝えしましたが、やること自体はどちらも同じです。違うのは、「どこまで細かくやるか」だけです。

ということで、まず最初にやるのは課題をまとめることです。

ここでよくある失敗が、いきなり課題の洗い出しを始めてしまうことです。そうではなく、まずはプロジェクト計画書に書かれている「背景」をベースに考えます。背景に書かれている課題感を、もう一段具体化してあげるイメージです。

この記事では、次のような背景・目的を持つ架空のプロジェクトを例にして進めていきます。

架空プロジェクトのテーマ

背景：

売上は大きく落ちていないが、営業一人あたりの成果が年々低下している
営業現場からは「忙しい」「本来の営業活動に時間を使えない」という声が多い
マネジメント側も、何に時間が使われているのか把握できていない

目的：

営業活動の中で発生している ムダ・非効率を構造的に解消し、営業が本来注力すべき活動に時間を使える状態を作る

このプロジェクトの課題を具体化するにあたって、まず着目するのは 「背景」 です。

なぜなら、背景にはこのプロジェクトで解決したい課題感が要約されているからです。ということで、この背景をもとに課題を考えてみましょう。

今回の例では、「売上は大きく落ちていないが、営業一人あたりの成果が年々低下している」とある通り、営業の生産性に問題がありそうです。さらに、営業現場からは「忙しい、本来の営業活動に時間を使えないという声が多い」ともあるので、営業現場にも何らかの問題がありそうです。

では、現場にどんな問題があるのか？？？

いきなり課題を決めるのではなく、まずは 現状を整理してみます。

提案品質が人によってばらついている
営業プロセスが定まっておらず、人によってやり方が違う

現状を見ると、確かに問題がありそうです。ただし、ここで重要なのは、

見つかった問題を、すべて課題として扱うわけではない

という点です。

課題とは、「理想の状態の実現を妨げているもの」です。なので、これらの問題が今回のプロジェクトの目的を妨げているか？という視点で見ていきます。

まず、「提案品質が人によってばらついている」について考えてみます。理想的には、提案品質は揃っている方が良さそうです。ただし、これは 品質の問題 です。今回のプロジェクトの目的は営業生産性の向上 なので、直接的には関係がありません。そのため、この問題は今回のプロジェクトではスコープ外 と判断します。

次に、「営業プロセスが定まっておらず、人によってやり方が違う」について考えます。理想は、営業プロセスが標準化されている状態です。これは目的と関係がありそうなので、もう一段掘り下げて考えてみます。

ここで考えるのは、現状と理想の「違い」 です。

現状：営業プロセスが定まっていない
理想：決まった営業プロセスに従い皆が動いている

では、この違いはなぜ生まれているのでしょうか？？理由を考えると、「標準的な営業プロセスが可視化されていないから」と整理できます。

これが、課題です。

同じ考え方で、もう一つの背景である「マネジメント側も何に時間が使われているのか把握できていない」からも課題を抽出します（手順は省略します）。

その結果、背景から次のような課題を抽出できました。

標準的な営業プロセスが可視化されていない
生産性低下の要因を定量的に可視化できていない

このあと対応方針を考えやすくするために、業務・マネジメントの観点で課題を区分分けしてみます。

このように、何もないところから課題を考えるのではなく、背景から課題を導くことで、論理的なつながりが生まれます。結果として、プロジェクト全体の整合性も取りやすくなります。

課題が抽出できたら、このように区分を分けて整理します。どの軸で分けるかはケースバイケースですが、AIを使って整理させるのも一つの方法です。

この課題抽出は「なぜこのプロジェクトをやるのか？」という Why に関わる、かなり重要な作業です。特に、要件定義前の段階で行う課題整理には、時間をかける価値があります。

より詳しい課題の出し方については、こちらの記事で解説していますので、参考にしてみてください！

STEP2：解決のための対応方針を考える

課題を可視化できたら、次は その課題をどう解決するか を考えていきます。

ここで書くのは、具体的な対応方法ではなく「対応方針」です。この違いは、とても重要です。

イメージとしては、次のような感じです。

OK：標準化する／見える化する／分離する
NG：◯◯ツールを導入する／◯◯機能を作る

両者の違いは、抽象度です。

対応方針として書く場合は、あえて 抽象度を高めに 書きます。なぜなら、具体的な中身は 要件定義で決める からです。

たとえば、

どのツールを使うのか
どんな機能を作るのか
画面や項目をどうするのか

といった話は、対応方針というより要件に近いものです。

最終的にはプロジェクト内でそこまで考える必要がありますが、このフェーズでやることではありません。

では、先ほどの例をもとに対応方針を考えてみます。基本的には、課題の裏返しが対応方針になるケースがほとんどです。

たとえば、次のようになります。

営業プロセスが可視化されていないので、営業プロセスを作成する。とてもシンプルな対応方針です。

ここでのポイントは、「どう作るか」までは決めないことです。

どんなプロセス群にするのか
どんな形式で可視化するのか

こういった具体は、後続の要件定義で決めます。

次に、マネジメントの課題を見てみます。

こちらも方向性としては、生産性低下の要因を可視化することになりそうです。ただし、よく見ると、そもそも 生産性を評価する指標自体が定義されていません。

指標がなければ、可視化しようにもできません。

そのため、この課題については1つの課題に対して、2つの対応方針が紐づきます。

このように、課題と対応方針は 必ずしも1対1ではありません。

課題1つに対して、対応方針が複数
課題が複数あって、対応方針が1つ

といったケースも普通にあります。

対応方針を考えるときは、方針そのものの内容だけでなく、課題との対応関係にも注意が必要です。

どの課題に
どの対応方針が
なぜ紐づいているのか

この論理構成を意識しておかないと、プロジェクトの後半で「なんでこれをやるんでしたっけ？」という問いに答えられなくなります。

課題と対応方針は、後工程を迷わせないための道しるべでもあります。

STEP3：対応方針の粒度を確認する

最後に、出来上がった課題と対応方針を一度引いて見直し、粒度が細かくなりすぎていないかをチェックします。

たとえば、ここまでで整理した内容は次のようになっています。

このSTEPで、特に注意して見たいのは対応方針の粒度です。要件定義で決めるレベルの粒度になっていないか？をチェックします。

上の例でいうと、「営業生産性をBIツールで可視化する」という表現は、やや粒度が細かくなっています。「BIツールで可視化する」と書いてしまうと、すでに ソリューションに言及している状態 です。

どうやって可視化するのかは、要件定義で検討すればよいこと。そのため、この段階では抽象度を少し上げて、「営業生産性を可視化する」と書き直しておくのが適切です。

このように、「方向性は示すが、手段は決めない」状態にしておくのが、このフェーズのゴールです。

とはいえ、「どこまでが方針で、どこからが要件なのか」は、要件定義を経験していないと判断が難しいのも事実です。そのため、

要件定義の経験がある人にレビューしてもらう
可能であれば、このSTEPから一緒に考えてもらう

といった進め方がおすすめです。

また、要件定義で何をするのかをあらかじめ知っておくことも、粒度判断の大きな助けになります。要件定義の全体像については、次の記事で解説していますので、参考にしてみてください。

まとめ

ここまで読んでみて、「課題も対応方針も、意外と作るのが難しいな…」と感じた方もいるかもしれません。

実際、それっぽくまとめること自体はできます。ただし、後続フェーズにつながる課題と対応方針を作ろうとすると、一気に難易度が上がります。

特に悩みやすいのが、対応方針をどこまで具体的に書くかという点です。方針と対応内容は、似ているようで別物です。

方針とは、

どのような方向性で、対応内容を考えていくのか

を示したものだと捉えると、イメージしやすくなります。

課題と対応方針を考えるのは、プロジェクトのかなり序盤のフェーズです。

この段階では、

まだ見えていないこと
これから決めること

が多く残っています。

だからこそ、最初から細かく決めすぎる必要はありません。このフェーズでは「方向性を示すこと」にとどめておき、具体的な話は後のフェーズで詰める。この考え方を持っておくと、プロジェクト全体が進めやすくなります。

おまけ：よくあるNGパターン

NG① 対応方針から考える

課題を整理する前に、いきなり対応方針から考え始めてしまうパターンです。

たとえば、

「クラウドを使いたい」
「このツールを入れたい」

といった やりたいこと からスタートするケースです。

この進め方だと、課題が後付けになりがちです。

本来は課題ではないものを無理やり課題として設定してしまったり、説明のために課題をでっち上げてしまったりします。

そうなると、「なぜこのプロジェクトをやるのか？」が曖昧になります。

やりたいことの絵は描けますが、投資判断や決裁の場面で説明がつかず、プロジェクトが止まってしまう原因になります。

NG② 課題が困りごとの集まり

課題分析をしているつもりが、現場の困りごとを集めただけになってしまうパターンです。

もちろん、現場の声を聞くことは大切です。ただし、現場の声がすべて正解とは限りません。

プロジェクトには、

実施する背景
達成したい目的

があります。

これらを軸に、「本当に解決すべきものか？」という視点で課題を選び取る必要があります。

そのためにも、

困りごとをそのまま課題にしない
背景から現状を捉え直す
目的の阻害要因になっているかを確認する

というステップが重要です。

NG③ 方針が具体的すぎる

方針と書いてあるものの、中身を見ると 要件レベルまで具体化されている パターンです。

いわゆる、

ソリューション先行
Howに寄りすぎている

状態です。

一見すると、しっかり考えられているように見えます。しかし、その分 手戻りのリスクが高くなります。

プロジェクトでは、工程ごとに確認・レビューを行いながら、段階的に具体化していきます。こうしたチェックを重ねることで、誤った方向に進むリスクを下げています。

最初から具体化しすぎてしまうと、このプロセスをショートカットすることになり、後から指摘が入った場合に、大きなやり直しが発生してしまいます。

課題と対応方針は、後工程をスムーズに進めるための土台です。完璧を目指すよりも、「次に進める状態」を作ることを意識して、ぜひ取り組んでみてください。

関連記事