msksgm’s blog

msksgm’s blog

Webエンジニアです。日々の勉強記録、技術書感想、美術観賞感想を投稿します。

2022年の振り返り

概要

2022 年の振り返りをします。

2022 年に立てた目標は以下です。

msksgm.hatenablog.com

振り返り一覧

2021 年の振り返りの反省で、1 月ごとと四半期ごとに目標を立てて振り返りを計画していました。 無事に毎月と四半期ごとの振り返りを実施できました。 振り返りの粒度はまちまちですが、継続できて良かったです。

振り返ってみた感想は、1 ヶ月ごとと比較して、3 ヶ月ごとに振り返ると明らかに進捗度具合がわかるようになりました。 3 ヶ月前と比較して技術の習熟度具合や関心事の変化が明確にわかります。 一方で、3 ヶ月だと自信はつかないと思いました。普通に考えたら自信がつくほどの内容が学べるかといわれた、そうでもない期間だと実感しました。半年程度でようやく具体的な方向性がわかってくるレベルなんだと思っています。この期間については個人差があると考えています。今後は、自分は半年続けて技術の方向性を見直そうと考えています。 そのため、今年はおこないませんでしたが、来年は半年間の振り返りをおこないます。

月の振り返り

msksgm.hatenablog.com

msksgm.hatenablog.com

msksgm.hatenablog.com

msksgm.hatenablog.com

msksgm.hatenablog.com

msksgm.hatenablog.com

msksgm.hatenablog.com

msksgm.hatenablog.com

msksgm.hatenablog.com

msksgm.hatenablog.com

msksgm.hatenablog.com

msksgm.hatenablog.com

四半期の振り返り

msksgm.hatenablog.com

msksgm.hatenablog.com

msksgm.hatenablog.com

msksgm.hatenablog.com

目標

生活習慣

生活習慣として、朝 4 時におきてジムに通うことをやっていました。 10 月ぐらいまでは、週 5 回でできていたんですが、年末が近づくにつれて朝が寒いのと生活習慣の乱れによって、週 3 で通うようになってしまいました。 途中から重量がほとんど変わらなくなってしまったのも、モチベーションが下がった要因です。

勉強時間を増やすために、始業時間を遅くした結果ランニングもしなくなりました。流石に生活習慣の悪化による体力の衰えを実感しはじめたため、危機感を持っています。来年度はジムに通った日をメモして、ある一定の日数を超えなかったら、ジムを退会しようと考えています。やめた後は家トレかリングフィットアドベンチャーとかにして、ハードルを下げます。

勉強関連

勉強時間

計測を 5 月から始めました。「Be Focused」というポモドーロタイマーで計測しています。結果を表にまとめました。 1 月から 4 月は平均 100 時間ぐらいは勉強できたのではないかと考えています。 そのため、合算すると約 1306 時間になります。1 万時間の法則というのがありますが、実家住みで時間を確保しやすい状況で、この結果だったので達成するのは難しい数字だとよくわかりました。

1 月 2 月 3 月 4 月 5 月 6 月 7 月 8 月 9 月 10 月 11 月 12 月
- - - - 約 121.6 時間 約 100.2 時間 約 152.4 時間 約 101.6 時間 約 95.3 時間 約 127 時間 約 128 時間 約 134 時間

時間を確保できて満足感はありますが、それに対してリターンを考えたら満足できていません。 とりあえず質よりも量をとってから、質を追求するタイプなので、今年は割り切って来年目標を設定する際に、どうやったら質を追求できるか考えます。

注力分野

2022 年の上半期は以下を目標としていました。

いろいろ掲げていますが、最初の 6 ヶ月間に主に勉強していたのは、Go、ドメイン駆動設計(DDD)、セキュリティです。この 3 つから学んだことから技術的関心事が移り変わりました。

