「過剰品質」とは一体何を指すのか

「日本の製品は過剰品質なのでコストが高くなり、グローバルで売るのが難しい」といった主張を聞いたことはないでしょうか。
このような主張がなされるとき、本当に現状を憂えている場合もあれば、「日本製品の品質の高さ」をどこか誇っているようなこともあります。

それでは、「過剰品質」とは何を指すのでしょうか。

品質特性と顧客価値

JaSST'24 北海道の発表資料*1で、当日言及できなかったスライドを、Twitterに放流してみました。

JaSST北海道では言及する時間のなかった、「過剰品質」についてのスライドの供養。
日本企業が過剰品質を自嘲する時、「当たり前品質」を頑張り過ぎる➋を言っているつもりが、実は「当たり前品質」も上がっていない➊になっていないか？というのが言いたかったことでした。

過剰品質とは？

かけた労力に対して、品質*2や顧客価値がどう変化するかでマトリクスを作ってみましょう。

価値 → 品質 ↓	上がっている	上がっていない
上がっている	理想的な状態	②自己満足
上がっていない	ありえない？	➀完全な無駄

おそらく、本来の意味の「過剰品質」は、②を指すのではないでしょうか。労力をかけて、製品を「良く」した、けれど顧客のうれしさにつながっていないと。
ただこれは、「顧客を見る・知る」ことで解決すべき、前向きな課題に思えます。

一方➀は、技術力の問題に帰着するかもしれません。
「テストケースは多いほど正義」「理由はわからないが、過去のリグレッションテストは決して減らすことができない」、こういった意識が根付いていて、「効果的なテスト」を追求する意志がないと、➀につながっていくのではないでしょうか？

自社ビジネス価値

上のツイに対し、こんなコメントをいただきました。

あとは、③として、品質も価値もあがってるがビジネスになってないというのもありそう。
耐久性上がって買い替えサイクルが長くなるとか、著しく人に依存した職人芸とか

これにはハッとさせられました。十分な時間をかけて品質を上げ、顧客も大喜び、でも自社は全然投資回収できていない・・。これでは本末転倒ですよね。

とくさんの例はすごくわかりやすいです。
「耐久性が上がる」、つまり品質が上がった、顧客も大喜び、しかし買い替えが起こらなくなるために、長期的には自社の首を絞めてしまう・・。
過去、某メーカーの何とかタイマーという都市伝説がありましたが、「あえて耐久性を制限する」（＝品質も価値も下げる）ことで、自社ビジネスの継続性を担保する、その代わりの他の品質特性で圧倒的な価値を与えるという戦略もあるのかもしれません。倫理とのバランスはあると思いますが・・。

ともあれ、自社にとってのビジネス価値。
言われてみれば当たり前ですが、「品質特性」「顧客価値」の2軸マトリクスで網羅した気になっていると見落としてしまう、大事な観点だと思いました。

他社ビジネス価値

ついでに、JaSST'24 TokyoでのGojko Adzicさんの基調講演で提示されたこの絵のことも思い出しました。

Gojko Adzicさんのモデル

見ての通りこれは、マズローの欲求5段階のオマージュで、下の方から順に満たされていくというモデルです。

第1階層は「デプロイできる、機能がまとも」ということで、本当に「最低限」です。マズローでいうところの「生理的欲求」に対応しています。
第2階層は「性能が出て、セキュアである」。マズローの「安全欲求」に何となく対応しているのが面白いところです。
第3階層は「使うことができる」。ここまできてようやく、製品としてまともになってきますね。
第4階層で「有用である」となってきます。SQuaREでいうところの「製品品質」から「利用時の品質」にシフトしている感じもあります。ただ、「製品」と「利用者」に閉じた話にも見えます。

第5階層はそれを飛び出し、その製品の利用を通じて「組織として成功しているか」*3に注目しています。利用者が製品を喜んで使っていたからといって、それがビジネスとしての利益に結びついていないなら、まだ道半ばということですね。これも、過剰品質の話につながってきそうです。

まとめ

過剰品質話は誰も得をしないので、「どんな価値につなげるために何をがんばるのか」は意識しておきたいところです。
また「自社あるいは他社が利益を得られるか」となると、（狭義の）品質からは話が飛び出してしまいますが、QAたるもの、こういう視点も持っていたいものですね。勝手に勉強になりました。

