DX推進:「作ってもらう技術」を知る_#2_作ってもらう側がちゃんとやるべきこと

もともとPdMが「どうやってエンジニアとコミュニケーションを取るべきか」について学習するつもりで今回の参考図書を手にしました。

内容はあいにく、PdMというよりDX推進を任されたPM向けの内容です。
ただし本書は読みやすく簡易かつMECEにDX推進の流れをまとめてくれているようなので、最後まで読んでみます。

前回は、全体のフローを確認し、少し詳細に入りました。

参考①PMの役割の説明

システムを導入するために必要な心得｜Nakano Yasuaki｜note

参考②：そもそもDXとは

参考図書

システムを作らせる技術 エンジニアではないあなたへ

今回は詳細の続きです。
文字数：約3,800

1．全体フロー（今回は③～④）

①Concept Framing（ゴール明確化）（C章）
・この段階でメンバー全員の頭の中身が揃っていることは稀
・プロジェクトのゴールやコンセプトの仮説を決める
②Assessment（現状調査）（D章）
・現時点での業務やシステムを把握する
・集めた情報を構造化し「成長を妨げるボトルネックはここ」と統一見解を出す
・Whyを明確にするフェーズ
③Business Model（構造策定）（E章）
・Assessmentで明確になった課題を解決するための将来像を描く
・Howを検討するフェーズ
④Scope（要求定義）（F～M章）
・いよいよどんなシステムが必要か考えるフェーズ
・システムへの要望を文書化することがゴール
・Whatを決めるフェーズ
⑤PEW（製品選定/ベンダー選定）（N～R章）
・Partner Evaluation Workshopの略で、Scopeでどんなシステムが必要かが明確になったので、それを実現するパッケージ/ソリューションを提供するパートナーを選ぶ
⑥BPP（プロトタイプ検証）（S章）
・Business Process Prototypingの略で、プロトタイプでシミュレーションしてみる
⑦Design〜Depolyment（開発）（T～W章）
・設計書を書くDesignとプログラミングやソフトが使えるように設定するDepolyment
・このフェーズから、作ってもらう人から作る人が主体になる
⑧Rollout（稼働）（X章）
・システムだけでなく業務も変わるので、作ってもらう人と作る人が共同で乗り越える一大イベント

・システム構築より前のフェーズ（①〜⑤）に時間をかけることが重要

システムを作らせる技術
ISBN 978-4-532-32399-8
P31〜38

E章 Business Model：将来像（How）を明らかにする

【狙い】
・システム機能を具体化する前に、システムが変わったらどうなっているかという将来像を描く
・将来像の描き方や将来業務フローの作成方法を知る

システムを作らせる技術
ISBN 978-4-532-32399-8
P78

1．プロジェクトで変えることを明らかに

・棚卸した結果見えてくる施策一覧には、効果が高い／低い、難易度が高い／低いが混在している
・ゴールと照らし合わせながら効果が高く、比較的簡単にできる施策を厳選していく

システムを作らせる技術
ISBN 978-4-532-32399-8
P79

2．現状＋施策＝将来の姿

・現状で大きな問題がない業務は「棚卸した業務＝将来の姿」になる。レガシーシステムのサポートが切れてしまい、再構築するプロジェクトが該当する
・現状に問題がある業務は「現状業務＋施策による変更＝将来の姿」となる
・As-IsとTo-Beを比較できれば「何を変更するのか」「変えた結果、どんな効果が見込まれるか」が分かり、業務イメージも湧き、システム機能が求めること（機能要求）も分かってくる

システムを作らせる技術
ISBN 978-4-532-32399-8
P79～81

3．システムをテコにして業務を変える

＜よくある5つのパターン＞
①電子化によるペーパーレス
・小口顧客はFAX、大口顧客の一部はEDI（Electronic Data Interchange）をWEBシステムに刷新するなど
②デバイス配布による電子化推進
・現場からオフィスに戻って確認するというムダな往来を無くしたいので業務用タブレットを配布するなど
③発生時点入力
・データは発生した時点で当事者が入力するのが一番効率的を実現するためのシステム導入など
④データの一元管理
・紙やエクセルで情報リレーをしており、同じような作業が存在しているので、それを削減するための一元管理など
⑤人手で煩雑すぎることをシステム化
・長期間の商談や顧客との関係をMAで代替するなど

システムを作らせる技術
ISBN 978-4-532-32399-8
P81～86

