DX推進:「作ってもらう技術」を知る_#8 _最後の大詰めと効果測定を忘れずに！
前回からいよいよ「作る人」がかなりの頻度で登場してきました。
でも「作らせる側」の登場頻度もほぼ一緒！？
つまり、「作る」「作らせる」という境はあってないようなものです。
これ結構重要だと思いました。
今回で最後となりました。
最初はPdMとエンジニアのコミュニケーション手法を学ぶつもりで読み始めたこの本。
最初の印象はちょっと違うかも？でしたが、PdMも知って損のない内容ばかりだったので最後まで読み切れました！
文字数：約4,000
参考①：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
X章 Rollout：いよいよ新システムの稼働
【狙い】
・いよいよ本番稼働
・狙った通りの成果を上げているかをチェックし、対策していく方法を学ぶ
ISBN 978-4-532-32399-8
P348
1．2つのシステムを並行稼働
・システム本稼働までに段階を踏んで多くのテストを行うが、その最後の仕上げとして、新旧の2つのシステムを並行稼働する期間を作る
・並行稼働によって、業務担当者が新しい業務ルールやシステム操作について勘違いしているケースを発見できる
・2つのシステムを並行稼働するので、業務の手間は2倍になるので、「現場は業務負荷に耐えることができるか？」「並行稼働なしで本番を迎えて問題ないか」など天秤にかけて、並行稼働の実施可否を決定する
ISBN 978-4-532-32399-8
P348～P349
2．業務とシステムの切り替えは最大の山場
・並行稼働は、切替スケジュールを綿密に立てる必要がある
・大規模プロジェクトには制約が多く、膨大なタスクに依存関係があるため「この作業が終わってからでないとできない」など考慮が必要
・データ移行と同様に、制約や切替順序をすべて正確に把握している人はいないので、切替ファシリテータを設けると良い
ISBN 978-4-532-32399-8
P351～P352
3．本番稼働直後のフォロー体制
・本番稼働直後にはトラブルが付き物になるので、対策を取っておく必要がある
①ヘルプデスクの設置
・問い合わせに対する対応はプロジェクトに関わってきたメンバーにしかできない
・システムが完成してすぐにメンバーを解散するのではなく、システムと業務が安定するまでプロジェクトメンバーの一部を残しておく
②エスカレーションルート
・ケースによって相談すべき相手や意思決定のレベルが変わってくる
・報告・対応プロセスを予め決めておく
③コンティンジェンシープラン
・「バグが多く業務ができない」「アクセスが集中しシステムが停止した」など大きなトラブルで計画がうまくいかないときの計画
・コンティンジェンシープランとして旧システムにすぐに戻せるような計画も立てておく
ISBN 978-4-532-32399-8
P353～P356
4．安定稼働後に「作らせる人」がやるべきこと
・安定稼働を成し遂げると、ここで力尽きることが多い
・作らせる側はこの後が重要で、システム稼働は手段なので、目的を達成しているか効果を確認する必要がある
・安定稼働後には現場で実際に使っている現場を必ず見る事が重要
ISBN 978-4-532-32399-8
P353～P356
Y章 【補足】ベンチャーでのシステム構築
【狙い】
・既存業務・システムがある場合と新規事業やベンチャーで業務とシステムを1から作る場合では進め方が異なる
・業務・システムを1から作る場合のコツについて理解する
ISBN 978-4-532-32399-8
P361
1．ビジネスや商品が揺れ動くなかでのシステム開発
・現状何もない状態からのスタートの場合、不確実性が高いプロジェクトとなる
・システムを作りながら相当な変更が必要になり、作って初めて本当に欲しかったものが分かってくる
ポイント①最初にFMをしっかり作る
・先が見通しにくくても、最初に全体像を書くことは必須
・いまは存在しない業務を支えるシステムなので、全部作る前提のFMになる（何がイレギュラーかも分からない）
ポイント②ステージは小さく区切る（スプリント）
・作ってみないと分からないので、細かく作る
ポイント③スプリントの分け方が重要
・意図的に着手順を決めないと、なんとなく作り易いところからになってしまう
例1）全体への影響が大きく真っ先に検討すべき機能から作る
例2）2週間単位で開発が終わる単位にする
例3）業務目線で価値を検証できる最小単位（MVP）で作る
ポイント④同時並行でスプリントする工夫
・スプリントの切り分けで、スプリント間の連携が複雑にならない切り分け方に注意する
・スプリントで作る機能間のI/F機能を重視する
ポイント⑤期限や品質を守るためのマネジメントは大切
・アジャイルは「意欲に満ちた優秀なエンジニアを集めたら、自主性に任せた方がうまくいく」という思想的背景があり、大規模プロジェクトになるとチーム任せになり過ぎて、品質が低かったりスケジュールがグダグダになりやすい
・新規事業に対して、細かいスプリントを切ってアジャイルで進める場合にも品質と進捗はきちんと管理しておいた方が良い
ISBN 978-4-532-32399-8
P361～P369
2．ウォータフォール、アジャイル、その中間
■ウォータフォール
・要求定義→要件定義→基本設計書→詳細設計書→プログラム→単体テスト→結合テスト・・・と1工程ずつ成果物を作っていく開発方法
・前工程の成果物を、次工程でより具体的かつ詳細にしていく着実な方法
・一方で前工程にミスがあると手戻りが大きくなる
・最大の弱点は、ビジネス環境の変化などで、最初に決めたことが変化してしまうこと
＜向いているプロジェクト＞
要求 ：固定的
規模 ：大規模
柔軟性 ：ミッションクリティカル
管理 ：ガチガチな管理
■アジャイル
・機能を小さく区切り、機能ごとに設計→開発→テスト→ユーザーレビューを高速で繰り返す手法
・最低限使える機能が少しずつ出来上がっていく
・弱点は全体コントロールが難しい
・全体が緻密に連携するシステムはアジャイル向きではない
＜向いているプロジェクト＞
要求 ：変動的
規模 ：小規模
柔軟性 ：トライ＆エラー
管理 ：チームの自主性を重視
■中間（Cambridge RAD）
・全体の流れはウォータフォールと同じだが、工程にアジャイルと共通する精神が含まれている
・「すべてを一度に作るのではなく、段階的に稼働する」「BPPを実施し課題を先出しする」「プロジェクトを通じてメンバーが成長することを重視」などが含まれている
ISBN 978-4-532-32399-8
P370～P372
Z章 【補足】FMをシステム構築以外にも応用する
【狙い】
・活用場面の5つの例を見て、他にも転用できるようにする
ISBN 978-4-532-32399-8
P373
1．FM応用事例 5選
①組織機能の実現範囲を決める
・今後強化すべき組織機能をFMと同様のプロセスで検討する
・将来の全体像を示すことができ、どこに向かうべきか、何に価値を置いているかなど認識を合わせることができるので、優先順位の決定プロセスを共有できる
②商品開発や研究テーマの優先度決定
・新商品開発においても、盛り込みたい機能が膨れ上がりがちなので、全体像を示し、優先度の決定とそのプロセスを振り返ることが重要
③WEBサイト掲載コンテンツの決定
・掲載したいコンテンツは多くなりがちだが、サイトとして一貫性がないとメッセージが伝わらないし、価値のないサイトになってしまう
・掲載したコンテンツを洗い出し、FMのプロセスに沿って優先順位をつけることで全体としてちぐはぐになっていないかチェックできる
④データウェアハウスに収集するデータを決める
・何の目的で、どんなアクションに用いるのかを記入していき、「そのデータを集めるのは簡単か≒技術的容易性」「データを参照したうえで有効なアクションが取れるか≒ビジネスベネフィット」など優先順位を決める
⑤データの移行範囲を決める
・W章で説明した通り、全体を一覧化し優先順位を決めるプロセスはFMと同じ
ISBN 978-4-532-32399-8
P373～P378
＜#8 _最後の大詰めと効果測定を忘れずに！所感＞
400ページ弱ある分厚い本でしたが、あっという間に読み切ることができました。
最後には、著者からの熱いメッセージなどもあり手にとって是非読んでもらいたいです。
この本で学んだ手法を知っているか知っていないかでDXの成功確率は相当変わると思います。
まずは一度サラッと読んでみて、全体の流れを把握し、必要な場面ですぐに見ることができれば良いと思います。
丸覚えするモノでもありませんし、すべていっぺんに実践すべきことでもないと思います。
要素を把握し、少しずつ実践していくだけでもプロジェクトの進め方はだいぶと変わってくると思います。
非常に読みやすく、良い本でした。
マガジン作りました
この記事が気に入ったらサポートをしてみませんか？