やる気がストロングZERO

やる気のストロングスタイル

2020年活動まとめ

2020年も終わるので1年を振り返る。

去年立てた目標と結果

yaruki-strong-zero.hatenablog.jp

 


去年言っていた「来年の目標」は以下。

  • kubeを使えるようになりたい。(運用してる個人サイトをkubeで動かすのを目指す)
  • もうちょっと仕事の割合を減らしたい。(あふれるタスクの捌き方とか、断り方とか??)

kube(k8s)は一旦使ってみたものの、インフラ側の知識不足により今は距離を置いている感じ。
個人的結論としては、RDSなどのPaaSをふんだんに使える状況ならアプリケーションエンジニアでもなんとかなる気がするが、そうでない状況の場合(自分でDBやその他ミドルウェアをセッティングしなければならない状況)はかなりインフラエンジニアの力を借りなければならならず、安易に手を出さないほうが良い、というもの。
個人サイトはgke => heroku => vps と構成を移行した。
gke => heroku はk8sの構築テストを終えた後、gkeの料金がそこそこ高かったので減らすために。
heroku => vps はちょっとミドルウェアやインフラセッティングを自分でやってみようと試みるために。主にelastic stackを使ってログ監視を構築したけど、アラート周りとかの設定が有料機能だかであまりスマートに出来ず、zabbixのほうが良かったかな、、となった。

 

「もうちょっと仕事の割合を減らしたい。」に関して、結果的には減らすことが出来た。
「結果的に」というのは、コロナの影響でリモート勤務になり、残業を行うことに対して会社の雰囲気も含めて心理的障壁が高くなった結果、残業が減ったという意味で、自発的に調整出来たわけではない。

あらためて振り返ると去年(と今年の始めあたり)残業が多かったのは「差し込みやそもそもタスクが多い」というのもあったが「スケジュールに沿えるように今日出来ることを出来る限り進めておきたい」という「残業でカバー」体質があったようにも思う。

本当にすべきだったのは「上に理由を説明しスケジュールを見直す」だったのかもしれないが、説明(何にどれくらい時間がかかったからどれくらいスケジュールが遅れるという説明。)作業が新たに発生し更に遅れることを嫌って、残業でカバーする方向になってしまっていた。

子供も生まれたので、こういうのが常態化しないようにしたい。

今年あったこと

テックリードになった

年齢的なものもあるだろうけど、一応普段の自分の興味から学んでいる姿勢とか、それを実際に導入してみる姿勢とかを評価されてテックリードポジションを貰った。

実際はテックをリードするほど色々知っているわけではなく、どちらかと言えばアーキテクト的な感じで動いている感じだった。

一人でやっていると問題にぶつかって解決して進めてまた問題にぶつかって、、と、問題は1つずつやってくるけど、数人に作業をお願いしていると一気に数個問題が上がってきて、自分が解決するスピードが遅いと他メンバーの作業がストップするというプレッシャーに追い回される事になった。

また業務委託さんのやることが無くならないように常に先回りしてタスクを整えるのも結構大変だなぁとか感じた。

自分は結構細かくメンバーにやってほしいことを指示するタイプなので上記のようなプレッシャーに追い回されることになった。

もっとメンバーに任せる範囲を増やせばもう少し楽かもしれないが、品質管理や方向性制御などが自分の力量的に出来る気がしないので今の所は今の感じで頑張って進めたいと思っている。(もっと自由にやってもらいつつ、大きくは当初の目標に向かっていく、、みたいな制御ができるようになれたら少し楽かも)

自分プロジェクトでアーキテクチャを自由に試した

去年からDDDを中心にアーキテクチャを独習しているが、業務の中では色んな制約でなかなか自由に試すことができないので、一度自分で自由に試してみようと試みてみた。

github.com

実際にやってみると本でつかんでいたイメージちがって「思ってたよりまどろっこしいな。。」とかイメージ通り「やっぱり有用だ!」とか思うところがそれぞれあった。
また、Goで試みているけど、Kotorinとかのほうがよかったかもしれない。

コツコツ続けているけどまだ完成は見えてこない。

その作業風景をYouTubeでも公開してみている。

俺が考える最強の契約管理システムを作る - YouTube

YouTubeは"ついでにやってみた"位の感じなので編集作業とかしていないし見易くはない。わかってたことだけど、やっぱり人に見てもらうのが目的だったらそれなりにコスト払わないと見てもらえるものにはならないすね。。

OSSコードリーディングをやってみた

 自分は昔からコードリーディングがあまり得意じゃなかったが、Goのコードはやはり読みやすくOSSのコードリーディングに対する心理的障壁がかなり下がった。

GoのOSSのコードが読みやすかった理由は

  • コードの作りが疎結合であまり広く把握しなくても理解できる
  • 型が読む際のヒントになる
  • 愚直な記述が多く事前知識があまり要求されない

あたりかなと思った。

OSSのコードを読むことで、効率的にノウハウがたまるので継続的にやっていきたい。

来年は?

ストレスを減らしてQOLを上げたい

ストレスの溜まりやすい仕事が増えてくる年齢だと思うので、いかにストレスを溜めないかを考えたい。
ストレスが掛からないように仕事のやり方を変えたり、考え方を変えてストレスに感じないようにしたり。
外的要因の排除は難しい場合が多いので、主には考え方を変える必要がある気がしている。

自分の持ってるノウハウをわかりやすくまとめておきたい

やっとなんとなく自分の得意なエンジニアリングの方向が見えてきた気がするので「どういう事が得意でどういうノウハウを持っているのか」をわかりやすくまとめてみたい。