勘と経験と読経

略すとKKD。ソフトウェア開発やITプロジェクトマネジメントに関するあれこれ。

ソフトウェアエンジニアの誕生と苦悩

あるところで「NASAのマーガレット・ハミルトンが自らの仕事を正当に評価させるためソフトウェアエンジニアという言葉を作り出した」という文章を読んで、あれ、そうだったっけ? と考えて調べたこと。「ソフトウェアエンジニア」という肩書や、日々の開発の裏側にある「当たり前」のルーツについて。

ソフトウェアエンジニアの誕生

世間一般のイメージでは、プログラミングやシステム開発というと、なんとなく「コードをガリガリ書く職人仕事」みたいな見方をされがちだ。でも、歴史を少し紐解いてみると、そのイメージを根本から覆し、「いや、これはハードウェアと同等、あるいはそれ以上に厳密な『工学(エンジニアリング)』なのだ」と世界に叩きつけた一人の人物に行き着く。
それが、アポロ計画でフライトソフトウェアの開発を率いたマーガレット・ハミルトンだ。
www.britannica.comen.wikipedia.org

当時、宇宙船の主役はあくまでハードウェアであり、プログラムなんておまけの付属品、あるいは補助的な計算作業くらいにしか見られていなかったらしい。そんな時代に、彼女は命懸けのミッションを支えるソフトウェアの重要性を信じ、「ソフトウェアエンジニアリング」という言葉を自ら作り出し、世間に突きつけた。

彼女がやったことは、単にコードを書くことじゃない。 予期せぬトラブルが起きたとき、システム自体がどう自律的に立ち直るべきかという「エラーからの自動復旧」の思想を設計に組み込み、すべての処理に厳密な優先順位をつけた。あの有名なアポロ11号の月面着陸寸前のパニック(過負荷エラー)を救ったのも、まさに彼女が仕込んだその執念の設計だった。
そして面白い(というか、歴史の必然というか)のは、彼女が現場でその戦いを繰り広げていたのとほぼ同じ時期に、業界全体が「ソフトウェア危機(Software Crisis)」という巨大な壁に直面したことだ。

ソフトウェアエンジニアの苦悩

ハードウェアがどんどん進化していく一方で、人間が作るソフトウェアはあまりに巨大化し、複雑になりすぎた。属人的な「誰でも書けるコード」の寄せ集めでは、もはやプロジェクトは破綻寸前。1968年のNATOソフトウェア工学会議で「ソフトウェア危機」が声高に叫ばれたのは、まさにハミルトンが現場で感じていた恐怖そのものだったはずだ。
「このままではいけない。私たちはちゃんとした工学(エンジニアリング)をしなければならない」
彼女が切り拓いた道は、そのままその後の業界全体の「危機」を乗り越えるための羅針盤になった。

混乱は今も続く

というわけで冒頭に記載した疑問は解消。ソフトウェアエンジニアの誕生は言われた通りのものだった。そして誕生直後に危機に陥ったという点も興味深い。

一方で混乱は続いている。「ソフトウェアエンジニアリングは間違っている」という批判もあったな。私の好きな意見は以下の記事でどうぞ。
agnozingdays.hatenablog.com

INCOSEの要求ガイドをざっと読む

AI要件定義サミットという興味深いイベント(知ったのは開催終了後だった)の基調講演を確認していたところ、要求工学に関する新しい知見としてINCOSEがガイドを出しているという。というわけで、ざっと読んでみたメモ。

ai-requirement-definition-summit.com

この講演は良かった。

オライリー教育プラットフォームに収録されたので、そこで読んだ

INCOSE Needs and Requirements Manual とは

国際システムエンジニアリング評議会が発行する、いわゆる上流工程のモデリングに関するガイドブック。総本山はおそらくこちら。
www.incose.org

全般的な感想

正直な感想:ロケットサイエンス感がある

上記サイトでダウンロードできる「FREE DOWNLOAD! Guide to Writing Requirements Summary Sheet」というPDFで示される図が、ある意味ではすべてである。一般的な要求を「コンセプト・ニーズ・要求」に分解し、細かいフィードバックで検証と妥当性確認を行うという構造が説明されている。なお実行には要求管理システムを前提とし、普通の文書化ではダメだ、ということになっている(実際、ここに書かれているプロセスをたとえば表計算ツールで実行するのは現実的ではないだろう)。

最終的にはそうやって構成された高精度な要求はモデルベース設計(MBD)と統合され、真のエンジニアリングができる・・・んだろうか。

個人的な印象としては、頻繁に変更が必要となるエンタープライズアプリケーション向けではなく、ライフサイクルがもっと長い制御システムなどでは有効なんじゃないかと思った。が、後者は詳しくないのであくまでも印象である。

各章の覚書

1 INTRODUCTION(序論)

  • ニーズと要件マニュアル(NRM)では、システムライフサイクル全体におけるニーズ、要件、検証、妥当性確認(NRVV )の定義と管理という観点から、システムエンジニアリング(SE )について説明を行う
  • このマニュアルは、INCOSE System Engineering HandbookおよびSEBOKを補足する位置付け

2 DEFINITIONS AND CONCEPTS(定義と概念)

  • PMI、ISO/IEC/IEEE、NASAなどの既存標準間での用語の混乱を防ぐため、本マニュアル固有の用語定義と相互関係を整理・提示する
  • NRVV
    • Needs(ニーズ): ステークホルダーがシステムに「何をしてほしいか」という運用上の期待を定義したもの。技術的な要求と区別するため、「shall」という言葉を使わずに記述される
    • Requirements(要求 / 設計入力要求): ニーズを満たすために、システムが「何をしなければならないか」を明確にした技術的な規定。「shall(〜するものとする)」を用いたテキスト形式で記述される。
    • Verification(検証): 「システムを正しく構築しているか(Are we building the system in the right way?)」 を確認するプロセス。製品や設計が、定義された要求事項(Design Input Requirements)を満たしているかを評価する
    • Validation(妥当性確認): 「正しいシステムを構築しているか(Are we building the right entity?)」 を確認するプロセス。完成したシステムが実際の運用環境で意図通りに動作し、ニーズ(Integrated Set of Needs)を満たしているかを評価する
  • CNR
    • Concepts(ライフサイクルコンセプト):ステークホルダーの課題、機会、ミッション、目標などを達成するために、対象のエンティティが運用・維持・廃棄までのライフサイクル全体で「どのように運用・管理・利用されるか」の構想を表現したもの。文章(ConOps / OpsConなど)や図表、運用シナリオ、ユースケースなどの形式で表現される
    • Needs(ニーズ / Integrated Set of Needs):ライフサイクルコンセプトの分析・熟成を経て公式に変換・導出されるもので、ステークホルダー視点から「エンティティに何をしてほしいか(期待)」を記述したもの。構造化された自然言語で記述されるが、要求(Requirements)とは異なるため「shall」という表現は使用しない
    • Requirements(要求事項 / Design Input Requirements):統合されたニーズのセットから変換され、ニーズを実現するために「エンティティが何をしなければならないか(技術的義務)」を開発・設計チーム向けに明確化した規定。「shall(〜するものとする)」**を含む厳密なテキスト形式で記述される
    • CNRは目的および組織で階層的に構築される。CNRの展開例:組織➡戦略➡運用➡システム➡サブシステム➡システムエレメント
  • 上流工程の重要性➡技術的負債の回避:初期段階でのコンセプト分析やニーズ定義をすきっぷして直接要求や設計に飛びつくと、後工程で致命的な手戻りやコスト超過(技術的負債)が発生するリスクがある