*1:元資料はコチラです。 speakerdeck.com

*2:本稿でいう「品質」とは、品質全体を構成する各品質特性のことです。たとえば、性能とか、使い勝手とか。

*3:講演と聴いた時には、「製品開発側の自組織が、その製品の提供によって成功しているか」という話に聴こえたのですが、ご本人のブログ記事を読む限りでは違うようです。 gojko.net

デシジョンテーブル超圧縮の夢に破れて

『ソフトウェアテスト技法練習帳』の勉強会で、めちゃくちゃいい質問がありました。

ソフトウェアテスト技法練習帳 ~知識を経験に変える40問~

その場で答えてはみたのですが、すごく大事な話だと感じたので、ブログ記事にしておきたいと思います。ただわたし自身の理解も足りていないかもしれないので、お気づきの点があればフィードバックお願いいたします。

3行まとめ

• デシジョンテーブルテストは、「複数の条件を組み合わせた場合の動作」を検証する技術である。
• 「組み合わせる前の単一条件の動作」は、デシジョンテーブルテストの前に検証しておく必要がある。
• デシジョンテーブルで2つ目もカバーできると思っていると、痛い目に合うかもしれない。

デシジョンテーブルの超圧縮!?

対象の問題は、本書「2.3 紳士服店の割引率」。
問題を雑に簡略化するとこうなります。

以下の仕様に基づいて、デシジョンテーブルを書け。
「ワイシャツとネクタイを含めて7点以上買えば、7%引きになる」

単純には、以下のようになります。
7点以上⋀ワイシャツあり⋀ネクタイあり ならば、7%引き。それ以外は割引なしと。
特にヒネリはありません。

	1	2	3	4	5	6	7	8
7点以上	T	T	T	T	F	F	F	F
ワイシャツあり	T	T	F	F	T	T	F	F
ネクタイあり	T	F	T	F	T	F	T	F
割引7%	T	F	F	F	F	F	F	F

これに対して、以下の質問をもらいました。

「ワイシャツあり」「ネクタイあり」の条件を別々にせず、「ワイシャツとネクタイが入っている」という1つの条件にしてはいけないのか。

なるほど。これをヨシとすると、以下のようになります。

	1	2	3	4
7点以上	T	T	F	F
ワイシャツとネクタイあり	T	F	T	F
割引7%	T	F	F	F

なんと、テストケース数が半分になりました！

ただそんなうまい話があるわけもなく、何か失っているものがありそうです。何しろ、これを突き詰めていくと、これでもいいのですからね・・・。

	1	2
7点以上でワイシャツとネクタイあり	T	F
割引7%	T	F

具体的なテストケースを考えてみると・・

さて、少し話が変わります。
デシジョンテーブルでテストケースを導出したとして、ではそのままテストができるでしょうか？

いいえ、必ずしもそうではありません。
たとえば最初のテーブルの#1のテストケース、「7点以上」という条件がTになっていますが、具体的には何点にしましょうか。また「ワイシャツあり」とありますが、ワイシャツは何点含めましょう。
てな感じで、実際にテストを行うにはもうワンステップ、テストデータの具体化が必要なわけです。

では、2つ目のデシジョンテーブル（以下再掲）のために、こんなテストデータを用意します。

	1	2	3	4
7点以上	T	T	F	F
ワイシャツとネクタイあり	T	F	T	F
割引7%	T	F	F	F

• #1: ワイシャツ×3、ネクタイ×3、ソックス×4
• #2: ソックス×10
• #3: ワイシャツ×3、ネクタイ×3
• #4: ソックス×3

もし実装が以下のようになっていれば、このテストはすべて通るでしょう。

7点以上 ⋀ (ワイシャツあり ⋀ ネクタイあり) → 割引7%

一方、以下のように実装が間違えまくっていても、このテストはすべて通ります。

9点以上 ⋀ (ワイシャツあり ∨ ネクタイあり) → 割引7%

デシジョンテーブルで網羅的にテストをしたはずなのに、一体、何が悪かったのでしょうか・・？

ブレイクタイムに書かれた重要な注意書き

実はこの2.3のコラム欄「ブレイクタイム」に、こんなことがさらっと書かれています。

