「保守性」と「拡張性」が複数の意味をもっていそうなので調べてみた

　『アジャイルメトリクス』を少しずつ読んでいます。

作者:Christopher W. H. Davis
翔泳社

　職業がら、最初をすっ飛ばして「品質」の項から手を付けていることもあり、なかなか歯ごたえのある（つまりわたしには難しい）本だなーと噛みしめております。
　読み進めていくなかで、「この品質特性、多義的じゃないか？」と感じたものが2つあったので、わたしの理解をメモしておきます。

TL:DR

国内規格で「保守性」といえば、コードの修正のしやすさ。運用の仕方ではない。
「拡張性」は、外部品質的なscalabilityと、内部品質的なextensibilityのどちらの話をしているかに注意。

保守性

　まず、「保守性」です。
　ソフトウェアの分野で「保守性」という言葉は、少なくとも2つの意味で使われるように感じます。開発寄りか、運用寄りか、の2つです。DevかOpsか、と言ってもいいかもしれません。

(A) 開発寄りの「保守性」

コードの修正のしやすさ、修正に伴うテストのしやすさ、みたいなもの。
「このプログラムは保守性が低くて、どこを触ったらどこに影響があるかわからないよ・・・」
ソフトウェアの内部品質特性のように思える。

(B) 運用寄りの「保守性」

ログの明瞭さ、トラブルシュートのしやすさ、運用ドキュメントの充実、みたいなもの。
「このサービスって、保守のこと何も考えてないから、ろくにアラートも上がらないんだよな」
ソフトウェアの外部品質特性のように思える。

　結論を言うと、ISO/IEC 25010:2011（SQuaRE）における「保守性」は、(A)です。
　JIS X 25010:2013による「保守性」*1の定義は以下の通り。

保守性（maintainability）
意図した保守者によって，製品又はシステムが修正することができる有効性及び効率性の度合い。

　この品質特性の下には、以下の副特性がぶら下がっています。

モジュール性（modularity）
再利用性（reusability）
解析性（analysability）
修正性（modifiability）

　では、運用寄りの(B)を表す品質特性はあるのでしょうか。
　一番近いものは、「運用操作性」に見えます。　

運用操作性（operability）
製品又はシステムが，それらを運用操作しやすく，制御しやすくする属性をもっている度合い。

　なお「運用操作性」は、「使用性」（Usability）の下にある品質副特性です。ユーザビリティの下か～。
　そのソフトウェアの運用のしやすさを表現するための「運用性」なんて品質特性があってよさそうですが、ないのですね。Observability（可観測性）なんてまさにそういうものなのかなと思っているのですが・・。

　なお『アジャイルメトリクス』では、保守性の構成要素として以下を挙げています。
　これらの一部は、ソフトウェアの保守性そのものというより、保守性の「結果」として現れるメトリクスに見えます。

平均修復時間（MTTR）
リードタイム
コードカバレッジ
コーディング規約ルール（の順守レベル）
機能追加やバグフィックスのためにどのくらいコードを変更しなければならないか
バグ率

拡張性

　『アジャイルメトリクス』の第8章『ソフトウェア品質を測定する』では、「拡張性」と「スケーラビリティ」が1つの図に同時に現れ、混乱させられました*2。
　　結論を先に言っておくと、この2つは別のものです。

　『アジャイルメトリクス』の『8.2　品質特性によるNFRの測定』では、「拡張性」を以下のように説明しています。

新しい視能を追加したり、アプリケーションを拡張したりするために必要な労力の大きさ

　これってソフトウェアの内部品質っぽいですよね。SQuaREでいうと、「保守性」の下の副特性「修正性」に相当するとみていいでしょう。

　一方、ISTQBのFoundation Level 性能テストのシラバスでは、「拡張性テスト」を以下のように説明しています。
　こちらは外部品質っぽいですよね。

拡張性テストでは、現在要求されている以上の将来的な効率性の要求を満たすためのシステムの能力に焦点を当てる。これらのテストの目的は、現在指定されている性能要件に違反したり故障したりすることなく、システムが成長する能力（ユーザー数の増加や保存データ量の増加など）を判断することである。拡張性の限界が明らかになれば、しきい値を設定し、本番環境でモニタリングすることで、問題が発生しそうなときに警告を発することができる。また、適切な量のハードウェアで本番環境を調整することもできる。

　この2つの「拡張性」は明らかに別のものなのですが、辰巳さんにいただいたオチが以下でした。

