社内SEと属人化の世にも奇妙な物語。

  • このエントリーをはてなブックマークに追加
  • Pocket
社内SEと属人化の世にも奇妙な物語

社内SEや企業のIT部門は、その企業の中で少し特殊な技能を持った社員となります。

その技能によって「自分にしかできない仕事」があるのは喜ばしい事ですが、組織の中では必ずしも良い事だけではない「諸刃の剣」でもあります。

「自分にしかできない仕事」は「属人化」であるということ。これらの関係性を「ある物語」から分析します・・・。

とある社内SEの仕事

AさんはITベンダー企業のシステムエンジニア(SE)でした。

AさんはB社の基幹システムの開発を担当し、B社の社長や担当者からの信頼も厚く、仕事の出来るSEとして評価されていました。

ある日、AさんはB社の社長から直々に「うちの社員にならないか?社内でうちのシステムの面倒を見て欲しい。」と声を掛けられます。

Aさんは、B社の社長からの要請に意気を感じ、在籍していたITベンダー企業を退職し、B社へ入社しました。

自分の手掛けたシステムを保守開発する社内SEの誕生です。

B社でのAさんの仕事は、システムの不具合対応や、システムの追加機能の開発、各種のメンテナンスなど多岐にわたります。

1名の部下を付けてもらったものの、自分で作ったシステムなので、部下に仕事を教えて任せるよりも自分で手を動かした方が圧倒的に早かったため、IT部門の責任者という立場にいなから常に忙しく自分で作業をしていました。

やがて、B社のシステムも入れ替えの時期が迫ります。古くなったB社システムを新システムに入れ替えるタイミングがきました。入れ替えの理由は、B社の規模も大きくなり、Aさんが手がけたシステムでは対応できない業務も増えてきたためです。

Aさんはここではっと気づきます。

「システムの事は熟知している。新システムへの入れ替えには賛成だし、自分が中心になって進めるべきだと思っている。しかし、現状まだ稼働しているシステムの保守対応をしながら、新たに新システム導入のプロジェクトを並行するのは仕事量的に無理だ!」と。

システムの事はAさんに一任しているB社社長は、そんなAさんの状況を知らず、新システム導入のプロジェクトマネージャーにAさんを指名します・・・。

自分にしかできない仕事の落とし穴

上記のAさんの例は、社内SE誕生の一例ですが、同じような話を何度か聞いたことがあります。なので、担当SEを引き抜くのは意外と一般的なのかもしれません。

ここで注目すべきはAさんの仕事ぶりです。

職人気質のSEにありがちですが、とにかく自分で手を動かすことが大好きで、何でも自分でやりたがる人は多いです。このタイプの人はマネジメントには向いていないタイプとも言えます。

Aさんがマネジメントが得意ではないから、他にマネジメントできる人がいれば問題は解決するのかといえば、そうとも限りません。

Aさん自身が自分にしかできない仕事を自ら作り出しているのだとしたら、Aさんが変わらなければ組織は良くなりません。とにかく、Aさんの頭の中にしかない情報資産を表に出さなければいけないのです。

キツイことを言うようですが、Aさんは自分の仕事を部下に引き継がせず、自分にしかできない仕事を自分の中に閉じ込めることで、Aさん自身の価値を高めようとしている可能性が高いのです。

「システムの詳しい事はAさんしかわからない、だからAさんを頼ろう!」と、周りから言ってほしい、そんな状況を作り出しています。

情報を公開することを防ぎ、その情報を使って自身の価値を上げているとしたら、組織にとって良い事はありません。そもそも、Aさんが隠し通したい情報は、Aさん個人の物ではなく会社の資産なのです。

結果として、Aさんの仕事の属人化行為は、Aさん自身の首を絞めることとなります。

どうやってこの局面を切り抜けるべきか?

Aさんには部下がいましたが、システムの詳細に関するほとんどの仕事はAさん自身が直接対応していたため、雑用ばかりしていたことになります。雑用ばかりの仕事だとしたらAさんの部下のモチベーションも高くないと推測できます。

このような状況では新システム導入プロジェクトはスタートできません。スタートする前に、まずは現行システムの仕様を明らかにすることから始めなくてはなりません。

しかし、状況から考えて、システムの仕様書がドキュメントとして残っている可能性は限りなくゼロに近いと言えます。一人で対応する状況では、誰かのためにドキュメントを書き残す意味もないため、ドキュメントは存在しないはずです。

