今年は社会人として、エンジニアとして色々と「初めて」なことの多い１年だった。
社会人として
フラットな関係で仕事を依頼する、されるようになった
今まではSIer,web制作会社にいたので、仕事の依頼はお客様からの「受注」でやっていて、何かを依頼する時はこちらから「発注」する形で他社のエンジニアやデザイナと一緒にやってきた。なので、どことなく金銭のやりとりが発生することから「上下」関係みたいなものがあって、その中でコミュニケーションを取って仕事をしてきた。別に下請けに傲慢な態度を取るとかってことはしなかったけど（お客様から見たら自分だって下請けだ）、それでもなんか一定の距離というか遠慮というか、そっちの事情はそっちの事情、みたいな所があって、同じものを作ろうとしてるのに違和感というか残念な感じがあった。
それが今年からは事業会社に転職し、営業・マーケ・デザイナ・エンジニアが全て自社の人間になった。その中で仕事をお互いに依頼する/されるようになり、そのコミュニケーションの仕方に最初戸惑った。どのように依頼すればいいのか、されればいいのか。入社した直後は他部署に何かを頼む場合（例えばこれこれの画面の確認をしてくれ、とか）も随分と堅苦しいもの言いをしていたように思うし、何が何でも期日を守らなければならないとか、言われたことは無理でも全部やらなきゃならないとか、受託開発で食ってきた人間のクセが抜け切れていなかった。
でもやってくうちに、事業会社の場合はみんなが同じ方法で利益を追い求めるのだから、個々の都合ではなく全体最適でタスクを捉えてどう進めるかを議論すべきだ、ということに気づいた。つまり、言われたから全部やる、ではなく、それが会社の為にどういう意味があるのか？を考えて議論して、やる内容や優先順位付けをできるようになってきた。他の部署もそういうものの考え方をして話をしてくれる。たまにそうでない人もいたりするが、その上司は分かってくれるので非常にやりやすい。一方で、受託開発と違ってその施策をやって、必ずしも売上が上がる訳ではないので、本当に効果があるかどうかビビりながらやったり、逆に数値が下がって慌てて切り戻すなんてこともある。それでも、今のフラットな関係で、みんなで同じ目的を達成するために議論しながら仕事を進める今のスタイルが好きだと思う。
新卒氏のOJTをした話
今年の夏頃から諸事情で営業から異動になった今年入社の新卒のOJTを担当した。
後輩を持つのもOJTを担当するのも、社会人になってから５年目にして初めての経験で、仕事として人からプログラミングを教えてもらった経験が殆んど無かった自分としては色々不安があったのだが、その分得るのものが大きい経験だった。
最初の一ヶ月半は教育期間ということでjava初心者本の写経、webアプリ開発のための基礎知識として自分が講師をやった座学を数回、webアプリ開発課題をやってもらった。
本当はjavaの基礎に加えて、webサーバ・APサーバ・DBの連携部分などのwebアプリの基礎をじっくり教えてから課題に取り組んでもらいたかったけど、すでに他の新卒は業務に入っていた時期で時間がなかった。なので、Webアプリケーションの登場人物や、静的なホームページとWebアプリケーションの違い、データーベースの概要なんてのを座学でわずかにフォローしたに過ぎなかった。課題がギリギリ出来る程度の。
しかし、後に業務に入ってもらってから、この辺はもっと時間をかけてじっくりやっておけば良かったと感じた。業務に入ってからの共通言語になるこれらのレイヤーの知識が頭に入っていないと、タスクの内容も正しく把握できないこともあるし、「何となく」ロジックを直して動いた、で終わってしまっていたなと思うこともあった。この辺は反省材料として来年の新卒教育カリキュラムに活かしていく予定。
業務に入ってからは、スキル差というかベースとなるIT関係の知識の無さが問題になることが多かった。元々中途入社で固めてきた会社だったので、「エンジニアとしての常識」みたいなものがあることを前提に業務を回してきたけどそういうのが全くないメンバーへの対応は非常に難しいものがあった。主に自分がチケットを管理して新卒氏に振って自分がレビューする、スケジュールも管理する、みたいなことをやっていたが、Webアプリというものはサーバ側もフロント側のhtml,js,css、さらには使ってる外部のミドルウェアまで広く知らないといじれないもので、その辺をつまみ食いしながらタスクをこなしてもらっている状態で中々体型づいた知識の蓄え方をさせてやれなかった。
毎日３０分その日のタスクの振り返りをして、技術的に足りない部分はQA形式や自分個人が必要だと思うことを教える形でフォローしたけど、本当はここも週単位でテーマを決めてそれに基づいて講義形式で技術を叩き込むべきだったのだと思う。あまりにも言語の知識も足りてなかったし、コードを書く上での「作法」とかコードを追う上での勘所が分かっていないようだった。自分が激務で週２，３は終電帰りとかで時間がなかったと言い訳をしてしまえばそれまでなんだけど、申し訳ないことをしたと思う。教育担当になったのだから、自分のタスクを減らすことを上司に交渉してでも教育に専念すべきだったのだと思う。けど自分の仕事の裁量が大きくなってきた時期とも重なっていて、責任ややり甲斐が大きくなってきた中で、自分の業務を減らしたくないという思いもあった。結果として、中途半端になってしまって申し訳ないことをしたと思う。
結局そんな状況だったので、見かねた会社の教育＋サポート専門で入ってもらっているフリーランスのエンジニアにサポートをどっぷり頼む形となった。自分の至らなさを認めなくてはならず凄く辛かったけど、結果としては新卒氏のスキルアップという意味では良かったのだと思う。１２月末頃までにはwebアプリの機能保守という点では業務が出来るようになった。まだゼロベースで作れるほどではないが、前より大分総合的なスキルが深まったように思う。
11月末頃にエンジニア内でチーム再編があって、新卒氏は自分とは違うチームになって業務的にチケットを振ることは無くなって実質お役御免になった。ただ、週１でフォローアップをする時間を作ってそこでのフォローは続けている。そこでは、今やってるチケットの相談とか、チームの愚痴を聞いたりとか、UI設計やjsやフロントの実装がまだ弱いのでその辺の技術的なフォローをしたり、その新卒氏と他のエンジニアも交えて「javascript本格入門」の読書会を初めたりした。決して良いOJTトレーナーではなかったけど、次の新卒が入ってくる頃まではフォローを続けて、自分自身の「教えるスキル」の向上に努めたい。
エンジニアとして
人のソースをレビューするようになった
前職ではほぼ１人デコードを書いて自分でテストして自分でリリースするような感じだったのだが、現職からは１０数名のチームで開発している。
そこで当然のごとくお互いのソースをレビューするのだが、初めての経験だったのでどこまで突っ込んだレビューをしていいのか戸惑った。
とりあえず目的を満たしていればいいのか、クラス設計の適切さやメソッド名や変数名の適切さとかの細かい部分まで突っ込むべきのか、時間の成約があるなかでどこまでやるべきか迷った。明確な基準がある訳ではなく、個々人の裁量に任されていたので自分でそこは決めなければならない。
最初はチェックアウトしてローカルで動作させて問題なければ大方OK、ソースを見て「まぁこんなもんだろ」でLGTMとしていて、動作がおかしければ「大体ここがおかしいでーす」とかの大雑把な指摘で今年前半は良かった。メンバーのスキルも仕様理解度も高いメンバーで構成されていたからツーカーの会話で大体済ませられたし、どちらかと言えばこの頃は俺の方がマサカリを投げられまくっていた。
それが、チーム内のメンバーがどんどん他事業に行ったり中途で入ってきたりして入れ替わってきて、今年初頭と比べて殆んどのメンバーが入れ替わった今年後半においては、プログラミングのスキルが低かったり仕様の理解が不十分なメンバーが増えて、レビューでの突っ込みどころが凄く増えてきた。このクラスはこのパッケージに置いちゃダメなルールなの！Wikiに書いてあるでしょーが！とか、この処理はApache CommonsのUtil使って～みたいなレベルのツッコミをしなければならないことが増えたので、スキル底上げも兼ねて細かい実装レベルでレビューをするようになった。
先に書いた新卒氏のレビューなんかもそうである。レビューする時にRedmineのチケットのソースに延々と細かい駄目だしとなぜそれが必要なのか？を書くようになった。jsのイベントのbindの仕方がミスってて「ここでonでbindしたらajaxでリロードした時にbindされないから$(document).onでやった方がよくて、その場合もさらに。。」みたいな感じのことを書いたり。
他にも何度も使用するmatcherをクラスのフィールドで初期化しないとダメな理由を本人とっ捕まえてコンコンと説明したりしなくちゃいけないような場面も増えたが、結局チーム全体のスキルを底上げしていかないと良い仕事なんて出来ないので、レビューは今後も「細かく」「地道に」やる方針で続けていこうと思う。
オブジェクト指向をちゃんと意識するようになった
javaをガッツリ書くようになって、ポリモーフィズムの重要さとかデザインパターンの有用さとかがようやく分かった気がする。１年前まではクラスはせいぜい処理を一定の単位でまとめたものぐらいにしか思ってなくて、インターフェース？美味しいのそれ？って感じだったのだが、今は特定の機能を「いかに差し替え可能な実装にするか」を考えてクラス設計したり、必要に応じてインターフェース作ったり、ということが自然にできるようになった。たまに、今触ってるソースでも過剰に抽象化し過ぎているクラスもあったりもするが、抽象化し過ぎたものを具象化し直すのはそれ程難しくないが、その逆は凄くめんどくさい。一度、「こうやって作ったけど処理の最初の方で実装クラス分けて処理書くようにしたら内部の分岐がシンプルになるじゃん」みたいなケースがあって、ほぼ終わってたがそこからインターフェース書いて実装クラス作りなおしてやり直したみたいなことをしたことがある。テストも全部やり直しでめんどーくさいのだが、後から保守していく上では業務ドメインを細かく分けておいた方がやりやすくなった。ドメイン分析大事。けどDDDはまだ良くわからないので来年勉強して、部分的でも取り入れていきたい。
![ノンデザイナーズ・デザインブック [フルカラー新装増補版]](http://ecx.images-amazon.com/images/I/41nvddaG9BL._SL160_.jpg "ノンデザイナーズ・デザインブック [フルカラー新装増補版]")
