【参加メモ】「QA業界のパイオニアが語る！アジャイル・AI時代の品質保証の今」

2024年3月7日(木)の午後、「QA業界のパイオニアが語る！アジャイル・AI時代の品質保証の今」というイベントに参加してきました。
スピーカーは早稲田大学の鷲崎弘宣先生、永和システムマネジメントの平鍋健児さん、AGESTの髙橋寿一さんです。

この記事は当イベントのメモですが、AGESTのオウンドメディアであるSqripts会員限定＆抽選式のイベントであり、SNSでの発信についてのご案内もなかったことから、あまり詳細には触れずに概要を紹介したいと思います。

sqripts.com

アジャイルメトリクスの全体像と利用者・顧客満足に向けて

鷲崎先生のご講演です。

初めに、従来型開発とアジャイル開発における品質メトリクスの違いを説明したうえで、アジャイル開発においてよく利用されている品質メトリクスは圧倒的に製品品質に関するものが多く、一方で肝心の顧客満足を測定する取り組みが目立たないことを課題として提起されました。ユーザ価値を目指しているはずが、それを調べられていない状態ということです。

この課題を解決するために、バグ票やソースコードのコミット履歴が公開され、かつアプリストアでユーザレビューも見られるソフトウェアを対象にした研究を実施。間接的ながら、コミット履歴からは開発プロセスの特性を定量化でき、ユーザレビューからは顧客満足に相当する情報を定量化できる、というわけです。

結論として、レビュー依頼からマージまでの時間は、レビュースコアと明らかな負の相関があるということがわかったそうです。
擬似的な代替メトリクスであり、両者に因果関係があるとまでは断定できないとのことでしたが、顧客満足に影響する要素を特定するための活動としてとても面白いと感じました。

デジタルビジネスの潮流とアジャイル開発 〜ビジネスとエンジニアの協働チームづくり〜

平鍋さんのご講演です。

まずウォーターフォールの課題として、「要求からリリースまでのターンアラウンドタイムが長い」「終盤になってモメて、発注側と受注側のゼロサムゲームで消耗する」ことを挙げられました。これとは対照的なモノ作りとして、現場でユーザの実施のふるまいを観察しその場でプロトタイプを作り上げていくNordstromのアジャイル開発を紹介。

www.youtube.com

その中で品質保証の人間は意思決定できるチームの中にいるべきで、プロダクト横断的な観点、たとえばセキュリティの作り込みやテストのような開発項目を、「品質シナリオ」*1としてプロダクトバックログの中に組み込む役割を果たせるだろうとお話しいただきました。

また、「アジャイル開発の全社標準」といったものには注意すべきで、やるとしても、実践してうまくいったチームの経験を使うこと、またそれぞれの開発チーム自身が工夫できる余地を残すことを強調されていました。
個人的にも、「うまく行ったことのあるやり方」や、「工夫して作り込んだテンプレ」みたいなものを共有・紹介するのはとてもいいと思う一方で、それらの謎ANDを取って「全員このプラクティスに従うべき！」というのはチームを縛るだけで、アジャイル開発の良さを殺すんだろうなと感じます。

AI時代のソフトウェアテスト入門（シフトレフトするの？シフトライトするの？）

高橋 寿一さんの講演です。

高橋さんは、「生成AIによって開発生産性は上がるが、テストの生産性は上がっていない」と問題提起したうえで、AIのテストの難しさについて解説されました。
出力の非決定性、学習データのバイアス問題、テストオラクル問題*2とそれに伴うテスト自動化の困難さ、未成熟なテスト技法、といった具合です。また技術面とは別に、法規制などの側面でも新たな問題が生まれそうだとしています。
良くも悪くも、テストエンジニアの仕事はむしろ範囲が増える形になっており、それをどうやって減らしていくかが課題になりそうだとお話されていました。

なお、AIのテストについての翻訳本が春に出るというアナウンスがありました。
現著者は、Adam Smith氏とRex Black氏。Black氏はソフトウェアQA/テスト業界ではあまりに著名なコンサルタントですし、Smith氏はISO/IEC JTC 1/SC 42（人工知能）のメンバーでもあります。つまり、テストのプロとAIのプロが組んで書いた本。これは楽しみですね。

Artificial Intelligence and Software Testing: Building systems you can trust (English Edition)

↑ これは原著ですのでご注意！

おわりに

