見出し画像

プロセス品質と「ならば」の話(T3:Pt2:Ch05)

論理の言葉が実際に使われている例で、論理のスキルを磨きましょう。
「T3:Pt1:Ch01 論理スキル・“入門編”のこと」と「T3:Pt2:Ch03 「プロセス」を振り返ってみよう」の合同企画? です。


論理の言葉にアンテナを張ろう

人の発言を聞いたり、人が書いた文を読んだりといった外部からの入力を受け取る時は、得てして「言葉をそのまま受け取ってしまって論理のスキルが働きにくい」ということも起こりがちです(発言や文が滑らかだと特に)。

それで話の筋道を読み落としたり、おかしな点に気づき損ねたりにならないように、「聞いた発言や読んだ文から論理の言葉を見つけたら、その働きを考え、文の意味を考える」ということに慣れておくとよいでしょう。

例としてISTQB-FLシラバスの文を取り上げて、そこに現れる論理の言葉を考えてみましょう。

ISTQB Foundation Level V4.0シラバスから

取り上げるのは「1.2.2 テストと品質保証(QA)」、QA(品質保証)の基本的な考え方を述べている一文です。

よいプロセスが正しく行われれば、よいプロダクトを作ることができるという考えに基づいている。

[1] p.18

It works on the basis that if a good process is followed correctly, then it will generate a good product.

[2] p.17

“ならば”を使って表すと

論理の言葉を陽に使ってみる

日本語訳でも条件つき主張であることが読み取れますが、原文では if が使われており条件法の文であることがより明確です。

これを論理の言葉“ならば”を使って表すと、以下のような文が考えられるでしょう。
(ついでに(ではありませんが)原文 then 節にある it (プロダクトを生み出す主体)を拾っています)

よいプロセスは、それが正しく守られる ならば、よいプロダクトを生み出す。

「よいプロセスが正しく守られる」が前件(または前提、仮定)で、これをPと略しましょう。

「(よいプロセスは)よいプロダクトを生み出す」が後件(または帰結)です。これをQと略しましょう。

前件「よいプロセスが正しく守られる」について

前件は短いながら重要なことをふたつ言っています。

プロセスは(ありさえすれば)どんなものでもよいというわけではない。そのプロセスは「よい」ものでなければならない。というのがひとつ。
プロセスの品質を考える時心に留めておくべきその①ですね。

どうであれば「よい」と言えるのかについては諸説あるでしょうが、ソフトウェアの開発においてやるべきことを網羅している、然るべき時に然るべきことをやる、やるべきでない時にやるべきでないことはしないようになっている、作業の内容や成果物をチェックする仕組みがある、などです。

そのよいプロセスも、自己判断で端折ったり約束事を破ったりしたのでは意味がない。やるべきことを正しく遂行しなければならない。というのがふたつめ。
プロセスの品質を考える時心に留めておくべきその②です。

“ならば”の意味と働きを考える

“ならば”の意味

条件つき主張「PならばQ」は、

  • 「Pが成り立つ(真である)時は、必ずQが成り立つ(真である)」

  • =「Pが成り立つ(真である)のに、Qが成り立たない(真ではない)、ということはない」

と主張していることを意味します。(「主張している」がポイント。その真偽は別の話です)

必要条件と十分条件

「PならばQ」において、QはPであるための必要条件で、PはQであるための十分条件といいます。

必要条件。「P=よいプロセスが正しく守られている」と言えるためには、「Q=よいプロダクトを生み出している」ことが必要である。あるいは、Qでなかったら、Pであることにはならない。

十分条件。「Q=よいプロダクトを生み出している」と言えるためには、「P=よいプロセスが正しく守られている」のであれば十分である。あるいは、Pであれば、自ずとQであると言える。(ただし、PでなくともQであることはあり得る)

これは、Pである場合の集合より、Qである場合の集合の方が“大きい”という関係性によります(Fig.01)。

Fig.01: “ならば”におけるPとQの関係

両者の関係は、次のような例を考えれば納得ができるでしょう。

  • プロセスなど気にしなかったりプロセスがぐだぐだだったりしても、よいプロダクトが生まれることはある(Pは偽だがQは真)

  • どんなに“よいプロセス”と自負していても、よいプロダクトづくりに結びついていないのだったら、そのプロセスには“よくない”ところがあると考えられる(Pは真のつもりだがQが偽)

逆・裏・対偶

「よいプロセスは、それが正しく守られるならば(P)、よいプロダクトを生み出す(Q)」に対して、前件・後件を入れ替える、また前件・後件をそれぞれ否定した形を考えることができます(Fig.02)。

Fig.02: “ならば”と逆・裏・対偶
  • 逆:「よいプロダクトを生み出している(Q)ならば、よいプロセスが正しく守られている(P)」

  • 裏:「よいプロセスが正しく守られていない(NOT(P))ならば、よいプロダクトが生み出されていない(NOT(Q))」

  • 対偶:「よいプロダクトが生み出されていない(NOT(Q))ならば、よいプロセスが正しく守られていない(NOT(P))」

「PならばQ」が成り立っている時、対偶も必ず成り立ちますが、逆と裏は必ずしも成り立つとは限りません。

それぞれ、具体的な例を想像してみるのもよいトレーニングになります。

こんな風に具体例があると

実際の文や具体的な例に当てはめて考えると、論理の言葉の働きについての理解が深まりやすいです。特に条件法の言葉“ならば”の意味/働きと逆・裏・対偶という変換は、実際の例でたくさん考えてみるのがよいでしょう。

プロセスとプロダクトの関係、プロセス品質とプロダクト品質の関係

ISTQB-FL V4.0の記述に戻ります。

「よいプロダクトはよいプロセスから」というのは、ソフトウェア業界では広く認められている考え方です。

込み入った仕事になるほど、作業の順序や進め方、作業の実施の仕方や注意点が重要になってきがちです。加えて、実施内容のチェック(検証、妥当性確認)や成果物のチェック(同前)も重要になります。

そのような仕事を、各自が思うがままに作業していたり、進め方やチェックが作業者の経験や勘に依存しているようでは、出来上がる製品に(常に)高品質を期待するのは難しいものがあります。(まして作業や成果物のチェックが蔑ろにされたら……)

そういうわけで、高品質のソフトウェアプロダクトを 継続して確実に 生み出すためには、プロセスの 品質 (よいプロセスを正しく守る)が不可欠と考えられています。

この「プロセス」には、当然テストのプロセスも含まれます。よいテストケースを作るにはテスト分析・テスト設計が大切ですし、テスト実装はテストの効果・効率に影響します。テストプロセスやテストウェアのレビューも欠かせません。
テスト活動も含めて「よいプロダクトはよいプロセスから」を実践しましょう。(開発担当者はしばしば自身が行なうテストを軽く考えがち)

QA(品質保証)はプロセス品質が保たれているかどうか――プロセスが守られているか、適切にチェックされているかを追いかけ、確認する活動です。プロセスの遵守に問題が見られた場合や、プロセス自体の問題が見つかった時にはプロセスの改善にも関与します。


参考URL (Sqripts掲載記事)


参考文献

  • [1] Japan Software Testing Qualifications Board (JSTQB)・訳,
    『テスト技術者資格制度 Foundation Level シラバス Version 2023V4.0.J01』
    (2023)

    • [2] の日本語訳

  • [2] International Software Testing Qualifications Board,
    "Certified Tester Foundation Level Syllabus v4.0" (2023)


(2024-07-09 R001)

いいなと思ったら応援しよう!