仕様変更を業務部門に伝える前に──影響範囲を機能ではなく仕事で見せる

仕様変更の説明をしているのに、なぜか業務部門に伝わらない。

この画面を直します。この項目を追加します。この処理を変えます。IT側としては、影響範囲を説明しているつもりでも、相手の反応が薄い。あるいは、軽く受け止められてしまう。

逆に、業務部門からは簡単な変更に見えている。ちょっと項目を増やすだけ。少し表示を変えるだけ。帳票の並びを変えるだけ。そう見えているから、納期や工数やリスクの話をすると、IT側が大げさに言っているように見えてしまう。

ここで起きているのは、どちらか一方の理解不足ではない。多くの場合、見ている対象が違う。

IT側は、機能を見ている。業務部門は、仕事を見ている。

だから、仕様変更を業務部門に伝える前に必要なのは、機能の影響範囲を整理することだけではない。その変更によって、誰の仕事が、どのタイミングで、どの判断を伴って変わるのかを見せることだと思う。

僕自身、上流工程や業務改善の現場で何度も見てきたが、仕様変更が揉めるときは、変更内容そのものより、変更の見え方がずれていることが多い。IT側から見ると重い変更でも、業務部門から見ると小さな修正に見える。業務部門から見ると重要な変更でも、IT側から見ると単なる例外処理に見える。

このズレを埋めないまま話すと、会話はすぐに対立になる。

できるか、できないか。
いつまでにやるか、やらないか。
費用が増えるか、増えないか。

もちろん、それらは大事な論点である。ただ、その前に置くべき問いがある。

この変更で、業務はどう変わるのか。

たとえば、受注画面に新しい項目を追加する変更があったとする。IT側の説明では、入力項目を一つ追加する、DB項目を追加する、帳票に出力する、既存の入力チェックを変更する、という話になりやすい。

しかし、業務部門が本当に判断したいのは、そこだけではない。

その項目は誰が入力するのか。入力する人は、どの情報を見て判断するのか。入力しない場合、後工程で誰が困るのか。承認者はその項目を見て何を判断するのか。月末処理、請求、出荷、在庫、レポートに影響するのか。既存データはどう扱うのか。過去分を補正するのか、それとも新規分からでよいのか。

ここまで見せて初めて、業務部門は変更の重さを判断できる。

機能影響は、システムの中の変化である。業務影響は、人の仕事の変化である。

上流SEやPL、PM補佐の役割が難しいのは、この二つを行き来する必要があるからだ。技術的に正しい説明だけでは足りない。業務部門に寄り添うだけでも足りない。両方の言葉をつなぎ、判断できる形に変える必要がある。

そのために、仕様変更を伝える前に、最低限三つの視点で整理しておくとよい。

一つ目は、誰の作業が変わるのか。

変更対象の機能名だけでは、業務側は自分ごとにしづらい。受注担当、承認者、経理、倉庫、営業、管理者、顧客対応担当。どの立場の人が、どの作業を変える必要があるのかを示す。

ここで大事なのは、担当部署名で止めないことだ。営業部に影響があります、では粗い。営業部の誰が、どの画面で、どのタイミングで、何を判断するのか。そこまで落とすと、急に話が現実になる。

二つ目は、どのタイミングが変わるのか。

業務は、単体の作業ではなく流れで動いている。入力、確認、承認、出力、連携、締め処理、問い合わせ対応。仕様変更が一つ入るだけでも、流れのどこかに待ち時間や確認作業が増えることがある。

特に見落とされやすいのは、締切前、月末、リリース直後、繁忙期、イレギュラー対応時である。平常時には軽く見える変更でも、繁忙時には業務負荷を大きく増やすことがある。

だから、影響範囲は機能単位だけでなく、業務カレンダー上のどこに出るかで見る必要がある。

三つ目は、どの判断が増えるのか。

仕様変更は、作業量だけを増やすわけではない。判断を増やす。例外を増やす。確認を増やす。迷いを増やす。

この項目は必須か任意か。未入力の場合は誰が判断するのか。古いデータと新しいデータが混在した場合、どちらを正とするのか。システムで止めるのか、運用で吸収するのか。例外が出たとき、誰が承認するのか。

こうした判断が曖昧なまま変更を進めると、リリース後に現場が止まる。IT側から見ると実装は終わっているのに、業務側から見ると運用が始められない状態になる。

仕様変更を業務部門に伝えるときは、相手を説得しようとしすぎないほうがいい。説得しようとすると、どうしても守りの会話になる。これは難しいです。工数が増えます。リスクがあります。そういう話ばかりになると、業務部門からは抵抗に見える。

本当に必要なのは、判断材料を出すことだ。

この変更を入れると、誰の作業が変わる。
このタイミングに影響が出る。
この判断が追加される。
この帳票やデータ連携に波及する。
代替案としては、今回入れる、次回に送る、運用で一時対応する、範囲を絞る、という選択肢がある。

ここまで出すと、話は対立から選択に変わる。

業務部門は、仕様変更をしたいだけではない。多くの場合、現場の困りごとを何とかしたい。売上、請求、納期、顧客対応、確認負荷、ミスの削減。何かしら守りたい仕事がある。

一方で、IT側にも守るべきものがある。品質、納期、保守性、データ整合性、運用負荷、セキュリティ、将来の拡張性。それを感情論でぶつけると、どちらも正しいのに話が進まない。

だからこそ、仕様変更は機能ではなく仕事で見せる。

この変更は、画面のどこを変える話なのか。
その前に、誰の仕事をどう変える話なのか。

この順番を変えるだけで、会話の質はかなり変わる。

上流SEやPL、PM補佐の価値は、すべての仕様を知っていることだけではない。技術と業務の間にある見えにくいズレを、判断できる言葉に変えることにある。

仕様変更を断る力も大事だ。けれど、それ以上に大事なのは、断るか受けるかを決められる状態を作ることだと思う。

最近受けた仕様変更を、機能ではなく仕事として見直すなら、誰のどの作業が変わるでしょうか。

次に読む：

はじめての方へ：

マガジンの紹介：

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

＜PR＞

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