
『[Tidy First?](https://www.oreilly.co.jp/books/9784814400911/)』を読みました。残念ながら、僕にはあまり響きませんでした。

著者は Kent Beck です。僕は彼のファンです。彼が執筆した『[エクストリームプログラミング](https://www.ohmsha.co.jp/book/9784274217623/)』や『[テスト駆動開発](https://www.ohmsha.co.jp/book/9784274217883/)』は何度も読み返しました。Kent Beck の新作なので期待値も高かったのですが、あまり楽しく読めず、残念です。

この本は物理的に薄い本で、章が細かく分割されています。なので、各章が数ページで終わります。さらに、章がほぼ独立しているので、気になる章だけ読むこともできます。

これはメリットでもありますが、僕にとっての「響かなさ」の要因のひとつでもあります。たとえば『テスト駆動開発』は「通貨の実装」を100ページ以上かけて行います。一歩一歩コードを書き進めていく様はライブ感たっぷりでした。しかも実際のプログラミング言語 (= Java) で書いているので、Kent Beck の思考プロセスを追体験できます。これは良かった。

一方『Tidy First?』は短い章が連なっているので、「あれ? 今の話これで終わり?」と思うことが多かったです。サンプルコードも疑似言語で「これは実際にはどういうコードを想定してるんだ?」というのを読み解きづらくもありました。

知識を得る本というより、問いかけを得られる本という趣です。良く捉えれば「考えさせられる本」と言えます。その意味では、多人数でわいわい読書会をするネタとしては、良い本なのかもしれないです。


『Tidy First?』


『[小さな習慣](https://www.diamond.co.jp/book/9784478065778.html)』を読みました。良い本でした。

かねてより人間は「習慣」と「環境」で形成されていると感じています。環境は選べる範囲で選んできました。進学先しかり、就業先しかり。しかし、習慣はコントロールしづらいものです。良い習慣を身につけたいと一念発起してもモチベーションが続かず、いつもの生活に逆戻りする。これが、お決まりのパターンでした。

習慣をコントロールしたいという気持ちから、本書を手に取りました。読後の高揚感もありますが、ある程度はコントロールできるかも、と思えるようになりました。

まず、本書は目標設定の指針が独特です。「ばかばかしいくらい小さい目標」が良いとしています。具体例として「腕立て伏せ1回」という目標があります。これは、数秒で達成できる簡単な目標です。なお「腕立て伏せ1回」が目標ですが、別に1回以上やっても構いません。

この「目標を超えてもペナルティがない」というのが重要です。目標に向かって進むとき、最初の一歩が最も大変です。「ジムで1時間汗を流す」という目標だと、なかなか最初の一歩に踏み出せません。ところが「腕立て伏せ1回」であれば、最初の一歩が重くありません。というか、最初の一歩でゴールです。

この考え方は応用が効きます。例えば200ページの本を執筆したいとします。一日あたり半ページ書くという目標はどうでしょう。興が乗って10ページ書く日もあるかもしれません。でも、それを目標にしてはいけません。ペンを持ち、半ページ書く。それが続けば、習慣になります。「毎日10ページ書く」というのが目標だと、最初の一歩が重いかもしれません。半ページなら、そうでもないはずです。

なお、この本は「モチベーションに頼ってはいけない」と言っています。同意します。モチベーションは管理が難しいものです。「ばかばかしいくらい小さい目標」は、モチベーションなしでも達成できる目標です。そうすることで、モチベーションに依らず目標をクリアし続けられ、良い習慣を作れるということです。


『小さな習慣』


『[TAKE NOTES!――メモで、あなただけのアウトプットが自然にできるようになる](https://www.amazon.co.jp/dp/4296000411)』を読みました。

メモを [Obsidian](http://obsidian.md) に集約するようになって、数年が経ちました。未だに Obsidian を使いこなせていないように思います。しかし、Obsidian の機能がわからないというより、Obsidian を使ったメモ書きのベストなワークフローがわからない、という感覚です。少し前に流行った本書に Obsidian に対する言及があると聞き、手にとってみました。

この本は、ニクラス・ルーマンという社会学者が採用したツェッテルカステンというメモ術を紹介しています。身も蓋もないことを言うと、ツェッテルカステンの細かい実践方法は理解できないまま読了しました。ルーマンは 20 世紀に活躍した人物なので、彼は紙とペンによるメモを採用していました。これが僕の Obsidian のワークフローとメンタルモデルが乖離していて、ピンと来ませんでした。「紙のメモに一意の数字を振り、関連するメモ同士をリンクする」という旨の説明があった (と理解している) のですが、「どうやって?」の部分がクリアになりませんでした。僕の読解力が不足している可能性も大いにあります。

メモを書くときの心構えとして紹介されている内容は面白かったです。まず、メモは何かを書き写したものではいけない、ということです。たとえば読んでいる本の内容をメモするとき、本の内容を抜粋するのではなく、内容を自分の言葉に置き換えて書く、ということです。「自分の言葉に置き換える」ことは、内容を理解しなければできない。つまり、自分の言葉でメモを取ることこそが学習である、と著者は主張しています。

また、走り書きのメモと永久保存するメモは明確に区別せよ、と述べられています。走り書きのメモは、数日以内に永久保存用のメモに昇華するべきで、そうできないメモは残しても価値がありません。読み返されないから。

ここで自分の Obsidian の使い方に思いを馳せます。僕は Obsidian で、走り書きのメモばかり書いてきました。一日の最初に [Daily Notes](https://help.obsidian.md/Plugins/Daily+notes) を作り、その日にやりたいタスクを書き出します。それをマークダウンでチェックボックスにしておき、終業のタイミングですべてチェックされていることを目指す、という使い方です。タスクごとに一時的なメモが必要なことがあり、それも Daily Notes に含めていました。この使い方だと Daily Notes を見返すことは稀だし、知識が積み上がりません。これは「なんちゃって [Getting Things Done](https://ja.wikipedia.org/wiki/Getting_Things_Done)」で、仕事をこなす意味では良いけど、知識と理解を深めて大きな仕事に取り組むには不十分です。

本書を読んだ上で、とりあえず次のように Obsidian の使い方を変えようと思いました。

1. Daily Notes は引き続き使う
2. Daily Notes の中で積極的にページを作り、その中でもページをリンクさせる

たとえば Daily Notes で「Spring Security による認証機能を実装する」というタスクを作るとき、Spring Security を個別ページとし、そのページの中で、例えば OIDC や Kotlin などのキーワードをまた個別ページとし、リンクさせる...というイメージです。

このようにワークフローを変えて起こる変化がポジティブかどうか、しばらく後に振り返ろうと思います。


『TAKE NOTES!――メモで、あなただけのアウトプットが自然にできるようになる』


遅ればせながら、2024 年の振り返りを書きます。

これまでの分はこちらの通りです。

* [2023年のまとめ](https://mahata.vercel.app/posts/2023-12-22-retrospective)
* [2022年のまとめ](https://mahata.vercel.app/posts/2022-12-23-retrospective)
* [2021年のまとめ](https://mahata.gitlab.io/post/2021-12-25-retrospective/)

## 「去年までの振り返り」の振り返り

> Obsidian はかなり良い。MarkText は 2022 年の時点でも不満を感じながら使っていたけど Obsidian には不満がほぼないです。強いて言えば、僕自身が Obsidian の機能を使いこなしてないように感じるくらいです。機能そのものには大満足なので 2024 年も使い続けていると思います。

はい、これは変わらずです。[Obsidian](https://obsidian.md) は大好きなソフトウェアのひとつになりました。毎日メモを Obsidian で書いています。

> Mastodon から離れて [Bluesky](https://bsky.app/) へと移りました。 Bluesky の UI がほぼ Twitter で、自分はそこに心地よさを感じています。...略...。まだ「Bluesky 一択」と言えるところまでではないです。

もう「Bluesky 一択」と言っていいくらい、ソーシャルメディアの中では Bluesky ばかり見ています。もう少し気軽にポストできるようになりたいんだけど、「これはさすがにくだらなすぎるかな」と思って自重しちゃうのを何とかしたい。

> ダイエットは無事に成功しました。

これは食事の記録をつける習慣が一瞬なくなってしまい、そのときだけリバウンドしかけました。その後、習慣を取り戻し、トータルではキープできています。

> 最近は英語をずっと聞いていても疲れなくなったので、もっぱら [Syntax](https://syntax.fm/) を聞いています。

はい、聞き続けています。[Syntax は動画も配信するようになった](https://www.youtube.com/@syntaxfm)ので、これも観ています。音声だけのときとはまた違う印象を受けます。

> 情報収集といえば、携帯に [Artifact](https://artifact.news/) を入れて時折ニュースを読むようになりました。これは「僕が欲しかった SmartNews」という趣きです。

[2024 年中に Artifact がサービス終了してしまった](https://artifact.news)のは衝撃でした。やっぱりニュースビジネスは難しいんだなあ。

> 自分より若い世代がよく使っているツールは積極的に試そうと思っており、その意味で [Arc](https://arc.net/) を使うようになりました。

残念ながら Arc は手になじまなくて、やめてしまいました。今は Safari をメインのブラウザにしています。なるべく OS に付属しているソフトウェアだけで生活したいという気持ちが強まったので。

> はじめて献血を体験しました。...略...。今後も続けていこうと思います。

2024 年も何度か献血に行きました。来年も続けると思います。

> 仕事関連では Kotlin プログラミングに時間を投資したい気持ちがあります。

この気持ちは薄れてきています。どちらかと言えば、2024 年は TypeScript をたくさん書きました。GitHub Copilot が流行り、VSCode をクローンして生成 AI を組み込んだ IDE が 2024 年中はたくさんリリースされたわけですが、Kotlin は IntelliJ と運命共同体なので、今後が少し心配です。

## 読んだ技術文書

勤務先が買収されたことにともない、2024 年の途中から [O'Reilly Online Learning](https://www.oreilly.com/online-learning/) のサブスクリプションがなくなりました。よく O'Reilly の本や動画を視聴していたので、これは痛手です。

このような理由から、オンラインの技術文書を読むことが増えました。たとえば [React の公式ドキュメント](https://ja.react.dev)や [MDN](https://developer.mozilla.org/ja/) などです。最終的には「これはこれで悪くないな」と思うようになりました。しかし、電車内でこれらのドキュメントを読んでいると、電波の弱いところで記事が読めなくなったりするので、O'Reilly コンテンツを (あらかじめダウンロードして) 視聴する体験には勝てないな、とも思いました。

オンラインの資料とは別に、オフラインでは図書館で本を借りて読むことが増えました。2024 年は次のような本に目を通しました。

* [スタッフエンジニアの道 - 優れた技術専門職になるためのガイド](https://www.oreilly.co.jp/books/9784814400867/)
* [手を動かしてわかるクリーンアーキテクチャ - ヘキサゴナルアーキテクチャによるクリーンなアプリケーション開発](https://book.impress.co.jp/books/1123101096)
* [関数型ドメインモデリング - ドメイン駆動設計とF#でソフトウェアの複雑さに立ち向かおう](https://tatsu-zine.com/books/domain-modeling-made-functional)
* [ドメイン駆動設計をはじめよう - ソフトウェアの実装と事業戦略を結びつける実践技法](https://www.oreilly.co.jp/books/9784814400737/)
* [なぜ依存を注入するのか DIの原理・原則とパターン](https://book.mynavi.jp/ec/products/detail/id=143373)

「目を通した」という表現には複雑な気持ちを込めています。実はこれらの本は読み切れていません。図書館で借りて読むというスタイルであるため、年内に出版された本は取り合いになることが多く、読了に 2 週間以上かかるものは一度返す必要があります。そのため、一気通貫で読みづらい、という感じです。

また「図書館で借りて読む」というスタイルが主流になったため、[ブクログ](https://booklog.jp)で読書の進捗状況を管理するようになりました。時間を置いてから本を読み返すことが多くなるので、ブクログの記録が役立っています。

## 読んだ漫画本

* [葬送のフリーレン](https://websunday.net/work/708/)
* [COSMOS](https://www.sunday-webry.com/episode/4856001361087694972)
* [僕の心のヤバイやつ](https://championcross.jp/series/899dda204c3f2/)

いずれも有名な漫画ですね。

### 葬送のフリーレン

これは二周しています。最初は実は「そこまで面白くないな」と思ったのですが、あまりにも評判が良いので、再度読み直したら「めちゃめちゃ面白いじゃん」となりました。物語の展開が、しっかり前半の記述を踏まえた内容になっているので、逆に展開を理解してから前半を読み直すことで「これがつながってたのか...」という感動がありました。特にセリフまわり。

あとは「[サンデーうぇぶり](https://www.sunday-webry.com)」で読む体験が良くて、各話についたコメントを読むことで自分が理解できていなかった描写に気づき、それもまた感動、という感じでした。

### COSMOS

これも「サンデーうぇぶり」で連載を読んでいます。フリーレンと似たような感想ですが、これも周回で読んで「おぉー、これがこう繋がってたのか」と思うことが多々ありました。主人公が「嘘を見抜ける」というスキル持ちで、それそのものは「よくある設定」なのですが、画力と構成力の高さからチープな設定がよく活かされていて読み応えがあります。なんか偉そうなことを書いてしまいましたが、シンプルに言うと「面白い」です。今後も楽しみ。

### 僕の心のヤバイやつ

ラブコメです。最初は「下ネタがきついな」と思ってギブアップしそうになりました。途中から下ネタが減ってきて、すっと感情移入しながら読めるようになりました。まさに「感情移入」がこの漫画の肝だと思っていて、いわゆる陰キャの主人公が悶々と考え込んでいる様をみながら「あぁー、ちょ、おまえー」みたいな感じで読みました。

冷静に考えると 40 を超えたおじさんが中学生の恋愛模様を感情移入しながら読むというのはちょっと...というところではあるのですが、なにせ面白いんで...。

## その他

### Spring Certified Professional

[Spring Certified Professional](https://www.credly.com/badges/9af6e708-c552-48af-87aa-e4cc4cec30f3/public_url) を取得しました。「難しいな」という手応えだったので、無事に合格できてホッとしました。勉強していて Spring について理解が深まったのはもちろんのこと、Spring の細かい部分はまだまだ理解できていないということにも気づけました。時間を割いて勉強した甲斐があります。

### 仕事

2024 年の前半は、各国オフィスのチームメンバーと一緒に仕事ができました。楽しかった。具体的にはシンガポール、インド、韓国、日本という感じでした。クライアントにも恵まれ、自分自身が日頃からよく使うアプリケーションの新バージョンを開発する、というものでした。やりがいがありました。

後半は... (後日追記予定)

コードは概ね Kotlin / Java でバックエンド (Spring Boot) を書き、TypeScript (react) でフロントエンドを書きました。CSS は SASS だったり Tailwind CSS だったり。インフラは AWS を Terraform でいじったり CDK でいじったり。

### はじめての Note

[Note の記事をいくつか書きました](https://note.com/ymahata)。[ktlog](https://github.com/mahata/ktlog/) というブログエンジンを作っていたものの、なかなか公開までたどり着けず、公開できないうちに書きたいことが増えたため Note に手を出しました。良いウェブサービスだと思います。ktlog に対する気持ちが下がってきているので、もしかしたら 2025 年も記事を公開するかも。

### 海外株 (個別銘柄) への投資

資産形成として「インデックス連動型の投資信託を毎月積み立てる」というのをしています。よくあるやつです。

ところで、僕は「2005 年前後に Google の株を買わなかった」というのを後悔しています。当時、僕は Google は「すごい会社だ」と思っていて、「伸びるに決まっている」と思っていました。でも、その頃に読んだ本に「素人がファンドマネージャーに勝つことは難しい。生半可な知識で株を選んでもカモになるだけ」とあり、そういうものなのか、と諦めました。

ここで 20 年前を振り返ると、「ひょっとして、金融機関のファンドマネージャーより自分の方が、Google の将来性を "わかっていた" のではないか」という気持ちになります。ファンドマネージャーは広い視野が必要だけど、こと「技術」に特化すれば、自分の方が見る目があるのではないか。ファンドマネージャーは短期的に成果を出す必要があるけど、僕は長期的な視点に立てるのではないか。そのような気持ちが芽生えました。

そういう気持ちから、僕は個別株として「Cloudflare」と「Microsoft」を選定し、購入しました。

結果。大した利得を得ずに、これらを売却してしまいました。損こそしていないものの。

個別銘柄を買うことのダウンサイドは、それらの銘柄の株価に一喜一憂せずにはいられない、ということです。当たり前のことですが、買ってみるまで気づけませんでした。毎日、これらの銘柄のニュースを追い、株価をチェックしていたのですが、自分のアテンションが「しょうもないこと」に奪われている気持ちになりました。また、これらの銘柄には「期待が持てる」と思っていたものの、円ドルレートの乱高下は自分には想像しづらく、トータルで利得を考えることは想像よりも難しかったです。

そうして、個別銘柄を選定するという試みは 2024 年にはじめ、その年の内に終えてしまいました。実はまだ売り切れていない部分があるものの、買い増すことはないと思います。

## 2025 年の展望

2025 年は TypeScript に投資したいです。

2023-2024 年は「Kotlin に投資していたい」と言っていたのですが、仕事で Spring Boot を使う機会が少なくなりそうで、そうであれば積極的に Kotlin を選ぶケースは減ると思っています。そしてフロントエンド開発で TypeScript を触るので、それならバックエンドも特別な理由がなければ TypeScript でおおむね賄えるのではないかと思います。そして TypeScript でフロントとバックが地続きなウェブサービスを作るとしても、まともに CSS が書けなければ「フルスタック」にはなりません。僕は CSS およびウェブデザイン一般を「なんちゃって」でやってきているので、腰を据えて勉強したいと思っています。

もうひとつは、コミュニティ活動です。コミュニティ活動、実に曖昧な言葉ですね。とりあえず、平日開催のミートアップやカンファレンスに足を運ぶようにしようと思います。うっすらわかっていたのですが、[Kent C. Dodds 氏による「AI があなたの仕事を奪う」という記事](https://zenn.dev/mahata/articles/ai-is-taking-your-job)を読み、「コミュニティと疎遠では将来がない」という気持ちになりました。そして「書くこと」を習慣にしたいです。コニュニティ活動において、まず自分が何者なのか知ってもらわなければ、コミュニティで役に立つことは難しいと思っています。継続的にブログなりなんなりにテキストを残す習慣を作り、自分のやっていること、知っていることを公開していきたいと思っています。


2024 年の振り返り


『[疲労とはなにか すべてはウイルスが知っていた](https://bookclub.kodansha.co.jp/product?item=0000385169)』を読みました。

「疲れ知らずになりたい」という邪な気持ちで手に取ったわけですが、得られた結論は「疲れは必要であり、疲れ知らずになることはできない」ということでした。

本書は「疲労」と「疲労感」を分けて捉えるところからはじまります。「疲労感」を軽減する方法はいくつかあり、たとえばエナジードリンクに含まれる抗酸化成分によって疲労感は抑えられる、ということでした。しかし、これは単なる疲労感の抑制であり、内蔵や体の筋繊維は通常通り疲労を蓄積するそうです。したがって、エナジードリンクの過剰摂取によって真の疲労に気づかず、体組織の障害や突然死にいたる可能性もあるとのこと。

また、疲労そのものはビタミンB1が欠乏すると解消しない、とありました。「eIF2α」という酵素にリンがくっつくことが疲労であり、それを剥がす働きをする酵素を出すには軽い運動が必要、ということが書かれていました。重い疲労を回復するため、軽い疲労が必要というのは興味深い話でした。

しかし、残念ながら「疲れ知らず」になるために役立つ知識としてはここまででした。

後半では「病的疲労」としてうつ病やコロナウイルス後遺症の話がありました。僕の興味の範疇ではなかったのですが、いずれも原因についてクリアに説明されており「そこまでわかっているものなのか」と思いました。

余談ですが、会社の人事は「ストレス耐性の高い人 (= うつ病になりにくい)」を選り好みすべきでない、という話がありました。ストレス耐性の高い人は「対人関係に極めて鈍感で戦力にならない」とのこと。

> そんなことをしたら、真面目で、仕事熱心で、献身的で、責任感が強い、おおいに会社のためになってくれる人が入ってこなくなるからです。

だそうです。

ところで、本書は「講談社ブルーバックス」のシリーズだけあり、内容に手抜きがなく、記述の随所に科学的な裏付けがありました。これは読み応えがあると同時に、自分の知識不足を痛感させられることでもありました。正直に言えば、書籍で語られている内容の一部は「よくわからないな...」と思いながら目を通しました。一方で、小難しい話によって「煙に巻かれている」という感覚もなく、著者の専門領域の語彙で、この内容を正確に表現しようとすると、このようなテキストになるのだな、という感想です。いつか化学および生物学の知識を仕入れ直して再挑戦したい本の一冊となりました。

それにしても、かつて『[デザインされたギャンブル依存症](https://mahata.gitlab.io/post/2021-10-16-addiction-by-design/)』を読んだときは「効率よくゾーンに入りたい」という気持ちで本を手に取ったものでした。今回も「疲れ知らずになりたい」という気持ちであったわけですが、いつも「楽な道などない」と思わされる結果に終わります。中々うまくいかないものです。


『疲労とはなにか すべてはウイルスが知っていた』


途中まで読んだ『[Software Engineer at Google](https://learning.oreilly.com/library/view/software-engineering-at/9781492082781/)』をギブアップしました。この本は去年の内に半分くらいまで読み、その後で放ったらかしにしていたものです。何章か感想を書いたりもしました。

* [Software Engineering at Google: Chapter 1 - What Is Software Engineering](https://mahata.vercel.app/posts/2023-02-06-software-engineering-at-google-chapter1-what-is-software-engineering)
* [Software Engineering at Google: Chapter 2 - How To Work Well On Teams](https://mahata.vercel.app/posts/2023-02-10-software-engineering-at-google-chapter2-how-to-work-well-on-teams)
* [Software Engineering at Google: Chapter 3 - Knowledge Sharing](https://mahata.vercel.app/posts/2023-02-14-software-engineering-at-google-chapter3-knowledge-sharing)

第三章を読んだ後、気になる章をピックアップして読むスタイルに変えて、最終的に興味を失った、という感じです。

## "at Google"

もともとは『Software Engineering at Google』というタイトルの "at Google" という言葉が発する魅力に惹かれて読み始めました。Google といえばエンジニアリングの会社であり、そこで培われている技術には特別なものがあるのでは、と思っていました。

ところが、最近は Google に対するリスペクトを強く持てなくなりました。特に 2023 年の Google は、外部の者としては「ダサい」とすら感じました。Google 社員の 6% に相当する 12,000 人がレイオフされ、一方で [CEO の Sundar Pichai 氏は $226M の報酬を受け取ったと報じられて](https://www.cnbc.com/2023/05/03/google-employees-complain-about-ceo-sundar-pichais-pay-raise.html)います。これは [Apple の Tim Cook 氏が自身の役員報酬を減らし](https://www.cnbc.com/2023/01/12/apple-ceo-tim-cook-receives-a-40percent-pay-cut-after-shareholder-vote.html)つつ、レイオフを行わなかったこととの対比で、さらにダサさが際立ちました。

Google 製のプロダクトも、近年は魅力に欠けます。ChatGPT の後追いで登場した Bard からは ChatGPT ほどの賢さを感じられません。Google 検索にはノイズが増え続けています。Google Home は簡単な会話すらままなりません。Gmail へのスパムも増え続けています。[AWS の後を追っていたはずの GCP は Azure ほど伸びていません](https://www.publickey1.jp/blog/24/publickeyit2024azureaws_it.html)。

"at Google" が魅力的でないのに、なぜ『Software Engineering at Google』を読み続けるのか...。そういう気持ちになり、読み進める気持ちをなくしてしまいました。

ところで昨年末には [Spotify が 17% の従業員をレイオフするというニュース](https://www.cnbc.com/2023/12/04/spotify-to-lay-off-17percent-of-employees-ceo-daniel-ek-says.html)も飛び込んできました。こうなると、[過去に読んだ『ユニコーン企業の秘密』](https://mahata.gitlab.io/post/2021-06-18-unicorn-kigyo-no-himitsu/)のありがたみも目減りします。

企業ブランドは水物であり、コンテンツがそれに依存するようでは歴史の重みに耐えかねるな、と感じました。


ギブアップ: Software Engineering at Google 


2024 年は年初から悲しいニュースを多く目にしました。元日には[令和6年能登半島地震](https://ja.wikipedia.org/wiki/%E4%BB%A4%E5%92%8C6%E5%B9%B4%E8%83%BD%E7%99%BB%E5%8D%8A%E5%B3%B6%E5%9C%B0%E9%9C%87)が発生し、倒壊した建物や、燃え上がる家屋の様子などが東京都内の全てのテレビチャンネルで流れました。

その翌日には羽田空港で炎上する飛行機の様子が流れました。報道によれば、前述の[能登半島地震の救援に向かう海上保安庁の航空機と日本航空の旅客機が衝突した](https://ja.wikipedia.org/wiki/%E6%97%A5%E6%9C%AC%E8%88%AA%E7%A9%BA516%E4%BE%BF%E8%A1%9D%E7%AA%81%E7%82%8E%E4%B8%8A%E4%BA%8B%E6%95%85)とのことです。この事故で海上保安庁の職員 5 名が亡くなられたそうです。

地震に関しては、この記事を書いている時点でも「落ち着いている」状態とは言い難いです。被災地の一日も早い復興を願っています (少額ながら「[能登半島地震災害義援金](https://www.jrc.or.jp/contribute/help/20240104/)」への寄付を行いました)。

僕は東北の出身で、実家が宮城県仙台市にあります。[東北大震災](https://ja.wikipedia.org/wiki/%E6%9D%B1%E6%97%A5%E6%9C%AC%E5%A4%A7%E9%9C%87%E7%81%BD)の折には東京にいたので直接的な被害は被っていないものの、事態が落ち着いた後で仙台市に戻ったときには災害の爪痕の大きさを感じずにはいられませんでした。

自分は「運良く生きているだけ」だと感じます。災害に好んで巻き込まれたい人はいないでしょう。これまで運良く、自分は幸せに生きてこられらたと思っています。これを「当然のこと」と思い上がることなく、一日一日を大事に生きなければならないと思う年始でした。


運良く生きている


今年のまとめを書きます。

なお去年までの分はこちらの通りです。

* [2022年のまとめ](https://mahata.vercel.app/posts/2022-12-23-retrospective)
* [2021年のまとめ](https://mahata.gitlab.io/post/2021-12-25-retrospective/)

## 去年のまとめを振り返る

> 今年の中旬まで、技術メモは Dropbox Paper に書いていたけど MarkText にスイッチした。このブログ記事も、下書きは MarkText に書いている。

[MarkText](https://www.marktext.cc/) は使わず、代わりに [Obsidian](https://obsidian.md/) を使うようになりました。Obsidian はかなり良い。MarkText は 2022 年の時点でも不満を感じながら使っていたけど Obsidian には不満がほぼないです。強いて言えば、僕自身が Obsidian の機能を使いこなしてないように感じるくらいです。機能そのものには大満足なので 2024 年も使い続けていると思います。

> 僕は (中略) Twitter からは距離を置きたいと思うようになった。
> 
> 何が代替として優れているのかよくわからないながら、代替手段としておそらく最も選ばれているであろう Mastodon に僕も移行した。Mastodon にも思うところはあるけど、今のところは便利に使えている。

さらに Mastodon から離れて [Bluesky](https://bsky.app/) へと移りました。 Bluesky の UI がほぼ Twitter で、自分はそこに心地よさを感じています。それだけに「過去の Twitter は素晴らしいものだったな」とも思うようになり、Bluesky への不満もあります。たとえば検索機能が貧弱であったり DM が送れなかったり。多くの友人が Bluesky に来ておらず、Mastodon や Threads、Misskey や LinkedIn などに分散していることもあり、まだ「Bluesky 一択」と言えるところまでではないです。

> 今年はついに、定期健康診断時に「少し体重を落とした方が良いです」と医師に言われてしまった。その言葉を受けて、ダイエットをはじめた。

ダイエットは無事に成功しました。だいたい 5~6 kg の減量です。「[あすけん](https://www.asken.jp/)」と、後述する Anker の体組成計で達成できました。よかったよかった。

> 実は懸垂を 1 回もできないのだが、近所の公園でぶら下がることからはじめている。2023 年には 2-3 回くらい自分自身を持ち上げられるようになりたい。

自重を 1 回だけ持ち上げられるようになった...のが初夏の頃です。僕は帰宅時に公園の懸垂台を使うことが多いのですが、夏になると人が遅くまでたむろするようになり、あまり懸垂をすることがなくなりました。僕の成長はここまで...。ただ、人目を気にせず懸垂の練習をできるメンタルも欲しいので 2024 年こそはやるぞ、という気持ちです。

> 英語をずっと聴いていると疲れるので、日本語で頭を使わずに消費できるコンテンツがほしく、たまたま発見したドングリfmというポッドキャストもたまに聴いている。主にホストが雑談しているだけの番組だけど、ちょっと「ふふっ」となることが多く、癒やされている。

最近は英語をずっと聞いていても疲れなくなったので、もっぱら [Syntax](https://syntax.fm/) を聞いています。ほどよく技術的なトピックがカバーされていて楽しいです。ホストの二人の人柄にも好感を持っています。

> オンライン大学院にも少し興味がある。ただ、かなり時間を取られそうなので、手が出ない可能性もある。本当に手が出ないかどうか確かめるため MOOC でいくつか大学院レベルの講義を受講するくらいが現実的なラインかもしれない。

これは興味が薄れました。アカデミックなことよりも、もっと実践的なことを学ぶ方が今の自分には有意義だと感じています。たとえば僕は Spring Boot や React についての理解を深める方が仕事に役立つだろうと思います。

とはいえ、大学院でのコースワークは「仕事に役立てたい」という気持ちよりは「知的好奇心を満たしたい」というところから来ていたので、仕事にもっと余裕が出てきたら改めて検討するかもしれないです。しかし 2024 年中には手をつけられないだろうとも思っています。

> あとは CKA が2023年10月に期限切れしてしまうので、その前に CKS に更新しておきたい。

無事に [CKS (Certified Kubernetes Security Specialist) を取得しました](https://zenn.dev/mahata/articles/93225ad5a4d3d7) 😉

## 読んだ本

### 技術書

2023 年は技術書はあまり読めませんでした。まともに読めたのは『[Reactハンズオンラーニング 第2版](https://www.oreilly.co.jp//books/9784873119380/)』と『[プログラミングTypeScript](https://www.oreilly.co.jp//books/9784873119045/)』、『[ベタープログラマ](https://mahata.vercel.app/posts/2023-04-20-better-programmer)』くらい。特に『Reactハンズオンラーニング 第2版』と『プログラミングTypeScript』は仕事に役立てられたので良かったです。

今読んでいる本は『[Kotlin Design Patterns and Best Practices - Second Edition](https://learning.oreilly.com/library/view/kotlin-design-patterns/9781801815727/)』です。これは Kotlin を書く人には強くオススメできる本で、僕自身も複数回読むと思います。

### 漫画本

2023 年に読んだ漫画本で印象に残っているタイトルを挙げます。

* ONE PIECE
* スキップとローファー
* ザ・ファブル The second contact
* スピリットサークル
* 結界師

『ONE PIECE』は誰もが知っているタイトルだと思うのですが、僕は過去に何度か「読みかけ」て離脱していました。改めて読むと「これは人気が出るわ...」と思うストーリーラインで楽しめています。まだ途中なので今後も読みそう。

『スキップとローファー』はこのブログを書いている時点では未完ですが、読むと穏やかな気持になるところがいいです。純然たる「嫌なやつ」が登場せず、読後感がとても良いです。

『ザ・ファブル The second contact』はファーストシーズンと同様に安定して面白いです。

『スピリットサークル』は同僚に勧めてもらって、一気に読みました。一気に読めるくらいに引き込まれます。

『結界師』は古い作品で、これも過去に読みかけて離脱したタイトルなのですが、改めて読んで面白さに気づきました。作中で「親子関係」に関する描写があり、自分自身が親になった今は、かつてとは違う面白さを感じるようになりました。

## 買い物

2023 年に購入したものの中から、気に入っているものを紹介します。

* [エチケットカッター ER-GN70](https://panasonic.jp/mens/p-db/ER-GN70.html)

電動カッターに対する謎の不信感があったのですが、こちらを使うようになってハサミには戻れなくなりました。短時間で綺麗に仕上がるので、もっと早くから使えば良かったと思います。

* [ぶんぶんチョッパー](https://k-and-a.jp/bbc/bbctop.html)

かなり地味な商品ですが、野菜のみじん切りをするときの時短に役立っています。特に玉ねぎをみじん切りしようとすると目が痛みますが、これを使うと玉ねぎの催涙成分をカットできるので、涙を流すことなく調理できて便利です。よく使っています。

* [Anker Eufy Smart Scale P2 Pro](https://www.ankerjapan.com/products/t9149)

体組成計です。最初はダイエット目的で購入しました。使い勝手の良さから今も使い続けています。記録が iPhone アプリに自動で転送されること、家族全員のデータを集約できること (アプリが自動で誰の情報か振り分けてくれる) などが気に入っています。

## ソフトウェア / ウェブサービス

X (Twitter) から離れたので、情報の収集には [Feedly](https://feedly.com/) を使うようになりました。もともと 2000 年代後半から 2010 年代前半までは RSS リーダージャンキーだったので「これこれ、これだよ」という感じで使えています。しかし、昨今は RSS フィードを出力しないウェブサイトが増えているため、昔ほど「これで情報を集約できる」という感じではなくなっているとも思います。

情報収集といえば、携帯に [Artifact](https://artifact.news/) を入れて時折ニュースを読むようになりました。これは「僕が欲しかった SmartNews」という趣きです。想像ですが Artifact を作っている人たちも SmartNews をベンチマークにしていると思います。時おり「これは SmartNews のアレだな...」と思うような UI やレイアウトに出くわします。記事の推薦がゴシップくさくないことや、鬱陶しい広告が嫌なタイミングで出てこないところが特に気に入っています。

また、自分より若い世代がよく使っているツールは積極的に試そうと思っており、その意味で [Arc](https://arc.net/) を使うようになりました。過去に Brave や Edge を試すこともあり、そのときは「うん、これは 90 %くらい Chrome だな」と思っていました。一方 Arc を使うときはマインドセットを切り替える必要があり、だいぶ新しいパラダイムをもたらしています。今のところ順調に Arc に馴染んできているので 2024 年も Arc を使いそうです。 

ところで ChatGPT は 2023 年に使うようになったサービスとしては革命的に便利だと感じているのですが、これについては今さら僕が語れることも少ないので、割愛します 😛

## その他もろもろ

### 勤務先の買収

[去年転職したばかりの会社](https://mahata.vercel.app/posts/2022-12-01-startup-like-big-tech)が買収されました。また新入社員です。

公開情報だけを書こう (...というか非公開情報を知らない) と思うのですが、買収にともなう悲しい出来事の最たるものは同僚たちレイオフです。自分自身もレイオフされる可能性はあったし、同僚たちもある程度は覚悟していたと思うのですが、やはり実際に起きると悲しいものです。

大企業同士の合併は文化的にも中々む... (日記はここで途切れている)

### ライブ

今年も B'z のライブ (B’z LIVE-GYM Pleasure 2023 -STARS-) に行きました。久しぶりにマスクを外して声を出しながら鑑賞しました。相変わらず B'z のライブは楽しいし元気をもらえるので、とても良いです。今年のツアーは「デビュー 35 周年」のライブツアーでしたが、今後も長く続けてもらいたいものだと思いました。

ところで僕は B'z のファンクラブ会員であるにも関わらず、今回はファンクラブ会員向けのチケット販売期間にチケットを予約できず、一般向けチケット販売でチケットを購入しました。スケジュール管理ミスです 😢 次回は気をつけようと思いました。

### 献血

はじめて献血を体験しました。これといったキッカケはなかったけど「なにか世の中に貢献したい」欲求があったように思います。今後も続けていこうと思います。今年がはじめてだった割に、今年 3 回ほど献血をしたので、割といいペースだと思います。

### 歯医者

今まで「歯医者いらず」で、子どもの頃から歯医者にはほぼ行かずにいたのですが、ここにきて奥歯が痛むようになったので歯医者にかかるようになりました。

がりがりとドリルで歯を削られ、樹脂の詰め物をしてもらいました。こういう体験をすると「体を大事にしよう」と思うようになります。だいたい気づくときには既に遅い...というやつです。

いちど詰め物をしてしまった以上、歯医者には定期的に行く必要がありそうです。せめてこれ以上は悪くしないようにしたいです。

### 2024 年の展望

今年のダイエットはうまくいきました。リバウンドはさせず、体重をキープしたまま体脂肪率を落として筋肉量を増やしたいです。前述の Anker の体組成計を見ながら頑張ります。また、軽い腰痛持ちなのでストレッチをルーチンに含めて体の可動域 (特に腰回り) を広げたいです。

仕事関連では Kotlin プログラミングに時間を投資したい気持ちがあります。Kotlin を書いている割に Java っぽさが出てしまったりして、自分の未熟さを感じます。また [Kotlin/Wasm がアルファ版になる](https://blog.jetbrains.com/ja/kotlin/2023/12/kotlin-for-webassembly-goes-alpha/)など、Kotlin そのものを取り巻く環境も進化しており、ここへの投資は仕事の幅を広げる意味でも良いだろうと感じています。

あとは [Tanzu Application Platform](https://tanzu.vmware.com/application-platform) についての知見を深めてほしいと上司に言われているので、重い腰を上げて真面目に取り組もうと思います。


2023 年の振り返り


最近は [ktlog](https://github.com/mahata/ktlog) というサービスを作っています。これは Spring Boot (Kotlin) と React (TypeScript) で作られているブログサービスです。...というのは言い過ぎで、ブログサービスに **なる予定のもの** というのが正しいです。

これを作っているせいで、今はブログ記事をどこに書くべきか迷子になっているのですが、もうしばらくは ktlog がまともに動くようにはならなそうなので、ちょっとここで再び記事を書いてみるか、という気持ちになりました。書きます。


近況報告 - ktlog


[5月11日に Google Bard が日本語をサポート](https://japan.googleblog.com/2023/05/bard.html)してから、Google Bard (LaMDA) を利用してきました。ChatGPT の代わりを務めてもらった、ということです。

しかし、いくつかの点で不満を感じたため、涙を飲んで ChatGPT へ戻ろうと決意しました。ただいま ChatGPT。浮気してごめんな...。

まず最初にに Google Bard の「良いところ」を挙げてみようと思います。

1. すべての機能が無料で使える
2. 回答の生成が (ChatGPT の GPT-4 モデルより) 速い
3. (ChatGPT と比較して) 新しい情報も教えてくれる
4. 知らないことを「知らない」と伝えられる

`4. 知らないことを「知らない」と伝えられる` について補足します。Google Bard は答えられないことは「それについては答えられない」という旨の返答をします。これはハルシネーション (= 情報を捏造してしまうこと) よりも好ましいです。しれっと嘘をつかれると検証に時間がかかるからです。

とはいえ、これにはデメリットもあります。生成 AI を情報ソースとしてではなく対話相手として利用している場合、「それには答えられない」と返されると、そこで会話が止まってしまうのです。たとえば生成 AI が嘘をついたときに「でも、それだと xx と矛盾するよね」と言える方が **対話** としては面白いと思います。むしろ、ChatGPT はそういう使い方ができるのでウケているのだと思います。また ChatGPT に間違いを指摘すると「自分が間違えていました」と認めることもあります。このような誤りを認識し、認める能力こそ、AI における知性を感じる瞬間だと僕は思います。

さて、次は ChatGPT の方が優れていると感じる点です。

1. 履歴に「質問と回答のセット」が残る
2. (GPT-4 の場合) 生成されるテキストが Google Bard (LaMDA) より信頼できる **(要出典)**
3. スレッド形式で質問可能で、コンテキストをスレッド内でまとめられる
   * 各々のスレッドにタイトルをつけられる (最初のタイトルは ChatGPT 自身がつけてくれる)
   * (Web UI の場合) サイドバーに過去のスレッドのタイトル一覧が表示されている
     * 過去のスレッドから会話を再開することで前提を再入力する手間が省ける
4. iOS アプリがある

「生成されるテキストの質」について、僕は ChatGPT の方が優れていると感じています。しかし、実際には UI/UX に関してこそ ChatGPT を高く評価しています。

僕は技術的なトピックに関するディスカッションの相手として生成 AI を活用することが多いです。たとえば AWS で VPC/Subnet の設計をしているときに「この IP アドレスレンジでサブネットAを運用したいんだけど...」とスレッドをはじめて、一通り満足のいく会話をしたとしましょう。新しい要件が出てきたとき、このスレッドに戻ってきて「ところで VPC ピアリングもしたくなったんだけど...」と続けられるのは便利です。これは Google Bard などでは実現しがたい点です。

また、サービス履歴に「質問と回答のセット」が残っていると壁打ちしてもらった内容を一覧できて便利です。Google Bard は (デフォルトでは) 質問のみが残るようになっています。これは意図的な設計だと思うのですが、その質問から再び回答を得ようとすると時間がかかるし、そもそも同じ内容を得られるとも限りません。やはり、質問と回答がセットで残るメリットは大きいです。

最後に iOS アプリの存在も、地味に嬉しいポイントです。携帯のブラウザで同等のことを行えるものの、やはり専用アプリのユーザー体験には及ばないと感じています。

...というような理由から、Google Bard に一旦の見切りをつけて、また ChatGPT の課金ユーザーに復帰しました。半年くらいしたら、また別の生成 AI にスイッチする可能性は残っているけど、しばらくは ChatGPT を楽しもうと思います。


投稿記事