ラーメンで考えるMECE

あさこ @acha_821

MECEにやるには、経験が必要そうだな。何事もそうだけど。 で、網羅性を高くするために、他の知識が生きてくる。何かほんと、面白そう！！

みずのり：jack of all trades/freelance @NoriyukiMizuno

@acha_821 どんなロジックツリーがMECEにしやすくて、どのロジックツリーがMECEには難しいか意識してみると面白いですよ。

あさこ @acha_821

@NoriyukiMizuno なるほど！たしかに。非機能系は難しそうなイメージがありますね。 自分が苦手なところが見えてきそう。知識不足なドメインだと、MECE難しいし（当たり前ですね(^_^;)）。色々試したくなりますね！

みずのり：jack of all trades/freelance @NoriyukiMizuno

@acha_821 ちなみに、has-a関係、is-a関係、Whatツリー、WhyやHowツリーでMECEにしやすいものを一回頭の中で整理しておくと良いかもでーす。

あさこ @acha_821

@NoriyukiMizuno おお…ありがとうございます…すごい…

あさこ @acha_821

森崎先生にのレビューのお話をお聞きしたときに、is-a、has-a等を想像しながら聞いたところがある。当たり前だけど、レビューする観点は、テスト観点を洗い出すのにも有効で、第三者の目線をいかに持てるか、もだいじなのかなと思う。 ちゃんと、鏡を見続けないといけない。

みずのり：jack of all trades/freelance @NoriyukiMizuno

MECEのはなし、以下をツリーで整理する違いを考えてみるとか ・ラーメンの分類 ・ラーメンの構成要素の分類 ・ラーメンの種類の分類 ・ラーメン屋を選ぶ観点 ・なぜラーメンを食べるのか

リリカル @mhlyc

僕はトップダウン、ボトムアップを繰り返すだけではMECEなツリーを作ることはできないと思います。MECEにするには何を軸にするかがないといけないし、また軸によってMECEにしやすかったりそうでなかったりもする。

きんぢ @kjstylepp

@mhlyc トップダウンとボトムアップはノード抽出の順序の話で、軸を頼りにふるってのはノードの属性の話で、単に直交する概念なのではっていう気がします。

リリカル @mhlyc

@kjstylepp あっ、すみませんそれはその通りです。 僕が言いたいのは、ノードの属性をMECEに出していくにはなんとなく出すんではなくて軸を意識した方がいいんじゃないかということです。

リリカル @mhlyc

MECEにするっていっても厳密なMECEにするのは不可能なわけで。なんでMECEにしたいの？って言ったら、「MECEになってますよね」ってお客さんと合意をとりたいからで。

あきやま🍠 @akiyama924

@mhlyc そういう理由もあるかもしれませんが、MECEツリーを作る最も重要な理由は抜け漏れを防ぐためです。

あきやま🍠 @akiyama924

@mhlyc MECE を意識しないと初めから可能性を捨ててしまうのです。 たとえば、目玉焼きの作成に失敗してしまったとします。 この時にMECEで分析しないと、玉子が冷えすぎだからだよとか、焼くときのオイルの量が悪いんじゃない？と思い付いたところだけの分析になりがちです。

あきやま🍠 @akiyama924

@mhlyc 今書いた玉子の温度で話を続けるとMECEにしないと「玉子が冷えすぎ」からスタートします。ひょっとしたら冷えすぎどころかもっと冷たい方が上手く目玉焼きが焼けるかもしれないのに。その可能性を捨ててしまうことを玉子の温度をMECEで漏れなくダブり無く分解すると防げます。

リリカル @mhlyc

@akiyama924 なるほど。MECEでない思い込みの論理展開をしてしまうと、可能性を捨ててしまったりするわけですね。 MECEかどうか検討するというステップを踏むことで、他のケースはない？という確認をして観点を増やしているのですね。

リリカル @mhlyc

@akiyama924 MECEかどうかが重要というか、その検討ステップを踏むことが大事なように思いました。

あきやま🍠 @akiyama924

@mhlyc はい。私もそのように思っています。

リリカル @mhlyc

@NoriyukiMizuno @acha_821 横入りすみません。 MECEにするってどういうことだと思いますか？また、MECEにしやすいっていうのもどういうことを言うのでしょうか。どうなるとMECEにできて、どうなるとMECEにできないんでしょうか。質問ばかりですみません。

あさこ @acha_821

@mhlyc @NoriyukiMizuno MECEのゴールは、目的にあるから、MECEであるための理由に起因するんだと思う。 MECEは状態だけど、手段なんだと思う。 なので、ゴールは、テストだと、にしさんの資料40頁に具体例があるように、c0とかがメトリクスになるのかな。

リリカル @mhlyc

@acha_821 c0はたしかにMECEかどうか判断するためのひとつの基準かもしれませんが、それはトップが状態モデルになっているからそういう考え方ができるのですよね。トップがわかりやすくモデルになっていて分解しやすいならよいですが、そうではないことも多いように思います。

あさこ @acha_821

@mhlyc 分解しにくい場合、テスト実装に持っていきにくくない？ 詳細設計のあとには実装があるから、実装できる粒度に落とせる内容であることが望ましいのかしら…すると、モデルはある程度は定義できるんではないかな、と考えているんだけど… そうでもないと、確かに辛いね。

リリカル @mhlyc

@acha_821 トップに何を持ってくるかですが、確かにある程度モデルを定義できないと実装できる粒度への落とし込みが難しいですね...

あさこ @acha_821

@mhlyc @NoriyukiMizuno MECEにできないのは、目的を見失うとき。何をテストしたいのかを考えながらできてないとき。あとは、状態を網羅するので、MECEにできないのは、自分が思い付かない経路がある、って言うときじゃないかな。そこは知識不足…かな。

リリカル @mhlyc

@acha_821 知識があればMECEにできるんですかね？？そこに疑問を感じています。

あさこ @acha_821

@mhlyc ある程度は、かな。絶対は存在しないから、言い切れないのが正直なところ。ごめんね。でも、知識がないと足らないところが出てくると思う。