特に注力していたのは、DDD です。知人間でドメイン駆動設計 モデリング/実装ガイド(松岡本)と実践ドメイン駆動設計(IDDD 本)の勉強会を主催しました。どちらも初めて読む本でしたが、徹底的に予習をおこない当日発表するというのを繰り返しました。それらの時間を合算したら 200 時間程度になりました。この時間をかけて知識の整理を強制されるため、 3 ヶ月たったころには曲がりなりも自信を持てました。 しかし、その後、業務に導入しようとしましたが、大きな課題感がありました。DDD が必要なのかだったり、何を対象にするかだったりです。現状、実務に DDD を導入できているとは言えません。ただ、システム理解のためにドメイン知識とソースコードの対応づけは意識づけられたように感じています。 DDD というのは名称として具体化されすぎたメソッドに感じられたため、もっと汎用的な設計分野を学びたくなり、会社の知人と設計書籍の勉強会が始めることにしました。

セキュリティは、認証認可の本を再度読みました。Auth 屋の書籍と Keycloak の書籍です。OAuth・OIDC 周りに加えて IAM 分野も学べました。資格試験は「セキュリティマネジメント試験」と「徳丸実務知識試験」の受験を目標に勉強していました。前者は無事に合格しました。後者は勉強と勉強会もしていたのですが、使用 PC が M1Mac のため、一部動かないアプリケーションがあり断念することにしました。 結果として、脆弱性と認証認可の両方を学べました。個人の範囲では Web を対象としたセキュリティの知識が一区切りついたため、勉強を中断することにしました。飽きたというよりやりきった感が強かったです。

最後に Go です。RealWorld を実装しようと挑戦してみたり、ドメイン駆動設計入門のソースコードを Go に置き換えてみたりしていました。結果として得られた知見は個人的にシンタックスが合わなくて、しかも戦術的 DDD と相性がわるそうに感じたことです。後者については、以下の記事にまとめました。批判的な記事だったため、最初は反響が怖かったのですが、意外といいねをいただき批判的な意見もなかったので出してよかったと思っています。

zenn.dev

そして、Go で DDD を実践できなくても DDD を身につけたい欲実践したい欲はかわりませんでした。すると、オブジェクト指向言語へと関心事が移りました。結果、Kotlin に対して強い興味を持つことになりました。

以上の経験から 2022 年下半期は以下の 2 つ目標を切り替えて注力しました。

  • Kotlin
  • 設計

Kotlin は RealWorld の実装をおこない、zenn に記事を投稿することで知見を深めました。 題材は RealWorld です。 自分の数倍知見のある方に手伝ってもらったので、なんとか勉強が続きました。 人に助けてもらいながらですが、プログラミングの課題に対してやり切ったのは初めてのような気がするので達成感もありました。 Kotlin に加えて DDD の実践、Git、スキーマ駆動開発、renovate、テスト論など 1 人では得られなかった知見を獲得できたので、今年の下半期の学習は非常に充実していました。 おかげで Kotlin が一番好きな言語になりました。 現在は人に体系的に教えられるよう Kotlin の技術書を作成しています。 そして、本を書く難しさを痛感しています。 年末年始の目標として引き続き書籍を執筆します。 書籍が完成したら、次の目標は OSS へコミットです。

設計は、設計の書籍の勉強会をおこない議論することで知見を深めました。 半年の間、課題図書として読んだ書籍は以下です。

前半 2 つでソースコードレベルの設計を学び、後半 2 つでは抽象度の高い設計について学びました。 このバランスは結果として自分の設計観点に幅を持たせてくれたと考えています。 これらを読んで、ソースコードや言語に関係ない 2 つ考え方を持ちました。
1 つめは「全ての設計には唯一解はなく、必ずトレードオフがある。トレードオフのない設計は設計できていない」です。 「ソフトウェアアーキテクチャの基礎」から学びました。 例えば、「DDD は導入と保守コストが高いので、大規模アプリケーションには適用できるが、小規模アプリケーションには向いていない」といった意見がよく言われます。 DDD に限らず、全ての意思決定においてトレードオフは発生する可能性があります。 些細なことで言えばインタフェースにより抽象化やテストダブルにモック・スタブ・フェイクのどれを選ぶのかといった規模でもトレードオフが発生します。 設計について安易に「ベストプラクティス」ということはできません。 答えを求めて設計の勉強をしていたつもりが、答えは存在しないことを再認識しました。 そうなると大事なのは意思決定です。個人の範囲ではなく、可能な限りステークホルダーが合意する意思決定をおこない、意思決定の記録に残さないといけないと考えるようになりました。 2 つめは「コンウェイの法則とその逆は常に成り立つので、ソフトウェアの問題は人の問題」です。
ソフトウェアの設計はマクロとミクロの両方の観点は組織構造が反映されます。 1 つめの学んだことと関連しているのですが、当時のチームの意思決定が強く反映されるので、誰かの問題というより組織の問題になります。 そのためチーム全体でソフトウェアアーキテクチャについて意識しなければあっというまに負債が生まれてしまいます。 それぞの経験や学習したことから成り立つ感性を大事にし、噛み合わなくても相手の神経を逆なでしないように議論を重ねていくことを意識しようと考えています。

