【感想・ネタバレ】手戻りなしの要件定義実践マニュアル[増補改訂版]（日経BP Next ICT選書）のレビュー

水田哲郎

真の問題が見える! ぶれない要件が決まる!

本書では架空のシステム開発プロジェクトを例に、若手SEがベテランの助言を基に要件定義を進めていき、多くの成果物を実際にまとめていきます。現場のリアリティ溢れる内容で、要件定義の進め方やコミュニケーションの手法、各種成果物のまとめ方を、実践的に学べます。前作に、保守開発での要件定義手順や、要件定義の演習例題を加えました。



≪目次≫




【第1章】 要件定義を成功させるポイント
＜ 1-1 ＞ 手戻りをなくすカギは要件定義 ほか

【第2章】 業務分析の進め方 ～方針定め真の問題を特定する～
＜ 2-1 ＞ ステップ 1：方針と実施計画の策定 ほか

【第3章】 業務設計の進め方 ～解決策を考え要件決める～
＜ 3-1 ＞ ステップ 4：課題解決策の決定 ほか

【第4章】 既存システム改善における要件定義の進め方
＜ 4-1 ＞ 既存システム改善を成功させるポイント ほか

【第5章】 情報を漏れなく集めるヒアリングのスキル
＜ 5-1 ＞ ヒアリングの準備 ほか

【第6章】 全員が納得する合意形成のスキル
＜ 6-1 ＞ 会議の準備 ほか

【第7章】 BABOK を実践する方法
＜ 7-1 ＞ BABOKとは何か ほか

【付録A】 問題分析の演習例題
【付録B】 要件定義の成果物一覧


【ワンポイント講座】
・ 業務を分割する二つの切り口 ほか

[ブクログ · ★★★★★]

手戻りなしの要件定義実践マニュアル
増補改訂版
著：水田　哲郎
編：日経SYSTEMS

ITシステムの要件定義は、設計や実装とは明らかに異なります
プロジェクトがとん挫したり、手戻りが多発するのは、この要件定義の工程をしっかり行っておらず、クライアントと合意形成が取れていなかったことが原因です

システムが巨大化し、複雑化するにつれて、要件定義という工程は、ますます重要となっていくのです

本書は、要件定義書をどう書けば、プロジェクトを成功に導くことができるのか、を語るのが目的です。

ロジカルな構成をとっていて、今何をしているのかが、分かりやすい

気になったのは、以下です。

■要件定義の失敗

　原因　①要件定義の難易度があがった（ITシステムが旧来に比べてより複雑になった）
　　　　②ITエンジニアの知識・スキルが追っつかない
　結果　①検討した課題・解決策・要件に過不足が発生
　　　　②要件定義書に記載されている内容が具体性に欠ける
　　　　③検討内容について、利害関係者から十分な合意を得られない

■要件定義は何を決める

①システム化方針　システム化の目的・目標、対象範囲、制約条件
②解決すべき課題　解決すべき業務上の課題
③課題解決策　課題を解決するための業務方式（プロセス、制度、ルール、組織、担当者）
④新しい業務の仕組み　課題解決策を反映した、対象範囲全体の業務方式（プロセス、制度、ルール、組織、担当者）
⑤システム要件　機能要件：機能の内容、非機能要件：性能・信頼性・操作性
⑥後続作業計画　作業の進め方、体制、スケジュール

■要件定義の中の工程

　業務分析　ステップ１：方針と実施計画の策定　⇒　①システム化方針
　　　　　　ステップ２：現行業務と問題の把握
　　　　　　ステップ３：問題分析と課題の設定　⇒　②解決すべき課題

　業務設計　ステップ４：課題解決策の決定　　　⇒　③課題解決策
　　　　　　ステップ５：システム要件の整備　　⇒　④新しい業務の仕組み
　　　　　　　　　　　　　　　　　　　　　　　　　⑤システム要件
　　　　　　　　　　　　　　　　　　　　　　　　　⑥後続作業計画

■ステップ１：方針と実施計画の策定

＜システム化方針の決定＞
　①システム化方針の確認　システム化方針（対象範囲、背景、目的、達成事項、期待成果、制約事項
　②システム化方針ドキュメントの作成
　③システム化方針ドキュメントのレビュー
＜実施計画の決定＞
　①実施計画の作成　要件定義の実施手順、体制（PM,PL,メンバ、レビュア、事務局、コーデネータ）、スケジュール
　②実施計画の承認
※論理の飛躍、あいまい語、くどい言い回しを避ける

ドキュメント
⇒システム化方針

■ステップ２：現行業務と問題の把握　いわゆる AsIs

＜現行業務の調査と整理＞
　①現行業務内容の調査
　②調査結果の整理
＜現状問題の収集と整理＞
　①カードの記入方法の説明
　②カードの回収と確認
　③カードの分類

ドキュメント
⇒現行業務リスト
⇒現行業務関連図
⇒ＲＡカード（ヒアリング結果をまとめたもの）

■ステップ３：問題分析と課題の設定

＜ミーティングの準備＞
　①概要レベルの問題分析
　②詳細レベルの問題分析のたたき台作成
＜問題分析と本質的課題の決定＞
　①詳細レベルの問題分析
　②解決すべき問題と本質的課題の決定
＜課題分析と検討課題の決定＞
　①本質的課題の分析
　②解決課題と検討課題の決定
　③解決策のアイデア収集

