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

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

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

エンジニアリング戦略の作り方 ―エンジニアリングの難局を打破する意思決定

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

• 「スタッフエンジニア マネジメントを超えるリーダーシップ」をマネジメントの観点で読んだ - 勘と経験と読経
• 就任予定はないけど「エンジニアリング統括責任者の手引き」を読む Part.1 - 勘と経験と読経
• 就任予定はないけど「エンジニアリング統括責任者の手引き」を読む Part.2 - 勘と経験と読経

本書の概要

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

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

全般的な感想

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

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

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

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

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

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

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

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

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

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

良い戦略、悪い戦略 (日本経済新聞出版)

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

Enterprise Architecture As Strategy: Creating a Foundation for Business Execution (English Edition)

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

Facilitating Software Architecture: Empowering Teams to Make Architectural Decisions (English Edition)

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

というわけで、本書の感想はここまで。さて次は何を読もうかな。
引き続き気になっている本はこれ

• アーキテクチャモダナイゼーション【リフロー型】 組織とビジネスの未来を設計する
• GROWTH――「脱」でも「親」でもない新成長論
• シニアエンジニアリングリーダーのしごと ―組織を導き、育てる力を磨く (オライリー・ジャパン)
• シンプリシティ ―持続可能かつ人間的で効果的なソフトウェア開発

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

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

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

文芸書のおすすめ（一般編）

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

青空と逃げる (中公文庫)

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

文芸書のおすすめ（趣味のSF編）

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

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

ループ・オブ・ザ・コード（新潮文庫）

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

文芸書のおすすめ（趣味のミステリ編）

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

少女には向かない完全犯罪

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

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

教養書のおすすめ

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

• 去年と今年の新書大賞を見ながら考える、新書読書計画2026 - 勘と経験と読経

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

なぜ人は締め切りを守れないのか

物語化批判の哲学　〈わたしの人生〉を遊びなおすために (講談社現代新書)

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

ビジネス書のおすすめ

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

メタスキル：努力の価値が変わる時代の「AI×自分」戦略

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

超知能ＡＩをつくれば人類は絶滅する

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

技術書のおすすめ

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

AIエージェント 人類と協働する機械

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

• 強い情報統合と言語化の力を見せつける「AIエージェント 人類と協働する機械」 - 勘と経験と読経

プロダクト倫理: あなたのプロダクトは誰かを傷つけていないか

ソフトウェア倫理に関する本。すなわち「良い」「正しい」プロダクトは何かという話である。類書では「責任あるソフトウェアエンジニアリング ―現実社会における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. 円環少女　５魔導師たちの迷宮 (角川スニーカー文庫) 著名SF作家の若かりし頃のラノベシリーズ
16. 生成AI時代のソフトウェア開発 ―ツールを賢く選択、評価、活用し、より速く効率的な開発を進めるために 良い本だったが、高速で陳腐化している
17. メインテーマは殺人 ホーソーン＆ホロヴィッツ・シリーズ (創元推理文庫) カササギ〜の作家の別シリーズ。こっちも面白い
18. SHIFT解剖　究極の人的資本経営 競合研究。でも現在は方針変わってしまったらしい
19. 物語化批判の哲学　〈わたしの人生〉を遊びなおすために (講談社現代新書) 反物語主義の哲学
20. AIエージェント 人類と協働する機械 AIをどう使うかという考え方の本→書評
21. コンプレックス (岩波新書) 心理学の古典名著。勉強不足を痛感させられる
22. プリンシプル オブ プログラミング 3年目までに身につけたい 一生役立つ101の原理原則 IT名著の入り口になりそうな本。若い人にはここから始めることをおすすめする
23. 主体的に動く アカウンタビリティ・マネジメント（新装版） オズの魔法使いに触発された思考法に関する本
24. 円環少女　６太陽がくだけるとき (角川スニーカー文庫) ラノベ。東京地下戦争編がこれで終了
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. ＮＨＫ １００分 ｄｅ 名著 『谷川俊太郎詩集』 2026年 6月 ［雑誌］ (ＮＨＫテキスト) 詩人のことは全然わかっていなかった
49. プロダクト倫理: あなたのプロダクトは誰かを傷つけていないか ソフトウェア倫理。網羅的でよい
50. 円環少女　７夢のように、夜明けのように (角川スニーカー文庫) ラノベ。幕間劇な巻
51. DIVA ゲンロンＳＦ文庫 ゲンロンSF新人賞。よい
52. ＮＨＫ １００分 ｄｅ 名著 ウィトゲンシュタイン『論理哲学論考』『哲学探究』 2026年 4月 ［雑誌］ (ＮＨＫテキスト) 生成AIの例えで驚きのわかりやすさ
53. 哲学史入門Ⅳ　正義論、功利主義からケアの倫理まで ＮＨＫ出版新書 倫理学のよいガイド
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. 超知能ＡＩをつくれば人類は絶滅する 今読むと答え合わせに間に合う可能性がある
75. ループ・オブ・ザ・コード（新潮文庫） アフターコロナの良作SFエンタメ
76. AIと生きる　対話から始まる成長の物語 数学ガールの登場人物がAIについて語る本
77. 教養としてのパランティア・テクノロジーズ: 世界の意思決定を支える企業の正体 コンパクトな良質のレポート
78. 天皇への敗北―シリーズ哲学講話―（新潮新書） 哲学というより憲法学の本だがよい視点を得られた
79. 機械ぎらい　機械音痴のテクノロジー史 (集英社新書) ソフトウェアも含むUX論
80. 屍人荘の殺人 〈屍人荘の殺人〉シリーズ (創元推理文庫) その発想はなかった！密室ミステリ

