技術書「IT業界の病理学」はこうして書かれた

まえがき

「IT業界の病理学」という書籍が、技術評論社から2019年11月に発売されました。
私（堀）は、この本の企画立案者の一人として、執筆を担当いたしました。

Amazonで見る

IT業界の病理学 | Amazon

本コラムは、通常のソフトウェアテストに関わるものとは別に、番外編として、「IT業界の病理学」を執筆したきっかけや執筆初期のエピソードをお届けします。
キーワードは「正攻法だけではうまく行かない」です。

「IT業界の病理学」とは

「IT業界の病理学」（以降「IT病理学」と略記）では、IT業界ではびこる問題や課題を病気として捉え、その症状・原因・治療法・予防法等を整理してまとめたものです。
扱っている病気は全部で34個あります。

1章 開発の病気
1-1　仕様を決められないユーザー
1-2　「現行どおり」の要件定義
1-3　要求に対する問題がリリースの直前になって見つかる
1-4　スパゲッティ・ドキュメント
1-5　T.B.D依存症
1-6　なんちゃってアジャイル症候群
1-7　絶対にさわれないソースコード
1-8　だれも見ない開発標準

2章 レビュー・テストの病気
2-1　全部そろってからレビュー
2-2　メールレビューという名のアリバイ作り
2-3　腐敗したテスト仕様書
2-4　絶対に見ないエビデンス
2-5　重荷にしかならない不具合管理
2-6　テストケース肥大病

3章 保守・運用の病気
3-1　困りごとが解決されないヘルプデスク
3-2　マニュアルどおりにしか動けない運用者
3-3　「運用でカバー」依存症
3-4　なんちゃってDevOps症候群
3-5　高齢化するばかりの運用現場

4章 マネジメントの病気
4-1　プロジェクト管理無計画病
4-2　有識者をつれてきたから安心病
4-3　リリース可否判定会議直後の重大バグ報告
4-4　杓子定規な監査
4-5　プログラマのモチベーションが一番大事病
4-6　問題解決のための会議に当事者が参加していない
4-7　再発防止につながらないトラブル解析
4-8　永遠の進捗90％
4-9　失敗だらけのPoC
4-10　部署名錯乱病

5章 業界の病気
5-1　勉強会は業務ですか？
5-2　受注のジレンマ
5-3　超多段階下請け開発
5-4　プログラマ→SE→プロマネのキャリアパス病
5-5　学生のキャリアアンマッチ病

いわゆるIT業界全体を通してよく見聞きする「アンチパターン」を扱ったものです。
なぜアンチパターンを扱ったのか、その理由は、本記事の最後の部分で言及いたします。

まずは、IT病理学を書こうと思ったきっかけや、執筆当初のエピソードをご紹介していきます。

きっかけはケイパーズ・ジョーンズの「ソフトウェア病理学」

「「IT業界の病理学」を書きたい」と思ったのは、かれこれ10年以上も前だったと思います。そのきっかけは、ケイパーズ・ジョーンズのかの名著「ソフトウェア病理学」を読んだことでした。「IT業界の病理学」は、ケイパーズ・ジョーンズのそれを参考にしたものです。
「ソフトウェア病理学」は邦訳版の書籍名であり、原著のタイトルは「Assessment and Control of Software Risks」と言います。これが一風変わった本で、ソフトウェア開発に関係するさまざまな問題や課題を、病気に見立てて解説しています。
（ケイパーズ・ジョーンズの「ソフトウェア病理学」で扱っている病気と項目立ては、本記事の末尾に付録して記載しておきます）

こんなふうに病理学風に解説されたソフトウェア開発の技術書なんて、見たことがありませんから、強く興味が引かれました。内容もちょっと皮肉が効いていてとても面白いものでした。しかし残念なことに、ずいぶん前から絶版でいました。中古本は定価をはるかに超える数万円ものプレミア価格で取り引きされていて、復刊を望む声も多かったのですが、復刊が実現する見込みはどうも薄いように思えました。

こんなにも良書なのに、なんて、もったいない...。
復刊される望みが薄いのであれば、いっそ自分で新しい病理学を書いてしまおうかと、いつからか思うようになりました。
そんなバックボーンがある中、日本科学技術連盟（通称：日科技連）のソフトウェア品質向上の活動組織「SQiP（Software Quality Profession）」で、会社組織の垣根を越えた有志が研究活動を行う仕組みができました。これを契機に、かねてから暖めていた"病理学 執筆プロジェクト"を立ち上げたのでした。

執筆仲間を集めた

執筆するにあたって、IT病理学は一人で書くのではなく、複数人による共同執筆にしようと考えました。複数人で書いた方が、より幅広くモノを見て執筆できると考えたためです。

執筆プロジェクトをキックオフする際、執筆者を集めるのに、ソフトウェア品質に関わる方たちが集うメーリングリストで呼びかけたり、これはと思う方に直接連絡したりしてお誘いしました。