『アジャイルメトリクス』を確認すると、翻訳本のp.169に
「保守性/拡張性―機能の追加や問題の修正、製品のデプロイがどのくらい簡単か？」
が出てきます。
これを原著で見ると"Maintainability/extensibility- .."、
何と拡張性はscalabilityではなくextensibilityの訳なのでした!
— Keizo Tatsumi (@KeizoTatsumi) 2023年2月3日

　つまり、本書での対訳が以下のようになっているのでした。

拡張性 : extensibility
スケーラビリティ : scalability

　これはわからん・・・ですが、本書を読むときにはこの対訳を覚えておきましょう！　

おわりに

　辰巳さんによると、後者のscalabilityも品質特性に追加されるようです。

ISO 25010 (SQuaRE)の次期改訂では、主品質特性のPortability(移植性)がFlexibilityに(名称が)変更となり、その下の副特性にScalabilityが追加されるようです。保守性はそのまま(副特性はモジュール性、再利用性、解析性、修正性、試験性)。
— Keizo Tatsumi (@KeizoTatsumi) 2023年2月1日

　そういえば、「信頼性」にも、reliabilityとdependabilityがあったような・・・。

*1:製品品質モデルの下の品質特性である。

*2:先立つ章にきちんと説明があるのかもしれません。であれば、つまみ食い読者のわたしの問題です。すみません。

2023-03-19

JaSST'23 Tokyoで、テスト管理ツールの話をしてきました #jassttokyo

イベントテスト管理

　2023年3月9日・10日に開催されたJaSST '23 Tokyoで、『テストウェアのデータモデル』というタイトルの発表をしてきました。セッションのパートナーは、朱峰錦司（きんぢ）さんです。

発表の背景

　以前に比べてだいぶ普及してきたテスト管理ツール。しかしテスト管理ツールはその名の通り「道具」であり、勝手に何でもやってくれるわけではありません。
　ツールが用意してくれるのはざっくりとした「枠組み」とそれを利用するための「機能」であって、それを自分たちの仕事にどう生かすかは、自分たちで設計する必要があります。

　このセッションは、テスト管理ツールを「使う」側（鈴木）と「作る」側（きんぢさん）で、それぞれが考える悩みと、それに対するアイデアを交換し、さらに聴講者の方の質問にも答えていこう！という、60分にしてはなかなか詰め込んだ企画でした。

感想

　セッションに向けて資料を作成する中で、自分が課題と感じていることとをある程度クリアに言語化できましたし、きんぢさんの柔軟な発想から刺激を受けることもできて、とてもよい経験になりました。

　また、聴講してくれた方からたくさんコメント＆質問もいただけたのもの楽しかったです。時間がなく超高速回答になってしまったので、またどこかでじっくり議論してみたいものですね。
　mass氏からもらったこのまとめは、とても励みになりました。ほんと地味で泥臭すぎるセッションテーマだと思ってたんで・・。

マニアック、骨太とのことですが、おそらくどの現場でもずっと悩んでいる問題 (弊社も前職でも) なので、むしろ需要ど真ん中だったのではという感想を持ちました。ありがとうございます。

　カオスエンジニアリング！ AIちゃん！みたいな、トレンドにふさわしい大きなテーマはもちろん人気がありますが、わたしはこーいう「派手なセッションを聴いて興奮しながら現場に戻ってみたら、そこに転がっていた悩み」みたいなやつに取り組んでいきたいと思います！

今後やりたいこと

　で、コレ。

発表終わった、きんぢさんとコラボできて楽しかったぞい。
テスト管理ーツールのベストプラクティス整理とか課題解決提案、みんなでやっていこうぜ！#jassttokyo
— Kazu SUZUKI (@kz_suzuki) 2023年3月10日

　一番やりたいのはこれです。ベストプラクティス作りたいんですよね。
　割と汎用的なナレッジになると思うので、英語化して発信する！ 2023年度に！　誰か興味ありませんか？

One more thing ...

　今回わたしは「モノリシックなテスト管理」という言葉を、きんぢさんは「強いトレサビ、弱いトレサビ」という言葉を生み出しました。
　テストケース管理ツールについて語る際に、積極的にご利用ください（いつ？）。

モノリシックなテスト管理: テスト観点・テストケース・テスト実行・バグが、1つのエンティティとして強力に結合した形式のテスト管理。本来別のエンティティが結合してしまっているため、暗黙の裡に1:1:1:1であることが強制されてしまう。
強いトレサビ 導出元（たとえばテストモデル）と導出先（テストケース）が連動しており、元の変更に追随して先も変更されるようなトレーサビリティ。
弱いトレサビ 導出元と導出先を関連付ける情報は保持しているが、元の変更によって先が追随することまではしないトレーサビリティ。