この半年の書評記事

1. 翻訳するミドルマネジメントとして「冒険する組織のつくりかた」を読んだ - 勘と経験と読経
2. ソフトウェアテストの教科書と徹底指南書の比較 - 勘と経験と読経
3. 強い情報統合と言語化の力を見せつける「AIエージェント 人類と協働する機械」 - 勘と経験と読経
4. チームと政治の話だった本「プラットフォームエンジニアリング」を読んだ - 勘と経験と読経
5. Living Documentation: Continuous Knowledge Sharing をざっと読んだ - 勘と経験と読経
6. 心理的安全性のその先へ行くための本「失敗できる組織」を読んだ - 勘と経験と読経
7. 組織の足並みを揃える「Aligned ―プロダクト開発におけるステークホルダーとの関係性の築き方」を読んだ - 勘と経験と読経

去年の読書ふりかえり記事

• 2025年上半期に読んだ本まとめ - 勘と経験と読経
• 2025年下半期に読んだ本まとめ、おすすめ本など - 勘と経験と読経

組織の足並みを揃える「Aligned ―プロダクト開発におけるステークホルダーとの関係性の築き方」を読んだ

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

今回とりあげるのは「Aligned ―プロダクト開発におけるステークホルダーとの関係性の築き方」だ。Alignedの意味は「揃える」で、ビジネス的な文脈でいえば「足並みを揃える」となる。まさに、組織の足並みを揃えるようなことが書かれているようだが、実際のところはどうだろう。

Aligned ―プロダクト開発におけるステークホルダーとの関係性の築き方

物語形式が読みやすく、しかしウッとなる

さて、本書の特徴はストーリー仕立てであるということだ。古くは有名な「ザ・ゴール」形式というか、主人公がいて、様々な困難に立ち向かいながら（都合よくいろんな人にアドバイスを貰って）解決していくという仕立てになっている。これが本書のテーマであるステークホルダーとの関係性の構築にうまく当てはまっていて、素晴らしいというのが感想である。特に人間関係に関するテクニックを学ぶ際に重要なのは共感だと考えている。いくら方法論やフレームワークを習得しても、困った時に出てこないと困るのだ。そういう時に、ストーリーで理解しやすい私たちの脳に物語でスッと入ってくる点が良い。ハマった時に「そういえばアイリーはこんな時……」と思い出すことができるだろう。たぶん。

というわけで先走ってしまったが、本書は健康系のアプリを開発する会社にプロダクトマネージャーとして転職してきたアイリーという主人公が奮闘する物語を中心に展開していく。同じようなシチュエーションになったことがないので実際のところがどうなのかはわからないが、オンボーディングが超雑で驚き、その後も組織がカオスで泣ける。

