DX推進:「作ってもらう技術」を知る_#7 _作りはじめたら「あとよろしく！」ではない

前回はベンダー選定（PEW）が完全に完了し、決裁も得て、プロトタイプでテストをちゃんとしましょう。
というそれぞれ独立した内容について見ていきました。

今回はからは、いよいよ「作る側」がメインとなるDesignフェーズに入っていきます。
Designまで来たから「作らせる側」はもう安心！というわけでもなさそうです。

文字数：約3,600

参考①：PMの役割の説明

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

参考②：そもそも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

T章 Design〜Depolyment：開発チームの立上げ

【狙い】
・システムを作る側が本格的に参加してくるタイミング
・協力しあえる最強のチームを作るには、作らせる側の姿勢が重要となるので、そのための原則を理解する

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

1．良いチームを作る9原則

原則①ユーザーが参加し続ける
・システム開発チームには、業務担当者が参加しておく

原則②保守をにらむ
・どの組織のどの担当者が保守を担うのか決めておく
・この保守担当者も開発チームに参加してもらう

原則③エキスパートとのつながり
・業務ないしシステムのエキスパートを専任メンバーとしてアサインするのが理想だが、希少なのでトラブル時の相談や成果物レビューなどに参加してもらう

原則④OneTeamにする
・OneTeam創設に向けたポイント
A）請負契約をやめ、フェーズごとに準委任契約にする
B）プロジェクトにとって何が最適かを基準にする

原則⑤WhyやHowをきちんと伝える
・システムをコツコツと作る人は後から参加するので、しっかり意義を伝えておく

原則⑥言葉と進め方は明示的に

原則⑦ストレートに意見を言い合う

原則⑧プロジェクトルームはできれば1つ

原則⑨学び合う
・ITベンダーはシステムのプロとして、有益な知識・知恵を持っているので、教え合うことでチーム全体のスキルを上げていく

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

U章 Design〜Depolyment：キーチャート

【狙い】
・要求事項のすべてをFMで表現するのは現実的ではない
・補足資料としてキーチャートを役割を把握し、7つのフォーマットを利用できるようにする

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

1．キーチャートとは

・FMはバリエーションを表現することが苦手なので、キーチャートと呼ばれる図表が役に立つ
・システム構築に必要なバリエーションを表現し、FMを補完する
・キーチャートとは、FM・FSで記述した要求よりも、もう少し緻密に業務を整理した図表であり
　＋業務担当者が理解できる
　＋設計書やパッケージ設定に直結（エンジニアがそのまま設計に使える）
もの
・業務担当者とエンジニアの能力ギャップを埋める資料

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

2．キーチャートの7選

①ステータスマトリクス
・商談や事務手続きの進捗、製造工程など「各案件がいまどこまで進展したのか？次にどのステップに進むべきか」をシステムで管理することが多い
・エンジニアが画面遷移やステータス変更のチェック機能を設計する際に、ステータスマトリクスを見れば、求められる挙動を理解できる

②ステータス × 操作可否
・①のキーチャートはステータス同士の関係を表現したものに対して、これは商談などの工程ステータスごとに可能な操作を示したもの

③機能 × 利用者権限
・FMは機能の一覧を補助し、FSはその機能を誰まで・どこまで利用できるかを記載することが可能
・しかしFSをセルごとに書いていくと整合が取れないことに気づきにくいので、FSとは別にキーチャートを作ることが多い

④BOM（Bill of Materials：部品表）ごとの管理情報
・それぞれのBOMでどんな情報を管理しているか、変更可否を一覧化する

⑤採算管理における集計対象
・売上や費用など、目的によって集計する単位や情報が異なるので、集計方法を網羅的に整理したもの

⑥承認プロセスのキーチャート

⑦受注チャネルのバリエーションを表現したキーチャート

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

V章 Design〜Depolyment：開発中の関与

【狙い】
・作らせる側にできることは、プロジェクトが安全に進んでいることをチェックすること

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

1．作らせる側の開発中の4つの役割

役割①監理できるプロを任命する
・監理者とは、設計した通りに作られているかを工程ごとにチェックする人
・監理する項目
　A）計画の妥当性
　＋工程に抜け漏れがないか、品質担保に問題はないかなど
　＋ITエンジニアに責任のある項目だが、システム開発のプロに丸投げするのではなく、事前にチェックする
　B）品質担保の方法
　＋システム品質を担保する手法や能力にはかなりの幅があるので、プロジェクトやユーザーの特性を鑑みた方針決定を事前に議論する
　C）進捗と予算消化

役割②課題解決への参加
・要求をエンジニアに伝えた後にも決定すべき課題が日々発生する
・意思決定できる人が参加できるような定例会議の場を設けて新しい課題に迅速に対応することがプロジェクト全体のスピードを高める

役割③使う人目線でのチェック
・BPPの観点で、網羅的にチェックするイメージ
・使う人目線のチェック方法
　A）仕様ウォークスルー
　＋ユーザーを集めて、画面遷移を表現した表を壁に貼り付けて全員でワイガヤを実施する
　B）システムテストのシナリオ
　＋実業務で使えるかどうかのテストなので、ユーザーが作るべき
　C）UAT

役割④ユーザー教育
・「Why：プロジェクトの意義」「How：業務がどのように変わるか」「What：システムがどう変わるか」の3点セットを説明する

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

W章 Design〜Depolyment：データ移行

【狙い】
・データ移行はすべてエンジニアに任せられない作業も多いので、作業量が大きくなること理解しておく

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

1．データ移行に必要な3種類の知識

①現行システムの知識
②新システムの知識
③業務知識
・3つの知識を持った人はまずいない。だからこそデータ移行は難航する

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

2．データ移行を進めるうえで、作らせる人が意識するポイント

ポイント①捨てるものを決める
・FMの優先順位付けの際に*3つの機能に分類したように、移行するデータも以下の4種類に分類する
　1、稼働時点で新システムへ移行するデータ
　2、稼働後に期間をおいて移行するデータ
　3、システム外で閲覧可能な状態で保管するデータ
　4、破棄するデータ

ポイント②マッピングがキモ
・マッピングとは「新システムのあるデータは旧システムのどのデータから持ってくるか」を一つひとつ紐づけする地道な作業

ポイント③移行ファシリテータがハブとなる
・3種類の知識を持った人はどうせいないので、それぞれの知識を持った人から情報を集めて整理することが役割

*FMに含まれる3つの機能
　1、「効果がある」＝ビジネスベネフィットが高い
　2、「簡単に作れる」＝技術的容易性が高い
　3、「簡単に使いこなせる」＝組織受入態勢が高い

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

＜#7 _作りはじめたら「あとよろしく！」ではないの所感＞

T章～W章は一連の流れになっているので、読みやすかったです。
PMの力量が試されるのって本当はここからな気がします。

要求をいくら丁寧に時間をかけて出し尽くしても、いざ開発してテストすると絶対変更が生じます。

その際に、関係者および意思決定者とすぐにコミュニケーションを図り、迅速な舵キリをするのがPMです。

ただこのフェーズのPMの役割を説明する本や記事はたくさんあるので、ここではこのくらいのボリュームでぴったりと思います。

いよいよ次が最後です。結局最後まで読み切そうです。

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