資料

　資料は以下*1です。

鈴木資料

speakerdeck.com

きんぢさん資料

speakerdeck.com

聴講くださったからのレポート

ありがたや～。 sqripts.com

*1:二人ともピンインURL・・悲しい

2023-02-27

ソフトウェア仕様についてChatGPTに相談してみる

機械学習

　ChatGPTでテスト設計してみた記事と、そのアンサーソングを見つつ、また色んな人が色んなことをやってみた記事をみてChatGPTのすごさがあらためて伝わってきました。両方ともとても面白い記事です。

zenn.dev nihonbuson.hatenadiary.jp

　一方、わたしのは埋め草で、特に難しいことはしていません。
　仕様についてChatGPTに質問してみて、その回答と自分の期待値を比較してみようという実験です。

曖昧な仕様についての質問

　初めに、とてもシンプルな質問をしてみました。
　「曖昧」とは何か、「バス」とは何か、みたいなことはまったく配慮してあげなくていいはずなのですが、なぜか「機械でも読み取れるように」ちょっと気遣っている自分がいます。

以下の仕様に曖昧な点があるか、教えてください。
「バスの料金は、10歳以下が無料です」

　この質問の意図は、「自然言語で書かれたスペックの妥当性検証みたいなことができるのか？」を知ることです。
　また、期待回答は、「11歳以上の料金が定義されていない」でした。

　実際の回答は以下の通りです（太字はわたしによるものです）。

年齢の計算方法
10歳以下という年齢には、具体的にどのような計算方法が使われているのかについては明確にされていません。例えば、誕生日当日の年齢を基準にするのか、前後何日間を含めるのか、切り捨てか切り上げかなどが不明確です。

料金の種類
「バスの料金」とは、具体的にどのような種類の料金を指しているのかについても明確にされていません。一般的には、大人や学生などの料金区分がある場合がありますが、それらについては触れられていないため、10歳以下の子供にはどのような種類の料金が適用されるのか不明確です。

無料の範囲
「10歳以下が無料」という表現からは、子供の年齢が10歳以下であれば完全に無料ということになると解釈できますが、実際にはいくつかの場合で料金が発生する可能性があります。たとえば、大人と同じ座席を使用する場合には、大人と同じ料金が必要になる場合があるため、この点についても明確にされていません。

以上のように、この仕様には曖昧な点がいくつかあります。具体的にどのような状況でどのような料金が適用されるかを確認するためには、より詳細な情報が必要です。

　正直、想像以上でした。
　この3つの回答それぞれが、素晴らしい示唆を与えてくれていると感じます。

回答1. 暗黙の了解をスルーしない

　この単純なスペックにおいてわたしは、無意識のうちに「年齢は、曖昧な要素が少なく一意に決まる情報」のように扱っていました。
　ところがChatGPTはそんな暗黙の前提、コンテキストに乗っかってきません。国や地域、法律や常識、それぞれで違う「年齢」の定義のうち、どれを採用するかというのは、場合によっては大事な条件になるでしょう。

回答2. 一般論を踏まえている

　2行であっさり書かれた仕様の文章の中に閉じてどうこう言うのではなく、「バスの料金といえば」という一般論を踏まえて、具体化の必要性について指摘しています。
　これはある意味「ドメイン知識」と言えるかもしれません。

回答3. 実ビジネスケースを考慮している

　たとえばペットを連れてグリーン車に乗っても、ペットの分の料金はかからないでしょう。一方でペットのケージを置くのに一座席使うのなら、その席の料金は払うことになりますよね。
　回答3は、「子どもであっても料金がかかるケースがあるのではないか？」という点を考慮しているといえ、実際に起こりうるビジネスケースをカバーしています。とても「QAっぽい」と感じました。

　なお、「11歳以上の料金が定義されていない」点をわたしから伝えたところ、ChatGPTの回答は以下の通りでした。

そうですね、確かに「11歳以上の料金」が明示されていない場合、その場合の料金についても不明確です。一般的に、バスの料金には大人料金や学生料金、シニア料金など、年齢に応じた様々な種類があることがあります。そのため、10歳以下が無料である場合には、11歳以上についてはどのような料金が適用されるのかについても明示する必要があります。より詳細な情報が必要になる場合がありますので、バス会社や交通機関に問い合わせることをおすすめします。