デシジョンテーブルを使ってテストをしたからといって、十分にテストをしたとは言えません。なぜなら、デシジョンテーブルは条件の組み合わせを網羅するものであり、個々の条件をテストするものではないからです。

これは、単体テスト→統合テスト→システムテストと、小さな範囲のテストを積み上げていくことに似ています。部品の組み合わせのテストをする前に、部品自体のテストをする必要があるということです。

では、先のデシジョンテーブル（以下再掲）を元に、部品である個々の条件を調べてみましょう。

	1	2	3	4
7点以上	T	T	F	F
ワイシャツとネクタイあり	T	F	T	F
割引7%	T	F	F	F

条件「7点以上」

「7点以上」という単一の条件自体が正しく動作するかを確認してみましょう。
この場合は、デシジョンテーブル上で「7点以上」の値だけが結果に影響を与えるテストケースを選んで、境界値テストをすることができます。

	1	3
7点以上	T = 8点	F = 7点
ワイシャツとネクタイあり	T	T
割引7%	T	F

ここでもし実装が上述のように

9点以上 ⋀ (ワイシャツあり ∨ ネクタイあり) → 割引7%

と誤っていれば、#1のテストが失敗（割引7%がFになってしまう）で検知できることになります。

条件「ワイシャツとネクタイあり」

「ワイシャツとネクタイあり」という条件が正しく効いているのかの確認には、テストケース#1と#2を使います。

	1	2
7点以上	T	T
ワイシャツとネクタイあり	T ワイシャツあり ネクタイあり	F ワイシャツあり ネクタイなし ワイシャツなし ネクタイあり ワイシャツなし ネクタイなし
割引7%	T	F

そう、デシジョンテーブルの中で1つの条件に丸めることで、一見テストケースが減ったように見えましたが、部品の確認のために結局、ワイシャツとネクタイのあるなしの組み合わせを個別に確認する*1ことになるのです。

つまり、やるべき具体的テストケースの数は別に減っちゃいないということですねー。

まとめ

再掲。

• デシジョンテーブルテストは、「複数の条件を組み合わせた場合の動作」を検証する技術である。
• 「組み合わせる前の単一条件の動作」は、デシジョンテーブルテストの前に検証しておく必要がある。
• デシジョンテーブルで2つ目もカバーできると思っていると、痛い目に合うかもしれない。

勉強会での質問を受けて、あらためて認識しました。これを説明しているところって、意外に少ない気がしましたが、どうでしょう*2？

なお本稿は、ネモトノリユキさん、しましまさん、ブロッコリーさんにレビューいただきました。ありがとうございます。

追記 (2024/9/24)

秋山さんから以下のコメントをいただきました。

先に条件（condition）と判定（decision）を教えてからデシジョンテーブルテストの説明をしないとそう言う質問がくるかもですね。
疑問に思っても質問しない人が多いから良い質問だけれど。

— あきやま🏀 (@akiyama924) 2024年9月23日

ここでいう「条件」とは、「7点以上である/ない」「ワイシャツがある/ない」「ネクタイがある/ない」の、各単一条件を指します。
判定とは、単一条件を組み合わせた結果、「割引がある/ない」という判定がどうなるかを指します。

Generated By Dalle

*1:なし/なしを省略する作戦はありうる

*2:ブロッコリーさんから、『ASTERセミナー標準テキスト』に近いことが書かれている、とコメントいただきました。確かに演習問題の方のファイルP.23に、以下の説明がありました。

それぞれの条件に対して同値分割法・境界値分析を適用する。

QAエンジニアならきっと学びのある『地雷グリコ』を読んでほしい

突然ですが、わたしはギャンブル物のマンガが大好きです。ギャンブルは弱いんですけどね。
そんなギャンブル物のマンガ、フィクションは、大きく2つに分かれます。

1つは、主人公が強敵たちと戦いながら強くなっていくもの。
運要素もあるのですが、経験や精神力を駆使して戦うものです。ある意味、スポーツ物やバトル物に似ています。 既存ギャンブルを下敷きにしていることが多く、たとえば麻雀の『天』『アカギ』『凍牌』がそんな感じです。直感、情熱、精神力が武器。
ギャンブルを題材に、ストーリーを重視していることが多いので、「ストーリー型」と呼んでおきましょう。