執筆プロジェクトの名称は「ソフトウェア病理学NEO」としました。某テレビ局の人気番組「サ○リーマンNEO」からもじったものです。なお、「IT業界の病理学」という正式な書籍名は、執筆プロジェクトのずっと後になってから、技術評論社の敏腕編集者が名付けてくれたものです。

執筆に賛同してくれる方は順調に集まり、希望を胸に執筆プロジェクト「ソフトウェア病理学NEO」は船出するわけですが、執筆活動をキックオフしてから本格的に執筆を開始するまで、相応の労力と準備期間が必要でした。

試行錯誤して病気をリストアップ

「IT業界の病理学」は、言わば短編集のようなもので、「こんなことってあるあると共感される」「読んでいてついついニヤリと笑ってしまう」ことを基本コンセプトとしていました。したがって、変な言い方ですが、読んで面白いと思えるような、魅力的な病気がリストアップできるかどうかがポイントになると考えていました。

「読んで面白いと思えるような（魅力的な）病気」をゼロから適切にリストアップするのは因難でしたので、まずは「病気」と言えそうなものを、執筆者一人あたり10個以上の案を出し、それらをまとめて俯瞰してみることにしました。

その結果、全部で200個ほどの"病気の候補"があがってきました。その数の多さに少し目眩がする思いでしたが、あがってきた"病気の候補"たちを一つの巨大なマインドマップに放り込み、一つ一つ根気よく、KJ法でグルーピングしてまとめていきました。この検討をしている時は、病気のタイトルしかリストアップしていなかったので、タイトルだけではどんな内容なのかさっぱり分からないものもあり、その場合は一つずつ発案者に確認する必要もありました。

とにもかくにも"病気の候補"たちを俯瞰できるようにまとめあげたら、次は、実際に執筆する病気の選定を行いました。200個もの"病気の候補"を一つ一つ吟味し、単なるしくじりで病気と言えないものや、あまりに特殊すぎて一般的とは言えないなものをふるい落としていって、少しずつ、"IT業界の病理学"の輪郭を描き出していきました。この作業は大変でもあり、また楽しくもあったのですが、かなりの時間を要しました。

書いてみて、考えて、書き直してみて

病気のリストアップと並行して、テーマは何でもいいから、項目立ても自由に、執筆者一人ずつ一本だけでも、原稿を通して書いてみるようにしました。執筆の条件や取り決めはあえて何も設けず、とにかく一本だけを通して最後まで執筆してみることを目標としました。つまり、原稿の試作をしたわけです。

試作の目的は、練習という意味もありましたが、原稿を執筆して行くにあたって、「項目立てをどうするか」「文体は "ですます調" か "である調" か」など、決めるべきものがいろいろとあり、それらの答えを模索していくためには、とにかく一回書いてみることが必要でした。
特に、項目立てはIT病理学の骨格となるものですから、何回も議論を重ねました。

今回の執筆活動は、最初から商用出版を目標にしていました。手製の冊子を作るとか、ブログなどで公開するとかは考えていませんでした。
IT病理学のようなものは、どうしても、いろいろな鬱憤を吐き出すような、自己満足的で自己本意的で決めつけ的な内容になってしまいがちだと思っていました。そうなると、質の低下に繋がってしまいます。どうせやるなら一定の質のものを書きたかったので、本当にできるかどうかは分かりませんでしたが、商用出版を目標に置くことで質を向上させることを目指しました。

本の質を向上させるためには、執筆の内容が重要であることは当然として、文章もちゃんとしたものであることも必要でした。執筆陣には過去に商用書籍の執筆経験を持つ方も数名いらっしゃったので、文章作法を講義してもらったりもしました。

さまざまな議論を経た後、執筆者間で統一すべきルールが定まってきました。一度執筆した試作原稿は練習用と割り切って一旦捨てて、再度書き直すようにしました。そうこうしているところで、執筆すべき病気はだいたいリストアップできてきたので、各執筆者の得意分野や希望を踏まえて執筆担当を決め、本格執筆に入りました。

なんやかんやで、執筆プロジェクトを発足させてから本格的な執筆を開始するまで、一年あまりの時間を要しました。

遅れに遅れた執筆活動

本格的に執筆を開始した後も、かなりの期間を要しました。
執筆者全員、本業を持っていたので、本業の状況によっては、執筆活動はどうしても後回しにせざるを得ませんでした。進捗が言語道断的に遅れる中、どうにか出版までこぎつけられたのは、ひとえに出版社の敏腕編集者の忍耐とご指導のおかげでした。

これら準備から執筆にかけての一連の作業は、当然と言えば当然ですが、業務外の自分のプライベートの時間でやりました。執筆陣はみんな違う会社に勤務していたので、議論や連絡は、普段はメーリングリストでやりました。対面での議論も必要で、業務終了した後の夜に、執筆者の会社で会議室を使わせてくれるところに集まって、だいたい月に一回くらいの頻度でミーティングを実施しました。
こんな調子で本業と並行して執筆しましたが、自分で好きでやっていることなので、辛いとか大変とかは、ほとんど感じませんでした。