　最後放置された。

仕様の矛盾についての質問

　次に、以下の質問をしてみました。

ある動物園の入園料金は、以下のルールで決まります。
6歳未満　無料
6歳以上18歳未満　1000円
18歳以上60歳未満　1500円
60歳以上　無料
この場合、15歳の人の入園料金はいくらになるでしょうか。

　以下のように、正しい答えをくれます。

問題にある動物園の入園料金のルールによると、15歳の人の入園料金は「6歳以上18歳未満 1000円」となります。よって、15歳の人の入園料金は1000円となります。

　正直、これだけですごすぎると思いますが。。
　次に、矛盾した仕様を提示します。

その通りです。では、別の仕様として、以下のルールを考えます。
6歳未満　無料
6歳以上18歳以下　1000円
18歳以上60歳未満　1500円
60歳以上　無料
この仕様に、矛盾はあるでしょうか？

　回答は、以下の通りです。
　わたしからすると、2～5行目が仕様で、1・6行目が地の文であると解釈できているだけでもすごいと思いますが、回答も的確です。。

この仕様には、矛盾が含まれています。問題は、18歳の人が入園料金として1000円となってしまうことです。18歳の人は「6歳以上18歳以下」という条件に該当するため、前者の料金が適用されるべきです。しかし、仕様によると、18歳以上の人には「1500円」という料金が設定されているため、矛盾が生じています。この仕様では、料金の設定に関する条件に誤りがあるため、修正が必要となります。

　とはいえ、あまりにあからさまな矛盾かもしれません。仕様の矛盾というのは、もっと入り組んだビジネスルールの中に埋もれがちなので、そういう実験もそのうちやってみたいと思います。

状態遷移モデルの検討

　デブサミでも使った、「状態遷移が曖昧な仕様」から、状態遷移表を作ってもらいました。

また別の仕様として、あるSNSのユーザが、SNS内のグループに入るための仕様を考えます。
(1)ユーザの初期状態は、「メンバーではない」です。
(2)ユーザが「グループ参加希望」ボタンを押すと、ユーザの状態は「管理者承認待ち」になり、管理者に通知されます。
(3)管理者が通知を承認すると、ユーザの状態は「メンバー」になります。
(4)管理者が通知を却下すると、ユーザの状態は「メンバーではない」になります。

この仕様を、状態遷移表にしてください。

　ChatGPTの回答。

以下が、上記のSNSグループ参加の仕様に基づく状態遷移表です。
この状態遷移表により、ユーザがどのようなアクションをとった場合に、どのような状態遷移を経るかが明確になります。

現在の状態	アクション	次の状態
メンバーではない	グループ参加希望ボタンを押す	管理者承認待ち
管理者承認待ち	管理者が承認する	メンバー
管理者承認待ち	管理者が却下する	メンバーではない
メンバー	なし	メンバー

　ちょっと期待していたフォーマットではなかったので、追加で

縦軸を「現在の状態」に、横軸を「アクション」にして状態遷移表を書いてください。

とお願い。しつこいですけど、この依頼を理解できるだけで、信じがたい能力だと思うんだよ。。

現在の状態	グループ参加希望ボタンを押す	管理者が承認する	管理者が却下する
メンバーではない	管理者承認待ち	-	-
管理者承認待ち	-	メンバー	メンバーではない
メンバー	-	-	-

この表を見ると、現在の状態によって、可能なアクションが限定されることが分かります。たとえば、「メンバーではない」状態からは、「グループ参加希望ボタンを押す」アクションが可能で、「管理者が承認する」や「管理者が却下する」アクションは不可能です。逆に、「管理者承認待ち」状態では、「グループ参加希望ボタンを押す」以外のアクションが可能で、「メンバー」状態に移行するか、「メンバーではない」状態に戻るかのいずれかになります。

　今回の質問の仕方では、「定義されていない遷移は、遷移が不可能である」という解釈をされたようです。
　なので、未定義の状態遷移について質問してみました。

「管理者承認待ち」状態で、ユーザが再度「グループ参加希望ボタンを押す」アクションを行った場合、どの状態に遷移するでしょうか？

　答えはこう。

「管理者承認待ち」状態で、ユーザが再度「グループ参加希望ボタンを押す」アクションを行った場合、状態は変化しません。既に「管理者承認待ち」状態にいるため、管理者に通知は再送信されません。ユーザは引き続き、管理者の承認待ちとなります。次に可能なアクションは、管理者の承認または却下になります。