もう1つは、指定されたルールの範囲内で頭脳戦を繰り広げるもの。
そのルールにおいていかに相手を出し抜き、うまく立ち回るかが勝負になってきます。作者の考えたオリジナルゲームが出てくることが多く、ある意味ゲームが主人公とも言えるでしょう。『ライアーゲーム』『トモダチゲーム』『ギャンブルフィッシュ』『賭ケグルイ』なんかはこ地川といえそうです。論理、冷静、心理戦が武器。
こちらは「論理型」と呼びましょう。

もちろんこの「ストーリー型」「論理型」という雑なくくりはグラデーションであって、「どちらか」ではなく「どっちに近いか」という性質のものです。
またそもそもこのくくりに収まらない作品もあるでしょう。たとえば『嘘喰い』は、ギャンブルの頭脳戦と暴力バトルを組み合わせたものでした。

天－天和通りの快男児　１

「論理型」の傑作・『地雷グリコ』

『地雷グリコ』（青崎有吾・著）は、まごうことなき「論理型」の大傑作です。

地雷グリコ (角川書店単行本)

5つの短編集が合わさって1つの作品になっており、それぞれの短編にオリジナルゲームが出てきます。そのゲーム達の素晴らしいところは、「誰でも知っているゲーム＋オリジナル要素」という作りになっている点です。

書名にも入っている「グリコ」とは、そう、「ジャンケンで勝った方が、グリコ・チョコレート・パイナップルと言いながら階段を上っていく」、あの「グリコ」なのです。
ここに、「プレイヤーがそれぞれ、3つの段を選んで”地雷”を設置し、相手プレイヤーはそれを踏むと10段下がる」というルールを追加しています。
さあ、たったこれだけで、一体何が起こるというのでしょう？

グリコは、これは子供の遊び。それゆえにルールはきわめてシンプル。そこに独自ルールを一匙混ぜることで、いきなり増す深み。たまりません。
『カイジ』の「限定ジャンケン」の衝撃を思わせます。
ジャンケンという世界中の子どもが知っているゲームに、「手を使える回数が限られ、かつ時間内にその回数を使い切る必要がある」というシンプルに見えるルールを加えただけで、想像もつかない世界を描き出しました。これってまさに、「既存のものを組み合わせて新しいものを生み出す」イノベーションでは？

賭博黙示録 カイジ　１

『地雷グリコ』は、そのイノベーションを5つ生み出しています。
出てくる「元ゲーム」は以下の5つ。

• グリコ
• 神経衰弱
• ジャンケン
• だるまさんがころんだ
• ポーカー*1

この手のって、タイトルになっている表題作だけが面白くて、後は「無理やり作ったな～」感が出がちなのですが、『地雷グリコ』は全部面白いんですよね・・。
そしてこの手のって、ギャンブルは面白いけど、文章や描写がへたくそ過ぎて・・というガッカリケースがあるのですが、文章も描写も上手で、読みやすいんですよね・・。また一人称を都度切り替える手法も、ギャンブル物フィクションとかなり相性がいいんだなと感心しました。

「論理型」ギャンブルフィクションは、何らかの言及がそのままネタバレになってしまいそうでなかなか紹介しづらいのですが、「誰でも知っているゲームをちょっと拡張して深いゲームにし、そこで緻密な頭脳戦を繰り広げる傑作」ということで、すごくオススメです。

論理型ギャンブルとQAエンジニアは相性がいいのか

さて、ではなぜ、『地雷グリコ』がQAエンジニアにオススメなのか。

論理型ギャンブルでは、「自然言語で」「ある程度複雑な」ルールが提示されます。プレイヤーはそのルールを深く理解し、ルールに隠された意図や曖昧さを見抜き、ゲームにおいて何が起こり得るかを吟味して戦略に組み入れます。

ソフトウェアテスト*2では、これも「自然言語で」「ある程度（時には過剰に）複雑な」仕様が提示されます。QAエンジニアはこの仕様を十全に理解し、設計者の意図を把握して曖昧さを排除しながらも、実際のユーザやその環境において何が起こり得るかを検討してテスト設計に組み入れます。

この「抽象的な記述から、ありうるケースを列挙して具体的に記述する」、「特にレアかもしれないけれど、起こり得るケースを見逃さない」というところが、両者ですごく似ていると思うんですよね。

