以下の内容はhttps://agnozingdays.hatenablog.com/より取得しました。


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

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

今回とりあげるのは「AIエージェント 人類と協働する機械」だ。良い評判を聞く一方で、執筆そのものは全てAIエージェントが実施しており、いわゆるAI生成書籍でもあるというわけだが、実際のところはどうだろうか。


「AIエージェント 人類と協働する機械」の紹介

AIエージェント 人類と協働する機械』は、生成AIを単なる効率化ツールではなく、人と協働する存在として再定義する一冊である。文字の発明からソフトウェアの民主化、そしてAIによる知識創造へと至る歴史を俯瞰しながら、仕事・組織・競争の構造変化を描き出す。問いは明快である。仕事は奪われるのか、生産性とは何か、企業は何で競争すべきか。本書は「相対優位」と「知識創造」という視点から、その答えを提示する。AI時代を生き抜くための思考の地図となる一冊である。

特に以下のような点が良いと思う

  • 著者が技術者でもあり、かつAIエージェントを早くから活用しているという点で、人文的な視点と技術的な視点のバランスが優れている
  • 良くも悪くも現在進行中の社会変化のさまざまな断片情報をつなぎ合わせて、優れた情報統合と言語化を実現している
  • 書籍そのものがAIエージェントと著者の協働によって制作されており、単なるAI出力ではなく、人間の構想力とAIの処理能力が掛け合わさることで、通常のAI対話をはるかに超える統合力と完成度を実現している点に強い説得力がある

AIエージェント協働執筆について

気になるのは、AIエージェント協働執筆という点である。その概要については冒頭でも紹介した著者の記事に記載されている。

が、書籍版には付録「本書はどのようにつくられたか」が収録されており、より具体的なアプローチが説明されている。詳細は書籍を見ていただくとして、特にすごいと感じたのは以下の点だ。

  • インプットとして、著者の講演だけでなく、関連する情報を含む様々な会議の議事録などをインプット
  • 前著や他の執筆記事から文体などに関する指示書を作成
  • レビューのための編集コメントシステムも(AIで)作成

などであるが、よく考えてみればどれも、いますぐ出来ることなのである(単にやっていないだけ)。また、結果として定型作業が大幅に圧縮されたおかげで人間は知識創造により注力できたということ。まさに本書のテーマを具現化する確かな事例と感じた。

マネジメントからの質問の回答のタネ本にも……

というわけで大変良い本なのだが、わたしは本来的ではない使い方もしている。それはマネジメントからの(雑な)AI活用関連の質問への回答のタネ本である。ビジネス誌やネット記事を見て、立場的には様々な方針や対応方法の相談を受けることもある。その際の情報源として本書はとても便利である。少なくとも2025年後半基準で、極めて優れた各種情報の統合と言語化が実現されるからである。

と思っていたら、本書著者のX投稿から衝撃の事実が。なんと本書をベースとした公式GPTsが公開されているというのである。表紙の次ページにリンクが!な、なんだってー!
これで、マネジメント対応もさらに捗ることが確実だ。

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

確か有名Podcastゆる言語ラジオで面白い新書を探すなら雑誌中央公論の3月号を読むと良いと紹介されているので、昨年からチェックをしている。2026年の新書大賞も発表されたので、去年読んだ新書を振り返りつつ、今年読みたい新書を選別した、という話。

雑誌「中央公論」の3月号

2025年3月号

2026年3月号

発売日はだいたい2月10日前後。

読み始めたのが2025年からなので昔どうだったのかはわからないけれど、新書大賞についてはこんな構成で紹介されている。

  • 新書通100人が厳選した年間ベスト20 (人数は変動するようで26年は103人になってた)
  • ベスト20までの紹介(選者推薦文のサマリー)
  • 大賞受賞者インタビュー
  • 目利き45人が選ぶ私のおススメ新書(ひとり5冊)

目利きのおススメではベスト20に選ばれなかった「えっ、こんな本があったの」という本もピックアップされているのが興味深い。

というわけでこの特集を眺めながら、今年はどの本を読もうかと計画を立てているわけである(わたしはハズレ率を下げるために、著者や出版社や広告以外で誰かが推薦している本しか読まないポリシーを立てている)。

2025年の新書大賞特集からピックアップして実際読んだ本のふりかえり

読んだ本