3 INFORMATION-BASED NEEDS AND REQUIREMENT DEVELOPMENT AND MANAGEMENT(情報に基づくニーズおよび要求の開発と管理)

  • システムの複雑化やソフトウェア重視の傾向に伴い、従来の文書中心(Document-centric)から、統合されたデータ・情報モデルを基盤とするアプローチへの移行が不可欠
  • I-NRDMアプローチの導入: I-NRDM(Information-based Needs and Requirements Definition and Management)は、ライフサイクルコンセプトから統合されたニーズ、そして設計入力要求へと変換する「設計入力(Design Inputs)」のプロセスをデータ中心で行う手法
  • 真のMBSE(I-NRDM + MBD)の実現: 多くのプロジェクトは設計出力に注力するモデルベース設計(MBD)に偏りがちだが、MBD単体では妥当性確認(ニーズを満たしているか)の失敗リスクが高まる。設計入力に注力する「I-NRDM」と設計出力の「MBD」を組み合わせることで、真のMBSEが実現する

4 LIFECYCLE CONCEPTS AND NEEDS DEFINITION(ライフサイクル概念およびニーズの定義)

  • プロジェクト成功の核となる「受容に必要な条件(Necessary for Acceptance)」の明確化について

5 NEEDS VERIFICATION AND VALIDATION(ニーズの検証および妥当性確認)

  • 評価対象の明確化: 本章で扱う「ニーズの検証(Verification)」および「ニーズの妥当性確認(Validation)」は、完成したシステムがニーズを満たしているか(システム妥当性確認)を評価するものではなく、「ニーズ表現(記述文章およびニーズのセット)そのものの品質と適切性」を評価するプロセスである
  • ニーズの検証(Needs Verification):「ニーズは正しく定義(記述)されているか?(Are the needs defined correctly?)」
  • ニーズの妥当性確認(Needs Validation):「ニーズはステークホルダーの意図やコンセプトを正確に伝えているか?(Do the needs communicate the intent?)」

6 DESIGN INPUT REQUIREMENTS DEFINITION(設計インプット要求の定義)

  • ニーズから「設計入力要求(Design Input Requirements)」への変換について
  • 5つのカテゴリによる要求の構造化:抜け漏れを防ぐため、要求事項を「機能/性能(Function/Performance)」「運用(Fit)」「物理的特性(Form)」「品質(-ilities)」「コンプライアンス(Compliance)」の5カテゴリに分類・整理
  • 各要求文章の定義時に、将来のシステム検証に向けた属性(成功基準: Success Criteria、戦略: Strategy、手法: Method、担当組織: Responsible Organization)をセットで定義し、要求が「検証可能(Verifiable)」であることを保証する

7 REQUIREMENTS VERIFICATION AND VALIDATION(要求の検証および妥当性確認)

  • 要求事項の検証(Requirements Verification):要求事項が「正しい形式とルールで記述されているか(Wording and Form)」
  • 要求事項の妥当性確認(Requirements Validation):要求事項が「正しいメッセージや意図を伝えているか(Content and Intent)」

8 DESIGN VERIFICATION AND DESIGN VALIDATION(設計検証および設計妥当性確認)

  • 設計の検証(Design Verification): 「設計を正しく行ったか(Did we design it right? / Did we design it correctly?)」
  • 設計の妥当性確認(Design Validation): 「正しい設計を行っているか(Do we have the right design?)」

9 PRODUCTION VERIFICATION(製造検証)

  • システム(SOI)が、設計出力仕様(Design Output Specifications)に従って「正しく構築されたか(built right)」を確認する
  • 同時に、組織の設計管理(ガイドラインや品質管理システム)や、規制・標準規格に従って、製造・コーディングのプロセスが「正しく行われたか(built correctly)」を客観的証拠に基づいて評価

10 SYSTEM VERIFICATION AND VALIDATION COMMON PRINCIPLES(システム検証および妥当性確認の共通原則)

  • システム検証(System Verification)とシステム妥当性確認(System Validation)は異なるプロセスだが、多くの共通原則を共有している。ここでは共通原則が説明される

11 SYSTEM VERIFICATION AND SYSTEM VALIDATION PROCESSES(システム検証およびシステム妥当性確認プロセス)

  • システム検証:物理的なシステム(SOI)が設計入力要求を満たしているか。「システムを正しく構築したか(built it right)」
  • システム妥当性確認:システムが統合されたニーズのセットを満たしているか。「正しいシステムを構築したか(built the right thing)」

12 THE USE OF OTS SYSTEM ELEMENTS(OTSシステム要素の活用)

  • OTS(Off-the-Shelf)とは、市販品(COTS: Commercial Off-the-Shelf)や、組織内の他プロジェクトで過去に開発された既存のシステムエレメント(電源、ディスプレイ、ソフトウェアなど)を指す
  • これらに軽微な改修を加えたものをMOTS(Modified OTS)と呼ぶ
  • 採用時には「隠れたコスト」に注意する必要がある。OTSをシステムに適合させるための改修コストや時間(MOTS化)が、ゼロからカスタム品を設計・製造するコストを上回ってしまうケースが存在する

13 SUPPLIER-DEVELOPED SOI(サプライヤーが開発するSOI)

  • システム(SOI)の開発、生産、検証、または妥当性確認の一部や全体を外部のサプライヤー(請負業者、ベンダー)に委託する際の考慮事項とベストプラクティス

