自分がやってもらって嬉しかったことを、他人にもやっていこう
現場が変わると文化も変わる
SESでの仕事だともっとも顕著に現れるのですが、プロジェクトが変わると同じ社内でも全然文化が変わります。作業手順、文書のフォーマット、使用しているツール、プロジェクト・マネージャの指針、などあげればキリがありません。
そんな中、多くの現場を経験していると、以前の現場で有効活用していたツールを他の現場でも活かそうという考えが出てくるのが普通です。
謎ルールによってツールが使用不可というのもよくある話
同じ社内なのに、上司のよくわからんルール、顧客の理解できない開発の縛り、情報漏えいなどから認可されたツール以外禁止、怪しいツールで問題があったらどうする？という責任のなすりつけあい、など職場独自の謎ルールより◯◯以外は使用不可とお達しがでていることもあります。特に大企業系。
こういう謎ルールが多いからこそ、開発の効率を無駄に落としていたり、社内独自ルールの多さから他の会社では仕事ができない不安、恐怖が染み付いてしまう、といった弊害も多いのではないかと個人的には感じているところです。
以前、こういうのを辞めて効率化しようと構造改革しようとして失敗した経験もあったりしますが、何もしないより経験して改善していくのは大事なのでは？とも思ったし、同意も得られました。
ツールがダメなら考え方や行動をパクろう
・どんな風にやったら信用を得られるか？
・どんな風に進めたら失敗が減るか？
・どんな提案をしたらカドが立たないのか？
・どんなフォローをしたら喜ばれるのか？
・何を自らどんどんやったほうがいいか？何は確認しないと危ないか？
いろんな現場の先輩、上司から教わって学んだことがあります。これは逆に職場に伝わる良い文化だと思います。こちらについては職場をまたがって良いものは良いと伝えてもあまりカドが立ちません。だからこそ、自分がやってもらって嬉しかったことを他の現場や自分の部下や後輩に伝えていくことは大事です。
フリーランスになった私は、後輩や部下というものがいません。だけど職場では色んなことを教えるシーンがあります。そういうのは正直面倒くさいし大変ですが、それだけで信用・信頼を積み重ねることができてきます。
こういう信用・信頼はのちのちの単価交渉にも役立つし、現場を離れても人脈として残っていきます。ITエンジニアとしてスキルも大事ですが、こういう事もしっかりやっていくことも社会人として大事なことだと思いますよ。
------------------------------------------------------------------------------
ITエンジニア以外のお仕事についてブログをやっています