【工事中】論理的思考 5つの基本 － ITへの応用例
注：書きかけですが一旦公開します。
はじめに
記事『論理的思考 5つの基本』で論理的思考の5つの基本（以下、基本1～5）について書きました。本記事では、いくつかのIT基礎について基本1～5を使って説明します。なお、基本1～5の各基本について、基本1、基本2、… と表記します。
皆さんがIT基礎の理解を深め、応用力を高めることに役立てば幸いです。
基礎1：フローチャート
フローチャートだけで論理的に考えるのは難しい
図1-1は、簡単なフローチャートの例です。変数A、Bを宣言し、それぞれの変数に値を入れる処理を表しています。
フローチャートを描く場合は基本3「線でつなぐ」を使います。しかし、ただ単にフローチャートを描くだけなら論理的思考はあまり使えない、と私は考えます。理由は、単に「コンピュータに処理させる順番」にすぎない、言い換えれば、人間にとっって不自然な考え方が必要なため。
もう1つ、フローチャートの例を挙げます。図1-2は、2つの変数の値を入れ替える処理を表しています。なお、変数の宣言処理を簡素化した表記にしました。
図1-2を描く場合も、論理的思考を使いません。フローチャートで学んだ解法（*1）を活用するだけなので。そうでなければ、「値を入れ替える処理」でもう1つの変数（図1-2の場合は変数C）を使うことに気づきにくいです。
*1：正しくはアルゴリズムの解法です。
フローチャートは、アルゴリズムを表記する図法の一つです。
論理的思考を使ってフローチャートを描くためには工夫が要る
図1-1を論理的に考える場合は、たとえば、コンピュータの5大装置で補完する工夫をします。図1-3では、CPUとメモリを補完しています。
この工夫をすれば、基本1「ゴールを決める」に従って、ゴール「変数A、Bそれぞれに値が入った状態」を視覚的に表現できます。それにより、基本2「ゴールから考える」に従って、コンピュータ処理の前提条件（*2）を踏まえながら論理的に考えられます。
*2：必要な値の数だけ変数を用意する、変数に値を入れると上書き
される、など
図1-2を、図1-3と同じように工夫したのが図1-4です。この工夫により基本1〜3を使って考えることができます。
基礎2：構造化チャート
プログラムを設計する際は、フローチャートより前に木構造図などを使った図（＝構造化チャート）を描くことが多いです。様々な構造化チャートが提唱されていますが、ここでは木構造の構造化チャート（*3）を使います。
*3：次の記事を参照。
第３回 構造化技法でプログラムの品質を上げる
可読性の高いメソッドを書くための実践テクニック
構造化チャートの例
説明に使う構造化チャートは図2-1（抜粋元は後述で、会計処理を表しています。
図2-1の構造化チャートを使う大きな利点の一つとして、全体感が分かることがあります。上から順に段階的に詳細化していることも掴めます。たとえば、「取引レコードを処理する」から複数の処理に分かれていることです。基本3「線でつなぐ」を使っているので、論理的に考えやすいです。
ただ、欠点もあります。たとえば次です。
条件分岐や繰り返しなどが表現できない。補足で表記すると煩雑になり、全体感がつかみにくくなる。
処理数が多いと構造化チャートが大きくなり、全体感がつかみにくくなる。
構造化チャートからフローチャートに変換する手間が増える。
アクションダイアグラムに変換した例
私は構造化チャートではなく、アクションダイアグラム（または行動ダイアグラム）を使うことが多いです。アクションダイアグラムを使えば、図2-1は図2-2のように表現できます（抜粋元は後述）。”==”が繰り返し処理の始まり、”-- IF”が条件分岐処理の始まりを表します。
アウトライン化したアクションダイアグラムの例
MS Excelのような表計算ソフトウェアを使ってアクションダイアグラムを書けば、図2-3のようにアウトライにできます（">"はコメント行）。これにより、構造化チャートの欠点が解消します。
アウトライン化できれば、MS Windowsのエクスプローラーと同じ構造で考えられ、基本3「線でつなぐ」を使いやすくなります。論理的思考の精度を高められます。
ただ、残念ながら、アクションダイアグラムは日本ではほとんど知られていません。興味のある方は次の本を読んでください。なお、この本から図2-1と図2-2を抜粋しました。
『構造化プログラム設計：行動ダイアグラム』
（J.マーチン、C.マックルーア／著、近代科学社／出版）
基礎3：エンタープライズアーキテクチャー（EA）
EAとは？
EA（Enterprise Architecture）は、基本情報技術者試験（※）の出題範囲に含まれる基本的な知識の一つです。概要については、次のIT用語辞典をご参照ください。
＜IT用語辞典＞
エンタープライズアーキテクチャ（EA）とは
※基本情報技術者試験（レベル2）シラバス
→ ストラテジ系 大分類7：システム戦略 中分類17：システム戦略
EAは次の4つの要素に分けられます。（説明は上記シラバスより抜粋）
Business Architecture（BA）
組織の目標や業務を体系化したアーキテクチャData Architecture（DA）
組織の目標や業務に必要となるデータの構成，データ間の関連を体系化したアーキテクチャApplication Architecture（AA）
組織としての目標を実現するための業務と、それを実現するアプリケーションソフトウェアの関係を体系化したアーキテクチャTechnology Architecture（TA）
業務を実現するためのハードウェア、ソフトウェア、ネットワークなどの技術を体系化したアーキテクチャ
現状に合わせたEAの考え方
IT化が進み、クラウドサービスの活用が当たり前になった現在、EAを基本どおりに使うのは過剰な場合が多いと感じています。私は、EAを図3-1のように応用し、かつ次の箇条書きのように簡素化して使っています。
BA：ビジネスや業務の視点で検討する
DA：ビジネスや業務で必要なデータモデルの視点で検討する
AA：システム機能（プログラムなど）の視点で検討する
TA：その他基盤等（※）の視点で検討する
※ハードウェア（機器など）や基本ソフトウェア（OS、DBMS、ミドルウェア、など）、プラットフォーム、ネットワーク、など
特にBA、DA、AAの3つを重視しています。それにより、システム要求・要件定義や設計時に基本4「3つ挙げる」を使って論理的に考えやすくなります。具体的な使い方について、基本設計の例を使って説明します。
基礎4：基本設計 その1 － 機能設計
出力用の機能
プログラムを設計する際は、IBM社が提唱した HIPO（Hierarchy plus Input Process Output）のIPOダイアグラム（※）のように、フレームワーク「インプット → プロセス → アウトプット」を使って考えます。
※次の記事を参照。
HIPO図とは？Hierarchy plus Input Process Output設計書の書き方
図4-1aは、このフレームワークを使って表記した注文書を出力する処理概要です。注文データを入力し（インプット）、注文書出力に関する処理をして（プロセス）、注文書を出力する（アウトプット）という流れを表しています。
図4-1aについて、基本1「ゴールを決める」に従って考えると、ゴールは「注文書」です。なぜなら、業務ユーザーが必要なのは「注文書」なので。
次に基本2「ゴールから考える」に従って考え、その注文書を出力するために必要なデータを特定し、基本3「線でつなぐ」に従って線でつなぎます。そして出力処理をつなぎ、最後に矛盾がないことを確認します。
以上を図示したのが、図4-1bです。なお、点線と①～③は思考の順序を表します（以下同じ）。
システム要求・要件定義のアウトプットの一つが「注文書」の要件定義なので、図4-1bのように考えることは理にかなっています。
図4-1bとEAを組み合わせると図4-1cのようになります。前述したEAの基本に合っており、かつ基本4「3つ挙げる」も使えます。さらに、注文データのようなデータはRDB（Relational Database）に格納されていることが多いので、基本5「表で整理する」も活用できます。
図4-1bのように考えることで、論理的思考のすべての基本（1～5）が使えます。結果として、設計の品質を上げやすくなります。
出力用と入力用の機能群
図4-1cにデータ入力画面を追加のが、図4-2aです。基本的な考え方は図4-1bと同じです。
特に着目したいのが、①-1と①-2です。データ入力画面と注文書が、注文データを介して線でつながります。論理的思考の基本に従えば、機能（Process）抜きでゴールとその他を線でつなぐことを優先することが「正しい進め方」になります。
詳しい説明は割愛しますが、この進め方はデータ中心アプローチ（Data Oriented Approach；DOA）の基本的な考え方と合っています。
出力用の機能群
IT技術の発達により、1つのデータモデルから複数の媒体やソフトウェアで活用するのは当たり前になりました。たとえば、図4-1aの注文書以外に3つの画面を追加した図4-3aのような実装ができるようになりました。なお、「BI」はBusiness Intelligenceの略で、BIツールを使った画面機能を表します（以下同じ）。
論理的思考の基本1〜3を応用して、複数の出力機能（ゴール）と1つのデータモデルを線でつなげる考え方が必要になります。
図4-3aの構成のままだと、同じのデータ加工が複数の処理に分散される可能性が高いです。それを避けるためにデータ加工の共通化を図ったのが、図4-3bです。
出力用と入力用の機能群
図4-4aは、図4-3bに（図4-2aと同じように）注文データ入力を追加した例です。なお、出力機能のように複数の入力機能を追加しました。
図4-3bと同様に考えることに加え、複数の入力機能も線でつなげる考え方が必要になります。この場合でも、思考順は図4-2aのように「BA → DA → AA」で変わりません。
【コラム1】基本設計とプログラム設計
以上から、IPOダイアグラムのような考え方と、基本設計で求められる考え方が、大きく異なることが分かります。
プログラマの役割だけでなく、基本設計も担えるようになるためには、論理的思考の5つの基本を使って図4-1cのように考えるスキルが必要です。そうすれば、だんだんと図4-4aのようにシステム全体を考えることもできるようになります。
プログラミングの経験が浅いうちは、IPOダイアグラムのような考え方に慣れたほうがよいと思います。ただ、基本設計を担えるようになりたいなら、論理的思考の5つの基本に沿って考えるスキルも徐々に身につけるのが望ましいです。
【コラム2】実際に論理的思考を使う場面
システム要求・要件定義において、業務ユーザーなどからさまざまな要求が出てきます。ゴールがあいまいなまま進めざるを得ず、徐々にゴールが明らかになってくることが多いです。言い換えれば、先に多くの点（＝要求やデータモデル、処理）が上がり、整合性を取りながら線でつなぐ進め方になります。
基本1～3を使って図4-4aのような図をまとめるのは、システム要求・要件定義の中盤以降になるのが現実的だと思います。ゴールだけ決めて、まったくゼロからゴールから考えて線でつなぐ、ことは少ないです。
【コラム3】BI機能の混在
以前はコンピュータの性能制約によりBI専用のシステムが必要でした。そのため、基幹システム（ERPシステムなど）の技術者とBI専用システムの技術者が棲み分けできました。
しかし、今はコンピュータの性能が上がり、BI機能も使える基幹システムも増えてきました（*4）。それにより、基幹システムの技術者がBI機能に関するスキルも求められるようになりました。
論理的思考を適切に使う場合には、前提条件の最適化が欠かせません。BI機能のように、前提条件は昔と変わります。自分の知識や経験だけに頼らず、常に前提条件の最適化を図ることに気をつけてください。
*4：たとえば、SAP ERPシステムが該当します。SAP ECCまではBI機能が
使えませんでしたが、SAP S/4HANAから使えるようになりました。
SAPコンサルタントの役割も広がっています。
基礎5：基本設計 その2 － 実装方法選択
ウォーターフォール型の進め方（以下、WF）が生まれたのは、コンピュー化が進み始めた頃。各システム開発で使うプログラミング言語は一種類しかない時代（注：DBも使われていなかったので、SQLもなし）。その時代では実装方法が決まっているので、「プログラムでどう実装するか？」の検討に集中できました。その前提で考えられたWFが今も主流に見えます
しかし、今は時代が大きく変わっています。プログラミング言語にSQLを組み合わせることが当たり前になりました。図4-xxのように3つ以上の実装方法を混在させることも増えました。システム要求に対して、システム要件定義または基本設計（の前半）で適切な実装方法を選ぶことが必要になりました。
そこで、基本1〜5を使って実装方法を1つ選ぶ考え方について説明します。題材として、次のシステム要件を使います。なお、SAP S/4HANAのことを知らなくても気にしなく構いません。考え方は伝わるよう考慮したので。
実装方法の案を3つ挙げる
まず、基本1〜4を使い、前提条件を踏まえて実装方法の案を3つ挙げます。
【補足】
ABAP：SAP固有のプログラミング言語。SAP GUIを使う場合に必須。
CDS：SAP S/4HANA用のView。ここではDB Viewと思ってください。
なお、案②と案③なら、図5-2のように（ノーコード・ローコード開発ツールの）SAPクエリと組み合わせられます。案①より難易度が大幅に下がります。
旧来のSAP ERP（R/3やECC）までは案①しか使えませんでした。そのため、案①以外の方法を知らない方がまだまだ多いかもしれません。
その場合は、基本4「3つ挙げる」により「方法を3つ挙げられない」ことに気づけます。追加で調べるなり、他の人に相談するなどして、なんとか3つ挙げます。
実装方法の案を比較評価する
実装方法を1つ選ぶために、3つの案を比較評価します。その際に、基本5「表で整理する」を使って図5-3のように表に整理してまとめます。なお、自分で評価できない場合は、他の人に相談してください。
注：「現在」については後で使います。
この相対評価だけだと、すべての評価が “○” である案②を選ぶのが妥当です。
実装案の再検討
ただ、追加で検討するのが望ましいです。理由は、「現在」とつながる「未来」の視点が必要になるので。表で整理するにとどめず、基本3「線でつなぐ」を使い、さらに検討します。
「未来」に該当する代表的な比較項目として、拡張性や仕様変更対応性があります。今のIT基礎技術であれば、図4-3bのように、Webブラウザやモバイル端末（スマートフォン、タブレットなど）、BIなどへ対応する考慮は必須です。
案③であれば、図5-4のように拡張性などの「未来」を考慮した拡張ができます。しかも、うまくいけばノーコード・ローコード開発ツール（SAPクエリ、SAP Fiori Elements、SAP BIなど）を使えます。
図5-4を踏まえて再評価すれば、図5-5のようになります。案②と案③を比べると、“◯”の数が同じで、”△” がない案③を選択するのが妥当、という判断になります。
元になったシステム要件には「未来」の視点がありません。システム要件どおりに実装する、という考え方は、従来のウォーターフォール型でいえば「正しい」です。それに慣れていれば、図5-3の評価により実装方法を選べばよいです。
しかし、いまはVUCAの時代です。「いまの要件」がいつ変わってもおかしくありません。必然的に「未来」の視点で検討することが私たちには求められます。それがIT基礎を習得する前提になっています。以上を参考に、図5-4のような実装案に気づき、図5-5のような比較評価ができる力を身につけるようにするのがよいと思います。
基礎6：基本設計 その3 － ITシステム全体設計
ITシステム全体を設計する場合も、基本1～3が使えます。A社の商品在庫販売プロセスで使うシステムの設計を題材に説明します。なお、話を簡単にするため、商品出荷業務および直接関連する業務に限定します。
ゴールを決め、ゴールから考えて線でつなぐ
ゴールは次の2つです。
顧客視点 ： 商品を得ること
A社視点 ： カネを得ること ※企業の目的が「Make money」なため
そのゴール（＝債権債務）を、契約書や注文書などの文書を使って明らかにします。
顧客がA社から商品を得る権利（債権）と、A社が顧客に商品を渡す義務（債務）
顧客が商品を得た後にA社にカネを払う義務（債務）と、A社は顧客からカネを受け取る権利（債権）
なお、通常は顧客に商品を渡すと同時または渡した後に請求書を渡すのが慣例です。
以上を図でまとめたのが、図6-1です。
帳票の流れを追加する
大きめの会社であれば、分業化が進んでいます。たとえば、営業部門や倉庫部門、経理部門などに分かれます。それらの部門間や、顧客とA社間のコミュニケーション（指示、伝達など）では「帳票」が使われます。図6-1に注文書や出荷指示書などの帳票、およびその流れを追加したのが図6-2です。
帳票をデータモデルに変換する
会社の業務でコンピュータを使う前は、帳票が3つの機能、具体的には入力機能（＝帳票への記入）、蓄積機能（＝帳票の蓄積）および出力機能（＝帳票の受け渡し）を兼ねていました。そして、業績等を把握するために、定期的（週次、月次、四半期など）に帳票の内容をまとめていました。
世の会社がコンピュータを使い始めた（※）後しばらくしてから、DBの活用が始まりました。その際に使ったのが3つの機能をもつ「帳票」でした。つまり、「帳票」を材料にしてDBを設計しました。
※当時は「コンピュータ化」や「情報化」などと言われていました。
いまの「DX化」と基本的には同じです。歴史は繰り返します。
帳票の蓄積機能に着目すると、図6-2の帳票をデータモデルに置き換えることができます。実際に置き換えたのが図6-3で、データモデルとデータの流れを表せます。
あとは、帳票の入力機能と出力機能を組み合わせます（注：図示は割愛します）。以上で、システム全体設計の土台ができます。あとは、仕様の具体化、実装方法の選択や機能概要設計などを進めて、システム全体設計の精度を上げていきます。
システム全体設計、機能設計とも基本的な考え方は同じ
「帳票」を材料にしてDBを設計する流れは、機能設計で使った図4-1cの①の流れと同じです。論理的思考の基本を使えば、システム全体設計も機能設計と同じように考えることができます。
ただ、設計量の多さと複雑さは異なるので、ITシステム全体設計では工夫が必要です。留意してください。
基礎7：木構造と表（テーブル）
『基礎2：構造化チャート』で木構造の構造化チャートについて説明しました。ここでは、木構造と表の組み合わせについて、次の参考書籍の目次を使って説明します。
＜参考書籍＞
システム設計のセオリーと実践⽅法がこれ1冊でしっかりわかる教科書
（石黒直樹／著、技術評論社／出版）
書籍の目次は木構造
書籍の目次の多くは、木構造になっています。参考書籍の目次も同じです。その目次の一部を、字下げ（＝インデント）を使って木構造を表したのが、図7-1です。
木構造を一覧表に変換する
木構造の階層を一覧表形式に変えたのが図7-2です。題名（1階層目）やCHAPTER（2階層目）の値が重複させるのがコツです。
一覧表を木構造に変換する
図7-2の一覧表をMS Excelで作った後、ピボットテーブルにより木構造に変換できます。それが図7-3です。
木構造は、基本3「線でつなぐ」の応用です。一覧表（の構造）は、基本5「表で整理する」の応用です。それぞれの基本を組み合わせて、図7-2と図7-3のように使えるスキルが実践では求められます。基礎8～9も参考にしてください。
基礎8：業務分析
IT基礎ではないですが、システム要求・要件定義で使う業務分析について、次の1～2の前提で考えてみます。
あるメーカー企業のお客様からあなたに、「国内企業に在庫を販売するシステムを開発したいので、会って話がしたい」と連絡があった。
お客様と実際に会う前に、あなたは必要となる業務プロセスを洗い出すことにした。
業務知識に頼った業務分析の場合
販売業務の知識や経験があれば、「国内企業に在庫を販売する業務」を「国内在庫を顧客に出荷する業務」と、すぐに置き換えて理解することが多いと思います。
しかし、この置き換えだけで十分でしょうか？
根拠が「知識」や「経験」では論理的思考とは言えません。その知識や経験は、あくまで個人のモノであり、相手と合っているか分からないためです。
知識や経験に頼らない根拠を示し、その根拠を補強するために知識や経験を使う、という考え方が論理的思考らしいです。
基本5「表で整理する」を使って業務を分析する
知識や経験に頼らない根拠を示す場合、一般的なフレームワークを活用するのが代表的な方法です。私がよく使うのが、経営の3要素「ヒト・モノ・カネ」です。在庫販売の場合、次のように対応させます。
・ ヒト ：（組織面で）自社、顧客
・ モノ ： 製品、商品
・ カネ ： 有償、無償
この「ヒト・モノ・カネ」を使って、表で整理したのが図8-1です。私はこのような表を「業務分析表」と呼んでいます。
注：色を付けたのは見やすさのため。以下、同じ。
図8-1のような表を使って整理する大きな利点は、次の3つです。
検討の軸（ここでは「ヒト・モノ・カネ」）を決めれば、すべての組み合わせを挙げられる。そのため、検討モレを防ぎやすい。
重複して検討する可能性を大幅に減らせる。
「ー（該当なし）」を示せるため、検討モレがないことを表せる。
※1～3は論理的思考の基本フレームワーク「MECE」を満たしています。
実践では、表で整理するだけでなく、一覧形式も活用する
一般的に使われる「業務プロセス一覧」のような一覧形式だと、この1～3の利点が得られにくいです。それに一覧の行が数10行以上になると、MECEを満たしているかどうかベテランでも容易ではありません。
しかし、一覧形式の利点もあります。代表的なのは、計画や管理（ここでhはコントロールの意）で使いやすいということです。たとえば、全体の工数算出、スケジュール計画、進捗管理、など。
また、表で整理することの大きな欠点もあります。軸や、個々の軸の値が増えると組み合わせの数が飛躍的に大きくなる、いわゆる「組み合わせ爆発」という欠点です。そのため、何らかの工夫が必要になります。
そこで、大雑把に表で整理した後に、次のような一覧表に変換します。
列「該当」を追加するのがコツです。例「該当」があれば、MS Excelのピボットテーブルでクロス表を作成して、図8-3のようにすべての組み合わせで該当有無を示せます。
なお、該当有無が未検討状態なら空欄にしておけば、図8-3にも空欄で表示されます。（皆さん自身でお試しください）
以上のように工夫すれば、計画や管理で便利な「一覧形式」と、論理的に思考／説明しやすい「表形式」の双方の利点を活かせます。「知識と経験」に頼る範囲を減らせ、より効果的な業務分析ができるようになります。
基礎9：デシジョンテーブル
デシジョンテーブルは、システムの挙動指定やテストケースの洗い出しなどで使われます（次のIT用語辞典を参照）。私は、デシジョンテーブルをテストケースの洗い出しで使います。その経験から、IT基礎の一つだと考えています。
＜IT用語辞典＞
デシジョンテーブル（判断表 / 決定表）とは
デシジョンテーブルの例題
なお、上記仕様とデシジョンテーブルは、次のブログから抜粋しました。
＜ブログ＞
『デシジョンテーブルについて調べてみた - RAKUS Developers Blog』
私がデシジョンテーブルを使わなかった理由と原因
実は、私はしばらく、デシジョンテーブルを実践で使いませんでした。大きな理由の一つが使いにくかったことです。図9-1程度なら簡単に分かります。しかし、実践で扱うテストケースは多いのでデシジョンテーブルを書く手間がかかり、基本を守っていられませんでした。
しかし、論理的思考の5つの基本を知ってからは考えを変えました。それらの基本を踏まえることで、デシジョンテーブルの理解度が増したからです。勉強不足だったわけです。
デシジョンテーブルを表で整理しなおす
デシジョンテーブルは、名称に「テーブル」（＝表）と付いています。しかし、基本5「表で整理する」で使う表を使う場合より、思考しにくいと感じています。パッと見だけではヌケモレに気づきにくいので。
そこで、基本5が使いやすい表に変えます。図9-1を変えると、図9-2のようになります。ヌケモレがないことがすぐに分かります。
しかし、図9-2の表にも大きな欠点があります。テストケースが分かりにくくなることです。表が大きくなると、テストケースを列挙する際に誤る可能性が高まります。これでは、論理的思考の基本を使っても効果半減です。
そこで、図8-2と図8-3と同じような工夫をします。たとえば、図9-3と図9-4のように使い分けます（注：図9-1のように表示できないのは残念ですが…）。
このような工夫をすることで実践的なデシジョンテーブルになり、テストケースを洗い出す精度を上げやすくなると期待できます。
まとめ
以上の基礎1～9について、基本1～5の視点でまとめました。
フローチャート
メモリも組み合わせることで、基本1～3を使える。構造化チャート
木構造を使った構造化チャートでは基本3を使うが、
アクションダイアグラムなら基本3がさらに使いやすくなる。EA
EAを現状に合わせて使えば、基本4が使いやすくなる。基本設計 その1 － 機能設計
アウトプットを「ゴール」にすれば、基本1～3を使って適切な機能設計ができる。また、データモデルを設計する際には基本5も使う。基本設計 その2 － 実装方法選択
基本4を使って実装案を3つ挙げ、基本5により表を使って比較検討すれば、適切な実装案を選べるようになる。基本設計 その3 － ITシステム全体設計
基本設計と同じ。木構造と表（テーブル）
基本3の応用である木構造と、基本5の応用である一覧表の両方を組み合わせて考えることが実践的なスキル。業務分析
基本1～5に一般的なフレームワークを組み合わせれば、業務分析の精度を上げられる。
また、一覧表とクロス表を組み合わせれば、業務分析を論理的かつ効率的に進められる。デシジョンテーブル
一般的なデシジョンテーブルではなく、一覧表とピボットテーブルを組み合わせて工夫すれば、テストケースを論理的かつ効率的に洗い出しやすくなる。