日本のIT現場、特にレガシーなSIerや、製造業的な文化が色濃い企業のソフトウェア開発プロジェクトを観察していると、ある共通の「病理」が見えてきます。
それは、特定の個人のスキル不足ではなく、組織の文化や前提（パラダイム）そのものが引き起こす、構造的な「病気」です。
これらの疾病は、プロジェクトの生産性を著しく低下させ、エンジニアのモチベーションを削ぎ、最終的にはバグとコスト増、そして「納期遅延」という合併症を引き起こします。
今回は、外資系IT企業で最先端の現場を仕切るシニアプロジェクトマネージャー（PM）の視点から、IT現場を蝕む**「IT業界の三大疾病」**を診断し、その合理的な処方箋（解決策）を提示します。
サマリ：IT業界を蝕む「三大疾病」の正体
まず、今回診断する三大疾病の全体像（病状と根本原因）を共有します。
| 疾病名 | 表面化している症状（ペイン） | 根本原因（病巣） | PMの処方箋（解決策） |
| ① ファイル管理不全症 | 1つの事実が複数のファイルに散在。多重管理による矛盾とバージョン地獄。 | 情報アーキテクチャの欠如。DRY原則の無知。 | **Single Source of Truth（唯一の正実）**の確立。Wiki・Markdownへの集約。 |
| ② Excel方眼紙病 | データをデータとして扱わず、見た目のためだけにセルを結合。機械可読性を破壊する悪習。 | Excelの「方眼紙（作図ツール）」化。データ構造とレイアウトの混同。 | データとレイアウトの分離。Markdown/Wikiでのドキュメント化。データは構造化形式（JSON/CSV）で。 |
| ③ 詳細設計病（処理レベル設計） | ソースコードをそのまま日本語に翻訳したような、無価値で分厚い詳細設計書を大量生産。 | 「設計」と「製造（コーディング）」の誤解。製造業モデルのソフトウェア開発への誤用。 | 設計書のダウンサイジング。設計は外部仕様（IF・データ構造）と概念のみ。コードこそが「最終図面」である。 |
それでは、それぞれの疾病について詳しく診断していきましょう。
第1の疾病：ファイル管理不全症（DRY原則の崩壊）
エンジニアの基本中の基本である「One fact in one place（1つの事実は1箇所に：DRY原則）」が完全に崩壊し、同じ仕様やデータが複数のファイルに散在している状態です。
弊害と具体例
- 症状：あるAPIの仕様を変更しようとした時、Wordの仕様書、Excelの項目定義書、PPTの全体概要図、そしてWikiの3箇所を同時に修正しなければならない。
- 弊害（合併症）：
- 情報の不整合：どれか1つの修正を忘れると、仕様に矛盾が生じ、開発者がどれを信じれば良いか分からなくなる。
- 無駄なオーバーヘッド：1つの変更のために、複数のドキュメントを「整合させる」という、本質的でない作業に膨大な時間が奪われる。
- 「最新版」迷子：ファイル名に「_v3_修正版_最終_確定」のような無意味な接尾辞が増殖し、どれが本当の最新版か誰にも分からなくなる。
発生する原因
情報アーキテクチャ（情報の整理・構造化）の欠如です。「とりあえずファイルを作る」という安易な行動が、情報の多重管理を生みます。また、文書管理システム（バージョン管理システム）の正しい運用知識がないことも拍車をかけます。
PMの合理的処方箋
1. Single Source of Truth（SSOT：唯一の真実）の確立
情報は必ず「1箇所」に集約します。WordやExcelのローカルファイルを廃止し、ConfluenceなどのWikiツールや、Gitで管理されたMarkdownファイルにドキュメントを集約します。
2. DRY原則（Don’t Repeat Yourself）の徹底
仕様書の記述において、同じ内容を複数の場所に記述することを「バグ」とみなします。他のファイルを参照（リンク）させるか、インクルード（埋め込み）機能を活用して、1箇所を直せばすべてに反映される構造を作ります。
第2の疾病：Excel方眼紙病（構造化拒絶症）
本来、表計算（データ処理）ツールであるExcelを、見た目のレイアウト（作図）のためだけに使い、セルのサイズを極小にして「方眼紙」のように扱う悪習です。
弊害と具体例
- 症状：画面設計書やテスト仕様書で、1文字を入れるためにセルを結合したり、テキストが複数のセルにまたがって記述されていたりする。見た目は綺麗だが、中身はデータの墓場。
- 弊害（合併症）：
- 機械可読性の完全破壊：並べ替え、フィルタ、検索が機能しない。データをプログラムで読み取って自動化することが不可能になる。
- メンテナンスコストの青天井：1行、1列を追加するだけで、結合セルのレイアウトが崩れ、数時間の再レイアウト作業が発生する。
- バージョンの比較不能（diff不可）：Excelのバイナリファイルは、Gitなどで「どこがどう変わったか」の差分を正確に比較できず、レビューがブラックボックス化する。
発生する原因
Excelを「紙の書類の延長」として捉えている、日本のレガシーな事務文化です。データ構造よりも「印刷した時の見た目」を最優先する思考停止が、この疾病を生みます。
PMの合理的処方箋
1. データとレイアウトの分離（Separation of Concerns）
ドキュメントはMarkdownやWikiなどの「テキスト形式」で作成し、見た目（レイアウト）はツールに任せます。テスト項目やデータそのものは、CSV、JSON、またはセルの結合を禁止した構造化されたスプレッドシート（データベース）として管理します。
2. Excelの用途限定とセル結合の全面禁止
Excelを作図ツールとして使うことを禁止します。どうしてもExcelを使う場合は、セルの結合を禁止し、1行1レコードのデータベース形式（テーブル）を徹底させます。
第3の疾病：詳細設計病（プログラム処理レベルの設計という無駄）
「詳細設計書」と称して、これから書くソースコード（プログラム）のロジックを、日本語（自然言語）でそのまま翻訳したような無価値なドキュメントを大量生産する状態です。
弊害と具体例
- 症状：「もしXがYより大きければ、A処理をする。そうでなければB処理をする」という、コードそのものの「1対1の日本語訳」が詳細設計書にびっしり書かれている。
- 弊害（合併症）：
- 膨大な記述コスト：日本語で複雑なロジックを厳密に書くのは、コードを書くよりも時間がかかり、矛盾が生じやすい。
- レビューの形骸化：レビューアは「日本語が正しいか」をチェックするだけになり、本質的なロジックの妥当性レビューがおろそかになる。
- ドキュメントの即時陳腐化：コーディング中に発覚した不具合を修正した瞬間、詳細設計書とコードに乖離が生じる。そして、誰も詳細設計書をメンテナンスしなくなる（＝存在価値がゼロになる）。
発生する原因
「設計」と「製造（コーディング）」の役割分担の誤解です。「設計書を作ってから、工場（プログラマー）で作る」という、製造業モデルのソフトウェア開発への誤用。このパラダイムでは、プログラマーを「設計書の通りに手を動かすだけの作業者」とみなし、プログラマーの創造性や思考を奪います。
PMの合理的処方箋
1. 「コードこそが最終図面である」という認識の転換
ソフトウェア開発において、プログラミング（コーディング）こそが製造業におけるCAD（図面作成）である、と再定義します。詳細設計書の日本語訳は不要です。
2. 設計書のダウンサイジングと役割の限定
設計書は**外部仕様（APIインターフェース、データ構造、UI要件）と、概念的なロジック（フローチャート、状態遷移図、UML等の概念）**のみに留めます。具体的な実装詳細はコード（およびコード内のコメント、自己文書化されたコード）に任せます。これにより、設計書の価値を高めつつ、記述・メンテナンスコストを激減させます。
結論：PMが現場に「経済合理性」を連れ戻す
IT業界の三大疾病は、組織が「考える」ことをやめ、過去の慣習（レガシー）に囚われ続けることで蔓延します。
シニアプロジェクトマネージャーの使命は、これらの疾病を早期に診断し、感情論や慣習ではなく、「期待値コントロール」と「経済合理性」に基づく処方箋を現場に適用することです。
無駄なドキュメント管理や、機械が読めないデータの修正にエンジニアのCPU（脳）を浪費させてはなりません。浮いたコストと時間は、よりアグレッシブな機能開発や、AIなどの最先端テクノロジーの検証、そして「ブログ執筆による知見の発信」といった、未来の資産を生み出す活動へ投資すべきです。
あなたの現場は、これらの疾病に侵されていませんか？ 勇気を持って「解約」という決裁を下すべきサブスクリプションが、まだ現場に眠っているはずです。
コメント