ドキュメント
⇒問題体系図
⇒業務の問題関連図のたたき台
⇒業務の問題関連図
⇒業務の目的樹木図
⇒業務の解決課題一覧表
⇒解決策検討シート

■ステップ４：課題解決策の決定

＜解決策の検討単位決め＞
　①変革内容の想定
　②検討単位の設定
＜解決策の立案と決定＞
　①解決方針の明確化
　②解決策の原案作成
　③解決策の原案レビューと決定

ドキュメント
⇒検討単位分類表
⇒解決策の全体イメージ
⇒解決策の説明書

■ステップ５：システム要件の整備（前半）システム機能の洗い出し　いわゆる　To Be
　ステップ５：システム要件の整備（後半）データフロー図で情報と処理を整理

＜新しい業務の仕組みの設計＞
　①全体業務構造の設計
　②個別業務構造の設計
　③業務活動とシステム化内容の整備
＜機能要件の具体化と整理＞
　①システム機能の抽出と分類　---------------- ここまでが前半
　②入出力情報の整理
　③処理内容の整理
　④主要入出力項目の整理
＜非機能要件の具体化と整理＞
　①非機能要件の整理
　②後続作業計画の作成　---------------------- ここまでが後半

ドキュメント
（前半）
⇒業務機能関連図
⇒業務活動定義書
⇒システム機能整理表
⇒システム機能階層図
（後半）
⇒システム要件の整理
⇒新論理データフロー図
⇒新機能記述表
⇒主要入出力一覧表
⇒非機能要件整理表
⇒作業計画表

■ＢＡＢＯＫ：知識体系：要件定義の標準化

７つの知識エリア
　①エンタプライズアナリシス　企業組織レベル
　②要求アナリシス　要求分析、優先度評価
　③ソリューションのアセスメントと妥当性確認　妥当性評価、体制、スケジュールの定義
　④引き出し　ユーザ部門から要求を引き出し文書化する
　⑤要求のマネジメントとコミュニケーション　要求に対するステークホルダーからの合意形成、成果物の作成・管理
　⑥ビジネスアナリシスの計画とモニタリング　ビジネス分析の実施計画の立案、実施状況の管理
　⑦基礎コンピテンシ　ビジネス分析を実施する担当者に求められる基礎的な知識・能力

要件とは、承認された要求

４階層の要求
　①ビジネス要求　経営層
　②ステークホルダー要求　利用部門がシステム化によって解決を期待する業務上の問題や課題
　③ソリューション要求　組織・業務・システムでの実現内容　機能要求と非機能要求とがある
　④移行要求　ソリューション要求を円滑に実行するための手順、体制、スケジュール

CONTENTS

はじめに

第1章 要件定義を成功させるポイント
　1-1 手戻りをなくすカギは要件定義
　1-2　要件定義を成功させる進め方とスキル

第2章 業務分析の進め方 ～方針定め真の問題を特定する～
　2-1 ステップ 1：方針と実施計画の策定
　2-2 ステップ 2：現行業務と問題の把握
2-3 ステップ 3：問題分析と課題の設定

第3章 業務設計の進め方 ～解決策を考え要件決める～
　3-1 ステップ 4：課題解決策の決定
　3-2 ステップ 5：システム要件の整理（前半）
　3-3 ステップ 5：システム要件の整理（後半）

第4章 既存システム改善における要件定義の進め方
　4-1 既存システム改善を成功させるポイント
　4-2 既存システム改善における要件定義の手順


第5章 情報を漏れなく集めるヒアリングのスキル
　5-1 ヒアリングの準備
　5-1 ヒアリングの実施
　5-1 ヒアリングのクロージング

第6章 全員が納得する合意形成のスキル
　6-1 会議の準備
　6-2 会議のオープニング
　6-3 議論の進行（前半）
　6-4 議論の進行（後半）
　6-5 会議のクロージング

第7章 BABOK を実践する方法
　7-1 BABOKとは何か
　7-2 BABOKを活用する

付録A 問題分析の演習例題
付録B 要件定義の成果物一覧

索引

ISBN：9784822277284
出版社：日経BP
判型：B5変
ページ数：208ページ
定価：2700円（本体）
2011年04月18日第1版第1刷発行
2014年04月22日第2版第1刷発行
2016年10月17日第2版第2刷発行

[ブクログ · ★★★★☆]

全体のフローから具体的な会議の開催方法などまで全体について書かれた本。どう要件を探して固めていくかが具体的になっている。

[ブクログ · ★★★★☆]

この本に書かれているようなtoo heavyなプロセスで要件定義してたら、システム出来上がる頃にはビジネス環境変わってそう。というのが率直な感想。
超巨大基幹システムとかを作る場合は、こういうプロセスが必要になるのかも。ただ、その場合も細かく分けてなるべく大きなリリースにならないようにすべきだと思う。
既存システム改善における要件定義の進め方は、今やっていることでもあり、参考になった。もらった要望をそのまま鵜呑みにせず、一回噛み砕いてみることは大事だと思う。
5章と6章はヒアリングスキルと、合意形成のスキルということで、要件定義以外の場面でも使えそうだった。
というわけで、最後まで読み終わった。BABOKにちょっと興味が沸いた。