アシスタントディレクターの髙見です。
今日は「MECE」について書きたいと思います。

MECEとは？

MECEは「ミーシー」と読みます。（「ミッシー」と読む派も？）
「Mutually Exclusive and Collectively Exhaustive」
の頭文字を略した言葉で、日本語訳すると「漏れなく、だぶりなく」「過不足なく」という意味になります。

MECEはロジカルシンキングの基本となる考え方です。
「モレなく、ダブりなく・・・そりゃ大事だよね」と簡単に感じるかもしれませんが、
意識していないと、意外と「モレあり、ダブりあり」になることはとっても多いです。

「モレなく、ダブりない」状態とは？

例えばアプリの利用ユーザーを分析するため、年齢で分けてみましょう。

①の場合、「10代・20代」だけではそれ以外の年齢のユーザーが漏れてしまいます。
②の場合、「社会人・学生」という軸を増やしてしまったことで
「20代」にも「社会人」にも該当するダブりのユーザーが発生してしまいます。
③のように、全ユーザーを「モレなく、ダブりなく」整理するのがMECEな考え方です。

上記の図は極端な例ではありますが、IT開発の現場でも
・要件定義をするとき
・改修箇所を洗い出すとき
・テスト仕様書を作るとき
・不具合報告をするとき
・議事録を書くとき
・・・など、あらゆるシーンでMECEを意識することができます。

具体例①：案を比較しよう

要件を考えているときに、色々な案がでてきて、
それぞれのメリット・デメリットを比較するシーンはよくあると思います。
こういった情報を比較するときにも、MECEに整理することは大切です。

例えば、案がいくつかでたときに、以下のように出てきたままに箇条書きにするだけだと、
「結局、①②③のどれがいいの？」と判断がしづらくなってしまいます。
さらによく読むと、”スケジュール”について触れている案と触れていない案があったりと、
情報に過不足があります。

この例をMECEにする為に、
それぞれの案を検討してきた中で出てきた観点（費用、ユーザビリティ、スケジュール）を
並べてみて、再度それぞれの案で当てはめ直してみましょう。

上記のように整理することで、
「そういえば、案③は、追加費用は要らないんだっけ？要るんだっけ？」と
曖昧になっていた部分もすくいとることができます。
さらに、「そもそもスケジュール遅延はNGだから案①はないな」などと、
どの観点で判断すればよいか、線引きや判断軸も見えやすくなります。

具体例②：テスト箇所を洗い出そう

例えば、
「ネットワークエラーの時のエラーダイアログが、出る画面と出ない画面がある。
また、でてくる文言が、合っている画面と間違っている画面がある。」
という不具合があったとします。
その修正結果をテストする場合、どのように報告するのがよいでしょうか。

↑このように報告しては、何をもって「◯」「×」だったかが分かりません。
「全画面漏れなく見たのか？」「どの画面が×だったのか？」と疑問が湧きますよね。

今回の場合、
・確認する観点はそれぞれの画面で2つある（出ているか・文言が合っているか）
・全画面で確認を行う
・i/Aそれぞれで確認を行う
ということを網羅すると、例えば以下のような形式になります。

こうすることで、
「どの粒度で確認をした結果、どこが◯で、どこが×だったか」が明確になり、
他の人が見た時や、後で自分が見返した時にもわかりやすくなります。

まとめ

いかがでしたでしょうか。
簡単なようで意外とできていないことが多いMECEな整理の仕方。
私もまだまだ修行中の身ですが、、、
情報をまとめる上で、「文字に起こす、並べる、表にする、絵にする、、、」ということは
とにかく意識して、練習していきたいです。
４象限でまとめてみるのもいいですよね！
無意識にできている人も多いと思うMECEな考え方、改めて意識してみるとより品質が高くなるかも？