SEとして要件定義や設計を経験された方にお伺いしたいです。 私は、社内SEの人数があまり多くない会社に勤めており、要件定義から導入までを一貫して一人で担当することがよくあります。

Question

そのため、要件定義の段階から、どうしても設計を意識しながら進めてしまいます。

一方で、「要件定義と設計は切り分けて考えるべき」というのが一般的な考え方だとも理解しています。
ただ、自分としては後続工程を意識して取り組んだほうが、結果的に手戻りも少なく、効率的なのではないかとも感じています。

やはり、要件定義と設計は意識的にしっかり分けて考えるべきなのでしょうか。

ご経験のある方のご意見をいただけますと幸いです。
よろしくお願いいたします。

Answer 1

「効率」という言葉の受け取り方の問題です。要件定義とは「要件を客観的に明確化」することであり、設計は全くの無関係です。

質問者様がやっていることは「質問者様に可能な設計に合うように顧客の要件を誘導すること」です。誘導された要件は必ず（少なくとも質問者様に）可能な設計に合うようになっていますので、簡単に設計できます。

これは家具に例えると、

顧客「ここの隙間にピッタリ入る棚が欲しいんだ」
質問者様「そうでしたか。この隙間は27センチですね。幅25.4センチの板がありますので、25.4センチ幅の棚ということで宜しいでしょうか？」
顧客「（ぴったりには出来ないのか、仕方が無いな）良いよ」

のような感じです。この誘導が無い場合、

質問者様「ということで27センチ幅の案件を取ってきたぜ」
大工「中途半端だな25.4センチにはならないのか？ わざわざ30.48センチの板を27センチに切り落とすのか？ 工賃が増えるぞ？」
質問者様「ということで27センチぴったりで高いのと25.4センチで安いのとどっちが良いですか？」
顧客「どう違うのか良く解らないんだけど？」
質問者様「（理解してもらえるまで説明する）」
顧客「聞いてもさっぱり解らないから安い方で」

という一往復が余計に必要になる＝＝効率が下がる、場合によっては工数が増える＝効率がもっと下がる、という認識なのだろうと思います。

質問者様自身が設計可能なので（或いは実際に質問者様自身が設計するので）その場で設計（概要設計）まで済ませてしまう。このこと自体には問題はありません。ですが要件定義の存在意義は、顧客が求めているものが何かを正確に訊き出すことです。

そして次の段階である設計に「これさえ満たしていれば自由にやって良いよ」というお墨付きを与えることです。

この二つを意識的にしっかり分けて考えるべきだと思います。

これを一人で担当すること、同時に進めることが誤っていると主張しているわけではありません。意識的にしっかり分けて考えていれば、「顧客が求めているもの」を訊き出すフェーズと「顧客が求めているものが工数＝見積やランニング・コストにどの程度のインパクトを与えるのかを説明して折衝するフェーズ」とは自然と分かれてくるはずです。例え同じ会議の場で話したとしても。

もしかしたら【顧客が本当に必要だったもの】でヤフると、何かが見えてくるかも知れません。

Answer 2

> 要件定義と設計は切り分けて考えるべき

要件定義フェーズと開発フェーズは別で契約なら、そのとおりです。

通しで契約なら先方の予算や期間がありますよね？要件定義で盛り込んだら予算やサービスイン時期を大きくハズレてもOKなんですか？と。

全ての希望をきく必要はないです。目的は何なのか、それを達成するために最低限必要なものは何なのか、予算と時期は？
を明確にした上で妥協と摂政するものが要件定義かと思います。普通はね。

予算や期間に問題ないなら顧客のなすがまま。

Answer 3

＞「要件定義と設計は切り分けて考えるべき」というのが一般的な考え方

そうなの？

個人的な意見に過ぎないのでは？

いいもの作ろうという姿勢だけで考えればそういう考え方もあるが、金が絡むとそうとばかりは言えなくなる。

客の頭お花畑夢の世界の仕様を、現実の予算に沿って実現するとなれば、予算（たいていは足りない）に納まるように方式まで想定する必要がある。

Answer 4

> やはり、要件定義と設計は意識的にしっかり分けて考えるべきなのでしょうか。

はい。
そもそも要件定義はシステム化関係なくユーザーの要件を定義するものですし、その中からシステム化する部分を抜き出して基本設計に回すものです。
抜き出す段階でその先のことを考えながら抜き出すのは当然ですが、最初からシステム化「だけ」を考えて要件定義なんてやったら、ユーザーメリット自体外減りかねないし、システム化の最大の目的はユーザーメリットを高めることです。