承認これくしょん

my black histories

自社製品開発エンジニアに転職して 3 年経った

転職してからずっとブログをお休みしていましたが、いい機会なので1簡単にこれまでを振り返ってみようと思います。

3 年間でやったこと

1 年目

スクラムチームに所属して、自社製品の次バージョン開発をやっていました。

それなりに大きな規模のコードベースを相手にする改修は、私にとって初めての経験でした。 当時は不安もありましたが、幸いにもスプリントプランニングやペアプロなどで同僚の仕事の進め方を間近で見ることができました。 現在のテクニカルスキルの多くは、そこで学んだことが基礎になっていると思います。

特に「設計思想やモジュールの責務を理解し、適切な場所に修正を加える」具体的なアプローチを知れたのが、私にとって財産になりました。 前職では諸般の事情2から、「できる限り差分を小さくする」場当たり的な改修ばかりで、上記が重要と知っていても実践する機会はありませんでした。 そのため自分自身で interface を定義することもなかったのですが、実際の使用例やそれによる恩恵を理解してから使用頻度が増えました。

2 年目

自社製品をベースとしたクラウドサービスの開発をやっていました。

インフラとして使用する AWS の知識はほとんどありませんでしたが、同僚の支援を受けながら仕様検討を進めました。 ここでは各選択肢についてメリット・デメリットを提示し、関係者を集めて議論により決定するやり方を学びました。 これによる決定は関係者間のレビューを経ているため、独りよがりな結論にはなりにくい印象がありました。 そのため、その方針に基づいて出来上がったタスクは自信をもって進めることができました。

また作業を社外の方にお願いする場合もあり、それが必要と判断した根拠などをミーティングで共有することもありました。 パワポ資料を準備して臨んだりと、いい意味で SE 時代よりもそれらしい仕事をする機会を得られました。

3 年目

前半は昨年度と同様にクラウドサービスを、後半からは 1 年目に担当した自社製品も含めて横断的に活動するようになりました。

年度初めに中途入社された方が私のチーム配属となり、こちらはメンター的な立場で一緒に仕事をするようになりました。 ちょうど私が入社したころに経験したようなペアプロを行い、たくさん会話しながら実装を進めました。

コーディング以外では、以下のような活動を行いました。

  • 前述のクラウドサービスの有識者としてナレッジを esa にまとめる
  • 他チームへの情報共有
  • 流しのコードレビュー 3
  • エンハンス要望の実現可能性と工数調査

所感

「きちんと設計して可読性・保守性の高いコードを書くスキル」はある程度身についたと思います。

特定の技術分野に注力するよりは、まず一通りのことをこなせるよう努力していましたが、これも一定の成果を得られたと思います。

私自身の指向がゼネラリスト寄りなので戦略は間違っていなかったと思いますが、一方で今後のキャリアについて悩むようになりました。 その時必要とされるスキルが市場価値の向上に役立つとは限りませんし、日々進歩していく技術をキャッチアップしていく必要もあります。 いよいよ自分が何を大事にしたいのか……といった価値観が問われているのかもしれませんね。

こんな経緯から kiitok でキャリア相談してみようと Facebook に登録したのですが、翌日アカウントがブロックされて今に至ります。


  1. 平成の終わり、周辺状況の変化に一区切りついたなど

  2. ソースコードの品質、変更箇所をコメントで明示する文化、BP として参画している……など

  3. 必ず一人はレビュアーにアサインされる決まりですが、私が担当でない場合も気になった点はコメントしていました