【感想・ネタバレ】ユーザーの役に立つシステムを作る 本当に使える要求定義［改訂版］（日経BP Next ICT選書）のレビュー

木村哲

要求定義の「正しい手順」を提示し、圧倒的な支持を得た不朽の名著の改訂版。
「基幹系」と「情報系」、それぞれのシステムでの要求定義の手順を具体的かつ実践的に解説します。
筆者の豊富な経験に基づいたケーススタディとそのまま使える豊富なドキュメントサンプルで「いつ」「誰が」「何を」「どのように」「なぜ」やればよいかがわかります。


≪目次≫




【序章】 問題提起
■要求定義の担当者はプロ集団ではない

【第1章】 要求定義を学び直す
1-1■良い要求定義とはどんなものか
1-2■良い要求定義を阻むものは何か
1-3■開発プロセスの中でどう位置付けるのか ほか

【第2章】 要求定義の手順を知る─基幹系システム編
2-1■基幹系システムのプロセス・マップの考え方
2-2■［プロセス1］ 戦略と目的を確立する
2-3■［プロセス2］ スコープを設定する ほか

【第3章】 要求定義の手順を知る─情報系システム編
3-1■情報系システムのプロセス・マップの考え方
3-2■［プロセス1］ 戦略と目的を確立する
3-3■［プロセス2］ スコープを設定する
3-4■［プロセス3］ 対象ユーザーを洗い出す
3-5■［プロセス4］ 現状を把握する ほか

【第4章】 要求定義のトラブル・シューティング
4-1■思い通りに進まない原因を潰す
4-2■トラブル・シューティング一覧

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

ユーザサイドの要求定義について、全体像とプロセスを例示しており、非常にわかりやすい内容だった。
現実的にRFP段階でここまで実践できている企業は少なく、
システム開発の要件定義で実施する事が多いだろう。
(システム開発の要件定義として見てしまうと、抜け漏れがあるように見えるため、本書の対象範囲に注意が必要。要求定義、という言葉事態が誤解されやすいところではあるが…）

本書の説明する業務内容は、一般的にはユーザ企業/コンサルティング会社/現行システムベンダーといった組織が関わる箇所になると思われる。

要求定義プロセスの中では、ユーザヒアリングからの新業務設計が非常に難しく、特に基幹業務の刷新を考える場合、本書に記載されているレベルの内容はシステム要件定義と別に、現行業務調査・新システム構想(グランドデザイン)フェーズとして時間を掛けて行うべきだと感じる。
現行調査を甘く見て失敗した大規模システムの事例は非常に多いのであるが、それだけ現行調査は難しいのだ。

…と色々考えさせてくれる良書。

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

理屈や理想論にこだわらずに、システム構築の現実を認識した上で、現実的な要求定義の方法が説明されている。

用語の不統一や粒度の不整合といったシステム開発の現場で日常的に起こる問題が、実例を交えて説明されており、あー、こういうしょぼい問題ってどこでも起こってるんだなーと認識することができ、面白かった。

全体的に平易な用語で、要点を絞って説明されているので、実際に要求定義をする際に傍らに置きながら参照する形で使ってみたい。