■ 1. 経歴とHoneycombの原点
- Linden LabからParseへ:
- 最初の職はLinden Labで、Second Lifeを開発
- その後Parseでモバイル向けバックエンドを構築し、Facebookに買収された
- 買収の失敗から得たもの:
- 買収の大半は失敗し、Parseも例外なく閉鎖された
- スタートアップ育ちで無名だったが、Facebookを離れる段階で投資家から声がかかり、Honeycombの創業につながった
- Scubaによる原体験:
- Parseでは100万を超えるモバイルアプリをホストし、毎週どれかが壊れる状況だった
- 原因特定は数時間から数週間かかる運任せの作業だったが、データをScubaに入れた途端に数クリックで解決した
- Honeycomb創業の動機:
- Scubaのない環境ではエンジニアとしての力が大きく落ちると痛感した
- どうせ失敗するならGoで書いてオープンソース化し、どこへ行っても持ち運べるようにするつもりだった
■ 2. 個人の生産性の測定
- 測定できる次元と限界:
- 個人の生産性は一部の次元しか測れず、チームの状態や誰が要かは表れない
- 詳細に踏み込んでいる良いマネージャーやリードであれば実態は分かる
- 意見ではなくデータで裏づける:
- 分かっていても裏づけとなるデータが必要で、絵の中の一色のような部分的指標に頼ってはならない
- グッドハートの法則があるため、単一指標を目標化してはならない
- チームこそが重要:
- 個人のアウトプットを重視する流れが続いてきたが、依然として重要なのはチーム
- AIがもたらす問い直し:
- 良いとは何か、生産性とは何か、より良いとは何かを早期かつ頻繁に問い直させる点はAIの利点
- 速度に真っ先に飛びついた事実は示唆的で、速さだけを「より良い」とするのは未熟な定義
- 速度偏重への疑問:
- Spotifyが1日または1週あたり4500件の変更を出荷したと語る一方、品質や機能の良し悪しは語られていない
- 顧客がアプリのボタンの位置が常に動くことを望んでいるとは思えず、速度は最も測りやすいだけの指標
■ 3. 2025年のAI転換点
- 2025年はクラウドの2010年:
- 2025年3月のSREconではバイブコーディングを試すよう勧め、会場からうめき声が上がった
- 当時の売り込みは、AIを学べばより的確に文句を言えるという趣旨だった
- 転換点はモデルより harness:
- 当時はプログラミング言語より大きいがクラウド程度の機能拡張であり、世代交代ではないと見ていた
- 転換点は2025年11月のOpus 4.5だが、振り返れば7月頃から兆候があり、変化を起こしたのはモデルではなく harness とツール群
- 懐疑から転向へ:
- 今年前半、周囲の全員が再び試して考えを変えていった
- 考えを変える人を尊敬する
- 当初の懐疑は誤りではない:
- AIが中央値のソフトウェアエンジニア並みにコードを書くという主張は、当時としては極めて特異な主張だった
- ニューラルネット、COBOL、ノーコードやローコードなど、同種の約束は繰り返し裏切られてきた
- あの時の懐疑は正しかったが、今回の懐疑は間違いだった
■ 4. 読んでいないコードの出荷
- 問題は「いつ」であって「もし」ではない:
- 自分が読んでいないコードを出荷するかという論点も、かつての懐疑と同じ経路をたどっている
- 5日後か5年後かは分からないが、方向としてはそこへ向かうことは明らか
- 信頼を成立させる条件:
- 変更内容が見え、ハーネスで検証済みだと分かる仕組みがあれば信頼できる
- AI以前に「自分が保証する、叩き込んだ」と言うチームメンバーを信頼したのと同じ構図
- 数か月AIと並走して、どちらがどれだけ検出するかを比較し、訓練していく道もある
- Phoenixアーキテクチャの前提:
- イミュータブルインフラ、ステートレスサービス、コンテナ、ブルーグリーンデプロイ、コードとしてのインフラは、動くものを直さず置き換えるという前提を共有する
- AIはその前提をインフラからアプリケーションコードへ拡張し、書き直しが安価になると、その場での編集がリスクになる
- 変更は entropy を蓄積するが、置き換えはそれをリセットする
- ペットから家畜への移行の再来:
- サーバーを個別に設定し修理していた時代は終わり、捨てて新しくする運用に移った
- コードは60年以上にわたり編集する対象であり続けたが、経済性が同じ転換を迫る
- 生成が安価であることの帰結:
- 一度書くより速く、関数の変種を1万通り生成できる
- そのため大量のevalとテストが必要になるが、生成の安さがその方向へ強く押し出す
- ソフトウェアのコストは常に保守に紐づいており、信頼の根拠は本番で使い続けてきた実績にある
- 全面生成には慎重:
- 難しいデータベース移行を経験した者は、契約を外挿し保存する能力について謙虚であるべき
- すべてのコードを生成すべきとは考えないが、今より遠くまで進めることは確実であり、それは良い変化
- 書き直しの痛みの実例:
- ParseではRuby on RailsのAPIを6か月で書き、Goへの書き直しに2年を要した
- 当時のGoは未成熟でMongoDBドライバから自作する必要があり、型安全性のない環境も苦痛だった
- ストラングラーフィグのように利用者との契約を一つずつ壊して発見する手法は理想的な成果物ではない
- アーキテクチャ図をレビューし議論し、そこからコードを仕様どおり生成できるようにすべき
■ 5. OpsとQAへの再評価
- 行レベルのコードは理想的な成果物ではない:
- レビュー対象としてのコード行は最適な単位ではなく、必要なツールはまだ存在しないが、着想の多くは既にある
- その多くはOpsとQAという、ソフトウェアエンジニアリングが見下してきた二つの領域に由来する
- OpsとQAの関心:
- OpsとQAは常に「何であるか」に関心を持ち、ソフトウェアエンジニアリングは「どうあるべきか」に関心を持ってきた
- OpsとQAは検証、正しさ、期待どおり動くか、そもそも動くかを問うてきた
- 本番は開発の一部:
- リポジトリの中に世界が存在すると信じる態度は不可解で、実体は本番にある
- ソフトウェアエンジニアに本番を見せない組織すらある
- 本番は開発の後に来るものではなく、開発の一段階
- AIが押し進める方向:
- AIは業界が長年必要としながら進めなかった方向へ規律を押し進めており、その点に強い期待を持つ
- 金曜日デプロイ論争:
- 「金曜日にデプロイするな」という主張が広まったが、CIとCDによって恐れずいつでもデプロイできる状態を目指すべき
- UAT環境も不要であり、本番でテストすべき
- マージすれば本番へ出るのが既定で、出さないためには列車を止める必要があるという状態が正しい
■ 6. コードレビューの再定義
- 人間の脳は検証に向かない:
- コード生成は安価になり、人間側のボトルネックはレビューに移った
- 業界はレビューを増やし、ツールを改善する方向に押し進んでいる
- レビューは過剰に多義的:
- コードレビューは人により場所により意味が違いすぎ、多くの投影が起きている
- レビュー不要と言うと、同僚と話したくない、ジュニアを指導したくないという意味に取られるが、それは事実ではない
- 残すべき部分:
- これを自社のプロダクトに入れるかどうかを決める場としてのレビューは、人間が得意とする議論
- メンタルモデルが一貫しているか、API設計はどうか、アーキテクチャはどうかという対話には価値がある
- 理想を言えばコードを書く前に話すべき議論
- 捨ててよい部分:
- 構文やバグを読み取る作業は悪ではないが、教育機会として最良でない限り価値は高くない
- 検証としてのレビューは優先度の最下位
- ガードレールを整えていない穴を自分たちの時間で埋めているだけの場面が多い
■ 7. 非決定性システムと規律
- 非決定性はより多くの規律を要求する:
- AIは規律も規律のなさも増幅する
- コードを信頼できる成果物として扱うなら、人間が予測できる範囲のテストしか書けず、その水準は高くない
- 振る舞いのテスト、スモークテスト、性能テスト、負荷テスト、ファズテストなど、QA由来の手法が必要になる
- 信頼の口座:
- コード生成から信頼を引き出すなら、その信頼はどこか別の場所で積み上げねばならない
- AIを退屈にする:
- AIという括りより、決定性システムと非決定性システムを共存させる問題として捉える方が有用
- 決定性は消えず、極めて価値が高い
- 非決定性のツールは振れ幅が大きいため、通路を掘り、囲い込み、超能力として使える領域に限定する必要がある
- 非決定性の実害:
- HackerRankが外部委託した履歴書スコアリングは、同じ履歴書を100回評価すると66点から99点まで振れる
- 多くの企業は85点を基準にしており、採用支援を謳う道具が実質コイン投げだと判明した
- AIがすべての用途に適した道具ではないと言えることが重要
■ 8. Honeycomb社内のAI規範
- 1年前は自社を信頼していなかった:
- 1年前にAIを使うべきと決めても、十分な知識がなかった
- この1年で学びが進み、今は同僚が「この仕事にAIは不適切」と言えば信頼できる
- 良くなる前に一度悪くなる過程が必要
- バーは全員に対して上がった:
- 強力な新しい道具を得たときに起きることであり、荒野をさまよう段階にあるが、さまよわなければ取り残される
- バーを定義する唯一の方法はより良い結果であり、これは良いか、より良いかを問い続ける必要がある
- ヒューマン・イン・ザ・ループではなくループの所有:
- ループの内側にいるすべてのエージェントに何を許すかを制御することが本質
- スロップは送るな:
- 自分が読んでいないものを他人に送ってはならない
- 作るのにかかった時間より読む時間の方が長いなら、それはスロップであり、相手に対する明確な不作法
- 何かを渡す行為は相手の時間と注意を要求する行為であり、中身を知らないまま渡せばコストを相手に転嫁することになる
- 自己認識の実践:
- 自分で調べずに人に質問しようとする瞬間、生成物をそのまま渡そうとする瞬間に気づくことが第一歩
- 新入社員が先輩の時間を尊重する作法を学ぶのと同じ構図
- 深く考えるために使う:
- AIは考えずに済ますための近道にも、より深く厳密に考えるためにも使える
- 中核業務においては後者を求める
- 第二言語話者や神経多様性のある人の利用は尊重の範囲内であり、AI禁止ではなく互いに妥当な要求をすべきという話
- 品質と尊重の基準は既にあり、新しく作り直す必要はない
■ 9. 分断する二つの陣営
- どちらも作り話ではない:
- 推進派も懐疑派も実際に恐ろしい傾向を見ており、悪化する現実の難題に取り組んでいる
- 推進派の見ている現実:
- これは競争であり、快適圏の外へ出る必要があると強く意識している
- 他社がより速く動き、追いつき、追い越すのを見て、取り残される恐怖を抱えている
- 指数曲線の内側にいるという歴史的に稀な状況にあり、備えるのが賢明
- 懐疑派の見ている現実:
- 分断の境界はしばしばオンコール担当かどうかで引かれる
- 責任を負う側はメンタルモデルの融解、スロップ、積み上げた仕事の消失を目撃しており、終わりが見えない
- AI利用が増えて以降、システムが著しく悪化しているという観測は本物
- 双方が少数派を自認する皮肉:
- どちらの陣営も自分たちが少数で圧倒され抑圧されており、真実と勇気のために立っていると感じている
- 断絶の構造:
- 勝ちを見ている側はコストと結びつけないため、同僚を職を失うのが怖いだけの人間だと誤認する
- オンコール側は勝ちの報告を信じられず、すべて捏造だと考える
- 静かな部分、つまり代償と後始末が語られていないことが原因
- 全体を語れという要請:
- 書き直しや真の toil の自動化など、目を見張る成果は実在し、誰も手放したがらない
- 勝ちと同時にコスト、割に合うのか、今何が起きているのかを必ず併せて語るべき
■ 10. 信頼性の悪化という実態
- Metaでの深刻度ゼロの多発:
- Metaは最高深刻度のSev0を追跡しており、この2か月ほどで異常な多発が起きている
- InstagramやWhatsAppで信頼性を担う人員が削減されており、関連を否定できない
- Metaがここまで悪化したのは10年近くぶり
- 業界全体の同時多発:
- 会議で話すと、VC出資企業や上場企業から同じ現象が起きていると告げられる
- 各社が自分たちだけの問題だと思い込んでいたが、実際には業界全体で起きている
- Intercomの正直な公表:
- Intercomは18か月にわたり信頼性とコード品質が低下したことを公表した
- 直近でようやく回復の兆しが見えているが、元の水準には戻っていない
- 都合の悪い部分を隠さずに出す姿勢が価値を持つ
- Intercomの規律:
- CTOは10年前から「出荷は会社の心拍」と語っており、Rubyモノリスを10分から15分間隔で1日数百回出荷している
- AI以前に創業しながらAIネイティブへ移行した組織の到達点
■ 11. ソフトウェアはAIのキラーアプリ
- 論理と言語という共通性:
- ソフトウェアは論理と言語でできており、AIも論理と言語でできている
- そのためガードレール、チェック、検証を組み込めるが、生活の他の領域で同じことをする方法は分からない
- 他領域での検証困難:
- 幻覚を含む準備書面を提出した弁護士が訴えられているが、それを検証する手段がない
- ソフトウェアには構造化データがあり、検証できる領域という強みがある
- コンパイルの通るコードという優れた訓練データも存在する
- コードと散文の非対称:
- 生成コードは自分でも書き得た水準に達する一方、自分の文体を指定した文章は自分では絶対に書かない代物になる
- 訓練データがあってなお散文は反復的で見分けがつく
- ソフトウェアは目的のために単純化された言語であり、そこが最適な適用先
- 書くことは考えること:
- 文章生成の効率化に多くの時間を投じたが、書くことは紙の上で考えることであり近道はないと結論づけた
- 構造の相談やフィードバック取得には利用する
■ 12. 人間であることへの回帰
- 人間の価値は蓄積で決まる:
- 5年後の採用は対話の中で判断される形になり、思考と自己研鑽に費やした分だけ価値が高まる
- 思考をAIに外注してきた候補者は、その部分が空白になる
- 対面と人間性:
- Slack上でエージェントと人間が延々と往復するのは不快で、対面の交流の方が豊か
- 機械を統べるのは自分たちであり、機械は自分たちに仕えるという前提を忘れてはならない
■ 13. DevOpsの成否
- DevOpsが生まれた理由:
- 開発と運用が分断され、コードが壁越しに投げ込まれていた
- 半分がコードを書き、もう半分がそれを理解するという分断脳の構造は元来悪い発想
- 自分で運用しない限り自分の書いたコードは理解できない
- 半分の成功と半分の失敗:
- 運用担当がコードを書けるようになる波は成功し、コンピュータを扱う全員がコードを書くべき
- ソフトウェアエンジニアが本番でコードを理解する波は成功度が低い
- 20年のDevOpsは、コードを書く人と本番のコードをつなぐ単一のフィードバックループの構築が本質であり、それは失敗した
- 関心の分離自体は健全:
- 誰かに全部をやらせることはできず、プラットフォームチームとプロダクト側の分離は良い切れ目
- インフラ側は安定性と回復力に、アプリ側は全ユーザーの体験に向く
- 片方だけが成立する状態があり得るため、両者は分離可能
- Anthropicも同じ構造:
- Anthropicは白紙から始めながらクラウドプラットフォームチームと応用AIチームに分かれている
- 両者はソフトウェアエンジニアが不要になるかという基本問題への見解すら大きく異なる
- プラットフォーム側は不要にならないと考え、応用側は起こり得ると考える
■ 14. 観測性の実践
- 三つの柱という説明の限界:
- 観測性はメトリクス、ログ、トレースの三本柱として説明されがち
- メトリクスとログはシステムの排気であり、自社で書かず所有しない大量のサードパーティ製品から出続けるため無くならない
- 排気は安価な場所に置けばよく、量は多いが価値は高くない
- 王冠の宝石としての自社コード:
- 自社を自社たらしめるコードについては、テレメトリはプロダクト上の意思決定であるべき
- 結合組織ごと一度で保存すべきで、豊かなデータの価値は線形でも指数的でもなく組み合わせ的に増える
- 29個の属性を持つワイドイベントに30個目を足すと、その30個目は他のすべてより価値が高い
- 非決定性ソフトウェアでは挙動を事前に予測できないため、トレースの取得は明確な製品判断
- 自動計装の成熟:
- OpenTelemetryを使うべきであり、一般的なパターンはすべてモデルが学習済み
- 計装しながら作る方が、計装しない場合より速くて容易になった
- 計装は開発者の意図の宣言であり、本番でその意図を確認する手段
- かつての障壁:
- メトリクスかログかトレースか例外かエラーかプロファイルか、カウンタかゲージか、カーディナリティはどうかと判断が連なり、実装時間を数倍に膨らませた
- デプロイ後も名前をどう探し、どう表示し、どうダッシュボードを作るかという壁が残った
- 現在はこれらを開発環境の中に持ち込め、開発ループの一部にできる
- スパンとタイムライン:
- トレースは高機能なフィールドを持つ構造化ログであり、スパンはその全体の持続時間を構成する部分集合
- ウェブの登場以来の基本単位はトランザクションだったが、AIの登場でそれが通用しなくなった
- Honeycombはスパンの上に載るタイムラインを出荷した
- 監督エージェントが複数のエージェントを起動し、各々がAPIやストレージを呼び、数時間に及ぶ会話を俯瞰する用途に対応する
- トレースのトレースという新しい構成要素が必要になった
- エージェントとコンテキスト:
- 世の中には大量のごみデータがあり、従来型のテレメトリはコンテキストウィンドウをごみで埋めがち
- 最も重要なのはデータ間の関係であり、それが判断を助ける
- あるAI SREスタートアップの報告では、実運用のエージェントは観測性データを迂回し、より豊かで無傷なテレメトリを求めて上流へ向かう
- テストとevalの融合:
- 今後はテレメトリの観点からテストとevalが結び付くことに期待している
■ 15. 『Observability Engineering』第2版
- 全面書き直し:
- 初版は2019年から2021年に書かれ、執筆開始時と終了時で観測性の定義が変わってしまった
- 出来に満足して出したのではなく、これ以上続けられないという状態で出した
- 第2版は初版250ページに対し600ページで、内容はすべて新しい
- 構成:
- 全6部で、第1部は決定性システムと非決定性システムを同時に運用する意味を扱う
- 第2部と第3部は共著者による計装と理解の解説で、AIを使う場合と使わない場合の並行トラックがある
- 第4部と第5部はゲスト著者による事例と深掘りで、フロントエンドとモバイル、CI/CD、ClickHouseによる列指向ストレージ、FinnのKeshaによる反復的な観測性運用を収録
- 第6部の狙い:
- 当初3章の予定が全体の3分の1、200ページのリーダー向け観測性ガバナンス論になった
- 冒頭はCTOへの公開書簡で、AIの大目標はシステムを理解する能力に阻まれていると説く
- バズワードを使わずシステム理論で語る内容で、ドネラ・メドウズを好む読者に向く
- 観測性の影響を財務向けに定量化する章、投資として扱う場合とコストセンターとして扱う場合の使い分けを扱う
- 権限なく大規模な変革を推進するスタッフ以上のエンジニア向けのゲスト章、内製か購入かオープンソースかを扱う章を含む
- ベンダーとの関係:
- 最終章は「ベンダー提携の技術と科学」で、必要なソフトウェアをすべて自作できない前提から出発する
- 良い提携とはロードマップに影響力を持ち、相手からも信頼される関係
- 変革の多くは失敗するが、成功する場合は内部に信頼と信用を持つ人間が官僚制を切り裂いている
- ベンダーの営業組織には最初から信頼がなく、互恵によって時間をかけて信頼を築く
- 最良の関係は互いの成功が自分の成功だと感じられる状態だが、これは稀であり、握手と対価の交換で終わる通常の関係でも問題ない
- これらは AI 時代においても長く価値を保つ技能
■ 16. リーダーシップと事業
- 最も有効なリーダーの順序:
- 最も有効なのは、優しく思いやりのある人間であり、かつ有能な事業運営者
- 次に有効なのは、ひどい人間だが有能な事業運営者
- その後にその他全員が続き、善良だが運営が雑で事業に弱い人は多い
- Twitterを例にした論点:
- Twitterは16年かけても事業を確立できず、それは誰の目にも明らかだった
- X が良くなったか悪くなったかは議論できるが、20パーセントの人員で運営されている事実は議論できない
- コアプロダクトのエンジニアは30人ほど、合計でも60人ほどで、以前は1700人いた
- 以前のエンジニアの仕事の上に成り立っている面はあるが、それが要点ではない
- 自ら基準を課す:
- 高い基準を自らに課し、効率的に作り、絶えず改善しなければ、誰かが外からそれを課しに来る
- 文化と規範と倫理観を自分たちで決めたいなら、まず事業で勝つ必要がある
- DEIの後退から学んだこと:
- 2010年代の潤沢な資金が尽きた途端、各社がDEIプログラムを取り消した
- もともと信じておらず人を懐柔していただけであり、これは非常に示唆的
- 善人であるだけでは足りず、人を思いやるリーダーは同じ職位のソシオパスより良い結果を出すが、それは事業に強い場合に限られる
■ 17. マネジメントの変化
- 全員が手を動かす時代:
- リーダーも差分を出しPRを通す感覚を持つべきで、実装に関わるリーダーの方が優れているのは以前からの事実
- 拾い直すことがかつてなく容易になり、やらない言い訳がなくなった
- チーム縮小への評価:
- より広い範囲を所有できるなら、チームが小さくなること自体は良いこと
- ただし他社がやっているから、魔法だから、レイヤーオフだからという理由でCEO主導で進む現状を懸念する
- 反マネジメント論への反論:
- 権力が時間とともにマネージャー側へ漂流し、マネージャーが過剰になる傾向があることは否定しない
- 官僚制では否と言うより諾と言う方が容易であり、定期的に権限をエンジニアへ戻す必要がある
- それでも中間管理職は本質的に不可欠
- マネージャーの本質的役割:
- 中間管理職の役割は意味づけと文脈の付与
- タスクを割り当てられるだけの世界は望まず、それはAIにできる
- 何をしようとしているか、どうやろうとしているかを理解する人が必要
- 理解なしに感情的にも創造的にも協働的にも関与できず、その理解は築くのが難しく壊れやすく長続きしない
■ 18. 中間管理職とディレクターへの助言
- 一度ICに戻る:
- 望む方向でないと分かっていても、しばらくICに戻るのが戦術的に有効
- 履歴書にAIを載せる必要があり、それが得られない職場にいることは重大なキャリアリスク
- 経験の差は開き続ける:
- AIエンジニアリングの経験を2、3年持つ人材の市場は史上最高の状態
- 未経験で職を失った人は誰も見込みを与えてくれず苦戦している
- 正しい状況ではないが現実であり、始めた人と未着手の人の差は時間とともに広がる
- 次の面接では必ず問われ、なければ落とされる
- 不安と興奮は同じもの:
- ディレクターは管理職歴10年ほどの人が多く、技術変化への恐れを抱えている
- 不安と興奮は生理学的にほぼ同じで、違いは主体性の有無
- 波が来るのを待てば怯えるだけであり、波に向かって走るべき
- マネージャーがICに戻ることは高く評価されるため、堂々と選び、自分の経験を語り広めるべき
■ 19. ジュニアエンジニア
- 価値の定量化という前提の欠落:
- ジュニアの価値を測るのが難しいのは、そもそもどのエンジニアの価値も測れないから
- 若手は問題なくやれる:
- 高校生や大学生と日常的に話す友人によれば、彼らはソフトウェア開発ライフサイクルを知らないまま非常に多くの成果を出している
- 自分たちが思いつかなかった結論とやり方を持ち込むはずであり、必要なのは採用し機会を与えること
- 実例:
- 優秀なオープンソース貢献者を採用しようとしたら17歳だったという話が複数のスタートアップから出ている
- インターンシップでもよく、たとえその人が定着しなくても経験を積ませること自体が双方にとって有益
- 大変化期の逆転:
- iPhoneとAndroidの登場時、最も優れたiOSエンジニアは18歳や19歳の若者だった
- 2年後には22歳のスタッフエンジニアと40歳の新人という構図が生まれた
- 大きな変化のときは自ら主導することで専門家になれ、誰も何が正しいか知らないため止められることもない
■ 20. AI疲れへの向き合い方
- 疲れの種類を分ける:
- スロップを受け取ることによる疲れ、誇大宣伝による疲れなど、種類が異なる
- AnthropicやOpenAIのCEOが終末を語り続ける行為は doom trolling と呼ばれ、無責任に人々を不安にさせている
- 技術は従来、楽しさや生活の改善として語られたが、今は恐怖として語られ、家族までが怯えている
- SNSはAIスロップ投稿ばかりで、そこから距離を置いている
- 主導権を取り戻す実験:
- 不満が普遍的である今こそ、主導権を取り戻す実験を提案する好機
- AI生成のPR説明文をやめる、水曜日は誰もAIを使わない、1週間試すといった合意が例
- 変化が大きいため実験はかつてなく容易であり、リーダーは歓迎する
- 事前に報告せず、何がうまくいき何がうまくいかず何を学んだかを後から伝える形でよい
■ 21. 推薦書籍
- 『Catastrophe Ethics』:
- 著者は生命倫理学者のTravis Reederで、現代生活ではあらゆる選択に加担が伴うと説く
- 牛乳なら牛の苦痛、アーモンドミルクなら水、豆乳ならホルモンと、何を選んでも誰かを害する
- 問題が巨大すぎて個人の判断が無意味に思えるという緊張を扱う
- 功利主義など伝統的な倫理枠組みをたどり、どの処方も愚かな帰結に至ることを示す
- 神も主人もいないが相対主義ではなく、世界について学び、自分が何に引かれ何の苦しみに心が動くかを聞き取る必要がある
- 何が重要かは誰も教えてくれず、自分で決めるほかない
- この内省は、演技的な怒りとは正反対の姿勢
- 『More Everything Forever』:
- 著者はサンフランシスコ在住のジャーナリストAdam Beckerで、哲学の学士と天体物理学の博士を持つ
- AI宗教、シンギュラリティ、効果的利他主義、加速主義、無限成長主義を打ち砕く
- 指数関数的成長について唯一分かっているのは、S字曲線か崩壊のいずれかで必ず終わるということ
- 恒星系の獲得を語るオックスフォードの倫理学者たちの馬鹿馬鹿しさを乾いた笑いで描く
- 寿命延長に打ち込む人々を、父を恋しがる悲しい少年たちだと評しており、人類最古の恐怖である死への恐怖がそこに見える