やあ(´・ω・｀)
呆れずにメールのリンクを開いてくれてありがとう。そうなんだ、このページは前回の続きというわけなんだ。おっと、control+wでタブを閉じるのは待ってほしい。ショートカットキーに親しんだ貴方を見られて感慨深く思うが、せっかくなので居酒屋で変なおじさんに絡まれたと思って聞いてやってほしい。
とりあえず、初めの1年間がきちんと終えられたようでおめでとう。楽しい事ばかりではなかっただろうし、理不尽なことやつまらないこともあっただろうが、自分の手がける製品について話している姿からはそれなりに充実した生活が想像できる。貴方が良い職場と良い仕事に出会えたことを感謝している。
周囲への感謝と対処
そう、まずは充実した生活が送れていることに感謝しよう。感謝はぜひ口にしてほしい。人に伝えてほしい。そこが今一番気がかりだ。1年間を振り返って、思う所があれば今からでもいいので伝えに行くといい。
マンネリとその向こう側にあるもの
さて1年過ぎたころというと、そろそろ1日が想像通りに終わることが増えてきたころなんじゃないだろうか。つまり持ち合わせの知識で間に合うことが増え、業務に新鮮味がなくなり、環境や製品を展望できはじめるころだろう。良く言えば余裕が生まれた、悪く言えば飽きが来たわけだ。
もちろん持ち合わせの知識が働く上で充分なレベルに到達したわけではない。少なくとも技術者は、どんなに経験ある人でも学習を継続しなければならない。ただ、学ぶモチベーションが切り替わる時期にあるというだけなんだ。
学習の動機
今までは危機感や責任感が学びの動機にあったことだろう。そしてそれらは今後も効いてくる。しかしそれだけでは足りなくなってくるかもしれない。なぜなら危機感や責任感は、学ばなければならないことが明白なときにしか働いてくれないからだ。
資格を取らなければならない、保守を引き継いだ製品のSQLが理解できない、システムの負荷が高くてとにかく対応しなければならない……そういった状況で得る学びの動機はわかりやすく、即効性があり、また周囲の協力を得やすい。でもそれは受動的だ。自分から知識にアプローチしないと、いつまでも仕事に追われてしまう。
プライベートを大切にする貴方なら、仕事に追われることの危険性を本能的に察知していることだろう。
では仕事に追われないためにはどうすればいいのか。受動でないなら能動という話になるんだけど、具体的にはどうすればいいのか。
それを考える前に、なぜ誰も要求していないことを学ばなければならないのか、つまり学ぶべき理由が明白でないことを学ぶ必然性について考えてみたい。それは端的に言うと「仕事を変化させるため」なんだと思う。未来を予測する１番いい方法は未来をつくることだ、なんて言うけど、仕事でもやっぱり同じことが言えるはず。仕事に追われないためには仕事を追う、つまり仕事に働きかけていかないといけない。
仕事を変化させるためにできること
貴方は仕事は上から降ってくるものだと思っているかもしれない。あるいは上が決めてしまって下には動かせないものだと思っているかもしれない。
それはある意味で正しい。仕事はお客様があって成り立つものだし、お客様との交渉や契約は上が関係しているし、上司は部下に関するいろんなことを勘定に入れて仕事を振っているはずだ。言われたことをきちんとこなすことやこなせるようになることが求められているし、まずはそこを達成しなければならない。
だが、言われたことをこなすだけでは充分ではないと思う。期待をいい意味で裏切り、求められている以上のことをやる必要がある。
というか単に期待するアウトプットを求めるだけなら、外注やOSS利用やライセンス購入など魅力的な選択肢が他にも多数ある。会社がわざわざ人件費をかけてまで人を抱えるのは、「工数」だけを期待してのことではないはず。会社の存在意義、文化、目標、戦略、独自性……まぁその会社ならではのいろいろを理解した上での創意工夫や化学変化を期待されていると思っていいんじゃないかな*1。
ちょっと理屈に飛躍があるけど、作業をこなすだけなら外注でも新卒でもバイトでもできるというのは感じてもらえると思う。
社員にしかできない創意工夫をすること、つまり仕事に変化をもたらすこと・責任をもって向き合う*2ことを成し遂げてはじめて、雇ってもらっている*3ことへの貢献になるだろう。
注意すべきなのは、期待をいい意味で裏切るためには要求を満たしてから＋αする必要があるということだ。＋αを先に持ってくると悪い印象を与えてしまうことが多い。
例えば上司がSQLの高速化を求めた場合に、SQLでなくアプリケーションロジックの変更で高速化できることに気づいたとする。このとき「コード変えても速くなりますよ」という報告はきっと求められてない。「仕事を振ってから今までそんな無関係なところを調べていたのか！」と言われる可能性も高そうだ。
だから調べ始める前に、「なんでSQLなんですか、ロジックも遅そうですけど」と聞いてneedを明確にしてみよう。もちろん「SQL改善だとX倍速ですが、ロジック改善ならテーブル構造を変えずにY倍速にできますよ」とwantを実現した上で提案を持って行くのも良いだろう*4。
大事なのは相手の仕事を想像すること、ここでは「何をどう判断したい（する責任がある）のか」を考えて先手を打つことだと思う。まぁ、私もまだできないんだけど。
学習すべきことが明白でないときにどうするか
さて本題。学習すべきことが明白でないときにどうするか。特に技術そのものに関心が（少なくとも就職前は）なかった貴方のような人はどうすればいいのか。
こういう場合は、まず「何を知らないのか」「何がわかってないのか」を認識するところから始めたほうがいい。前回の表現を借りるなら「世界地図」を描くところから始めるといい。*5
これを描くには、経験ある先輩の体験談を聞いたりHOWTO本じゃない技術関連書を読んだりするといい。こうした話にはストーリー、起承転結がある。要素技術の間を繋ぐ線がある。この線をたどれば、今わかっていないことやこれから必要になることが探しやすい。 歴史に関心が持てるなら、闘うプログラマーみたいな伝記でもいい。以前プレゼントしたLinuxの教科書みたいに広く浅く技術について扱っているものでもいいかもね。こういう本を紐解けば、自ずと以下の様な漠然とした問題に対するアプローチが見えてくる：
- サーバからのレスポンスが平日朝だけ遅くなる。CPUの負荷はまったく高くない。
- サーバを1日起動しておくとOutOfMemoryExceptionで落ちる。
- 新しいバグを作ってしまったようだが、何が悪かったのかいまいちわからない。
あとは幅広い仕事を拾いに行くのも有効だ。このとき、全く新しい仕事を拾うよりは、今やっていることと関連した新しい取り組みを探したほうがやりやすい。
例えば保守しかやっていないなら、保守作業を助ける小さなシステムをスクラッチで書いてみる。Antを使っているなら、Mavenも試してみる。テスト環境をメンテナンスしているなら、システム負荷を調べてテスト実行時間を短くしてみる。オーバーコミットにならない範囲で、手を挙げてやってみるといい。
そして前回も書いたけど、やったことは形に残すこと、アウトプットすることを忘れないで。できるだけ人目に触れるところに置こう。別に私に見せろって言ってるんじゃないよ(´・ω・`)見たいけど……。
保守について
サーバや稼働中プロダクトの保守を担当することが多いと聞いている。そんな貴方に私からのアドバイス。
Unixコマンド
まず、Unixコマンドに慣れておこう。cat, head, tail, grep, ps, top, xargs, awk, sed, kill, less, wget, pingなどなど*6。
- 原因調査用Linuxコマンド | 外道父の匠
- ちなみにここに書いてある「テディベア現象」というのは、先輩に説明するための練習にテディベア人形に説明していたら、その過程で解決策に自分で気づいてしまうという現象。言葉にしてみるだけでも違うので、人に協力を得る前に試してみては。
サーバがWindows ServerだったらPowerShellがいいね。スクリプト言語が使えるならそれでも大丈夫。Windowsでもping, nslookup, tracertとかは使えるよ！
ログ
次に、どこにどんなログが出るかを覚えておこう。Windowsのログ、postfixのログ、MySQLのログ、cronのログ、Apacheのログ、Tomcatのログ……というのを覚えるだけで、トラブル対応の初動が違ってくる。
ちなみにログは超が128個つくくらい大切なものなのでぜひ重要視してほしい。問題が起こったときはまずログ。サーバに新しくサービスを立てたら、まずログがきちんと残ることを確認。ログがいつでも残るようにHDDの空きを監視しておくこと。異常を知る（比べる）ために平常時のログもきちんと残しておく。トラブル対応もまずログ（と、CPUやHDDなどのリソースの現状把握）から。
はじめの頃は「最近こういう変更をしたのがまずかったのかも、巻き戻そう」という推測をやりがちだが、最近の変更はあくまでも仮説をたてるための情報。仮説の検証にはログが必要だ。まずはログから。
空気としてのスクリプト言語
以上の2つで、トラブル時の対応と問題切り分けはかなり良くなる。そうなれば保守担当としてかなりいい仕事ができるだろう。
最後に、Rubyに慣れておくといい。最近のサーバ担当者が使うツールはけっこう高確率でRuby製だ、と思う。DSLがRubyベースだったり。Rubyに慣れておけばそうしたツールのキャッチアップが早くなるし、ツールで足りないところを補うことも簡単にできるようになる。
周囲の先輩がPerlやPythonを使っているならそれでも大丈夫。始めやすいところから始めよう。
とりあえずループと文字列への変数埋め込み（puts "user:#{user}"とか）が使えれば困らないと思うので、継承とかモジュールとかみたいな細かいところまで突っ込まなくて大丈夫。「あー、これ手作業じゃダメだな」と思ったときに抵抗感なくサッとエディタを立ちあげられられるようになればそれでOK。
後輩について
そうだ、貴方は今月から先輩になるのですね。厳密には1コ下が配属されたタイミングで先輩になるんだろうけど、そんなに遠い話じゃないはず。
自分がどういう人か知ってもらうとか、得意分野（技術に限らない）を知ってもらうとか、考える手助けをしてあげるとか、後輩にやるべきこと／やってもらうことはたくさんある。けど、とりあえずは興味を持って接することを心がけていれば大丈夫。
愛の対義語は無関心らしいけど、関心さえあればコミュニケーションの機会はできてくる。自分のことで精一杯になったとしても、関心だけは払ってあげて。
つまり、何が言いたいか
仕事を積極的に楽しみましょう！プライベートを楽しむためにも！
