kozawa のたまに気になること

リンクの少ないでもぶろぐ・・・にせぶろぐ?
スポンサーサイト

一定期間更新がないため広告を表示しています

| - | | - | - |
デシジョンテーブルでMECEをニッチに突き詰めたら実は奥が深いかもしれない話

この記事は、主にITシステム設計書書きな人な気がしまして、それ以外の人にも役に立つことがありますが、なにぶんニッチです。ななめ読みしてか
もっというとフローチャート脳な人向けの記事かもしれません。

さて、デシジョンテーブルとは何ぞやというと、デシジョン・テーブルを活用するのようにいい記事がありますので、そこを読んでもらうとよいでしょう。

例えば、設計書で「この場合はこれをやって、この場合はこれをやる」みたいな話、まぁ条件と結果が1対1とかなら、いいんですけど、これが複雑になった場合、「人間が読む文書」として、網羅性とかそういうのを見落としやすくなるんですよね。目でチェックの漏れが起きやすい。手続き型言語プログラマーやフローチャート脳の人が設計書を書くとif-elseのように

1)何々ならば
1−1)何々する
2)何々でなければ
1−2)何々する
みたいな設計書を書きがちです。
このぐらいならまだいいんですけど、組み合わせやifの階層が深くなると、以下のようなデシジョンテーブル的な表現の方が組み合わせと結果の組み合わせの誤りをチェックをしやすくなります。デシジョンテーブル、素敵です。
場合分けについての、漏れとか重複とかのミスを防ぐ方法の一つとして使えます。

で、ここからが、私が気になっているもっとニッチな話になります。

デシジョン・テーブルを活用する の最初の例を見ましょう。これでいうと条件記述が3つで、すべてYesとNoだけの値を取っています。
この例の場合、「レンジ時間セット」と「トースト時間セット」は同時には成り立たないという前提で書かれています。読み手がそれを誤解する恐れがないときはこれでもいいのですが、網羅性の漏れチェックを容易にするという観点から私が推奨したい記述方法の解説を始めます。もちろん、こういうのはドキュメントの目的次第ですがそれは大前提として…。

まずは網羅性や重複などがないことを重視します。
デシジョンテーブル記事図0
しかし、これに厳格にこだわると、条件の数が増えた時
1)条件記述が多い時
2)条件指定の値の種類が多い時
に全部の組み合わせを入れるととんでもないことになり、結局「人間の目じゃ見てらんないよ」という点において大差ないじゃないか、ということになると思います(条件部分の場合分けの漏れや重複の排除だけならロジカルに並んでさえいれば根性でチェックする余地はありますが、動作記述部が合ってるかを他の条件との関連を見ながらチェックするなどを考えると絶望的になると思います。特に動作記述部分の内容が条件毎にある程度関連があって離れた行同士で規則性があるような場合とか、見るのが大変です。 ※余談、プログラムでチェックするとか、Excelのフィルタでチェックするのであって目だけで見るわけじゃないよ、という方向の解決策を探すなら以下の話はあまり関係がなくなります)。

そこで、条件部のミスしなさと表のサイズ爆発防止をいい感じで両立する方法はないか、といった時、例えばこういう書き方もできます。今回の例の表だと、結果的にこのように書き換えても意味が同じになります。
デシジョンテーブル記事図0.5
※ここでこっそり「不問」という表現を入れてあります。これは便利な簡略化方法で有用だと思います(-とか他にも記法はありますが、「不問」が誤解の余地が少なくて個人的お勧めです)。
デシジョンテーブル記事図1

これの欠点の一つとして、条件記述の並び順をかえてしまっているので、逆に見づらくなっている面があって万能ではないのです。が、ひとまずこの方法を使った場合の話を続けます。また、こういうまとめ方は表の改定容易性を下げている側面もあると思いますがそれも脇におきます。

さて、次が「条件指定の値の種類が多い時」の問題です。ここで「レンジの生産工場」を追加の条件とし、実は工場は100以上ある、とします。
デシジョンテーブル記事図2
元の定義通り全部書いてると、表がすごいことになります。もちろん、それでも書いておくべき名ことというのはあるので、その時はそういうものとして対処を考えるしかないですが妙案はここにはありません。しかし、「漏れもダブりもない」ことをチェックするだけでも大変で、その上で、それぞれ全部についての他の項目や結果との整合を確かめるのも涙目です。
これを、工場が100個あるとはいえ、いくつかのグループに分けることができる場合、見かけの見通しは少しよくなります。まとめた場合、それぞれが一グループであることの正しさも見なければいけないので、一長一短ではあります。※少し乱暴に言えば、技術者よりの人がみる仕様書的なものや辞書的なものなら全部個別記述してなんぼでしょうし、業務の場合分けなどは、これとこれが同じ、と固められて見えることのメリットは大きいと思います。
デシジョンテーブル記事図3

