seri::diary

日常

キャリアを積み直せ

あまり過去を振り返って後悔していることはないんだけど、一つだけあるとしたら高校時代に将来の職業について何も考えずに大学を選んだことである。

某大学農学部に行ったのは、前提として高校を出たら国立の大学に行かないと親が許さない状況(考えてみれば姉二人は私立だったのだからおかしな話だ)、しかし興味のあることが生物ぐらいしかない。じゃあ農学部か、ぐらいの感じであった。結果としてどうなったかと言えば、卒業研究でリンドウの花弁の画像計測+判別分析を用いた予測モデルの構築という今の機械学習への興味に繋がる貴重な経験はできたのだが、結果としてそれを元に就職するほどの学術的知見はなく、SEとして就職してその後サービス開発屋になって現在に至る。

これまでのキャリアに何も不満はない。SIerで新卒入社→事業会社に中途入社というのは、数年前に流行ったSEのキャリア転換の典型そのもので、自分のキャリアは客観的に見ればうまく行っているのだと思う。幸いにして、現在は転職時にこちらが会社を多少選ぶくらいのことはできるぐらいのスキルも身についた。

悪くない。しかし、自分がここまでスムーズにキャリアを積めた要因は、これまで周囲から言われた評価を統合すれば、結局のところ「よく働く」以外の何者でもなかった。 単に会社員として優秀、というもの以外の何者でもない。実際、エンジニアとしてのスキルは非常に平凡で優れているとは決して思っていない。 エンジニアリングだけで見れば自分より優秀な人はたくさん見てきた。自分には、言ってしまえば、既存のフレームワークの上でビジネスロジックを実現するだけのスキルしかない。言語やフレームワークを乗り換えることはできる。むしろ得意な方だが、ゼロから何かを実装するスキルはない。だから誰かが作った環境の上に乗っかるしかない。ついでに言えば結局webアプリケーション以外の実務経験はないから知識が酷く隔たっていることも自覚している。

今の職場環境を考えれば非常に贅沢なことを言っているのはわかるのだが、今はそれが今後のキャリアにおける最大の不安である。結局のところ自分のような会社員として評価されるような人間はマネージャーになるしかないと薄々感じているが、正直に言えば「会社員として優秀なエンジニア出身のマネージャー」で終わりたくないと感じている。

今はエンジニアとして本当に難しい問題を解決する力が欲しい。最近、仕事でもパフォーマンスが問題になっている箇所について取り組んでいても、効率のいいデータ構造もアルゴリズムも知らない自分にはマシンリソースを増やすことで力技で解決することしかできないケースが増えている。費用対効果を考えたら時間をかけるよりマシンリソースを増やすことで対応する方が良かったりするのでビジネス的には間違ってないかもしれないが、永遠にマシンリソースを増やしていくことが本当に正しい解決策なのか。本当はもっと優れたアルゴリズムを書いて解決できそうな問題もあり、実際社内では将来パフォーマンスが問題になりそうでなんとかして書き直せないかという議論が度々起こるメソッドがある。しかし自分にはそれを解決できない。

上記を踏まえた上で、今年に入ってからもう一度本当に「エンジニアとして」のキャリアを積み直すために動いている。具体的にはこのブログでも何度か書いてるが、具体的にパタヘネ本とその他資料で大学のCS専攻の学部卒業と同レベルの知識を積み直す。だいぶ忘れている高校数学をやり直す。(今は数ⅡB辺りか。この辺の勉強方法についても別途記す)TopCoder,Hackerrankの問題解きつつアルゴリズムについて勉強する。昔とった杵柄、機械学習をゼロから勉強し直す。データサイエンティストになるつもりはないが、今関心がある大量のデータを効率的に処理する処理、及びそこから必要な知識を得てデータを活かすことをスキルとする場合において機械学習は必須であると考えた。また、機械学習と統計の違い、ディープラーニングとNNの関係すらちゃんと理解していないエンジニアが多いということに最近気づいたので、まだこの分野では頭一つ抜けるチャンスがあるのではないかという打算もある。