　これは、仕様に基づいて答えているのではなく、ChatGPTの提案と言えると思います。
　「状態は変化しない」はともかく、「管理者に通知は再送信されない」という仕様でいいかどうかは、人間が考えて決めるのもいいでしょう。

　ということで、再度状態遷移表を書いてもらいます。

以下が、管理者承認待ち状態で再度「グループ参加希望ボタンを押す」アクションが行われた場合を含めた状態遷移表です。

現在の状態	アクション	次の状態
メンバーではない	グループ参加希望ボタンを押す	管理者承認待ち
管理者承認待ち	管理者に承認される	メンバー
管理者承認待ち	管理者に却下される	メンバーではない
管理者承認待ち	グループ参加希望ボタンを押す	管理者承認待ち (変化なし)
メンバー	グループ脱退ボタンを押す	メンバーではない

　！？！？

　突然現れたアクション「グループ脱退ボタンを押す」・・・！
　この状態遷移は、「メンバーではない」に戻れない、いわゆる「シナリオが閉じていない」仕様なのですが、なぜ突然そこに気づいた・・・？

　「メンバーでない」を遷移「先」とする遷移がないことから、その遷移を押す「グループ脱退ボタン」を想起したのでしょうか。怖すぎる・・・。
　ともあれこの実験でも、ChatGPTは「仕様に書かれたことに閉じず、提案をしてくれる」ことがわかりました。

所感

　QAエンジニアは日ごろ、自然言語で記述された仕様やモデルと向き合って、「さーて、どんな仕様で、どんなテストをすればいいかな？」って頭をひねっていると思います。
　ChatGPTは現在のところ、仕様の完全性・無矛盾性みたいなものを証明してくれるわけではない*1ですが、「与えた仕様に対し、開発チーム内のバイアスにとらわれない、仕様の文面だけに閉じない意見を出してくれる」ところが、思考のサポートになってよいなあと感じます。新鮮な観点を与えてくれる相棒になりそうです。

　一方裏を返すと、「人間によっては文面に書くまでもない」ところを忖度してくれるわけではないので、そういう部分を人間がサポートするとか、そういう関係になるのかなー。それともそんな役割も残されないかなー。
　いやあ、~~ぞっと~~ワクワクしますね。

*1:インプット、つまり質問の仕方が悪いのかもしれないけれど

2023-02-18

リスキリングに関する「あのグラフ」は、何を表現したかったのかの勝手な推測

MS Office 雑記

　マイナビの記事で掲載されたグラフが難解だと、Twitterで話題になっていました。
　元記事はこちらです。

https://news.mynavi.jp/techplus/article/20230215-2592553/news.mynavi.jp

　この記事では「リスキリング」という言葉がどのくらい認知されているかについて解説しています。そこで紹介されたのが、こちらのグラフです。

　リード文の日本語を読み解くことはできませんでしたが、タイトルを見るかぎりこのグラフは、「男女別の割合」を表現したいものなんでしょう。実際グラフ中には、性別ごとに「32%」「14%」という数字を出しています。
　が、横軸の数字と合っていない上に、「32より14の方が大きい」という事態が発生しています。

どのようにしてこのグラフが生まれたのか（推測）

「知っており、正しく理解している」と回答した割合を男女別で見ると、男性が32%、女性が14%という結果が出ている。

という本文の内容、つまりパーセンテージの比較を表現したいなら、こういうグラフになりそうです*1。

　ではこの横のスケールは何なのか。
　あくまで推測ですが、横軸は「人数」なのではないかと思います。
　元グラフの横軸の値とパーセンテージから雑に逆算すると、こんな感じになるはずです。

　推測の推測ですが、まず2個目の方のグラフ（人数を表現）があった。だけど男性と女性で回答した人数が大きく違うのに人数だけ比較してもしょうがないから、値としてパーセンテージを追加した・・・のかなと考えました*2。

どう表現するといいのか

　わたしはグラフの達人でも何でもないので「正解」はわかりませんが、普通に1つ目のグラフを使うだけじゃないかなと思います。

　ただ、男性と女性に分けてパーセンテージを表現したうえで、さらに男性と女性のサンプル数の違いを表現したいという理由があるなら、「モザイク図」が1つの方法かなと思います。Excel標準で描けませんが、丹精込めて手書きで作ると、こんな感じです*3。