どれも印象に残る講演で、自分の仕事にも取り込んでいきたいと感じました。
わたしはAGESTさんの回し者ではありませんが、SqriptsはQAについての記事を幅広く、またかなりの頻度で出しているメディアであり、購読をお勧めします。まあ読み切れないのですが。。

余談ですが、懇親会で供されたビュッフェ、めちゃくちゃ美味しかったです・・・帝国ホテルのローストビーフ・・・。

Generated By Dalle

*1:『アジャイル品質パターン』で定義された、アジャイル開発における品質プラクティスの一つ。

アジャイル品質パターン「QA to AQ」 伝統的な品質保証からアジャイル品質への変革（CodeZine Digital First）

*2:テストにおいて、あるべき期待値を決める根拠が得られないという問題。たとえばChatGPTに「美しい詩を書いて」と指示した場合、どんな詩が出力されれば「正解」で言えるかを決めることは難しい。「テストオラクル」については、こちらの記事も参照。 www.kzsuzuki.com

【参加メモ】AI時代のソフトウェアテストの現在と未来 #genai_autify_launchable

本日2024年3月5日(火)の昼間に開催された、『AI時代のソフトウェアテストの現在と未来』というイベントがとてもよかったので、特に印象深かったポイントについて共有したいと思います。

イベントの詳細はこちらで。 autifyjapan.connpass.com

登壇者はタワーズ・クエストの和田卓人 @t_wada さん、Launchableの川口耕介 @kohsukekawa さん、Autifyの近澤良 @chikathreesix さんのお三方。ファシリテーターは、近澤さんと同じくAutifyの、末村拓也 @tsueeemura さんです。

宣伝タイム

• Launchableは、「テストの失敗をよりインテリジェントに扱う」ことを目指している。
  たとえば、テストのFlakinessの判定や対処にできるだけ人を介在させないとか、過去の実行結果を見て再実行要否の判断をするといったもの。
• Autifyは、E2Eテストの2つのペインポイントである実装と保守を、ノーコードで行う。画面変更にも自動的に追随できる。

質問1. AIを活用した開発プロセスのあるべき姿

「ソフトウェア開発における生成AIの活用といえばまずコード生成が挙がるが、生成AIは要件定義でも強みがありそう」という川口さんのご指摘に対して、近澤さんも「要件定義など上段をしっかり作ると、良いアウトプットができる」とおっしゃっていました。
基本設計→詳細設計→プログラミング と、設計ドキュメントを十全に作り上げてから実装の始まる従来の開発から、「包括的なドキュメントよりも動くソフトウェアを」を旨とするアジャイル開発へのシフトが起こりましたが、今後は「動くソフトウェアを素早く作るためのドキュメントを」というパラダイムも来るのかなーと感じます。

生成AIによって生成されたモノの質の担保について、「何をもって正しいかは人間が判断する」とした和田さんのご意見が印象的でした*1。AIはあくまでも「自分が書くとこうなる」とわかっているものを作ることは楽にしてくれるけれど、「どう書けばいいかわからない」ものは、質を評価できないと。これはプロダクトコードもテストコードも同じ。
「プロダクトコードとテストコード両方を書く場合、プログラマーは頭のモードを切り替えて自分との会話をするが、LLMにこの対話をさせるパイプラインをデザインできないか」という川口さんのアイデアに対し、「両方をAIに生成させると、両方が等しく誤るリスクがある」とおっしゃっていました。ただ、「要件・仕様ドキュメント」「プロダクトコード」「テストコード」のトリオのうち2つを人間が作り、残りの1つを生成させると、高い精度が得られる傾向があるというお話をされていました。
何となくRAID5の分散パリティを思わせるようでもあり、またある意味「たがいに冗長」である2つをしっかり作ることで、残りの1つが間違える確率を減らしているようにも思え、ワクワクする知見でした。

質問2. テストにおけるLLMの活用

近澤さん、川口さんともに、今後はテキストベースのログだけでなく、マルチモーダルAIでスクリーンショットをチェックし、従来はベテランの直感頼りだった異常検知もできるようになるだろうとおっしゃっていました。
「才能のあるテストエンジニアの力を民主化し、スケールさせる」という表現も面白かった。

質問3. 人間に残されるタスク

