炎上知らずのDXプロジェクトマネジメント～業務システム開発 七つの鉄則 [単行本]

炎上知らずのDXプロジェクトマネジメント～業務システム開発 七つの鉄則 の 商品概要

• 目次

  ■第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】仕上げと運用への接続～「言った、言わない」を残さない～

• 内容紹介

  曖昧な要件定義、度重なる仕様変更、それに伴うプロジェクトの遅延や炎上、現場の疲弊や顧客の不満など……。DXによる業務のIT化・効率化が進められる中、開発プロジェクトがなかなか上手くいかないという悩みを抱えている方は多いかもしれません。プロジェクトの舵取りを担う部門の担当者やリーダー、マネジメント層が、解決の糸口が見えない現状に危機感を抱くことも少なくないはずです。
  
  本書では、著者が長年のシステム開発・プロジェクトマネジメントに従事した経験に基づき体系化した手法である「スペックパターン開発プロセス」を軸に、DX・業務システム開発プロジェクトを成功に導くためのノウハウを解説します。
  
  科学的な手法による正しい計画作成から始まり、顧客の要求をしっかりと掴む会議運営と議事録作り、データベース化による仕様管理、上流工程での徹底的なユーザーテスト実施、生成AI時代も見据えた画面量産体制の構築などを、7つの鉄則として整理しました。スペックパターン開発プロセスの本質を理解することで、顧客・開発サイドの双方が満足できるWin-Winの業務システム開発プロジェクト実現に繋げられるでしょう。

• 著者について

  深沢 隆司 (フカサワ タカシ)
  株式会社イマジンスパーク代表取締役。陸上自衛隊少年工科学校第25期生。防空指揮装置の修理要員として自衛隊に勤務。退職後、プログラマー、仕様策定者、プロジェクトマネージャーとしてソフトウェア開発に従事。小規模システムから上場企業、官公庁の大規模基幹システムまで、幅広いプロジェクトに携わる。本書で紹介する手法を実践し、数多くのプロジェクトを成功に導いてきた。現在は、中小IT企業・DX内製化企業を中心に、プロジェクトマネジメントおよび業務システム開発の実務支援、コンサルティング、研修を提供。日本のデジタル競争力向上に貢献している。著書に『SEの教科書【完全版】』『デスマーチよ！さようなら！』『いちばんやさしいPMBOKの本』（いずれも技術評論社）、『ベースラインで成功するプロジェクトマネジメント』（日本実業出版社）など多数。

炎上知らずのDXプロジェクトマネジメント～業務システム開発 七つの鉄則 の商品スペック