kwn’s blog

2024年の振り返り

振り返り


エンジニア編

仕事

昨年から変わらずVite, React, TypeScriptあたりを使ってフロントエンドの開発をしています。新しく仕事で触れた技術はPlaywright, Lefthookぐらいです。来年は変化がある予定なので楽しみです。

GitHub

仕事では使ってないアカウントの記録です。今年の合計コントリビューション数は170でした。

ブログ

この記事含めて20記事投稿しました。

kwn1125.hatenablog.com

Qiita

今年デビューして2記事投稿しました。

Zenn

Article

記事は投稿しませんでした。

Scrap

4つ作成しました。

connpass

70のイベントに参加しました。全てオンラインです。貼るの大変なので参加したイベントのリンクは省略します。

読書

17冊読みました。ブクログにタグをつけて整理してあります。目標を50冊としていましたが、全くダメでした。

LAPRASスコア

LAPRASのスクショです。1年前からそこそこスコアを上げることができているので良かったです。

2023/12/24

2024/12/24

その他

11月に"Write Code Every Day"に挑戦しました。

kwn1125.hatenablog.com

kwn1125.hatenablog.com

プライベート編

アニメ

Annictにまとめています。見返したアニメや1年以上続いてるアニメはカウントが難しいので対象外として、視聴作品数は以下の通りです。

  • 2023年: 79作品
  • 2024年: 72作品

サッカー

視聴試合数は以下の通りです。全て家で配信を見ました。

  • 2023年: 272試合
  • 2024年: 311試合

ゲーム

プレイしたゲームは以下の通りです。ユニコーンオーバーロードはめちゃくちゃ面白くて時間が溶けました。今プレイ時間200時間ぐらいですがまだやることが残っています。Nintendo Switch Online + 追加パックは結局更新しました。プレイしたいゲームが溜まり続けています。

生活

良くも悪くも去年から変化がほどんどない1年でした。花粉の時期と真夏を除いてランニングが一応続いているのは自分を褒めたいですが、1年間の平均だと週1回以下なのでもう少し走りたいところです。

振り返り感想

今年は去年からの継続がメインだった1年でした。

エンジニアとしてアウトプットや読書数を増やしつつ、趣味にもしっかり時間を使えたのは良かったです。一番インパクトがあったのはユニコーンオーバーロードですね。去年も書きましたけどもっとゲームに時間使えるように工夫したいです。

継続ばかりではなく、来年の振り返りでは何か違うことを書けるように意識して過ごしたいと思います。

『世界一流エンジニアの思考法』を読んで

書籍紹介 読了


はじめに

『世界一流エンジニアの思考法』という本を読んだのでアウトプットします。以降記事内では『本書』と省略します。

どんな本か

内容や目次は↓に記載されています。

www.kinokuniya.co.jp


なぜ読むのか

  • 評判が良く、タイトルや著者に惹かれたから
  • より良いエンジニアになるためのヒントが得られるかもしれないと思ったから


感想

著者を含めたMicrosoftのエンジニアたちの仕事への取り組み方や考え方を学ぶことができる一冊でした。小難しいことは書かれておらず読みやすかったです。エンジニアでないとピンとこない話も多いですが、技術的なことがわからなくても読めるようになっていました。

ざっくり言うと「どうすれば生産性を上がるのか？」について、著者がMicrosoftのエンジニアから学んだことを中心に書かれています。コードリーディングのコツやプライベートを含めた生活習慣についてなど、内容は多岐にわたります。日本とアメリカを比較した話も多く書かれており、特に日本でのCocoaへの批判的な反応から見られる文化の話は印象的でした。


メモ

自分用にページ数のメモです

  • P.35 初歩の学習を「簡単だ」と馬鹿にせず本当に一からやり直す
  • P.43 デザインドキュメント
  • P.94 作業量を調整する
  • P.120 エビングハウスの忘却曲線
  • P.134 情報量を減らすコミュニケーション


2024年11月は"Write Code Every Day"月間とした（完走）

その他

kwn1125.hatenablog.com

以前の記事に書いた通り2024年11月は"Write Code Every Day"月間として、毎日コードを書くという挑戦をしました。結果、無事完走することができました。以下雑感を書いていきます。

凄い大変というわけではありませんでしたが、そこそこ大変でした。11月は比較的時間があり、有給休暇により休みも多かったので、別の月だったらもっと大変だったと思います。間に合うかヤバそうな日は1〜2日だけでした。また、1ヶ月と期間を決めていたので、来月以降にまわせることは来月にまわしてコードを書くことを優先するような考慮もできたのも大きかったです。

本来の"Write Code Every Day"は1ヶ月だけやるものではなく、可能な限りやり続けるものだと思いますので、だいぶハードルが下がった挑戦だったと思います。長期間続けている人たちの凄さがわかりました。しかし、1ヶ月だけとはいえ普段プライベートでコードを全然書かない自分にしては頑張ったなと思いますし、完走したことで少しだけ自信がつきました。学べたことも多く、有意義な1ヶ月を過ごすことができました。

今月は他にやりたいことが多く、結局またコードを書かない日々になってしまっています。来年はもう少し期間を伸ばしたり、ルールを少し弄ったりして、また似たような挑戦をしていきたいと思います。

『エンジニアリングマネージャーのしごと ―チームが必要とするマネージャーになる方法』を読んで