組織マネジメント、リーダーシップ論ではないのが良い

組織の足並みが揃っていない状況でありがちなのが、組織マネジメントの問題であったりリーダーシップの課題だと考えることだ。まあ、もちろんそれらの機能不全が原因ということはあるのだと思うけれども、往々にしてないものねだりになってしまう。

本書では組織の足並みが揃っていないという課題に、（主にアイリーが）権限を持たない立場で周囲を巻き込んでいくというアプローチとなっている点が良い。メンバーの立場からもアクションできるからだ。

人を動かす　改訂文庫版

チーミングや自己組織化の話ではないのも良い

組織の足並みが揃っていない状態というと、チームビルディングの問題じゃないか？　アジャイルの文脈からするとチームの自己組織化に課題があるのでは？　コーチを入れると良いのでわ……みたいな話にもなりがちだが、本書はそういった方向性からも距離を取っているという点も良いと思っている。

もちろんチーミングがうまくできたり、自己組織化に成功すれば良いのだけれども、あくまで当事者として対処するのが本書の流儀のようである。というわけで、アイリーはあくまで1人の担当者として考えていく。

その他本書で勉強したこと

というわけで本書は一種のステークホルダー分析と対策の話なのだが、いくつか興味深いテクニックや解決策の提示もある。個人的に気に入ったものをピックアップしておく。詳細は書籍を参照。

• パワープレーヤー見極めのための「支配的職能のための質問」
• 「上流ステークホルダーと下流ステークホルダー」身も蓋もない分類だけど、なるほどと感心した
• 「DACI意思決定モデル」RACIモデルは知っていたけど、これは知らなかった。
  • DACI：意思決定フレームワーク | Atlassian Team Playbook
• 「ステークホルダーキャンバス」なんでもキャンバスにするのは反対だけど、ステークホルダー一覧としてみても良い整理という印象
• 「衝突を探るテクニック」たとえばワークショップで意図的にひどいアイデアを紹介して判断基準について探るなど、実際にやれるかは別としてテクニックとして知っておくのは良いと思う
• 「ノーと言うときのコツ」こう言うのはいくらでも持っておきたい

でも本書はプロダクト開発のときの話なんでしょう？　いや、そうでもない

というわけで、なかなか良い本だと思っている。だけどタイトルにもあるように「プロダクト開発」向けの本である。ではその他のソフトウェア開発プロジェクトでは活用は難しいだろうか。いや、そうでもない。

• 受託開発などでも、複数部門が関与する大規模プロジェクトでは似たような話になりがち
  • たとえば基幹システムとか、ERPの導入など
  • システム部門の人など、組織のアラインメントが取れなくて、よく引き裂かれているので参考になるのでは

そもそも、大変に読みやすい本でもあるので、プロダクト開発にスコープを狭めず手に取ってみれば良いのではないだろうか

というわけで、本書の感想はここまで。さて次は何を読もうかな。
引き続き気になっている本はこれ（消えた本は実はもう読んでしまっている）

• アーキテクチャモダナイゼーション【リフロー型】 組織とビジネスの未来を設計する
• GROWTH――「脱」でも「親」でもない新成長論
• エンジニアリング戦略の作り方 ―エンジニアリングの難局を打破する意思決定
• シニアエンジニアリングリーダーのしごと ―組織を導き、育てる力を磨く (オライリー・ジャパン)
• シンプリシティ ―持続可能かつ人間的で効果的なソフトウェア開発

エンジニアの「モヤモヤ」を言語化する倫理的意思決定の「セブン・ステップ・ガイド」

日々の業務や個人開発の中で、「これって技術的には可能だが、本当にやっていいのだろうか」「波風を立てたくないが、このやり方は筋が悪い気がする…」とモヤモヤすることがある。

ITエンジニアは、コードを書くプロセスからチーム開発のコミュニケーションに至るまで、常に「正解のない意思決定（倫理的ジレンマ）」に直面している。コンプライアンスや法律のギリギリのラインを攻める時だけでなく、日常的なチーム内の振る舞いにおいても判断に迷う場面は多いはずだ。