両者の対比を表にしてみましょう。ついでに、「詐欺」列も入れておきます。こうやってみると、QAエンジニアは詐欺向きなのかもしれません（突然の暴言）。

項目	論理型ギャンブル	プロダクト開発	詐欺
熟考する対象	ルール	仕様	法律
立てる作戦	戦略の検討	テストケースの作成	詐欺シナリオの作成
行うこと	ルールの穴を見つけて武器し、相手に勝つ	仕様上起こり得る可能性を見つけてテストする	法律の穴を見つけて相手を騙し、金を儲ける
心理	相手の思考を読み、誘導する	ユーザが自然に思考するであろうことを想定する	相手の思考を読み、誘導する
バトルする主体	プレイヤー vs プレイヤー	QAエンジニア vs プロダクトの可能性やユーザの多様性	詐欺師 vs 被害者

QAエンジニアの思考の習慣として、たとえばこんなものがあると思います。

1. 数字の範囲を見たら、上限と下限を確認しろ
2. 見慣れない用語を見たら、定義を確認しろ
3. 条件を見たら、MECE性*3を確認しろ
4. 「ただし」で始まるような補足、例外的なルールほど深く掘れ
5. 開発者視点ではなく、ユーザがどのように考えるかを考えろ*4
   …

論理型ギャンブルでも、これをそっくりの思考過程が起こります。
たとえば『天』（福本伸行・著）に「クリア麻雀」という戦いがあるのですが、まさにこれに類する驚きの結末が待っていました。脚注にネタバレを書いておきます*5。

『地雷グリコ』はまさに、起こるうること、起こせることを徹底的に吟味し、それを実際に起こすことで戦いを進めていきます。
読めば、わたしが無理やり2つを結び付けているわけではないとわかっていただけるでしょう。

天－天和通りの快男児　１

おわりに

論理型ギャンブルのフィクションって、本当に面白いですよね。最近は、『ジャンケットバンク』をお勧めしています。

ジャンケットバンク 1 (ヤングジャンプコミックスDIGITAL)

*1:ポーカーだけある意味「本格ギャンブル」ですが、手がかなり簡略化され、シンプルにされています。

*2:レビューでも同じことをします。

*3:「Mutually Exclusive and Collectively Exhaustive」、モレなくダブリなく。

*4:ソフトウェアテストでは、「心理戦」「裏をかく」は起こりませんが、「ユーザはどう考えるだろうか」「どのように振る舞うだろうか」という想定しますよね。その意味でも似ていると感じます。

*5:クリア麻雀の勝利条件は、以下の2つのいずれかを満たすことでした。➀指定された5つの役をすべて完成させること ②相手陣営のプレイヤーの持ち点を0点未満にすること。ですがこの➀と②は、排他ではありません。主人公が5つ目の役を完成させ上がった（➀を満足）時の点数が高すぎて味方の持ち点を大きく減らしてしまった（相手が②を満足）ため、勝利条件と敗北条件を同時に満たすというイレギュラーが起きました。一見排他に見える条件が同時に起こる可能性の考慮は重要です。

仕様スニペット004「サブスクリプションの自動更新」の #テスト設計パターン を考えてみる

JaSST北海道にかかりっきりで、テスト設計パターンに手をつけられていませんでした。
が、テスト設計パターンを考えることは、テスト設計という分野を今後充実させていくためにけっこう大事なことなんじゃないかと思っているので、仕様をもらえたら続けます。誰か、いい感じの仕様をくれ！！

docs.google.com

「テスト設計パターン」「仕様スニペット」って何？という方は、こちらの記事を先にご覧くださいね。

www.kzsuzuki.com www.kzsuzuki.com www.kzsuzuki.com

仕様スニペット004: 「サブスクリプションの自動更新」

第3回に続きこのネタも、かいりさんにいただきました。

以下に示す「サブスクリプションの自動更新」の仕様について、テスト観点を考えてください。

1. サブスクリプションプランには、月次更新と年次更新がある。
   • 2024年1月1日に月次更新プランに登録した場合、次は2024年2月1日に更新される。
   • 2024年1月1日に年次更新プランに登録した場合、次は2025年1月1日に更新される。
