システムを作らせる技術
Amazon : https://amzn.to/3Hyxq4G
A 章 作る前に知っておくべきこと
1. 作らせるのは誰か？
システムを使う業務部門
経営と業務部門のどちらかが他人事だと失敗する
2. システムより先に考えるべきことは？ : システムを手に入れて何をしたいのかを考えつくす
3. なぜこんなに計画がブレるのか？
B 章 プロジェクト全体の進め方
Concept Framing (ゴール明確化)
C 章 ゴール (Why) を明らかにする
ゴールが明確でなければ成功裏に稼働までたどり着かない
良いゴールを作るコツ
以降の工程で使えるか？
地に足がついているか？
なんのためのプロジェクトかがゴールやコンセプトに含める
ゴールのわかりやすさにこだわる
Assessment (現状調査・分析)
D 章 現状の棚卸しをする
現地現物主義は良いが、調査の目的が明確でない場合がある
課題発見をするのか、棚卸しをするのか
仮説ベースで深ぼるか、網羅性が大事か
それをもとに分析する
課題の本質や、繰り返さないようにすべきことは何？
Business Model
E 章 将来像 (How) を明らかにする
現行システム構成図を見て、人間が情報を繋いでいる部分の改善
データを一元管理する
将来業務フローを描いていく
Scope (要求定義)
F 章 システム要求 (What) を決めるプロセス
システム要求の本質的な難しさ
完璧な一覧化はできない
常に予算を超えてしまう
関係者全員の同意を取ることが難しい (立場によって求めるものが違う)
G 章 機能を洗い出す 7 つの方法
要求定義の第一歩
ファンクショナリティ・マトリクス作成の最初の段階
H 章 要求を FM にまとめる
ファンクショナリティ・マトリクスにどうまとめるか
開発着手前にスコープを決めることが大事 → アメリカでは Scope フェーズと呼んでいる
とはいえスコープ明確化が重要という観点は大事だな
J 章 優先順位の基準を決める
ケンブリッジ・テクノロジー・パートナーズでは、3 つの軸で評価
ビジネスベネフィット (ビジネス価値)
組織受入体制 (利用者側のコスト)
技術的容易性 (開発コスト)
それぞれ 3 段階で評価できるように、基準を明確化
K 章 作る機能を決める
L 章 FM がシステム構築を成功に導く
M 章 機能以外の要求を定義する
PEW (パートナー選定)
スクラッチ開発ではなく汎用パッケージソフトを利用することが増えてきた
これまでにない IT サービスを作る業務を除くと、ほとんどの業務向けのパッケージが存在する
N 章 ～ O 章
Q 章 稼働までの計画を立てる
システム構築以外の作業も全体スケジュールに載せて管理する
R 章 プロジェクトの投資決済を得る
ベンダーの予算見積りはプロジェクトの予算見積りとは異なることに注意 (ベンダーの見積りの対象範囲外のものもある)
BPP
S 章 課題を先出しする
業務のやり方自体を検証する
Design・Deployment
T 章 開発チームの立ち上げ
プロジェクト全体のマネジメントは発注者が責任を持つ
OneTeam になるために
率先して 「プロジェクト最適」 を言い続ける (自社の利益や都合を持ち出さない雰囲気づくり)
U 章 キーチャート
V 章 開発中の関与
監理できるプロの任命 → IT プロジェクトの監理
課題解決への参加
ファシリテーションも重要
利用者目線での確認
ユーザー教育 : プロジェクトの意義、業務がどう変わるか、システムがどう変わるかを説明
W 章 データ移行
Rollout
X 章 いよいよ新システムの稼働
稼働後には振り返りが重要
補足
Y 章 ベンチャーでのシステム構築
本書で説明している方法論は Cambridge RAD
Z 章 FM をシステム構築以外に応用する