目次

第1章　なぜ日本のIT投資は利益を生まないのか

1.1　2025年の崖と社内DX～ベンダー丸投げの限界～

• 1.1.1　12兆円の損失警告～「2025 年の崖」の真の意味
• 1.1.2　投資は増えているのになぜ生産性は上がらないのか
• 1.1.3　わからないものを作ることはできない
• 1.1.4　仕様を知らない発注者が招く悲劇

1.2　日本のIT人材不足の正体とその解決の道

• 1.2.1　IT人材不足の正体～本当に足りないのは誰か～
• 1.2.2　家内制手工業からソフトウェア工場へ

第2章　第3の選択肢としての「スペックパターン開発プロセス」

2.1　ウォーターフォール vs. アジャイルという不毛な対比

• 2.1.1　ウォーターフォールモデルの定義
• 2.1.2　アジャイルは日本の契約と相性が悪い？
• 2.1.3　日本企業に必要な第3の道「スペックパターン開発プロセス」

2.2　スペックパターン開発プロセスが解決するもの

• 2.2.1　紙の延長線で合意することの問題点
• 2.2.2　データベースで合意する
• 2.2.3　変化に対する考え方の違い
• 2.2.4　ソフトウェア開発現場の生産性を高める
• 2.2.5　属人性を最大活用する

2.3　スペックパターン開発プロセスの重要なポイント

• 2.3.1　工場化の5ステップ
• 2.3.2　逆転の発想：テストを最初に終わらせる
• 2.3.3　業務分析・要件定義・モデルスペックパターンの作成
• 2.3.4　インプリメントリーダーというキーパーソン

2.4　AI・DX時代におけるスペックパターンの価値

• 2.4.1　AI・DX時代におけるスペックパターンの価値
• 2.4.2　実装工程を工場のように自動化・高速化

第3章　【鉄則1】正しく計画せよ～誤解されたWBSと、失われた計画作成～

3.1　「計画」という名の「要望記述書」

• 3.1.1　ガントチャートは計画ではない
• 3.1.2　プロジェクトマネジメントに対する決定的な誤解
• 3.1.3　作業を分解するな、成果物を分解せよ

3.2　PMBOKが教える本来のWBSとは

• 3.2.1　WBSという名前から生まれる誤解
• 3.2.2　本来のWBSとは

3.3　WBS辞書がない計画は計画とは言えない「願望表」

• 3.3.1　言葉の定義がズレればプロジェクトは炎上する
• 3.3.2　WBS辞書は成果物の定義書である
• 3.3.3　WBS辞書こそが計画の中心である

3.4　アクティビティリストとプロジェクトネットワーク図～ストーリーからシナリオへ～

• 3.4.1　プロジェクトのシナリオとは
• 3.4.2　アクティビティリスト
• 3.4.3　プロジェクトネットワーク図

3.5　プロジェクトネットワーク図を作成する

• 3.5.1　WBSの作成
• 3.5.2　WBS辞書の作成
• 3.5.3　アクティビティリストの洗い出し
• 3.5.4　プロジェクトネットワーク図の作成

3.6　アーンドバリューマネジメントでプロジェクトを数値化する

• 3.6.1　「頑張っています」という報告はいらない
• 3.6.2　EVMが教えてくれる未来の景色

3.7　計画から工場への接続

• 3.7.1　ソフトウェア工場の製造ライン設計図はWBS辞書の中にある

3.8　まとめ：計画作成が変わればプロジェクトが変わる

第4章　【鉄則2】議事録は発言録ではない！ 決定事項を記録せよ～会議法＆議事録術～

4.1　会議と議事録はプロジェクトの土台であり両輪

• 4.1.1　会議はなぜ生産性を下げるのか
• 4.1.2　議事録がない仕事は仕事ではない
• 4.1.3　多くの現場が陥る「日記のような議事録」
• 4.1.4　記載された内容についての合意が必要

4.2　4ビートミーティングの実践テクニック

• 4.2.1　会議の進め方・議事録の取り方
• 4.2.2　4ビートミーティングの進め方
• 4.2.3　笑顔の会議
• 4.2.4　事前のシナリオとリハーサル

4.3　AI時代の4ビートミーティング

• 4.3.1　音声認識とAI要約活用
• 4.3.2　議事録とスペックパターンとの照合

4.4　会議コストとリスク管理

• 4.4.1　会議は時間単価の高い資源の投入である
• 4.4.2　4ビートミーティングは最大のリスクヘッジ

4.5　まとめ：笑顔の会議を4ビートミーティングで実現する

第5章　【鉄則3】仕様書は書かずに「出力」せよ～開発プロセスの心臓部 「仕様のデータベース化」～

5.1　最初に明確に伝えたいこと

• 5.1.1　ドキュメンテーションの難しさ
• 5.1.2　スペックパターン開発プロセスの価値

5.2　なぜ仕様書は陳腐化するのか

• 5.2.1　既存システムのドキュメントは見ないほうが良い？
• 5.2.2　ドキュメントが使えなくなる理由とは
• 5.2.3　WordとExcelの限界
• 5.2.4　必要なのは構造と仕組み

5.3　画面項目レベルのスペックパターンレコード（画面項目定義）

• 5.3.1　「画面項目1項目＝1レコード」の原則
• 5.3.2　圧倒的な変更耐性

5.4　スペックパターンデータベースが生み出す量産効果

• 5.4.1　標準化とコピペの推奨
• 5.4.2　ドキュメントの自動生成
• 5.4.3　スペックパターン記述のポイント

