A Day In The Boy's Life -110ページ目

A Day In The Boy's Life

とあるエンジニアのとある1日のつぶやき。

無難な格好、無難なデザイン、無難な意見。

Yahoo!辞書(大辞泉)で「無難」を引いてみると、下記のような答えが返ってきます。


1 危険のないこと。また、まちがいのないこと。また、そのさま。無事。「―な日を送る」「貴重品は持って行かないほうが―だ」
2 欠点のないこと。特にすぐれているわけではないが、格別の欠点も見当たらないこと。また、そのさま。「―な歌い方」「―にまとめた演技」

先ほどの例の意味で言えば、2番目の欠点が無いことって意味に当てはまるわけですが、「無難」と聞くと少しネガティブな印象を受けたりもします。

特に優れているわけではない、というところが大きなポイントになってくるんでしょうけど、欠点も無い故に万人ウケする可能性もあったりするわけです。

ただ、いざその無難というものを表現しようとすると難しかったりもするわけで。



奇抜なファッション、無難なファッション


例えばファッションで言ったら、一般的にお洒落というと雑誌のモデルが着ているような服装に身を包んでたりもするわけですが、それって結構奇抜だったりもするわけです。

雑誌やテレビの中の世界なのでそれが妥当に見えたりもするわけですが、現実世界でそういう服装の人を見ると、お洒落というよりは「派手なやつ」という印象を持ったりもします。


一方で「無難だね」といわれるファッションは、その人を引き付ける魅力は無いにしても、悪い印象をもたれることも無かったりします。

お洒落というのは、個人によって好みも大きく変わってきますので、万人ウケするお洒落というのは存在しないと思います。

また、異性によっても感覚が違ってくるので、男から見たお洒落と女の子から見たお洒落な人って結構差があったりもします。


印象をもたれるファッションが良いか、強く印象に残らないファッションが良いのか、というと目立つこととそれを受け入れることは別なので、受け入れられるという観点で言えば後者の方に軍配が上がるのだと思います。



無難さの難しさ


無難というのは、何が一般的なのかということを知っておかなければできません

欠点が無いということは、その欠点を埋めておかなくてはならず、プラスにもなりすぎず、マイナスにもなりすぎてはいけません。

それってかなり難しいことです。


例えば、奇抜なデザインのTシャツと無地のTシャツがあったとして、そのどちらを使うかというと個人の好みによってきますが、相手が受け入れられるものを薦めなさい、とするとほとんどの人は無地のTシャツの方を薦めるのではないでしょうか。

その方が受け入れられる可能性が高いので。


これはあくまで二者択一の場合であるから、どっちが無難かということがわかりやすかったりもしますが、何も無い状態で無難なもの、無難な意見、無難な格好を表現することはかなり難しかったりします

自分の考えでなく、世間一般的に受け入れられるのはどういうものかわかってないといけないからです。

この意見は無難だとか、この服装は無難だろという自分自身の考えは、周りから見れば奇抜に映っているのかもしれません。



先に書いたように無難というとぱっとしない印象もあったりもするわけですが、その無難という自分の考えそのものがずれている可能性もあるわけです。

自己の表現として奇抜な意見や奇抜な格好をするのも良いかと思いますが、何が一般的でそこに要素としてプラスしているものは何かということを知っておかないと、全く視点がずれているという場合もあると思います。

なので、まずは本当の無難さを知るというところも大事なのではないかと思うのです。



それが良いかどうかという議論は置いといて、きっかけとして技術っていうのはそれを身につけざるを得ないという状況に追い込まれた方が習得しやすかったりします。

次の仕事で使うからとか。


一方で新しい技術を使うというのは当然リスクもあったりするわけですから、その仕事でそれを使うかどうか判断が難しい場合もあります。

そして、社内のシステム開発なんかをする情報システム部門にとっては、そういったリスクを回避する意味も含め、新しい技術というものを取り入れようとするメリットが少ないケースもしばしばあります。



強制的に身に着ける技術


エンジニアをやっている場合、仕事からその技術を学んだということは最も多いケースでしょう。

自己学習するということも考えられますが、そこまでのモチベーションがあがらなかったり、それを職場で活かせなかったりして、思いとどまることもあると思います。


こういう場合、「次の案件はJavaだから勉強しといて」とか「今後のサービスの拡大を狙ってRubyの開発ノウハウを溜めておきたいから使おう」という方針を打ち出して、強制的にその技術を使わざるを得ない状況に追い込まれたら、身に着けるという観点では楽なものです。

もちろん初めてその技術に触れるというところでは大変な場合が多いでしょうが、結果としてそのプロジェクトが終了した頃には一通りのことは理解できているという状況を生み出すこともできます。


これは組織としての方針の流れに身を任せれば、それを習得できるということになります。

そして、組織としてその技術を使うことへの協力体制を作ってくれたりもします

自分でこの技術は凄いと思った場合、その流れを作り出すためには、そのメリットをわからせて納得させる必要があり、多くはそのメリットを感じ取れない人がいるわけで、しかもその技術を理解するためには独学となるケースがあります。

そこまでのモチベーションと豊富な知識がある人であれば成し遂げられるかもしれませんが、単に「この技術使ってみたいな」ぐらいの漠然な考えを持っているだけではそこまで到達することは難しかったりします。