そんな時、直感や感情、あるいはその場の空気に流されるのではなく、論理的かつ多角的に解決策を導き出すための強力なフレームワークが存在する。
それが、イリノイ工科大学（IIT）のマイケル・デイビス（Michael Davis）博士が提唱した「セブン・ステップ・ガイド（Seven-Step Guide to Ethical Decision Making）」だ。

参考リソース：

• Seven-step Guide to Ethical Decision Making（金沢工業大学 科学技術応用倫理研究所による翻訳・解説資料 PDF）
• Ethics and Statistics（ペンシルベニア州立大学による同ガイドの解説ページ・英語）

直感を論理に変える「7つのステップ」

セブン・ステップ・ガイドは、複雑な問題を解きほぐすために、以下の7つのプロセスに沿って思考を整理するアプローチだ。

1. 問題を明確にする (State the problem)
   • 自分が直面しているジレンマの本質は何かを言葉にする。
2. 事実を収集・整理する (Check facts)
   • 憶測や思い込みを排し、「客観的に分かっている事実」と「不確かなこと」を切り分ける。
3. ステークホルダーを特定する (Identify relevant factors)
   • 自分の決断によって影響を受けるすべての人や組織（ユーザー、会社、同僚、社会など）を洗い出す。
4. 複数の選択肢を考案する (Develop a list of options)
   • 「やるか・やらないか」の二択ではなく、実行可能な第3、第4の行動案を5つほど列挙する。
5. 選択肢を倫理的にテストする (Test the options)
   • ここがガイドの最重要パートである。出した選択肢に対し、以下の5つのテストを行う。
     • 危害テスト: もたらす悪影響（リスク）が一番少ないか？
     • 公開テスト: この決断が世間に広く報じられても、自分は堂々としていられるか？
     • 可逆性テスト: もし自分が影響を受ける側（被害を被る側）だとしたら、その決断を許容できるか？
     • 徳テスト: 人として、プロフェッショナルとして誇れる行動か？
     • 専門家テスト: 同僚や業界の専門機関は、これを支持してくれるか？
6. 行動を決定する (Make a choice)
   • テスト結果を総合的に判断し、最も妥当な方針を決定する。
7. 再発防止策を検討する (Review / Preventative measures)
   • 今後同じようなジレンマが発生しないための仕組みづくりや予防策を考える。

考えてみてほしい2つのケーススタディ

このガイドが実際の場面でどう役立つのか。最近IT業界で話題になった2つの事例を共有しよう。わたしの考えた「正解」は書かない（そもそも正解はない）。 ぜひ皆さんで、先ほどのセブン・ステップ・ガイドに当てはめて「自分ならどう評価し、どう行動するか」を試してみてほしい。後述するが生成AIあたりと壁打ちするのが手軽でおすすめ。

ケース1：非公式クライアントの実環境テスト

ある若い技術者が、大手飲食チェーンの公式注文システムのUXに不満を持ち、非公式の注文クライアントツールを自作した。これを「試しに」実際に稼働している店舗のサーバーに繋いで注文のテストを行い、その実行結果をネット上に公開しようとしている。
（「自分だけで試すだけなら誰にも迷惑をかけないのでは？」という直感は、5つのテストを通すとどう評価されるだろうか）

ケース2：筋が悪そうに見える方針への介入

同僚や他チームが進めている仕事の方針が、どう見ても「筋が悪い（非効率、無駄が多い）」と感じている。しかし、口を出すと相手のやる気を削いだり、人間関係に波風が立ったりするリスクがある。「静観する」か「あえて口を出す（介入する）」か。プロフェッショナルとしてどう振る舞うべきだろうか。
（参考事例：筋が悪そうに見える方針に口を出す - Konifar's ZATSU）

生成AIを「倫理の壁打ち相手」にする

とはいえ、この7つのステップを一人で、頭の中だけで完結させるのはなかなか骨が折れる。どうしても自分に都合の良いバイアスがかかってしまうこともあるだろう。

