システム要求を分類する

自分が開発に携わっているシステムは、社内にも利用者がいるのでわりと頻繁に改善要求を受ける。

そして要求を受けたときに、要求を出した人が何を考えて、どのレベルのことを言っているのかを切り分けて考えないと、 顧客が本当に必要だったもの のようになりかねないなぁと思ったので整理してみる。

要求を分類する

要求という言葉のままでは少し抽象的なので分解して考えると、大体の要求は以下のように分類できる

• 現状の課題を言っている
• 解決策の提案をしている
• 目的の共有をしている

エンジニアは要求がこれらのどれに分類されるか判断して、それ合わせて対応も変える必要がある。

一番多いのは、現状の課題を言っているパターン

比較的小さめのタスクでよくある

「あったら便利だよね」「みんな欲しがっているよね」から生まれる要求なので、明確な目的がないことも多い

〜〜イメージ〜〜

要求「検索条件に "出身地" 追加してー」
↓
エンジニア「できました！」　　（以前も似たような対応したような...）

しかし、目的が見えないまま、その都度改修を続けていると「あれ？この処理は他のクラスにも書いた気がするな...」「検索画面のパフォーマンスが悪くなってきたぞ」といったように、後々大きな作り直しが必要になる可能性をはらんでいる。

こういった目的がなく課題だけが存在している要求の場合は、

• この機能がなかったときはどうしてたか
• この機能は今後どのように使われるか

をヒアリングし、機能の発展性の確認と、現行機能の組み合わせで解決できそうかを考えたい。

解決策の提案をしているパターン

一見楽そうに見えるが要注意のパターン

例：

場面：会員へ向けたコミュニケーション機能が欲しい

要求「会員へ向けたメール配信機能がほしい！」
↓
エンジニア「メールサーバー用意して、メール機能もつくりました。」
（チャットツールという選択肢もあったな...）

要求をだした人は**「メール」という手段しかしらない**可能性がある。

この場合は、目的を持っているならそれをヒアリングするし、目的持っていなければ目的を一緒に考える必要がある。

• 提案者が非エンジニアの場合は、データ構造ガン無視の場合がある（※もちろん提案者に非はないし、そこがエンジニアのチカラの見せ所）
• もっと良い解決策が見つかった場合、提案者に再提案する必要がある（コミュ力大事）

目的の共有をしているパターン

「〇〇をできるようにしたい。」という要求

例：

要求「会員が商品を購入したら、サイト運営者通知する機能がほしい！」
　→（通知はタイムリーなのか、通知停止機能はいるのか、どの権限まで通知するか等、色々決まっていない）

この場合は、目的を達成するための機能を洗い出し、色々なことを定義する必要がある。

とても自由度が高く楽しいが、その分難易度も高い。

抽象的な要求を理解し、具体的な機能に落とす構造化スキルがもっとも試されるところだと思う。

最後に

相手が課題・解決策・目的のどれで話しているのかで、その後の対応も変わるべきだなと思ったので自分なりにまとめてみた。