論理スキル・“入門編”のこと (T3:Pt1:Ch01)
このnoteで『テストエンジニア(を目指す人)のための論理スキル・入門編』とでもいったものを書こうと構想していたのですが、株式会社AGEST様とお会いする機会があり、話の中でそのことを話題に上げたところ、同社の品質メディアSqriptsに掲載していただけることになりました。
本編はSqriptsをお読みいただくことになりますが、こちらのnoteでは、「なぜそういうものを書こうと思ったのか」を綴ることにします。
※上記“入門編”は完結し、2024年4月からは「テストエンジニアのための論理スキル[実践編]」と題して、“論理の言葉の使い方”を紹介しています（リンクは第1回になっています）。お読みくださったらうれしいです。
トレーニングをしていて気づいたこと
技術トレーニング
筆者はテスト関連技術トレーニングとして以下のようなものを手がけていますが：
テスト技術者向けミニワークショップ
テスト技法や、テスト分析・テスト設計のエッセンス、コミュニケーションスキルなどを、2時間程度で体感してもらうワークショップ
テストプロセス/テスト技法等のトレーニング
“定番”：ISTQB Foundation Level, IVEC レベル1・2ベースのトレーニング
テスト技法2日間コースなど
この数年は“若年層”のソフトウェアテスト技術者の育成や“底上げ”に関わることが多くなっています（新卒入社の人や中途採用の人に対するテスト技術者導入教育は特に増えています）。
この数年で気づいたこと
その中でたびたび感じたのが、二値論理や論理演算を知らない（または忘れている）人がいる……ということでした。
最初に気づいたのは、テスト技法を取り上げたミニワークショップで、ワークで問題を解いた後、みんなで過程や結果を振返って話し合った時。
(論理演算の組合せからなる)“複合的な条件”を分解して考えるとか、条件の組合せの否定を考えるといったところで、(。´･ω･)？ となる……説明しても今ひとつピンと来ない表情……という人を見たのだったと思います。
中堅クラスでも、新卒入社でも見かけました。
属性を考えればそう驚くことではないように思えます。新卒では情報系やプログラミング系の学部/学科/専攻でない人もいましたし、中途入社の多くは他分野での就業経験を経ての入社（いわゆる「未経験者採用」）でした。そういう人たちが、二値論理と論理演算を学んでいないとか、使わないうちに忘れてしまったとかはありそうなことです。
ただ、それ以前には感じなかったことでもあり、盲点を突かれた思いでした。
（時間は前後しますが、後述する論理スキルの講座を開発し、中堅テスト技術者向けに開催させていただいた時に参加者に訊いてみたところ、参加者15名中、
論理演算などを学んだことが…… ある：2名 ない： 11名
「ある」の内訳：情報処理技術者試験の勉強1名、前職プログラマー1名
（論理演算など）はじめて聞くことばかりだった： 10名
(ド・モルガンの法則)ワークが難しかった： 9名
という回答でした）
論理のスキルに触れるコンテンツ
ワークショップで論理演算回りを補うようなテーマを取り上げるといった対応もしてみましたが、対症療法に過ぎませんし、論理演算だけを習得すればよいというものでもない……というところから、「論理のスキルに触れるコンテンツ」を考えるようになっていきました。
もともと別の全く異なる経緯から、文章の読み書きや“推論”に関わる論理のスキルを考えていて、そこにつながるようなものが望ましい。
論理演算だけならインターネットを検索すれば解説記事/ページは山ほど見つかりますが、整理・構成された教材は習得の流れや解説、ワークに一貫性を持たせられるのがよいところです。
“大々大前提の基礎教養”？
テスト技術者資格のシラバスにはない
テスト技術者資格制度であるISTQB Foundation Levelにも、IVECのレベル1にも、シラバスに「二値論理と論理演算」といった項目はありません。
これ自体はそんなにおかしいことではないと思います。
現場でソフトウェアテストの話をしていて論理演算の話題が前面に出てくることは殆どありません(当社比)（話題の一端に上ることはあります）。作る側にとって、プログラミング初心者の頃を除けば論理演算のことなど滅多に話題にならないようなものでしょう(当社比)（もちろん、論理演算がホットな話題になる瞬間はあります）。みんな、こうしたことは当然知っているものとして考えたり、話をしたりしているわけです。言ってみれば“大々大前提の基礎教養”ということでしょう。
筆者もISTQB Foundation LevelやIVECのトレーニング講師を何年もやっていますが、シラバスに「足りないところ」があると思ったことはありませんでした。
ひどく困ることはない、のかも知れないけれど
論理演算を知らない/忘れてしまっているとしても、ひどく困ることはないかも知れません。論理演算といってもものすごい秘技を繰り出すわけではなく、日常感覚の延長で考えたことと同じ結果になることも多いです。
ですが、知らずにいることには次のような“デメリット”があります。
知らないでいると、知っていれば簡単に解けることが時間がかかったり、確信が持ちづらかったりということがすることが起こり得ます。
知っている人同士なら瞬時に伝わることが、説明に時間がかかったり(自分が話し手の場合)、相手の説明がすぐに理解できなかったり(自分が聞き手の場合)することも起こり得ます。
場合によっては無駄なテストが生じたり、仕様を誤解した末に誤ったテストをすることも起こり得ます。
そもそもが論理の塊であるソフトウェアが相手の仕事ですから、“基礎教養”的なことを知らないままテスト技術者の道を歩んでいくのは、ひのきのぼうだけ持ってダンジョンに潜っていくようなことになりかねません。
“論理演算の先”にあるもの
それだけでなく、論理演算をはじめとする“論理の言葉”は、「論理的な思考」の基本的な道具になるものです。
論理的な思考はビジネスコミュニケーションに欠くことはできません。
論理演算を知っていれば論理的な思考ができるわけではありませんし、論理演算を知らなくても論理的な思考はできるでしょうが、基本的な道具は持っていた方がよいです。
また、“論理の言葉”を身につけることは、テスト技術者としての成長に寄与します。テスト技法の中には二値論理と論理演算を前提にしているものもありますし、テストベースをレビューする際などにも必要になってきます。
そういうことで
「“論理の言葉”を学ぼう」コンテンツから、Web記事へ
数年前、論理演算から始めて、基本的な“論理の言葉”を学ぼう、というコンテンツを作りました。以来、提供先向けに仕立て直したりしながら続いています。
このコンテンツを下敷きにして、基本的な“論理の言葉”を紹介しようと考えていたものがnote記事の構想です。Sqriptsに掲載させていただくことになったおかげで、ほぼ全面的に考え直す機会を得ることができました。
むすび
トレーニングコンテンツも、Sqriptsの記事も、後半は文の論理構造を把握するために押さえておきたい言葉を取り上げています。
（自分の解釈を加えたり想像で補ったりせずに）文章の 筋道を辿って 理解するというのは、テストに取り組む時だけでなく、“論理的に考える”ために大切なことだからです。その過程で文章の論理の欠落や飛躍に気づいたりもしますし、ひいては論理的な文章を書く際にも活きてきます。
“入門編”の先には以下のようなテーマが待ち構えていますが……
文章の論理構造を把握するための論理の言葉たち
長い文章の筋道を見失わずに読み書きするための手がかり
考えの筋道を立てるためのルール
文章の論理構造を検証したり、自分の考えを筋道立てて組み立てるための考え方
テストの領域だと、以下のようなことに関係します
複数の事象(故障や不正)に共通する要素を見つけ、事象の発生要因を推測する
故障を引き起こす原因(欠陥(バグ))を推測する
これらについては、追々、このnoteで記事にまとめていけたらよいなと思っています。
付記＠R002
おかげさまで、テストエンジニアのための論理スキル［再］入門は3月に全6回の連載を終了しました。
株式会社AGEST様からは、引き続き、「論理スキル“実践編”」執筆の機会をいただきました。
これを機に、本記事の細部を加筆修正しました（リンク先の修正、冒頭とこの付記の追加）。
“実践編”で取り上げているのは、「むすび」にある「考えの筋道を立てるためのルール」「文章の論理構造を検証したり、自分の考えを筋道立てて組み立てるための考え方」に相当します。“入門編”と併せてお読みくださったらうれしいです。
(2023-10-30 R001)
(2024-04-04 R002)