上流SEが評価されるのは、要件定義が上手い人だけじゃない──差がつく業務の見え方

要件定義ができるようになれば、上流で評価される。

そう思って頑張ってきたのに、なぜか同じように上流工程にいる人の中で、信頼の集まり方に差が出ることがある。

議事録も書ける。ヒアリングもできる。画面要件も整理できる。
それでも、あの人には早い段階で相談が集まり、自分は仕様をまとめる役に留まりやすい。

この差は、文章力だけではありません。
コミュニケーション能力という曖昧な言葉でも片づきません。

上流SEで本当に差がつくのは、要件定義の作業スキルそのものより、業務をどう見ているかです。今週の4/23朝案でも、主題は要件定義の型ではなく、業務の見え方に置かれています。

僕は、上流に寄っていく人と、現場で止まりやすい人の分かれ道は、ここにあると思っています。

要件を聞ける人と、業務の詰まりを見つける人は違う

上流に入り始めた頃は、つい 何を作るか を早く固めようとします。

画面は何項目必要か。
承認フローは何段階か。
CSV連携はいるか。
検索条件は何個か。

もちろんそれも必要です。
でも、それだけだと、上流SEとしては半分しか見えていません。

本当に重いのは、その機能がないことによって、現場のどこが滞っているかです。

たとえば、申請画面を作る案件でも、見るべきは画面レイアウトより前にあります。

• 誰が入力しているのか

• なぜそこで止まるのか

• どこで確認待ちになるのか

• 例外処理は誰が抱えているのか

• システム外の手作業がどれだけ残っているのか

ここが見えていないまま仕様に落とすと、作ったのに回らないシステムになります。
逆に、ここが見えている人は、要件定義の場で出す言葉が変わります。

確認すべき項目が変わる。
曖昧な前提に気づける。
後で揉める論点を先に拾える。

だから、同じ要件定義をしていても、評価が分かれていきます。

上流SEが見ているのは、機能ではなく流れの詰まり

業務が見えている人は、会話の入り口が違います。

機能の説明から入らず、まず流れを見ます。
画面の要望から入らず、どこで止まるかを聞きます。
要望をそのまま受け取らず、なぜそれが必要になったかを確かめます。

これは、顧客に逆らうという話ではありません。
要望を深く理解するために、業務の流れまで戻って見るということです。

現場でよくあるのは、ユーザーが 不便です と言っているのに、作る側が 機能追加ですね と早く結論づけてしまうことです。

でも実際には、

• 承認責任が曖昧

• 判断基準が人によって違う

• そもそも前工程の入力が揃っていない

• Excel運用が前提化していてシステムが悪者にされている

といったことも少なくありません。

つまり、不便の原因がシステムではなく、業務の曖昧さにあるケースがあるわけです。

ここを見抜ける人は強い。
なぜなら、作るべきものだけでなく、決めるべきことまで見えているからです。

上流で信頼される人は、仕様をまとめる人ではなく、何を先に決めないと危ないかが見える人です。

止まりやすい人は、仕様化が早すぎる

逆に、上流で伸び悩みやすい人にも共通点があります。

それは、理解が浅いのではなく、仕様に落とすのが早すぎることです。

言われたことを整理する力がある人ほど、この罠に入りやすい。
会話をまとめるのが上手い。文章も早い。資料も整っている。
だからこそ、まだ曖昧なものまで、形にして前へ進めてしまう。

一見すると仕事が早いように見えます。
でも、その速さが前提のズレを固定してしまうことがあります。

たとえば、

• 現場Aの言葉を、そのまま全体要件だと思い込む

• 例外運用を通常運用として書いてしまう

• 部門間で責任が曖昧なまま、画面設計に入ってしまう

• まだ合意できていない論点を、決まったものとして整理してしまう

こうなると、後から手戻りが増えます。
本人はちゃんと仕事をしているのに、なぜか後半で苦しくなる。

これは能力不足ではありません。
見る順番の問題です。

仕様化が早い人は、作るための整理には強い。
でも、決めるための整理が弱いと、上流では信頼が積み上がりにくい。

ここを分けて考えられるかどうかが、かなり大きいと思います。

業務が見える人は、言葉の後ろにある責任を見ている

業務の見え方で差がつく、というのは、業務フローを暗記しているかどうかではありません。

本質は、言葉の後ろにある責任と判断を見ているかです。

たとえば、承認という言葉ひとつでも、

• 誰が承認するのか

• 何を見て承認するのか

• 差し戻しの基準は何か

• 承認しない場合の扱いはどうなるか

• 承認遅延のしわ寄せは誰が受けるのか

ここまで見て初めて、業務が見えていると言えます。

逆に、承認が必要です で止まると、まだ機能の表面しか触れていません。

上流SEに必要なのは、業務知識の量だけではなく、業務の重さの置き場所を見つける力です。

どこが曖昧だと後で揉めるか。
誰の認識差が危ないか。
どの例外が全体を壊すか。

こういう見方ができる人は、自然と相談されやすくなります。
要件定義が上手いから評価されるのではなく、危ないところが見えるから評価されるのです。

明日から見る場所を少し変える

では、どうすれば業務の見え方は変わるのか。

僕なら、まず仕様の前に次の3つを置きます。

1. 誰がいちばん困っているか

システム化の話になると、声が大きい人の要望が中心になりやすいです。
でも、本当に見るべきなのは、いちばん負荷を受けている人です。

入力している人か。
確認している人か。
差し戻しを受ける人か。
例外対応を抱える人か。

ここが見えると、要件の優先順位が変わります。

2. 何が滞っているか

現場は困っていると言います。
でも、その困りごとは、時間がかかるのか、判断できないのか、責任が曖昧なのかで意味が違います。

滞り方を分けて見るだけで、打ち手はかなり変わります。

3. どこが曖昧なまま進んでいるか

上流で危ないのは、分からないことではありません。
分からないまま進んでいることです。

• 定義が揃っていない

• 部門で言葉の意味が違う

• 例外時の扱いがない

• 責任分界が決まっていない

ここを拾える人は、後で効いてきます。

上流SEの強さは、きれいな要件書だけでは決まらない

きれいな要件定義書を書く人は、たしかに頼りになります。
でも、それだけでは上流で強いとは言い切れません。

上流SEの価値は、業務を仕様に変換することだけではなく、業務の曖昧さや詰まりを見つけて、決めるべき論点に変えることにあります。

要件定義の上手さは、その結果として見えるものです。
先にあるのは、業務の見え方です。

だから、上流に行きたい人ほど、機能の話を早くまとめることより、業務のどこに重さがあるかを見るほうがいい。

何を作るかの前に、どこで止まっているかを見る。
画面の前に、流れを見る。
要望の前に、責任を見る。

この順番が変わるだけで、同じSEでも見え方はかなり変わってきます。

僕は、上流に寄っていく人の差は、結局ここに出ると思っています。

あなたは最近、仕様の前に、業務のどこを見ていますか。

次に読む：

はじめての方へ：

マガジンの紹介：

IT業界の「技術×キャリア×整える」を束ねるマガジンを公開中です！
ビジネスや心と体を整える良記事が集まってきていますので、
是非、覗いてみてくださいね。
記事は全て無料記事のみです。
気に入って頂けたらマガジンのフォローもよろしくお願いします！
共同マガジンに参加希望の方も募集中です！

＜PR＞

次のキャリアを考えたい方へ。
求人サイトGreenを応援しています。