2023年に読んで印象に残った本、読書に関するふりかえり
年の瀬なので、今年読んだ本のふりかえりをば。それではレッツゴー！
実践的データ基盤への処方箋
会社でデータ基盤周りのことを考える機会があったので読んだ。データ基盤素人にもわかりやすく書かれていたと思う。最初の一冊として良いというのを同僚のデータエンジニアからも言われた。
『実践的データ基盤への処方箋』ざっと読んだ。データ基盤周りまったく土地勘がなかったのでだいぶイメージつきやすくなった感じ。かなり記述は（アプリケーション開発者が読む場合は）親切だと思った。
— こま (@koma_koma_d) 2022年12月11日
Webブラウザセキュリティ
認証認可周りを触る機会があったので読んだ。Webアプリケーションのセキュリティに関しては徳丸本などもあるけど、この本はブラウザに特化していて仕様の話なども充実しているので面白かった。
図解即戦力 暗号と認証のしくみと理論がこれ1冊でしっかりわかる教科書
これも認証認可周りを触るときに読んだ。「図解」とあるので初歩的なものをイメージしがち（自分はそう）なのだが、これはなかなか骨太で、数学的な部分も入ってくる。しかしそれでいて読みづらくはないというのが素晴らしいと思う。
誤謬論入門
ブログにしたもの。IT系とは別のところで反響が大きかった。インターネット上の言説に違和感を感じるときにこの本の整理を参照すると少し違和感をクリアにできる。
アジャイルプラクティスガイドブック
Rettyの常松さんの著書。スクラム関係の本やアウトプットが多いのに対して、アジャイルの技術的プラクティスについてはあまりまとまった形で出てくることがないなと感じているなかで、待望の一冊だった。
アジャイル開発をする上で悩んでいることがある開発者のみなさんは自分も運営で関わっているScrum Developers Night!をよろしく（以下のページは前回開催時のもの。次回開催の案内は2月を予定していますので、Scrum Masters Night!*1のconnpassのグループに参加して通知をお待ちください）。
世界一流エンジニアの思考法
マイクロソフトの牛尾さんの著書。noteやブログで牛尾さんがどういうことを感じている/考えているのかは以前からウォッチしていたが、それが書籍という形でまとまったもの。想定読者としては現場のエンジニアよりも「管理者」向けの側面が大きい（倉貫さんの『人が増えても速くならない』に近いものがある）と感じるのだが、最初の方に書かれている牛尾さんの周囲の優秀なエンジニアの行動パターンの話は非常に興味深く読んだ。
特に、「理解に時間をかける」という話が印象的だった。自分の所属する会社でも学習への投資が積極的に行われている（下記のブログ参照）のだが、ついつい目の前の仕事を前に進めるために不十分な理解を放置して進んでしまいがちだと感じていたのだが、やはり理解に時間をかけてスキルを伸ばすことが将来的にいい仕事をするためにも必要で、自社のマネージャーもそれを期待しているということもあって、この本を読んだ頃からは以前よりも「理解に時間をかける」ようになった（もちろん時にはスピードを重視しないといけない場合もあるだろうけど）。
Linuxのしくみ
こちらもブログにしたもの。秋以降は『プログラマーのためのCPU入門』、『コンテナセキュリティ』、そして現在は『詳解システム・パフォーマンス』と（アプリケーション開発者から見た）低レベルのところに意識的に取り組んでいる。記事にも書いたが、最初に読む本として『Linuxのしくみ』は非常におすすめ。
プロダクトマネージャーのしごと
自分はプロダクトマネージャーではないが、プロダクトマネージャーに限定されない仕事の考え方の話も書かれているという評判を目にして読んだ。たしかにそういう側面もある本で、時々読み返す本になりそうだと思った。
特に印象に残っているのは「過剰コミュニケーション」の話と、
『プロダクトマネージャーのしごと』を読んでから、これまで以上に「当たり前のことをあえて質問する」「みんな認識してそうなことをあえてもう一度言う」というのを意識的にするようになった
— こま (@koma_koma_d) 2023年11月17日
「最初のドラフトは1ページで、作るのに1時間以上かけない」という話。
数年前、私はビジネスパートナーたちに「チームにドキュメントに使う時間と労力を減らせとコーチする割には、いまだにあなた自身は内部ミーティング資料を念入りに作り込んでいるんですね」と指摘されました。私が「当然ですよ。あなたたちは優秀だからいいけど、私は仕事をちゃんとやってるって思わせたいんです」と言うと、全員が一瞬固まりました。「はぁ」。
（『プロダクトマネージャーのしごと』p.154）
2024年に向けて
来年の4月でソフトウェア開発者として働き始めてから7年が経つことになる。
ソフトウェア開発関連の書籍を読むことはキャリア初期から自分を大いに助けてくれてきたのだが、この1,2年くらいは仕事で向き合う課題が単なる知識不足では解決できないものが多くなってきて、以前ほど書籍を読むことの意義が感じられなくなってきている側面があり、以前ほどたくさん本を読まなくなっていた（2022年末のサッカーW杯でサッカーにどハマりして休日の夜が欧州サッカーで消費されるようになったのと、2023年1月クールのアニメ「お兄ちゃんはおしまい！」で声優・アーティストの石原夏織さんのファンとしての動きを再開したのとで、そもそも学習にかける時間が減ってしまったというのも大きいのだが）。
![石原夏織 5th Anniversary Live -bouquet- Blu-ray【特装版】(特典なし) [Blu-ray]](https://m.media-amazon.com/images/I/41nK4EjQIoL._SL500_.jpg "石原夏織 5th Anniversary Live -bouquet- Blu-ray【特装版】(特典なし) [Blu-ray]")
しかし、2023年後半からはややバランスを取り戻して、学習への時間を増やし始められている。書籍を読むことで解決する仕事上の課題が増えたわけではないのだが、周りのシニアなエンジニアと話していると自分が知らないことをたくさん知っているなと感じることが多くあるので、仕事基準ではなく人基準で足りないところを埋めていこうと思って勉強をしている。
また、↓で書いた毎日1ページでもいいので本を読むという活動に参加したこともいいきっかけになっている。やはりピアプレッシャーは習慣化の大きな助けになる。
某コミュニティの人たちと一緒に「毎日1ページでもいいので本を読もう」というのをやっていて、自分はこれまでに、
— こま (@koma_koma_d) 2023年12月21日
・『プログラマーのためのCPU入門』
・『コンテナセキュリティ』
・『男性の繊細で気高くてやさしい「お気持ち」を傷つけずに女性がひっそりと成功する方法』…
この活動は「みんチャレ」というアプリを使ってやっていて、5人1組でヨーイドンで始めるものなので現在自分の参加しているグループに追加で参加してもらうことはできないのだが、仲間さえ集まれば簡単に（アプリは無課金でも利用できる）始められるので、興味がある人がいたら周囲の人に声をかけてみるといいと思う。
そういうわけで、2024年はより一層ペースを守って勉強することを重視したいと思います。みなさん良いお年を。
*1:Scrum Developers Night!はScrum Masters Night!の派生イベントで、同じconnpassに同居しています。Scrum Masters Night!もエンジニア歓迎だと思うのでそちらもぜひどうぞ。
1年間積読になっていた『Linuxのしくみ』を読んだ
この記事は、「積読 Advent Calendar 2023」6日目の記事です。
昨日の記事は @hanhan1978 さんの記事でした。
『［試して理解］Linuxのしくみ ―実験と図解で学ぶOS、仮想マシン、コンテナの基礎知識【増補改訂版】』を読みました。発売日は2022年10月17日で、発売されて割とすぐに買った記憶がある（現在は3刷までは少なくとも出ているようだが、手元にあるのは1刷）のですが、1年経ってようやく読みました。
なぜ買ったのか
自分の主戦場とする領域の1つ下のレイヤの知識を知っておきたかったからです。
自分は普段、Webアプリケーションの開発をしていて、バックエンドを主に触っています。学生時代の専門は情報系ではなく、成り行きでソフトウェア開発の会社に就職することになってからプログラミングを学びました。
就職してからは、コードの書き方や設計の考え方、あるいは開発プロセスについて関心が強く本をよく読んでいたほか、仕事で使うミドルウェアやツールをユーザーとして学ぶ（ex. MySQLのインデックスの使われ方や最適化がどうとか）ことはあったものの、インフラのレイヤのことをちゃんと学ばない（仕事で接するたびにその部分だけ調べる程度）まま生きてきてしまいました。目の前の仕事をこなすだけならそこまで困るわけではないのだけど、技術者としてはやはりそこもわかるようになっておきたいなという思いを持っていました。
同じ背景で、少し前（2022年1月に読み終わっているようです）に『コンピュータアーキテクチャのエッセンス』は読んだものの、ハードウェアの話が中心なので正直ピンと来ず、自分の普段触っているレイヤとの隣接性も感じられなかったため、消化不良のままになっていました。
そんな中で、『Linuxのしくみ』の増補改訂版が出るよ、カラーになって読みやすいよ、プログラマにもおすすめだよ、というのをTwitterで見かけて、これだったら興味を持てるかもしれないと思って買ったのでした。
なぜ1年間積んでいたのか
ここ1年、単純に本を読む量が減ってしまっていたというのがまず大きいです。理由は色々とありますが、これを書き始めると長くなるので省きます。
他には、やはり「仕事に短期的に直結しない本なので後回しになってしまった」というのもあります。そもそもの動機からして、「毎日の仕事をこなす分にはそこまで困っていないんだけど、読んでおきたい」という切迫感の弱いものだったし、仕事に直結する勉強（たとえば、アプリケーションの認証認可の部分を実装するにあたって、OAuthやOIDCの勉強をしたり、『暗号と認証のしくみと理論がこれ１冊でしっかりわかる教科書』を読んだり）と比べて具体的なきっかけを普通に仕事をしているだけで得ることが少ないので、一度積読になってしまったあとは手付かずになっていました。
なぜ今になって読んだのか
直接のきっかけは、最近仕事をしている中でスレッドやコンテキストスイッチの話を同僚とする機会があったからです。
幸いなことに現在同じチームで働いている同僚には低レベルのことをよくわかっているシニアなメンバーがいて、チーム内のコードレビューやモブプログラミングでそこの知識も踏まえて話をしてくれるのですが、「おっ、今この人の言っていることがわからないぞ」と思わされることが時折ありました（その都度説明してもらったり調べたりはする）。
そんな中で、先日スレッドやコンテキストスイッチの話になり、ぼんやりとはわかっているが理解度が全然足りないなということを改めて感じたので、重い腰を上げて読み始めました。
感想
非常に読みやすかったですし、自分が知りたいなと思っていたところを知ることができました。
「実験と図解で学ぶ」とあるように、文章での説明に加えて実験と図解が豊富にあるのですが、特に実験のパートが「サンプルコードとその出力」というプログラミング言語の書籍でよくあるものに留まっておらず、レイテンシやリソースの使用量などのデータを表やグラフにして掲載していたのが良かったです。仕組みを図や文章で説明するだけでなく、「その結果として、実行した際にどのような挙動になるのか」まで理解させてくれるのがこの本の良さだと感じました。
終章では、この本を読んだ後にどんな勉強をするとよいかという紹介がありましたが、自分の場合はWebアプリケーションの運用と開発のための知識・スキルをつけていきたいので、巨大積読である
- Brendan Gregg『詳解システム・パフォーマンス 第2版』*1
を次は消化していきたいと思います。来年は積読を増やさず、これまでに積んできた書籍を着実に読んでいくぞ……！
『Linuxのしくみ』と前後して、関連する内容のある以下の本も読みました！積読を解消しているぞ！！！
- Takenobu Tani 『プログラマーのためのCPU入門 ― CPUは如何にしてソフトウェアを高速に実行するか』
- Liz Rice『コンテナセキュリティ』
*1:原書が『Linuxのしくみ』の終章でも紹介されていました。翻訳が出たのは今年になってからですね。
ICとEMの狭間を揺蕩っている（会社ブログにインタビュー記事が載りました）
掲題の通り、会社のブログにインタビューしてもらった記事が載りました。
会社の開発組織の価値観を言語化・明確化していこうぜという取り組みの一環で、インタビューをしてもらった記事が出ました！ぜひ「偉そーなこと喋ってんな！」とツッコミを入れながらお読みください！bioに書いている「ICとEMの狭間を揺蕩っている」がどういう趣旨なのかが伝わると思います！ https://t.co/kYhnl9lkWa
— こま (@koma_koma_d) 2023年9月5日
組織の一員として語るべきことは記事中で語っていますので、そちらをぜひご覧いただきたいのですが、せっかくの機会なので記事には載らなかった個人的な話を少し書いておこうかと思います。「あれ、エンジニアリングマネージャーなりたいっていってなかったっけ？」という話です。
記事では、2020年4月に現職に入社してから社内でどのようなことをしてきたかを、開発者としての開発チームでの仕事以外の部分にフォーカスを当てて話しました。一般的にはエンジニアリングマネージャーなどが関わることが多そうな領域に、IC（Individual Contributor）の立場にありながら関わっていることがわかるかと思います。
Twitterなどではしばしば語ってきたところですが、2017年4月に新卒でソフトウェア開発者としてのキャリアをスタートしてから、1年経たないくらいの時期にあった2冊の書籍との出会いが自分のこれまでのキャリアにとっては大きなインパクトをもたらしました。いずれも2018年2月に出版された『カイゼン・ジャーニー』 と『エンジニアリング組織論への招待』です。
プログラミング未経験で開発者として就職して、「これからは技術で仕事をしていくんだな」と漠然と考えていた自分にとって、ソフトウェア開発の世界で、いわゆる「技術」とは異なるトピックが存在していて、どうやらそこがうまくいかないことで苦労することも少なくなく、その部分の問題解決のスキルを強みとして仕事をしている人たちがいるらしい、ということを知ったのがこの時期でした。
これらの書籍との出会いをきっかけに、アジャイルやマネジメントなどのコミュニティに出入りするようになり、自分よりも少し先輩に当たる人たちとの関わりができました。そうした人たちとの交流から、自然とアジャイルコーチ/スクラムマスターやエンジニアリングマネージャーといった仕事に興味を持つようになりました。現職に入るときも、そういう志向を口にしていたような気がします。
で、現職に入ってからほぼ3年半経つのですが、エンジニアリングマネージャーにもなってないし、スクラムマスターロールで仕事をしているわけでもないのですよね。どうしてこうなった？
理由は色々あります。一つの理由は、記事の中でも話しているように、現職の組織文化として「マネージャーだからこれをやる」という発想が弱く、「必要だと思ったらロール関係なくやればいいでしょ」という感じなので、元々やってみたいと思っていた活動にエンジニアリングマネージャーにならなくても携わることができているというのがあります。もちろん評価などの権限はないのでそういうことはやっていないのですが、採用面接に出たり、組織改善の取り組みに関わったりと、そこそこやりたいことができているわけです。
他には、現職で働いている中で、自分の技術スキル不足が仕事を進める上での1番のネックだなと感じる経験を多くしてきたというのもあります。開発プロセスなどのことは色々と勉強してきたので、その観点から改善を図るというのは必要であればやるし、実際にうまくいったことも多いのですが、それ以上に「自分がもっとコードをゴリゴリ書けたら前に進んだのに」などと思う機会や、チームが停滞しそうになったところを技術力（時に筋力）で突破 する同僚の姿をみる機会が多く、「もっとこっちの力を身に付けた方が自分の満足のいくパフォーマンスが仕事で出せるんじゃないか？」と思うようになりました。
「将来エンジニアリングマネージャーやるならこれくらいは技術も知っておきたい」というふうに考えて技術の勉強をするという話もよく見ますし、自分もそういうふうに物を考えることもありますが、それ以上に「仕事を前に進めるために自分がもっと持っていたら良かった力はなんだろう？」というところで、いち開発者としてのスキルをもっと磨きたいと考えて、正式にエンジニアリングマネージャーというロールを担いにいくことをしていないということです。
まぁそういうわけで、ICとEMの狭間を揺蕩い続けているわけです。
自分と似たような志向を持っていた（多分年齢の近い）開発者の人がエンジニアリングマネージャーになって活躍している姿をみて「自分はこれでいいんだっけ？」と思うことももちろんありますし、マネジメント以外の領域で一芸に秀でている人に憧れる思いもありますが、少なくとも「こっちに進んでいればよかった」という後悔は今のところはないので、それは幸いなところだなぁと思います。
とはいえ、今後どういう方向に進んでいこうかというのはやっぱり悩みどころですし、考えていかねばならんなぁとも思っています。 知人の皆様におかれましては「軽率に」飲み会に誘うかもしれませんのでどうぞよろしくお願いします。
#軽率に飲み会に誘われたい ってハッシュタグ流行らないかな？
— きょん＠アジャイルコーチ、システムアーキテクト (@kyon_mm) 2023年8月5日
『誤謬論入門 優れた議論の実践ガイド』を読んだ
3月に発売されたばかりの『誤謬論入門 優れた議論の実践ガイド』（原題：Attacking Faulty Reasoning）*1を読んだ。
原書は、非形式論理学・クリティカルシンキングの教科書として使われているもので、初版が1980年、今回の翻訳の底本となっている第7版が2013年の出版と、帯に謳われている通りの「ロングセラー」本のようである。
自分はこの分野が専門だったわけでもないのだが、論理学には学生時代少し興味があったし、どうすれば議論を実りのあるもの、平行線を辿らずに済むものにできるかということを意識する機会も多いので、この翻訳本の紹介を見てすぐ予約購入した。
「前件否定の誤謬」や「規範的前提の欠如の誤謬」といった「論理学らしい」誤謬のほかに、「藁人形論法」や「お前だって論法」といったTwitterでも見ることの多い誤謬も数多く取り上げられていることが紹介から窺えたので、読む前の期待としては「色んな誤謬の類型を知りたいな」というものだった。「これは知らなかった！」と思うような新しい誤謬が色々と掲載されていて、これからその誤謬を犯している議論を見たときに（あるいは自分自身がしてしまいそうになったときに）気づけるようになりたいということである。
しかし、一読してみると、その期待はあまり満たされなかった（たしかに様々な誤謬が紹介されているのだが、「ああそういう名前がついているのね」程度で、新しい気づきは乏しかった）のだが、それ以外の部分で面白い部分がいくつもあったので、書評を書こうと思った。
なお、本書の学術上の位置付けや、本書自体への学術的な批判については、巻末の監訳者解題が充実しているので、そちらを参照してもらえればよいと思う。
構成について
本書は以下のような全10章構成である。
- 第1章 知的行動の規範
- 第2章 議論とは何か
- 第3章 優れた議論とは
- 第4章 誤謬とは何か
- 第5章 構造の基準に違反する誤謬
- 第6章 関連性の基準に違反する誤謬
- 第7章 許容性の基準に違反する誤謬
- 第8章 十分性の基準に違反する誤謬
- 第9章 反論の基準に違反する誤謬
- 第10章 論述文を書く
分量の上ではおよそ1/3に当たる第4章までが概論で、第5章から第9章が（タイトルからは本編であることが期待されそうな）誤謬のカタログである（第10章は、第9章までの記述を踏まえた論述文のための簡単なガイド）。
全体で見ると400ページほどの書籍だが、章末課題の解答例と監訳者解題で50ページほどあるし、第5章以降は誤謬の具体例にも多くの紙幅が割かれているので、本論を追うだけであればそこまで時間をかけずに読むことができると思う。
知的行動の規範
第1章では、「知的態度に取り入れるべき行動原則」として、以下の12の原則が提示される（うち5つが後に論じられる「優れた議論の基準」）。
- 可謬の原則
- 真理追求の原則
- 明瞭性の原則
- 立証責任の原則
- 寛容の原則
- 構造の原則（=優れた議論の基準の1つ目）
- 関連性の原則（=優れた議論の基準の2つ目）
- 許容性の原則（=優れた議論の基準の3つ目）
- 十分性の原則（=優れた議論の基準の4つ目）
- 反論の原則（=優れた議論の基準の5つ目）
- 判断保留の原則
- 解決の原則
5つ目の「寛容の原則」は、英語ではprinciple of charityであり、これは「思いやりの原則」（伊勢田哲治『哲学思考トレーニング』p.48-49）や「善意の原理」（『岩波哲学思想事典』955L）などとも訳される。
他者の議論を再構築する場合には、論者の本来の意図だと考えられるものを損なわない形で、最も強い議論になるよう注意深く表現するべきである。議論の意図された意味や暗示的な箇所に不確かな部分があるなら、議論を提示した者に有利になるように解釈し、要望があれば修正する機会を与えなくてはならない。（p.23）
自分としては、Twitterでの不毛な議論の原因で最も多いと感じるのがこの原則に違反する一方（あるいは双方）当事者の言動である。また、仕事での議論でも意識することの多い原則で、「〜さんの言っていることはこういうことですか？」とこの原則に則りながら再構築して質問することは議論をスムーズに進める上で役立っている（もし自分の再構築した議論が本人の意図と違っていた場合も、この原則を意識していれば相手に不快な思いをさせることは少ないと思う）。
議論とは何か？
本書において議論（argument）*2とは、「他の複数の主張に裏付けられた主張」であり、裏付けられる主張が「結論（conclusion）」、裏付けに使われる主張が「前提（premise）」である。さらに、前提自体を結論として裏付けるものは「補完前提（subpremise）」と呼ばれる。
議論と区別されるものとして「意見（opinion）」があり、意見は必ずしも前提による裏付けを持たない。意見としてのみ表明されている限りではその意見を受け入れるべきかどうかの判断がつかないが、裏付けのある議論として表明されればその議論の質を問うことができるというのがポイントになる。
議論の質を評価する際には、「議論の標準形式（standard form）」に論者の議論を再構成するべきだと本書は主張する。
議論の標準形式とは、論者の意図を汲み取って元の議論を明確かつ簡潔な言い回して再構成したものである。すべての暗示的な部分を明示的に表現し、結論と前提や補完前提がきちんと区別されていなくてはならない。（p.39）
相手の議論における暗示的な部分を明示的にしようとすることは（当然ではあるが）話し合いをしている際には極めて重要なことだと思う。その部分に対して実は異論があるというケースもあるし、異論はなくても、話し合いに参加している人のうちにその部分が共有されていないために、後になって不適切な議論を立ててしまうケースもみる（ex. 「あの時こういう理屈でああしたじゃないですか」「いや、あのときはかくかくしかじかの前提があったからああしたんですよ」）。
優れた議論を構築する
第3章では、（第2章までの）上記の話を踏まえつつ、前述の優れた議論の5つの基準を提示しながら、議論を優れたものにする方法を紹介する。印象に残った点をひとつだけ挙げる。
それは、「許容性の原則」に関わるものだ。許容性の原則とは以下のものである。
ある立場に賛成あるいは反対の議論を行う者は、成熟した合理的な人に受け入れられそうで、かつ許容性の標準的な基準を満たす根拠を示さなければならない。（p.60）
議論で使う根拠は、「真である」必要があると考えられる場合が多いだろう。しかし、本書ではそうではなく、根拠は「許容しうる」必要があるという。「許容しうる」という基準が「真である」という基準よりも適切である理由として、いくつかのものが挙げられているが、興味深いのは、4つ目に挙げられている、「仮にある前提が絶対的な意味で真であったとしても、それが真であるかを判断できる立場にない特定の受け手にとって許容できないものになる可能性があること」（p.61）という理由である。
たとえば、根拠として挙げられているものの専門性が高すぎて相手にとって理解不能な場合には、その議論を強化する役割をその根拠は果たせない。議論が相手に意見を受け入れてもらうことを目的としたものである以上、議論の良し悪しには相手によって左右される部分があるというのは当然ではあるのだが、明確に言語化されてみるとハッとさせられる。
誤謬の分類、誤謬ゲームのルール
第4章からはいよいよタイトルにも掲げられている「誤謬」についてである。第4章では誤謬というものをこれまでに論じてきた「優れた議論の5つの基準」の1つ以上に違反するものとして定義している。つまり、誤謬は以下の5つのうちの1つ以上の欠陥を持つものということになる。
- 議論の構造的欠陥（「構造の原則」への違反）
- 結論と関連のない前提（「関連性の原則」への違反）
- 前提の許容性の基準を満たさない前提（「許容性の原則」への違反）
- 結論を裏付けるのに総合的に不十分な前提（「十分性の原則」への違反）
- 議論への予想される批判に対する効果的な反論の欠如（「反論の原則」への違反）
たとえば、「前件否定の誤謬」は構造に関わる誤謬であり、「伝統に訴える誤謬」は関連性に関わる誤謬である。名前のついた誤謬は数多くあるが、それらを整理できるようになるのが本書の提示している枠組みの利点であると思う。
推論における欠陥パターンの特徴に精通していれば、間違いを正しく特定し、効果的に対処できる可能性が高まる。（p.87）
誤謬の分類の提示に続いて、3種類の誤謬の突き方（自壊に追い込む、論外な反例を提示する、反証を示す）が紹介される。ここで紹介された誤謬の突き方の具体例が、第5章以降の個別の誤謬の解説のなかでも提示される。まさに原題である「Attacking Faulty Reasoning」のパートになる。
以上が第4章の本論に当たる部分だと言えそうだが、章末に置かれた「誤謬ゲームのルール」も本書には欠かせない記述である。そこでは、効果的な話し合いを実現するために必要な12の行動原則（前述）とは別に、スポーツマンシップに相当するルールとして以下が提示されている。
- 誤謬発見器にならない
- 相手に推論の欠点を指摘するのは、優れた議論の基準に違反したことで根拠のない結論に達したと確信した場合や、結論を受け入れがたい理由を説明したい時だけにする
- 自分自身の誤謬を指摘された際には、それを認めて考え方を適切に修正する
- できれば"誤謬"という言葉は一切使わない
本書のような書籍を手に取る読者は、論理や誤謬について関心を持っている人が多いだろう。そして、本書で紹介されているような誤謬やその突き方を学ぶと、日常の話し合いの中でも「あ、この人はあの誤謬を犯したな」と気づき、指摘したくなってしまうことがあると思う。しかし、そのような行動は相手との関係を悪化させてしまい、優れた議論によって実現されるべき知的進歩や対立の解消を阻害してしまう。実際、著者の論理学の授業を受けた学生にも、周囲の人との関係性が以前よりも悪化してしまったという人がいたとのことで、このセクションを設けることは著者にとっては必要不可欠だったのだと思う。
誤謬のカタログ
第5章以降は誤謬のカタログである。先述の通り、紹介されている誤謬にはそこまで新規性を感じなかった（定番ものを押さえているという見方もできる）。しかし、それは第5章以降が無駄であるということを意味しない。このパートの白眉は、それぞれの誤謬の解説の末尾に付け加えられている「誤謬を突く」のセクションである。
第5章から第9章の5つの章（違反している「優れた議論の基準」に対応している）では、60個（！）の誤謬について、定義と解説、いくつかの具体例に加えて、その誤謬への対処法が紹介されている。この誤謬への対処法が、非常に実践的なのである。
たとえば、「お前だって論法」（「特定の行為に関する論者の批判や議論について、論者が似たような行為を行っていることを理由に、真摯に評価したり反論したりする義務を回避すること。」p.315）については、以下のように記載されている。
議論や批判の内容と行動に一貫性がないと批判されたからといって、黙り込まなくてはならないわけではない。その指摘が正しければ素直に認め、一貫性のなさをとりあえず置いておいて、批判や議論の中身を検討してほしいと言おう。（p.315）
このように、単に誤謬を指摘する論理を紹介するにとどまらず、どのように相手に伝えるかというところまでを含んだ対処法を紹介しているのが面白い。純粋な学術書ではなく、教育的な著作としての色が出ている部分だと思う。
まとめ
以上、『誤謬論入門 優れた議論の実践ガイド』の感想を述べてきた。頭の整理に役立つ書籍で、教育的でもあり、ロングセラーとなっているのも納得であった。また、記事ではあまり言及しなかったが、政治的・社会的テーマについての議論から日常の発言における議論まで幅広い題材から採られている具体例も豊富で、「あるある〜」と思いながら読むことができる。目から鱗が落ちる系の書籍ではなく、「それはそうでしょう」という記述も多々あるが、記事で紹介したような目を引くポイントもあり、全体としてみると価値のある書籍だと思う。
Scrum Developers Night! を初めてオンサイトで開催しました
12月14日に、運営を務めている勉強会「Scrum Developers Night!」を初めてオンサイトで開催しました。
会場
会場は、（運営メンバーの長岡さんの勤務先である）ヤフー株式会社内のスペース「LODGE」です。新型コロナ以前は勉強会やイベントの打ち合わせなどで度々利用させてもらっていた会場で、僕自身とても懐かしく感じました。会場提供ありがとうございます。
※2022年12月現在は一般利用の受付はしていないとのことです。
Scrum Developers Night! について
Scrum Developers Night! は、2020年の夏ごろから始めた勉強会です。この勉強会については以前サブのブログの方に書いたことがあります。
なんでオンサイトで開催したのか
新型コロナの流行以降に始まった勉強会だったので、当初から一貫してオンライン（Discord）での開催を続けてきました。僕自身、フルリモートで働いているので、夕食後の時間に家から参加できるのが便利でしたし、Discordにも慣れているのであまり不便さを感じず、オンサイトへのこだわりはありませんでした。
ただ、年の瀬ということもあり、普段一緒に運営をしているメンバーと「忘年会くらいしたいですよね、せっかくだからオンサイトでイベント開催しますか？」という話をして、オンサイトでの開催をしてみようということになりました。
オンサイトで開催してみてどうだったか
上述の通り、オンライン開催に不便を感じていなかったのですが、オンサイト開催はやっぱり全然違いました。OST形式の勉強会なのですが、オンラインだとどうしても同時に喋るのは1人か2人になってしまいがちなところが、オンサイトだと横から入っていきやすいんでしょうね。聴いているだけの参加者がほぼいませんでした（聴いているだけでも気楽なのが逆にオンラインの良さでもあるのでしょうけれど）。わざわざ足を運ぶだけのモチベーションを持って参加していただいているのでということもあるのでしょうけれど、やっぱり話しやすいのかなとは感じたところです。ホワイトボートもかなり積極的に活用されていました。
当日の様子は以下のScrapboxにまとめています。
今後について・・・は考え中です
今回のオンサイト開催の体験が良かったので、オンサイトもやっていけたらなという思いはあります。一方で、オンラインの気楽さ・地理的な制約のなさも捨て難く感じます。運営メンバーの中でも相談しながら今後については考えていければと思っています。続報をお待ちください。