そこで推奨したいのが、生成AI（ChatGPTやClaude、Geminiなど）を「壁打ち相手」として活用することだ。
何か判断に迷った時、「今こういう倫理的ジレンマに直面している。セブン・ステップ・ガイドのフレームワークを使って、私が取るべき選択肢を一緒にテストしてくれないか」とプロンプトを投げてみてほしい。

AIは感情に流されることなく、「ステークホルダーに〇〇が欠けている」「公開テストの観点から見ると、その選択肢は炎上リスクが高い」といった客観的なフィードバックを返してくれる。一人で悩むよりも、はるかに解像度の高い意思決定ができるはずだ。
倫理的な意思決定とは、「絶対に正しい一つの答え」を探すことではない。「なぜ自分はその行動を選んだのか、論理的かつ誠実に説明できる状態を作ること」である。

次に業務で「モヤッ」とする状況に直面したら、そのまま見過ごす前に、ぜひこのガイド（とAI）を活用して、納得のいく意思決定を試みてほしい。というか、わたしはやってる。

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

↑ いまこれをベースにした放送大学の授業を受けている。本書は未読

プロダクト倫理: あなたのプロダクトは誰かを傷つけていないか

↑ ソフトウェア開発における近年の倫理的問題などを取り上げており、よい本だった

哲学史入門Ⅳ　正義論、功利主義からケアの倫理まで ＮＨＫ出版新書

↑ 第四巻は倫理学がテーマ。連続性はないので興味があればいきなりⅣ巻から読んで問題ない。よかった

「要求開発」を復刻してみた（かも）

本ブログでときどき言及している、超上流工程向けの開発方法論である「要求開発」というものがある。以前は書籍やコミュニティサイトでの公開文書などがあったのだけれども、現在は入手困難であったりサイトは閉鎖されている。というわけで、復刻してみたという話。Zennというエンジニア向けの情報コミュニティに掲載している。無料です。Zennの仕組みで感想などをフィードバックすることもできる。

zenn.dev

復刻について

どうやったのか

以前に存在していた要求開発のサイトのインターネットアーカイブから当時の資料を取り出して、AIに入力して下書きを書かせ、ブラッシュアップして作成している。とはいえ全自動ということはなくて、だいぶ試行錯誤をしている。元のサイトの文章のコピーでもない形にはなっているはずである。
また、現在（2026年）の時点で明らかに古すぎる情報や、現代の読者にわかりにくい表現なども見直すように心がけている。またコラムという形で過去にはなかった、わたしの意見も少し足している。

どうしてやったのか

以前にに記事で言及した通り、改めて見直されても良い方法論のように考えたからである。
agnozingdays.hatenablog.com
あとは、ついカッとなってやりました。

権利的に問題ないのか

参考にしているアーカイブ上の要求開発のサイトでの掲載情報はそもそもクリエイティブ・コモンズのCC-BYというライセンスで公開しており翻案することが許諾されているという点で、問題ないはずだ。また、ややこしい話だが、そこで掲載されていた文書というのは、当時コミュニティのメンバーとしてわたしが執筆していたということもあり問題ないだろう（誤解のないように補足しておくと、要求開発という手法を考えたのはわたしではない。わたしは分散している各種の資料を統合して、Openthology Ver1.0の文書化をしていたに過ぎない）。

なお、要求開発は出版社から2冊の書籍として発売されている。これらの書籍については手元になかったので参考にしていない（わたしは出版に関与もしていないので、原稿すら持っておらず、AIにも入力していない）。この点でも権利上の問題はないはずだ。

なぜZenn？

これは単に使ってみたかったかから。ブログやNoteなどで掲載することも考えたが、ひとまとまりのEブック的な塊で情報提示するのであればZennは良いサービスだと思う。

クイックリー？

Eブックのタイトルは「要求開発クイックリー」というタイトルにしている。これはDDD Quicklyというドメイン駆動開発に関する短いブックレットを模している。骨子を紹介する短い本にしたかったのでこの形にしている。

• Domain Driven Design（ドメイン駆動設計） Quickly 日本語版 - InfoQ

今後の展望について（？）

特に考えていることはない。ただこの復刻作業を実施して、いくつか考えたことがある。それらは本ブログで掲載するかもしれない。