積んでいる本

ふりかえってみると、やはり「働き方」や「政治・経済」「学問」関係の本は楽しめた一方で、純粋な歴史や教養に関する本はそうではなかったような気がする。これを踏まえて今年なにを読むかを考えたい。

2026年の新書大賞特集からピックアップする今年読みたい本

すでに読んでる

読みたい本

というわけで、まずはこのあたりを中心に読んでいきたい。新書は数時間で読めるので、通勤時間やスキマ時間にやっつけたい。Kindleセールを狙っていけば、ワンコインで入手できることも多いしね。

Windows Vistaの研究(2008)とチームの嫌な臭い

いま「AIエージェント 人類と協働する機械」を読んでいる(良い本だ)のだけれども、その中でずいぶんと懐かしい話が出ていた。それはMicrosoft Windows Vistaリポジトリと組織に関する研究だ。いわゆるコンウェイの法則の話だけれども、改めていろいろ読み返している、という話。

コンウェイの法則の妥当性は、多くの実証研究によって裏付けられています。
マイクロソフトの研究チームが2008年に発表した「Windows Vista ケーススタディ」は特に興味深い結果を示しています。3,400以上のバイナリと組織メトリクスを解析した結果、組織の複雑さが高いモジュールほど障害率が高いことが明らかになりました。さらに驚くべきことに、組織指標は従来のコード指標よりも故障予測精度が高かったのです。これは、コードの品質そのものよりも、どの組織の誰が関与したかという組織的要因が障害発生に直結することを示しています。


AIエージェント 人類と協働する機械、第7章 人と半導体の価値転換、より

Making Software

このVistaの話を初めて知ったのは「Making Software ―エビデンスが変えるソフトウェア開発」に収録されたエッセイからだった。2011年の本であるが示唆のある良書だ。この本は様々なソフトウェア開発に関する言説を、複数の論文などを参照しながら複眼的に検証するというもので、他にもなかなか楽しい話が載っている。

Vista研究について言及するのは「11章 コンウェイ法則の系」で、ここではVista研究だけでなく複数の研究をもとに、コンウェイの法則について検証している。結論を抜粋するとこんな感じだ。

コンウェイの法則の系は、ソフトウェア開発という挑戦にマイナスの影響もプラスの影響ももたらし得るものであり、プラスの影響を活用することで、プロジェクトのステークホルダたちに力を与えることができます。今やその効果を支持するエビデンスが存在するわけですから、それを無視するならそれなりのリスクを覚悟すべきでしょう。


Making Software ―エビデンスが変えるソフトウェア開発 11章 コンウェイ法則の系、より

ただ、当時は機械翻訳の精度もまだまだであり、生成AIもなかったので、現論文を参照してより深く考えるということはできなかった。しかし、今は違う。というわけで 現論文を今回はちゃんと読んでみようと思ったのである。

The Influence of Organizational Structure on Software Quality

以下、論文を読んで理解したことを書くのだけど、いくつか注意点がある。まず Vistaの開発は25年前の話であるということ。また、有名なMicrosoftの「Hit Refresh(ヒット・リフレッシュ) マイクロソフト再興とテクノロジーの未来 (日経ビジネス人文庫)」(再起動)前の話であり、Microsoft社内の開発者文化はおそらくかなり悪かった(このあたりは 最近読んだ「FRICTION(フリクション) 職場の問題を解決する摩擦の力」でも紹介されている)だろうという点である。

そのあたりを差っ引いた上で、論文に書かれていることをざっくりと読んでみよう。

組織指標(Organizational Metrics)

あるバイナリ(モジュール)に関与した

  • 開発者数
  • チーム数
  • 上司(マネージャ)の数
  • 途中で担当者が変更された回数
  • 組織構造の複雑さ(報告ラインの多さ)

などを組織メトリクスとして、故障(Failures)との関係性を分析するというのが論文のアプローチだ。すでに嫌な予感が……

わかったこと

  • ソフトウェア品質は「コード」より「人と組織」に強く依存する
  • 人員の入れ替え・関与人数が増えるほど故障率は上がる
  • しきい値」を超えると故障が急増する
    • 開発者:3人以上
    • 担当交代:2回以上
    • 関与チーム:3チーム以上
    • このあたりから 故障率が段階的に跳ね上がる
  • 組織メトリクスは故障予測に非常に有効
  • 地理的分散(海外・別拠点)は本質的な問題ではない
  • 故障の原因は「知識の断絶」