ここで、こういう記述もあり得ます。
デシジョンテーブル記事図4
条件「レンジの生産工場」に項目の漏れがないということは割と容易にわかります ※記述された仕様全体として正しいかはまた別ですが、一覧性がいい方が全体をチェックしやすいので、そこにメリットがあります。
業務の仕様書で条件記述(今回の表で言う条件の縦の個数)が多数のものだと、しばしばこういうのがあります。
「商品の品番コードを条件とする」みたいな場合には、どうしてもホワイトリストで網羅することができず、「〜以外」を条件に入れないと網羅性に問題があることがあるので、今回の私がこれを書いている目的では「〜以外」は積極的に使うべきという発想になります。もちろん、網羅性が自明である時はあります。レンジ時間でYとNの二値であるのが自明なのに「〜以外」の出る幕があるのかと言われると、この場合は要らないと思います。しかし、大量のドキュメントをこの方式で統一しようとするときっと「どれが自明でどれが自明でないか」悩む場面には結局出くわすと思います。特段これにいい解決法とか思いつかないので、「〜以外」はなるべく使う方向でがんばって悩みましょうという程度にします。
この「〜以外」の一つの欠点は上記の「ABC」と「ABC以外」ぐらいだとたいした問題はないのですが、このリストが長くて複雑な場合、表のメンテ性が低下してしまいます。「1〜10」「13〜18」「21,25,29」に対して「1〜10,13〜18,21,25,29以外」とかだと、曖昧性はないけれど、二重記述による記述誤りのリスクが増えてしまいます(読むのも長くて鬱陶しいしその誤りがないかをチェックする負荷も高いということになる)。

「〜以外」の二重記述からの回避方法としては「左記以外」などというのもあります。これはこれで便利なのですが、「〜以外」の導入が結局別の問題を発生させる例が出てきてしまうので、次はその話です。
まずこの例だと、うまく行きそうな気がします。
デシジョンテーブル記事図5

しかし、こちらの例だと、問題があります。
デシジョンテーブル記事図6 「左記」が指定する範囲がわかりにくいのです。今回私の使っている階層構造の条件表記だと、最上位の条件では誤解の余地がほぼないのですが、二段目以降に使うと途端に問題が起きます。
まぁこれも、読み方を以下のように上の段で絞られた範囲とする、などと定義することで回避することも可能は可能ですが、誤読誘発の恐れは増えます。また、「このルールに従ってみんなで書いてね」という標準化に使うと、このルールが徹底されないでめんどくさいことになるリスクは、ここまで書いてきた他のルールと比べても高いのではと推定します(経験談を元に可能性を推定しています)。
デシジョンテーブル記事図7

今回のお題はひとまずここまでです。もっとこれが何を言わんとしているのかもっと明瞭に伝えるには「一見大丈夫に見えるけどMECE的に間違ってる例」や「一見大丈夫に見えるけど解釈に揺れの余地がある誤解を招く例」を例題として色々作って演習問題にするのが一番よいのかもしれないなぁと今更思っています。もっと分かり易く書けば有用度が上がる記事になるのになどと思いつつ今回の品質で妥協して公開します。

まとめると(話を蒸し返しているのですが)、冒頭にリンクした記事でも仕様の記述の明確化の手段としてデシジョンテーブルを紹介しています。
私の問題意識もそこで、しばしばエンジニアは設計書にフローチャート式だったり、if分岐の羅列で書いてしまうのです。これが、ロジックが正しいのかを非エンジニアの人間がチェックするのが難しくなるのでは、それを比較的容易にしたいという方法の一つとしてデシジョンテーブルを持ち出しています。エンジニアでもif分岐の羅列だと、MECEのチェックやロジックの正しさのチェックは結局難しくなります。
仕様記述書の書式として、作業者(ワーカー/PG)にこの方式を強いることでフローチャート/if文式より、「レビューしやすい」設計書ができるのでは、ということです。
ただ、ここまでに色々書いてきて「この場合はうんたら」というのがいくつか出ています。書きたいものが何かによって最適な表はきっとかわります。杓子定規にルール化して守らせると、場合によってとんでもない不自由な表が出来上がりかねません。この辺に標準化ルールとしてのデシジョンテーブル表記法工夫の限界があります。都度表記の利点と限界を加味して工夫してコンパクトにまとめればもっとも都合がよいのですが…。

| pc/net | 08:30 | comments(0) | trackbacks(0) |
スポンサーサイト
| - | 08:30 | - | - |









http://kozawa.jugem.cc/trackback/573
Firefox3 Meter レビュープラス
   1234
567891011
12131415161718
19202122232425
2627282930  
<< November 2017 >>
+ NEW ENTRIES
+ CATEGORIES
+ ARCHIVES
+ LINKS
+ PROFILE