14 NEEDS, REQUIREMENTS, VERIFICATION, AND VALIDATION MANAGEMENT(ニーズ、要求、検証、および妥当性確認の管理)

  • 従来の文書ベース(Document-centric)の管理から脱却し、プロジェクトのツールセット上に統合されたデータを構築・管理する。これにより、矛盾のない「信頼できる唯一の情報源(ASoT)」を確立し、あるデータへの変更が他のすべての成果物やビュー(文書やダッシュボード)に一貫して反映されるようにする

15 ATTRIBUTES FOR NEEDS AND REQUIREMENTS(ニーズおよび要求の属性)

  • ニーズや要求事項は、テキストによる「記述文(Statement)」単体では完成しない。記述文に「属性」という追加情報を組み合わせることで、初めて完全な「ニーズ/要求事項の表現(Expression)」となる

16 DESIRABLE FEATURES OF AN SE TOOLSET(SEツールセットに望まれる機能)

  • 「万能な単一ツール」は存在しない

うーん、気合いで読んだが、思ってたのとは違った・・・

「C4 モデル(Japanese Edition)」を読んだ

アーキテクチャのモデリング記法であるC4モデルについての提唱者が書いた書籍「The C4 Model: Visualizing Software Architecture (English Edition)」がある。オライリー学習プラットフォーム上で実験的なAI翻訳版が出ていたので読んだメモ。

www.oreilly.com

ちなみにこの本はとても短い。しかし為替の影響で原著がめちゃ高い。

なおオライリー学習プラットフォームは個人加入で利用。利用感などは以前に書いているが、最近はいろいろなところで共有されているので検索すれば良いだろう。
O'reilly learning platform(オラのサブスク)のすすめ 2024 - 勘と経験と読経

感想

モデル考案者である著者が、20年以上に実際にワークショップなどで活用した経験を踏まえてC4モデルについて解説する形となり、非常に有用。
また、AI駆動開発におけるモデルの活用まで視野に入っており、このタイミングで出版されたのはまさに良いタイミングだろう。
訳書へのアクセス方法が限られるのはとても残念だ(とはいえ、過去にもAI翻訳版がある作品がちゃんとした翻訳で出版されたことがあるので、期待できるかもしれない)。

AI翻訳について

普通に読める。ところどころに過剰な翻訳がある。例えば「コンポーネント図」が「構成要素図」に翻訳されているなど(C4はコンテキスト(context)、コンテナ(containers)、コンポーネント(components)、コード(code)の略なので)。

C4モデルについてはWikipediaに日本語ページが存在するので、AI翻訳時の参考にすれば伝達性が向上するのではないだろうか、というようなフィードバックを一応実施してはみた。

各章に関する覚え書

C4モデルそのものについての詳細説明はいくらでもネットで閲覧できるので省略している

1. コミュニケーションの失敗

  • 現在もまだソフトウェア開発業界はコミュニケーションという意味では失敗している
  • 建築業界ではとっくに実現されている「アーキテクチャの視覚化」が出来ていない。バラバラな方法で分かりにくい図が描かれ続けている
  • AI駆動開発の時代でコンテキスト共有の重要性は高まっている。ソフトウェアアーキテクチャ図の重要性は引き続き高い
  • UMLは様々な理由で役に立っていない
  • アジャイルの影響(誤解)で多くのソフトウェアチームは文書化を「赤ん坊を風呂の水と一緒に捨ててしまった」
  • アジャイル以前の慣習(ウォーターフォール型のデリバリーサイクル等)により「ソフトウェアアーキテクチャ図には技術選択を含めるべきではない」「論理設計と物理設計を分ける」という誤った通念が形成されている。この通念は現在は有効ではない

2. 基礎

  • 共通の表記法は重要ではない。地図には様々な表記法があるが凡例によりどの表記法でも読み取れる。重要なのは、共通の語彙である
  • C4モデルは表記法に依存してしない。図の凡例で説明されれば好きな表記法を自由に使用できる。C4モデルの目的はその場しのぎの四角と矢印の図に構造を持ち込むことにある

3. システムコンテキスト図

  • ソフトウェアシステムを俯瞰的に捉える高レベル図
  • 優れた分析ツールでもある。要件収集ワークショップでシステム境界を明らかにする議論などで利用できる

4. コンテナ図

  • ソフトウェアシステムの境界内に存在するアプリケーションやデータストアを記述する、C4モデルの中核的なダイアグラム
  • デプロイメントに関する側面の記載は推奨されない(デプロイメント環境によって異なるから)。必要であれば別途デプロイメント図を作成すればよい
  • 主要な技術選択の結果も記述する

5. コンポーネント図

  • 単一のコンテナ内に存在する構成要素を拡大表示する
  • 基本的には作成しなくてよい
    • データストアはERDなどで文書化するのが適切
    • 単純な構成のコンテナについても作成する必要はない
    • 大規模であったり、複雑な場合に選択的に作成するもの

6. コード図

  • 内部実装の詳細を示すために使用する
  • ほとんどの場合、作成する必要はない。コードを見れば良いからだ

7. 動的図

  • 実行時の挙動を示す場合に、UMLのシーケンス図、コラボレーション図をベースとしたダイアグラムを作成する

8. デプロイ図

  • ソフトウェアのデプロイメントトポロジーを図式化したもの

9. システムランドスケープ図

  • 複数のシステムコンテキスト図を合成した、より俯瞰的なビューを提供するもの

10. 表記法

  • C4モデルに標準的な表記法はない
  • 共通の語彙と適切な凡例を示せば、誰でも容易に理解できる

11. 基礎を超えて

  • 抽象化の拡張について(例えばDDDによる境界づけられたコンテキスト)。必要であれば追加すれば良い。ただし既存のC4モデルの図にグループ化などを追加して対処できる場合も多い
  • マイクロサービスやメッセージ駆動型アーキテクチャを図式化する際の推奨事項など

12. 実践におけるC4モデル

  • C4モデルは軽量なものだが著者の経験上、一般的なエンタープライズソフトウェアを開発しているチームの大多数には有効なものとなっている
  • C4モデルはソフトウェア設計のプロセスを記述するものではない、という点には注意が必要
  • 成熟度。ソフトウェアアーキテクチャの図解能力のさまざまなレベル
    • 初期段階:図を作成していない
    • アドホック:バラバラな図を作成している
    • 定義済み:定義された抽象化と図の種類を備えたC4モデルを採用して図を作成している
    • モデリング段階:モデリングツールの利用に移行
    • 最適化:組織内でモデルを作成、使用、共有する方法が最適化されている

