【実践】ロジカルシンキングの基礎、『MECE』で考慮漏れを防ぐ(エンジニア向け)

いきなりですが、現場でこんなミス、やっていないですか?

  • スケジュールに漏れがあった
  • 設計漏れがあった
  • 上司を説得しようとしたら、論破されてしまった

上記のミスは、ロジカルシンキング(論理的思考)を鍛えると、改善される可能性があります。

本記事では、ロジカルシンキングの基礎中の基礎、『MECE』を紹介します。

MECEを知ると、漏れがない設計や、説得力がある説明ができるようになります。ぜひ最後まで読んでください。

この記事で説明することは以下です。

  • ロジカルシンキングMECEの言葉の説明
  • MECEで整理するメリット
  • 具体的なMECEの使い方
  • 注意点

それでは行きます。

用語の説明

用語を説明します。

ロジカルシンキングとは

ロジカルシンキングlogical thinking)とは、一貫していて筋が通っている考え方、あるいは説明の仕方のことである。日本語訳として論理思考あるいは論理的思考と置き換えられることが多い。

ロジカルシンキング-Wikipedhia

つまり、筋道を立てて合理的に考えることがロジカルシンキングです。

MECEとは

MECE(ミーシー: Mutually Exclusive, Collectively Exhaustive)とは「相互に排他的な項目」による「完全な全体集合」を意味する言葉である。要するに「漏れなく・ダブりなく」という意味である。

MECE-Wikipedhia

重複していなく、漏れもないと言う意味です。
身近な例でいうと、日本の四季です。

日本には、春と夏と秋と冬以外に季節がない(漏れなく)し、春と夏と秋と冬は、重複する期間がありません(ダブりなく)。「漏れなく・ダブりなく」なので、MECEです。

MECEを図に示すとこんな感じです。ちなみに、以下のような図をベン図Venn diagram)と言います。

逆に、MECEじゃない例を示します。

性別」は「」と「」だけでは、MECEではありません。これだと漏れがあります。

  • 男性の要素だけを持つ人(男性)
  • 女性の要素だけを持つ人(女性)
  • 男性と女性の両方の要素を持つ人(トランスジェンダーや不定性など)
  • どちらの要素も持たない人(無性)

上記ならMECEと言えると思います。

MECEで考えるメリット

MECEで整理するメリットはたくさんありますが、主にこの3つが大きいと思います。

  • 考慮漏れを防げる
  • 見通しを立てることができる
  • 説得力が上がる

考慮漏れを防げる

MECEで整理すると考慮漏れを防げます。設計漏れや、タスクの考慮漏れは、手戻りの元です。手戻りするとインパクトが大きいですよね。

見通しを立てることができる

MECEで整理すると、見通しが立てられます。

例えば、ある案件のタスクを洗い出すと、下記の3つだとします。

  • A画面の実装
  • B画面の実装
  • C画面の実装

1画面あたり、3人日でタスクを完了できるとします。

もし、上記がMECEならば、9人日ほどで実装完了できる、と言う見通しを立てることができます。


ちなみに、このようにタスクの全量を洗い出して、工数を積み上げる見積方法を積算法と言います。

MECEじゃない場合は?

逆にもし、A画面、B画面、C画面の実装がMECEではない場合を想定します。実はD画面があるかもしれない。C画面の実装は不要かもしれない。という状況ですね。

この場合、1画面あたり3人日で作成できると分かっていても、見通しが立てられないですよね。

したがって、MECEでないと、スケジュールの精度が落ちてしまいます。

説得力が上がる

ロジカルシンキングの本質は、説明です。

ロジカルシンキングで新しいことを考えることはできません。新しいことを考えて、他人に説明するときに、説得力を持たせるためにロジカルシンキングMECEを使います。


余談ですが、アイデア出しなど、新しいことを考える思考法は水平思考などがあります。水平思考で思いついたアイデアをMECEを使って説明する、というような使い方ですね。

MECEの使い道

前述していますが、改めていくつか例を書きます。

  • 説明
  • 設計
  • スケジュール作成、タスク分割(WBS)

MECEを使って、説得力がある説明を

MECEを使って説明すると、説得力が上がります。理由は、すべてのパターンを検討されている、という納得感があるからです。

先に、MECEを使用しない報告の例を示します。

現在、進捗が遅れております。

そこで、作業範囲の変更と、休日出勤をしたいと考えているのですが、よろしいでしょうか。

土曜日は、Aさん、Bさん、Cさんに手伝ってもらい、日曜日は休もうと思います。

これでは、上司は「え、スケジュール変更すればいいんじゃないの?確認した?あと、ヘルプも調整できるし、わざわざ休日出勤は必要なくない?大丈夫?」と、いろいろな心配をしてしまいます。