2. サブスクリプションの更新は、毎日定時にバッチ処理で実行される。
   　ただし、特定の日付を指定して実行することもできる。

回答の例

鈴木の場合

やっぱり一番気になるのは日付なので、日付にフォーカスして考えてみました。

そもそもこの仕様1には「例示」があるだけで「ルール」が明示されていません。仕様を記述するうえでは、まずルールがあって、その理解を助けるための補足としての例示があるべき（個人の感想です）なので、例示しかない時点で設計した人と会話すべきでしょうね。

とはいえ今回は、

• 月次更新の場合は、登録日の月mに1を足して yyyy年m+1月d日 に更新
• 年次更新の場合は、登録日の年yに1を足して yyyy+1年m月d日 に更新

するのだろうと考えてみます。
パッと思いつくのは、以下の観点です。

• m=1 なら m+1=2 でいいが、m=12 なら m+1 = 13 になってしまう。つまり、「年をまたぐ月次更新」はやりたい。
  • 同じ発想で、yの上限も考慮すべきかもしれないが、リスクは低い？
• d = 31, 30, 29 のない月がある。
  • 月次更新の場合: 1/31、1/30、1/29（非うるう年）、3/31などは、mに1を足してもらうと該当する日付がない。
  • 年次更新の場合: 2/29（うるう年）などは、yに1を足すと、該当する日付がない。
• そもそも、登録した日付によってサブスクリプションの有効日数が異なることがおかしいのでは？
• タイムゾーン、サマータイム、時差までは考えすぎ？

仕様2の方もいろいろありそうですが・・・。

𝓜𝓪𝓼𝓪𝔂𝓾𝓴𝓲 𝓣𝓪𝓬𝓱𝓲𝓫𝓪𝓷𝓪 さんの場合

https://x.com/taiden32/status/1800775149245051085

気になる点として、閏秒及び閏年のテストがどうなるのかというのと、2/29に初回登録した時の年次更新がどうなるのかが気になりました。

うるう「秒」までは考えていませんでした。60秒の次に00秒があるケースを考慮要・・・？

やまずん さんの場合

https://x.com/55_ymzn/status/1802702136222040173

字数内ジャストアイデアで
・定時のバッチ処理なので、何件くらい処理できるかの負荷的なところを見たいです。
・更新ということなので、登録だけでなく解約があると思いますがこの辺の動作も見たいです。
・日次処理ってことですが、31日に登録した場合、次はいつになるのかが気になります。
・うるう

わたしがサボった仕様2について、非機能要件をカバーしてくれました。

また、仕様に書かれた「登録」「更新」と本来セットになるべき「解約」について言及してくれています。CRUDのように、この手の「考えられる操作の一そろい」を考えることはとても大事ですね。すると同時実行を連想して、更新のバッチ処理と解約処理を同時に行ったらどうなる？と考えていくことになると思います。

アシカ さんの場合

https://x.com/tyngw/status/1802826438825086978

解約や継続しないを選んだ後に、次回更新タイミングまでサブスクリプションを利用できることは確認したいです(よく私自身やる操作なので)

これ、わたしも今、某アンチウィルスソフトでこの状態ですｗ 「おいおいおいおい、もうすぐサブスクリプション期限が切れるぞ、後悔しないか？」って毎日詰められています。

やまずんさんと同じく、仕様に書かれた話からは外れるんですが、このように思いついたことを設計した人とぶつけあって、仕様を形にしていくのがわたしは好きです。

https://x.com/tyngw/status/1802829701880373656

特定の日を指定して実行というのがなかなか癖がありそう。
定時処理に失敗して、過去に遡って実行はありそうだけど、未来日も指定できるのかは気になります。

仕様2の「ただし」に書かれた手動実行、確かにバグの香りしますね。
今回はかなり情報が少ないのですが、「そもそも何のために必要な機能なのか」という目的に立ち返ることが必要な内容に思えました。

Hideo Oide さんの場合

https://x.com/hide_ramen_san/status/1802712643784024396

決済方法によるんですが、クレジットカードの有効期限切れは確認必要ですよね。

この発想は全然していませんでした。。いや、「更新が失敗するケース」は当然考えるべきなのですが、「日時」に注目しすぎている自分がいる。。
もちろん失敗はいろんな段階で起きうるでしょうから、各段階の失敗ケースをテストする必要がありますね。

