最近考えていること

残りの人生をどう生きるか

自分は２０代後半で大して人生も生きていない。

生きていないのだが、大学を卒業して就職して何年か経って、毎日満員電車に乗って出勤して仕事をして夜遅くに帰宅する、という同じような日々が続き、毎日ほぼ同じような体験をしている。エンジニアという仕事は毎日が変化のように見える人もいるかも知れないし、実際そういう仕事をしていればそうなのだろうけど、自分の場合はもう何の変化も刺激も感じなくなってしまった。誰のために手を動かしているのかすら分からなくなって、必死になって何かの為にできることを考えている。

休日になれば少し遠出したりギターを弾いたりコードを書いたりしているのだけど、それでもどこか、「また同じようなことをしている」という感覚に捕らわれる。１年を通して大体何が起きて自分が何をしているか想像が出来てしまう。

だから残りの何十年かは、ひたすら同じ体験を毎日繰り返すような感覚なのではなかろうか。そう思うようになった。何がきっかけかは分からないが。

それと共に、自分の人生は本当にそれでよいのだろうかとか何とか、まるでプロジェクト半ばに来て本当にこのプロジェクトの要件定義は正しかったのか、みたいなことを考え始めてしまった。この手の思索はどれもそうなのだが、一度考え出すと仕事中もずっとそんなことを考えてしまって止まらなくなって困っている。

散々に考えた挙句出てきた一つの明確な答えが、「自分が好きな場所で暮らして一番やりたいと感じていたことを人生でやったと実感して死にたい」ということだった。今自分が住み、働いている場所は、自分が好きな場所とは言い難い。自分は田舎生まれ田舎育ちのせいか、ずっと東京に馴染めないでいる。５年も毎日満員電車に乗って通勤してきたのに一向に慣れないし、寧ろ最近はストレスでしかなくなった。あと人が多いのにも慣れない。東京で遊びたいと思わない。休日に突然実家である栃木に帰ったり、大学時代を過ごした盛岡に行ったり、会津若松に行ってみたり、箱根に行ってみたり、足柄の山奥にフラっと行ってみたりするのもそういうことに対する反動なのだろうと思う。

薄々感付いてはいたのだけど、やっぱり自分は地方に住みたい。

でも地方に住めば、今のエンジニアとしての仕事を失う可能性が高い。IT系と行っても地方のSIerでは今時の開発をすることは難しいし、プログラマよりSEやPMの方が（単価が高いという理由で）求められるだろう。そのせいで躊躇している。

結局、今みたいにバリバリコードを書ける環境が都会にロックインされている。そのことが少なからず自分は辛く感じ始めている。それが最近色々悶々としている理由なのだと思う。

ここまで書いて少しスッキリした。

話は変わるが、ソニックガーデン代表の倉貫さんのブログを良く読んでいるのだが、こういう会社でこういう働き方が出来たらいいなと感じている。

リモートワーク（在宅勤務）を導入するためのポイントと残された課題 | Social Change!

自分がすぐそういう働き方ができるとは思っていないけど、それでもいつかそれを実現することを目標にして動こうとしている。

それを活力に少しでも前向きに生きられたらいいなと思う。

技術サポート業務の難しさ

今年１月から、入社以来所属していたチームを離れて社内全体の技術サポートをするようになった。

今の所メンバーは自分しかいない。

だからリソースはかなり少ないのだが、社内のサービス開発でのお困り事の調査だったり、上司が気になる技術の調査をしてサンプルコードを書いて上司に報告したり、ある問題に対してどういうライブラリを選択するべきかを議論したり、ひたすら社内wikiにまとめたりしている。取り扱う内容は、フレームワーク・ミドルウェアの検証から、使う可能性があるWeb APIの仕様のとりまとめまで様々である。javaでiphoneアプリを作るライブラリなんてのも検証して実際に作ってみたりした。

調べた内容については、週１回社内共有会という形で自分がLTみたいなことをして共有している。大体２０分自分が話して残りは雑談しながら質疑応答という感じだ。

こんなことを２ヶ月近くやってきたが、ずっと開発ばかりしてきた人間なので色々と壁にぶつかり始めるようになった。

１つ目は「自分がきちんとアウトプットが出せているか」が分からない点。

前に所属していたチームではスクラムっぽい開発をしていて、１回のスプリントでこなすべきチケットが決まっていて、それを達成することがとりあえずのアウトプットの形で、自分で達成度合いを確認することができた。

それが今は、タスクを積み上げてそれに対してスケジュールを大体で決めて進めているけど、別にそれが遅れたからといって誰も困る訳ではないので、スケジュールを守ろうとが守るまいが、あまりインパクトがない。もちろん同じスケジュールならアウトプットは多い方がいいのだろうが、それによって何か変わるようなことは今は出来ていない。そういうものを自分でコミットしてやらないといけないのだろうなぁと思うのだが、方法がまだ確立出来ていない。

