DX推進:「作ってもらう技術」を知る_#6 _ROIを精査する＆細かくテストする
この本の醍醐味とは作らせる側が責任を持つ「要求定義」
と気づき、前回からその後続フローに入っています。
前回は要求定義をしっかり実施したあとに、いざシステム構築を発注するベンダー選定でした。
ベンダー選定するときにも、要求定義でしっかり作ったFMが大活躍でした。
今回は最終選定できたベンダーといよいよシステム構築について議論を開始していきます。
フェーズとしては、まだPEWです。
文字数：約4,500
参考①：PMの役割の説明
参考②：そもそもDXとは
参考図書
1．全体フロー（今回は⑤⑥、前回は⑤）
①Concept Framing（ゴール明確化）（C章）
②Assessment（現状調査）（D章）
③Business Model（構造策定）（E章）
④Scope（要求定義）（F～M章）
⑤PEW（製品選定/ベンダー選定）（N～R章）
⑥BPP（プロトタイプ検証）（S章）
⑦Design〜Depolyment（開発）（T～W章）
⑧Rollout（稼働）（X章）
ISBN 978-4-532-32399-8
P31〜38
Q章 PEW：稼働までの計画を立てる
【狙い】
・ベンダーからの提案を受け、稼働までの全体スケジュールを立案する
・全体スケジュールは、システム構築以外の様々な要素を加味する必要がある
ISBN 978-4-532-32399-8
P250
1．ベンダーから提案されたスケジュールを鵜呑みにしない
・プロジェクトの目的はシステムを作ることでなく、業務が良くなり成果を上げること
・通常ベンダーから提示するスケジュールをそのまま全体スケジュールとするわけにはいかない
・Q章では、プロジェクトの全体スケジュールの作り方に焦点を当てる。
「発注側で精査する方法」→「プロジェクト外とのコミュニケーションを計画する方法」について見ていく
ISBN 978-4-532-32399-8
P250～P252
2．システム構築スケジュールを精査する6つの観点
・ベンダーはプロジェクトをしっかり進める能力がありそうか？を見極める際にも役立つ
①MUST期限が守られているか
・議論をしっかりし、本当に動かせないMUSTな期限と、調整すれば動かせる期限が存在している
②業務繁忙期とシステム構築のピークは重なっていないか
・実際に業務をやっている人しか検証できないことも多くあるので、業務が忙しい時期に確認を実施するとプロジェクトが停滞することになり得る
・またシステム構築では、上流の要求の洗い出しと下流の教育や稼働の前後で担当者の負荷は上がる
・業務の閑散期を踏まえたスケジュールにする
③工程ごとのゴールは明確か
・テストの考え方はベンダー各社で異なることが多いので「ベンダーが請負責任を負うテスト」「共同で実施すべきテスト」「発注者側がすべきテスト」を明確にしておく
・進めていくと「ベンダーがやることと思っていました」というようなケースも増えてくるので、最初のうちに「どこまでやったら次の工程に進めるのか」という工程ごとのゴールを全員で確認し、文章に残しておく
④成果物をチェックするマイルストーンはあるか
・各工程の途中で、作りかけの成果物を見せてもらう日を決めておく
・実力が怪しいベンダーほど、マイルストーンを設けてチェックすることを嫌がるので、強行し確認を実施する
⑤各領域の整合が取れていない
・チームごとに詳細スケジュールを作成し合体させて全体スケジュールとすると、矛盾を含むケースがあるので計画段階で行き違いを防ぐ
⑥各フェーズの期間バランスを適当か
・スクラッチ開発の場合は設計：開発：テスト＝1：1：1になるのが一般的
・パッケージ開発では、スクラッチと比べてテストの割合が大きくなる
ISBN 978-4-532-32399-8
P252～P257
3．プロジェクト外とのコミュニケーションは疎かにしない
・DXに限らず、業務改革やシステム構築では、関係者に必要性を理解してもらい協力してもらうことが必須
・とは言え、いざプロジェクトとなると目の前の仕事に追われて外部とのコミュニケーションは疎かにしがち
・大きな変革を伴うプロジェクトの場合、趣旨を1度説明しただけでは全く不足しており、進展に応じて違った切り口でコミュニケーションを重ねる
・コミュニケーションを重ねることで、「単に出来上がったものを押し付ける」のではなく、「一緒に作るメンバー」にすることで大きな効果を狙うことができる
・だからこそコミュニケーション計画が重要
・コミュニケーション計画は「誰に」「いつ」「なにを」伝えるのか、その結果何を協力してもらうのかを含める
ISBN 978-4-532-32399-8
P258～P261
参考：テストの定義（ケンブリッジ版）
①単体テスト（UT：Unit Test）
②結合テスト：内部結合テスト（IT①：Integration Test I）
③結合テスト：外部結合テスト（IT②：Integration Test II）
④性能・運用テスト
・非機能要求に対するテスト
⑤システムテスト（ST：System Test）
・システムがほぼできた段階で通しで行うテスト
⑥ユーザー受入テスト（UAT：User Acceptance Test）
・依頼通りの内容かを発注者が確認するテスト
ISBN 978-4-532-32399-8
P262～P265
R章 PEW：プロジェクトの投資決裁を得る
【狙い】
・決して小さくない投資額に正当性があるのかを会社全体で意思決定する
ISBN 978-4-532-32399-8
P266
1．費用対効果分析は数回実施する
・投資して儲かるのか、価値があるのかをシミュレーションする
・費用対効果分析を実施すべきポイントは
1回目：プロジェクト計画が固まった時点（E章）
2回目：ベンダー選定が終わり、投資の最終決定をする段階（R章）
3回目：業務が安定したタイミング（X章→後述）
ISBN 978-4-532-32399-8
P266～P268
2．ベンダーの見積範囲外が落とし穴
・この段階でのベンダーから見積もりは精緻化されてはいるが、システム構築にかかわるコストをベンダーがすべて見積対象にしているわけではない
・ベンダーがやってくれない作業は意外と多い
・どこまで見積りに含まれているのかは、ある程度ITプロジェクトの知見がないとチェックできないので、IT部門にフォローしてもらった方がよい
ISBN 978-4-532-32399-8
P270～P272
3．黒字にならないシステムの訴求方法
・ガートナー社がIT投資を3つに分類することを提唱
①戦略投資：変革
＋全く新しい市場やビジネスモデルの創造
②ROI投資：成長
＋既存事業の継続・強化による収益増
③事業継続投資：運営
＋売上げに直接貢献しないが、事業継続上、法令順守やコミュニケーションなどで必要
・黒字化しないプロジェクトは「事業投資継続投資」に該当する。この場合の投資決裁を通すためのポイント
ポイント①：ビジョン・理念を伝える
＋会社のビジョンや経営者が謳っている理念に訴えるのが良い
ポイント②：他社劣後を訴える
ポイント③：事業継続の土台であることを理解してもらう
ISBN 978-4-532-32399-8
P274～P276
S章 BPP：課題を先出しする
【狙い】
・後工程で課題が見つかった方が、修正に手間がかかることの理解
・なるべく早いタイミングで課題を見つけるための仕掛けが必要
ISBN 978-4-532-32399-8
P280
1．本格的に作る前に、試す
・システムを「作らせる側」と「作る側」が共同で行う工程がBusiness Process Prototyping
・プロトタイプで業務が流れるか確認し、課題を出すための通し稽古
・BPPを実施しないと、担当者が業務やシステムに触れるのはUATになる＝もう完成してしまった後になる
・効率よくシステムを開発するためには、上流で埋め込まれたバグを極力早いタイミングで見つけ出すことが重要
ISBN 978-4-532-32399-8
P280～P283
2．BPPの7つのステップ
STEP①対象シナリオの選定
・プロトタイピングは手間のかかる作業でもあるので、検証する業務を選ぶ
＜通常BPPで対象とする業務＞
A）王道の業務
＋要求した通りの機能が提供されないと業務・ビジネスが成り立たない領域
B）現在と大きく変わる業務
＋BPPの目的は課題を先取りすることなので、このような領域があれば真っ先にシナリオに含める
C）要求通りにシステム機能を提供できそうな業務
＋パッケージソフトが前提としている業務と自社の業務に大きなギャップがありそうな領域
STEP②シナリオの準備
・すでに現在の業務フローに対して将来のあるべき業務フローがあればそれを流用すれば良い
STEP③確認ポイントの明確化
STEP④プロトタイプを用意する
・選定したパッケージの特性によってプロトタイプの作成工数は異なるので、ITベンダーに準備負荷をかけすぎないように進める
STEP⑤データの準備
STEP⑥プロトタイプセッションの実施
・セッションをスムーズに進めるために役割を予め決めておく
A）レビュア：業務に詳しい人。業務やシステムへの懸念点を出す
B）ファシリテータ：全体の進行とシナリオの説明
C）スクライバー：懸念や後で議論すべきテーマを記録しておく
D）システム操作者：プロトタイプを操作する人
＜BPPに参加する作らせる人の心構え＞
A）機能単体よりもプロセス全体の確認を優先する
B）見た目よりもやりたいことができるかに着文句
C）動かないことにいちいち目くじらを立てない
D）課題が見つかったら喜ぶ
STEP⑦課題を潰す
ISBN 978-4-532-32399-8
P283～P298
＜#6 _ROIを精査する＆細かくテストするの所感＞
今回は
Q章：稼働までの計画を立てる
R章：投資決裁を得る
S章：課題を先出しする
の3章を一気に見ていきましたが、それぞれが独立して重要な項目でした。
あとで読み返してみると、つながりを見つけようとすると混乱するので、そのまま各章を素直に読むと良い内容でした。
決裁資料の作成方法まで指南しているので、ここでコケてしまうケースが結構あるんでしょうね。
「あなたが言い出したのに・・・」って経験、結構ありますね。
ここまでの要求定義、ベンダー選定、スケジュール策定は結構時間がかかるので、経営者も指示したことを忘れてしまう可能性があると思います。
なので、
決裁という形でなく、細かく報告する
のが絶対良いと思います。
真面目にコツコツと一生懸命考えたのに、決裁を得られなければ水の泡ですので。
この記事が気に入ったらサポートをしてみませんか？