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

A Day In The Boy's Life

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

スキル依存症 @ 101回死んだエンジニア


スキルを磨けば磨くほど確かにできることとできないことがはっきりしてきます。

時間は物理的に越えられない壁になるので、そこに費やす時間量というのは限界があって何に時間を割くかということになってしまいます。

極端に言えば、これは俺がやる(できる)仕事、これは俺がやらない(できない)仕事というような切り分けにもなってきます。



スキルを集中化するリスク


ただ、当然スキルを一本に絞るというのはかなりリスクを伴うことでもあります。

技術的なスキルであれば、そのスキルがいつまでも通用するわけも無く、時代の流れとともにガラっと中身が変わっていくということもしばしばありますので、それについていく努力をやめた時点であの頃の栄光にすがってだけ生きていくような状況にもなりかねません。

「俺も昔、○○をやってたんだよ」みたいな過去の経験をちらつかせる人の話って大抵的外れなことが多かったりもしますからね。

別に技術だけの話ではなくて、業界そのものがなくなってしまうということも考えうるでしょう。


あと、スキルを磨くってよく言われる台詞ではありますけど、そう簡単なものでもありません。

本当に特定のスキルが一級品とみなされる人ってほんの一握りですし、探せば探すほど自分より上の人なんてたくさん出てきます。

斯く言う自分も技術的なレベルというのはたいしたことが無いということが痛感している人で、それ以外のもので補ってキャリア形成できればいいかな、見たいな事を思ってたりします。


それは、技術的な難しさそのものより、そこにどれだけの労力と時間を費やせるのかというのを考えると、がむしゃらにしかもただただ楽しそうにその道を突っ走っている人には到底かないそうにないしまねできそうも無い、って言う理由であったりしますが。



中途半端な人でも働ける環境の存在


少し皮肉っぽく書いてしまいましたが、そういう人って凄いなと思いますし、尊敬できる人です。

なので、そういう人たちが活躍できる場所っていうのは、そんなスペシャリストな人たちに任せて、自分はその他のところをサポートできればいいなと思ったりしています。

スペシャリストな人が活躍できる環境って、色々な条件がそろわないとなかなか本領発揮ができなかったりもするので、なかなか見つかりにくいって思ってたりもしています。

なので、そういう裏方の仕事もあるんだなと。


一つのことに特化した能力のある人って当然他方で苦手なことも多かったりします。

技術的なスキルレベルが平均であったとしても、平均でわかるレベルでスペシャルな人から情報を聞きだして、自分が通訳のようにさらにスキルレベルを持たない人との間に入ればそれだけで存在意義も出てきます。

最高レベルの人と最低レベルの人とでは当然会話がかみ合わないわけですよ。

会話術がトップレベルなら話は別ですけどね。


全員が全員何か1つのことしかできないって状況になったら当然世の中回らなくなるわけで、中途半端に持ち合わせた人でもそこに存在意義が生まれる仕組みにはうまくなっていたりするもんだなと思ったりしています。



どうやってスキルを見つけるか


それ相応の社会人歴を経ると「あぁ。俺これで食っていこう」みたいなものが見つかったりするでしょう。

もちろん、それがあきらめの境地としてたどり着いたのか、天職として見つかったのかでは大違いですけど。


新人に様々な現場や環境の経験をつませるという教育であれば、その中から自分のやりたいこととを見つけてステップアップするみたいなキャリアも描けるかもしれませんが、最初から一本に絞られた場合、その道が閉ざされた瞬間、一からのキャリア形成をする羽目にもなります。

最初から正解のキャリアパスを描けるなんて早々ないので、試行錯誤の経験の末「これが自分に合う」というものを見つけていくしかないと思います。


そこでこれだと思うものに残りの時間をかけて集中すればそこに特化した自分というものも生まれるでしょうし、この辺りかなという漠然としたフィーリングを感じていたとしても、先に書いたように中途半端でもいいように立ち回れる自分というものを生み出すことにもできると思います。


スキルというのは経験を持つための武器にはなります

レベルは問わず、何かができるということになればその経験をすることができるでしょう。

要はわらしべ長者みたいに、自分の持っているスキルでステップを重ねていくというやり方も取れると思います。