その先に何があるか。独学では正直限界があるのと、時間が十分に取れないということから、一度サービス開発屋としての仕事から離れて時間を取って勉強したいと考えている。具体的には大学院進学を真面目に考えている。問題は果たして金銭的になんとかなるのか?というのと、卒業後にちゃんと再就職できるかという点。この2点については今後対策を検討していく。幸い、前者については試算した限りでは今のペースの貯金で数年貯金すれば学費を払いつつ引っ越しもしつつ2年間無職でも食いつなぐことができそうな目処が出ているので、どちらかと言えば問題は後者か。

普通30にもなれば結婚して家庭を持って、そんな大きなチャレンジはできなくなる年齢かも知れない(でも最近は晩婚化進んでるしそうでもないか?)。幸い自分には今は仕事しかない。仕事しかないのなら、できるところまで突き詰めて生きていくしかない。

会社で朝活を始めた

一人でも相変わらず何か勉強的な何かを続けてはいるのだが、社内slackで朝活の機運が高まったのでオフィスで朝活をやることにした。毎週水曜日の朝9時から10時まで。

朝活といっても今の所はただ集まって各々がやりたいことをするのみに留まっている。自分はひたすら高校数学の問題集を解いていた。他の二人はhackerrankの問題を解いたり朝lintをしたりしていたようだ。参加者も自分を含めて3人しかない。いつ無くなるかも分からない。人が増えればなにかテーマを決めてLTをする時間を取ってもいいかもしれない。

仕事以外のことをする時間を取ることが今の自分には必要だと感じる。仕事だけをしていると人生が不安になる。今後何をして生きていけばいいのか、もはや分からなくなりつつもあるのだが、仕事だけではなく何か一心不乱に取り組めるものがあると救われる気がしている。今の自分にとってそれがCSだったり機械学習だったり数学だったりギターだったりする。

やる気がしない時

どうしようもなく仕事したくない時もある。明確な理由もないのだが(多分)、まぁそういう時もあるということだろう。

それでも明日は月曜日だし会社には行かなくてはいけない。けれども行きたくない。

それでも大体仕事に行けてしまうのは出勤のための準備と通勤のための移動が作業興奮につながって意外となんとかなってしまうとかの体の仕組み的なものもあるだろうが、なんとなしにもうそういう儀式を経て仕事に向かうことが習慣化されていることによる「慣れ」の方が大きいんだろうなと思う。考えてみれば「朝起きて決まった時間に決まった場所に行く」というのは小学校の頃から続けている訳だ。

話を戻すと、目の下の問題は明日は月曜日だが会社に行きたくない。パタヘネ本を読みながらアセンブラを書いていたい。データサイエンティスト徹底入門を読みながらRをいじっていたい。線形代数の参考書を読んで手で問題を解いていたい。

そんな時どうするか。自分の場合

  • 機械的に手を動かせばいいレベルまでタスクを明確にしてから着手する。仕事が終わったらさっさと帰ってやりたいことをやる。
  • 全然関係ないことをする。最近はジムに通っているのだが無酸素運動有酸素運動の両方をそれなりにやって肉体的に疲労させると気分は幾分かマシになることに気づいた。
  • やる気がでない理由を論理的に考えて原因を突き止める努力をする
  • やる気が出るようになるまでダラダラ仕事して待つ

これらのことを試す。そうするとある程度はマシなレベルにまで戻る。

いきなり何を書いてるんだという話だが、別にうつ病とかそういうものではなくて単純に日曜の夜だから憂鬱になってるだけじゃないかという説もある。

最近忙しかったのでKPTした

4月末~6月上旬までかなりタイトなスケジュールのプロジェクトを担当していたのだが、そろそろ終わりが見えてきたので個人的な仕事の進め方に関するKPT