たとえば運転は、自動運転に代替され始めている。そうなると、「運転する」こと自体は重要ではなく、「どこに行くか」を考えられることが重要というのが、San FranciscoでWeimoの自動車を目の当たりにしている近澤さんのご意見でした。「何を作るか」は人間が考えるということですね。
一方川口さんは、いわゆる「上流」の仕事も、ユーザやマーケットの観察などある意味で機械的・言語処理的なものであり、生き残るかどうかには懐疑的とのご意見。

ファシリテーターの末村さんは、ベテランのエンジニアが行っていることの例として、「どのタイミングでどういうテストを行うべきか」といったテスト戦略の立案や、新しいテスト技術の開発*2といったものがあり、こういった作業は代替されないのでは？と問いかけを行っていました。

前者について和田さんは、従来のテスト戦略の暗黙の前提になっている点を見直す必要が出てくるというお話をされていました。
これまでのテスト戦略は、テストを行う主体が人間であることを前提とし、そのうえで最適な方法を模索しています。単純な例だと、「パラメータの全組み合わせを手動で実行している時間はないから、リスクに応じてカバレッジ基準を落とそう」といったものです。
テスト自動化によりそれも変わってきてはいますが、生成AIがそれに拍車をかける。よって、今まで前提としてきたもののうち、依然として有効なものがどれで、すでに無効になっているものがどれかを見極める必要がある、ということです。

4. レガシーコードの技術的負債に対するAIの活用

巨大なコードベースで、テスト容易性・理解容易性・変更容易性がすべて低いような状況において、「リファクタリング前後のサンプル」を少数与えることで、残りのレガシーコードも「以下同文」としてすべてリファクタリングすることができるのではないか」という和田さんのお話が面白かったです。
また、数万行オーダーのコードを生成AIが一気に理解できるようになれば、コードから仕様ドキュメントの生成も容易になり、「誰も全体を把握していない」「超ベテランしか把握していない」という状態から抜け出せるというお話もありました。夢が広がる話です。

感想

今後のテスト・QAに対する自分の取り組みに新たな発想を与えてくれる、非常に有意義なトークセッションでした。生成AIを含めたAI全般についての知識を深めつつ、業界内の動向や事例をよく吸収して、良いモノづくりにつなげていきたいと感じさせられました。

登壇者のみなさん、運営のみなさん、ありがとうございました。

Generated By Dalle

*1:なお、人間が指示→AIが作業→人間が確認する形を「サンドイッチワークフロー」と言うそうです。

*2:たとえば、最近書籍が出版された話題になっているプロパティベーステスト（Property-based Testing）を挙げられていました。

実践プロパティベーステスト ― PropErとErlang/Elixirではじめよう

JaSST'24 Tokyoでパネルディスカッションに参加します！

JaSST'24 Tokyoは3/14(木)、3/15(金)に開催。再来週に迫ってきました。

jasst.jp

わたしも同僚とともに2日間、現地で参加予定。とても楽しみにしています。

IT系イベント・カンファレンスといえば最近はオンライン開催も多く、自宅から気軽に参加できる大きなメリットを享受しています。運営に関わるみなさまには感謝ばかりです。
一方で現地イベント。移動の手間はかかるし、聴講する環境も必ずしも良くはなかったりする。それでも。
それでも、現地ならではの熱気と、何より自分自身の集中力がまったく違うんです。現地イベントにおけるわたしの集中力を53万とすると、映像コンテンツの苦手なわたしのオンラインイベントにおける集中力は5くらいなんですよね。

また、わたしはコミュニケーション能力が高い方ではないのですが、それでも現地に行けば、多少なりともネットワーキングができる！
有力な転職情報は特に求めていないのですが、「ソフトウェアの品質やテストについて、ダラダラしゃべったりできる同志」がとても大切なんです。 現地にいらっしゃるみなさん、当日はどうぞよろしくお願いします。

なお2日目は、『テスト管理ツールの向かう先』というセッションで「しゃべる側」になります。

jasst.jp

テスト管理ツールベンダ三社とユーザ（これがわたし）の立場から、「テスト管理ツールってどうなの？」に加えて、「テスト管理ツールって、これからどうなっていくの？」という話ができればと思っています。
Quality Forwardを担ぐベリサーブの朱峰さん、CATを担ぐSHIFTの石井さん、TestRailを担ぐテクマトリックスの会田さん。みなさんそれぞれベンダーの立場としてのご登壇ですが、「ぶっちゃけで行きましょう」という方ばかり。

