DX推進:「作ってもらう技術」を知る_#4_作らせる側と作る側のバトン渡し（PdMも必要な知識）
PdMが「どうやってエンジニアとコミュニケーションを取るべきか」について学習するつもりでしたが、今回の参考図書はちょっと目的と違いました。
ただ、とても読みやすくDXを推進しているPM向けのテキストのようなイメージです。
読み進めてみると意外と知らないことも多く、むしろ色々勉強しているところです。
この本の醍醐味とは作らせる側が責任を持つ「要求定義」
と気づき前回は要求定義FM作成の5ステップを一気に見ました。
以下は参考として載せておきます。ここから読み始めた方は参考②は事前に目を通してもらえると嬉しいです
文字数：約4,200
参考①：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
L章 要求定義：FM（Functionality Matrix）がシステム構築を成功に導く
【狙い】
・FMを作るプロセスと成果物は以降の工程をスムーズに進めるための秘訣が詰まっている
・FMの意義を理解し、大事なポイントを端折ったり、誤ったアレンジをしないようにする
ISBN 978-4-532-32399-8
P170
1．システム構築の失敗はFMで防ぐ
・失敗する事例として多いのが以下のように要求定義にまつわるもの
例1）関係者が「あれもこれも」となり収拾がつかなくなる
例2）必要性の薄い機能まで作り、予算オーバー
例3）作ると決めたが、あとで変更が生じる
ISBN 978-4-532-32399-8
P170
2．FM作成プロセスとFMそのものの効果
■FM作成プロセスの効果
①透明性が納得を生む
・FMを作らないと、どの機能を作るのかがなんとなく決まったり、声の大きい人の意見ばかりが反映され、偏りが生じる
・FMは意思決定までのプロセスを明確にし、検討結果に対する納得や信頼感につながる
②関係者を巻き込んで作る
・関係者をこの段階から巻き込んでおくことで、稼働後のシステムが狙い通りの効果を上げるかに大きく関わる
・FMを作らないと、関係者が多い＝意見の収拾がつかなる→避ける、関係者の協力が得られなくなるという悪循環になっている
③網羅性の担保
・すべての候補を検討の俎上に載せることで、抜け漏れを防ぐことができる
④全社視点、プロジェクトゴール視点
・FMによる優先順位決定は、個人の嗜好（ノイズ）を除去できる
・結果個別最適でなく、全体最適になる
⑤ユーザー vs エンジニアの構図を避ける
・エンジニアは予算と納期という制約があるにもかかわらず、それを無視した要求によるムダな押し問答が発生しない
⑥効果とコストのバランス
・FMの優先順位付けの議論で、機能ごとに効果とコストを考慮するので、必然的に効果とコストのバランスをとった意思決定へと導かれる
⑦組織受入態勢を忘れない
・システム構築のコスト ＝ 「構築するためのコスト」と考えがちだがそれに加えて「作ったあとの使えるようにするまでのコスト」にも目を転じることができる
■FMの効果
①Scopeが明確になる
・Scopeを決定すれば、それ以降はいつもFMを見ながら計画を立てることになる
・最初の稼働に向けて集中すべき時期に、余計なことに時間を割いていないかをチェックするのもPMの役割
②やらないことが書いてある
・この機能は「諦めてください」とは言いにくいが、FMの色分けであればそれを伝えることができる
・どうしてもあきらめきれない場合は、予算・納期を変更するなど冷静な議論をすることもできる
③一覧性
・ひと目で見ることで、考えたり把握できるようになる
④作成過程が後から見える
・システム構築とその本格稼働には時間がかかるので、後から決定プロセスを振り返ることで、納得して利用してもらうことにつながる
ISBN 978-4-532-32399-8
P170~179
3．FMは要求定義以外でも使える
・FMの最大の用途は「システムを作る人に開発を依頼すること」
・FMはWhatを明確に表現したものなので、用途は要求定義だけに収まらない
①設計・開発フェーズ
・プロジェクトの進行とともに、Scopeは変わっていくもの
・変更に合わせてFMを逐次更新することで、合意形成をスムーズにできる
②導入フェーズ
・ユーザーへの説明会の際にもFMは役に立つ
・納得して使ってもらうために、FMの作成プロセスを共有する
③稼働後
・先送りにしていた機能について、継続的な更新活動もFMがベースなっていく
ISBN 978-4-532-32399-8
P179～181
M章 要求定義：機能以外の要求を定義する
【狙い】
・非機能要求とアーキテクチャの2つを議論する必要がある
・どちらも専門家であるITエンジニアを中心に検討するが、「作らせる側」が関与する部分もあることを知る
ISBN 978-4-532-32399-8
P183
1．機能以外に決めるべき2つのこと
・非機能要求とは、セキュリティレベルなども含めた「システム全体の性能」のようなもの
・アーキテクチャとは、システム全体の性能を長期的に実現するためにどんな構造をどんな工法で作るかを決める
・非機能要求とアーキテクチャは知識を持ったプロがリードする
ISBN 978-4-532-32399-8
P170
2．非機能要求の6つの切り口
・JUASによる「非機能要求仕様定義ガイドライン」が有名だが、システムを作らせる側が最低限知っておくべきこととして6つの大分類を説明する
①可用性（どれくらい使えるか）
・システムがいつ使えるのか≒いつ、どのくらい止まるのかを意味する
・高い可用性を目指すほど、ハードウェアが壊れたりしたときのバックアップや念入りなテストが必要となり、コストも大きくなる
＜作らせる側がエンジニアに伝えるべきこと＞
＋トラブルによる停止はどの程度許容できるか
＋夜間や長期休暇など、計画的に停止できるのはいつか
②性能/拡張性
・プログラム実行時にどのくらいの時間がかかるのか、同時に何人のユーザーが利用できるのか、といったボリュームに関する要求
＜作らせる側がエンジニアに伝えるべきこと＞
＋どれくらいの応答スピードを求めるのか
＋どれくらいのビジネス規模なのか
＋数年以内にどれくらい拡大する可能性があるか
③運用/保守性
・保守は採用するアーキテクチャやエンジニアレベルによって変わってくる
＜作らせる側がエンジニアに伝えるべきこと＞
・長く使えるように作ってください、としか言えない
④移行性
・既存システムからどのデータを持ってくるかを決める
＜作らせる側がエンジニアに伝えるべきこと＞
・機能と同じく優先度をつけて伝える（W章で後述）
⑤セキュリティ
・この項目も③運用/保守と同じく高度な専門スキルが必要でプロに任せるしかないが、重要
⑥システム環境/エコロジー
・ハードウェア（データセンタなど）がどのような環境に置かれ、耐震や湿度対策ができているか、CO2削減は考慮しているかなど
ISBN 978-4-532-32399-8
P184～187
3．作らせる側の心構え
・非機能要求は、他のシステムの稼働時期やインフラ構成の制約を受けることもあり、他システムとの関係も考慮しなければならない
・ここは全体システムを俯瞰しているIT部門やそれに類する外部のプロにアドバイスをもらう必要がある
・業務を担う者としてのこれらの意思決定に関わる心構え
①ビジネスの文脈を伝える
・ここで決まったことは一度意思決定すると、ずっと引きずることになるので、なるべく変更に柔軟にあって欲しい
・今後どれだけ利用者が増え、将来的にどんな事業を想定しているのかをしっかり理解し伝える
②許容できる下限を伝える
・非機能要求は一定のラインを超えると急に費用が膨らむ（コストの壁）
・コストの壁の高さの分岐点は技術の進歩によって変わるため、システムに詳しい人でないと分からない
・作らせる側は過剰な望みを伝えるのではなく、下限から決めていくことが重要
③トレードオフを判断する
・稼働率と投資額はトレードオフの関係にある
・トレードオフはIT部門では決めることができないので意思決定していく必要がある
※SaaSの台頭に伴い、SaaSを利用することで非機能要件を詳細に検討する必要が無くなってきているので、利用する価値はある
ISBN 978-4-532-32399-8
P188～192
4．システムアーキテクチャの3つのポイント
①パッケージかカスタマイズか
②オンプレかクラウドか
③複数システム間の連携
・アーキテクチャはエンジニアの腕がものいう検討内容であり、長年にわたってコストや品質に影響を及ぼすので、しっかりしたITエンジニアに依頼すべき
ISBN 978-4-532-32399-8
P192～195
＜所感＞
今回のセクションはPdMでも知っておかないといけない重要な項目です！
この本の面白さは読み進めるほどわかってくる。噛めば噛むほどうまくなる本ですね。
最初の印象からガラッと変わって、常に持っておきたい本になってきました。
noteに書くと、
走りよみせず、詳細を見ることができる
一度書き出すと最後まで書きたくなる
という気持ちが生まれて良いですね。
noteを始めたきっかけも、
単に本を読む（インプット）だけでなく、
書いて（アウトプット）して記憶への定着を図る
ことだったので、その目的による効果を実感しています！
ちなみに、読書履歴をNotionにまとめているので、後で思い出したいときの検索性も抜群に向上してきています
この記事が気に入ったらサポートをしてみませんか？