　モザイク図では、男性女性それぞれの「理解している・いない」が表現されているとともに、男性と女性の人数比もわかります。
　これによって、「全体でみて、理解しているのはどのくらいか」ということが、視覚的に理解できます。

　ただモザイク図が役に立つのって、（今回の例でいうと）男性と女性の比率が何かを代表しているときだと思うんですよね。
　たとえばある会社の全体でアンケートを取って、みんなが回答したのであれば、グラフの男性女性比率は、会社の男性女性比率そのものを表現していることになります。

　ですが、今回の記事の調査は、そこがよくわかりませんでした。「全国の30歳〜59歳の経営者・役員」の大半が女性であり、その情報自体が本質的な意味をもつなら、モザイク図を使えるのかなーと思いますが・・・。グラフ・データ分析に詳しい方、教えてください。

まとめ

　以上、単なる推測にすぎませんが、「こういうことがしたかったのかな？」というお話でした。
　データを視覚化するためにグラフを描くのって、楽しいです。それだけに、「何を表現したいのか」によって適切なグラフを選ぶことが大事ですよね。モデリングと似ているなーと思います。

　なおこの文章を書きながら、「男→女」の順で並べている自分、男性には青っぽい色、女性には赤っぽい色を割り当てている自分などを再発見してしまい、アンコンシャスバイアスだ・・・って思いました。

*1:同じ「理解している」を別の色にするのは良いとは言えないと思いますが、後の図との対応のため分けています。そのせいで凡例もおかしくなっているが。。。

*2:この推測の怪しいところは、「全国の30歳〜59歳の経営者・役員」の8割以上が女性だということになってしまう点

*3:ちゃんとしたモザイク図だと、縦軸にもパーセンテージを入れたりしています。イメージだけつかんでいただければ・・・。

2023-02-09

#devsumi で「テストを学んでみたい開発者のためのソフトウェアテスト読書マップ」という発表をしてきました。

イベントテスト設計・技法

　Developers Summit (デブサミ) 2023で、「テストを学んでみたい開発者のためのソフトウェアテスト読書マップ」という発表*1をしてきました。

event.shoeisha.jp

　資料はこちらです。

speakerdeck.com

　これまで、ソフトウェアテストとかQAの世界でばかり聴講やら発表やらをしておりまして、その外に出る機会があまりありませんでした。
　今回、イベント主催者の翔泳社様から発表の打診をいただき、かなり腰が引けていたのですが、「これを機に、もうちょっと外に目を向けよう」という無理やりな動機付けで場を借りることにしました。
　といっても結局発表はテストに関することですし、全然外に出ていないのですが・・・まあそれはこれからってことで。

　今回は、ソフトウェアQAエンジニアの有志が一気呵成に作り上げた『ソフトウェアテスト読書マップ』を借りた発表であり、みなさんの成果を流用するものです。マップコントリビュータのみなさんに感謝。

　『ソフトウェアテスト読書マップ』についての記事は、こちらです。

www.kzsuzuki.com

　今回作った「ソフトウェア読書マップ Another View」は、以下のようなものです。

　こうやって本を列挙してみると、「いい本にたくさん出会えて、エンジニア人生楽しめてるなあ」思う一方で、「やっぱ勉強足らんな」とも思います。
　なんかたくさん技術書を読んでいる風ですが、おおむねハッタリで、つまみ食いも多いし、咀嚼できない部分も多いし、何なら積んでますしね（堂々）。

　いずれにせよ、この発表を機に、「ソフトウェアテストやQAってけっこう面白いかも？」って思ってくれる方がいたら嬉しいです。
　また、他の分野の「読書マップ」も見たいので、各コミュニティの方、ぜひお願いします！

　発表の機会をいただいたこと、聴講いただいたこと、感謝いたします。
　どうもありがとうございました！

追記 (2023/2/15)

　マップに対し、QAエンジニア仲間の方からのコメントを見て、明確に書いておくべきだったなーと思うことがありました。
　まず、完璧な本っていうものはない、ですよね。
　また、完全な正解を与えてくれる本というのもないと思います。情報が粗い、必ずしも事実に基づいていない、トピックや考え方が古びてしまっている・・・、いろいろ理由はあると思います。「最初読むにはいいけれど、理解が進むにつれて粗さが感じられてくる」ということもあるでしょう。

　今回入口として紹介した本も正直、やはりそういう側面があります。
　あくまでもトッカカリとしていただき、興味があればより新しく、精緻な本に触れていくのがいいかなと考えています。