おわりに

このシリーズも第4回なのですが、どうしても「情報が足りない」「仕様がよくない」の方に向きがち・・・。
いや実際そのケースもあるんですが、「テスト設計」が半分になってしまうから難しいなあ。
みなさん、もっと仕様を！

Generated By Dalle

2024年前半に読んで特によかった本

もう8月も終わりますが、2024年前半に読んだ本を振り返って、よかったな～と思うものを記録しておきます。

ソフトウェア開発

継続的デリバリーのソフトウェア工学

継続的デリバリーのソフトウェア工学　もっと早く、もっと良いソフトウェアを作るための秘訣

わたしの周りにも優れたスクラムコーチがいて、従来の発想から脱しきれないわたしに、アジャイルのエッセンスや考え方を辛抱強く共有してくれています。
そのうえで読む『継続的デリバリーのソフトウェア』は、わたしの蒙をさらに啓いてくれる良書でした。

実験主義、経験主義という言葉を軸に、「なぜアジャイルが今のような形になっているか」を繰り返し（時に冗長に？）教えてくれます。また「工学」というだけあって、単に思想的な部分だけでなく、技術的な説明も豊富です。

第4章のこのフレーズが、とても印象的です。

イテレーションの本質は、私たちが誤りを犯し、犯した誤りを正すことを認めることであり、学びを発展させ、広げていくことを認めることです。

ちょうど「失敗」について学んでいて、「失敗をどう生かすか」を考えていたわたしにとって、「アジャイルって、失敗を繰り返しまくるアプローチなんだ！」と膝を打ったのでした。
「アジャイルって、ウォーターフォールを短くして、エンジニアが好き勝手にやってるやつでしょ？」と考えがちな方にお勧めします。

ノンフィクション

評伝クリスチャン・ラッセン

評伝クリスチャン・ラッセン　日本に愛された画家 (単行本)

クリスチャン・ラッセンという名前につきまとう、どこかうさんくさい雰囲気。そのラッセンを神格化するのではなく、そのうさんくささが何に起因するのかに踏み込んでいるのが、『評伝クリスチャン・ラッセン』です。

ラッセンの流行り廃りにとどまらず、「平成」という時代との関連性、本流美術からの扱われ方、かつて亡きものにされた戦争画との類似性など、思った以上に広いトピックを論じていて面白い。
たとえば「CR・ラッセンワールドMJ」というパチンコ台。これを単にラッセンの凋落とみるか、もっと別の背景・文脈があるとみるかで、本書では後者の立場を取っています。

日本における美術の位置づけについてもよく解説されており、タイトルで敬遠するのはもったいない良書でした。

深夜特急

深夜特急1―香港・マカオ―（新潮文庫）【増補新版】

『働かないふたり』という素晴らしいマンガがあるのですが、その主人公の一人である読書好きの兄が読んでいた本。

いやーこれは・・・。旅の良さがここに詰まっている。
大学時代にこんなの読んでしまったら、熱に出したように旅に出てしまうんだろうなと思います。

ただ、この本で描写されているような「旅」は、現代では実現できないかもしれないなあと寂しく思ったりもします。今ほど海外旅行が当たり前でなかった時代の、無計画な旅。せめてその擬似体験を楽しめる。そんな本です。

働かないふたり　1巻 (バンチコミックス)

学問

詭弁論理学

詭弁論理学　改版 (中公新書)

名前は固いのですが、自然言語や論理パズルなどを扱った本です。タイトルの通り、詭弁もたくさん扱っていて、その例にいちいち腹が立ってしまうのが難点です(笑)。

以下は、「相殺法」という詭弁の例。

「わたしの家の前に車を停めちゃ困るよ」
「おまえは車を停めたことがないのか？」

イラァ・・・。

ぶっちゃけ、詭弁ってけっこう強い武器なんですよね。聞けば誰もが「こいつの言い分は何かおかしいぞ」って感じるので、詭弁の使い手は嫌われる。でも、その武器の性質を知っておかないと反撃することができず、その場では言いくるめられてしまう。なので、身を守るために詭弁を知っておくことは重要だと思います。
またこの本はタイトル通り、「論理」の本でもあるので、論理学についても学ぶことができますよ。

