DX推進:「作ってもらう技術」を知る_#3_要求定義はクイックに確実に
もともとPdMが「どうやってエンジニアとコミュニケーションを取るべきか」について学習するつもりで読み始めた本ですが、前回からいよいよ醍醐味が見えてきました。
これが見えてくるとめちゃくちゃ面白い本です。
その醍醐味とは作らせる側が責任を持つ「要求定義」
ここからしばらく要求定義の作り方が続きますが、これを理解することが本書の意義です。
参考①：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
4．FM作成の5つのステップ（今回①～⑤まで一気に）
①機能の洗い出し（G章）
・欲しい機能をひたすら洗い出す
②FM作成（H章）
・欲しい機能はFMのフォーマットにまとめ、グループ分けをしておく
③機能詳細の記述（I章）
・具体的などんな機能かの説明を入れる
④優先順位基準の決定（J章）
・必須機能、あると良い機能を分け優先順位をつける
⑤優先順位の決定（K章）
・FMに優先順位が分かるように色分けなどしておく
ISBN 978-4-532-32399-8
P103～105
G章 要求定義：STEP1:機能を洗い出す7つの方法
【狙い】
・徹底的に洗い出すことに集中する
・7つの方法を事例も交えて理解する
ISBN 978-4-532-32399-8
P108
1．発散→収束モデル
・実現可能性など考えず、とにかく数を出すことに専念する（発散）
・網羅的に機能を洗い出すことは難しく、洗い出しに集中する必要がある
・出てきたアイデアを否定するのではなく、受け入れて、次の収束フェーズでしっかり選別する
ISBN 978-4-532-32399-8
P109～110
2．機能を洗い出す7つの方法
■基本編
①現行システムから
・現行システムで業務は曲がりなりにも回っているので、現行システムを一通り見渡す
・現行システムを見渡すうえで注意すること
a）細かすぎる記述は不要
b）使われていない機能もまずは出し切る
c）いま使っている＝必要な機能とは限らない
d）現行システムの詳細を語れる人がいないときは、まず触って理解
②標準テンプレートを使う
・ITコンサルを雇うのであれば、機能洗出しのフォーマットがないか確認
・自社で行うのであればIT部門が持っていないか確認する
・テンプレートを使う方が圧倒的に効率的
③業務フローから機能を拾う
・業務の流れに沿ってシステム機能を洗い出す
・業務フローとしてはスイムレーンチャートがあると良い
④ソリューションや入門書で抜け漏れをチェック
・一番手っ取り早い方法はパッケージソフトの機能を一覧を参照すること
ただし、情報量が多いのでまともに見ると、何が必要か分からなくなる
・将来業務フローを作成し、それをベースに必要な機能を洗い出すと良い
■応用編
⑤ビジネスの文脈を捉え、将来への布石を打つ
・近視眼的になりがちだが、ビジネス全体が目指す方向性を見極めて将来必要となる機能まで目を転じる
・将来的な機能なので優先度は低くなってしまうかもしれないが出し切ることが重要
⑥新規ビジネスモデルから導き出す
・全く新しい事業をゼロから創り出すようなケースでは、業務フローよりもざっくりした新事業の構想図をベースに洗い出すこともある
⑦シーズ × シーンマトリクスを使う
・新技術（シーズ）と自社ビジネスの様々な局面（シーン）を無理やり掛け合わせる方法
・特に、無難な現状踏襲機能の話ばかりになってきた際に有効で、無理やり発散させる
ISBN 978-4-532-32399-8
P110～123
H章 要求定義：STEP2:要求をFMにまとめる
【狙い】
・洗出した要求を俯瞰して見えるようにする
・ただ並べるだけでは役に立たないので、FMのまとめ方/分割の視点を知る
ISBN 978-4-532-32399-8
P123
1．FMにまとめる基本ステップ
①機能をセルに整理する
・機能の重複や漠然とした機能もあるので、分かり易いタイトルをつけてまとめていく
・機能一つひとつをセルと呼び、このセルを厳密にシステム画面一つまでに落とし込む必要はない
②セルをグループ分けする
・機能に対してカテゴリーを振ってグループ分けする
③セルとグループを分ける
・業務の流れあるいは重要度の高い順に並べる
＜セル作成のコツ＞
Ａ）実装が難しいそうな機能は分ける
Ｂ）色々な実現方法がありそうな機能は分ける
・手動/半自動/自動など分けれそうなものは分けておく
Ｃ）利用シーンが複数ある機能は分ける
Ｄ）セルの粒の大きさはあえて揃えない
ISBN 978-4-532-32399-8
P123～131
Ｉ章 要求定義：STEP3:詳細をFSに表現する
【狙い】
・FMの機能ごとに「どんな機能か」という機能詳細（Funciton Specification）を記載する
・あら過ぎず・書き過ぎずの塩梅が必要
ISBN 978-4-532-32399-8
P134
1．セルの説明を具体的に書く
・セルごとに「どんな処理を行うのか」「どんな情報を扱うのか」を書く
・FSの利用シーン
シーン①：プロジェクト内の認識合わせ
＋要不要の判断の際に、機能に対する認識を揃えておくことが重要
シーン②：ITベンダーへ渡すRFP（Request for Proposal）
＋ITベンダーへの提案依頼書
＋ITベンダーに都合よく解釈されないため
シーン③：パッケージのFit&Gap
＋FSの実現可能性評価のフェーズが後であるので、その際に齟齬を生じさせない
ISBN 978-4-532-32399-8
P134～136
2．FSに書くこと、書かないこと
■書くこと
①実現したいこと
・素直に機能を実現してできることを書く
②扱う情報
・扱う情報をざっとでも書けば、ITエンジニアは必要な処理まで推測できることが多い
・詳細まで書くとキリがないので、メインで使う情報だけで十分
③他の機能との関連
④バリエーションやイレギュラー
・網羅的に抽出するのは時間がかかるので、ざっと把握できる範囲で記載しておく
■書かないこと
①実装方法
②画面イメージ
・この段階では、画面イメージまで作るのは無駄になる
ISBN 978-4-532-32399-8
P137～140
J章 要求定義：STEP4:優先順位の基準を決める
【狙い】
・すべての要求を作ることはできない
・本当に必要な要求を見極め、納得と合意を得られるようにする
ISBN 978-4-532-32399-8
P145
1．絶対に全部つくらない
要求を絞り込まない弊害
①予算超過、納期オーバー
②難易度を上げる
③使われない機能ができる
ISBN 978-4-532-32399-8
P145～146
2．3つの基準を3段階評価
■3つの基準
基準①：ビジネスベネフィット
・この機能がどれほどビジネスに価値があるかを示す
基準②：組織受入態勢
・この機能を使いこなすのどれくらい簡単かを示す
・難しい場合がLow、簡単な場合はHigh
・作ったは良いが、使われない機能になることを防ぐ
・「使うのが難しい」「業務を大きく変えなければならない」「他部門との調整が必要」「データを用意できない」など難しくするハードルを意識する
基準③：技術的容易性
・作るのが簡単か難しいかを示す
・技術的容易性はプロジェクトが進むと変わってくる
■3段階評価
・評価はH/M/L （High/Medium/Low）
・評価を細かくし過ぎると時間ばかりかかる
ISBN 978-4-532-32399-8
P147～157
K章 要求定義：STEP5:作る機能を決める
【狙い】
・要求のレーティングから作る順・範囲を決める
・時間をかけず、判断理由も明らかなフェーズの分け方を知る
ISBN 978-4-532-32399-8
P160
1．良いレーティングの機能を真っ先に作る
・「効果がある」＝ビジネスベネフィットが高い
「簡単に作れる」＝技術的容易性が高い
「簡単に使いこなせる」＝組織受入態勢が高い
・要するに「効果があり、簡単に作れ、すぐに使いこなせる機能を真っ先に作り、それよりも優先度が低いものは後から作る。もっと優先順位が低いものは作らない」と決めていく
ISBN 978-4-532-32399-8
P160～161
2．レーティング結果から機械的にフェーズを分ける
・レーティングがH/H/HやL/L/Lであればすぐにジャッジできる
・ただM/H/Lなど中途半端なものは判断に悩み、時間がかかりがち
※H:3、M:2、L:1などスコア化して、総和に対してしきい値を持つのもありかも（note作者追記）
・機械的に判断することで、現場の意見に引っ張られ過ぎず、現状踏襲を防ぐメリットもある
ISBN 978-4-532-32399-8
P161～164
3．セル同士の関係と総ボリュームを調整する
・機械的な判断はスピーディーであるが二つの落とし穴があるのでこのタイミングでチェックしておく
①セル同士の関係がちぐはぐ
・例えば「情報登録は実施」、「情報参照は次回」であれば問題ないが、これが逆だと機能として成立しない
・機能Ａがなければ、機能Ｂは作っても意味がない、という状態になっていないかチェックする
②どう見ても予算や納期が収まらない
・結局あれもこれもになっていないか再度チェック
ISBN 978-4-532-32399-8
P164～165
＜#3_要求定義はクイックに確実に、の所感＞
ページ数にして60ページくらいを一気にまとめました。
この本はかなり読みやすい（だから人気みたい）ので、エッセンス抽出がかなり楽です。
この調子でどんどん進んでいきますが、それにしてもこの本は丁寧過ぎるかも？と思い始めています。
ギュッとすれば、100ページ以上削減できて、分厚い本でなくなり、もっと手に取り易い気がします。
大きなお世話かもしれませんが。
この記事が気に入ったらサポートをしてみませんか？