contents memorandum はてな

目次とメモを置いとく場

『システムを作らせる技術――エンジニアではないあなたへ』(白川克, 濵本佳史 日本経済新聞出版 2021)

著者:白川 克[しらかわ・まさる](1972-)  コンサルタント
著者:濵本 佳史[はまもと・よしふみ](?-)  コンサルタント
装丁:竹内 雄二[たけうち・ゆうじ](1966-) ブックデザイナー。
本文イラスト:今村 友加里[いまむら・ゆかり]
illustration:iStock.com/studiostockart
備考:索引は無い。それだけ項目一覧(≒目次)が読者の役に立つ。


システムを作らせる技術 | 日経BOOKプラス



【目次】
はじめに [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 4つの関係者 ITプロジェクトにかかわる人々 020
図表A-2 4つの関係者 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 2段階選抜 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 1次選定結果 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投資の3段階 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