5.5　レガシーシステムの刷新とAI時代のスペックパターン開発プロセス

• 5.5.1　ブラックボックスを開ける鍵
• 5.5.2　AI時代のスペックパターン開発プロセス

5.6　まとめ：業務システムの開発をまるごと近代化せよ

第6章　【鉄則4】上流工程で成功を確定せよ～ソフトウェア製造ライン設計術～

6.1　モックアップによる超早期での合意

• 6.1.1　初対面から数日で実際に動く模型を見せる
• 6.1.2　モックアップは未来の契約書
• 6.1.3　パッケージ製品選択の弊害を解消

6.2　顧客業務の徹底理解と「産能大式」の威力

• 6.2.1　システムの前に業務を作る
• 6.2.2　産能大式業務フロー図で流れを可視化する
• 6.2.3　「180度逆の法則」で本質を見抜き、良いアイデアを得る

6.3　なぜ、設計書を渡してもまともなシステムはできないのか

• 6.3.1　壁の向こうへ投げるな
• 6.3.2　SEとプログラマーの対立を解消する
• 6.3.3　可能な限りPMSEとILの2名体制にする

6.4　インプリメントリーダーという最強のパートナー

• 6.4.1　上流工程と実装工程の断絶を埋める
• 6.4.2　ILは顧客との会議に参加してはいけない
• 6.4.3　ペアデザイニングとは
• 6.4.4　ILとの情報交換が重要な理由

6.5　モデルソースによる品質の固定

• 6.5.1　最初の一つを完璧に作る
• 6.5.2　誰でも名工になれる仕組み

6.6　まとめ：ソフトウェア工場の製造ライン建設

第7章　【鉄則5】テストは最初に、徹底的に実施せよ～実装と品質保証の自動化・工場化～

7.1　コンバースリリース～最も難しい山を最初に登る～

• 7.1.1　常識の逆をいくスケジュール戦略とスペックパターンの作成
• 7.1.2　最強に意地悪なユーザーテストを最初に実施する

7.2　仕様変更ゼロを実現する

• 7.2.1　仕様変更はなぜ起きるのか
• 7.2.2　確定した仕様だけを工場に流す

7.3　まとめ：製造ライン建設を完了し「製造」から「組み立て」へ

第8章　【鉄則6】仕様と計画を完全支配せよ～内製化とベンダー共創の新しい形～

8.1　日本企業の現実と内製化ブームの落とし穴

• 8.1.1　エンジニア採用＝内製化という誤解
• 8.1.2　丸投げの真の問題点とは
• 8.1.3　目指すべきは「設計と製造の分離」と「高度な分業」

8.2　丸投げでも抱え込みでもない第3の道

• 8.2.1　ユーザー企業が握るべき「コア」は何か
• 8.2.2　新しい業務システム開発の仕組み
• 8.2.3　ベンダーを敵にするな～Win-Winの関係構築～
• 8.2.4　見積もりの精度を劇的に上げる方法
• 8.2.5　成果物ベース契約への転換

8.3　新時代の「仕様サプライチェーン」構築

• 8.3.1　スペックパターンデータベースを共通言語にする
• 8.3.2　マルチベンダー開発の司令塔になる
• 8.3.3　丸投げから「部品発注」へ
• 8.3.4　契約条項への反映：曖昧さを排除する
• 8.3.5　上位マネジメントや経営層が決断すべきこと

8.4　まとめ：さあ、自社の「ソフトウェア工場」を建てよう

第9章　【鉄則7】工場は小さく始めて大きく育てよ～開発プロセスの導入と体制構築～

9.1　見えないコストに気づきROIを高める

• 9.1.1　IT投資の歩留まりとは
• 9.1.2　スペックパターン開発プロセスの劇的なROI
• 9.1.3　スペックパターン開発プロセスが実現したこと

9.2　スモールスタートの鉄則～いきなり全社展開をしない～

• 9.2.1　変革に対する現場の拒絶反応
• 9.2.2　パイロットプロジェクトの選び方
• 9.2.3　工場長を育てる
• 9.2.4　キャリアパスの変革
• 9.2.5　現場を守る特区の創設
• 9.2.6　導入のロードマップ～3ステップ戦略～

9.3　組織体制と人材戦略～誰が工場を回すのか～

• 9.3.1　スーパーマンはいらない
• 9.3.2　適材適所を実現する任命基準とキャリアパス
• 9.3.3　PMとSEを一人に集約すること

9.4　まとめ：日本を「ソフトウェア工場の国」へ

第10章　業務システム開発におけるAIの活用

10.1　AI時代の業務システム自動生成

• 10.1.1　なぜ、AIにコードを書かせても失敗するのか
• 10.1.2　AIは魔法の杖か、それとも鏡か
• 10.1.3　AIは魔法使いではなく、優秀なライン工である
• 10.1.4　スペックパターン開発プロセスにおけるAI活用のポイント
• 10.1.5　レガシー刷新における逆モデリングとAI

10.2　まとめ：AI時代にこそ仕様が価値を持つ

Appendix　スペックパターン開発プロセス標準実施手順書

• A.0　前提
• A.1　【フェーズ1】プロジェクト立ち上げとイメージの固定
• A.2　【フェーズ2】業務分析と「製造ライン」構築～要件定義の段階でテストを終わらせる～
• A.3　【フェーズ3】量産（設計・実装・テスト）～書くのではなく出力し、作るのではなく組み立てる～
• A.4　【フェーズ4】仕上げと運用への接続～「言った、言わない」を残さない～