全般的には知ってるわ、という結論だが、しきい値のあたりが生々しい

実証的な研究は味わい深い

本論文で語られていることは、嫌な臭いとしてエンジニアには経験的に知られているものだとは思うが、データとして実証されると極めて示唆深い。

Google Scholar あたりで本論文を引用している論文などを漁れば、もうちょっと面白い話が読めるのではないかと思う今日この頃。

ソフトウェアテストの教科書と徹底指南書の比較

ソフトウェアの品質保証やテスト関して紹介しやすいコンテンツとして「【この1冊でよくわかる】ソフトウェアテストの教科書 [増補改訂 第2版]」と「ソフトウェアテスト徹底指南書 〜開発の高品質と高スピードを両立させる実践アプローチ」をよく利用している。タイトル通りだけれども教科書は基本を確認しやすく、指南書は高度で専門的な内容となっている。要は使い分けなのだけれども、では共通的な部分がどこまで共通なのかが気になった。というわけで共通部分を中心にちゃんと比較してみようと思ったという記事*1

なお内容は読み手(わたし)の力量による。確からしさは保証できない(たぶん大丈夫だと思っているけれど)

教科書と徹底指南書の概要

だいたいこんな感じだろうか

両書の共通項についての比較 読み比べ

以下、『ソフトウェアテストの教科書』(Text)の章番号を T-Ch、『ソフトウェアテスト徹底指南書』(Guide)の章番号を G-Ch で記載する*2

基本概念:ソフトウェアテストとは

まずは入り口から見て行こう。T-Ch 1、G-Ch1 タイトルは同じく「ソフトウェアテストとは」である。この時点で両者の方向性が異なっているのことがわかり興味深い。

ソフトウェアテストとは、欠陥を取り除いて、ユーザーの要求を満たす、品質のよいソフトウェアを作ること』(T-Ch 1)

ソフトウェアテストは、ソフトウェアからフィードバックを得る活動です。そのフィードバックは、デバッグや品質向上といった様 々なソフトウェア開発活動で活用されます』(G-Ch 1)

冒頭でも述べたが、教科書の方は企業向け情報システム開発(いわゆるエンプラ開発)を意識しており、極端にいえば「作ってテストしてリリースする」というスコープであるのに対して、指南書はウェブ・プロダクト開発などを含む継続的な品質活動までをスコープにしているところが大きな違いだ。

テスト戦略

教科書はシンプルにV字モデルを中心に工程とテスト戦略を整理している(T-Ch 2「ソフトウェア開発の流れとテスト工程」)。主軸はウォーターフォール型開発(アジャイルは別章 T-Ch 12 で解説)で、丁寧に段階的な開発工程の説明を行い、それに対比させてどのようなテストを行うかを解説しており シンプルでよい。ソフトウェア開発の初心者にとってはわかりやすい良い説明だと思う。なおコラムでW字モデルが紹介されている。

一方で、指南書ではV字モデルは「伝統的な開発のテスト」というひとことで済まされており、細かい説明もない(G-Ch 5「定番のテスト戦略」>5.3「W字モデルの戦略」)。また他の戦略として アジャイル開発(G-Ch 6)、継続的デリバリー(G-Ch 7)、DevOps(G-Ch 8)、プロダクトライン開発(G-Ch 9)もカバーされている。応用編ともいえるが、実際のソフトウェア開発におけるウォーターフォール開発の適用機会も減っているという意味では、指南書のほうが射程も長く、実践的な印象だ。

テスト計画

ソフトウェアテストは計画も大事。ただこのテスト計画については、両書で取り扱い方は異なる。 教科書では概論を述べたあとは事例紹介を中心に計画を紹介していく(T-Ch 9「テストドキュメントの作成」)。一方で指南書ではじっくりと考え方やポイントについて論じていく(G-Ch 32「テスト計画」)。どちらも最終的に目標とするアウトプットは似ている。

とっつきやすさで言えば教科書はわかりやすいだろう。ただ、指南書には以下のような記述があり、まさにこの懸念はあると思う。

