論点設計

プロジェクトが停滞するとき、原因はタスク不足ではなく、決めるべきことが曖昧なまま作業だけが進んでいる場合が少なくありません。論点設計の目的は、着手前に「この局面で答えを出すべき問いは何か」をはっきりさせ、検討や会議をその問いに集約することにあります。

ここでいう論点とは、たとえば要件定義であれば「移行対象のデータをどこまで含めるか」「既存業務のどの例外パターンを標準化し、どれを残すか」といった、答えが割れうる問いを指します。単なる作業項目（データを整理する、業務を洗い出す）ではなく、判断が必要な問いとして立てるところが要点です。

つまずきやすいのは、論点と作業を混ぜてしまうことです。「〇〇を調査する」はタスクであって論点ではありません。調査の先に「その結果を踏まえて何を決めるのか」を書き添えないと、調べただけで満足し、意思決定に至らないまま次工程へ流れてしまいます。論点は必ず、決裁者が「はい／いいえ」または選択肢から選べる形に落とすと扱いやすくなります。

進め方は、論点の洗い出し、構造化、優先順位づけの順で進めると整理しやすくなります。PMが単独で決め切るのではなく、業務担当者や設計担当を交えて問いを出す段階が起点になります。

• 洗い出し
  関係者から「まだ決まっていないこと」「意見が割れていること」を集めます。付箋やドキュメントに問いの形で書き出し、作業と混ざったものは問いに書き換えます。
• 構造化
  集めた問いを、目的・範囲・体制・スケジュールといった軸で束ね、大きな論点とその下にぶら下がる小さな論点に分けます。上位が決まらないと下位が決められない依存関係をここで見つけます。
• 優先順位づけ
  後続作業への影響が大きく、かつ関係者の意見が割れている論点を先に置きます。影響が小さい問いは後回しにして、会議の時間を重い論点へ振り向けます。

成果物としては、論点一覧に「問い・想定される選択肢・誰が決めるか・いつまでに決めるか」を並べた表がよく使われます。これをキックオフや定例の議題表に反映させると、会議が雑談で終わりにくくなります。つまずきやすいのは、論点を出しすぎて優先順位がつかなくなることです。すべてを同じ重みで扱うと会議が発散するため、いま決めなくてよい論点は明示的に脇へ置く判断が要ります。

論点設計でよく起きる失敗には、いくつかの決まった形があります。どれも進行の途中では気づきにくく、後工程で手戻りとして表面化します。

• 論点の粒度が粗すぎる
  「システムをどう作るか」のような大きすぎる問いは、答えようがなく議論が空転します。移行範囲、権限設計といった判断可能な単位まで割る必要があります。
• 決める人が不在のまま議論する
  論点は出ているのに、その場に決裁権を持つ人がいないと結論が持ち帰りになります。論点ごとに決める人を紐づけておくと、この空転を避けやすくなります。
• 前提の食い違いを論点にしていない
  関係者が別々の前提で話していると、議論がかみ合いません。前提のずれ自体を一つの論点として明示すると、そこから整理できます。

もう一つ見落とされやすいのが、決まったはずの論点が蒸し返される問題です。いつ・誰が・どの選択肢を選んだかを記録に残さないと、後日「そんな話は聞いていない」となり、同じ議論を繰り返すことになります。論点一覧に決定日と決定内容を書き足していく運用にすると、この繰り返しを抑えやすくなります。

論点設計は、課題設定やアジェンダ作成と重なる部分がありますが、対象とする層が異なります。軸を「何を対象にするか」に置いて整理すると違いが見えやすくなります。

• 課題設定との違い
  課題設定は「そもそも何を解決すべき問題か」を定める、より上流の営みです。論点設計は、その課題を解くために「どの問いに順に答えていくか」を組み立てます。課題が定まっていないと論点も定まりにくい関係にあります。
• アジェンダとの違い
  アジェンダは会議で扱う項目の並びで、時間配分に近いものです。論点設計は、その項目それぞれで「何を決めるのか」を規定します。良いアジェンダは、裏に論点設計がある場合が多いといえます。
• タスク分解との違い
  タスク分解は作業を細かくする営みで、実行のための地図です。論点設計は意思決定のための地図であり、両者は補い合う関係にあります。

実務では、これらを切り分けすぎる必要はありません。課題を定め、論点を並べ、それをアジェンダに落とし、決まったことをタスクに変えていく、という流れの中の一工程として捉えると扱いやすくなります。つまずきやすいのは、論点設計を飛ばしてアジェンダとタスクだけを整えてしまうことで、そうすると「決める場」が抜け落ちたまま作業が進みがちです。

論点設計の力は、PMの評価を左右する場面に直結します。進捗管理やスケジュール調整は多くの人が担えますが、「いま何を決めれば前に進むか」を見抜き、決める場を用意できる人は限られます。会議を意思決定の場に変えられるPMは、規模の大きいプロジェクトや上流の検討を任されやすくなります。

転職を検討する際も、この力は語りやすい強みになります。担当したプロジェクトで、どの局面でどんな論点を立て、どう合意へ運んだかを具体的に語れると、単なる進行役ではなく判断を前に進める人材として伝わります。ITコンサルや上流工程への移行を考える場合にも、論点設計の経験は接続点になりやすい領域だといえます。日々の定例や要件定義の場を、論点を立てる練習の場として使ってみることをおすすめします。

論点設計はいつやるのが良いですか

各工程の入り口で行うと効果が出やすくなります。キックオフ前、要件定義の開始時、設計フェーズの切り替わりなど、これから何を決めるかが問われる局面が適しています。一度作った論点一覧も、状況の変化に合わせて随時見直すと、決め残しを防ぎやすくなります。

論点と課題は何が違いますか

課題は「解決すべき問題」そのもので、論点は「その問題を解くために答えるべき問い」です。たとえば業務効率化が課題なら、どの業務を対象にするか、どこまで自動化するかが論点になります。課題が上位にあり、論点はそれを分解した意思決定の単位だと捉えると整理しやすくなります。

論点が多すぎて絞れないときはどうしますか

後続作業への影響の大きさと、関係者の意見が割れている度合いの二つを軸に並べ替えると絞りやすくなります。影響が大きく意見も割れる論点を先に扱い、影響の小さい問いは明示的に後回しにします。すべてを同じ重みで扱わないことが、会議の発散を抑える助けになります。