【感想・ネタバレ】システムを作らせる技術 エンジニアではないあなたへのレビュー

白川克 / 濵本佳史

SEじゃないあなたのための
DX推進の教科書！

企業のDX推進でシステムを「作らせる技術」の重要性は増しています。
プログラマーやSEのような専門家だけがシステムについて考えればよいのではなく、「自分では作れなくとも、思い通りのシステムを『作ってもらうノウハウ』」が必須の時代になったということです。

そのためには、

・「こんなシステムがあればいいのに」を構想し、
・「A機能とB機能、どちらを優先すべきか」を判断し、
・これを作るのにいくらまで投資する価値があるか？を見極め、
・作ってくれる人（社内の情報システム部門、または社外の専門ベンダー）を探し出し適切に依頼し、
・構築プロジェクトで沸き起こる様々な課題を解決

していかなければなりません。

本書はシステムに詳しくない業務担当者が、新しいビジネスを立ち上げるために、または既存の業務を改革するために、すべきこと／陥りやすい落とし穴を余すことなく書きます。
著者が20年以上にわたり支援してきた多くのプロジェクトでの事例やエピソードを詰め込んだ、実務家のための教科書です。

[ブクログ · ★★★★☆]

システムを作らせる技術
A章作る前に知っておくべきこと
・関係者。経営陣、業務部門、PLが作らせる人。IT部門とそれに紐づくベンダーが作る人。
・why？→how？→whatでストーリーを納得させる。例）工場ごとにバラバラな業務を統合し、一つの会社として運営すべき→統合後の業務プロセスはこうあるべき→そのためにこういうシステムを作ろう
・whatから考えるのでなく、whyから考える。

B章プロジェクト全体の進め方
・メンバー間の意識を合わせる（C章）
・今の仕組みを調べる。ここまでがwhy（D章）
・howにあたる3つを行う。ビジョンを明らかに、そこに到達するための施策を練る、施策群をまとめて1つの計画立案（E章）
・どんなシステムが必要か（F〜M章）
・ベンダー選定（N〜R章）
・プロトタイプ検証（S章）
・システム設計やデザイン（T〜W章）
・切替作業（X章）

C章 ゴール(Why)を明らかにする
・良いプロジェクトゴールづくりの4つのコツ
以降の工程で使えるゴールにせよ
地に足のついたゴールにせよ
何のためのプロジェクトかゴールやコンセプトに込めよ
ゴールのわかりやすさにこだわれ

D章 現状の棚卸をする
・今のシステムの棚卸しを、スイムレーンチャートわタスク一覧表、全体システム構成図などなどから把握

E章 将来像(How)を明らかにする
・システムが変わったらどういう絵姿になっているか？という将来像を描く
・変化点を必ず書き出し、メインフローや概要から取り掛かる

F章 システム要求(What)を求めるプロセス
・要求定義はシステムを作らせる人が求めることを明確にすること。要件定義はシステムを作る人が実装すべき機能を明確にすること。
・網羅性がない、予算オーバーになる、立場が違えばシステムに求めるものが違うなどから、要求定義は難しい
・要求定義の成果物。
FM（ファンクショナリティ・マトリクス）H章で。
非機能要求定義書（M章）
キーチャート

G章 機能を洗い出す7つの方法
・要件定義の第一歩はシステムに求めることについて片っ端から要求を書き出す作業。現行フローや業務フローから洗い出すのも良し。

H章 要求をFMにまとめる
・前章で洗い出した項目を整理。グループに分けて並べて…（サイトなども参考に）

I章 要求の詳細をFSに表現する
・先の項目に対して、具体的に書く。FSファンクション・スペック。
・FSに書くこと。実現したいこと、扱う情報、他の機能との関連、バリエーションやイレギュラー
・FSに書かないこと。実装方法、画面イメージ。

J章 優先順位の基準を決める
・FSにおける優先順位はビジネスベネフィット（ビジネス上どれほど価値があるか？）組織受入体制（そのシステムをどれほど使いこなせるか？）、技術的容易性の3点を3段階評価で決める。
→セルごとに色分け

K章 作る機能を決める
・先の優先度が高いレーティングの機能から作る。

L章 FMがシステム構築を成功に導く　

M章 機能以外の要求を定義する
・非機能要求おアーキテクチャの議論が必要。
・非機能要求仕様定義ガイドライン参照。
・システムアーキテクチャの３つのポイント。パッケージか手作りか、オンプレかクラウドか、複数システム間の連携

N章 パートナーの1次選定
O章 提案を依頼する
P章 パートナーを決定する
Q章 稼働までに計画を立てる
・ベンダーから全体スケジュールが展開されるが、そのまま採用するわけにはいかない。精査が必要。
マストな期限が守られているか、業務繁忙期とシステム構築のピークは重なっていないか、工程ごとのゴールが明確か、成果物をチェックするマイルストーンはあるか、各領域の整合が取れているか、各フェーズの期間バランスが適切か
・テストも誰がやるのか、何のテストか確認が必要。どの工程でも、どこまでやったら次の工程に進めるのか、工程ごとに確認を

R章 プロジェクトの投資決裁を得る
・費用対効果のシミュレーションを行う。不確実性があるので、数回行いブラッシュアップを

S章 課題を先出しする
・要求定義に相対するユーザー受入テスト。プロトタイプを使ったチェックでBPPと言われる

T章 開発チームの立ち上げ
U章 キーチャート
V章 開発中の関与
W章 データ移行
X章 いよいよ新システムの稼働