AI駆動開発時代に「要求開発」が再浮上する（かも）

最近考えていること。AI駆動開発時代に、「要求開発」を見直してもいいんじゃないかと考えたこと。

要求開発~価値ある要求を導き出すプロセスとモデリング

「要求」は引き出すものではなく、開発するもの

『情報システムに対する要求は、あらかじめ存在しているものではなく、ビジネス価値にもとづいて「開発」されるべきものである』。これは、かつて「要求開発」という上流工程の方法論が提唱した中心的なコンセプトである。

agnozingdays.hatenablog.com

従来の「要求分析」や「要求定義」という言葉は、あたかも要求がユーザーの中に最初から存在しており、それをヒアリングして文書化すればよいという錯覚を与えがちである。しかし実際には、作ってみないと分からない部分が多く、何度もトライ＆エラーを繰り返すわけにもいかない。そこでシステムを作る前に、ビジネス価値を入力として「要求を創造・開発する」というプロセスが必要だ、というのが要求開発の根本的な考え方である。

要求開発では、ビジネスの全体像をモデリング（可視化）し、それを中核にステークホルダー間で要求に関する協議と合意形成を進める。このアプローチは非常に芯を食っていたが、その後に台頭したアジャイル開発やプロダクト開発の進展の陰に隠れ、大きなトレンドにはなりきらなかった。
しかし、AI駆動開発が現実のものとなった今、私は「改めて要求開発のアプローチが必要なのではないか」と強く感じている。

AI時代は「コンテキストの正確性」で勝負が決まる

AI駆動開発によって、設計や実装といったソフトウェア開発の中核プロセスは爆速で実行できる時代に入りつつある。それに伴い、「上流工程がより重要になる」という議論が様々な場所で交わされている。

しかし、肝心の上流工程について、従来型の要件定義のフォーマットを埋める作業として語られていることに違和感を覚える。AIを使えば立派な要件定義書を瞬時に作成できるが、「その要件は、本当に正しいのか？」という本質的な問いが残されたままなのだ。

企業情報システムにおいては、精度の高い要求を開発するために、要求開発のアプローチを再考すべき時期に来ている。そこには以下の3つの理由がある。

1. 要求はそもそも「最初から定義できるもの」ではない

現代のシステム開発では、「業務や既存システムを隅々まで理解している設計者がもういない」「業務全体が巨大化しすぎて、全体像を把握している人がいない」という事態が頻発している。要求は、多数の利害関係者の頭の中に、ぼんやりとした形でしか存在していない。存在しないものをAIが引き出すことは不可能である。

2. 「コタツモデル」による集合知の形成が必要である

無矛盾の要求を定義するためには、ビジネスオーナー、業務担当者、開発者が知識を持ち寄り、共に議論する必要がある。要求開発ではこれを「コタツモデル」と呼ぶ。各自の暗黙知をモデリングによって可視化し、構造化することで、初めて欠落を補完し、真の合意形成に至ることができる。

3. 「なぜ作るのか」というコンテキストの強度が結果を左右する

システム化の目的と手段の連鎖を明確にし、それが常に追跡可能（トレーサブル）であることが、今後の開発品質に直結する。AIに無数のトレードオフの中から最適な選択をさせるためには、単なる機能要件の羅列ではなく、「なぜこのシステムが必要なのか」という圧倒的なコンテキストの量と正確性が必要不可欠だからである。
AIがコードを生成するスピードが上がるほど、「何を、なぜ作るのか」を人間同士がモデリングを通じて合意する「要求開発」の領域が、プロジェクトの成否を分ける最大の要所となるはずである。

「要求開発」をモダナイズして再公開する

上記のようなことを思いながら、公開中止されてしまった「要求開発」の復刻について考えている。当時の資料はネット上では非公開になってしまっているが、CC-by-2.5であったし手元にはおおむね揃っている。生成AIなどを使って再整理、モダナイズして公開すれば、良い議論ができるんじゃないかと考えている今日この頃。

ソフトウェア要求　第3版

ケース・スタディとケース・メソッド