というわけで良い本だった

Enterprise Architecture As Strategyをざっと読む

エンジニアリング戦略の作り方 ―エンジニアリングの難局を打破する意思決定」で紹介されていた「Enterprise Architecture As Strategy: Creating a Foundation for Business Execution (English Edition)」をざっと読んだという話。

『Enterprise Architecture as Strategy』Jeanne Ross、Peter Weill、David Robertson著(Harvard Business Review Press、https://lethain.com/notes-on-enterprise-architecture-as-strategy)は、ソフトウェア(当時の言葉では「IT」)の進化、企業内での成熟度、事業部門間の結合と統合に関する戦略の選び方を扱っており、一読の価値があります。

この記事は、技術指導者であり元CTOのWill Larson氏が、2006年に出版された書籍『Enterprise Architecture as Strategy』(邦題:『エンタープライズ・アーキテクチャ・アズ・ストラテジー』、Jeanne W. Ross / Peter Weill / David C. Robertson 著)を読み、その核となる理論と現代における有用性をまとめた書評・要約です。
出版から20年近く経っており、事例自体は古いものの、「複数のビジネス部門を持つ企業が、どのようにITとビジネスプロセスを統合・調整すべきか」という現代的な課題に対して、非常に実践的で整理されたフレームワークを提供しているとLarson氏は高く評価しています。

実際に読んだ感想

まず、もっとも重要なのは本書が(一般的な)エンタープライズ・アーキテクチャすなわち、BA・DA・AA・TAの四層で構成されるEAの本ではないということだ。本書で扱われるのはより抽象的な企業アーキテクチャ、もしかすると現代ではビッグピクチャーなどと言われるようなものを中心とした議論である。

その上で20年前の書籍という古さはあるけれど、ビジネスを中心に企業の構造を(ITも含めて)どう統合し調整していくべきかという現在も未解決な課題を扱っているという点では学びは多いという印象だ。この記事では紹介しないが当時の基準で先進的な企業のアーキテクチャがダイアグラムとして紹介されており参考になる。

マイクロサービスもクラウドもない時代であるが、本書が取り扱う抽象度であれば影響は受けていない、そういう点でも興味深い本だというのが感想だ。

各章の覚書

1: To Execute Your Strategy, First Build Your Foundation

戦略を実行するために、まず実行基盤を築く

  • 実行基盤とは:ITインフラのことではない。ITインフラと企業のコア能力を自動化するデジタル化されたビジネスプロセスのこと
  • 実行基盤を構築するために必要な3つの要素
    • オペレーション・モデル
    • エンタープライズ・アーキテクチャ
    • ITエンゲージメント・モデル(ITとビジネス目標の整合性を保つガバナンスメカニズム)

2: Define Your Operating Model

オペレーション・モデルを定義する

  • ビジネスプロセスの「標準化(他部署と同じやり方をするか)」と、「統合(データをどれだけ他部署とリアルタイムに共有・連携するか)」の強弱(2×2のマトリクス)によって、企業のオペレーティング・モデルは4つに分類される
    • 協調(Coordination) [標準化:低 / 統合:高]:共有するシステム実装は少ないが、データは高度に共有されるモデル。
    • 統合(Unification) [標準化:高 / 統合:高]:共通のシステムを使い、ビジネスユニット間でデータも密に結合しているモデル。
    • 多様化(Diversification) [標準化:低 / 統合:低]:ビジネスユニット間での共通点がほとんどなく、一部の共通サービス(人事など)を共有するだけのモデル。
    • 複製(Replication) [標準化:高 / 統合:低]:標準化されたシステムを各ユニットに個別に展開するが、ターゲット顧客が異なるため、ユニット間でのデータ連携はほとんど行わないモデル。

3: Implement the Operating Model via Enterprise Architecture

EAを通じてオペレーティング・モデルを実装する

  • EAを企業全体におけるビジネスとテクノロジーのイニシアチブを整合させるための強力な管理ツールとして使用する。これは、IT部門が主導するITアーキテクチャ設計のアプローチとしては異なる。
  • 経営層が理解しやすいように、本書では「コアダイアグラム」と呼ばれる1枚絵を用いる。コアダイアグラムには以下を表現するする
    • コアビジネスプロセス
    • コアプロセスを推進する共有データ
    • 主要なリンクおよび自動化技術
    • 主要顧客
  • 2章で紹介された4つのオペレーション・モデル別の事例
  • IT部門に任せてEAを作成するのではなく、上級管理職を中心としたオペレーション・モデルの議論から始めるべき

4: Navigate the Stages of Enterprise Architecture Maturity

EA成熟度の段階をナビゲートする

  • 企業におけるエンタープライズ・アーキテクチャの成熟度には以下の4つの段階があり、これらは「飛び越えて進化することはできない(必ず段階を踏む必要がある)」
    • ビジネス・サイロ(Business silos):個別の部門がそれぞれ独自のITを最適化している状態。
    • 標準化されたテクノロジー(Standardized technology):技術プラットフォームやインフラを全社で共通化し、効率を高めている状態。
    • 最適化されたコア(Optimized core):全社規模でデータやコアなビジネスプロセスを共通化・共有化している状態。
    • ビジネスのモジュール化(Business modularity):ビジネスプロセスが再利用可能な「モジュール」になり、変化に対して高い機敏性(アジリティ)を持っている状態。

5: Cash In on the Learning

学びから利益を得る

今日のマネージャーは、フォードが行ったように、現代の情報技術の可能性を活用するために、自社を再設計しなければなりません。エンタープライズアーキテクチャの設計は、新技術の利点を提供できる実行の基盤を構築する第一歩です。しかし、アーキテクチャ設計図から利益の実現へと移行するには、マネージャーはビジネスの進め方について異なる考え方をする必要があります。

6: Build the Foundation One Project at a Time

段階的に基盤を築く

  • ビッグバン形式での実行基盤の移行はリスクが高い。よって、段階的に移行していく必要がある
  • 段階的に移行するためにはガバナンスメカニズムが必要となる
  • 三層からなるITエンゲージメント・モデルが有効。業績の良い企業はこういったモデルを用いて、段階的な移行を実現している
    • 全社レベルのITガバナンス:意思決定と説明責任の枠組み
    • プロジェクトレベルのITガバナンス:成果物標準化とフェーズゲートを含むプロジェクト管理手法
    • 連携メカニズム:インセンティブを調整し、PJレベルの活動を全体的なITガバナンスに結びつけるプロセスおよび意思決定機関
  • エンタープライズアーキテクチャをコンパスとして活用し、企業を意図したオペレーションモデルへと導く。航路を保つために、ITエンゲージメント・モデルを用いる

7: Use Enterprise Architecture to Guide Outsourcing

EAを活用してアウトソーシングを推進する

  • アーキテクチャがアウトソーシングの意思決定の指針となる
  • アウトソーシングの三類系
    • 戦略的パートナーシップ
    • 共同調達(管理責任の共有)
    • 取引関係(外注)

8: Now—Exploit Your Foundation for Profitable Growth

基盤をから成長を生み出す

9: Take Charge! The Leadership Agenda

リーダーへのアドバイス

  • 10原則
    • 実行基盤へのコミット
    • 変革はトップダウンから始める
    • コアを育成するための「実験」を行う
    • アーキテクチャを「羅針盤」かつ「コミュニケーションツール」として活用する
    • 段階をスキップしない
    • 基盤構築は1プロジェクトずつ進める
    • アウトソーシングを活用する
    • 人材に投資する
    • 「全社的な視点」を評価し、報いる
    • 「実行基盤」で従業員に権限を委譲する

ITエンジニアのプロフェッション考

公共放送の影響で(プロジェクトXとか仕事の流儀とか)で、日本のプロフェッショナル像というのはけっこうあいまいになっている。ITエンジニアは、医師や弁護士と同等な「プロフェッション(専門職)」なのだろうか、ということを考えている。

プロフェッションを構成する6つの要素

放送大学の「共生のための技術者倫理」という講義を受講している。そこで技術者のプロフェッションについて紹介されていて興味深かった。一般論として、プロフェッションは6つの要素で構成されているということだ。

  1. 理論的知識に基づく技能
  2. 長期にわたる教育や訓練
  3. 試験による能力の証明
  4. 組織化
  5. 倫理綱領
  6. 利他的なサービス

本質から考え行動する科学技術者倫理 (科学技術者倫理教育のテキスト)

1〜3は、まあわかる。知識やスキル、教育、そして資格などによる能力証明である。では4以降はどうだろうか。医師や弁護士については、医師会や弁護士会といった職能集団の形成によって維持されている。一方でITエンジニアの「組織化」は極めて緩やかだ。業界全体を統制するような強制力を持つ団体は、一般的ではない。この現状をどう捉え、私たちはどこにエンジニアとしての規範を求めるべきなのか。少し整理してみたい。

「業務独占」の有無

なぜITエンジニアには、医師会や弁護士会のような強力な組織がないのか。その最大の理由は「業務独占」の有無にある。

医師や弁護士は、法的な資格がなければその業務を行うこと自体が禁止されている。不適格者が紛れ込むリスクを排除するため、国家と連動した強力な自治組織(職能団体)が必要となり、加入が事実上の義務となる。

一方で、ITエンジニアの世界は「自由参入」だ。資格がなくてもコードは書けるし、システムを構築してビジネスを動かすことができる。基本情報技術者や各種ベンダー資格は「名称独占」や能力の証明に過ぎず、参入の障壁ではない。だからこそ、業界全体を縛るような強制力を持つ団体が生まれにくい。それはもちろん良い点でもある。

プロフェッションの6要素に当てはめても、ITエンジニアは知識や技能(1、3)の面では専門職の形を整えつつあるが、組織化や倫理の強制力(4、5)という制度面においては、いまだ「開かれた実践者の集団」という性質が強い。

それでもこれまでは問題は小さかった。しかし近年ソフトウェアを取り巻く倫理の問題が増加している。これからもこのままで良いのか、という点には論点があるだろう。

日本における「守り」の倫理と資格

日本国内に目を向けると、ITエンジニアの周辺でプロフェッションとしての形を模索する動きがないわけではない。特に「法的な義務」を背景にした資格や団体はいくつか存在する。

その代表格が「技術士(情報工学部門)」であり、近年新設された「情報処理安全確保支援士(登録セキスペ)」だ。

これらの資格は、根拠法(技術士法、情報処理促進法)によって非常に重い法的義務が課されている。
特に「秘密保持義務」は強力で、資格を返上した後であっても一生涯にわたって課される。これに違反すれば、民間資格のような除名処分にとどまらず、「1年以下の懲役又は50万円以下の罰金」という、前科のつく刑事罰が背景にある。

また、技術士法には「公益確保の責務」も明記されている。
ここに、プロフェッション特有のジレンマが生じる。もしクライアントのシステムに重大な社会的欠陥(意図的なデータ不正流用など)を発見した場合、「秘密保持」と「公益確保」のどちらを優先すべきか。国やクライアントに対する義務、すなわち「守りの倫理」としての法的な枠組みがここにはある。

ACMが示す、もう一つのアプローチ(攻めの倫理)

一方で、法律や罰則による外在的な規制とは全く異なるアプローチで、包括的な指針を示しているのが米国計算機学会(ACM)の倫理綱領(ACM Code of Ethics and Professional Conduct)だ。日本ではあまり広く紹介されていないが、世界のソフトウェア工学における事実上の世界標準として機能している。

ACMのアプローチは、破ったら罰せられる「規則」ではなく、「テクノロジーで世界を変えてしまう我々IT専門職は、どうあるべきか」という、内在的な自律(モラル)の表明だ。

その内容は極めて包括的であり、現代のIT社会が直面する課題を先回りしている。

  • 社会と人間の幸福への貢献(1.1)
  • 公平性と差別の禁止(1.4): AIやアルゴリズムのバイアス(偏見)を排除する責任
  • リスクの徹底的な評価と説明責任(2.5)
  • 内部告発(ホイッスルブローイング)の容認: 組織が重大な社会的リスクを無視した場合、害を減らすために内部告発が必要になる場合があると明記

日本のIT倫理が「国家やクライアントに対する義務」だとすれば、ACMの綱領は「全人類や地球環境に対するエンジニアの責任」を説く。ビジネスの論理(納期や売上)に流されそうになったとき、エンジニアが専門職としてのプライドを保ち、踏みとどまるための「北極星」として機能しているのだ。素晴らしい。

「学びを止めること」という倫理違反

プロフェッションの構成要素を語る上で、もう一つ避けて通れないのが「知識や技能の維持・向上」、すなわち自己研鑽をどう規定しているかという問題だ。

技術士法第47条の2には、「資質向上の責務」が明確に規定されている。

“技術士は、常に、その業務に関して有する知識及び技能の水準を向上させ、その他その資質の向上を図るよう努めなければならない。”

情報処理安全確保支援士(登録セキスペ)では、情報処理促進法第26条により、支援士には定期的な「講習の受講義務」が課されている(毎年1回のオンライン講習と、3年に1回の実践講習)。これは単なる努力義務ではない。

ACMでは倫理綱領の第2.2項(プロフェッショナルとしての能力の維持)では、高いクオリティのコンピューティングは、個人やチームが能力の獲得と維持に責任を持つことで成り立つとされる。

こうして見ると、ITエンジニアにとって「最新の技術を学び続けること」は、単なるキャリアアップのための自己啓発ではない。社会に害を与えず、専門職としての責任を果たすための「最低限の倫理的要件」として定義されていることがわかる。

結びにかえて

強力な職能団体による統制がないということは、裏を返せば、エンジニア一人ひとりの「自律」に委ねられている部分が大きいということでもある。

私は現時点でで、強力な職能団体を新たに形成すべきだとか、免許制にするようなアプローチは別にいらないとは思う。しかし一方で、自律のレベルアップは必要だろう。

法的な罰則による「守り」の倫理をベースに持ちつつ、ACMが示すような社会への責任という「攻め」の倫理を個々人が胸に刻むこと。組織に縛られない自由な実践者の集団だからこそ、私たちは自らの意志で、プロフェッションとしての歩みを進める必要があるのではないだろうか。そんなことを考えたのだった。

システム思考の実践例だった「エンジニアリング戦略の作り方」を読んだ

読むのがホネな技術書やビジネス書を取り上げて2週間の読書期限を課して読んでアウトプットする仮想読書会「デッドライン読書会」の第91回。同僚と読書期限を約束することによって積読が確実に減るという仕組み。過去記事はこちら

今回とりあげるのは「エンジニアリング戦略の作り方 ―エンジニアリングの難局を打破する意思決定」だ。エンジニアリングマネジメントの領域で良書を多数発表しているWill Larsonさんの新しい訳書であり期待値が高い。しかも前著でもトピックとして興味深かった「戦略」に関する深掘りである。

Will Larsonさんの過去の本についての私の感想はこちら(エレガントパズルも読んだけど感想書いてなかった)

本書の概要

様々な企業(日本で有名なところで言えばStripeやUber)でエンジニアリード等を担ってきた著者が、エンジニア戦略に特化して書き上げた本である。その特徴としては理論だけでなく、具体的な事例を多数収録していることで、類書と異なり「どう考えるべきか」「考えた結果をどう文書化するか」について事例から深く学ぶことができる書籍になっている。

なお、本書の概要は、訳者の岩瀬さんが紹介スライドを公開しているのでそれを見るのが良いだろう。
エンジニアリング戦略の作り方 / Crafting Engineering Strategy - Speaker Deck

全般的な感想

本書が素晴らしいのは「システム思考」と「Wardleyマップ」についての考え方について具体的な事例つきで学べるという点だ。今のところまだ「Wardleyマップ」については腹落ちしていないので参考にする程度だが、「システム思考」について、考え方だけでなく分析方法から戦略にどう落とし込むか、までが示されているのが目から鱗が落ちるほど良かった。

例えば「16章 サービスマイグレーション戦略」ではUberのサービスプラットフォーム拡張方針についての説明となっている。単純にいえばインフラチーム頼みのプロビジョニングは破綻することが予想されるので、投資を行いセルフサービス化(今であればプラットフォーム化)するという戦略である。

日本語での読みやすい文章は本書を購入して読んでいただくとして、この分析については著者サイトでも紹介されている(英語)
lethain.com
この分析過程ではシステム思考を用いたモデルの構築とシミュレーションが行われているのだ。達人にとっては当たり前なのかもしれないが、ここは私にはけっこうなショックである。なるほど、こう使って文書化すればいいのね!

たとえばこの事例をたとえば絵に書くとこうなるが(ここまでは時々やる)、それだけでは不十分だと言うことだ。

Loppyで作成したモデルへのリンク

著者はPythonベースでモデルを作成し、パラメータを変えてシミュレーションしてデータを作成した上で、その結果をグラフ化することで戦略文書の読者に示している。結果は見た目的には実験論文のようになるが、その結論は単純明快である。いいな、これ。

本記事では一つの例を紹介したが、こんな事例が複数示されていて勉強になった。

同様に「Wardleyマップ」についても事例が豊富でこちらも参考になる。ただこちらの考え方はまだ自分の中で使いどころが腹落ちしていないので、現段階ではストック扱いである。

本書で紹介されている参考書籍について

本書では様々な書籍も参考文献として挙げられているので、少し触れておこう。

これは前著「エンジニアリング統括責任者の手引き ―組織を成功に導く技術リーダーシップ」でも推薦されていたので読んだが、戦略を考える際の必読書だろう(自分も所属会社で勉強会を行なった)。近年発売された他の技術書籍でも頻繁に引用されている(こちらの記事で触れた:前略、戦略 - 勘と経験と読経

未読。訳書もなさそうだが読んでみようと思っている。読んだらメモを公開する予定。

こちらも未読。訳書もおそらくない。本書の巻末では紹介されていないようだが、文中で推薦されている。読んだらメモを公開する予定。

2026年上半期に読んだ本まとめ、おすすめ本など

2026年1月~6月に読んだ本のまとめ。カウント対象は期間中に読み終わったものに限り、読みかけの本は対象外としている。あとコミック、漫画雑誌類もカウントからは除外。
この6カ月では80冊の本を読んだようだ(前シーズンは74冊)。概ね平常運転を継続。

いつもどおり半期で読んだ本の中で良かったものをピックアップしてみる。

文芸書のおすすめ(一般編)

お、おどろくべきことに、この半年はSFやミステリばかり読んでいて普通(?)の文芸書はほとんど読んでいなかった!とはいえゼロというわけではなく、読んだこの本は良かった。辻村深月さんの安定のクオリティ。

なお本書は『島はぼくらと (講談社文庫)』『傲慢と善良 (朝日文庫)』と世界観を共有している(出版社がバラバラなのが不思議)。どの作品も素晴らしいので興味があればまとめて読むのがおすすめ。

文芸書のおすすめ(趣味のSF編)

好きなSFには二種類ある。まず、始まりから思わぬほど遠いところまで連れて行ってくれるSF小説が好きだ。そういう点では「DIVA ゲンロンSF文庫」と「一億年のテレスコープ」は良かった。

もう一つは未来を感じさせてくれるSF小説だ。気候変動をテーマにした「ターミネーション・ショック」は今まさに進行中の世界の行末を感じさせてくれて良かった。が、パンデミック後で地政学リスクが増大した未来のことを考えさせるこの作品を推しておこう。

鋭い世界設定とサスペンス感が素晴らしかった。

文芸書のおすすめ(趣味のミステリ編)

ふりかえると意外にもこの6ヶ月はミステリばかりを読んでいる。すこし前に名作、良作と評判だった本をよく手に取っていたようだ。しかし、いちばん良かったのはこちら。

なにもできない幽霊と
なにもできない少女が織りなす
頭脳戦の楽しみに満ちた爽快な復讐譚!

というラノベというか子供向けの内容かと思ったら、ものすごい複雑な話だった。これ以上は書けない。おすすめ。

教養書のおすすめ

最近、新書大賞をよくチェックして読むようになった(読書数が増えている原因のひとつ)。

新書に慣れると欧米の訳書の冗長さがツラくなる。そして新書ばかり手に取ってしまうというループである。というわけで紹介するのも新書になるわけだが、どちらも美学者の難波優輝さんの作品である。

前者は「時間」、後者はナラティブ的な意味での「物語」に関して、考えてもいなかったようなことを考えることができるようになる。おすすめ。なお本著者の新刊「本とは何か(新潮新書)」も気になる(まだ読んでない)。

ビジネス書のおすすめ

ビジネス書を読むのは、まあ仕事に役立てたいからである。そしてAIが席巻する世情を考えるとAI系の本を取り上げざるをえないのが、ちょっと悲しい。

ふだんは情報収集のために聞いているPodcastやSNSをフォローしている著者三名の共著。その三人のメタ的な考え方がまとめられており、非常に参考になった。

こちらは、このまま進歩すると人類滅亡するという本。と書くとトンチキな印象があるが、理路整然と問題点を列挙しており考えさせられる本になっている。読むなら今であろう。答え合わせのタイミングがくると人類終わるので。

技術書のおすすめ

興味深いことに、良かった本はどちらもAIエージェントを利用して執筆されている。とはいえ、AIスロップ感はなく著者の幅広い知識が強化され、読みやすかった。

こちらの感想は以下の記事に書いた。著者製GPTsが非常に便利。

ソフトウェア倫理に関する本。すなわち「良い」「正しい」プロダクトは何かという話である。類書では「責任あるソフトウェアエンジニアリング ―現実社会におけるGoogleのケーススタディとともに (オライリー・ジャパン)」も良かったのだけれども、本書のほうがより実践的だと感じる。

この半期の振り返り

本の大喰らい、過食症気味、活字中毒である。とはいえTVもほとんど見ないし、スマートフォンやSNS、ネットサーフィンからも距離を置いているので別に無理をしているというわけではない。

  • じつは電子積読が数十冊あるので、減らしたい
  • 振り返るとミステリばかり読んでいたことがわかったので、下半期は普通の(?)文芸書や、SF小説をもっと読みたい。バランスが悪い

さて、次は何を読もうかな

2026年上半期に読んだ本の全リスト

  1. 私とは何か 「個人」から「分人」へ (講談社現代新書) 有名な本。AIエージェント時代に刺さる
  2. チーム内の低劣人間をデリートせよ ——クソ野郎撲滅法 想定外に嫌な同僚ではなく上司対策の本だった
  3. 火星の女王 NHKドラマ原作の社会派SF
  4. 会話の0.2秒を言語学する ゆる言語学ラジオの人の本で良作
  5. 名探偵の掟 (講談社文庫 ひ 17-21) メタミステリの傑作
  6. 数学ガール/フェルマーの最終定理 時々数学を勉強したくなる時に読む本
  7. ラーメンと瞑想 (ホーム社) 哲学者によるエッセイ。深い
  8. なぜ人は締め切りを守れないのか 時間哲学の本
  9. 言語化するための小説思考 SF作家による小説論
  10. 人生のレールを外れる衝動のみつけかた (ちくまプリマー新書) 若い人向けの本だがシニアも読むべき
  11. カササギ殺人事件 上 〈カササギ殺人事件〉シリーズ (創元推理文庫) 各賞絶賛の本だが、本当に傑作
  12. ソフトウェアテスト徹底指南書 〜開発の高品質と高スピードを両立させる実践アプローチ 日本のテストコミュニティの知見が全部入っている
  13. 私たちは意外に近いうちに老いなくなる 老化研究最前線。いや私も歳なんですよ
  14. カササギ殺人事件 下 〈カササギ殺人事件〉シリーズ (創元推理文庫) 傑作の後編。読み始めて驚きの声を上げた
  15. 円環少女 5魔導師たちの迷宮 (角川スニーカー文庫) 著名SF作家の若かりし頃のラノベシリーズ
  16. 生成AI時代のソフトウェア開発 ―ツールを賢く選択、評価、活用し、より速く効率的な開発を進めるために 良い本だったが、高速で陳腐化している
  17. メインテーマは殺人 ホーソーン&ホロヴィッツ・シリーズ (創元推理文庫) カササギ〜の作家の別シリーズ。こっちも面白い
  18. SHIFT解剖 究極の人的資本経営 競合研究。でも現在は方針変わってしまったらしい
  19. 物語化批判の哲学 〈わたしの人生〉を遊びなおすために (講談社現代新書) 反物語主義の哲学
  20. AIエージェント 人類と協働する機械 AIをどう使うかという考え方の本→書評
  21. コンプレックス (岩波新書) 心理学の古典名著。勉強不足を痛感させられる
  22. プリンシプル オブ プログラミング 3年目までに身につけたい 一生役立つ101の原理原則 IT名著の入り口になりそうな本。若い人にはここから始めることをおすすめする
  23. 主体的に動く アカウンタビリティ・マネジメント(新装版) オズの魔法使いに触発された思考法に関する本
  24. 円環少女 6太陽がくだけるとき (角川スニーカー文庫) ラノベ。東京地下戦争編がこれで終了
  25. その女アレックス (文春文庫) 14年、各賞総ナメのミステリ
  26. 日ソ戦争 帝国日本最後の戦い (中公新書) 25新書大賞入賞作。知らなかった歴史
  27. きみはメタルギアソリッドⅤ:ファントムペインをプレイする 実験的短編集。表題作がすごい
  28. 奇想の系譜 若冲ブームの火付け役と言われる名著
  29. 青空と逃げる (中公文庫) 「傲慢と善良」「島はぼくらと」とリンクした世界観
  30. ババヤガの夜 (河出文庫) キルビルのようだ
  31. 伝わるコードレビュー 開発チームの生産性を高める「上手な伝え方」の教科書 説明がとても丁寧で良かった
  32. なぜ日本文学は英米で人気があるのか (ハヤカワ新書) 世界文学論である。そして読みたい本が増える罠
  33. シャガールと木の葉 谷川俊太郎さんの詩集。脳と心が読みたくて
  34. カウンセリングとは何か 変化するということ (講談社現代新書) 26新書大賞の一位。カウンセリング論
  35. 顧客との「関係」を育てる実践マーケティング: 地域金融機関の変革事例から学ぶ、データ利活用の本質 (Relic Publishing) デジタルマーケティングの現場論
  36. プラットフォームエンジニアリング ―成功するプラットフォームとチームを作るガイドライン 技術の本だと思ってたらチーミングと政治の本だった→書評
  37. 読書アンケート 2025――識者が選んだ、この一年の本 識者が読んだ本の紹介。去年から買ってる。良いガイド
  38. ターミネーション・ショック 気候変動SF
  39. 苦しかったときの話をしようか ビジネスマンの子への手紙
  40. 物価を考える デフレの謎、インフレの謎 (日本経済新聞出版) 物価への解像度が爆上がりする良い教養書
  41. Living Documentation: Continuous Knowledge Sharing by Design (English Edition) TLで話題だった洋書。→感想
  42. モナ・リザのニスを剥ぐ (新潮クレスト・ブックス) 好評なアート・ミステリ
  43. 福音派―終末論に引き裂かれるアメリカ社会 (中公新書) 米国の厨二病
  44. 開発者とアーキテクトのためのコミュニケーションガイド ―パターンで学ぶ情報伝達術 パターン本、困った時にまた読む
  45. 集団浅慮: 「優秀だった男たち」はなぜ道を誤るのか? グループシンクの本
  46. 一次元の挿し木 (宝島社文庫) このミス受賞作。SF味
  47. 少女には向かない完全犯罪 予想外の本格ミステリ
  48. NHK 100分 de 名著 『谷川俊太郎詩集』 2026年 6月 [雑誌] (NHKテキスト) 詩人のことは全然わかっていなかった
  49. プロダクト倫理: あなたのプロダクトは誰かを傷つけていないか ソフトウェア倫理。網羅的でよい
  50. 円環少女 7夢のように、夜明けのように (角川スニーカー文庫) ラノベ。幕間劇な巻
  51. DIVA ゲンロンSF文庫 ゲンロンSF新人賞。よい
  52. NHK 100分 de 名著 ウィトゲンシュタイン『論理哲学論考』『哲学探究』 2026年 4月 [雑誌] (NHKテキスト) 生成AIの例えで驚きのわかりやすさ
  53. 哲学史入門Ⅳ 正義論、功利主義からケアの倫理まで NHK出版新書 倫理学のよいガイド
  54. 水中の哲学者たち 哲学対話の人のエッセイ。文章がうますぎ
  55. ヨルガオ殺人事件 上 〈カササギ殺人事件〉シリーズ (創元推理文庫) カササギ〜の続編。続きが書けるのがすごい
  56. エンジニア育成現場の「失敗」集めてみた。【固定型】 42の失敗事例で学ぶマネジメントのうまい進めかた 失敗集めてみた。 あるある集。チームで読むとよさそう
  57. 機動戦士ガンダム 閃光のハサウェイ(上) 機動戦士ガンダム閃光のハサウェイ (角川スニーカー文庫) 新作映画の影響でつい。89年の作品!
  58. 男性中心企業の終焉 (文春新書) 22年の本。メルカリ事例など興味深い
  59. ヨルガオ殺人事件 下 〈カササギ殺人事件〉シリーズ (創元推理文庫) この人の本は下巻の加速が本当にすごい
  60. 人文知は武器になる (文春新書) 話題の新書。両著者の組み合わせが素晴らしい
  61. 機動戦士ガンダム 閃光のハサウェイ(中) 機動戦士ガンダム閃光のハサウェイ (角川スニーカー文庫) キルケーの魔女。映画とは少し違う
  62. 魂にメスはいらない ユング心理学講義 (講談社+α文庫) 聞き手の谷川さんがいい
  63. 3カ月で改善!システム障害対応 実践ガイド インシデントの洗い出しから障害訓練まで、開発チームとユーザー企業の「協同」で現場を変える 書かれている通りにやれる丁寧なガイド
  64. Aligned ―プロダクト開発におけるステークホルダーとの関係性の築き方 すり合わせの本。→感想
  65. その裁きは死 ホーソーン&ホロヴィッツ・シリーズ (創元推理文庫) 著者が主人公なミステリの続編
  66. あなただけのAI社員 忙しすぎるあなたのための10分AI革命 読むのは10分では終わらない。初心者向け
  67. Z家族~データが示す「若者と親」の近すぎる関係~ (光文社新書) ファクトフルネス的本
  68. AIとソフトウェアテスト 信頼できるシステムを構築するために テストにまつわるAI系の話題を網羅したよいガイド
  69. メタスキル:努力の価値が変わる時代の「AI×自分」戦略 有名な3人の思考が読めてよい
  70. 一億年のテレスコープ 話題のSF小説。射程が長くてとてもよい
  71. 責任あるソフトウェアエンジニアリング ―現実社会におけるGoogleのケーススタディとともに (オライリー・ジャパン) Google事例中心のソフトウェア倫理本
  72. 生きものハイウェイ 都会の生き物観察エッセイ
  73. その対応では会社が傾く―プロが教える危機管理教室―(新潮新書) 転ばぬ先の杖として。ゼミ形式で読みやすい
  74. 超知能AIをつくれば人類は絶滅する 今読むと答え合わせに間に合う可能性がある
  75. ループ・オブ・ザ・コード(新潮文庫) アフターコロナの良作SFエンタメ
  76. AIと生きる 対話から始まる成長の物語 数学ガールの登場人物がAIについて語る本
  77. 教養としてのパランティア・テクノロジーズ: 世界の意思決定を支える企業の正体 コンパクトな良質のレポート
  78. 天皇への敗北―シリーズ哲学講話―(新潮新書) 哲学というより憲法学の本だがよい視点を得られた
  79. 機械ぎらい 機械音痴のテクノロジー史 (集英社新書) ソフトウェアも含むUX論
  80. 屍人荘の殺人 〈屍人荘の殺人〉シリーズ (創元推理文庫) その発想はなかった!密室ミステリ