Keep

  • 1番リスクが大きくて難しい所の作業を1番最初にやることで心理的な余裕が確保できた
    • 他のタスクも優先度の高さと技術的難易度を優先して進めることであとで設計を見直したりする余裕を確保することができた
  • 労働時間を延ばさないと間に合わないことが分かっていたが、終業を延ばすのではなく始業を平均2時間ほど早めて対応した
    • AMはmeetingが殆どないので集中して作業する時間が取れたので1日全体で見たときの作業効率がかなり高まった
    • 終業を延ばさなければいけない場合であってもAMに貯金があるのであまり終業は遅くならなくて済んだ日が多かった(退社時刻は平均して21時前後、1番遅い退社が23時過ぎだったと思う)
  • 色々あってプロジェクトの途中でリリース時に積むべき機能量の折衝をしないといけなくなったが、他のメンバーが判断できるレベルの十分な説明はできた(と思う)
    • プロジェクト始まる前にこれができればbetterだったが今回は色々あったので仕方がない

Problem

  • 5月中旬ぐらいまではうまくやっていたがその辺りから精神的・肉体的に疲弊してミスが増え生産性が落ちた
    • 「ちょっと疲れてきたかな?」と思った辺りで無理をしない、疲れを残さない対策を講じるべきだった
  • プロジェクトの全貌を掴んでいない状態から作業に入ってあとから出てきた追加タスクにうまく対応できなかった
    • 「ちょ、それもやるの!?」みたいなのがいっぱいあとから出てきたが、これは自分ではどうにもならなかった気もするが今考えたら早い段階でプロジェクトの全体像を全員が正しく共通認識として持つように提案をすべきだった
  • プロジェクトの目的とスケジュールがなぜ決まっているのかを正しく認識していなかったので感情的に納得できないまま自分が作業しておりストレスを感じながら作業していた(プロジェクト序盤
    • 最初に聞いておくべき。自分が入社する前から存在していたプロジェクトで回りは暗黙の了解みたいなので知ってたようだが、それを知ってそうな人全員に問いただせばこの辺は分かったはず。

Try

  • 自分が理解できてきない部分はプロジェクトが動き出す前にステークホルダーに確認すべきだった
    • とはいえ、仕事なので理解できなくてもやらなくてはいけないケースもある。そこは大人になって対応したい。(とは言え今回は自分が入社前から決まっていたことなので特殊ケースだと思う)
    • こういう事態を防ぐためにもプロジェクト発足時から積極的に不明なことはクリアにしていくようプロダクトマネージャーやプロジェクトマネージャー、経営陣に働きかけていきたい。
  • どんなに余裕がないときでも適度にサボる
    • 仕事しすぎた
    • 仕事しすぎると生きてるのが楽しくなくなって「なんで生きてるんだっけ?」「自分ってこの会社で何がしたいんだっけ?」的な哲学的なことを考え始めて時間を浪費してしまうのでよくない。
  • 自分が忙しいからといってイライラしない
    • ごめんなさい
  • 自分がだけがつらいと思わない
    • 考えてみれば今回のプロジェクトは色々あって関係者全員が何らかの形で辛かったのではないかと思う
  • リソース不足かどうか?は常に気を配り、足りなくなる前にヘルプを出す
    • 今回は割とギリギリのタイミングでヘルプを依頼して間に合った感じだがもっと早くヘルプの声をあげていても良かったのではないかと思う。
  • プロジェクトの進め方についてよくないと思う部分は積極的に改善案を出す
    • 全くの新機能が追加された上にサーバサイド、ios、webの整合性を完璧に取った状態でリリースしなければならないプロジェクトはまだ会社としても経験値が低い。やり方は都度考えていく必要がある。

コード改善 meetup #1でLTしてきた

コード改善 meetup #1 というmeetupが新たに始まると聞いて、エモい話ばかりブログに書いてる身として参加するのが義務であろうと思い、LTしてきた。

発表スライドはこちら。

speakerdeck.com

内容としては大して書いていない。これまで自分が所属してきた開発組織で体験してきたことをベースに、コードレビュー運用で起こりがちな問題と、それに対処するためのちょっとしたtipsを紹介した。

このmeetup、工夫されていた点として、単に発表者が発表して終わるだけではなく、その後発表された内容について参加者全員がディスカッションをする時間が確保されていた。

自分の発表の内容は、大抵どこの組織でも共感されやすい内容だったこともあったのか、いい感じに盛り上がって、

  • 「わかる」
  • 「うちも同じような問題がある」
  • 「うちは書いた人以外が全員でレビューしてる」
  • 「全員はつらくない?」
  • 「書いてるものによる?」
  • 「うちはそもそもレビューの文化がない」
  • 「ところでみなさんのチームって何人ぐらいのチーム?」
  • 「レビューコメントのつけ方ってすごく気を遣うよね。絵文字を積極的に使うとか」
  • 「レビューでdisり合いしてるんだけどそれでもうまく行ってるので特に気を遣ってない」

など様々な質問や意見が飛び交った。

参加者のバックグラウンドはSIerや自社サービス会社など異なっていたようだが、どの開発チームも同じような問題は多かれ少なかれ抱えているようだった。

他の発表についても色々な議論が飛び交って面白かった。その一部については参加者の一人の方がまとめてくれているのでリンクしておく。

blog.mogmet.com

この手の答えが出ないテーマをもとにディスカッションするのは面白いのだが、うまく自分が感じている課題を整理して参加しないとただ「うちもこういうのが大変でさ~」「うちもだよ」という不満を共有して終わってしまう危うさもあるように思う。

建設的な議論をするためには「つらい」とか「しんどい」という私情をこらえて、問題を客観的かつ広い視点で捉えて議論する必要もあって、今後参加する時には気を付けていきたいと思う(そういう意味では今回は非常に参加者の皆さんは建設的な議論をされていて大変よかったと感じた)。

勉強していること2016年4月版

  • 4月に入ってから完全に勉強が停滞してしまったので5月に入ってから立て直している
  • 花粉症・睡眠障害・肩こりなどの体調不良がずっと続いていた上に、新プロジェクトが始まったりして時間が確保できなくなっていたが、5月連休に入る頃には立て直した

CS

  • ヘネパタ本は読み進めていくうちに前提知識が不足していると痛感し、一旦置いておいてパタヘネ本を読む方向に変更。上下巻買うと8000円以上とか結構痛い出費だが圧倒的に読みやすい。

Elixir

  • 進捗なし

Golang

  • 仕事で使う可能性が出てきたので趣味ではなく割と業務時間も使って勉強し始めた
  • web apiの実装に使うというよりは重たい処理をするworkerやbatchの実装に使う想定

筑波大学大学院コンピュータサイエンス専攻 専攻公開・入試説明会に参加した

筑波大学のキャンパス来た。緑多くてよい。

www.cs.tsukuba.ac.jp

基本的に、筑波大学の学部向けの説明会だったようだが、学外の人間も参加できたので話を聞いてきた。

筑波大学の特徴として、

  • 国内大学のCS専攻としては講師の数がかなり多い
  • 講師が多いのでCSの分野でカバーしている範囲がかなり広い
  • 希望すれば同じく筑波にある産総研の研究所で指導を受けて研究ができ、筑波大学の単位として換算される
  • 社会人特別選抜枠があり、定員は1回の入試で1名〜2名だが、過去においては6人受験して5人入学してたりすることもあるので定員を超えて採用することもある模様 www.cs.tsukuba.ac.jp
  • enPiT(Education Network for Practical Information Technologies)のビジネスアプリケーション分野での提携大学で、PBL(Project-Based Learning)形式での授業がある
  • 留学生とか企業からの研究生受入が盛んなので社会人が入学しても違和感ないらしい(説明会会場にいた4回生に聞いてみた)