口だけうまくなってもしょうがないので、次のステップで今までのスキルに磨きをかけたり、新たなスキルを習得するという努力は必要でしょうけどね。



まとめ


結局のところ、スキルというのが何なのか自分でもよくわかっていません。

自分が持っているエンジニアとしての技術がスキルの一つなのかと言ってもそれだけで食っていけるかというと厳しいと思っています。

少なくとも、サッカーが凄くうまいからサッカー選手になれるというほど、サラリーマンの世界って単純ではない気がします。


あと、スキルって磨くだけじゃなくて今自分が持っているものをうまく掛け合わせていくことでもオリジナルのものを生み出せたりもできると思ってます。

関連性の無いスキルをやたらと身に着けていくよりは、自分の持っているスキルに何を足せばどんなことができるとかを考えていくことも重要なんじゃないかと感じています。




純粋なJavaScriptを利用している場合は、JavaScriptが無効になっている状態でアクセスがあった時のためにnoscriptタグを実装しておくということができますが、jQueryを利用してnoscriptを使う場合にはかなり限定的で簡易的な実装となってしまいます。


jQueryでDOM操作している部分をうまく代替の要素を表示できたり、jQuery内で複数利用しているプラグインに対してJavaScriptが無効になっていた場合、個々に表示を切り替えることができればユーザー側にもわかりやいサイトになります。



CSSとjQueryを使ってNoscriptに実装する


JavaScriptが有効になっている場合、jQuery自体が利用可能になっているため、そのDOM操作のメソッドとCSSを使えば、比較的簡単に実装することができます。


<html>
<head>
<style type="text/css">
.jsenabled {
    font-weight:bold;
    border: 2px solid #0000ff;
    padding: 5px;
    width: 400px;
    display: none;
}

.jsdisabled {
    font-weight:bold;
    border: 2px solid #ff0000;
    padding: 5px;
    width: 400px;
}
</style>
<script type="text/javascript" src="js/jquery.js"></script>
<script>

$(document).ready(function() { $(".jsenabled").show(); $(".jsdisabled").hide(); }) </script> </head> <body> <div class="jsenabled">JavaScript is enabled</div> <div class="jsdisabled">JavaScript is disabled</div> </body> </html>


CSSは、ごちゃごちゃ書いていますがほとんどはDIV要素をわかりやすく装飾するためのもので、重要なのはJavaScriptが有効であった場合に機能する、jsenabledというクラス名の中に「display: none:」を設定しておくというものだけです。

要は、JavaScriptが無効だった場合は、この要素が見えないように予め設定しておくというものです。


次に、JavaScriptが有効だった場合はjQueryが動きますのでDOM構築後の$(document).ready時に、JavaScriptが有効の場合のクラス(jsenabled)を表示し、無効だった場合のクラス(jsdisabled)を非表示にするという処理をしています。


実際に動作させてみると


- JavaScriptが有効だった場合

A Day In The Boy&#39;s Life-jQuery-noscript2
- JavaScriptが無効だった場合

A Day In The Boy&#39;s Life-jQuery-noscript1

と、それぞれの状態に応じて表示を切り替えることができます。

予めjQueryによって書き出すDOM要素が決まっていれば、その部分をCSSとjQueryのメソッドだけで表示/非表示に切り替えたり、メッセージや画像を表示しておくなんてことも対応できます。


少し対応方法が異なりますが、Youtube上に同様にJavaScriptを無効になっていた場合にjQueryで表示を切り替える方法がチュートリアルで紹介されています。

こちらは、hideやshowメソッドを利用するのではなく、removeClassを使うやり方。


Noscript Styles with JQuery - Tutorial


noscriptを使わなくても、うまく表示を切り替えることができるものですね。





トラブルが発生したときというのは、その対処に追われることになるものの、多くはその際のエスカレーションパスに従って報告というものが付きまとうことになります。

ただでさえトラブルが起きて緊迫し、誰もがピリピリしている中でその状況報告をするというのは、結構厄介なことです。

わかりやすく状況を伝えないととか、自分のミスで・・・ということになれば余計に気後れして、正確な情報を伝えることができません。