２つ目は「社内にシェアしてもそれが現場で本当に意味があるのか」が分からない点。

特に社内で共有会をやっていて思うのだが、基本的に社内のエンジニアにシェアしても大して反応は無いし、それがすぐに社内のサービスに影響を与えるということもない。

もちろん、仮に社外の勉強会に参加した所でそれがすぐに仕事に影響することなんて無いわけで、長期的に見て資産になれば良いだけのことである。それでも、業務に直接関係しなさそうなImmutable Infrastructure系の話とかCIの話だったりをしても全然反応がないのが若干辛い。基本的には社内で使ってないが、選択肢として覚えておいてもらいたい話題をチョイスしているのだが、業務時間にやっている以上は、もう少し現場に近いものをやった方がいいのか、それとも今のサービスが大きくなって負荷分散やソースの整理をしなければいけない事態になった時のことを考慮して選んだ方がいいのか。

いずれにせよ、自分は今の会社では若造の方なので、自分より年上のエンジニア達に話を聴いてもらうのは色々と工夫が必要であるということはよくわかった。基本的に３０を過ぎたエンジニアに新しい技術をインプットさせるのは相当な工夫がいるようなので、今後は巻き込み方とか、会の在り方とか色々考えていかなければいけないと感じている。

世の中の企業の研究職やR&D職の人もこんなジレンマと闘いながら業務にあたっているのだろうか。

10年後もプログラマとして働き続けるために考えていること

クロノトリガーは、確か自分が中１だか中２だかの頃に、偶然ハードオフで見つけて中古で買い、何周も何周もプレイした思い入れのある作品だ。

当時、既に発売から何年も経っていたから、周りの同級生とクロノトリガーを話題にしたことはなかったが、テキストとドット絵の、今考えたら制約の多い手法で表現される、時には熱い戦いに胸が踊り、時には辛い別れに涙する素晴らしい世界観に自分はめちゃくちゃハマり、主要な台詞を殆んど覚えるほどやりこんだ。気がつけば全員のレベルを★★（カンスト値）にするまで何周もやり込んだ。

そんなクロノトリガーで、今でも時々思い返す台詞（というかスクリプト）がある。物語序盤、中世で攫われたリーネ王妃を救うために向かったマノリア修道院のドア横に突然現れる「はりがみ」にこんなことが書いてある

行こうと心に決めた者のみが行ける道がある。

 物語の本筋と関係があるんだか無いんだか、良く分からない形で突然現れるこのはりがみ。

誰が、一体何のために書いたのかは劇中で触れられていないが、この言葉だけは初プレイから何年経っても時々思い返す。思い返すどころか、年を取れば取るほど重く感じるようになってきている。

突然話が変わるが、プログラマというのは特殊な職業なのだろうか、ということをよく考える。プログラマをどう定義するのかによるが、ここでは「業務としてコードを書く機会がある」人のことをプログラマとして定義したい。つまり、ITエンジニアという肩書だが、業務で全くコードを書かない人はそれに該当しないとしたい。

自分は今は仕事としてコードを書いている。最近、サービス開発の現場からは一歩退いて、プロジェクト横断で後方支援的なことをメインにやるようになったため、以前より書く量は減ったが、技術検証やテストコードの整備などで毎日何がしかコードを書いてコミットしている。また開発現場に戻るかも知れないが、少なくともプログラマとしてコードを書いて仕事をし続けたり、新しい技術を学び続けることに何の疑いもないし、１０年、２０年経っても続けていくつもりでいる。

しかし、１０年、２０年とプログラマをやっている人って、自分が知るかぎりではかなり少ない。自分の身近な存在で挙げると、17年プログラマとして働いている先輩が１人いるくらいだ。業界自体が若い、なんて話もあるが、仕事としてプログラムを書いていた人は1960年代から存在していたようなので（「闘うプログラマー」参照）、10年間仕事でコードを書き続けている人がいてもおかしくはない。

一方で、「元プログラマ」とか「元SE」みたいな人は大勢いる。別にそれが悪いということは無い。一度でもコードを書いて飯を食うことで見えてくることは沢山あるだろうし、それを元に別の分野で活躍できるのは素晴らしいことだと思う。

また、３０代、４０代になった時に、プログラマという立場でどういうアウトプットができればいいのかが今時点では分からない。前述の通り、ロールモデルが殆んど無いし、かといって今（プログラマ歴は丸2年と少し）と同じアウトプットで良い訳がない。もしそうなってしまったら他の人に取って代わられるだけだ。

そういう意味で、プログラマは続けるのが難しい「特殊な仕事」なのではないか、なんてこと考えるようになった。サラリーマンというよりはスポーツ選手のような印象を持っている。常に自分を磨き続けなければ脱落していく。1年後に仕事で今以上の高いアウトプットを出そうと思ったらこの1年間相当量のインプットとアウトプットを残さなければならない。そうしないと少なくともプログラミングのスキルは伸びないからだ。

