内容
歴史上の優れたリーダーや企業は一般とは違い、「Why ⇒ How ⇒ What」の順番で他人を説得する。
標準化
ルールやデータは完全に標準化・一元化する。
そして業務とシステムについては、2つに分けて考える方針となった。
・顧客に接するフロント業務は、地域特性ごとにある程度のバラバラさは許容する。会社の競争力を維持する上で必要だから
・一方でバック業務（事務処理など、顧客に接しない業務）は全社で標準化しない理由はない
アニメーション
新しい端末がもたらす未来の働き方を描いたアニメーションも制作した。
ストーリー仕立てだと、コンセプトを誰でも理解できる。
だから現場で懸命に仕事をする営業職員さんやその先の顧客のことを考えながらプロジェクトの1つ1つの仕事をできるようになる。
少しわかりにくいゴールやコンセプトを掲げる時には、ここまでの熱量を覚悟してほしい。
業務フローの用途
a）機能要求の洗い出し、
b）ベンダーへの情報提供、
c）プロトタイプセッションのシナリオ、
d）テストシナリオ、
e）ユーザーマニュアルや説明会資料、
などだ。
システム要求を決めるプロセス
要求定義
システムを作らせる人が、「システムはこんな風であってほしい」と、システムに求めることを明確にする作業。
システムに詳しくない人が定義するので、システム的な厳密性、網羅性には欠ける。
要件定義
システムを作る人が、システムに必要とされる性能や実装すべき機能などを明確にする作業。
システムが果たすべき機能はすべて要件定義書に書かれるべきなので、例えば「どういうケースでエラー表示をするか？」の一覧表を作るプロジェクトもある。
設計
システムを作る人が、要件を実現する技術的な方法を決める作業。
例えば「この機能は○○というソリューションを使う」「データ構造はこうする」といった具合だ。
ユーザーから目に見える画面レイアウトなどを固める設計を「外部設計」、目に見えない内部ロジックを考える「内部設計」に分ける場合もある。
要求定義とは利害関係者の意見をまとめて、実現すること／実現しないことを揺るぎなく定めること。
「要求を出し切ることに責任を感じるかどうか？」で、プロフェッショナルなITエンジニアと、言われたことをやるだけの作業者に二分できると思っている。
アイデアの発散、収束
アイディア出しと絞り込みをはっきり分けるプロセスを「発散⇒収束モデル」と呼んでいる。
まずはアイディアを発散させることに専念し、十分出し切ってからそれを絞り込む。
1回は風呂敷を広げられるだけ広げ、その後たたむイメージだ。
洗い出し方法
多くの顧客とプロジェクトをやっている会社は、業務領域ごとの標準テンプレートを持っていることがある。
これらを使えば、ゼロから洗い出すより網羅性を担保しやすいし、圧倒的に能率が良い。
システム機能を洗い出す一番手っ取り早い方法はパッケージ製品の機能一覧を見ることである。
まずは将来業務フローなどをベースに、自社で必要な機能を洗い出す。
十分時間をかけて洗い出した後で、ソリューションの機能一覧で抜け漏れをチェックする方法だ。
これならば、冷静に判断できる。
新技術（シーズ）と自社ビジネスの様々な局面（シーン）を無理やり掛け合わせてみる方法だ。
内製化のアクション
- 数社を渡り歩いた経験豊富なCIO（IT担当役員）をヘッドハンティング
- CIOのツテで腕のよいエンジニアを多数採用する
- ITをテコにした大胆な変革プロジェクトを推進する
費用対効果分析
システムに限らず企業で投資判断をする際には「投資が何年後に回収できるか？」を示した、費用対効果と呼ばれる分析を行う。
要は「それをやって儲かるのか」「やるだけの価値があるのか」のシミュレーションだ。
費用対効果分析はプロジェクトが進行するのに伴い、数回行うことにしている。
1回目：施策を検討し、プロジェクト計画が固まった時点
2回目：要求定義やベンダー選定が終わり、会社として投資の最終決定をする段階
3回目：システムが稼動し、業務が安定した頃
投資決裁
投資決裁を仰ぐ際に、改めて説明すべき情報は以下になる。
①現時点で何がまずいか →現状調査の結果
②だからこうなりたい（ビジョン・将来像） →将来のあるべき姿
③ビジョン実現のために、こんなシステムが必要になる →FMにまとめた内容
④選定したベンダーやパッケージと、その理由 →選定結果
⑤費用なリソース（費用、時間、体制）
⑥全体として、投資する価値があること
面白かったポイント
システムを作らせるという着眼点は素晴らしい思う。
DXの成功は、この業務部門と開発部門のコミュニケーションのギャップをいかに少なくするかがポイント。
オーナー、業務部門は、経営戦略から部門戦略、業務プロセス分析に落とし込み、IT化をするスコープを決める。
業務改革とシステム開発の両方の知識を持つ人はほとんどいない。
満足感を五段階評価
☆☆☆☆☆
目次
A章 作る前に知っておくべきこと
B章 プロジェクト全体の進め方
C章 ゴール(Why)を明らかにする
D章 現状の棚卸をする
E章 将来像(How)を明らかにする
F章 システム要求(What)を求めるプロセス
G章 機能を洗い出す7つの方法
H章 要求をFMにまとめる
I章 要求の詳細をFSに表現する
J章 優先順位の基準を決める
K章 作る機能を決める
L章 FMがシステム構築を成功に導く
M章 機能以外の要求を定義する
N章 パートナーの1次選定
O章 提案を依頼する
P章 パートナーを決定する
Q章 稼働までに計画を立てる
R章 プロジェクトの投資決裁を得る
S章 課題を先出しする
T章 開発チームの立ち上げ
U章 キーチャート
V章 開発中の関与
W章 データ移行
X章 いよいよ新システムの稼働
Y章 〔補足〕ベンチャーでのシステム構築
Z章 〔補足〕FMをシステム構築以外に応用する