2024年も終わるので、今年書いたTechな記事を振り返りたいと思います。
今年もお疲れ様でした。
総評
- 合計20記事書いてました。
- カテゴリ
| カテゴリ | 記事数 |
| リーダー経験 | 9 |
| 書評 | 1 |
| 品質 | 2 |
| 資格 | 1 |
| 雑記 | 1 |
| 環境構築 | 1 |
| 効率化 | 1 |
| イベントレポート | 1 |
| スクラム | 1 |
| コーディング系(Kotlin/Java, Spring) | 2 |
- 今年は（一応）リーダーとしての活動が多かったので、そこでの学びを記事にしたものが多かった模様。
- 逆に技術的な深掘りとかは浅め。
自分のペースで学ぶTCP IP
- 「低レイヤもわかんないとな〜」と思って年末年始休みにブックオフで買って読んだ本。
- OSI参照モデルとTCP/IPの違いとか、それぞれの層は何を責務にしているのかとか、ざっくり触りがわかる本。
- ただ実務にはあんまり使えてない模様。。
人に新しい仕事お願いするのは怖い
- 人に「これやって！」っていう時のマインドを書いた記事。
- リーダーとしては「人に仕事を任せていく」「最適配置をする」みたいな仕事が求められるが、そこが足りないな〜という意味の記事。
- 2024年末に読むと、個人的にちょっとはマシになっている気がする。（周りの人が優秀だったり、周りの人との関係性が築けてきたのもあるけど）
システムリプレイス難しくなるのなんで？
- 実務で「メンテコストが高くなったシステムをリアーキテクチャしましょう」的なことをやっていた時の学びまとめ。
- 結論、
- 開発スコープの設定がキモ
- リアーキ途中は旧側の改修は止めるよう調整したい
- それができない場合は新側で「リアーキ用スケジュール」「旧断面に追いつく用スケジュール」みたいなのを立てたい。そうしないとどこまでやったらいいのかメンバーが判断つかず困る
- スケジュール上、新旧両方リリースしないといけない部分のCICDとかも癖強くなる。（SRE的な観点で頑張りどころ）
- 旧側の仕様を漏らすと「デグレじゃん」と言われて悲しくなる
- 開発スコープの設定がキモ
良い単体テストってどういう状態か？
- 職場で流行ったので乗っかって読んでみた本。
- 「意味があるテスト」を書かないと意味なし。
- プロダクションコードを評価するのがテストだけど、そのテスト自体も評価対象。評価するのは人(エンジニア)。
任されるには「やる気ある姿勢」が必須
- あんまり言いたかないけど「任せる側も人間なのでこういう思考になりがちっすよね」に気づいたのでメモ。
- 自営業の社長でない限りは、人に何かを任せる/任される立場を兼任すると思うので、心に留めておきたいな〜とは思う
「またバリバリ働く」ためのサボりルーティン
- ちょっとモヤモヤした時にキッチリリフレッシュして次頑張るための記事。
- 僕はいつも喫茶店とか言って紙に色々書いて整理していますよ、という経験をシェアしています
- 夫婦間の揉め事解決でも使っていたりします（これやらないと感情的になっちゃうので...）
OKRはリーダーを育成してくれる
- OKRって立てんのむずいな〜と思っていた時の記事。
- 「メンバーだけじゃなくてリーダーをも育成してくれる！？」とのことで書いた記事。
- 「個人OKRって必須じゃない」は割と同意。（社の評価で使っていたら別なのだけど）
時期逃した感あるけど、応用情報受けてきた
- 「実務6年目で応用情報受けるって遅くね？」と思う同志を励ますための記事。
SpringBootでJST固定
- SpringBoot弄っててハマった仕様について書いた記事。
- 時刻リクエストのTimeZoneを固定したい時、そのデータがリクエストボディに入ってるかリクエストパラメータに入ってるかで設定方法が違った、という話
dotfilesデビュー
- dotfiles書いてる人、カッケ〜〜〜〜と思っているのでデビューしましたよという記事。
- ただ、IDE周りをCLIでインストールしてるだけなので俺がカッケ〜〜〜と思っている人たちにはまだ程遠い
リファクタ判断基準
- メンバーに「これってリファクタしちゃっていいすかねぇ？？」と聞かれた時にGoサインを出した。その時の判断基準について。
- 結論
- 仕様変更頻度高そうだったらやめといた方がいい
- そこの振る舞いを検証するテストがないならやめといた方がいい、先にテスト書くかテスト計画込みでリファクタしろ
TechBlog書くやつ変人
- ネタ記事。
- 自虐。
GitHubAPI
- 複数ブランチで並行開発をしていて「このブランチに入ってる変更対応を全部チケットに起こせ」的な仕事をしたときの記事。
- CLI使えて便利だった
- ほぼほぼChatGPTが書いてくれたのも便利だった。。
SCRUM BOOT CAMP
- プロダクトオーナー兼開発者っていう微妙な立ち位置で仕事していた時の悩みを解決しようと本読んだ時の記事
- 結論
- ユーザ目線、事業目線をもっと取り入れないといけない
- ユーザ目線、事業目線をもっと取り入れないといけない
エンジニアの評価
- 結論、合意形成イベント。
- 意思決定者は個人ではなく、組織である
チーム体制考える時は育成観点も入れよ
- 組織体制の変更に伴って、チームを新しく組むことになった。
- 「こんな案どうですか？」って叩きを作って行ったらちゃんと叩かれたので、その際に学んだことを書いた。
- 結論、チームの目的を整理して、育成を考えないといけないならそういう組み方をしないとダメよ、という話
キックオフでやること
- 新チームを立ち上げる時のやったことのメモ
- どんなことを共有しておかないといけないのかを整理
ドメイン駆動設計を一部だけでやると嬉しくない
- DDDを「プロダクト全体で」やらない場合、バッチ処理と逐次処理の間で仕様が変わっちゃったりしてダルい、という経験談。
アーキテクチャカンファレンス PDCA 2024
- 増田さんの発表が刺さったのでメモ。
- PDCA（現状の観察、経験知からの判断→現状変える、それのFB）の連続が大事
- 良い設計は「ビジネスで何を大事にしたいのか」から落とし込んでこそ実現できる
Gradle 備忘
- リポジトリ全体に関わるライブラリ整理の仕事をした時に不安になったので備忘。
- （ほぼ公式に書いてあること）