中上級の技術者教育について考えている。経験的に有効な手法の一つに実際の事例を用いたグループワークがある。これをより改善するための方法を調べたり、考えたりしたことの覚え書き。

ケース・スタディとケース・メソッド

自分は実際の事例を用いたグループワークのことを雑に「ケース・スタディ」と呼んでいたのだけれども、どうやらこれは正しくないようだ。世の中にはケース・スタディとケース・メソッドという学習方法があるということを最近知った。

ケース・スタディ	ケース・メソッド
事例の発端から結末までが明示されていて、それを第三者の客観的な立場から分析する。具体的状況の分析を通じて問題の原因を知り、再発防止のための教訓を学ぶことを目的とする	結末が明示されておらず、特定の状況での問題解決のための行動案を、当事者の主観的な立場から検討する。具体的状況について問題点を自ら発見し、それを解決していくための判断力を実践的に養うことを目的とする

うーん、自分はだいぶ混同していたことがわかる。

• 「ふりかえり／レトロスペクティブ」「失敗学」のようなアプローチはどちらかというと「ケース・スタディ」に近しい。教訓抽出の取り組みである
• メンバーの学習、スキルアップを目的とする活動は「ケース・メソッド」を使うべきだ
  • 結末は明示すべきではないらしい。この点をあまり意識していなかったな

土木学会「建設ケースメソッドのためのケース作成の手引き」に学ぶ

いろいろと調べていて学びが深かったのが土木学会が公開している建設ケースメソッドのためのケース作成の手引き（PDF）だ。

「ケースメソッド」の手法は、決まった答えのない領域において当事者が適切に判断し行動する能力を養うのに優れた方法であると言われています。それは、受講者が現実に起こった事例を基に作られた「ケース」を読み込み、そこに描かれる「修羅場」に対峙し、登場人物になりきって思い迷いながら判断、決断することによって、さながらその実体験したかのような効果（疑似体験）をもたらすします。そして、グループ討議や全体討議を通じて他者との間で掘り下げた意見交換を行うことにより、より深い考察や新たな気付きが生まれ、幅広い視野を持った実践対応力の涵養が行われるとされています。
建設ケースメソッドとは、この「ケースメソッド」の教育手法を建設分野に応用するものであります。
（同、1. 建設ケースメソッドとは　より）

これだ、と思っている。素晴らしい資料だ。

• 若手が決断を迫られる機会が減少しており、対策が必要という問題意識
• 擬似体験を通じて実践対応力を育む
• 現場で直面した「板挟み」を教材化する
• ケースの肝は「修羅場」（単なる苦労話ではいけない）
• 結末、結果はあえて書かない（正解をなぞるだけ、にしない）

実際に作成されたケース例などが以下のサイトで閲覧できる。参考にしたい
committees.jsce.or.jp

どんな用途で使うのか

（わたしの仕事である）ソフトウェア開発については、いくらでも使い所はありそうだ。プロジェクトマネジメントの領域でも、アーキテクティングでも良さそう。実際にPM教育では似たような取り組みをやったこともある。事例がベースになるので、各種のポストモーテムと関連させてプロセスに組み込んでしまうというのも良いかも。

• プロジェクトマネジメントの領域
  • 計画：複雑な（もしくは困難な）プロジェクトの計画をどうやるか？
  • 交渉：クライアントからの要求で、トレードオフを考えながらどう交渉する？
  • 問題解決：プロジェクト中に発生する困難な問題にどう対応するか
  • 炎上対応：QCDの達成が難しい局面で、どうするか
• アーキテクティングの領域
  • 設計判断：うーんよく考えてみたら、システム設計の面接試験 でいいような気がしてきた
  • 性能問題：どう対処するか
  • トラブル：どう対処するか

AIに書かせてみればいいんじゃない？

ここまでいろいろ考えてきたが、よく考えてみたら雑にAIに書かせてみればいいんじゃないか？という考えが降りてきた。これはちょっと研究してみよう。世の中に存在する豊富なトラブル事例をもとに、適当に合成できるのでは？

ケースメソッド教授法入門―理論・技法・演習・ココロ

新　失敗学　正解をつくる技術