次は、MECEを使った整理と説明についてです。

タスクが遅延してしまったときに、どうやってリカバリするか、を検討した図を作成しました。

リカバリ方法を検討するロジックツリー

上記の図を見ると、漏れなくダブりなく検討したことがわかります。上記を元に、遅延したタスクのリカバリ方法を上司に報告すると、このようになります。

進捗のリカバリ方法について検討しました。

まず、スケジュールを延期できないか確認しましたが、無理なようです。今からヘルプを投入しても、教育工数などがかかるので、効果的じゃなさそうです。

作業範囲は調整できそうなので、設計が得意なAさんと一緒に、作業範囲の調整をしつつ、残業と休日出勤で本件リカバリしようと思います。

土曜日はAさん、Bさん、Cさんに協力してもらいます。日曜日はみんな休ませようと思います。

漏れなく検討した感があり、普通に説明するより、説得力納得感があるはずです。

MECEでスケジュールを考えて、タスクの漏れを防ごう(WBS)

MECEを使用した有名なスケジュール方法にWBSWork Breakdown Structure)と言うものあります。

タスクをMECEになるように分割していくことをWBSと呼びます。以下はカレーを作るWBSです。

上記のように、第1階層の「カレーを作る」に対して、第二階層の5つの分類は、漏れもダブりもない、MECEの関係になっています。

第2階層も同様で、「買い出し」に対して第3階層の6つのタスクはMECEの関係になっています。

仕事を第1階層、第2階層・・・第n階層まで分割していき、それぞれがMECEであることが確認できる表がWBSです。なのでWBSを使ってタスクを洗い出すと、漏れもダブりもないスケジュールが作れます。

MECEで考慮漏れが少ない設計をしよう(ディシジョン・テーブル)

MECEを使用した設計方法にディシジョン・テーブルDecision table)があります。他にも決定表意思決定表と呼ばれることもあります。

決定表(けっていひょう 英: decision table)は条件と条件にともなう動作を表にした視覚表現である。JISでもJIS X 0125:1986 決定表として規格化している。

決定表-Wikipedia

Wikipediaによると、JIS規格で定義されている設計法のようです。ただし、プロジェクトによって、ディシジョン・テーブルの書き方はマチマチです。個人的にはIBM社の『意思決定表』の書き方が好きです。

例として、「A子ちゃんが選ぶ結婚相手の条件」のディシジョン・テーブルを使って説明します。

A子「ウチは、ブサメンなら、性格が良くて、年収1200万以上ならアリかな。フツメンなら、年収1000万以上はないとムリ。あ、でも、フツメンで性格悪いのはヤだな。イケメンなら性格悪くなければ、OK。あ、でも、イケメンでも年収650万円以上は欲しいかも。」

これをディシジョン・テーブルで表現してみましょう。

A子ちゃんが選ぶ結婚相手の条件

上記がディシジョン・テーブルです。

ディシジョン・テーブルはif文と同じ構造になっているのがわかりますか?この設計書は、そのままコードに起こすことができます。

(読みやすいかはさておき)ソースの構造はディシジョン・テーブルと全く同じになりました。漏れなくダブりなく設計できるだけでなく、コーディングも楽になります。

さらに、ディシジョン・テーブル自体がテスト仕様書にもなります。便利ですね。

MECEで整理できない場合の対処方法

MECEで整理できると、メリットがたくさんですが、注意点があります。

それはMECEで整理できないことが、往々にしてあることです。工程が進むまでMECEと言い切れないことも、多々あります。

そんな時は、「いったん、これをMECEとして進めましょう」と、MECEを仮定して進めます。そして、後から漏れが見つかったら、そのたびに軌道修正しましょう。

まとめ

本記事では、MECEで整理するメリットや、MECEを使ったマネジメントや設計術を説明させていただきました。

この記事で紹介した以外にもMECEを使った仕事の仕方(フレームワーク)はたくさんあります。

知っていると便利なので、皆さんもいろいろ調べてみてくださいね。

参考文献 & 私のおすすめな本の宣伝

本記事は、上司に教えてもらったことと、こちらの本を参考にしています。

以下の本は、MECEだけでなく、若手エンジニアが知っておいてほしいことがたくさんかかれた本です。

  • 技術のこと
  • エンジニアのこと
  • マネジメントのこと
  • ヒューマンスキルのこと

いろんな良書がありますが、一番最初に読むべきは以下の本だと思います。理由は、浅く広くいろいろなことが書かれているので、偏った知識にならないからです。

今後も、本ブログ(TAAKOのブログ)では、下記の本で知った知識を紹介していきます。

では、最後まで読んでいただき、ありがとうございました。

コメントを残す

メールアドレスが公開されることはありません。