DX推進:「作ってもらう技術」を知る_#1_まずは全体を把握する
PdMはありとあらゆるプロダクトに関わる情報を把握・理解・分析しないといけません。
とは言えPdM自身が優れたデザイン力、秀逸なコーディング能力まで持っていることはマストではありません。
プロダクトに関わるデザイナーと関わるためにはUI/UXのベースの知識が必要です。
これは以前まとめました。
一方でエンジニアとのかかわり方をちゃんと把握しないといけないと思い、話題の本を手に取ってみました。
参考図書
※当該記事作成後の意見
正直PdM寄りではなく、DX導入のPMのノウハウ本に近いな？と思いました。
ユーザーの課題解決をエンジニアと一緒にする、というよりは社内DXプロジェクトの成功率を上げるイメージです。
とは言え、400ページ近い本ですが、読みやすく知っておいて損はないと思うのでせっかくなので読み続けてみます！
ちなみにDXについて簡単にまとめた内容も作成していますので事前に読んでおくと良いかと思います。
文字数：約5,500
はじめに
・DXがバズワード化しており、DXが成功して企業は少ないのが実態
失敗原因①：ゴールがバラバラ
失敗原因②：システムをITエンジニアに丸投げ
失敗原因③：システムを欲しがるが業務を変えるつもりがない
失敗原因④：必要な技術がもれている（代わりに誰も使わない機能ばかり…）
失敗原因⑤：現場の声を聞きすぎてコストがかさむ
失敗原因⑥：システムを作ってもらうベンダーやソリューションの選択に失敗
失敗原因⑦：コントロールできない炎上プロジェクトに成り下がる
・これらの失敗はシステムを作る人でなく、作らせる人が原因
ISBN 978-4-532-32399-8
P6〜P9
A章 作る前に知っておくべきこと
【狙い】
①望むシステムを手にするために知っておくべきことを知る
②プロジェクトの立上げに何が不足しているか理解し、人集めや意識作りに役立てる
ISBN 978-4-532-32399-8
P18
1．作らせるのは誰か
＜システム構築プロジェクトの関係者＞
①経営者
・現場の担当者では判断がつかない意思決定が必要となるので、経営者が介在する
・短時間で決裁できる場を作らせる
②業務部門
・実際にシステムを使うことになる人
・システム要求を出すのが役割であり、予算もこの部門が持つと良い（ITでなく）
③IT部門
・関係者の中でシステムを作る側
④プロジェクトリーダー：PL
・①〜③の異なる部門の間に立ち、今何に集中すべきか決め、関係者を巻き込む役割
・システムを作らせるのはIT部門を除く3者であり、経営と業務部門が当事者であることの自覚が成功への第一歩
ISBN 978-4-532-32399-8
P18〜P22
2．システムより先に考えるべきこと
・Whyから考える（ゴールデンサークル）
・Why→How→Whatの順番が大切
・システム構築には膨大な手間とお金と人がかかるにもかかわらず、このプロジェクトにチャレンジするのはなぜか？と言う疑問に答えなければいけない
・こんなシステムが欲しい、このソリューションが良いなどWhatから始める人が多い
例）Why：工場ごとにバラバラな業務を標準化/統合し、一つの会社として運営すべき
How：統合後の業務プロセスはこうしたい
What：そのためにこういうシステムを作ろう
ISBN 978-4-532-32399-8
P23〜P26
3．なぜこんなに計画がブレるのか？
・システム構築プロジェクトは曖昧さ100%からスタートし、徐々に意思決定し不確実性な減り具体的になっていく
・この不確実性が減る道中は正解のない意思決定を繰り返す苦難の道のり
・「いま、どの程度細いことまで決めるれきか？」が悩ましいので、これから方法論を学んで行く
ISBN 978-4-532-32399-8
P26〜P29
B章 プロジェクト全体の進め方
【狙い】
・システムを作り導入するまでの流れをつかむ
・各フェーズが「何を持って終わった」を理解し、プロジェクトがどの段階か把握する
ISBN 978-4-532-32399-8
P31
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
C章 Concept Framing：ゴール（Why）を明らかにする
【狙い】
・ゴールが明確でなければ成功できない
・ゴールを有効に機能するゴールの事例を学ぶ
ISBN 978-4-532-32399-8
P42
1．システム作ること≒プロジェクトのゴールか？
・「このプロジェクトをなぜやるのか」「最低限達成すべきことはなにか」が明確にすることで、ゴールが曖昧にならないことが多い
・真の問題は「現場の無理解」ではなく「経営者・業務担当部門・IT部門がともに目指すゴールが明確でないために、厳しい意思決定の場面を乗り切れない」こと
ISBN 978-4-532-32399-8
P42～44
2．システム構築でのゴール事例
■事例1：システム再構築の意味をシビアに認めた
［ゴール］今使っているシステムと遜色のないシステムを作る
［背景］既存システムのサポートが切れる
［過程］
＋パッケージの導入
＋パッケージの機能だけでは業務が実現できなかった
＋要求が膨れ上がり投資額が巨大になった
［ポイント］投資額を少しでも安く、納期通り導入することがゴールになった
■事例2：ゴールをコンセプトで補完
［ゴール］営業社員用のタブレット端末を作り直す
［背景］営業端末更改プロジェクト
［過程］
＋プロジェクトのゴールが会社から与えられた
＋なぜ、端末が必要なのか？新しくしてどうなって欲しいのか？が何も議論されていなかった
＋プロジェクトメンバが合宿を実施し、なぜを徹底的に議論した
［ポイント］会社から与えられたゴールに頼るのではなく、自分たちで指針とするコンセプトを作りあげた
■事例3：本当に標準化すべきか？をちゃんと議論した
［ゴール］全社統一の仕事のやり方を作る
［背景］いくつかの向上のシステムのメンテナンス困難になってきた
［過程］
＋標準化は美辞麗句になりやすい
＋総論賛成だが、各論反対が巻き起こり、妥協が始まる
＋標準化を「ルール」「データ」「システム」「業務」など切り口を因数分解して、それぞれにどの程度の標準化が必要か議論した
［ポイント］標準化という対義名分を分解し自分ごとにした
ISBN 978-4-532-32399-8
P42～51
3．良いプロジェクトゴールづくりの4つのコツ
①以後の工程で使えるゴールにする
・プロジェクトのゴールは、判断を下す際の価値観になる
②地に足のついたゴールにする
③何のためのプロジェクトか（Why?）をゴールやコンセプトに込める
・Why？がしっかりしていないと、アレもコレもとなってしまう
④分かり易いゴールにこだわる
ISBN 978-4-532-32399-8
P51～54
D章 Assessment：現状の棚卸しをする
【狙い】
・機能の洗い出しや見積りの材料には、現状の棚卸しが必須
・漏れなくスムーズに業務とシステムを棚卸しするための9つのフォーマットを知る
ISBN 978-4-532-32399-8
P58
1．現状調査の2つの指針
①課題発見型
・変えるべきことをはっきりさせるために行う調査
・プロジェクトとして解決したい課題を明らかにし、解決策を磨いていく
・課題のない業務やシステムを詳細に調査するのは時間のムダなので、メリハリをつけた調査を心がける
②棚卸型
・システム構築の検討材料を集めるための調査
・現状業務とシステムを網羅的に把握しておく点が課題発見型と異なる
ISBN 978-4-532-32399-8
P58～60
2．現状業務とシステムの棚卸しするための9大フォーマット
■業務系フォーマット
①現行業務フロー
・業務の流れを視覚化し、現場担当者とのコミュニケーションを円滑にする
・スイムレーンチャートを作成しておくと、As-IsとTo-Beの比較も用意
②現行アクティビティ一覧
・業務にかかわる情報を網羅的に洗い出すためのフォーマット
■システム系フォーマット
③現行ファンクショナリティ・マトリクス（FM）
・システムの機能をマトリクス形式で整理したもの
・最大のメリットは一覧性で、全体像を見て現行システムのひずみなど問題点を発見できる
④現行システム一覧
・どの範囲をプロジェクト対象とするのか、データがどれだけ分散しているかを検討する
・現場担当者が使っているエクセルやAccessも対象
・どれだけシステムが重複・偏っているかを調べることもできる
⑤現行インターフェース（I/F）
・他のシステムをつなぐI/Fの一覧
・I/FのFrom、To、受け渡しの技術的方法、タイミングなどを網羅的にまとめる
⑥現行全体システム構成図
・パワーポイントなどで機能とその関係性を図にしたもの
・ワークフローと業務・データ・システムを並べ、I/F連携も付加して俯瞰図を作成
⑦現行システムの主要データ
・管理しているデータを整理したもので、DB設計や移行の検討材料
・エンジニアにDB項目一覧を出力してもらっても業務担当者との議論には使えないので、業務担当者が理解できる粒度で表現する
⑧現行コード体系
・主要コード（IDなど）を整理したもの
・社員コード、受注コードなど種類や体系、採番ルールを整理する
・システム上の情報の複雑さを表現することも多いので、ムダがないを確認できる
■共通フォーマット
➈課題一覧
・棚卸の過程で発見した課題を一覧にしたもの
ISBN 978-4-532-32399-8
P62～72
3．棚卸結果を基にシステムを分析する
＜棚卸の結果見えてくる課題で多いもの＞
＋機能連携ができておらず、同じ情報を2重、3重に入力している
＋必要な機能が場当たり的につぎ足しされており、プログラムが複雑
＋設計資料がなく、些細なメンテに莫大な時間と費用がかかる
＋販売と経理で別々の取引コードを使っている
＋セキュリティが考慮されていない
＋レガシーシステムで、サポート期限が迫っている
・システムを作ってもらう側の人にシステム分析は荷が重い
・システム分析にはIT部門やITコンサルに依頼する方が良い
・だが、ここを任せっぱなしは良くない
・自分でやらなくても結果は把握し理解しておくことが肝要
ISBN 978-4-532-32399-8
P72～74
＜#1_まずは全体を把握するの所感＞
「PdMとして企業の骨子となるプロダクトを熟成するために、
どうエンジニアとコミュニケーションをとるか」
を知りたかったのですが、この本は製造業におけるDX導入に苦労しているPM向けの本だと感じました。
ちょっと違ったな・・・と思いながらも、この本が話題なのは、右も左も分からず「DX導入しろ！」と言われている人が日本に多くいるのだな、と感じました。
この本を読みながら感じたのはPdM（プロダクトマネージャー）もPM（プロジェクトマネージャー）も
オーケストラにおける指揮者に似ている
と思いました。
ただPdMはさらに
・オーケストラの楽器が増えている
・会場の場の演出も考える
＝エンターテインメントプロデューサーでもある
という点で大きく異なると思います。
せっかくなので、この違いを意識しながら読み進めていきたいと思います。
この記事が気に入ったらサポートをしてみませんか？