例えば、今業務でやっているサービスの保守は出来ている。

しかし、新しい事業が立ち上がって、そのチームの唯一のプログラマとしてアサインされた時、1人でサービスの根幹を作ることが出来るか？使うフレームワークを自分で選べるか？AWSでVPC設定してEC2とELBとRDSを設定して最小限のインフラを構築できるか？出来ないとしたら、素早く習得できるだけの土台があるか？考えだすとキリがない。

今の仕事が出来ているから1年後も安泰、なんての昨今IT業界全般で言われる通り幻想である（これはITに限らないだろうけど）。ITエンジニアにとってどんどん必要なスキルは増えていく。必死で着いていかなければならない。辛いと思う人もいるだろうし、昨年入社したうちの会社の新卒諸氏は覚えることが多すぎて早くもしんどそうだ。

それでも自分は、プログラマとして働き続けようと思う。

なんでそう思えるのかと長いこと色々考えたけど、結局「好きだから」、に尽きるように思う。

自分は上流SEからプログラマに「転職」してからまだ2年と少ししか経ってないが、コードを書くこと、使ったことがないミドルウェアを使えるようになること、チームのタスクをマネジメントすること、誰かの問題を解決をするために頭を悩ませること、他のメンバーを育てること、全部含めてプログラマとしての仕事が心底好きだし、何よりwebで多くの人に「こいつぁすげぇや！」と驚き、喜んでもらえると凄く嬉しい。

だから「この道を行こう」と決めた。

「好きだから」でどこまで行けるか分からないが、今は新人教育やインフラ側・アプリ側双方での技術検証とかの仕事も始めて、前よりは仕事の幅が広がりつつある。その中で、自分が今どういうアウトプットが出来る人間かを考えて、そこからどうなりたいかということを模索していきたいと思う。

技術調査はググる前が肝心

概要

■「プログラミングは自分で調査しながら覚えた方が上達が早い」という意見は非常に同意

■でも出来ている人少ないよね。調査中に挫折しちゃう。

■それは「わからないこと」をブレークダウンして整理しないで調査し始めて欲しい情報をピンポイントで調べられてないから

■調査をする前に「何をしたいか」「何がわからないか」を徹底的に時間をかけて整理してから調査した方が結果的に早く答えに辿り着くからオススメ

プログラミングが上達しない or 勉強が続かない人へ:とあるIT系社長のブロマガ - ブロマガ

凄く共感できる内容だった。

特に以下の部分

実はプログラミングを"勉強する"ってこと自体ちょっとオススメできない。

どういうことかというと、僕が思うに
・何か作りたいものがある（アイデア）
・それはどうやったら作れるのか（調査）
・実際に作り出す（実行）
っていうプロセスが一番上達が早いと思うんだよね。

全くその通りだと思う。

しかしこれらをきちんと実践出来ている人は現実ではかなり少ないように思う。

何か分からない事があった時に、なんでも自分で調べてホイホイ作れてしまう人もいるが、多くの人は調査の段階で立ち止まってしまうことが多い。「調べたけど分からなかったから挫折した」みたいな。

自分は元々独学でプログラミングを覚えて、過去の仕事でもエンジニアが自分１人しかいないような状況で開発をしていたこともあってか、自分で調べて解決するのには割と慣れている。

例えば何か作業しててハマった場合、自分は下記のような感じで調査している。

 後半のググって見つかるまでキーワード変えてググるってのはみんなやっているのだが、前半のオレンジで書いた部分のフローを端折って

・何がしたいのか

・自分がどこまで分かっていて何が分からないのか

・どういう情報が欲しいか

を明確にしないまま、何となくエラーメッセージでググったりする人が多い。

これをやると、気が付くと的外れなことを調べていたり、漠然とググり続けて延々と時間をかけてしまったり、途中でそもそも何がしたいのか分からなくなってしまう。んなことを現場でやってると先輩から怒られること必須である。

ググっても分からず、最終的に誰かに質問する場合も、何が分かっていて何が分かっていないかを明確にしておかないと、聞かれた相手もどう答えていいか分からず、お互いの時間を無駄にすることになってしまう。
んなことやってると段々「あいつは自分で調べずにすぐ聞いてくるめんどくさい奴だ」とチームのメンバーに思われて、段々相手してもらえなくなる。現実は厳しい。

また、開発コストという観点からもなるべく短時間で調査できるようになることを常に心がけるべきだと思う。

調査を行う時間が初めから開発スケジュールに含まれているなら良いが、そうではない突発的な調査が必要になった場合の調査は長引けばスケジュールに影響を与える。