テスト計画書には様々なドキュメントテンプレートが提唱されています。(中略)不適切なテスト計画のやり方として、このテスト計画書のテンプレートを埋めるだけでテスト計画を進めるというものがあります(G-Ch 32.2「アンチパターン:テンプレート穴埋め計画」)

いやな臭い。

テスト観点/テスト分析

  テスト観点というのはあいまいな表現だけど、「テストの切り口」(T-Ch 2)とか「テストすべきもの」(G-Ch 14)のことを指している。このテスト観点についての扱い方も対照的だ。   教科書ではテスト観点については「必要である」ということと「再利用可能なテスト観点一覧を保持して、ノウハウ化する」ということが述べられている一方で具体的な作成方法についてはあまり触れていない(そのかわり、かなり有用なサンプルが掲載されている)(T-Ch 1「ソフトウェア開発の流れとテスト工程」>「テスト観点一覧表の作り方」)。   一方で指南書ではテスト観点の作成そのものが「テスト基本分析」(G-Ch 12)「テスト詳細分析」(G-Ch 15)と整理されており、かなり詳細に記載されている。ただ、内容はかなり難しく応用編になっているともいえるだろう。

テスト設計/テスト技法

これは言うまでもなく教科書より指南書のほうが多数の技法をカバーしている。が、教科書でも必要なラインナップはカバーしていると思う。

テスト実装/テストケース作成

実はこのあたりからちょっと印象が変わる。教科書のほうが親切に見えるのだ。

  • 指南書では引き続き、抽象度の高い説明が中心である(G-Ch 18「テスト実装」)。優れた説明だけど、抽象度が高くて、ちょっとツラい
  • 教科書はサンプルを示しながらの説明となっている(T-Ch 9「テストドキュメントの作成」>「テストケース作成のための中間成果物」、「テストケース」「テストログ」)

テンプレート思考になってサンプルの見かけを真似てしまうだけになる恐れはあるけれども、テストケース作成という点では教科書の説明の仕方はたいへんにわかりやすいと思う。

結局、教科書と指南書はどんな使い分けが良いのか

私見だが、こんな感じがよさそう

  • 教科書:初めてテストについて学びたい人、もしくは基礎を学び直したい人向け。ハウツー本として、書いてある内容を実行すれば一定レベルのテストが実施できる
  • 指南書:品質に関して何らかの課題を持っていて、解決のヒントを探している人向け。

おまけ:書籍内容の比較表

注:この表の作成にはAIを利用した(目次だけ入力している)。便利な世の中になったものだ。

凡例(再掲)

基本・技法・設計

縦:徹底指南書 (章構成) 横:教科書 Part 1 (基本・プロセス)
Ch 1〜2
横:教科書 Part 2 (技法・設計)
Ch 3〜8
Part I & II
基本・戦略・プロセス
(Ch 1〜10)
【共通:基本概念】
・T-Ch 1「テストとは」⇔ G-Ch 1「目的・課題」
・T-Ch 2「開発の流れ・Wモデル」⇔ G-Ch 5.3「Wモデルの戦略」

【指南書の拡張】
開発モデル別の戦略論へ展開。
・シフトレフト (G-Ch 5.1)
アジャイル戦略 (G-Ch 6)
・DevOps/継続的デリバリー (G-Ch 7, 8)
-
Part III
分析・設計・技法
(Ch 11〜17, 21〜24)
【指南書の拡張:分析】
技法適用の前に「分析・設計」プロセスを定義。
・テスト基本分析 (G-Ch 12)
・テストアーキテクチャ設計/VSTeP (G-Ch 13, 14)
【共通:ブラックボックス技法】
・T-Ch 4「同値・境界値」⇔ G-Ch 16.3, 16.4
・T-Ch 5「デシジョン」⇔ G-Ch 16.6
・T-Ch 6「状態遷移」⇔ G-Ch 16.7
・T-Ch 7「組合せ」⇔ G-Ch 16.8, 17.3
・T-Ch 3「ホワイトボックス」⇔ G-Ch 16.10「制御フロー」

【指南書の拡張】
・探索的テスト (G-Ch 22)
・ユーザーストーリーテスト (G-Ch 23)
Part III & VI
実装・環境・実行
(Ch 18〜20, 37〜43)
- 【共通:テスト実装】
設計したテストを手順化・実施するフェーズ。
・G-Ch 18「テスト実装(手順作成)」
・G-Ch 20「実行と結果判定」
Part IV
自動テスト
(Ch 25〜31)
- 【関連:ホワイトボックス】
教科書 Ch 3 の内容は、指南書では「開発者テスト」として深化。
・G-Ch 30「開発者テスト」
・G-Ch 31「テスト駆動開発(TDD)」