「テスト管理ツールにはこんなメリットがあるのでみんな使おう！」に終始する提灯セッションではなく、「テスト管理ツールでテストを・品質を・開発をどう変えていきたいか」という未来の話を、プロのみなさんから引き出せるよう、わたしも頑張ります！ よろしければぜひ、ご聴講ください。

なわとびから考える情報の仕分けとソフトウェアテスト

　レビューの難しさの一つに、「レビューする側とされる側で、感じる重みにギャップのある指摘」問題があります。
　特に、「レビューする側は大事な問題だと思っているのだけれど、される側はそう思っていない」ものが厄介です。このような場合、される側は「そんな重箱をつつくようなことを言わなくても・・」と感じているので、小手先の修正に終わってしまい、次回もまた同じことをやってしまいがち。

　その種の指摘の例として、「列のタイトルとデータが整合していない表」があります。

　「いやそんなことある？」って思われるかもしれませんが、「最初に列タイトルをつけてからデータを入れていったところ、タイトルとあまり関係ない情報も出てきた、でも列を分けなかった」みたいなものはちょいちょい見かけます。この手の表は、書き手が思っている以上に、読み解きの難易度が上がると感じます。

　ちょっと例がアレですが、イメージはこんな感じ。

メトリクス	計算式
テストケース密度	テストケース数 / 開発規模
欠陥密度	欠陥数 / 開発規模 ※n件/ks以上を目標値とする

　「計算式」の列に、計算式以外の情報を入れんでくれ～
　目標値を書きたいなら、「目標値」って列を作ってくれ～

　でふと思ったのですが、「たくさんの情報があるときに、それを仕分けして、適切な列名を定めて表に落とし込む」って、実はそこまで簡単なことではないんだよなと。

突然のなわとび

ということで今日は、「情報の仕分け」を考えてみましょう。お題はこれです！

ジャーン

　これはわたしの次男が学校からもらってきた、「なわとびけんてい」の表。各「種目」で何回飛べたかに応じて色塗りをしていくことで、自身の成果と成長を見える化する、素敵なプリントです。

　この表自体に特に問題があるわけではない（ただし通番と種目の列は分けてほしい、通番の数字は半角にしてほしい、数字は右揃えにしてほしい）のですが、種目を眺めていると、「なわとびの種目は、いろんな概念が組み合わせられている」と感じませんか？ これを紐解いていきましょう。なわとびだけに。

1. 要素に分解する

　名前からしてすでに組み合わせが発生している種目を、要素に分解していきます。

• 前とび → 前
• かけ足とび → かけ足
• 後ろとび → 後ろ
• あやとび（前） → あや × 前
• 交差とび（前） → 交差 × 前
• かけ足あやとび → かけ足 × あや
• あやとび（後ろ） → あや × 後ろ
• かけ足交差とび → かけ足 × 交差
• 前ふりとび → 前ふり
• 交差とび（後ろ） → 交差 × 後ろ
• 二重とび → 二重
• 二重とび（後ろ） → 二重 × 後ろ
• あや二重とび → あや × 二重
• 交差二重とび → 交差 × 二重
• 三重とび → 三重

　以下のような要素がそろいました。意外に少ないですね。

前、かけ足、後ろ、あや、交差、前ふり、二重、三重

2. 要素を仕分けする

　集まった要素を仕分けて、カテゴリーにしていきます。
　仕分けの一つの手がかりとして、「似ているもの」があります。たとえば「前」と「後ろ」は真逆ですが、「回転の方向」を語っているという意味で似ています。

　結果として、以下の4つのカテゴリーとなります。

• 回転の方向: 前、後ろ
• 足の動き: かけ足、前ふり
• 腕の動き: あや、交差
• 回転の回数: 二重、三重

　表の話に戻ると、「回転の方向」などのカテゴリーが列名となり、「前」「後ろ」といった要素がデータの種類になります。

3. 要素の過不足をチェックする

　さて、要素はこれで十分でしょうか？
　いいえ、足りていないものがありますね。最初の「仕分け」は名前を元に行ったので、名前に明示的に現れない要素が抜けているのです。たとえば「足の動き」は「ノーマル」、つまり単純にジャンプ→着地するものがありますよね。

　これらを加えると、以下のようになります。

• 回転の方向: 前、後ろ
• 足の動き: ノーマル、かけ足、前ふり
• 腕の動き: ノーマル、あや、交差
• 回転の回数: 一重、二重、三重

