新人技術者のためのロジカル・シンキング入門（10） ―― 「工学の知」を実務に生かす

【2】フロー全体を見渡した最適化が必要（1/2）

● MECEというキー・コンセプト

　「客観的な設問を積み上げて問題を切り分ける」というコンセプトを図式化すると，図6のようになります．このような樹形図を描きながら問題点を絞り込んでいくのが，以上のすべての議論に共通して言えることです．

図6　問題を切り分けると樹形図になる
YESかNOかで答えが出る設問を立て，事実に基づいて問題を切り分けていく．これをスマートにfact-based analytical approach（事実に基づいた分析アプローチ）と呼ぶこともある．MECEというのは，この樹形図を作るときのコンセプトである．

　このような樹形図の枝葉を分けていくときのポイントは「無駄なく，漏れなく」です．ロジカル・シンキングの世界では，これをMECE（mutually exclusive and collectively exhaustive）と呼ぶのが一般的です．

● ロジカル・シンキングの限界：MECE分類の落とし穴

　さて，ロジカル・シンキングに関する一般書であれば，「このように論理的に物を考えることは重要であり，従来の日本人にはこの資質が欠けていた．これからのボーダレス社会においては論理的に考えられるビジネス・パーソンが生き残っていくのであり，ロジカル・シンキングは欠かせない」などと結んで終わりになるような気がします．しかし筆者はあまのじゃくなので，ロジカル・シンキングの限界についても考えてみたいと思います．

　組み込みソフトウェア開発の分野で，MECE分類というコンセプトが見かけ上もっともぴったりするのは，なんと言ってもテスト項目の分類です．テスト項目はまず大きく分類し，そこから小さなテスト項目に分けていって，具体的なテストに移ることが多いです^（1）．このように整理されたテスト項目の一覧は，MECE分類の分かりやすい一例と言えるでしょう．

　さて，テスト項目を分類した結果，図7のようなA～Eの機能ブロックに分類できたとします．製品を開発し，テストを終えてリリースした後に仕様変更が入り，Cのブロックを改版したとします．このような場合，Cのブロックに関するテスト項目の再テストのみを行ってほかのテストは省略する，ということがしばしば行われます．

図7　MECE分類の落とし穴
MECEの落とし穴をテスト項目の例で示す．(2)のCブロックに仕様変更があったので，(2)の内部のみテストし直してリリースしたら，今度は①のBブロックの潜在バグが見付かることもある．MECEというのはあくまで物事を分類する一つのコンセプトであり，万能ではない，ということ．

　しかし実際には，Bのブロックにもともと潜在バグがあって，それがCブロックの旧仕様ではたまたま救われていた，ということが起こりえます．つまり，テスト・ケースの階層構造のみに着目してテストの絞り込みを行った場合，テスト漏れが生じる恐れがあります^注1．

注1；「それはテスト・ケースに無駄や漏れがあった，つまりMECEじゃなかったからだ．完ぺきに作られたテスト・ケースならそんなことは起きない」などと言ってMECE分類を擁護する人がいたら，もはやその人は「MECE病」と言えるだろう．

　実際に組み込みシステムを作ってみると，よく設計されたシステムであっても個々の機能ブロックにはある程度の依存関係があります．ブロック間でやり取りするデータのフォーマットがそろっていなければならないことはもちろんのこと，入出力のタイミングなどもハードウェアが関係するときは特に重要となります．もちろん，それらを注意深く設計して製品を作り上げるのですが，仕様変更などが入ると，それが思わぬケースで崩れることがよくあります．設計段階で想定していなかったようなものであれば，テストを考えたときにも見落としているかもしれません．完ぺきに作ったはずの分類でも，分類した細目間に「見えないリンク」^（2）があることは避けられません．そこで，大切なのはむしろ，それを見落とさないようにする工夫です．MECEというのは，あくまで物事を分類するための一つのコンセプトにすぎないのです．