こんにちは！
今回はメリデメ表の考え方・作り方についてご紹介します。
メリデメ表は、プロコン表とも言われますね。
基本的な内容ですが、民間企業も公務員もよく作成するものですし、仕事のご参考にしていただければ幸いです！
ちなみに、メリデメ表/プロコン表を使ってケース問題を解いていますので、使用例のイメージを持ちたい方は、以下の記事も併せてご覧ください。
では、いきましょう！
筋の良いメリデメ表のフォーマット
メリデメ表には、良いものと悪いものがあります。
上記の図のように、悪いメリデメ表は「単純にメリット・デメリットで評価軸を切っているもの」です。
一方で、良いメリデメ表は、「”観点”で評価軸が切られているもの」です。
これの良い点は、
- どんな観点で比較しているかわかりやすい（読み手に優しい）
- 評価軸に抜け漏れがないか議論しやすい
などが挙げられます。
メリデメ表の作るプロセス
作るべきメリデメ表のフォーマットが決まると、そこから逆算して検討すべき要素が決まってきます。
1つ目は「選択肢」の部分、2つ目は「評価軸」の部分、３つ目は「交点」の部分です。
特に「選択肢」と「評価軸」の部分は、MECEを意識しながら網羅感を出すことになります。
「選択肢」の部分の洗い出し方はケースバイケースですが、
「評価軸」については典型的なパターンが２つあるので、覚えておくと便利です。
一つ目は、打ち手を評価するときの、”効果と実行可能性”というものです。
実行可能性の細目には、費用や所要期間のほか、法律の制約などが入ってきます。
もう一つは、問題を評価するときの”深刻度と改善余地”というものです。
改善余地は、「改善の容易度」と言い換えてもいいです。
深刻度が高く、かつ、改善余地が大きいものから順番に対応します。
例えば、レストラン企業にとっての「立地地域の人口減少」問題のような、深刻度が高くても企業では改善余地がない問題（＝打つ手がない問題）は、基本的に放置するしかありません。
システムに不具合が出た際などで、どれから問題を潰すか検討する時にこの評価軸をよく使う気がします。
その問題が引き起こす問題の「深刻度」は、「影響内容」と「影響人数」に分けて考えたりします。
影響内容は、例えばシステムの不具合を整理するケースでは、利用できなくなる類の不具合なら”大”、操作性が悪くなるが利用は可能な不具合なら”小”など、一定の基準を持って設定していきます。
ただ、不具合の内容が酷くても、その不具合の影響を受ける人数が少なかったら対応の優先順位を下げたりします。
そして、「深刻度」が高く、かつ、「改善余地」が大きい（＝改善しやすい）問題から優先して対応していくことになります。
MECEについては以下の記事で解説しているのでご参考にいただければ。
評価軸のウエイト
まずは以下のメリデメ表を見てみてください。
何か違和感はありませんか？
おそらく、
「ユーザーニーズの充足度」で優れている”打ち手１”が、「A部長への説明難易度が高い」という理由で総合評価が並になっている…。
「A部長への説明」って内部の話だし、「顧客のニーズ」を優先するべきでは？
「ユーザーニーズの充足度」と、「A部長への説明難易度が高い」を同列の評価軸として扱っていいのだろうか？
と思ったのではないでしょうか？
実際にメリデメ表を作成していると、このような疑問を持つケースが出てきます。
その場合は、「重要度」や「優先度」という欄を設け、評価軸自体に優劣をつけると良いです。
現場用と幹部説明用
これも実務上の観点ですが、重要な事項についてメリデメ表を作成すると、「選択肢」の部分も「評価軸」の部分も膨大なボリュームになる時があります。
特に公務員などの仕事の場合は、「この観点の検討は不要だろ」と割り切ることは現実的に難しく、検討を進めるにつれてどんどん観点が細かくなる傾向にあります。
とはいえ、大臣や知事など幹部説明で使うメリデメ表に細かいものを出すわけにもいきません。
そういう場合は、現場用のメリデメ表と、幹部説明用のメリデメ表をそれぞれ作りましょう。
つまり、
- まずは現場用の細かいメリデメ表を作成し、緻密に検討し、
- その後、重要な選択肢・評価軸だけをピックアップし、サマリーのような形で幹部説明用のメリデメ表を作成する
という形が良いと思います。
おわりに
いかがでしたでしょうか？
普段のお仕事のご参考になれば幸いです
