はじめよう! 要件定義 : 賢者の図書館 (Under Construction) : livedoor Blog（ブログ）

キーワード：
　羽生章洋、要件定義、開発、画面遷移図、システム

システム開発における要件定義のやり方がわかりやすく示されている本。以下のような目次となっている。

第1部 要件定義って何だろう?
要件定義=要件を定義すること

要件定義の基本的な流れ

定義すべき要件の内訳

3つの要素の定め方
第2部 要件定義の詳細
要件定義、その前に

企画を確認する

全体像を描こう

大まかに区分けしよう

実装技術を決めよう

実現したいことを整理整頓しよう

利用者の行動シナリオを書こう

概念データモデルを作る

UIを考えよう

機能について考えよう

データについて考えよう

要件定義の仕上げ

要件定義、その後に
(目次から抜粋)

要件定義をやろう!!と思い立った時に、今まで下流工程メインでしかやってこなかったので、要件定義のような上流工程は未経験で、はて、何をどうやればいいんだろう?と思ったので、買って読んでみた。

要件定義ってそもそも何?というところから始まって、要件定義の基本的な流れ、定義すべきことなどがイラスト付きで170ページほどでコンパクトにわかりやすくまとまっている。

そもそもシステム開発での要件として必要なことが以下のように示されている。

プログラマがソフトウェアを完成させるために必要な情報
(pp.18)

そして、これの元ネタがUI、機能、データとなり、それらを決めることが要件定義でのやることと示されている。なので、完成させるシステムのゴールから逆算して以下の順番でそれぞれの内容を決める必要がある。

UIを決める
機能を決める
データを決める

しかし、要件定義の準備段階が重要になってくる。何をやるべきかは省略して、それらを実施していれば、その成果物と以下が手元に揃っている状態であると。

企画書
全体像（オーバービュー）
利用する実装技術
実現したいこと一覧（要求一覧）
行動シナリオ
概念データモデル

3月に転職してから受注側から開発ベンダーに依頼する発注側の立場となった。僕の事業室の内部IT要員は実質自分1人だけなので、内部の要件とベンダーの橋渡しをうまくやらなければいけないという状況。要件定義が重要なのは身に染みているので、なんとなくこんな感じでよろしく!!と言ってベンダーに丸投げしてまともなシステムができるわけがないことは言うまでもない。

なので、自分である程度要件定義に近いことを内部でやっておく必要がある。まずはこの準備段階をきっちり決めることだな。案外ないものがある。企画書とか全体像とか要求一覧とか行動シナリオとか概念データモデルとか、というかほぼ全部ない!!wこのあたりをしっかり分析して用意しておいて、そこからようやく外部ベンダーにこんな感じで、と依頼できるかな。

発注側も要件定義の内容としてのUI、機能もある程度洗い出し、完璧とはいかないまでも考えるネタとして資料化、そんで外部ベンダーに引き渡して、外部ベンダーにブラッシュアップしてもらうことで要件漏れや手戻りもある程度防げるのではないかと思う。まぁ、ビジネススピード優先でかつ内部のIT要員が自分１人の状態というのもあったりでどこまでできるかはわからないけど、ここまでは意識としてやっておきたい。

理想は発注元もデータを決める、つまりDB設計までやればよいが、ここまでになるとUI、機能を決めるよりもより複雑になってくるので、外部ベンダーに投げてもいいのかなと思ったり。理想は完全内製化でDevOpsで行きたいところなのだけど、実際そんなことができないから外注するしかないのだけどね。

また、以下のDainさんの記事がとても勉強になるので、一度読んでおくとよい。

糞システムにしないため、私ができること『はじめよう！要件定義』: わたしが知らないスゴ本は、きっとあなたが読んでいる

本書は著者の携わった案件から、最近はやりのアプリやゲーム開発も考慮された内容となっている。要件定義の漠然としていた内容がすっきり整理されて、明日からの自分のタスクが明確になった。受注側の特に上流工程をやる人は読んでおくべきだし、発注側のベンダーとのやり取りをする人も絶対読んでおいた方がいい。すべては糞システムにしないために。