IT 業界の病理学

仕様が決まらない、テスト仕様書が更新されずに腐っていく、進捗がいつまでも 90 % のまま動かない。システム開発の現場で繰り返し語られるこうした問題を「病気」に見立て、症状と原因、治療法と予防法を整理したのが『IT 業界の病理学』 (司馬 紅太郎、秋山 浩一、森 龍二、鈴木 昭吾、都築 将夫、堀 明広、佐々木 誠、鈴木 準一 著、技術評論社、2019 年 11 月刊) です。版元は、IT 業界で働く人、IT 業界への就職を考えている人、システムの発注者やユーザーに向けた本と案内しています。

開発から業界構造まで、5 章 34 の病気の構成

本書は、1 章「開発の病気」、2 章「レビュー・テストの病気」、3 章「保守・運用の病気」、4 章「マネジメントの病気」、5 章「業界の病気」の 5 章に、合わせて 34 の病気を収めています。1 章には「現行どおり」の要件定義、スパゲッティ・ドキュメント、なんちゃってアジャイル症候群、絶対にさわれないソースコードなど、2 章にはメールレビューという名のアリバイ作り、腐敗したテスト仕様書、テストケース肥大病など、3 章には「運用でカバー」依存症、なんちゃって DevOps 症候群、高齢化するばかりの運用現場などが並びます。4 章はプロジェクト管理無計画病、リリース可否判定会議直後の重大バグ報告、再発防止につながらないトラブル解析、永遠の進捗 90 %、失敗だらけの PoC など 10 項目と最も項目が多く、5 章では「勉強会は業務ですか?」、受注のジレンマ、超多段階下請け開発、プログラマから SE、プロマネへと進むキャリアパスの問題などを扱います。項目ごとに執筆者が分かれた 8 名の共著で、どの章から読み始めてもよい作りになっています。

症状と原因、治療法、予防法、異説で読む形式

各病気は、症状と影響、原因 / 背景、治療法、予防法、異説、補足という同じ形式でまとめられています。現場の「あるある」を並べるだけの本と違うのは、なぜその病気にかかるのかという背景と、かかった後の治療、かからないための予防を分けて書いている点です。たとえば アジャイル開発 は、短い反復で動くものを届け、振り返りで進め方を直していく考え方ですが、計画やドキュメントを省く口実として表面のプラクティスだけをなぞると、行き当たりばったりのプロジェクトになります。開発と運用の協働を目指す DevOps も、道具を導入しただけで組織の分断が残れば同じことが起きます。版元の紹介によれば、異説の欄は、病気でないのに病気と診断したり、その逆を見落としたりするケースを扱い、筆者らの一方的な決めつけにならないように置かれたものです。

立場の違う読者それぞれの読みどころ

開発や運用の現場にいる人にとっては、自分のチームで起きていることに名前が付くこと自体が助けになります。問題を「病名」で共有できれば、個人の不満ではなく組織の課題として話し合いやすくなるからです。就職を考えている学生には 5 章の下請け構造やキャリアパスの項目が、業界の仕組みを知る手がかりになり、発注者やユーザーの立場の人には、1 章の仕様と要件定義の項目が、発注側の振る舞いがプロジェクトにどう跳ね返るかを知る材料になります。一方で、特定の開発手法やツールの使い方を体系的に学びたい人には向きません。本書は問題の見立てと対処の方向を示す本で、手法の手順書ではないからです。チームの運営そのものを掘り下げたい場合は チーム開発とマネジメントの本の選び方 から次の一冊を探すのが近道です。2019 年 11 月刊の本なので、扱う事例はその時点の現場を前提にしています。

現場の困りごとを笑い話で終わらせず、原因と対策を言葉にして周りと共有したい人にとって、本書は議論の土台になる語彙を与えてくれる一冊です。気になる病名の項目から開いて、自分の現場に当てはまるかどうかを確かめてみてください。