そして、それを受けた上司や客先の担当者は余計にイライラを募らせ、怒り心頭になったりもします。

そんな悪い人のトラブル報告ってどこが悪いのでしょうか。



サービスの問題とトラブルの原因がごちゃごちゃになっている


まずはトラブルが起きた際には、今起きている状況を正確に伝える必要があります。

特に多くのユーザーに利用されているサービスであれば、その影響範囲やその障害によってユーザー側で何ができ、何ができない状況にあるのかということを知りたいと思うわけです。

サービスを提供する上でどんあ問題が起きているのかということを正確に把握できないと、それへの対処というのも当然正確に指示することができません。


ネットワークスイッチの障害ですとか、DBにトラブルが・・・と言われたところでシステムの構成をよく知る人ならまだしも、そうでない人にはそれによってどんなことが起きているのかがそれだけで掴むこともできません。

大規模なサービスになればなるほど、システム構成要素はおおくなるため、一箇所での障害がどれほど広範に影響を及ぼすのか、システム担当者ですら把握しきれていないこともあります。

システム責任者であってもそれによってシステムのどんな機能やサービスに影響が出ているかよくわからない場合もありますし、ましてや客先の担当者ともなればその報告は原因であって問題ではないと感じることが多々あるでしょう。


システムトラブルの元になっている、機器の障害やデータの不整合の発生やオペレーションミスなど、それらはシステムトラブルの原因でありサービス上の問題をあらわすものではありません

要は、技術者よりの問題というものとそれを総括する立場にある人にとっての問題というのの視点と認識がずれて報告されていたりするわけです。



目の前の対処と恒久的な対応の伝え漏れ


トラブルが発生したらまずは、サービスを正常化するために対処を始めるわけですが、トラブルの根本を解決するためにはそれなりの時間がかかったりもするため、とりあえずサービスが動くようにするための場当たり的な対応がなされたりもします。


機器の故障などになれば、保守業者に連絡して機器交換をしたりもしますが、到着と交換の完了や切り戻しのテストなどをしていたらかなりの時間になったりもしますので、代替機器を投入したり機能を他の機器へ移行してサービスを提供できるような状況にしたり、障害箇所の機能だけを停止してしまって、その他のサービスを提供できるようにしたり。


こういったことって、後々その一時的に対処した構成変更などを元に戻したりする作業も必要になるため、今回のトラブル時に行った取りあえずの対処というものが何なのかをはっきり伝えておく必要があります。

今回の一時的な対応により、何がどれだけの期間で回復するけど、それによってこんな弊害もありますよってことを伝えておかないと場合によっては、その一時的な対処を元に戻すためにサービス自体を再度停止しなければならないなんてこともあったりしますので、「あの時の障害対応は一時的なもので、本来の構成に復旧するために再度メンテナンスを実施する必要があります」なんていったところで「なんで?」ってなったりするわけです。


一方で、今後同じようなトラブルが発生した場合でもサービスに影響が出にくくするために、何かしらの対策というものが必要になってきますが、そういったものを考えられていない報告もあります。

機器故障に対応するために運用体制を強化しますとか言われても、そもそもトラブルが表面化しないための対策は講じないの?って事が言われてなかったり。

この辺のことって相手とのサービスレベルの握りでどうなっているかにもよりますが、今度起きたらこうしますではなくて、今後起こらないようにしますって事がはっきり言われてなかったりもするわけです。


まぁ、表面化するトラブルって言うのは、当初定めていた対策マニュアルの想定外のことが起きていたりするので、今後起きたらこうしますよって報告だけではすまない場合が往々にしてありますからね。



まとめ


問題のある報告というのは「問題」「原因」「対処」「対策」というものが一連の報告の中で揃っていなかったりします。

もちろんその内容は、伝えるべき相手によって異なってくるので、その報告する人の立場を意識しておくことも重要になるでしょう。


トラブル時には空気も緊迫していたりしますので、なるべく余分な手間を互いにかけたくありませんし、早期に解決すために的確な報告というものが求められてきたりします。

余計なことでトラブルを起したこと以上に相手をイラっとさせて怒られたりはしたくありませんからね。