ハマりそうなポイントがハナから見えているのであれば、調査かプロトタイプを作って検証するスケジュールを最初から入れておくことを検討しといた方がいい。

あと調査とは関係ないけど、手元で得られる情報をきちんと集めるのは調査以前の大前提になるので、javaの長ったらしいスタックトレースもめんどくさがらずちゃんと読もうね、ってのもいつも思う。

参考：デバッグ手順(スタックトレース重要) - jfluteの日記

組織の中で新しいことをする勇気

長いこと多くのエンジニアに保守され続け、機能拡張を続けたシステムにありがちな話。初期の設計思想が無視され、付け焼き刃の設計と実装でどんどんコードが汚くなっていく。

適当なパッケージに適当な名前のクラスが量産され、似たような処理のメソッドや、やたらと多くのことをやり過ぎるメソッドが増えまくる。当然コメントなんて一言も書いてない。

急ぎで作ったから仕方がない、なんて場合もあるのだが、大抵は一つの理由に行き着く。「安易に似た実装をコピペするから」。

他の実装をパクるのはラクだ。すでに動いているのだから間違いがないし、何より自分の頭を使わなくていい。メソッドが新たに増える分には副作用が無いケースが多い。だからバグを埋め込む可能性も低い。良いことづくしだ。

その結果どうなるか。後から触る人が泣くことになる。

コピペした本人はコピペ元がなにをやってて何の為にコピペしたのが分かっているから迷うことはないが、後からコピペした辺りを触る人はそんな経緯は知らない。だからなんでほぼ同じで少しだけ違う処理をコピペして持ってきたのかわからない。このメソッドがなぜこのクラスにいるのか分からない。そもそもこの処理、このパッケージに書いていいんだっけ？？？等々。ソースを読みながらそんなことを悩んでいるうちに日が暮れる。無駄に工数を消化する。スケジュールが遅れてマネージャーに怒られる。。良いことなし。

どうするか。「根拠のあるコード」を常に書くようにする。レビューで問い詰めてコードの根拠をはっきりさせる。経験上、大体これぐらいしかない。

根拠がはっきりしていれば、他とは違うクラスの設計をしても良い。そのクラスの責務はそのシステムで初めて発生したものかも知れない。だから無理やり他の実装と合わせる必要はない。

オブジェクト指向の原点に立ち返って、「このクラスの責務は何だろうか？このメソッドはこのクラスの責務を超えてはいないか？」と自問して、「この処理はこのクラスがするのはおかしい。別の名前のクラスがやるべきだ」と感じたら、堂々と新しいクラスを作ればいい。

こういうパターンの名前は今いじっているシステムには無い？でも散々考えた挙句、あなたはその名前がふさわしいと思ったんでしょ？根拠があるんでしょ？だったら堂々とレビューに出せばいい。何でもかんでもHogeLogic , FooServiceでピッタリハマる訳じゃない。

新しいことをやるとレビュアーに突っ込まれる？根拠を堂々と述べればいい。それが出来ないならきちんと設計ができていない。自信が無ければ作業中でも他の人にクラス設計をレビューしてもらえばいい。

実装に手一杯で設計まで手が回らない、なんて言うケースもたまに見かけるけど、それでも設計には時間をかけるべきだし、設計に時間がかかるんならチケットを切る段階でそれを見越して見積もりを立ててスケジュールを切ればいい。それくらい設計フェーズは大事だ。ここを疎かにすると後の人が泣く事になり、いずれ自分も泣く羽目になる。

必要ならば新しいことをする勇気を出して欲しい、といつも思う。確かに新しいことは怖い。リスクも大きい。でも、他と同じような感じで何となくコードを書いて飯を食ってたらいつまでもスキルは上がらない。

仮にそれをやって他から突っ込まれても、きちんと根拠を説明して議論することもエンジニアにとっては重要なスキルだと思う。自分が知る限り、説明が下手なエンジニアに良いエンジニアはいない。優秀になればなるほど完結な言葉で端的に説明できる人が多い。議論好きである必要はないけど、きちんと自分の頭で考えて、「これがベストだ！」と思える設計・実装をして、それを周囲に認めてもらいながらものを作り続けられるようにしたい。

ボ カ ロ で 懐 か し い 名 曲 は

【動画】ボ カ ロ で 一 番 の 神 曲 は：ひまねっと

便乗して書いた。反省はしていない。

自分が一番ボカロを聞いてた2007年～2009年の頃に好きだった曲（一部）を集めてみた。

本当はplay!2.1.1 + DBFluteの構成でアプリを作ってみたエントリーを書こうと思ったが次回に持ち越しである。

2013年振り返り

今年は社会人として、エンジニアとして色々と「初めて」なことの多い１年だった。

社会人として

フラットな関係で仕事を依頼する、されるようになった

今までは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はまだ良くわからないので来年勉強して、部分的でも取り入れていきたい。