そんな中途半端な気持ちで学んでも仕方ないという考えももちろんあると思いが、一つの技術を身につけるきっかけとしては、そうせざるを得ない環境に追い込まれた場合と、自ら切り開いていく場合とでは、前者の方が圧倒的に身に着けやすいわけです。

誰しもそこまで強い意志を持ってやれるわけではないので、追い込む環境に持っていくことがその契機にしやすいのだろうと感じます。



レガシー化された環境で身に着ける技術


一方でなかなか、そういった新しい技術に出会わない職場というものもあります。

「その技術を使って予期せぬ問題が出たら誰がどうやって対応するんだ」とか「その技術って安定してるの?」とか「他社の事例が無い」とかネガティブな言葉を並べて、いつまでも後ろ向きな判断をしないケースもよく見かけます。


社内のシステムの場合は、安定第一志向のようなところがあり、わざわざ新しい技術を持ち込まなくても十分に要件を満たすシステムを構築することができると考える人も多くいます

または、新しい技術を取り込む場合は、実績のあるベンダーに任せ充実した保守体制の元で導入に踏み切るとか。


何れにせよ、そういった新しい技術というものを社内メンバーが触れるという機会を奪っているところもあるのかなと。

社内にある例えレガシーでも技術は技術で、ある一定のレベルまでその環境でエンジニアを育て上げることはできるのだと思います。

しかし、それ以上その中での進化が無い以上、それを越えるエンジニアが育つ機会もまた無かったりします。


先ほど言ったような独学で社内に持ち込もうとしても、そのメリットが理解されなかったり、協力体制を仰ぐことができなかったりで、最終的なゴールに結びつかず、またそのエンジニアも中途半端な知識を持つにとどまるようなこともあるのではないでしょうか。


社内で最新の技術動向を察知し、常にそれを検証し実践してみるラボのようなチームがあれば、そこから新しい技術を学ぶということもできるでしょう。

しかし、そうでもない環境でエンジニア個人に「技術は自分で学び自分で身に着けていくものだ」という方針を考えている組織では、なかなか一線を越えるエンジニアも育っていかないのではなかろうかなと。


繰り返しになりますが、それを身に着けざるを得ない環境に持っていってしまうことも教育の一環としてはありなんじゃなかろうかと思ったりします。




SEって、出世には興味ないよね? @ Tech総研


昔、自分もあんまり出世とかには興味なくて、自分のやりたいことができればいいや、なんて思ってました。

ただ、この年になって新しい人も入ってくるわけで、否応なしに押し上げられるところもあり、出世したとまでは言いませんけど、その頃とは違う立場にいたりします。



上に立つという事への先入観


同僚で、「上流工程をやりたくないから今の地位でいいです」と昇進を断った人がいたりしますが、上に行けばいくほど、面倒な立場に追いやられるというイメージがあります。

上の立場になるとマネジメントという名の元に、後輩への教育や管理などの仕事が増えてきます。

これはどの職種でも一緒だと思いますが、技術系の場合はそれまでの仕事と、上の立場になったそこからの仕事というもののギャップに拒否反応を示す人も多いのではないかなと思ったりします。


技術系の仕事をしていて、物づくりが好きという人がそれを取り上げられて、全く興味の無い世界へ引きずりこまれていく。

それぐらいであれば、出世しない方がいいかな、なんて考えを持っている人もいたり。


私も最初の頃は、そういうのを敬遠してたりもしましたが、決定権が何も無いプログラマレベルだと、どうにもならないことが多いのもまた確かです。

むちゃくちゃな上流のせいでデスマを突入したとしても、その人に文句の一つは言えても、その仕事をやることを拒否しているという矛盾している自分もいたりするわけです。

好きなことをやれると思っていても実際はそうでもないことも多いわけで、実際は単にコントロールされているだけだったりする場合もあります。

だったら、自分が上に立ってコントロールできるようにした方が自分も周りも幸せにすることができるのではないかなと。



上か下かの世界


IT業界の世界って上流工程を取るか、下流工程を取るか、という二者択一しかないところに問題があるような気もします。

上に上がるなら、下の工程はやるなといわれるからこそ、余計に今好きな下流工程にしがみつきたくなる気分になる。


どちらもできるはずなのにその選択肢は無く、「お前はもう後輩を育てていく立場だし、これからはマネジメントスキルを身につけていくことがお前のキャリアパスになるんだ」と、下流工程の仕事自体をすることを許してくれなくなったりします。

致し方ない雰囲気に持っていき、そこに落ち着けることが30歳定年説みたいなものの引き金になっているのかなとも思ったり。


もちろん、やれるならやっても良いという環境もあるでしょう。

ただ、いざ上の立場になると「管理職エンジニアが伸び悩む理由 」に書いたようにやることが多すぎて、下流工程なんてやる時間がないというところもありますし、立場を間違えてその仕事を放置してしまえば、管理がおろそかになり、現場自体があらぬ方向に行ってしまったりもします。


上には上としての仕事が、下には下の仕事があるのはわかりますが、妙にその白黒の領域をつけようとするところがSEの出世欲をなくす一因にもなったりしているのではないかと思ったりします。