社内SEに最も求められる折衝スキル。社内折衝って具体的に何するの? | 情シスあるある

先日、社内SEのやりがいやストレス について書いた記事の詳細として
私が最も重要だと考えている社内での折衝(せっしょう)について書きたいと思います。

いろいろな場面で求められる折衝

ITベンダ側から見れば同じ「お客様」ですが、社内SEとしては、

ユーザ部門の意見をとりまとめ、ベンダ側との窓口になることが求められます。

特に社内の取りまとめが重要なのは下記のような場面です。

  • システム要求事項のヒアリング
  • プロジェクト実行計画の立案
  • 要件定義レビュー
  • 運用設計・受入テスト

以降で詳細について記載します。

適量が難しい要求事項ヒアリング

システム化する前には大なり小なり要件定義をしますが、私はその前に

システム化できるかできないかに関わらず、何がやりたいか=要求定義 を必ずします。

システムは業務を効率化する手段なので、
「システムをどうしたいか」というのは、
手段に対して手段で議論する事になり、やってはいけないことだと思っています。

なので、必ず「システムに関わらず、効率化したい業務や、日々不満に思っている事はありますか」とヒアリングしています。

私が今まで関わったプロジェクトは下記の両極端になることが多かったです。

  1. 要求事項が多すぎて収集がつかない
  2. 特に不満が無いと言うばかりで何も要求がない。

ここで、1は嬉しい悲鳴です。
中には既にシステムで実現できる事もあったりして、すごく刺激的な時間になります。

一方2は厳しいですね。
大体の場合は「不満はあるけど、言った者がやらされるからやめておこう」であったり、
「部内の○○部長の機嫌を損ねそうだからやめておこう」といったネガティブな理由が多いです。

上司に怒られる部下

そういったところも、やわらかく突いていくスキルが求められます。

例えば、

「私だけならいいんですが、○○業務ってもっとこうできたらお互いラクですよね?」

っていう振りをすると、

「それ、よく言われるんですよ。私も実現したいんですが、実は、、」って裏話も聞けたりします。

教科書通りの言葉で言えば「ユーザ部門の立場にたってモノを考えること」が大事です。

会議

プロジェクト計画のリソース調整には要注意

次の山場は社内稟議ですが、下記にまとめてありますので見てみてください。

関連記事:社内SEの最もタフなタスクは社内提案。社内なのになぜ大変なのか

これを乗り越えてベンダに発注し、プロジェクトキックオフ間近になると発生するのがプロジェクト実行計画の立案です。
ここではリソース調整で社内折衝が発生します。

簡単にいうと。ユーザ部門の誰がこの案件の担当になるのか。を決めることです。

ここで注意しないといけないことは、

ユーザ部門の担当者は通常の業務量を全く減らされないまま、システム対応の業務をします

優先されるのは通常の業務ですから、システム対応はどうしても優先度を下げられます。
また、担当者となる人は概ね「仕事ができる人」なので、どうしても業務量が多い傾向にあります。

Image by Dropbox Navi

私は担当者が忙しい場合は、下記を心がけています。

  • 副担当者(入社2~5年目が多い)をアサインし、宿題事項は副担当者に持ち帰ってもらう
  • 週○時間までと決めて、絶対にその打合せには出てもらう
  • 上記を担当者の上長と合意する

なかなかココまでやってても、すっぽかされることが多いですけどね。

業務とシステムの通訳が求められる要件定義、受入フェーズ

無事にキックオフが済むと、次は要件定義です。

私が関わった中では、ほぼ間違いなく

要件定義になるとシステムが主語になり、ユーザ部門の人間は戸惑います。

情シスの人間としては、ベンダ側が話す仕様を業務上の制約に置き換え、
ユーザ側が話す業務上の要望をシステム要件に置き換える通訳が求められます。

これは私にとってはスゴく楽しく、タフな仕事です。
何がタフかというと、業務がわかってないと何の役にも立てないからです。
(強いて言うなら、打合せをセッテイングするくらいかな)

パズルをあわせる人

いかがでしたでしょうか。
社内なのに中々大変な仕事だということはわかって頂けましたか?