　以上の要素を組み合わせることで、最初の種目すべてを表現できるようになりました。

#	種目	回転の方向	足の動き	腕の動き	回転の回数
10	交差とび（後ろ）	後ろ	ノーマル	交差	一重
01	前とび	前	ノーマル	ノーマル	一重
16	さいきょう	後ろ	前ふり	交差	三重

　いや～ このように整理できると気持ちがいいですね！ ぼくの考えたさいきょうのなわとび種目もすぐ作れるわけです。

4. 新しい要素を考えてみる

　さて、この整理をすると、もう少しできることがあります。

　確かに、最初に提示した種目はこれですべてカバーできるのですが、各列に足せる要素はないでしょうか？
　そうですねー、たとえば「腕の動き」。
　あやとびではジャンプのたびに腕の交差と解放を繰り返しますが、「1回のジャンプで交差と開放をする”ダブルあや”ができないか？」みたいな感じです。
　これは、「腕の動き」というカテゴリーで列名が付いていることにより、考えやすくなっています。

　「回転の回数」なら、単純には「四重」が考えられますし、「1回ごとに回転の回数が変わる飛び方」というのも発想できるかもしれません。

5. 新しいカテゴリーを考えてみる

　さらに、カテゴリーに何か追加できないか考えてみます。
　「足の動きと腕の動きがあるから・・・腰の動きってどうだ？ ジャンプごとに、腰を左右に捻る！これは腹筋に効くぜ・・・！」みたいに。

　これも、カテゴリーの名前が適切に付けられていることが、発想の源となります。

おわりに

　最初の話からだいぶズレてきました。

最初に言いたかったこと

　表を作るなら、列名とデータの内容を整合させよう。

今言いたいこと

　適切なカテゴリー名を付けて分類することは、要素だけでなく、そもそもの分類の軸であるカテゴリーの過不足を検討するためにも、とっても大事なプロセスである。

　QAエンジニアの方なら、「何か、デシジョンテーブルテストとか組み合わせテストやるときに似てるな」と感じたかもしれません。
　その通りです！ これらの表を作る時も、軸と選択肢の洗い出しと仕分けが重要なんですよね。実は最初は「なわとび直交表」を作ろうと思ったのですが、いつの間にか全然違う話になってしまいました。

　無理やりテストの話に持ち込んだところで、今日の雑談は以上です。今年の目標「三重とびをマスターする」を掲げて、今日も練習してきます。

Generated By Dalle

2023年後半に読んで特によかった本

2024年になりました。新年、あけましておめでとうございます！
2023年の後半に読んだ本を振り返って、よかったな～と思うものを記録しておきます。

ソフトウェア開発

システム障害対応の教科書

システム障害対応の教科書

ITシステムの障害対応は、「有期であり」「ユニークである」という特徴を考えると、プロジェクトの一種として捉えることができます。しかし、通常のプロジェクトと大きな違う点があります。それは、「納期が、”とにかくできるだけ早く”である」という点です。
この性質のために、中堅が若手に「じっくり教える」「やらせてみる、失敗も経験させる」というトレーニングが難しい。また皮肉なことに、安定しているシステムであればあるほど、システム障害を経験する場には恵まれないという逆説的な状況になります。

では、徒手空拳で体当たりするのか。それでは、「プロジェクト成功」は望めませんよね。 『システム障害対応の教科書』では、大きな障害が起きた時にどのように対応すべきかを広く説明しています。

広く、といっても、当たり障りのない表面的な情報の羅列ではありません。
たとえば、「事態が終息したら、顧客にも対応メンバーにも明確に宣言して解散する」といった地味ながら大事な話が、しっかりと書かれています。
リーダーの中では終息していても、その感覚は意外に、個々のメンバーには伝わっていないもの。リモートワークならなおさらです。そしてメンバーからは「もう終わりでいいですか？ 寝たいです」なんて言いづらい。リーダーや他の人が言い出すのを、ひたすら待っていたりするんですよね。

このような、ある意味小さな、でも重要なことも含めて、ノウハウが詰め込まれています。システム障害の現場での深い経験を持ち、多くの成功と失敗をしてきたのであろう人だからこそ書ける、良書だと思います。

プロジェクトのトラブル解決大全

