システムを作ってもらう側の人間です。
作る側の本やノウハウは多くありますが、作ってもらう側の本はなかなかなく、体系的に改めて新たなヒントを得たいと読んでみました。

記録としてサマリーをしたいと思います。

1.ゴールの明確化

システム構築自体をゴールに掲げるプロジェクトは失敗しやすい。
システム構築という面倒でお金もかかるプロジェクトをなぜやるのか？本当にやる必要があるのか？
組織全体で腹の底から合意できるゴールが必要。

【ゴール設定のコツ】
①以降の工程で使えるゴールにせよ
② 地に足のついたゴールにせよ
③何のためのプロジェクトがwhyをコンセプトやゴールに込めよ
④ゴールの分かりやすさにこだわれ

2.現状の棚卸

調査方法として2種類あり。業務改革のプロジェクトは両方満たす必要あり。
①課題発見型　何を改革するか？
②棚卸型　どのシステムに影響するかの洗い出しなど、網羅性がポイント。

棚卸しした資料をベースに分析を行う（現行システムのガンを把握する）。
システムの棚卸しは、エンジニアに任せてよい。

ただし、分析の結果はよく理解しておく必要がある。

whyを理解しないと、何にどれだけお金をかけるべきか？システムの一部を作り直すことに意味があるのか？など、今後のプロジェクトで迫られる判断を主体的にくだせなくなる。

【9大フォーマット】
業務系フォーマット
①現行業務フロー

②現行アクティビティ一覧

システム系フォーマット
③現行ファンクショナリティマトリクス
④現行システム一覧
⑤現行インターフェース一覧
⑥現行全体システム構成図
⑦現行システムの主要データ
⑧現行コード体系

共通フォーマット
⑨課題一覧

3.ビジネスモデル（将来像＝Howを明らかにする）

システム機能を具体化する前に、「システムが変わったらどういう姿になっているか」という将来像を描く。システムは業務の将来像を実現するためのものなので、目指したい業務がぼやけていては、システム構築も迷走してしまう。

何を変えたいか？なぜ変えたいのか？前後の業務とどうつながるか？将来の業務がどうなってほしいかちゃんと語れるか？

①施策一覧作成（なぜ必要か、何を変えるのか、何が良くなるのか）

②将来業務フローを書く前に、変えたいことをわかりやすく示した図を一旦書いておく。

③詳細業務フローを書く
【テクニック6箇条】
・変化点を必ず書き出す
・まずはアナログで
・フォーマットを決める
・メインフローが先、イレギュラーが後
・詳細はとりあえず脇に置く
・1人で作らず、人を巻き込む