Kotlin と設計を学んだのは非常に楽しく、とても良い経験になりました。 これらを踏まえた次の行動は以下の 2 つを考えています。

  • Kotlin と設計を保証するために、CI/CD とテスト(QA、テスタビリティ)を注力する
  • Kotlin、設計、CI/CD、テストを実践できる環境に映る

1 つ目は、自分は Kotlin と設計の両方がとても好きなのですが、好きな技術に対してコストと評価する力が不可欠だと考えたからです。CI/CD によって人が注力する領域を絞り、QA 観点から品質を保証する力を必要に感じました。来年は OKR 分析で 3 ヶ月ごとに分析します。
2 つ目は、技術的関心事を実務でも活かしたいからです。現職でも実践できるのならば良いのですが、難しい場合もあります。1 年目と比較して技術の方向性が固まってきたので、開発体験を向上させるために環境を移りたいと考えています。

英語

途中から優先順位が下がり、取り組みませんでした。 来年の目標からも外します。

読書

感想文を書いたのは 34 冊です。 設計・DB・セキュリティ・Kotlin に関連する書籍を読んでいました。 12 月に「『技術書』の読書術」に書いてあった 90 分読書法を実践しています。90 分読書法の記録は読書メーターを利用しています。

msksgm.hatenablog.com

msksgm.hatenablog.com

msksgm.hatenablog.com

msksgm.hatenablog.com

msksgm.hatenablog.com

msksgm.hatenablog.com

msksgm.hatenablog.com

msksgm.hatenablog.com

msksgm.hatenablog.com

msksgm.hatenablog.com

msksgm.hatenablog.com

msksgm.hatenablog.com

msksgm.hatenablog.com

msksgm.hatenablog.com

msksgm.hatenablog.com

msksgm.hatenablog.com

msksgm.hatenablog.com

msksgm.hatenablog.com

msksgm.hatenablog.com

msksgm.hatenablog.com

msksgm.hatenablog.com

msksgm.hatenablog.com

msksgm.hatenablog.com

msksgm.hatenablog.com

msksgm.hatenablog.com

msksgm.hatenablog.com

msksgm.hatenablog.com

msksgm.hatenablog.com

msksgm.hatenablog.com

msksgm.hatenablog.com

msksgm.hatenablog.com

msksgm.hatenablog.com

msksgm.hatenablog.com

msksgm.hatenablog.com

美術館

上半期には毎月通っていました。 下半期にはブルーピリオド展にいったのみです。 来年は久しぶりにいこうと考えています。

msksgm.hatenablog.com

msksgm.hatenablog.com

msksgm.hatenablog.com

msksgm.hatenablog.com

msksgm.hatenablog.com

技術記事の作成

技術記事を 34 記事書きました。 52 週のうち 34 週書いた計算になるので、1 年間の 65%は技術記事作成を意識したことになります。 題材はドメイン駆動設計や Kotlin の内容が一部を占めていて、他は雑多な内容がおおいです。

週 1 投稿をして思ったメリットは以下です。

  • 体系的な知識の定着を目的とした技術記事作成は目的を達成できた
  • 知識をインデックス化できたため、業務中に自分の記事を漁って調べやすくなった
  • 興味のある分野を対象に一次ソースを漁るようになる