4．将来業務フローを作成する6つのテクニック

①変化点を必ず書き出す
・将来業務フローを書く際に単にフローの清書になってしまうことがある
・これを防ぐために変化点を同時に書き出しておき、何を変えるべきかを一覧できるようにする
②最初はアナログで作る
・将来フローは議論の間に何度も書き直しが生じるので、ポストイット等を使ったアナログの方が効率が良い
③フォーマットを決める
④メインフローが先、イレギュラーが後
・最初から色々なケースを踏まえたフローを作成すると議論が発散する
・まずはメインフローを最後まで作成し、そのあとに肉付けする形でイレギュラーを挿入する
⑤詳細は脇におく
・作成中に湧いてくる疑問は検討項目として、別にまとめておき、最初はフローを完成させることを優先する
⑥一人で作らず、人を巻き込む
・多様な視点を含めて作成する方が後戻りが発生しにくい

システムを作らせる技術
ISBN 978-4-532-32399-8
P87～94

F章 Scope：システム要求（What）を決めるプロセス

【狙い】
・システム要求定義の流れを理解する
・システム要求をまとめる難しい点を把握し、「なぜこのプロセスならうまくいくか」が分かるようにする

システムを作らせる技術
ISBN 978-4-532-32399-8
P96

1．システム要求・要件・設計

■要求定義（システムを作らせる人が責任を持つ）
・システムを作らせる人が、「こんな風であってほしい」とシステムに求めることを明確にする作業
・この時点ではシステムに詳しい人が作成していないので、システム的な厳密性・網羅性には欠ける

■要件定義（システムを作る人が責任を持つ）
・システムを作る人が、システムに必要とされる性能や実装すべき機能などを明確にする作業

■設計
・システムを作る人が、要件を実現する技術的な方法を決める作業（例：データ構造はこうあるべきなど）
・ユーザーから見えるUIなどを「内部設計」、ユーザーには見えない内部ロジックなどを「外部設計」と呼ぶ

・本書では「システムを作らせる側」をテーマにしているので、要求定義に多くの章を割いている

システムを作らせる技術
ISBN 978-4-532-32399-8
P96～99

2．システム要求の3大障壁

・ユーザー（システムを作らせる側）が要求定義に責任を持つ
・システムのプロに抜け漏れなく、実現可能性のある要求を伝えることは難しい（無理）
・要求定義のステップの前に、システム要求の本質的な難しさを見ておく
①完璧なリストアップができない
②常に予算オーバーになる
③立場が違えば、システムに求めるものが変わる

これら3つの障壁を加味して、要求定義とは
「利害関係者の意見をまとめて、実現すること／実現しないことを揺るぎなく定めること」

システムを作らせる技術
ISBN 978-4-532-32399-8
P99～101

3．要求定義の3つの成果物

①FM （Functionality Matrix）
・構築する機能一覧
②非機能要求定義書
・夜間停止しても良いか、応答スピードはどうするか、データのバックアップはどうするかなどを定めたもの
・IT担当者寄りの内容なので任せられる部分は任せて良いが、意思決定には積極的に参加する
③各種補足資料
・FMに馴染みにくい機能をまとめたもの
・例えば業務パターン、ユーザー種別と権限、移行すべきデータの種類など

システムを作らせる技術
ISBN 978-4-532-32399-8
P101～103

4．FM作成の5つのステップ

①機能の洗い出し（G章）
・欲しい機能をひたすら洗い出す
②FM作成（H章）
・欲しい機能はFMのフォーマットにまとめ、グループ分けをしておく
③機能詳細の記述（I章）
・具体的などんな機能かの説明を入れる
④優先順位基準の決定（J章）
・必須機能、あると良い機能を分け優先順位をつける
⑤優先順位の決定（K章）
・FMに優先順位が分かるように色分けなどしておく

システムを作らせる技術
ISBN 978-4-532-32399-8
P103～105

＜#2_作ってもらう側がちゃんとやるべきことの所感＞

なるほど！
やっと本書の面白さと醍醐味が見えてきました。

PdMのこと知りたかったのにちょっと違ったな・・・と思っていましたが、この本が人気な理由が分かってきました。

確かに要求定義と要件定義をごっちゃにしていました。
そしてこの要求定義側にここまでフォーカスを当てた本は見たことがないです。

次からはこの要求定義の作り方を一気に見ていきたいと思います。

システムを作らせる技術 エンジニアではないあなたへ