[第2回] プログラムレベルのロジック (1)概要編

テストエンジニアが身につけておきたいスキルの一つに「論理スキル」があります。
この連載では、「プログラムのレベル」「文や文章のレベル」に分けて、論理スキルの基本である「論理の言葉」を徹底解説します。

第2回から第4回は、「論理の言葉」の基本でもあり、プログラムのレベルで働く論理の基本でもある論理演算を見ていきます。

連載第1回はこちら
 [第1回] なぜ、テストエンジニアに(も)論理のスキルは重要なのか
［連載初回全文公開中：Sqripts会員以外の方も全文お読みいただけます］

筆者のnoteサイトで、「論理スキル[再]入門」を書こうと思った理由・経緯を綴っています。
■論理スキル・“入門編”のこと　(T3:Pt1:Ch01)
よろしかったらご覧ください。

＜テストエンジニアのための論理スキル[再]入門　連載一覧＞※クリックで開きます

[第1回] なぜ、テストエンジニアに(も)論理のスキルは重要なのか【連載初回、全文公開中】
[第2回] プログラムレベルのロジック (1)概要編
 [第3回] プログラムレベルのロジック (2)解説編・基本の論理演算
 [第4回] プログラムレベルのロジック (3)解説編・論理演算の組合せ
 [第5回] 文レベルのロジック (1)文レベルのAND/OR/NOT

論理演算はソフトウェアエンジニアの必修科目、だが……
論理演算の言葉が重要である理由
具体例
- 忍び寄る“ロジックミス”のごく単純な例
- テストを考える時に働く論理演算
むすび
参考文献

論理演算はソフトウェアエンジニアの必修科目、だが……

プログラミング言語には実行の流れを制御するための条件分岐を司る仕組みが具わっています（簡単に言うとif文です）。

条件分岐の判定箇所にはひとつ以上の条件式を置く（「条件式」は本記事独自の呼称です）
- 典型的な条件式は、値の大小の比較や、等式/不等式。x > 10、y == 0、など
条件式は「真(true。成り立つ、満たす、当てはまる)」か「偽(false。成り立たない、満たさない、当てはまらない)」かどちらかの値を取る
- 条件式の取る値は 真か偽かいずれかのみ。
  また、「真であり、同時に偽でもある」ことはない（真でなければ偽。偽でなければ真）
- この「真」と「偽」を真理値(真偽値)と呼ぶ
判定の真偽で分岐先が決まる

判定箇所で複数の条件式の組合せを扱う場合や、真偽を反転して考えたい場合が(かなり頻繁に)あります。そこで活躍するのが論理演算です。

論理演算とは、真理値を入力として、結果の真理値を出力する仕組みのこと（図2-1）
基本となる論理演算は 否定(NOT)、論理積(AND)、論理和(OR) の三つ（第3回参照）

プログラミングには必須の要素なので、言語の学習には必ず含まれるほか、情報処理技術者試験のシラバスにも含まれています。

が、論理演算は憶えればそれで十分というものではありません(-ω-;)。
その後ずっと秘かにソフトウェアエンジニアについて回り、苦しめる存在です。というのは、論理演算はやりたいことに正しく合わせなければいけませんが、そこで起こるのが“ロジックミス”などと呼ばれるエラー(誤り)です。
（“ロジックミス”のすべてが論理演算の使い方によるものではありませんが、論理演算を誤ると“ロジックミス”に直結します）

論理演算がらみのエラーは、“修行”を積めば犯さなくなる……ということはなく、ベテランでもエラーを犯します(以下、いずれも当社比)。

仕様の記述を「条件を否定したif文にするとロジックをすっきり書ける」と思って、間違える
仕様の記述を“勘違い”したまま設計～実装に落とすこともある
コードをデザイン/実装する時は「正しく解釈した」と思っていても、後でレビューで指摘、あるいはテストで故障が見つかって、愕然とすることもある
まずいことに自分が考えたロジックに自信を持ってしまうと、自分のミスに自分で気づきにくくなる

このエラーを根本的になくす方策はありません（と、筆者は思っていますが）。すなわち、バグの種は尽きないということになります(´・ω・｀)

そのようなバグをできるだけ見つけるためにも論理演算の働きは理解しておきたいところです。

論理演算の言葉が重要である理由

ソフトウェアにとって“ロジックミス”が生じやすい、ということを除いても、

否定、論理積、論理和に相当する言葉は、ソフトウェアの仕様記述のレベルでもよく使われ、仕様を理解する場合やテストを考える際の手がかりになります。
一般的な文章や日常生活で使われる言葉にもあり、人の話や文章の筋道を辿ったり、自分の話や思考の筋道を組み立てたりする際に重要な役割を果たします。

具体例

論理演算が絡む「ロジックのミス」や、テストを考える際に論理演算の知識がどう関係するか、具体例で見てみましょう。

忍び寄る“ロジックミス”のごく単純な例

「利用者の年齢(入力値)が18以上の場合のみ、利用可能。18未満の場合、利用を拒否する(先には進まない)」といった仕様があるとします。

これをプログラム(疑似言語)で書くとこんな感じになりますが：

if age >= 18 then 
 
 　　.... (利用可能な場合のコード)
 
else 
 
 　　... (利用拒否)
 
end if

“>=”と書くところを”>”と書いてしまう、ということが起こります(以降、いずれも当社比)。タイプミスもあり得ますし、「仕様を勘違い」することもあります（もっとも、これは論理演算とは関係ありませんね）。

「利用拒否される場合(18歳以上でない)はそこで打ち切りにすればコードがすっきりする」と考えれば、「>=(等しいか大きい)」を否定してこう書くこともできるでしょう（第3回参照）：

if age < 18 then 
 
  　　... (利用拒否。処理打ち切りで先に進まない)
 
end if
 
... (利用可能な場合のコード)

ここで、<と書くつもりでいて実際には>=のまま、ということが起こりますが、これを論理演算の誤りと呼ぶのも違うかも知れません。しかし、
「>=の否定」を間違えて<=とするということも起こります。
「利用可能でないなら」という表現を“活かそう”と”NOT(age >= 18)”と書くつもりでいて、”NOT”を書き忘れて”if (age >= 18) then …”としてしまう、ということも起こります。

もっと複雑な条件になると、よりいっそうエラーが紛れ込みやすくなります。

ISTQB Foundation Levelシラバス 4.0 の境界値分析(4.2.2)で「開発者はこれらの境界値に関してエラーを犯す可能性が高い」としている通り、ここに挙げた“エラー(誤り)”とその結果としてのバグ(欠陥)は、いずれも「利用可能な年齢」の境界に絡みます。境界値分析はこうしたバグを見つけるのに適したテスト技法です。