今年１月から、入社以来所属していたチームを離れて社内全体の技術サポートをするようになった。
今の所メンバーは自分しかいない。
だからリソースはかなり少ないのだが、社内のサービス開発でのお困り事の調査だったり、上司が気になる技術の調査をしてサンプルコードを書いて上司に報告したり、ある問題に対してどういうライブラリを選択するべきかを議論したり、ひたすら社内wikiにまとめたりしている。取り扱う内容は、フレームワーク・ミドルウェアの検証から、使う可能性があるWeb APIの仕様のとりまとめまで様々である。javaでiphoneアプリを作るライブラリなんてのも検証して実際に作ってみたりした。
調べた内容については、週１回社内共有会という形で自分がLTみたいなことをして共有している。大体２０分自分が話して残りは雑談しながら質疑応答という感じだ。
こんなことを２ヶ月近くやってきたが、ずっと開発ばかりしてきた人間なので色々と壁にぶつかり始めるようになった。
１つ目は「自分がきちんとアウトプットが出せているか」が分からない点。
前に所属していたチームではスクラムっぽい開発をしていて、１回のスプリントでこなすべきチケットが決まっていて、それを達成することがとりあえずのアウトプットの形で、自分で達成度合いを確認することができた。
それが今は、タスクを積み上げてそれに対してスケジュールを大体で決めて進めているけど、別にそれが遅れたからといって誰も困る訳ではないので、スケジュールを守ろうとが守るまいが、あまりインパクトがない。もちろん同じスケジュールならアウトプットは多い方がいいのだろうが、それによって何か変わるようなことは今は出来ていない。そういうものを自分でコミットしてやらないといけないのだろうなぁと思うのだが、方法がまだ確立出来ていない。
２つ目は「社内にシェアしてもそれが現場で本当に意味があるのか」が分からない点。
特に社内で共有会をやっていて思うのだが、基本的に社内のエンジニアにシェアしても大して反応は無いし、それがすぐに社内のサービスに影響を与えるということもない。
もちろん、仮に社外の勉強会に参加した所でそれがすぐに仕事に影響することなんて無いわけで、長期的に見て資産になれば良いだけのことである。それでも、業務に直接関係しなさそうなImmutable Infrastructure系の話とかCIの話だったりをしても全然反応がないのが若干辛い。基本的には社内で使ってないが、選択肢として覚えておいてもらいたい話題をチョイスしているのだが、業務時間にやっている以上は、もう少し現場に近いものをやった方がいいのか、それとも今のサービスが大きくなって負荷分散やソースの整理をしなければいけない事態になった時のことを考慮して選んだ方がいいのか。
いずれにせよ、自分は今の会社では若造の方なので、自分より年上のエンジニア達に話を聴いてもらうのは色々と工夫が必要であるということはよくわかった。基本的に３０を過ぎたエンジニアに新しい技術をインプットさせるのは相当な工夫がいるようなので、今後は巻き込み方とか、会の在り方とか色々考えていかなければいけないと感じている。
世の中の企業の研究職やR&D職の人もこんなジレンマと闘いながら業務にあたっているのだろうか。
