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