『システム障害対応の教科書』がOperationに当たるとすると、Developmentのトラブルにはどう対処すべきでしょうか。
『プロジェクトのトラブル解決大全』があります。

プロジェクトのトラブル解決大全　小さな問題から大炎上まで使える「プロの火消し術86」

このところ、「大全」という言葉がマーケティング目的で付けられているようで敬遠しているのですが、この本はとても好きです。
一歩間違えたら「根性論」「昭和」「ブラック」と指弾されてもおかしくないことを、恐れずにしっかり書いている。トラブル解決は、そのくらい大変なんですよね。

この本が教えてくれることを3つ挙げるとすると、以下です。

1. 炎上プロジェクトは、平和なプロジェクトの延長線上にある

著者自身が書かれていることですが、本書で説明されていることの多くが、炎上「前」からやっておくべきことです。炎上してから急に必要になるスキルがたくさんあるのではなく、そもそも炎上させないようにするスキルが、炎上の現場ではより強く求められるということなんですよね。

平和なプロジェクトに、ポツポツとボヤが起こり始め、それを放置すると本格的な炎上になる。その前に、小さなボヤを、ボヤのまま鎮火するためのスキルが、本書には書かれています。

2. 根性論・精神論と言われようとも、「腹をくくる」のが第一歩である

本書で説明される「火消術」は、進捗管理やプロジェクト管理といった、ある意味ペーパーワーク的なものだけではありません。人と、その気持ちありきです。炎上プロジェクトに関わる人たちの中に飛び込み、協力をとりつけ、モチベーションを平常レベルに戻す。そのために何ができるかということが、事細かに説明されています。

3. リーダーのゴールは、メンバーに好かれることではない

リーダーも人間ですから、できればメンバーと仲良くなり、明るい雰囲気で仕事がしたいもの。「好かれたい」「嫌われたくない」という気持ちはどうしても消せない。でも、それだけでは炎上プロジェクトは（そして普通のプロジェクトも）うまくは回らないんですよね。

終盤に書かれた以下の言葉も、とても身に沁みます。

いくつもの炎上プロジェクトを経験してきて私が思っているのは、
・ミラクルはない
・飛び道具はない
・地味なことを地道にやるしかない

社会

軌道

軌道　福知山線脱線事故　ＪＲ西日本を変えた闘い

今年は「失敗」についての本を何冊か読んだのですが、その過程でお勧めいただいた本です。

JR福知山線の事故を、組織の問題ではなく個人の問題であるとし、企業の責任を認めようとしないJR西日本。一方、個人や会社の誰かを罰するためではなく、二度と同じことが起こらないようにするために「何が起きたのか」「何が原因だったのか」を突き止めようとする遺族。意見の相違ではなく、目標とするところがまったく食い違っている中で、「根本原因の究明」「再発防止策の特定」のために粘り強く戦う姿が描かれています。

正直、読んでいてとても苦しくなる場面もあれば、胸が悪くなるような描写もあります。遺族の心情を追体験させられているようで、読んでいてしんどいものがあります。
それでも、結果や成果だけを情報としてキレイに整理して渡されても、組織に文化を、中でも「失敗を教訓として生かす文化」を定着させることの本当に難しさは、その断片すら理解できないのではないかと思います。

失敗の科学

失敗の科学

「失敗」全般を学ぶ本としては、なぜ失敗が起こるのか、その失敗をなぜ生かせないのかについての幅広い研究をまとめた、『失敗の科学』をお勧めします。
面白い見解やエピソードが満載なのですが、たとえば第4章は、人がミスを認めない理由について扱っています。

「ミスを認めない」というと、その人の不誠実さだったり不勉強に起因するものと思ってしまいがちなのですが、そもそも人間には「最初に信じていた意見から離れることが難しい」という性質があるそうです。
無実の人間に対して、有罪と信じた司法長官が、「無実の容疑者は少ない。無実なら、そもそも容疑者にはならない。よって容疑者は有罪だ」という無茶苦茶な論理を押し通そうとする例や、大洪水の予言を外したカルト教祖に対し、信者の信仰がより深まる例などが紹介されています。

失敗の性質について広く学びたい方は、ぜひ。

学問

言語沼

復刻版 言語オタクが友だちに700日間語り続けて引きずり込んだ言語沼

わたし、専門外の学問を一般の人向けにおいしく味付けしてくれたような本に弱いです。
実際の言語学（というか学問全般）は地味で地道な仕事・調査の連続なんだろうけれど、『言語沼』その一番おいしい上澄みのところを堪能できます。

