要件定義と設計はなぜ揉めるのか（応用情報視点）

システム開発の現場で、
「要件定義」と「設計」の間がうまくいかない、という話は珍しくありません。

応用情報技術者試験でも、
この境界があいまいになった結果として起きる問題が、
繰り返し出題されます。

この回では、
なぜ要件定義と設計が揉めやすいのかを、
応用情報視点で整理します。

要件定義は「何を実現したいか」を決める工程

要件定義で決めるのは、
システムで何を実現したいのかです。

• どんな業務を支援したいのか
• 何ができれば成功と言えるのか
• 利用者は誰か

ここでは、
「どう作るか」は本質ではありません。

目的と期待値を言葉にする工程です。

設計は「どうやって実現するか」を決める工程

設計では、
要件で決めた内容を、
現実の制約の中でどう実現するかを考えます。

• 構造はどうするか
• どこに処理を持たせるか
• どこで判断するか

同じ要件でも、
設計の選択肢は一つではありません。

揉める原因は「境界の侵食」

問題が起きやすいのは、

• 要件定義の段階で
  実装方法が固定されてしまう
• 設計の都合で
  要件の意味が変わってしまう

といった、
境界を越えた判断が起きたときです。

応用情報では、
この侵食がトラブルの原因として描かれます。

応用情報の午後問題での典型パターン

午後問題では、

• 利用者の要求は満たしているはずなのに
  現場で使えない
• 設計上は正しいが
  業務の意図とズレている

といった状況がよく出てきます。

これは、
要件と設計の役割を混同していることを
見抜かせるための構造です。

実務でよくあるすれ違い

実務でも、

• 「仕様通りに作った」
• 「そんな使い方は想定していない」

という会話が生まれがちです。

どちらかが間違っているのではなく、
どこで何を決めるべきかが曖昧なことが原因です。

応用情報は、
その曖昧さを整理する訓練とも言えます。

まとめ

• 要件定義は「何を実現したいか」
• 設計は「どうやって実現するか」

この役割が崩れると、
システムは人の期待からズレていきます。

応用情報では、
そのズレを構造として捉えられるかが
問われています。

次回予告

次回は、
「『正しい設計』が必ずしも良い設計ではない理由」
を扱います。

設計の評価軸についての話です。