ドキュメント・自動化・マネジメント

縦:徹底指南書 (章構成) 横:教科書 Part 3 (ドキュメント・管理)
Ch 9〜11
横:教科書 Part 4 (次のステップ)
Ch 12〜13
Part I & II
基本・戦略・プロセス
(Ch 1〜10)
- 【共通:アジャイル
・T-Ch 12「アジャイル開発とテスト」⇔ G-Ch 6「アジャイル開発でのテスト戦略」
※教科書は「概要」、指南書は「4象限」や「ゾンビスクラム対策」など実践戦略。
Part III
分析・設計・技法
(Ch 11〜17, 21〜24)
【共通:ドキュメント作成】
・T-Ch 10「正しい書き方」⇔ G-Ch 15「詳細設計(ケース設計)」
-
Part III & VI
実装・環境・実行
(Ch 18〜20, 37〜43)
【共通:不具合管理】
・T-Ch 9,11「不具合報告書・分類」⇔ G-Ch 20.5「バグ報告」, G-Ch 38「バグ管理とチケット設計」
【指南書の拡張:CI/CD】
自動化を支える基盤技術。
・G-Ch 37「CI/CDの構築」
・G-Ch 42「ブランチ管理」
Part IV
自動テスト
(Ch 25〜31)
- 【共通:テスト自動化】
・T-Ch 13「導入・ツール」⇔ G-Ch 25「自動テストの活用」

【指南書の拡張】
実装・コード品質まで深く網羅。
・品質/Flaky対応 (G-Ch 26)
・設計原則/FIRST/xUTP (G-Ch 28)
デザインパターン/PageObject (G-Ch 29)
Part V
計画とマネジメント
(Ch 32〜36)
【共通:計画とモニタリング】
・T-Ch 9「テスト計画書」⇔ G-Ch 32「テスト計画」
・T-Ch 11「モニタリング」⇔ G-Ch 33「モニタリングとコントロール

【指南書の拡張】
リーダー・マネージャー向け視点。
・プロジェクトリスク (G-Ch 34)
・組織能力・採用・心理的安全性 (G-Ch 35, 36)
-

*1:この記事に限った話ではないが、あとで自分で読み返したり人に説明するときに利用するために作成した

*2:指南書を英訳するとガイドブックになる、というのはちょっとした発見だった。仕事でガイドブック的なものを書くときに今度からは指南書という名称にしようと思う

続:ソフトウェア開発で「なぜなぜ分析」はアンチパターン

先日書いた「ソフトウェア開発で「なぜなぜ分析」はアンチパターン」という記事には想定外の反響をいただいた。読んでいただいた方、コメントされた方には感謝する。勉強させていただいた。

コメントは全て目を通していると思うが、寄せていただいた意見を参考に追加で考えたことなどについて本記事で補足する。

本記事の前提となる前の記事はこちら。
agnozingdays.hatenablog.com

筆者は「なぜなぜ分析」を理解していない/誤解しているのではないか?

なぜなぜ分析にはメリットもあるが、筆者の理解、使い方の誤りがあるのではないかというようなご意見をいくつかいただいた。確かに、手法の確認が不十分だったかもしれない。

ただ一方で、指摘された「ただしい使い方」がどこまで共有されているのかについては疑問も感じている。今回の記事執筆にあたっては(この種の手法の辞書としてよく使っている)「アイデア大全*1」を確認しているが、基本的には『1つの出来事・現象について「それはなぜか?」と自問自答することを5回繰り返す』という手法しか紹介されていない。

他にはアクセスしやすい信頼できる情報源としてIPAの「情報処理システム高信頼化教訓集 ITサービス編 別冊Ⅱ:障害分析手法」というものもある。ただここでも手法の説明は大きく変わりはなく、これを理解してよい分析ができるのかという点には疑問が残る。