特に気に入ったのは、第6章の格助詞ネタです。

• 「平和な現代を生きる」
• 「平和な現代に生きる」

この2つを比べると、後者の方がしっくりこないでしょうか？ 一方で

• 「食うか食われるかの乱世を生きる」
• 「食うか食われるかの乱世に生きる」

だと、前者の方がしっくりきませんか？
一体どのように説明できるのか、気になる方はぜひ本書を！ 素晴らしく面白いです。

なお同じ言語学関連で、ネタも若干かぶるのですが、『なぜ、おかしの名前はパピプペポが多いのか？』は小学生向けの説明のためにポケモンやプリキュアを題材にしている点で、別の面白さがあります。

なぜ、おかしの名前はパピプペポが多いのか？ 言語学者、小学生の質問に本気で答える

文学

茨木のり子詩集

茨木のり子詩集 (岩波文庫)

すべての作品が大好きというわけではないのだけれど、ハッとさせられる力強い言葉が多いです。何となく、生きることが惰性になってしまっているこの歳だからこそ、読んでよかったなと感じます。

異色なのは、先に亡くなった夫への気持ちを綴った詩集、『歳月』からの歳月。他の詩集はどちらかというと、「強い女」としての茨木を感じるのですが、『歳月』だけは「夫の対となる妻」としての茨木なんですよね。
胸に迫るものがある詩が多く、詩集自体がほしいのですが、新品は出回っておらず、中古でも5,000円近くするのですね・・・。

ビジネス

採用基準

採用基準

湯本剛さんが講演で言及したこともあり、QA界隈で俄かに人気が急上昇した『採用基準』。

たしかに採用についての本ではあるのだけれど、軸にあるテーマは「リーダーシップ」だと思います。
企業面接で「あなたがリーダーシップを発揮した場面を教えてください」ってありがちで、あまり好きではなかったのですが、なぜそれを企業が求めるか少し理解できたように思います。

「リーダーシップとは、一握りのカリスマだけでなく、構成員みんなが具えているべき能力である」というのが主張の根幹。「これは自分の役割ではない」と「役割」にこだわって、文句だけ言っているような人ばかりだと、成功にはおぼつかないと断じています。

卑近な例がすごくわかりやすいです。
会議で持ち寄ったお菓子が多少余った時に、「お子さんのいるご家庭など、持ち帰りたい方はいますか？」と提案したり、タクシー待ちの長い行列で「同じ方向の方乗り合いしません？」と声を上げたりすること。これがリーダーシップ。

こんなのリーダーでも何でもないと感じるでしょうか？
「なるほど」となった方にも、「え？」となった方にも、ぜひ読んでいただきたい本です。

フィクション

三体0【ゼロ】 球状閃電

三体０【ゼロ】　球状閃電

三体3部作のメインキャラである科学者の若い頃を描いたもの。本編がすでに完結しているだけに、そこまで期待していなかったのが正直なところですが・・・
魅力的なガジェットが全編を通して主題になっているとともに、本編にしっかりつながる伏線。「その話につながるのか！ やられた！」となりました。
SFの一番おいしいところを堪能できる作品だと思います。

また、分厚いSFなのに読みやすい。原著者の文体と翻訳者のなせる業ですね。ありがたいことです。

ダーウィンズゲーム

ダーウィンズゲーム　１ (少年チャンピオン・コミックス)

スマホに突然届く「ダーウィンズ・ゲーム」の招待状。高校生・カナメは、わけもわからぬまま異能バトルに巻き込まれていく・・・というあまりにド定番な導入。
異能バトルモノに弱いわたしは、主人公補正の強さや能力のバランスの悪さを感じながらが淡々と読み進めていたのですが・・・、途中から様子が変わってきて、後半から「え？ これこういう展開になるの！？」となっていきます。

2023年の秋に完結したようですが、まだ読み終わってません！ 残りを読むのが楽しみです。
やっぱり、異能バトルものには男子の夢が詰まっているよ。

おわりに

2023年もけっこういろんな本を読んだなーと思いますが、やっぱりどこかで視野が狭められているんだろうなと思います。
突拍子もないところから本を勧めてくれるサービスとかあったら楽しそうですね～。
今年も読書を楽しみます！

Generated By Dalle