seri::diary

日常

この春情報系出身じゃないけどSE/PGになった人へ その2

前回からの「1年目に独学で学ぶべきこと」の続きです。


3.Linuxの操作

「俺の会社Windows Serverしかやんねーよ!」

という人がたまに居たりしますが、それでも若いウチにLinuxの操作ぐらいはできるようになりましょう。
遅かれ早かれ使う機会がありますし、その時に「Linuxいじれません」だと色々とアレです。

また、他の人に作業をお願いするときにも専門用語で指示出来たほうが確実です。(これは他の分野でも言えることですが)


「でも俺ん家のパソコンWindowsだし自由に触れるLinuxサーバなんてないもん(´・ω・`)」

という人が多いと思います。

なので、WindowsでにVMware Playerという仮想化ソフトを使って
Linuxを仮想環境で動かしましょう。商用利用でなければタダです。

↓のサイト見ながらやってみて下さい。

参考URL
アカベコマイリ VMware Player + CentOS

で、とりあえず以下のやり方だけでも覚えましょう

・ログイン/ログアウトの仕方
・ユーザ変更の仕方
・ファイル使用権限の変更の仕方
・ファイルの閲覧・コピー・移動・削除の仕方
・viの基本的な使い方
・topコマンドの見方
・psコマンドの見方

参考URL
再入門 体で覚えるLinuxの基本

とりあえず最低限でもこれだけ出来れば先輩に苦い顔をされずに済みます。

また、「マクロ」みたいな感じのシェルスクリプトが書けると
同じコマンドを何度も入れる必要がなくなってラクできたり
ミスが減ったりと良いことづくめですので、余裕が出てきたら覚えてみてください。

私は運用保守専門でやってた頃は、ヒマな時にテスト環境で色々とシェルスクリプトを書いて遊んでました。(今でもサーバに残ってるかも・・)


参考URL
bashで始めるシェルスクリプト基礎の基礎
シェルスクリプト入門



とりあえず独学で学ぶ「技術的なところ」はこんなもんだと思います。
あとは否が応にも入ったプロジェクトに応じて学ぶことが出てくると思います。

プログラマになるんであればまだまだアレですが、
必ずしも「プログラミングを専門業務」としないSEの方向けですので。

ただ、自分で何か興味を感じたことについては、ぜひ自分で勉強してみてください。
最近だと、Hadoopの概要を勉強してお客様先で活用事例について軽く説明できるぐらいになっておくといいことがあるかもです(あくまで想像w)

今はブログで情報発進しているエンジニアが沢山いますので、色んなエンジニアのブログをRSSリーダーに突っ込んでチェックしてみるとよいです。


「1年目に仕事の中で学ぶこと」

これはSEだろうとそうでなかろうと同じだと思いますが、社会人として仕事をするために身につけるスキルって殆どは仕事の中でしか身につかないものです。
実際、SEであっても独学で学べることの方がよっぽど少なかったりします。
私の実感としては、8割ぐらいは仕事をしながらじゃないと身につかないスキルです。

どんなに筋トレをしたところでスポーツで活躍できないように、実践の中で自分を磨くことが仕事において非常に大切です。


では、何を学ぶ必要があるのか?
いっぱいあるし、ここでは書ききれないので、自分のSEとしての経験から抜粋して書いてみます。

メールの書き方

特にお客様に対するメールの書き方。
ビジネスの基本ですが、細かい言い回しや伝え方が非常に重要です。
メールの書き方一つでトラブルに発展することが多々あります。

私は起こしたことがありませんが、同じPJ内のとあるメンバーの障害報告メールの表現が不適切だったせいで、営業が部長連れて客先に謝罪に行くハメになったことがあります。普通に対処してればそこまでの事態にならなかったのに、です。

ただ、入社したばかりだと書き方の良し悪しなんてすぐに分からないものです。

なので、まずは先輩や上司のメールの書き方を徹底的にパクりましょう。
大体、どこの部署でも客先相手のメールにCcで自分も宛先に入れてくれますので、それを見て社内外に対するメールの書き方を学ぶことができます。
Ccに入れてもらえてなかったら「勉強のためにCCで自分にもメールを下さい」と言いましょう。
イヤな顔する上司はいないはずです。多分。。

あとは自信が無い時は送信するメールの内容をチェックしてもらいましょう。
謝罪だとか障害報告だとかの「慎重」になるべきメールは特に送信前に上司レビューを受けることが必須です。

話し方

これも社内外問わず重要ですが、特にお客様への話し方。

色々ノウハウはあるんですが、一番SEがやらかしがちで危険なパターンとして

「専門用語でぐだぐだ話す」

です。


障害が起きた時、何かの理由で開発スケジュール遅延が起きた時に
ぐだぐだと専門用語を使って説明しようとするSEがいますが、そんなもんお客様には分からんのです。

システムが止まった!何故だ!

RAIDコントローラーが物理的に故障してRAC組んでるOracleの片方のノードが止まって、生きてる方のノードにアクセスが集中し・・

なんていう、SEの間であれば普通の報告であっても
それをそのまま話しちゃうとお客様には分かりませんし、障害報告なんかだと「ホントに悪いと思ってんのかこいつ?」と思われかねません。

システムが止まった!何故だ!

ハード故障でDBが停止した為にシステムが停止しました。部品交換により取り急ぎ復旧しました。

ぐらいの感じで、「結論」を「簡潔」に述べる話し方を常に心がけましょう。
これは何を話す時もそうです。
多少簡略化してでも事実を「簡潔」に伝えるクセ。つけましょう。
これも上司とかを見てれば分かりますが、話し下手な人もいるので話が上手い先輩やらを探して研究しましょう。

私は幸いにも、お客様への説明が非常に上手い先輩が身近にいたので手本にしていました。
その先輩から、上記の「簡潔に説明する」「長くならないように上手くまとめる」話し方を叩きこまれましたが、そのせいか運用保守SE時代はなんかお客様からの評価もそこそこ高かったようです(何故か良く名指しで作業依頼されてましたw)


SEは必ずしも口がうまい必要はありませんので、とにかく相手に「解りやすく」伝える努力をして下さい。多分、これが出来れば仕事を無くすことはないと思います。

こればっかりは経験がモノを言いますので、常に意識してどんどん社内外のいろんな人と話しましょう。


おしまい

さて、なんか中途半端な気もしますが、この辺で終了です。

またなんか思いついたら書きますが、若いころじゃないと新しいことは中々吸収できませんので、ぜひぜひアタマが柔らかいウチに色んな事を学んで、しっかりとした土台を築いて下さい。