詭弁といえば、このツイのクロコダインの詭弁(?)、とても好きです。

ここ地味に話通じて無くて好き。
バランは「ギガブレイクが直撃したらいくらお前でも即死だろ！？回復できる事がそもそもおかしいんだけど！？なんで死なないの！？」って言ってるのに、
クロコダインは「死ななければ回復できるから死なないように全力で頑張ったぞ！」って言ってて会話になってない。 pic.twitter.com/jVds63bUhM

— 私の好きなもの友の会 (@QRUKfCwr) 2024年4月21日

ビジネス

人生が整うマウンティング大全

人生が整うマウンティング大全

『会議でスマートに見せる100の方法』が好きな人ならきっと気に入る、ジョークビジネス書です。
読んでいると、「ああ、いるいるこういう人！」となったり、「あ、これ自分もやってるかも・・」となります。
たとえば「時差ボケマウント」。

ロンドン→ニューヨーク→シカゴ→東京を1週間で回ったせいで、時差ボケのオンパレード。学生時代に夢見た世界一周はこんなんじゃなかった。

この「嘆いている感じ」がまたいやらしいんですよねえ・・！

これらの「事例」だけでも面白いのですが、第3章。ビジネスにおけるマウンティングの位置づけを、非常にそれっぽく語っています。
虚構新聞の文が本物の新聞みたいであるように、第3章は「いかにもビジネス書にありそうな言い回し」がすごい。たとえば

「マウント消費」の活性化が長期的な経済成長をもたらす
:
官民一体となって、マウンティングを起点とする日本発のイノベーションを生み出す枠組みを整備することが求められる。
:
マウンティング欲求を「手放す」のではなく、マウンティング欲求を「味方につける」ことを意識することを始めてみるといいだろう。

とっても、っぽくないですか？ こういうの大好きです。

会議でスマートに見せる100の方法 (早川書房)

フィクション

FX戦士くるみちゃん

FX戦士くるみちゃん　1 (MFコミックス　フラッパーシリーズ)

表紙で敬遠する人もいると思うのだけれど、「投資」をしている人なら胃痛が止まらない、FX投機のマンガです。とんでもない速度で含み損が増えていくシーン、チャートが思惑とは違う方向に突き抜けてしまう描写、もう見てられません。見てられないと言いながら、この作品と衝撃描写が癖になって、何度もリピってしまってます。。

「投資で人生一発大逆転できるのでは？」
「5%の利益を20回繰り返せば資産が2.5倍になる・・？」
などというグッドアイデアを思いついた人に読んでもらいたいマンガです。

AIとSF

ＡＩとＳＦ (ハヤカワ文庫JA)

AI大勃興時代の今まさに読んでおくべき渾身の短編集。
自分たちが生きている間に起きても何ら不思議のない事象、しかしまだ見たことのないはずの出来事が克明に描かれています。もちろんSFとしても面白い作品ばかり。特に生成AIの登場は、SFの世界を広げていると感じます。
これらはSFというより、「確定した未来」なのかもしれません。その意味で、ソフトウェア開発に関わっている人ならきっと楽しめる本だと思います。

不思議なのは、示し合わせたわけでもないだろうに、AIと仏教を組み合わせた作品が3つもある点。「意外なものの組み合わせ」はアイデアの基本とはいえ、組み合わせてみると何とも味わい深いです。

「仏師達は同時に仏像のAIへと真言(プロンプト)を彫り込んだ。」（『月下組討仏師』）

いや、熱過ぎる・・。

幻夏

幻夏 (角川文庫)

これまでに読んだミステリーの中でも屈指の、「完璧な」作品の一つ。
警察が中心になるミステリーということであまり期待せず読んだのですが、素晴らしい作りでした。警察と司法が抱える問題を訴えながら、恐ろしく美しく回収されていく伏線、ミステリーとしての面白さなどが完全にマッチした作品です。

一方で、読んでいて苦しくなる作品でもあります。特に子供の話なので、親の立場になるとつらいです。
ただそれでも、単なるエンターテインメントに留まらないこの小説、ぜひ読んでもらいたいです。

おわりに

いやぁ、本って本当にいいもんですね。
2024年後半も、たくさん本を読みたいと思います。