要件定義はお客さんの言いなりになればいいわけではない

22日目でございます。

わろたわろた。

続いてます。

今日はSEっぽい話を。

システムエンジニアって、お客さんが思う「こういう感じにしてほしいなあ」という要望を実際にシステムで実現していくお仕事です。

そこで、「要件定義」という工程がシステムを作る前に存在します。

ざっくり言うとお客さんの「こうしたい」を具体的な要件として定めていく工程です。

例えばショッピングのサイトを作ろうと思った場合、

商品の写真がスクロールで見えるようにしようとか、

ボタンはここに置いてこのボタンを押すと商品の詳細が見えるようにしようとか、

商品の詳細にはこんな項目を載っけようとか、

支払いの時はクレジットカードシステムのAPIと繋いで決済できるようにしようとか、

まあそういう要件をお客さんと相談しながら決めていくわけですな。

この時に、お客さんが本当に求めてるニーズを引き出せるようにしましょう！

みたいな話がよくあります。

今回もそこは絡んできますけど、メインとしてはちょっと違う話をします。

要件定義の時に、お客さんの話をどこまで真に受けて聞くか。

今日はこれがむずいと感じました。

極端な話、お客さんが「どこでもドアみたいな機能が欲しいな」とか言い出しても

2021年現在では実現性が著しく低いわけであります。

それに対して「分かりました」と言ってはいけない。

如何にお客さんのニーズと言えどできないもんはできないっすからね。

そんな約束はしてはいけないのです。

ここまでになると流石に分かりやすいですけど、現実はもう少しややこしいです。

今、ぼくは担当システムの電子マニュアルを作っているのですが、

昨日お客さんに電子マニュアルの案を見せに行った時に、

「もうちょっと詳しめに処理の流れ書いてほしいですね」とそんな感じのことを言われました。

とりあえずその場では「持ち帰って検討します」的なはぐらかし方をしたんですけど、

後で上司に報告したら「そこまでする必要はない、今見せてる処理フローでマニュアルとしての機能は十分果たせるはずだよ」とのこと。

ということで今日もう一回お客さんとこ行って説明してきたんですけど、

やっぱ詳しめに書いてほしいなあみたいな感じのテンションに飲まれ結局帰ってきちゃいました。

まあ単純に言えば説得できなかったわけなので、

帰ってきて上司に報告したら「まだまだだなwww」みたいな感じに言われてしまいましたw

上司からすると、「コスト」という側面を考えるとそこまでする必要はないと思ってるみたいです。

該当の処理の流れを言う通り変えてみたところで、おそらくそこまで使いやすさは変わらない。

十分今回のもので賄える。他の仕事に時間を使うべき。ということです。

(お客さんの前で直接的にコストの話はあまりしませんが、実際ぼくもそれは同意)

そして、「ニーズ」という面で考えても、

「2回目行く時は、なんでお客さんがそこまで細かく拘ってるのかを書き出さないといけない。

おそらくちゃんと要望を聞いてみれば今回のマニュアル+αくらいの修正で済む場合も今回の場合はあり得たと思う。」

と言われました。

今回のことで、客側、開発側、双方がWin-Winとなる落とし所を作る難しさを実感した次第です。

もちろん、今回の例で上司の言うことが必ず正解、というわけではないと思います。

結果的に時間かけて直して、お客さんに喜んでもらえるかもしれない。信頼度が高まるかもしれない。

ただ、逆も然り。

「顧客要望だからといって、お客さんの言う通りに動くことが最善とも限らない」

先輩とかから話として聞くことはありましたけど、経験として理解できたのは初めてでした。

まあ1人で今回凸させてもらえたのは良い経験だったなと思います。

まだまだひよっこなのでこれからもがんばります。

ではまた明日。