デシジョンテーブルを作成して上流工程の抜けモレ対策に使う
今回は、管理人の身近で起こった出来事からピックアップします。設計書のレビューをしていたのですが、重大な要件モレが発覚しました。抜け・モレ対策の記述をしていなかったのです。
これは、管理人の指導不足だと思いまして、当人に条件の書き方について説明した次第です。みなさんはそのようなことはないと思いますが、そのときに説明した内容を記事にしてみます。デシジョンテーブル（決定表）の作成方法です。
上流工程で抜け・モレがあると後工程が大変なことに
人間が作るものなので、どうしても抜け・モレは発生してしまいます。
笑って済ませられる話ならば良いのですが、業務上で発生するといろいろと面倒なことが起こります。
特に上流工程（要件定義・概要設計など）での抜け・モレが発生すると、後工程で非常に大変な思いをしてしまいます。
なぜ、モレ・抜けが発生してしまうのか？
なぜ、モレ・抜けが発生してしまうのでしょうか。
今回管理人のプロジェクトで発生した事象は、次のような内容でした。
- 上流工程（外部設計）にて、ある区分の組み合わせパターンがもれていた
- そのため、まるまる、その条件に該当する処理が設計されていなかった
外部設計レビュー時に発覚したので、それほど大きな手戻りではないのですが、それなりの影響範囲がありました。よくある話です。
防ぐ方法はあるのか？
よくある話で済ませてしまうと、この先また同じことになりかねません。このような組み合わせの抜け・モレを防ぐために何か方法がないのでしょうか？
あります。デシジョンテーブル（決定表）というものです。ご存じの方も多いかと思います。
デシジョンテーブルの説明の前に
そもそも条件を記述する場合に「自然言語」で「箇条書き」で、書いている設計書を見かけます。
これをやめて、表形式で表現するだけで、抜け・モレが減ります。デシジョンテーブルとまで行かなくても有効です。
2次元くらいの組み合わせであれば、事足りるでしょう。これは、みなさんも使いこなされているはずです。
設計書を書くときの標準化のひとつにあげておいてもよいでしょう。レビューをする場合、レビュアーは「条件が箇条書きになっていないか」も確認することをお勧めします、というか必須ですね。
デシジョンテーブル（決定表）とは？
デシジョンテーブル（決定表）とは、テスト技法の書籍などによく出てくる手法です。
当然ですが、上流工程でも有効です。100%漏れがなくなるとはいえませんが、かなり有効だと管理人は考えています。意味は次の通りです。
デシジョンテーブルとは、複数の判断条件の正否の組み合わせを列挙し、それぞれの場合についてどのような判断を下すかを一覧にまとめた表。
デシジョンテーブルの構成
デシジョンテーブルの構成は、このような表のイメージです。
条件記述部
プログラムなどが動作する条件を洗い出し列挙します。
条件指定部
条件記述部に対して、指定する条件を入れます。次のような記号を使用します。
- Y：Yes
- N：No
- 語句、値またはコード
- ―：無関係、または起こりえない
動作記述部
条件の組み合わせを満足したときに動作する内容を記述します。
動作指定部
動作記述部に対して、動作を指定します。次のような記号を使用します。
- X：条件指定部を満足したときに動作する
- 語句、値またはコード
- ―：無関係、または起こりえない
デシジョンテーブルの使い方
複雑多岐にわたる項目の組み合わせを表現する場合に、抜け・モレを減らすために使います。
これを使えば、組み合わせパターンはすべて作れるはずです。（この後の問題で触れます）
2次元の表形式では書ききれない条件に対して、組み合わせを網羅するために使用します。
できれば、条件の組み合わせはシンプルであるべきなのですが、どうしても業務上で必要な場合に使用してください。
まず考えるのは、「どうすれば、条件をシンプル化できるか」に注力することを、忘れないでください。
デシジョンテーブルの作り方
作り方はいたって簡単？ です。次の例で作成してみます。条件は3つあげてみます。
条件1（性別）
- a:男
- b:女
- c:その他
条件2（年齢区分）
- W:0～29歳まで
- X:30歳～59歳まで
- Y:60歳以上
- Z:その他
条件3（既婚）
- 1:未婚
- 2:既婚
- 3:その他
ただし、条件に使用する項目の内訳に抜けモレがあると終了なので、各項目の内訳の吟味は十分に行ってください。
ここでいう項目とは、「条件1（性別）」の内訳である「a:男、b:女、c:その他」です。ここで抜けモレがあると、デシジョンテーブルをつくっても一からやり直しになるので注意してください。
条件記述部をつくる
例では、条件が3つあります。下図のように縦に並べてください。
条件指定部をつくる
ここで条件指定部を作りますが、コツがあります。「総数はすべての条件の内訳の組み合わせ」ということです。
この例では、「条件1＝3個」、「条件2＝4個」、「条件3＝3個」なので、3×4×3＝36パターンが「総数」です。
条件記述部に対して、横に総数36個の列を並べます。これが条件指定部です。
条件指定部の記述
総数を求めたら、次は各条件を入れていきます。ここもコツがあります。
条件1をセット
- まず、総数を条件1の個数で割ります。
- 「総数：36」÷「条件1の個数：3」＝12 … (1)
- 条件1の各項目は、それぞれ12個ずつ入れていきます。
条件2をセット
- 次に、先程求めた総数÷条件1の個数の商を使用して、条件2の個数で割ります。
- 「(1)（先程求めた総数÷条件1の個数の商）：12」÷「条件2の個数：4」＝3 … (2)
- 条件2の各項目は3個ごと、条件1の個数1つを構成します。
条件3をセット
- 同じ要領で、最後の条件3を求めます
- 「(2)：3」÷「条件3の個数：3」＝1
- 条件3の各項目は1個ごと、条件2の個数1つを構成します。
ここまで作成すれば、各条件の組み合わせが完成します。漏れはないはずです。
動作記述部を追加する
次に、各条件の組み合わせで発生する、動作部分を記述します。
例として、動作が2つある場合を想定します。
最後に動作指定部を記載
条件と動作の組み合わせができれば、あとはこのまま実装・テストが可能です。これを、箇条書きなどで表現しようとしたら、何が正しいのか判断することは非常に困難です。
利用者向けの説明書などでは工夫する点はありますが、設計書レベルであれば十分でしょう。
デシジョンテーブルの課題
よい事尽くめのようなデシジョンテーブルですが、いくつかの課題があると感じています。「作り方」で記載しましたものも含まれますが、以下の3点が管理人の考える課題です。
- 条件の内訳に漏れがあると、意味がなくなる（抜けモレのまま）
- 組み合わせが膨大になり収拾がつかなくなる（人間の理解を超えた量になる）
- 作成したはいいが、テストで死ぬことになる（組み合わせの整合性を担保できない）
まとめ
「抜け・モレ対策」に関する書籍やウェブサイトは多数あります。今回取り上げたデシジョンテーブル（決定表）は、そのうちのほんの一例です。
ただ、小難しい技法だったり、本当に使いこなせるのかよくわからない方法論もあったりで、さくっと現場で使えるものは少ないような気がします。
とにかく、「条件の抜け・モレ」は、設計工程以降でリカバリーする場合、数十倍のコスト増・期間増が発生してしまう可能性が濃厚です。さらに、急遽突貫で設計～製造を行うことで、品質低下も危惧されます。
プロジェクトメンバーはもとより、お客様も含めて「条件の抜け・モレ」の対策を打てるよう、プロジェクトマネージャは考えていく必要があるな、と管理人は感じています。
本記事を参考にしてもらえればありがたいと思います。
最後に、図表が小さいため見づらくなってしまったことをお詫びします。