Kengo's blog

Technical articles about original projects, JVM, Static Analysis and TypeScript.

新たに技術者となった知人におくるはなむけの言葉

やあ (´・ω・`)
めんどくさがらずにメールのリンクを開いてくれてありがとう。今月から技術者として働き始めたそうだが、経過はどうだろうか。貴方が私と同じ職種になると聞いた時には驚いたものだが、こうして実際なってみると意外と違和感ないものだね。ひとまずおめでとう。
これから貴方はJavaを使ったサーバサイドプログラムを保守したり開発したりすることになると思う。そしてそこは私の主戦場であり、ある程度は力になれるかもしれない。ということで思うところをつらつら書いてみたので、居酒屋で変なおじさんに絡まれたと思って聞いてほしい。

コミュニケーションについて

意外かもしれないが、技術者が仕事をするうえでコミュニケーションとかヒューマンスキルとかいうアレはかなり重要だ。
技術は手段であり力だ。そして力をいかに行使するか、どう他人の役に立てるか、そもそも今何をすべきなのか、という判断にコミュニケーションが役立つ。
ので、まずはコミュニケーションについて書く。

話の種

とりあえずファーストガンダムジョジョは押さえておいて損はない。エヴァンゲリオンや通称「ニチアサ」も支持率高いけど必須ではない、が、エヴァは映画の連作がぼちぼち完結するので今から親しんでおくと楽しめるかもしれない。
いきなりガンダムかよ!と思うかもしれないが、同じ釜の飯を食うのは人と一緒に働く上でかなり意味があるのでバカにせず騙されたと思って観てみて欲しい。

中期的には先輩がデスクに並べているフィギュアやグッズを見て「あ、あのアニメですね」と反応できるようになるといい。そんなところに置いてるってことは明らかにツッコミ待ち。「何のキャラですか?」と聞くのも悪くないが、毎回それだとイマイチだ。なお「自分もフィギュアを置こう!」などという努力はしないでいい。


日経新聞は読まなくてもいいがホッテントリは流しておいたほうがいい。あと自社や競合関連のニュースには目を通しておこう。Google AlertTwitter Searchを併用すればまず取りこぼすことはない。
得意の英語を積極的に活かすなら、redditstackoverflowのアカウントを取って使い始めておこう。アカウントなしでも使えるけどあったほうが断然いい。
こういうツールは大抵RSSで情報を取得できるので、Google ReaderLivedoor Readerを使って購読しておこう。

先輩や上司との話し方

飲み会には行っとけ。金曜日なら終電を逃してもいい。そこでしか話されないことはたくさんあるし、人となりを知るいい機会になる。
話題は相手や場に応じて変える。先輩相手なら社会人として・新人としての悩みを相談してもいいかもしれない。飲みの場で仕事関係の話をしたくないという人もいるので、まぁ適当に合わせておくといい。大切なのは話していて楽しい人だなーと感じてもらうこと。もちろん自分を偽ったり曲げたりしすぎる必要はないけど、たいていは自分なりのやり方を見つけられると思う。
当然ながらお客様の名前を出したり人の悪口を言ったりするのはご法度だ。というか悪口陰口は飲み会に限らず言うべきじゃない。誰も幸せにならない。

通常業務中は敬語に気をつけつつ普通に接すればいい。貴方なら人見知りさえ終われば(=ある程度の時間が経てば)自然とうまくいくんじゃないかと思っている。
大抵の人は「それ前も言ったじゃん!」という状況に直面するとイラつくので、1度言われたことはメモるなり覚えるなりしておいて、雑談中に「それって以前仰っていた◯◯と同じ観点ですよね」「この前教えていただいた□□について自分で考えてみたんですけど……」とおりまぜると「あぁ覚えてるな」と教え甲斐を感じてくれるかもしれないかもしれない。間違っても「この前言ってたことと違うじゃないですか!」と逆ギレないこと。

技術が趣味な技術者とのつきあいかた

奴らはネイティブだ。どんなプロフェッショナルもネイティブには敵わない。技術面で彼らと並ぼうなんて考えなくていい。ていうかむり。あっちのほうが傾きもy切片も大きいんだもん。チートめ。
ので、敬意を払い謙虚に接しつつも卑屈になる必要はない。彼らがなぜそれを得られたのか、何を犠牲にしているのかを考えてみると、お互いに補い合えることが見えてくるはず。

更に言うと、趣味技術者や技術系学科卒業生には意外と「人に読んでもらうコードを書く」「技術は手段だということを踏まえる」という基本的なことができない(知らない)人がいるので、総合力では意外と勝算があるかもしれない。

Twitterについて

そう遠くないうちに会社の人にアカウントを特定されると思っておいて間違いない。嫌なら今のうちから会社用アカウントを作っておくといい。そして今のアカウントを鍵つきにするんだ。
念押ししておくと、鍵つきアカウント=なんでもつぶやき放題ではない。良識の範囲内でつぶやくべきだ。が、働き始めてしばらくは「良識」の定義がよくわからないはずなので保守的になっておいて損はない。

TwitterなどSNSでの言動は、実名匿名にかぎらず今後の人生について回ると思っていい。常にそういう心構えのもとに使うこと。バカやってもいいけど、というか個人的にはバカ推奨だけど、危ない橋は渡らないほうがいい。
ついて回るというとネガティブな印象だが、良い行いや評価もついて回る、すなわち「日頃の行いの可搬性が高まった」と考えることもできる。まぁ「神が見ている」の境地で過ごせば問題ないんじゃないでしょうか。

技術について

最初に押さえるべき技術

会社が定めていると思うのでそれに素直に従っておくといい。むしろ求められていることすらできない段階から他の技術に浮気してしまうと、優先順位付けを間違ってると判断されるだろう。

ただ会社の要求を満たすだけだと物足りないし飽きると思うので、プラスアルファで自分が興味を持てそうなジャンルをちょこちょこ調べておくといい。特に興味を持てるジャンルがない場合は、単にまだどんなジャンルがあるのか知らないだけだと思われるので焦らなくていい。これなんてどうだろう?わりとつぶしが利くジャンルだと思う。

  • 自分が欲しいものをサッと作るために
    • bashzshとかに手を出すのはこの次でいい)
    • RubyあるいはGroovy(Pythonは個人的にオススメしない)
    • ライブラリ(jarとかgemとか)の使い方・作り方
    • Ant/Maven/Rake/Gradleなどビルドツール
  • 普段触らないクライアントサイド
    • HTMLとCSS
    • JavaScript(HTMLとCSSを使い分けられるようになってから)
  • サーバサイドプログラムを自分ひとりで構築・運用する
    • さくらのVPSを借りる
    • Apache/nginx/Tomcat/Jetty/MySQL/Postgresqlなどのセットアップと運用
    • Ichinga/munin/monitなどによる監視と通知
    • MavenSubversion(あるいはgit)でプロジェクトを作ってデプロイする
    • 自分用のブログやWikiを運用する

ちなみに今の時点から「見たことも聞いたこともない全く新しい技術」や「業界最先端の技術」を深く学ぶ必要はない。今は広く学んで基礎体力と判断力を身につける時期だ。
RPGでいうと世界地図を完成させるのが先で、洞窟や塔や魔王の城に入っていくのはずっと後でいい。世界地図があってこそ「このダンジョンは炎の武器が必要らしい、あそこに火山があったから探してこよう」とか「水の防具がほしいけどこの海底洞窟はレベルが高すぎるからまずは泉のダンジョンに行ってみよう」みたいな判断が可能になる。地図がないままダンジョンに特攻すると、教会に戻されてから他の人に「お城でブーメラン買っておけばもっと楽できたのに……」と言われることになる。

注意点

デザインパターンは当分知らなくていい。勉強してもいいけど、積極的に勉強していることを先輩に気取られないこと。優先度を間違えて金のハンマーを握った残念な新人だと思われる。
YAGNIやDRYのような用語にも言えることだけど、デザインパターンはいろいろ細かい説明をすっ飛ばして状況や意見や感情を伝えるためのツールであり、工夫と考察を重ねて書き進めたら自然と行き着くものだ。「ここはテンプレートメソッドパターンが使えそうだな、よし使おう!」みたいな使い方をするものじゃない。
ただ「そういう発想もあるのかー」という発見があるかもしれないので、半年ほど経ってから紐解いてみるといいだろう。

マイルストーンとして目指したい資格

これもたぶん会社が定めていると思うのでそれに従えばいいと思う。個人的なオススメはIPAの情報処理技術者試験。幅広く出題されるので試験対策の勉強が自分の弱みをうまい感じに塞いでくれる。
ベンダー系の資格は会社から指示と補助が出ない限り取らないでいい。お金かかる上に有効期間が短い。

本について

この世には「良書」と「本」がある。「本」は人によって合う合わないがあるので好きに選べばいい。入門書なんかがそうだ*1
特にJavaの入門書は掃いて捨てるほどあるので、かたっぱしから目を通すといい。私は職場の研修で新人さんに「著者の個人的意見やクセに気づくためにも、最低3冊は読め」と言っている。このとき著者や出版社が違う本を選んでおくと、自分にあった著者や出版社を見つける助けになるかもしれない。

「良書」は時間経過で色褪せないもので、気に入る気に入らないは別として読んでおくべきだ。私は「闘うプログラマー」になんの感銘も受けなかったけど、支持される意味はなんとなく理解できたし他所の技術者や歴史を知ることには価値があったと思う。
どれが良書なのかは人づてに聞いたりまとめサイトをあたるなりするといい。私からのオススメは「Effective Java」だ。就職祝いに差し上げようと思っている。

雑誌について

WEB+DB PRESSは定期購読の価値があるので、2〜3冊買ってみて良さそうだと思ったら購読するといい。最初のうちは日経ソフトウェアも悪くないがすぐに飽きるだろう。
他の雑誌は定期購読するというよりも、いい特集が載ったら買うというスタンスをおすすめする。連載はそのうち書籍化されることが多いので、連載目当てに購読する必要はない。

オレ直伝・これだけはやっとけ

アウトプット。ものを学んでいく上でこれが最重要であることは疑いない。ブログにやったことを書いていくだけでもいいし、GitHubアカウントを取ってコードを書きためていくのもいい。Gistならいちいちリポジトリとか作らなくていいので書き捨てるにはぴったりだ。JavaScriptならjsdo.itがいい。

ノートや参考書に書き込むだけ、はダメ。人の目に触れるところに置いて、極力他人向けの説明文も書くようにしよう。人に説明するという行為は最良の学びの機会だし、人に伝えられないならその知識にはあまり意味はない。
業務もアウトプットじゃん!という話もあるが、業務はなかなか完結しないし自分で全てをやっているわけじゃない。小規模でいいから最初から最後まで、コード作成からデプロイまで完結させてみよう。それだけで視界が随分と広くなるはずだ。

ある程度まとまった知識がついたら、ライトニングトークや勉強会での発表を目指してもいい。こうしたアウトプットの機会は早いほうがいい。苦手意識は持ってるだけ無駄だし、新人だからこそできることもある。例えば新人や初心者が何に魅力を感じるのか・どこに苦手意識を持つのかという情報は中の人や熟練者に歓迎される情報になりうる。

こうしたイベントの発生を知るには、RSSリーダPARTAKERSSを登録しつつATND notifyを活用するといい。IT勉強会カレンダーという手もある。けど、一番いいのは人づてに紹介してもらったり連れて行ったりしてもらうこと。先輩や同僚に聞いてみよう。

まとめ

  1. コミュニケーションの機会は自分から作りに行くべし
  2. 技術はまず広く学んで頭の中に地図を描くこと
  3. 継続して人の目に触れる場所にアウトプットする

私からは以上だ。お前もできてねーじゃんと思うフシもあるだろうが、「最初からこうしておけば良かった」という反省が入っていると考えてもらいたい。
いつか疎結合やパフォーマンスといった技術的な話題を肴に酒が呑める日が来ることを楽しみにしている。

*1:個人的には「Javaデザインパターン徹底攻略」だけはオススメしない。確かダブルチェックロッキングを有効な手として紹介していたはず。