著者：白川 克［しらかわ・まさる］(1972-) コンサルタント。
著者：濵本 佳史［はまもと・よしふみ］(?-) コンサルタント。
装丁：竹内 雄二［たけうち・ゆうじ］(1966-) ブックデザイナー。
本文イラスト：今村 友加里［いまむら・ゆかり］
illustration：iStock.com/studiostockart
NDLC：M154 科学技術 >> 科学技術一般 >> データ処理・計算機一般 >> 電子計算機システム
NDC：007.61 情報学．情報科学 >> データ処理．情報処理 >> システム分析．システム設計
NDC：336.57 経済 >> 経営管理 >> 事務管理 >> 事務の機械化．コンピュータ システム
件名：経営管理-データ処理
件名：システム設計
件名：プロジェクト管理
備考：力作だが、本書に索引は無い。それだけ項目一覧（≒目次）が読者の役に立つはず。
【目次】
はじめに [003-009]
「システムを作る技術」ではなく「作らせる技術」についての本
あなたに必要なのは「作らせる技術」
「作らせる技術」の欠如がビジネスを停滞させている
「作らせる技術」に出会った頃の話
目次 [010-017]
A章 作る前に知っておくべきこと 018
知っておくべきこと1：作らせるのは誰か？
知っておくべきこと2：システムより先に考えるべきことは？
知っておくべきこと3：なぜこんなに計画がブレるのか？
作らせるのは誰か？ 019
経営者
業務部門
プロジェクトリーダー（PL）
IT部門
システムを作らせるのは誰か？
［Column］IT部門は作る人？ 作らせる人？ 023
システムより先に考えるべきこととは？ 023
なぜこんなに計画がブレるのか？ 026
徐々に減っていく不確実性
いつ、何を、どの深さまで検討するべきか？
［Column］システムを 「作らせる」という言い方がエラそうな件 030
B章 プロジェクト全体の進め方 031
Concept Framing（ゴール明確化：C章） 031
Assessment（現状調査／分析：D章） 032
Business Model（構想策定：E章） 032
Scope（要求定義：F章～M章） 033
PEW（製品選定／ベンダー選定：N章～P章） 034
BPP（プロトタイプ検証：S章） 035
Design（設計 Deployment(開発：T章～W章） 036
Rollout（稼動：X章） 036
システム構築を着手するまでにしっかり時間をかける 037
［事例］全行程を愚直にはやらない特殊なプロジェクト 038
C章 ゴール (Why) を明らかにする 042
「システムを作ること=プロジェクトのゴール」なのか？ 042
［事例］現状維持をゴールとしたプロジェクトの末路 042
システム構築でのゴール4事例 044
良いプロジェクトゴールづくりの4つのコツ 051
［Column］「素晴らしい道具が手に入ればいい」症候群に陥ってないか 055
D章 現状の棚卸しをする 058
現状調査の2つの方針 058
［事例］新ビジネスだからと現状調査をしなかったプロジェクト 060
現状の業務とシステムを棚下ろす9大フォーマット 061
①現行業務フロー 062
②現行アクティビティ一覧 063
③現行ファンクショナリティ・マトリクス 064
④現行システム一覧 065
⑤現行インターフェース一覧 066
⑥現行全体システム構成図 067
⑦現行システムの主要データ 069
⑧現行コード体系 070
⑨課題一覧 071
棚卸し結果を元に、システムを分析する 072
システム現状調査に「作らせる人」が関与するか？ 073
［事例］お役所でのシステム開発と無謬性 074
E章 将来像 (How) を明らかにする 078
施策（プロジェクトで変えること）を明確に 079
現状 + 施策 = 将来の姿 079
システムをテコにして業務を変える 081
パターン① 電子化によるペーパーレス化
パターン② デバイス配布による「どこでも電子化」
パターン③ 発生時点入力
パターン④ データの一元管理
パターン⑤ 人間では煩雑すぎることをシステムで実現
［応用］全く新しい業務を構想する場合 085
将来業務フローを作成する6つのテクニック 087
①変化点を必ず書き出す 087
②まずはアナログで作る 088
③フォーマットを決める 089
④メインフローが先、イレギュラーが後 090
⑤詳細はとりあえず脇に置く 090
⑥一人で作らず、人を巻き込む 091
［Column］システムを作らせるには、 業務をちゃんと語れ 093
F章 システム要求（What）を決めるプロセス 096
システム要求、要件、そして設計 096
システム要求の3大障壁 099
要求定義3つの成果物 101
FM［Functionality Matrix］作成の5つのステップ 103
［Column］作らせる人が要求定義をし、作る人が要件定義をする、は本当？ 106
G章 機能を洗い出す7つの方法 108
発散⇒収束モデル 109
機能を洗い出す7つの方法 110
洗い出し方法①現行システムから 111
［事例］機器保守点検での要求洗い出し 112
洗い出し方法② 標準テンプレートを使う 113
洗い出し方法③業務フローから機能を拾う 115
［事例］工場ごとにバラバラな業務とシステムをゼロから議論した 116
洗い出し方法④ ソリューションや業務入門書で抜け漏れをチェックする 117
洗い出し方法⑤ビジネスの文脈を捉え、将来への布石を打つ 118
洗い出し方法⑥新規ビジネスモデルから導き出す 119
洗い出し方法⑦シーズ × シーンマトリクスを使う 120
H章 要求をFMにまとめる 123
FMにまとめる基本ステップ 123
［応用］FMを書く際に、 パッケージソフトを意識するケース 126
［事例］ダメなFM、 良いFM 132
I章 要求の詳細を FSに表現する 134
セルの説明を具体的に書く 134
FSに書くこと4つ、 書かないこと2つ 137
なぜ、FSを詳細に書きすぎなくてもいいのか？ 140
［Column］要求定義を Scopeフェーズと呼ぶ理由 143
J章 優先順位の基準を決める 145
絶対に全部作るな！ 145
絞り込みには納得ずくのコンセンサスが必要 146
3つの基準を3段階評価 147
［Column］3段階評価って粗すぎる？ 149
優先順位基準 1：ビジネスベネフィット 149
［事例］ビジネスベネフィットが全てHighのFMがあった 150
優先順位基準 2：組織受入態勢 152
［事例］今回は組織受入態勢を無視します！ 154
優先順位基準 3：技術的容易性 155
基準は関係者を巻き込んで決める 157
セルごとの評価は機械的に 158
［Column］技術的容易性はプロジェクトが進むと変わる 156
K章 作る機能を決める 160
良いレーティングの機能を真っ先に作る 160
まずはレーティング結果から機械的にフェーズを分ける 161
［Column］機械的な判断が現状踏襲を防ぐ 163
セル同士の関係と総ボリュームを調整する 164
色分けされた FMが完成し、 開発ステージが明確に 165
［事例］要求の半分を削り、 ミニマム導入にこぎつける 167
［Column］FM作成は一直線に進むのか？ 168
L章 FMがシステム構築を成功に導く 170
システム構築の失敗はFMで防ぐ 170
［事例］白いセルだけのFMを作ったプロジェクト 177
FM は要求定義以降も使い倒す 179
［事例］現場説明会には必ず FMを印刷して持っていく 181
M章 機能以外の要求を定義する 183
機能以外に決めるべき2つのこと 183
非機能要求の6つの切り口 184
［事例］販売管理システム構築プロジェクトでの非機能要求 187
非機能要求検討における、 作らせる人の心構え 188
［Column］SaaS 時代の非機能要求 191
システムアーキテクチャの3つのポイント 192
パッケージやベンダーを選ぶ 198
［参考］パッケージを活用することのメリット／デメリット 199
ベンダー選定の13ステップ 199
［Column］なぜベンダー選定／パッケージ選定は難しい？ 201
N章 パートナーの1次選定 203
ステップ① ロングリスト作成 203
［Column］ロングリストになるべくたくさん載せる理由 205
ステップ② 評価基準設定 （1次選定用） 206
ステップ③ RFI（Request For Information） 208
ステップ④ 1次選定 212
［応用］辞退されて慌てないように！ 214
O章 提案を依頼する 215
ステップ⑤ 複数パートナーの組み合わせ検討 215
ステップ⑥ 評価基準設定 (2次選定用) 217
ステップ⑦ RFP (Request For Proposal) 219
ステップ ⑧ Q&A 対応 222
［Column］質問や回答は全ベンダーに公開するか？ 223
ステップ ⑨ Fit & Gap 224
ステップ ⑩ デモ実施 226
［事例］デモシナリオの選定 228
［Column］他社に聞きにいけ！ 232
P章 パートナーを決定する 234
ステップ 11 投資額シミュレーション 234
［応用］提案金額が予算を大幅に超えてしまった時には 235
［事例］費用を抑えるためにベンダーへの依頼を絞り込んだ 237
ステップ 12 評価表の作成 238
［事例］各項目をなるべく機械的に採点した 240
ステップ 13 最終選定 243
［事例］中学生が運転するベンツに乗りますか？ 244
ベンダー選定は Scope フェーズ段階から始まっている 245
［Column］SaaSの選定で何が大事になるか？ 247
［Column］イケてる会社は内製化に向かう？ 248
Q章 稼動までの計画を立てる 250
ベンダーから提案されたスケジュールを鵜呑みにするな！ 250
システム構築スケジュールを精査する6つの観点 252
［Column］ベンダーの体制が整わずにプロジェクト開始が遅れてしまう 257
プロジェクト外とのコミュニケーションをおろそかにしない！ 258
コミュニケーション計画をあらかじめ作り、粛々と実行 260
［参考］テスト工程の定義 262
R章 プロジェクトの投資決裁を得る 266
費用対効果分析は数回にわたって行う 266
費用対効果分析をブラッシュアップする 268
［Column］最後まで不確実性が残るのがプロジェクト 269
ベンダーの見積範囲外が落とし穴 270
［事例］ 社内の体制確保と人件費見積 272
決裁資料はとにかくわかりやすさを重視せよ 273
［事例］予算感や必要性は早めに握れ 274
［Column］黒字にならないシステム構築をどう訴求するか？ 277
S章 課題を先出しする 280
本格的に作る前に、試すことの大事さ 280
［Column］プロトタイピングをやらないとなにが起こるか 281
BPP［Business Process Prototyping］の7つのステップ 283
ステップ① 対象シナリオの選定 284
ステップ② シナリオの準備 286
ステップ③ 確認ポイントの明確化 287
［Column］BPP セッションは何回やるべきか？ 288
ステップ④ プロトタイプを用意する 288
［応用］本物を使うか？ 紙芝居か？ を決める3つの作戦 290
ステップ⑤ データの準備 292
ステップ⑥ プロトタイプセッション当日 293
［応用］BPP に参加する「作らせる人」の心構え 294
ステップ⑦ 課題を潰す 296
［Column］システム課題の対応はベンダーのスキル次第 296
［事例］画面を見るだけでは、「課題の先出し」にならない 297
T章 開発チームの立ち上げ 300
開発チームづくりをITエンジニアに丸投げしない 300
［事例］プロジェクト全体のことなど一切考えていませんでした！ 301
良い開発チームを作る9原則 302
［Column］スクラッチはブレイクダウン、パッケージはすり合わせ 309
U章 キーチャート 312
キーチャートとは何か 312
キーチャートと網羅性 314
［事例］キーチャートを見ていてミスに気づいた 3164
だれがキーチャートを作るのか？ 317
要件を表現するその他の方法 318
キーチャート7選 319
V章 開発中の関与 324
役割①監理できるプロを任命する 324
［Column］ITベンダーは品質など気にしていない！ 327
役割②課題解決への参加 329
［Column］課題解決とファシリテーション 330
役割③ 使う人目線でのチェック 331
役割④ユーザー教育 332
W章 データ移行 335
実は「作らせる人」が主役のデータ移行 335
データ移行は想像よりずっと大変 336
データ移行はスーパーマンでなければできない？ 337
［Column］データ移行で業務担当者しか判断できないこと 339
データ移行の勘所① 捨てるものを決める 340
データ移行の勘所② マッピングがキモ 343
データ移行の勘所③ 移行ファシリテーターがハブになれ 344
［Column］なぜデータ移行の大変さがピンとこないか？ 345
X章 いよいよ新システムの稼動 348
2つのシステムを並行稼動させる 348
2種類の並行稼動 349
A) バトンタッチ型並行稼動
B) 業務テスト型並行稼動
業務とシステムの切替はプロジェクト最大の山場 351
［事例］経営陣に腹をくくれと迫ったプロジェクト 352
本番稼動後のバタバタを乗り越える 353
ヘルプデスク
エスカレーションルート
コンティンジェンシープラン［Contingency Plan］
［事例］大規模プロジェクトでのヘルプデスク 354
［Column］業務がスムーズに立ち上がるかは、これまでの通信簿 357
狙い通りの業務になっているか？ 成果をあげているか？ 357
この世で最悪のシステムは、 完璧に作って使われないシステム 358
Y章 ［補足］ベンチャーでのシステム構築 361
ペットロボット「LOVOT」を飼い主に届けよ！ 361
飼い主が亡くなったときにどんな業務が必要なのか？ 363
ビジネスや商品が揺れ動く中でのシステム開発 364
最初にFMをしっかり作る
ステージは小さく区切る（スプリント［Sprint］）
スプリントの切り分け方が重要
同時並行でスプリントをするための工夫
プロトタイプは大事だが、闇雲に作っても無駄
期限や品質を守るためのマネジメントはいつもと同じく大切
優秀なITベンダーに火を付ける大切さ
どんなに工夫しても、ツライもはツライ
［Column］ウォーターフォール、 アジャイル、その中間 370
Z章 ［補足］FMをシステム構築以外に応用する 373
FMはシステム機能以外でも効果を発揮する 373
①組織機能の実現範囲を決める 374
②商品開発や研究テーマの優先度を決める 375
③Webサイトに掲載するコンテンツを決める 375
④データウェアハウスに収集するデータを決める 377
⑤データの移行範囲を決める 378
おわりに [379-385]
個人的な執筆動機（2021年6月 濵本佳史）
「作らせる人」「作る人」の断絶と、One Team（2021年6月 白川克）
謝辞
執筆者紹介 [386]
【図表一覧】
図表A-1 ４つの関係者 ITプロジェクトにかかわる人々 020
図表A-2 ４つの関係者 ITを作る人、ITを作らせる人 022
図表A-3 ゴールデンサークル 024
図表A-4 不確実性コーン 028
図表B-1 システム構築の全体像 031
図表B-2 システム構築の全体像 033
図表B-3 アセスメントシート 040
図表C-1 本当に標準化／統合すべきなのか？ 048
図表D-1 現状調査2つの目的 059
図表D-2 スイムレーンチャート 063
図表D-3 現行アクティビティ一覧 064
図表D-4 現行ファンクショナリティ・マトリクス 065
図表D-5 現行システム一覧 066
図表D-6 現行インターフェース一覧 067
図表D-7 現行全体システム構成図 068
図表D-8 現行システムの主要データ 069
図表D-9 現行コード体系 070
図表D-10 課題一覧 071
図表E-1 施策一覧 078
図表E-2 現状と将来 080
図表E-3 施策名称：見積ルール／プロセスの見直し 080
図表E-4 見積プロセスのラフスケッチ 081
図表E-5 電子化によるペーパーレス化 082
図表E-6 データの一元管理 084
図表E-7 ビジネス概要図 086
図表E-8 変更点一覧 088
図表E-9 将来業務フローのフォーマット例 090
図表F-1 要求定義、要件定義、設計 099
図表F-2 システム要求定義の3つの成果物と作成ステップ 101
図表F-3 FM（ファンクショナリティ・マトリックス） 102
図表F-4 FM（ファンクショナリティ・マトリックス） 105
図表G-1 FM（ファンクショナリティ・マトリックス） 108
図表G-2 発散⇒収束モデル 109
図表G-3 標準テンプレート（人事領域の例） 114
図表G-4 業務フローから機能を拾う 115
図表G-5 将来像から機能を洗い出す 119
図表G-6 シーズ・シーンマトリクスで機能を洗い出す 120
図表G-7 シーズリスト・シーンリスト 121
図表G-8 カジュアルなシーズリスト 122
図表H-1 FM（ファンクショナリティ・マトリクス） 123
図表H-2 機能をセルに整理 124
図表H-3 セルをグループに分ける 125
図表H-4 セルとグループを並べる 126
図表H-5 FMの例（人員配置） 128
図表H-6 FMの例（契約管理） 129
図表H-7 FMの例（作業準備） 130
図表H-8 FMの悪い例 132
図表H-9 FMの良い例 133
図表 I-1 FM（ファンクショナリティ・マトリクス） 134
図表 I-2 FS［Function Spec］記述例 135
図表 I-3 FMとFS（Excel版） 135
図表 I-4 FSに書くこと 137
図表 I-5 ちょうど良いFSの記述レベル 140
図表J-1 FM（ファンクショナリティ・マトリクス） 145
図表J-2 優先順位の基準 148
図表J-3 FSにおける優先順位と評価 148
図表J-4 ビジネスベネフィット 150
図表J-5 組織受入態勢 152
図表J-6 技術的容易性 156
図表J-7 FM（レーティング済み） 159
図表K-1 FM（ファンクショナリティ・マトリクス） 160
図表K-2 デシジョンテーブル 162
図表K-3 FM（ステージ分け後） 166
図表K-4 FMの例 167
図表L-1 FMがプロジェクトを成功に導く理由 171
図表L-2 FMの用途 180
図表M-1 ２段階選抜 200
図表N-1 ロングリストの例 203
図表N-2 パッケージ情報のまとめ例 204
図表N-3 RFI掲載項目 209
図表N-4 対処範囲の例 209
図表N-5 システム要求の例 210
図表N-6 推奨の製品・組み合わせ 211
図表N-7 製品情報 211
図表N-8 導入実績 212
図表N-9 概算費用 212
図表N-10 １次選定結果 213
図表O-1 ベンダーごとの機能カバー範囲 215
図表O-2 複数ベンダー組み合わせの例 216
図表O-3 RFP［Request For Proposal］掲載項目 220
図表O-4 提案依頼内容 221
図表O-5 Fit&Gapの結果 224
図表O-6 Fit&Gapの評価方法 225
図表O-7 デモの優先度 228
図表O-8 基幹システム刷新のデモシナリオ 229
図表O-9 デモにおける確認ポイントの例 230
図表O-10 デモの評価結果 231
図表P-1 投資額シミュレーション 235
図表P-2 システム刷新範囲の選択肢 237
図表P-3 システム導入費用 238
図表P-4 ベンダーの評価結果 239
図表P-5 企業・製品信用度の評価結果 241
図表P-6 評価の根拠（信用度） 241
図表P-7 評価の根拠（アプローチ） 242
図表P-8 評価の根拠（非機能） 242
図表P-9 ベンダー正式決定へのステップ 243
図表P-10 ベンダー選定のステップと期間 246
図表Q-1 プロジェクト全体スケジュール 250
図表Q-2 様々なプロジェクト計画 251
図表Q-3 DX［デジタルトランスフォーメーション］の阻害要因 259
図表Q-4 変革需要曲線 260
図表Q-5 ECサイト再構築におけるコミュニケーション計画 261
図表Q-6 ベンダー主体のテスト 263
図表Q-7 ベンダーと発注者が共同で行うことが多いテスト 263
図表Q-8 発注者側主体となることが多いテスト 263
図表R-1 投資対効果シミュレーション 267
図表R-2 費用対効果の予測のブレは小さくなる 268
図表R-3 システム構築にかかる費用項目 271
図表R-4 IT投資の３段階 275
図表S-1 V字モデル 282
図表S-2 BPP対象シナリオ 285
図表S-3 BPPシナリオ 286
図表S-4 BPP確認ポイント 287
図表S-5 画像イメージの使い分け 290
図表S-6 前提となる組織イメージ 292
図表S-7 プロトタイプセッションの様子 293
図表T-1 プロジェクトを広く捉える 300
図表T-2 スクラッチとパッケージ 310
図表U-1 キーチャート 312
図表U-2 キーチャートの意義 315
図表U-3 販売実績のポイント化キーチャート 318
図表V-1 課題解決会議 330
図表W-1 移行の全体像 335
図表W-2 基幹システム再構築のプロジェクトにかける工数の割合 337
図表W-3 項目マッピング 343
図表W-4 移行ファシリテーター 344
図表X-1 並行稼動 349
図表X-2 ヘルプデスク 355
図表X-3 コンティンジェンシープランの例 356
図表Y-1 ウォーターフォール、 アジャイル、その中間 372
図表Z-1 組織機能ファンクションマトリクス 374
図表Z-2 コンテンツマトリクスの例 376
図表Z-3 データマトリクス 377
【メモランダム】
著者（白川氏）のブログのうち、本書へ言及している記事をメモしておく。
まず（本書の名が付された）カテゴリ。
https://blogs.itmedia.co.jp/magic/cat5079/
その他、関連がありそうな記事。
2021/07/20
https://blogs.itmedia.co.jp/magic/2021/07/post_100.html
2021/08/19
https://blogs.itmedia.co.jp/magic/2021/08/fm.html
2022/06/20
https://blogs.itmedia.co.jp/magic/2022/06/post_116.html
2023/08/07
https://blogs.itmedia.co.jp/magic/2023/08/post_128.html
