要件定義に必要なのは業務知識じゃなくて交渉コミュ力。そもそも業務理解なんて無理

※この文章はstand.fmの文字起こしをしたものです。
https://stand.fm/episodes/5ee2d9c033ca4e829970388e

開発の要件定義について簡単にお話ししたいと思います。有山です、よろしくお願いします。

Twitterで要件定義には業務を知っている必要があるっていう話が流れてきたんですけど、業務を知ってる人多分いないですよね。やればわかるけどその業界の専門性が高いとマジで全く分かんないんですよね。業務もフローも細かいレギュレーションとかも分かんないんで、要件定義する人、PMでもなんでもいいですけど、が業務を全部理解するのは無理です。めっちゃ時間かかります。だって10～20年やってた人がやっと習得してるぐらいのレベルの業界もあるので、業務を知ってるっていうよりはお客さんとちゃんと関係性を構築して業務を教えてもらえる、さらにはそれを業務に落とし込み、設計と言うかプロトタイプというかなにか見えるものをお客さんに見せてこういうことであってますかねみたいな、「この業務はこんな感じの流れにしていい感じにしたんですけど認識は合ってますか」ってすり合わせられるのが要件定義だと思います。

僕も新卒の時は金融機関系システム部署のSEだったんですけど、銀行の業務って全然わかんなかったです。やばいくらいわかんないし例外が多すぎて、「これはこうやるんだよ坊主！」みたいな感じでめっちゃ怒られたので、頭下げてめっちゃ教えてもらいましたね。

エンジニアあるあるかもしれないですけど、機能の単位で考えるとすごくいい感じがするけど現場からしたら使い物にならないケースがすごくあるんですよね。だから良かれと思って持っていって、例えばお客さんのトップがいいじゃん導入しようぜってなっても現場が大反発するようなことがすごいあるから、トップダウンで決まったとしてもちゃんと現場の意見を汲み取りみんながハッピーになれるように問題を解決するのが要件定義というか開発じゃないかと思います。

場合によっては最適解がなかったりするんですよね。それこそ銀行とかでは結構あるんですけどリストラするためにシステム化するみたいなのが結構あるんですよね。システム化することによって人手を減らして工数減らして自動化できるみたいな。そういう時に現場の人はこのシステム入ったら俺たち切られるんだなというのがやっぱり分かるから超やりづらかったりするんですよね。でも本当にそれが業界のためというか会社のためというか、明らかに世の中が良くなったり最適化したりするものだったらやる価値があると思います。

そんなところですかね。

要件定義するのは難しいですよね。お客さんはITリテラシー高くないことが多いと思うし、意欲的かって言うとそうじゃないお客さんも多いと思うんですよね。普段の仕事忙しい人も多いですし。だからそこをうまく取り入って真摯に向き合って、わかんないことは聞いてまとめてやっていくしかないと思います。

まあ大変だけど個人的には結構楽しいと思います。最近やってないけど。これ以上話すとグダグダしそうなのでこの辺で終わりにします。
要件定義頑張りましょう！