戯言。ベンダーコントロールのスキルって、つまりはどういうこと?

徒然草2.0

「私にはベンダーコントロールの経験があります。あれこれこういうことをしてきたよ」と、いうことをアピる機会が何度かあったが、そもそもこれってスキルなんだっけ?と内心は思っていたりもする。

なんだか、決まり文句のように使われていて世の中的に特に人材市場においてスキルの1つと数えられるらしいので使っている。人事部門の人が「ベンダーコントロールのスキルもおありなんですね」と言うものだから、こちらとしてもスキルなのか、と自覚をしたわけですが、言われるまで自覚ないもの。そもそも、スキルかどうか怪しいと考えています。

評価者がスキルだと解釈する=武器になるなら、眼の前でチラつかせて損は無いくらいに考えているが、もしスキルだとしたらそれはどういうものなのだと捉えるのが正しいのか。逆に私が面接官だったとしたら、事業会社のシステム部門に所属していれば自然発生する仕事をアピられても「それは武器なんでしたっけ?」と言ってしまいそう。別に相手を試しているわけではなく本人の認識を聞き出したい。それがなんらかの知識であれば知識があることを証明できそうだが、システム部門の付随業務なので他人に説明しづらくないか。自分のスキルを棚卸していたらポロりと出てきた棚ぼたスキルについて考えている。経験に根ざしたTips集で、こういう時はこうする、ああいう時はああする、の一部にベンダーコントロールスキルのノウハウは含まれていないことはないし、ベンダーコントロールに関するそれだけを抜き出せば本にすることはできなくもない。社内SEは楽ちんで定時上がり♪みたいなSES会社勤務の人からすると夢の仕事だと思われていなくもないなら、そういった人向けに「ベンダーコントロールスキルを身につけて社内SEに転職しよう!」みたいなフレーズで必要な知識を切り売りすることができますね。それだけを身に着けて転職できるとも思わないけれどハウツー本としては初めてのベンダーコントロール経験に戸惑いを感じている人に身に着けて欲しい知識や交渉術を授けることもできるのではないだろうか。

まあ、体系的な知識として、情報システム開発から切り出せるようなものなのか?というと怪しいと思っている気持ちはなくもないのだけど、少なくともスキルというくらいならば、システム開発プロセスとは別に切り出せる知識体系としてまとめることはできなくもないだろう。などと勝手に思いを巡らせてみたかったので、この記事はその走り書きです。

ただネットで軽く調べた限りでは、少なくともベンダーコントロールは体系的な知識が求められるようなものではなかったですが。。

話を戻しますが、結局のところ会社のシステム部門で開発会社との折衝に取り組んだかどうかぐらいのニュアンスでしかないのだよな。

つまりは、ベンダーコントロールの経験は、書き出そうと思えば幾らでもその大変さをふくらませることができるが…業務知識と情報システム、双方の知識が満遍なく持っており、対ユーザと対ベンダーの異なる立ち位置の人と適切なコミュニケーションをとる、橋渡し役に過ぎないのではないか。とはいえ、別にこの仕事は意味や意義がないというつもりはあまりないが、特段アピールするようなものでもないのではないか。

というわけで、もう少し別方向からベンダーコントロールなるものへ視線を向けて考えてみたい。

ベンダーコントロールの存在価値はないように見える件

動画「存在価値が無いタイプの情シス・社内SEの人」を見てもあんまりピンと個人的にこなかったがw、案の定コメント欄を見ると「この人は優秀」「あ、これ俺だ」という回答が多かった。

たしかに動画はユーザからベンダーへ横流ししているだけ。特に社内の人=ユーザ部門からすると、この人いる意味あるの?という印象は受けるかもしれない。

不幸中の幸いでトラブルになっていないのならば、十分に存在意義はあるわけだが。この情シス・社内SEが社内から評価されるかは、社内評価制度によるところが大きい気もする。

早い話が第三者からみてベンダーとユーザの間にいるシステム担当って必要なんだっけ?って思われがちだということを表していると理解しているが↓

もしこの人が動画が撮影されていないところで、ユーザの要件定義をそのまま実装しても既存システムやユーザ部門の業務に影響がないか?を考えるプロセスが省かれず行われているのであれば、これはこれでいいのでは?という気がします。

つまるところ、仲介するシステム担当者の必要性はケースバイケースだということ。

ベンダーコントロールにおける具体的な失敗とは

しかし…これだけだとよくわからないので、この仕事の失敗あるあるから定義してみればいいのかもしれないと、思いついたので書き出してみます。

1.システムにユーザが望んだ機能が追加されなかった。

2.システムにユーザが望んでいない機能が追加された。

3.納期が間に合わなかった。

1と2は本質的に同じで、単純な抜け漏れというよりは、ユーザ部門との意思の疎通が正確に行われなかったがゆえに起こるミス。

お互いに、正しく伝わっていると思い込んでいてベンダーに誤った情報が伝わってしまう他、ベンダーが勘違いしてしまうこともありえる。

その場合、機能を作り直すことになり、納期やコストの負担が嵩んでくる。ユーザ部門の不満も募る。

結論

・ベンダーとユーザをつなぐシステム担当者の経験であるベンダーコントロールに体系的な知識はない。

・しかしながら、社内に担当者を置いておかないとコミュニケーションに齟齬が生じた時の被害は甚大だから、責任者を置くのは適切である。DX化が進んで社内のユーザがITに詳しかったとしても、将来的に無くならないポジションではある。ただし、数年この仕事をやっていると、時代の変化に取り残される。また、会社にとって不要な仕事に思われがち。他の仕事においても付加価値を付けないとやってられない役職ではないか。

コメント

タイトルとURLをコピーしました