なぜ、アンチパターンを取り上げたのか

以下は、IT病理学「まえがき」の一部を引用したものです。

• アジャイル開発を導入するも，表面的なプラクティスをなぞるだけ。実施すべき作業を『面倒だから』と単純に省略して骨抜きにし，プロジェクトを行き当たりばったりで進め，火を吹いてしまう
• コストと納期が非常に厳しい状況下では計画を立てるのは無意味であると，リスクをまるで無視して，目先のマイルストーンだけを目指してひたすら突進し，破たんしてしまう
• 何か新しい技法を取り入れようとしても，『理想と現実は違う』『作業が増えてしまう』『すぐに効果が見込めない』と突っぱねられてしまう
• 流行っているものに闇雲に飛びつきマネするも，うまくいかなければ『ウチには合わない』と早々に捨て去ってしまう
• トラブルの原因を十分に分析しないまま，もっともらしい再発防止策はとられるものの，問題が再発する

いずれも、どこかで見たり聞いたりしたことがあるものではないでしょうか。
これらは技法や何かを取り入れさえすれば解決するような、単純な問題ではありません。
ソフトウェア開発に関する優れた知見やノウハウは世の中に広く共有されています。しかし、それらが世間に知られていない、伝搬されない、定着しないのは、それら知見の内容云々よりも先に、解決しなければならない、「思考停止」「責任転嫁」「独善」「妥当でない価値観」「悪い状況や習慣への慣れと麻痺」といったものがたくさんあるからではないでしょうか。単純に正攻法だけでモノコトを進めるだけでは足りず、現状を踏まえながら、現実解を積み上げていく必要があると思うのです。

こういったことにフォーカスを当てるため、「IT業界の病理学」を仲間たちと書きました。

アンチパターンを取り上げるにしても、暗く暗鬱にせず、思わずニヤリとしてしまうようなテイストにしました。
一度は笑い飛ばして、それから「ではどうするか？」と前向きになれるように、という願いがあったためです。

また、面白い本を企画し、書こうと思っています。

巻末付録

ケイパーズ・ジョーンズの「ソフトウェア病理学」 病気一覧と項目立てを以下に記します。
絶版になってから時間を経過しているためか、目次レベルの情報も得にくいので、ご参考までに。
なかなか手に入りにくい本ではありますが、探すと図書館で蔵書されているところもいくつかあります。
機会があったら、是非、一度 手に取ってみることをお勧めいたします。

＜ケイパーズ・ジョーンズの「ソフトウェア病理学」 病気一覧＞
（接頭の番号は章番号。なお、1〜3章はイントロダクション）

4.あいまいな改善目標
5.不自然な成熟度レベル
6.プロジェクトの中止
7.企業内の政治抗争
8.コストの超過
9.徐々に増大するユーザ要求
10.狭いオフィス環境
11.欠陥多発モジュール
12.過大な文書化作業
13.過酷なスケジュール
14.出荷時期の遅れ
15.生産性の誇大宣伝
16.顧客と受託開発企業の軋轢
17.ソフトウェア管理者と経営者の軋轢
18.高い保守コスト
19.不正確なコスト見積
20.不正確な尺度
21.不正確な品質見積
22.不正確な規模見積
23.不適切なアセスメント
24.不適切な報酬制度
25.不適切な構成管理
26.不適切な技術者教育
27.不適切な管理者教育
28.不適切な計測
29.不適切なパッケージ入手法
30.不適切な資料調査環境
31.不適切な規格
32.不適切なプロジェクトリスク分析
33.不適切な価値分析
34.不適切な管理ツールと手法
35.不適切な品質保証ツールと手法
36.不適切なソフトウェア工学ツールと手法
37.不適切な技術文書作成ツールと手法
38.再利用性の低いシステム構成
39.再利用性の低いプログラム
40.再利用性の低いデータ
41.再利用性の低い設計
42.再利用性の低い文書
43.再利用性の低い見積
44.再利用性の低いヒューマンインターフェース
45.再利用性の低いプロジェクト計画
46.再利用性の低い要求仕様
47.再利用性の低いテスト
48.専門分化の不足
49.老朽化システムの保守
50.低生産性
51.低品質
52.ソフトウェア従事者の低いステータス
53.低い顧客満足度
54.管理者の不当行為
55.技術者の不当行為
56.スケジュールの遅れ
57.不完全なソフトウェアライフサイクルの使用
58.弱体な組織
59.拙劣な技術投資
60.過酷なレイオフや解雇
61.性急な改善計画
62.銀の弾丸（特効薬）症候群
63.進まない技術移転

＜ケイパーズ・ジョーンズの「ソフトウェア病理学」 解説項目＞
1.症状
2.重病度
3.感染率
4.発病
5.感受性
6.病原
7.合併症
8.経済的影響
9.予防法
10.治療法
11.支援ツール
12.コンサルティング
13.教育
14.関連書籍
15.関連雑誌
16.規格
17.専門機関
18.治療効果
19.治療費
20.将来展望