デメリットや問題点は以下です。とりあえずは量をこなせばいいですが、途中から質を考えなければならない内容になりました。

  • 短い記事でもフィードバックがなければ体系的な文書の作成能力は頭打ちになる
  • 題材を選ばなければ週 1 投稿はなんとかなるが、内容が薄くなるのは避けられない
  • 投稿することが目的なのか知識をまとめるのが先なのかブレ始めると効果が薄くなる

来年も Kotlin についての記事を書く予定ではありますが、週 1 投稿はやらないです。 書くとしても以下を実践することでクオリティを落とさないように意識します。

  • zenn の記事を CloudRun を使って限定公開することで、事前にレビューをもらう
  • 可能な限り自分が注力している領域(Kotlin、設計、テスト、CI/CD)に絞ることで、内容に対して責任を持つ

zenn.dev

zenn.dev

zenn.dev

zenn.dev

zenn.dev

zenn.dev

zenn.dev

zenn.dev

zenn.dev

zenn.dev

zenn.dev

zenn.dev

zenn.dev

zenn.dev

zenn.dev

zenn.dev

zenn.dev

zenn.dev

zenn.dev

zenn.dev

zenn.dev

zenn.dev

zenn.dev

zenn.dev

zenn.dev

zenn.dev

zenn.dev

zenn.dev

zenn.dev

zenn.dev

zenn.dev

zenn.dev

zenn.dev

一年の総括

今年一年間で月の振り返り、四半期の振り返りを実践しました。 そのおかげで、年間の振り返りがしやすくなったため、反省を活かせました。 いろいろありましたが、継続できたことに自信を持ちます。勉強時間の記録も数字は嘘をつかないため、良い定量化につながりました。来年は年間を通して記録します。

勉強の関心事は上半期と下半期でまったく違う結果になりました。 上半期の目標は下半期の目標を見つけるために必要だったので、必要な時間でした。 また、興味が変わらないのもまた不自然なので、それだけちゃんと勉強できたんだと考えています。 そして、半年に自分の 1 回は技術的関心事を変更する可能性があることを考えると、6 月に意思決定がおこる予測を立てられました。具体的には以下です。

  • 技術的関心事が変わる場合:より自分に向いている関心事を見つけた
  • 技術的関心事が変わらなかった場合:感覚的に向いているものだった

そう考えると来年の上半期で関心事が変わらなかった場合、環境を変えるのに頃合いなんだと思っています。職場を変えるかどうかはわかりませんが、曖昧な意思決定にならないように、勉強を重ねます。

読書も関心事に引っ張られた本を読んだり読めかったりしていました。 分厚い本をとりあえず目を通すだけでも効果を実感したので、来年は浅く読む本と薄く読む本のバランスを大事にして読んでいきます。感想文も読み終わってから感想が遅めなので、可能な限り早くします。

趣味系は時間を割くのが減ってしまいました。最近は、エンジニアの感性について考え始めてから、美術館にまたいきたくなったので来年は空いている日を見つけて積極的に通います。

技術記事の作成の当初の目標では、週 1 投稿でしたが途中でやめたり再開したりしました。技術記事作成はメリットが多いとよく言われ、実際その通りだと思っています。しかし、この記事を読んでジャンクフードのようなアウトプットについて考えるようになりました。それから、質についても判断するようになりました。書くからには上質なアウトプットをしたいです。

業務では、人の増減、裁量の増加、チームビルディングの実践とコーディング以外様々なことを実践しました。よい経験であり疲れも感じて年末に体調を崩してしまいました。充実もしているのですが、納得しきれない意思決定もあります。来年はリスペクトを持ちつつ手が届く範囲から納得のできる決定や意見をだせるようになりたいです。

今年の感想は、「記録をおこなうことで自分の尽力具合がわかったけど、来年も似たようなやり方はよくないと思った」です。時間は費やしましたが、技術記事の質、インプット・アウトプットの比率、技術的な貢献度具合ではまだまだだと考えています。来年も振り返り方は継続しますが、貢献への指標の定量化の改善が急務です。

長くなりましたが、まとめは異常です。今年も振り返りができて嬉しいです。まだまだベストではないので、良かった点と反省点の両方を引き継ぎ、来年も引き続き尽力します。それではよいお年を。