なぜなぜ分析は、発生した事象(問題:対策を必要とする事実)を起点として、その事象が発生した根本原因(それに対策すれば問題が再発しなくなる原因)に至るまで、「なぜ(それが発生したのか)」と問いながら原因を遡っていく分析手法である。
分析を実施するにあたってのポイントは以下の 2 点である。
① 問題事象を発生させた直接の原因(直接原因)を見つけ、さらに直接原因を引き起こした原因を見つけるという手順をくり返し、本質的な原因(根本原因)を見つけ出す。
② 分析は事実をもとに実施する。そのため、実施の際には、可能な限り障害事象の当事者(障害を引き起こした人等)の参加を促すことが望ましい。その際に注意すべきことは、あくまで、実施の目的は障害を発生させた「個人」を責めることではなく、原因を究明して「組織」としての再発防止策を検討することである、ということを参加者に徹底することである。


情報処理システム高信頼化教訓集 ITサービス編 別冊Ⅱ:障害分析手法 2.1.1 なぜなぜ分析による原因分析 より

より専門的な書籍などで理解を深めると分析の誤りが回避できるのかもしれないが、では(製造業ではなく)ソフトウェア開発の現場でそこまで理解を深められることができるのか、という点については疑問を感じている*2

もしおすすめ書籍などがあったら紹介していただきたい。

記事に書かれているダメな分析例が作為的すぎる

これは素直に手抜きだったと反省している。ただ、それでは他の例として上記でも引用したIPA資料にある例を引いてみると、印象が変わるのかという点については問題提起をしておきたい。

IPAの資料にある事例》

  • A社のオンラインサービスが丸一日間停止した。
  • (なぜ?)お客様のサービス(復旧時間、障害中対応)に時間を要した(から)
  • (なぜ?)負荷分散装置はD社と共用しており、再起動等の対処によるD社サービスへの影響が不明のため、A社の了解のもと対処を業務終了後まで先送りすることとした(から)
  • (なぜ?)トラブル発生時等の情報共有のための利用者間の連絡体制は確立されていなかった(から、また)A社の論理区画を再起動した場合の共同利用している他企業D社のオンライン業務の影響を知らなかった(から)
  • 対策
    • 共同利用者間の情報共有の強化を行う
    • (また)B社は、システムを停止/再起動させる場合についての条件や手順、責任等に関する取決めをSLAで定義し、共同利用各社と合意する

事例の前提となっているだろうインフラ構成の古さはあるが、それを差し引いてもこのような分析には わかりやすさを重視しすぎて、本来検討すべき事項の欠落を感じてしまう。IPAの例なので分析の妥当性はそれなりにあると思うが、どうだろうか。

なぜなぜ分析に代わる代替手段が記事に記載されていない

ご指摘の通りで記載していないが個人ブログであるということも踏まえてお許しいただきたい。ただ、自分の考えとしては、インシデントの分析にあたって特定の手法や方法論を標準的に使用すること、そのものが正しくないと考えてはいる。前回の記事でも書いたが「複雑系は、複雑な方法で故障する」ので、その事象を観察した上で適切な分析方法も都度検討すべきではないか、というのが自分の考えである。

引き続き、ご意見などがあればX(旧Twitter)か はてなブックマーク などでどうぞ。

*1:先に「問題解決大全」を確認したのだけど、以外にも本手法が掲載されているのは「アイデア大全」でちょっと驚いた

*2:他には「ソフトウェア品質知識体系ガイド (第3版) ―SQuBOK Guide V3―」までは確認したのだけれども、手法の説明は載っていなかった

ソフトウェア開発で「なぜなぜ分析」はアンチパターン

なぜなぜ分析、根本原因分析、RCA(Root Cause Analysis)、5 Why手法はソフトウェア開発に適用すべきではなく、アンチパターンだと思っている。何度も説明するのが面倒なのでここにその理由を書いておく。

なお、超シンプルで小さなソフトウェアには有効かもしれない。が、現代ではそんな小さなソフトウェアは存在しないし、存在したとしても「なぜなぜ分析」の対象にはならないだろう。

(2026/1/26 23:00 追記。本記事には様々なご意見をいただき感謝。コメントを見て考えたことについて、「続:ソフトウェア開発で「なぜなぜ分析」はアンチパターン - 勘と経験と読経」という記事を書きました)