ドキュメントを書かないエンジニアの唯一のよりどころはプログラムソースとなりますが、長い年月使われたシステムほど、追加改修により複雑に入り組んだ、いわゆる「スパゲッティコード」となります。スパゲッティのように絡まったプログラムは、ほとんどの場合、書いた本人すら内容を忘れています。

スパゲッティコードのプログラムは、例えるなら、筋の通らない小説のようなもので、さっき死んでしまったはずのキャラクターが再び目の前に登場するような意味不明な物語になっています。

どんなに「文法的に」美しいプログラムを書いても、ストーリーが支離滅裂なら何の意味もありません。

現行プログラムのソース解析作業を軽く見積もるととんでもない目に遭います。特に「文法的に」美しいプログラムだけを見て、簡単に解析できると思ったら大間違いです。

何の名残りでこのロジックが残っているのか?何の意図でこの変数なのか何か特別な意味があるのか?といった謎を一つ一つ解明するのは、もはやITの領域を超え、遺跡発掘の考古学の領域と言っても良いくらい大変な作業です。

属人化した仕事とブラックボックス化した仕様、そして残されたスパゲッティコード。これらを見て見ぬふりしてプロジェクトをスタートさせれば、たちまちデスマーチへまっしぐらの危険なプロジェクトの出来上がりです。

まずやるべきことはAさんの頭の中にしかない情報をすべて吐き出してもらい、まわりに見えるカタチにアウトプットすることです。ただし、渦中のAさんのようなタイプは「コードは書けるが文章が書けない」タイプだったりします。そうなるとアウトプットにとんでもなく時間が掛かるかもしれませんが、絶対に必要なことです。

本質は人を育てること

まず大前提として、目先の利益を優先するのではなく「価値を与える人になる」ことです。

自分しか知らない情報を囲い込むことで自分の価値を上げようとする戦略は、一番やってはいけない戦略です。これでは折角の情報という価値を「与える」のではなく「奪う」行為です。

そして、「与える」のにもタイミングがあります。「与える」のは、相手の「受け取る」行為が無ければ意味がありません。貯め込んだ情報資産を一気に放出したり、出しっぱなしにしたりのような雑な与え方では、受け取る側が受け入れできません。

特に、長年貯め込んだ情報資産やノウハウは、相手に受け取りやすいように段階的に出すべきものです。価値を与えるのは大事ですが、ただ出せば良いというわけではありません。タイミングをはじめ、受け取る側への丁寧な与え方が最大の効果を生むのです。

価値を適切なタイミングで与えるという観点で考えると、「人を育てる」ことに通じます。

人は誰しも寿命があります。持っている資産は次の世代へ引き継がれます。仕事も同様で、後継者を育てて、持っている資産を引き継ぐことは自然の摂理とも言えます。

組織の中で「自分しかできない仕事」があったとしたら、自然の摂理に従い、積極的に他の誰かができる仕事になるように人を育てるべきです。

特に、社内SEや企業のIT部門は、その企業の中で本業とは少し違う特殊な技能です。他の間接部門と違い、専門性が深くて知識の習得には時間が掛かります。

人の育成と企業のIT部門としての在り方を明確にして、人と部門を育てることが忘れてはいけない本質です。

人の育成が出来ていないと気付いた時には手遅れです。くれぐれも手遅れとなりませんように・・・

  • このエントリーをはてなブックマークに追加
  • Pocket

社内SEへの転職 はじめの一歩

社内SEへの転職「はじめの一歩」は転職サイトに無料登録してみることです。


社内SEへの転職は、エージェントが紹介してくれる「非公開求人」に注目です。社内SEは募集人数が少なく、すぐに募集が締め切られてしまいます。あなた自身の転職希望のタイミングと合うか合わないか、ご縁次第かもしれません。


ご縁を引き寄せるためには日ごろからアンテナを張っておくことが重要です。今すぐ転職の希望が無くても、貴重な情報をキャッチし、ご縁に繋げるために、無料登録だけでも済ませておくと有利になります。


詳細はこちら。




 


システムエンジニアラボラトリーでは無料メルマガ会員を募集しています。


もれなく「失敗ITプロジェクト事例集」が無料ダウンロードできます。


無料メルマガ登録はこちら

SNSでもご購読できます。

スポンサーリンク

コメントを残す

*