Webエンジニアになって稼働ベースで200日経ったので振り返る
はじめに
（どういう節目！？という声は置いておいて）
みやと申します！🥃
10月にWebエンジニアに転職し、7月末で稼働ベースで200日経ったらしいです。
4月にやってからサボっていた温めていた振り返りをしておこうと思います。
月ごとに振り返っていると長くなってしまうので、
・この期間に考えていたこと
・感じた課題
などをベースに振り返りたいと思います。
一応超〜〜ざっくり何やってたかを挙げておきます。
4月
新規機能をガッツリ任せてもらう
設計~リリース可能な状態までの実装まで
5月
issueの進め方やその他の諸問題により上記機能のリリースが遅れる
上記機能が終わり、既存機能へのデカめの追加機能を任せてもらう
前述の遅れによりタイトめなスケジュール
6月
追加機能の潜在的な複雑性が想定より高かった＆進め方をミスり、追加機能のリリースがまたしても遅れてしまう
7月
追加機能リリース
既存機能改修（現在）
この期間に考えていたこと・感じたこと💭
大きめの機能をガッツリ任せていただいて、基本的にはそこに集中して取り組んでいた感じでした。
この期間は、技術力というよりもどちらかというと「仕事/Issueへの取り組み方」や「コミュニケーション」など技術力以外の部分で多く失敗し、学んだ期間でした。
実装力不足の不安からくる生産性の低下
前提として、この期間を通して工数に対して追加したい機能が多く、基本的にタイトめなスケジュールの中で開発をしてました。
その上、実装できないものはないけど、どれくらいの時間がかかるかは分からないという気持ち（実際そう）があったので、以下のような選択をしてしまいました。
・ 既存機能をしっかり把握する時間を取るよりも、とにかく手を動かして実装していくことを優先
・ テストは最低限だけ書いて残りは後から
ただ、6月にやっていた追加機能がただでさえ複雑な要件な上に
この選択によって考慮漏れが起こったり、開発スピードが低下する要因になってしまいました。
（その後「人が増えても早くならない」を深く頷きながら読みました…笑）
見積りとコミットメントの誤解
またこの期間は、見積もりとコミットメントの違いを意識できていなかったのも良くなかったと今振り返ると思います。
「見積もりはあくまで見積もりであり、確約事項ではない」という理解があれば上記のように本来必要なことを捨てる選択もしていなかったかもしれないので、同じ失敗をしないように意識したいと思います。
また自分が理解していても、相手が違いを理解していないと意味がないの
で、そのコミュニケーションも欠かさないようにしたいと思います。
※「見積もりとコミットメントの違い」自体についてはここでは深く触れません。以下の記事がわかりやすかったのでご参考までに！
3種類あるそうです。200種類じゃなくてよかった
issueの取り組み方・仕事の進め方
他にも改善できる点はあり
・アプリ開発側とのコミュニケーション
・WebのバックエンドのAPIを使っているため、認識を合わせる必要がある。
・APIの実装が遅れ、ボトルネックを生んでしまった。
・PRの分割の粒度
・初期リリースまでの優先順位の入れ替え
たとえば、「APIの実装が遅れ、ボトルネックを生んでしまった」というところだと最低限のレスポンスを返すAPIだけを先に作っておくなど、
技術力はあまり関係なく、自分の工夫次第でチームとしての開発生産性を上げることができる部分だと思うので、同じ失敗は避けつつ工夫点を探していきたいです。
仕事と自分の勉強
この期間、試しに帰宅後は自分の勉強はあまりせず、業務の続きをやってみてました。（終わるか不安だった＆これまでは自分の勉強メインだったので）
ただ、特別多く実装できたかというとそうでもなく、あまり上手くいきませんでした。
帰ってからも実装できる時間があると思ってしまうと、
業務中に100%の集中力を出そうとしなかったんだと思います（甘えlv100）
業務中に終わらせようとするからこそ集中力の高い状態を保つことができるのであって、帰ってからも仕事に時間を使うのはその状態を作ってからやるべきだったと今は思います。
よかったこと⭕️
反省点が多すぎるので、自分で後から見返したときに耐えられるように良かったことも挙げておきたいと思います。
集中力を高く保つHack
７月の中旬頃に知人のアジャイルコーチに教えていただいた
一日を30分のタイムボックスに区切り、そのタイムボックスに作業を合わせる
この方法を取り入れてから、一日を通して集中力を高く保つことができるようになりました。
入社初期にもgoogleの15分ルールを試してはいたものの、いまいち上手くいかず定着しなかったのですが、
今回のルールでは
・30分に拡張したこと
・30分でできる範囲を見積もれるくらいの実装力と経験（慣れ）がついてきたこと
でうまくいっているような気がします。
まだ実践して2週間弱ですが、この方法をやっていて感じるメリットは
・一定のリズムができること
・小さな進捗を重ねられること
・詰まったときに詰まっていることを実感できること
・気づいたら数時間経ってる、みたいなことを防げる
・作業を細かくすることで一つのことに集中できる
など。
実は3つ目、4つ目は今振り返っているときに気づいたのですが、
こう見ると結構無視できないメリットがありますね。
4つ目とかも入社初期では結構難しかったと思うので、やはりフレームワークを脳死でそのまま使うのではなく、自分に合っているかを考えながら活用する意識が大事だと思いました。
ちなみにタイマー&記録のために以下のサービスを使っています。
時間内で何をするかを記述するスペースがあり、その言語化の過程でやるべきことが明確になっていい感じです👌🏻
実装できる自信
ここは恥を捨てて書きますが、4月に任せていただいた新規開発を設計以降ほぼ一人で実装することができて、思ったより実装できるぞという自信がつきました。
まだ時間がかかることもあるし、具体性が高かったり、抽象度が揃ってなかったりということもありますが、コードが難しすぎて手が出ないことはほとんどなく（そういうissueを振ってもらってるだけかもしれませんが）
自分が好きな「より良く書くこと」にようやくほんの少し頭を使えるようになってきたのが今の実感としてあります。
（こんなことを書いてるとくそ難しいデータ構造とかが出てきそう…）
ただ、業務知識では自分だけでは到底手が出ないような部分もあったので、こちらも合わせて伸ばしていきたいと思います。
この期間で読んだ本📚
LeanとDevOpsの科学
人が増えても速くならない
issueから始めよ（再読）
サクッとわかるマネジメント（再読）
アクションリーディング
「技術書」の読書術
緋色の研究（シャーロック・ホームズ）
LeanとDevOpsの科学をちょうど読み終えた頃にfindyさんの開発生産性カンファレンスがあったんですが、仕事に追われていて行けなかったのが残念でした😢
調整できるように実装力もっと上げたい。
あとは帰っても仕事のコードを書いてたからか技術書を全然読めてなかったので、今月〜来月は技術書の割合を上げたいですね。
まとめ
やってみないと分からないスタンスで色々試行しましたが、振り返ると見合った結果になっていない事が多く、仮説の精度が足りないと言う感じでした。
考えすぎてしまうと動けないのでどこかでえいやするタイミングは必要だと思いますが、自分の場合はそのタイミングをもう少し後ろにした方が良さそうに感じました。
この辺りは次の3ヶ月で改善していきたいです。
一方で試行回数はそれなりにあったと思うので、その部分はキープしたいですね。
割りとネガティブ多めな振り返りになっちゃいましたが、
エンジニアとして200日働いても一日も嫌だと思ったことはなく、
やればやるだけ出来ることも増えるし、それがコードに表れるため成長実感もしやすいし、この道を選んで良かったと改めて思います。
※たまに知らないことの多さに絶望しかけますが見てみぬふりをして精神を保っています
振り返りについては、頻度が低いと鮮度が落ちて執筆量も増えてしまうのでできる限り毎月やろうと思います。少なくとも2ヶ月ペースでは、、、
実は今回も内容がまとめ切れずすこし諦めかけたんですが、笑
同じスクールに通っていた柊さんの振り返りに力をもらって書き切れました。ありがとうございます！
個人的な備忘録にも関わらず、最後まで読んでいただきありがとうございました🙇🏻♂️
それでは！
※今回のサムネイルは7月に行った静岡の大室山でした🏔
この記事が参加している募集
この記事が気に入ったらサポートをしてみませんか？