ソフトウェア開発に「なぜなぜ分析」を適用すべきではない理由

  • ソフトウェアは(平均的には)複雑系
  • 複雑系は、複雑な方法で故障する
  • インシデント/問題に対する単一の因果関係を持つ単一の根本原因は、そもそも存在しない
  • なぜなぜ分析は単一な根本原因に焦点を当てるために過度な、もしくは誤った抽象化を行いやすい

大まかに整理すると、ソフトウェア開発に「なぜなぜ分析」を適用すべきではない理由は上記のようなものになる。適用すべきではない、というのはかなり上品な言い方で、もっと言えば有害である。特に、なぜなぜ分析はその特性上、人的ミスに帰結しやすいという点も問題だ。

なぜ「なぜなぜ分析」はなくならないのか

  • 会社のルールだから
    • 正確には、古い会社のルールを見直さず放置しているから
  • 偉い人が言うから
    • 正確には、偉い人が学習を怠り、過去の自分の成功体験を繰り返しているから
  • 他の方法を勉強していないから
  • なぜなぜ分析の結果は、対外的に説明しやすいから

「なぜなぜ分析」はなくならない理由はこんなものだろう。なお「対外的に説明しやすい」点についてはある程度は理解できる。なぜなぜ分析が示すシンプルな因果関係、ストーリーはわかりやすいことは確かである。しかし、結果として選択したシンプルな因果関係、ストーリーはすぐに破綻する。また別の理由で次のインシデントが発生するからである。再発防止策がさらに増える。チェックリストが拡充される。そして無駄な作業ばかりが増え、生産性は落ちていく。

「なぜなぜ分析」がダメな例

先日読んだ「SREをはじめよう ―個人と組織による信頼性獲得への第一歩」にはこんな例が掲載されている。

  • システムがダウンした
  • (なぜ?)サーバーが停止したから
  • (なぜ?)ディスクがいっぱいになったから
  • (なぜ?)ログが肥大したから
  • (なぜ?)ログローテしてなかったから
  • (なぜ?)設定ファイルが漏れていたから →これが根本原因!
  • すべての設定ファイルにログローテーションの設定があることを確認!

ツッコミどころが満載である*1。まあ作為的な例ではあるが。

観察した1つの事柄を深く掘り下げようとするのは構いませんが、その状況における他の要因を無視することを犠牲にしてはいけません。 ときには、なぜを繰り返す前に、何(つまり、何が起こったのか)の質問にすべて答えたことを確認する必要があります。


「なぜなぜ分析」は、単一の根本原因に焦点を当てることが、失敗から学ぶ上でいかに不利になるかを示す、特に明らかな例です。 この用語を使うと、明確な因果の連鎖を1つ特定できたと思った時点で、インシデントを深く観察することを(潜在的にでも)やめてしまうことになりますが、これはアンチパターンです。


SREをはじめよう ―個人と組織による信頼性獲得への第一歩 10章 失敗から学習する、より

「根本原因」という正解はそもそも存在しない

言うまでもなく、インシデントの原因は無数にある。もちろん、そういった複合要因をちゃんと分析すればいいのだが「根本原因」という用語はすべての背後に1つの真の原因があるように見えてしまう点で、ダメだと考えている。

そういえば過去にこんなことも調べていた
agnozingdays.hatenablog.com

自戒を込めて、特に(自分を含む)少し前の教育を受けていた世代は、優等生主義というか正解主義のきらいがある。注意したい。畑村先生がいいことを言っていた。

現代は、いままでの思考法ーー問題を分析し、その問題の正解を外から持ってくるという思考法ーーだけでは、多くの場面で通用しないことは、前章で述べてきた通りです。
前章でも触れましたが、私は今の時代を「正解がない時代」というより、唯一解のない「正解がいくつもある時代」と捉えています。


新 失敗学 正解をつくる技術、第2章 すべては仮説から始まる より

というわけで、言いたいことはこんなことです

*1:書籍では大量ログ出力した原因を調べるべきでは?というツッコミ例が載っているが、他にも監視とか構成とかテストとか無限に気になる

翻訳するミドルマネジメントとして「冒険する組織のつくりかた」を読んだ

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

じつは今回紹介する本「冒険する組織のつくりかた──「軍事的世界観」を抜け出す5つの思考法」は積読ではない。昨年の上半期に読んで、内容が良かったので組織のマネージャー同士の読書会でも読んで、さらに同僚に紹介するために今回読んだ本の紹介である。昨年末にデッドライン読書会のメンバーで忘年会をした際にいろいろ議論して、本書を紹介したという次第。

