デッドライン読書会#09「IT業界の病理学」の感想文

課題図書

第９回のデッドライン読書会（読書×締切ではじめる「デッドライン読書会」を始めました）の課題図書は、「IT業界の病理学」でした。2019年11月に発行された書籍です。今回は１回で全ページ分を読む回になります。

感想文

感想文です。全体を通して感じたこと、個別に気になった部分へのコメントをまとめます。

全体

感想の前に、本書の構成を説明します。

本書では、IT業界に存在する「病」を、研究して治療・予防することを目指して病理学とうたっています。各章が病名となっており、症例は合計34ありました。それらに対して、

• 症状と影響
• 原因・背景
• 治療法
• 予防法
• 異説
• 補足

という切り口で対処方法などをまとめています。

本書で取り上げられた「病」は私も見たことある（罹ったことがある！？）ものがあり、各章のタイトルだけ見ても「それね！」と思うものが多々ありました。例えば、

• 「運用でカバー」依存症
• プロジェクト管理無計画病
• 再発防止につながらないトラブル解析

各章は著者らの現場での実体験に基づくものが多く、必ずしも読者の現場（や、その病）にはぴったり当てはまらないかもしれませんが、各章で上がった症例の着眼点や病理学の切り口が参考になり、自身で過去の苦い思い出を思い出しつつ、自分で分析するのが面白そうだなと感じました。

個別

本書で個別に気になった部分をまとめます。

キーワードは「歯を磨くように」です。

2-01 全部揃ってからレビュー P.55

なにかのレビューをするときにビッグバン的に全部揃ってからレビューをスタートするのではなく、気軽にカジュアルに小さな単位で進めましょうというメタファーです。この歯科治療のメタファーはちょっと面白いと思って、メモ。

■設計ドキュメントに記載されていない内容はテストされない（テストが漏れる）

■テスト担当者の大きな責任の１つは、設計レビューのレビューワー全員が見落としている欠陥を指摘することであると考えている

2-06 テストケース肥大病 P.77

ちょっとこの記載は微妙と思いました。

ここでいう設計ドキュメントに記載されていない内容とは、（ドキュメントは横においといて）「設計されているもの」だろうか、「設計されていないもの」だろうか、それともいわゆる「当たり前品質」的なものだろうか。気づきレベルではテスト担当者が指摘できるかもしれないが、それを最後の砦と役割付けるのだけではなく、もう一歩の改善策が必要なんだろうな。

QAW（Quality Attribute Workshop）という手法を使うと効果的です。QAWは、そのソフトウェアに対して、将来にわたり、どのような品質特性（性能や使い勝手など）を求められるかについて、関連部門（マーケティング、営業、評価、運用部門など）のキーマンを集め、ワークショップを開いて、関係者で予測・合意するものです。

3-01 困りごとが解決されないヘルプデスク P.83

QAW…はじめて聞きました、勉強不足・・・。ネットで調べましたが、日本語の解説が特に見つからなかったので、出処と思われるSoftware Engineering Institute（SEI）の資料を見つけました。ご参考までに。

• The SEI Quality Attribute Workshop
  • 概要資料
• Quality Attribute Workshops (QAWs), Third Edition
  • こちらは詳細資料

ワークショップで作る成果物（目的）は、アジャイルサムライで言うインセプションデッキに近いものですね。インセプションデッキの内容を一部掘り下げ、より品質特性にフォーカスした議論を追加すると行った形式もありかもしれません。

会議では「三現主義：現場、現物、現実の重視」を必須ルールとします。

4-06 問題解決のための会議に当事者が参加していない P.131

この三現主義という言葉が気に入ったのでピックアップ。NRIの用語解説の説明が詳しかったです。→NRI用語解説　経営戦略・事業戦略　三現主義
3 Reality Principle。

受託開発下において、「現」をないがしろにしてしまう雰囲気をよく感じます。ここでいう「現」というのは、例えば、「ソースコード」、「開発の現場」、「エンドユーザーの現場や気持ち」、「（サーバなどの）本番環境」、など。こういった「現」に対して勘がちゃんときくように、

• ソースコード/本番環境
  • プログラミングする能力を始め、ソフトウェア開発の基礎スキル
• 開発の現場
  • チーム運営や、評価、プロジェクト管理スキル
• エンドユーザーの現場や気持ち
  • ヒアリング能力や、チェンジマネジメントに関する知識、懐に入るひととなり

といったことは日々研鑽しなくてはいけないな〜と思います。身にしみる。

治療法

「その解決策を１年前に知っていたら、今回のトラブルは発生しませんでしたか？」

4-07 再発防止につながらにトラブル解析 P.133

このキラークエスション、良いですね。当時知っていたら、もしくは、当時実行していたら、そのトラブルは発生しなかったかを、振り返りの際、深堀の観点として入れるとより良い議論ができそうです。なぜいま（振り返りの際には）気づけたのに、それを当時（問題が発生した時点）は気づけなかったのか、もしくは、実現できなかったのか。などなど。

次回（#10）

スケジュールはGoogleカレンダーで分かるようにしています。本日以降は次の要領です。記念すべき#10の書籍はまだ決まっていません。候補はこのあたりでしょうか。

• #10の候補書籍（検討中）
  • Design It!
  • INSPIRED 2nd Edition
  • フィンテックエンジニア養成読本
  • チーム・ジャーニー（ただし、2020年2月17日発刊）
• デッドライン
  • #09の感想交換1Week（1/27〜2/2）
  • インターバル（2/3-9）
  • #10の読書する時間2Week（2/10～2/22）
  • #10のブログポスト期限（2/23）