書籍紹介 読了


はじめに

『エンジニアリングマネージャーのしごと ―チームが必要とするマネージャーになる方法』という本を読んだのでアウトプットします。以降記事内では『本書』と省略します。

どんな本か

内容や目次は↓に記載されています。

www.oreilly.co.jp


なぜ読むのか

  • エンジニアリングマネージャーに興味があるから


感想

エンジニアリングマネージャーはどういう考え方で何をする仕事なのか一通り知る事ができる一冊で、裏表紙にも書かれているとおり"エンジニアリングチームのマネージャーに必携の一冊"だと思いました。

「はじめに」に書かれている「考えてみてください。他の人たちが成功し、学習し、心理的に安全だと感じられ、クリエイティブでいられる状況をあなたが作れるとしたら？…（中略）…そう。どれも本当に実現できます。本書ではそのやり方を伝えます。」の一節が好きで引き込まれました。マネージャーとしてのモチベーションや目指す理由はこれだと改めて思わせてくれましたし、本を読み進めたくなる素敵な一節だと思いました。


メモ

P.42 - 自分のエネルギーをマネジメントする

何か嫌なことがあったとしても、次の行動に引きずられてはいけないという話です。これは若い頃にやってしまっていたので、当時のメンバーには申し訳なく思っています…本当に気をつけていきたいです。

P.43 - 2回測って、1回切る

コミュニケーションしたいときにコミュニケーションしてはいけません。コミュニケーションが必要なときにコミュニケーションするのです。

これも若い頃にやってしまっていました。というか今も意識しないと、伝えたい気持ちのままに動いてしまおうとすることがあるので気をつけています。誰しもあることなのか、自分がそういう特徴があるだけなのかわかりません。キッカケは忘れましたが段々これはダメだと思いはじめて気をつけるようになりました。

P.235 - コントロールの三文法

「コントロールの三文法」で検索してもヒットしないのですが、まず前提としてストア派哲学の考え方「自分でコントロールできるものもあれば、自分でコントロールできないものもある」があります。自分でコントロールできるものに集中し、自分でコントロールできないものには執着せず受け入れるという考え方です。

mensappmedia.com

これを発展させたのが「コントロールの三文法」で、自分でコントロールできないものを2つに分けて合計3つに分ける考え方です。

  1. 自分でコントロールできるもの
  2. 自分でコントロールできないもの > 全くコントロールできないもの
  3. 自分でコントロールできないもの > ある程度コントロールできるもの

マネージャーにとって重要なのは「ある程度コントロールできるもの」です。なぜならマネージャーの仕事の一つは「委譲」だからです。メンバーに何かを委譲した場合、それは「自分でコントロールできないもの」に分類されますが、だからと言って何もしないのはマネージャーとして適切ではありません。例えばメンバーへの支援や関係者との交渉によって、成果に影響を与えられる可能性があります。コントロールの三文法で言えば「ある程度コントロールできるもの」ということです。

本書では「ある程度コントロールできるもの」に「外部ゴール」と「内部ゴール」を設定することを推奨しています。

  • 外部ゴール：理想とする結果や目標
  • 内部ゴール：現在の環境や状況で自分ができることやそれに基づく目標

「ある程度コントロールできるもの」については「内部ゴール」を設定して自分が影響を与えられる領域に集中し、その結果としてうまくいかなかった場合は受け入れる事が大事なのだと思います。以下は本書に書かれている「外部ゴール」と「内部ゴール」の例を簡単にまとめたものです。

例1：スタッフの1人が転職を考えている

  • 外部ゴール：転職を思いとどまらせる
  • 内部ゴール：カウンターオファーの提示や環境改善

例2：プロジェクトが遅れそう

  • 外部ゴール：期限に間に合わせる
  • 内部ゴール：スコープ、リソース、納期の調整

この考え方にはとても共感できました。自分は「自分でコントロールできないもの」について業務時間外も含めて考えすぎてしまうことが多いのですが、今後は内部ゴールを意識することで、結果を受け入れてストレスを溜めないように意識したいと思いました。

P.260 - チームでのライトニングトーク

単純にチーム内でLTをする取り組みは良さそうだと思ったのはありますが、「高橋メソッド」を初めて知りました。ググったら関連して「もんたメソッド」があることも知りました。

note.com


2024年11月は"Write Code Every Day"月間とする（宣言）

その他

"Write Code Every Day"とは jQuery の開発者である John Resig 氏が自身のブログに投稿した記事のタイトルであり、タイトル通り"毎日コードを書く"という取り組みのことです。

johnresig.com

自分は @t_wada さんのリクルート研修講義資料で知りました。

speakerdeck.com

この資料は2024年バージョンですがもっと前からあって、初めて見たのは数年前だと思います。この資料のことを最近思い出して見直したのですが、初めて見た時に「実力不足なんだからもっとコード書かないと！」と思ったのに結局全然コード書いてないじゃん！となりました。ということで、とりあえず1ヶ月挑戦してみます。


ルール

  • 1日最低1コミットする
  • GitHubで管理しているPublicなリポジトリにコミットする
  • 以下の変更のみのコミットはカウントしない
    • 改行やインデントの調整などのフォーマット系
    • READMEやCONTRIBUTINGなどのドキュメント系


結果はこのブログに記事として投稿予定です。さてどうなるか…