「冒険する組織のつくりかた」の紹介

詳しくは出版社サイトを見るのが良いと思うが、ざっくりと紹介すると以下のような本である。

  • 著者は組織開発系のコンサル会社MIMIGURI代表の安斎さん。本書の前は「問いかけの作法」という本でも話題になっていた方である(こちらも良い本だったと記憶している)。
  • 従来の企業は「戦略」という言葉に代表されるように軍事的なものの見方で運用されている。
  • 一方で若者を中心に(様々な要因で)個人に対しては「人生中心のキャリア観」が(不可逆的に)定着しつつある。この「人生中心のキャリア観」と軍事的なものの見方は相性が悪く、それがモヤモヤ感や離職の引き金になっている。
  • 企業側の考え方も新たな考え方=「冒険的な世界観」にアップデートすべきなのでは?

ちなみにわたしが本書を知ったきっかけはPodcastのfukabori.fmのEP128である。もし興味があれば、まずこちらのエピソードを聴いてみると良いかもしれない。
fukabori.fm

翻訳するミドルマネジメント

記事タイトルにも入れたのだけれども、現代のミドルマネジメント(中間管理職)は組織の中でさまざまなメッセージの翻訳を求められていると考えている。なぜなら、ミドルマネジメント(中間管理職)は知識も情報量も異なる複数の階層の間に挟まれているからだ。

  • 経営層・上位マネジメント ⇔ 現場 (抽象度が異なる)
  • シニア社員 ⇔ 若手・ジュニア社員 (知識や経験、属する文化が異なる)

環境変化が激しい昨今、このギャップを埋めるための翻訳のような作業がとてつもなく困難であり、ストレスだ。というわけで困っていたところなのだが、本書はこの困りごとを軽減するためのヒントを与えてくれる。

軍事的世界観 & 冒険的世界観

本書のタイトルや宣伝文句を見ると、本書は(従来企業の)「軍事的世界観」はダメで、「冒険的世界観」が良いということが書かれているように見えるかもしれないが、実際にはもっと現実的に両方の良い点を活用していくことを推奨している。よって「軍事的世界観 VS. 冒険的世界観」ではないという点もポイントだ。

「はじめに」で予告したとおり、本書の目的は、軍事的世界観から冒険的世界観へと「組織のパラダイム」をシフトさせることにあります。ですがこれは、有益な軍事的ツールを"すべて放棄する”ということではありません。
(中略)
しかしここには、先人が築いた軍事的方法論を否定する意図はありません。むしろ、ビジネスにおける各種の戦略論は、冒険的世界観にとっても人類の欠かせない知的資産であり、リスペクトすべき対象であるのは変わらないのです。
冒険する組織のつくりかた──「軍事的世界観」を抜け出す5つの思考法、序論 より

この実践的な落としどころが、取り込みやすさにもつながっていると思う。

そもそも、企業は冒険的世界観にすでに向かっている

本書を読んであらためて感じるのは、本書を読むまでもなく企業はすでに冒険的世界観に向かいつつあるということでもある。MVVすなわちミッション・ビジョン・バリューを企業として策定することはあたりまえになってきたし、企業文化への注目も増している。また企業内でエンゲージメントサーベイを行うなどの取り組みも実施されている。

ただ、そういった新たな施策がイマイチ効果を上げていない、もしくは既存の組織経営と足並みが揃っていないというモヤモヤした違和感があるのではないだろうか。

本書では、Creative Cultivation Model(CCM)というモデル(モデル自体はMIMIGURIのサイトで参照できる)を横に置きながら解決するヒントなども示されていて、これは強い刺激になった。

というわけで本書は 上下の間でモヤモヤしながら闘うミドルマネジメントが読むと良い本だと思うのだ。おすすめだ。
(実際、あまりに良かったので 周囲のミドルマネージャーと読書会もやった)

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

だけど、このあたりから選んでもよいかも?
www.shoeisha.co.jp




以上の内容はhttps://agnozingdays.hatenablog.com/より取得しました。
このページはhttp://font.textar.tv/のウェブフォントを使用してます

不具合報告/要望等はこちらへお願いします。
モバイルやる夫Viewer Ver0.14