2025-10-12

日報書くツール最適解の現在

このブログを読んで、「日々の新しい情報や調べたことをストック情報として保持できていない」と感じた。
そこで、情報をうまく保持できるようにするためのメモツールについて考えた記録。

soudai.hatenablog.com

メモツールに求める条件

自分が日報や学びの記録を書くために求める条件は次のとおり。

PC・iPhone・iPadなど、すべてのデバイスで書き込み・閲覧できること
リッチテキストではないこと（Markdown対応なら理想だが必須ではない）
シンプルで、すぐにメモできる操作性があること
無料

日々の学びをざっと記録したいだけなので、Notionのような高機能ツールは日報用途には向かない。
特に重要なのは「操作がシンプルで、必要な時にどのデバイスでもすぐにメモできること」である。メモに凝った機能は必要ない。

試した結果、Consenseに落ち着いた

最初はApple標準のメモアプリを使っていたが、コピペ時にリスト（li）が消えることや、iCloud アカウントでログインできない環境では iCloudメモを使わないといけないので面倒でやめた。

その後、Consense を試した。
今まで使ったことはあったが、独自記法や公式アプリがない点が好きではなかったので続かなかった。ただ改めて使ってみると、独自記法を使いこなさなくてもメモアプリとして十分だった。そして公式アプリの代わりにPWAで代用できることから、最終的にこれで良いということになっている。

2025-09-30

Kaigi on Rails 2025 に「Web Components で実現する Hotwire とフロントエンドフレームワークの橋渡し」というタイトルで登壇しました #kaigionrails

イベント

先日 Kaigi on Rails 2025 で登壇しました。登壇内容の相談や、会社で何回も練習に付き合っていただいてありがとうございました。特に id:kozy4324 や id:kiryuanzu にはとてもお世話になりました。

speakerdeck.com

資料に盛り込めなかった話の補足や反響に対する私見を載せます。

当日のTwitterの反応

https://x.com/search?q=(%23kaigionrails)%20since%3A2025-09-26_15%3A45%3A00_JST%20until%3A2025-09-26_16%3A05%3A00_JST&src=typed_query&f=live

反響への回答

custom element へのデータの渡し方が複雑じゃない？

custom element へのデータを渡すインターフェースは、HTML属性 と DOMプロパティ の2つです。発表では渡したいデータ型によって使い分けるように説明しましたが、どちらかに統一できた方がシンプルだとは思います。

仮に HTML 属性に寄せたい場合は、コンポーネント側で文字列を型キャストする必要があります。Angular なら transform という API が用意されています。
入力プロパティによるデータ受け入れ • Angular 日本語版

ただ、この型キャストもプロパティごとに実装するのが面倒になりそうだったので採用しませんでした。

その代わり、DOM プロパティを利用して JavaScript 側から直接値を渡しました。これなら文字列以外も扱えます。ただし、この方法は inline script が必要になるため Strict CSP（特に script-src 'self'）が使えません。*1

CSP によりセキュリティを担保したい場合は、DOMプロパティは使いづらいと思います。

developer.mozilla.org

今回 custom elements を採用したのは新規サービスであり、コードベースも小さいです。そのため、セキュリティ的にまずいコードが混入しないようにレビューで担保できるので成立していると思っています。

データ属性に配列やハッシュを入れるとき、もっと良いサニタイズ方法はない？

正直なところ、現状は難しいと思います。サニタイズしつつ、ちゃんと動作するコードにするには少なくともの要件を満たす必要があります。

HTML として正しいこと
JavaScript として正しいこと
ERB（Ruby）として正しいこと

この条件を同時に保証する API はなく、自前で作るのも大変です。なので「data 属性に文字列として入れて、JavaScript 側で JSON.parse する」のが現実的だと思います。もし属性が増えて管理が面倒なら、script 要素に逃げるのではなく HTML 属性の工夫で対応するのが良いと考えています。*2

custom element を自作するとメンテナンスコストが高くない？

ここは設計次第です。うまくカプセル化できれば再利用性も高く、コストは抑えられます。逆に安易に作るとコストは増えます。

また、そこまで作り込むなら Hotwire で自前実装するのも選択肢です。私たちのチームは Angular の知見を持つメンバーが多かったので、custom element 化することで既存の知識を活かせるメリットがありました。チームのスキルセットや環境によって最適解は変わると思います。

こぼれ話

今回初めての登壇で半分病みかけながら、準備をしました。できうる準備はして望めたので、それは良かったかなと思いつつ、今後に活かしたい改善も見つかりました。そのあたりは別でまとめるかもです。

いろんな方に声掛けられまして、「初めて custom elements 知った」「今度使ってみたいといった」声を届けてくれた方々がいて嬉しかったです。登壇者は正直大変でしたが、その分コミュニティと繋がれた感覚が味わえて、またやりたいなと純粋に思いました。

あとは、懇親会で大倉さんとお話しできる機会がありまして、採択理由やコミュニティの話ができました。今後も Web 標準を追っていくモチベーションが湧きましたし、コミュニティや勉強会を主催したくなりました。*3 ありがとうございました。

色んな人と話して自分もコミュニティ欲しかなった。多摩でやるかー！
— daichi (@da1chi24) 2025年9月27日

同世代のレベル高い発表を見て、刺激ももらいました。自分も今日から良い発表ができるように日々の活動頑張ります。

最後に、Kaigi on Rails を主催していただいたオーガナイザーの皆様ありがとうございました。

*1:ちなみに Kaigi on Rails 2025 で紹介されていた Herb を触っていたのですが、 lint ルールで inline script を禁止するものを追加する issue がありました。erb に lint が掛けられるのはいいですね。 github.com

*2: id:hk_it さんに昔厳格なHTMLを定義するものとして XHTML という仕様があったことを教えてもらって、へぇ〜となりました。

*3:現在構想考え中です

2024-12-07

「わかったつもり」を乗り越える本の紹介

本

2024年の"推し"本 Advent Calendar 2024 の 7日目の記事です。昨日はまつーらとしおさんでした。

adventar.org

今年読んだものの中で、特に推したい本として『わかったつもり読解力がつかない本当の原因』（以下、本書）を紹介します。

books.rakuten.co.jp

本書を読むと、今まで読んだ本をまた読み返したくなります。

読解の最大の障害は「わかったつもり」である

本書は、小学2年生の教科書に掲載されている物語を読むところから始まります。その物語は平易な文章で書かれており、特に詰まるところがなく全て理解できている感覚になると思います。おそらく、これ以上同じ文章を読み返そうと思わないはずです。

しかし読み進めていくと、すぐに物語の読み込みが甘かったことに気付かされます。なぜ最初に読んだタイミングで物語を読み返す気にならなかったのか、それは「わかった」状態になってしまったことが原因であるというのがこの書籍の主張です。

「わかった」状態は、ひとつの安定状態です。ある意味、「わからない部分が見つからない」という状態だといってもいいかも知れません。したがって、「わかった」から「よりわかった」へ到る作業の必要性を感じない状態でもあるのです。浅いわかり方から抜け出すことが困難なのは、その状態が「わからない」からではなくて、「わかった」状態だからなのです。

「わかった」状態とは、よくエンジニアでいう「完全に理解した」に近いかもしれません。全てを理解している、いわば全能感に浸っているような感覚です。ただ、一旦その安定している状態になると、もう一歩深く理解することができなくなってしまいます。

「わかる」から「よりわかる」うえで必要なのは、「わかったつもり」を乗り越えることなのです。「わかったつもり」が、そこから先の探索活動を妨害するからです。

この状態をどう脱していくかは、文章を読む上で非常に重要なポイントになります。

「わかったつもり」を乗り越える方法

「わかったつもり」状態から抜け出す方法がいくつか紹介されています。1つは「矛盾」や「疑問」を見つけることです。一見すると「矛盾」や「疑問」を見つけると、文章の内容を理解できていないネガティブな印象になりがちです。しかし実はその発見が、次の「よりよくわかる」ためのきっかけになることがあります。

「矛盾」や「疑問」は、次の「よりよくわかる」ための契機となるものです。「矛盾」や「疑問」はネガティブに捉えられることも少なくないのですが、むしろ次の解決すべき問題を発見できたという意味で、「認識の進展」という観点からはポジティブな存在なのです。

ここはしっくりくる内容でした。文章を読みながら疑問を見つけると、自分で内容を検証したり、整理して読み直したりしたくなります。文章を素直に読みすぎず、違和感を見つけるプロセスが「よりよくわかる」に繋がるというのは納得感がありました。

この他にも「わかったつもり」状態から抜け出す方法として、要注意ワードを見つけることや文脈を整理することなど、色々なテクニックが紹介されています。本書では、これらのテクニックを実際の題材の文章を読みながら紹介しています。そのため、腑に落ちやすいと思います。

読解とは終わりなき探求

最後に一番刺さった内容を紹介して締めようと思います。

「わかったつもり」の状態から、「わからない」状態などを経由して、「よりよく読めた」状態に移行できれば、それで読みが終わるわけではありません。自分でかなり読めた、読みの進展があったという文章に、しばらくして出会ったとき、そこに、新たな「わからなさ」を見いだしたり、部分間に関連をつける新しい解釈を思いついたりすることは、珍しくありません。（中略）つまり、「よりよく読めた」という状態は、「以前よりはよく読めている状態」かも知れないけれど、その状態を乗り越えるための、もっとよい読みが存在するのです。

文章は一度読んで終わりではありません。特に名著や名文は何度も読み返すことで、その度に新たな発見や学びに気づけるものです。より良い読み方を学ぶと、新しい本だけではなく、今までの本もまた読みたくなると思います。

ここまで読んで本書の内容を「わかったつもり」になっていませんか？気になる方は、ぜひ『わかったつもり読解力がつかない本当の原因』を手に取ってみてください。

ありがとうございました。2024年の"推し"本 Advent Calendar 2024 、次はうーたんさんです。

2024年の"推し"本 Advent Calendar 2024 - Adventar

2024-07-28

Google Engineering Practices Documentationを読んだ

先日、会社の同僚の方に勧められて Google Engineering Practices Documentation の Google’s Code Review Guidelinesを読んだ。

google.github.io

このドキュメントは、Googleが様々なプログラミング言語やプロジェクトで培ったベストプラクティスのまとめをオープンソースとして公開しているものである。Google’s Code Review Guidelinesはレビュアー用のガイドとレビュイー用のガイドに分かれている。

ちなみにこのドキュメントには非公式な日本語翻訳もある。自分は基本こっちを読みつつ、わかりにくいところは原著にあたるようにした。

google-engineering-practices.translation.shuuji3.xyz

それぞれ内容も多くなく、全体として数ページしかないのでサクッと読みやすかった。

また内容もコードレビューの基準、期待値、レビューの進め方、レビューのスピード、レビューコメントの書き方など多岐に渡っている。実際に明日から取り入れられるような具体的なHowも書いてあるので、理解しやすかった。またレビュー時の反対意見の書き方や不満が生まれてないような振る舞い方などにも触れている。経験に基づいた内容だと感じた。

明日からできることを考える

このガイドラインを守破離の守として、具体的に明日からのコードレビューでできそうなことをNext Actionとして積む。

PR に対してシステムが今よりも良い状態になっているのであれば、Approveする。完璧を求めない
PR を読むときは diff だけではなく、システム全体のコンテキストから妥当かを判断する。
PR に何か優れたところがあったときには、コメントやチャットで伝える。

全部やるのは難しいので、適宜見返しつつやろうと思う。

感想

人間は知ったかぶりをしてしまう生き物だと自覚しておきたいなと思った。

PRを読んでいてなんとなく合ってそうでApproveするには一番避けたいし、ありがちなことだと思う。例えば、よくわからないアーキテクチャや知らないメソッドが出た場合は、その都度調べることができるので理解は進む。しかし、なんとなく知ってるメソッドだったり、他のリポジトリで使われているコードだったりすると、そもそも疑問が湧かない。なので特に調べずに、わかった気になってしまう（結果 Aprprove してしまうこともある）。

エンジニアリングの文脈ではないが、最近読んだ本にも似たような話が書かれていた。

www.kobunsha.com

一歩深いレビューをするためには、自分でもドキュメントを読んだり、実際に手元で動かしたり（動かしたログを読んだり）して、ある種批判的に見て行く必要があると感じた。抗いたい。

2024-07-14

要求を整理してリリースまで進める方法を整理する

要求の整理、実装からリリースまでの進め方をまとめました。「参考」にある本を読んだり、1on1 やチームメンバーの動きを見ていて気づいた学びを言語化しておきたいので綴ります。ここで考えるのは着手する前提のものであって、そもそもの問題設定や問題同士の優先順位を考えることは、スコープ外にします。

※ これが最善ではなく、あくまで現時点でのスナップショットです。

具体的な進め方

問題を理解する（事前条件の整理）

要望を受け取る
- ユーザーストーリーと Whyを明確にする

要件の前には要望があるから、まずは要望から聴くとよい。まぁwhyから話してって話でユーザーストーリーをちゃんと書きましょうって話で、なんでユーザーストーリーをちゃんと書いてほしいのか？って説明するのは大事だよね。 #kichijojipm
— そーだい@初代ALF (@soudai1025) July 13, 2024

要望から要件を整理し、ステークホルダーとエンジニアで要件の合意をする
- 要望に対してエンジニアはそもそも実現可能か？より実現性の高い方法がないか？のすり合わせを行う
合意を得た要件から仕様を整理する

計画を立てる

仕様を元に実装方針を計画する
- 実装を進める上で必要なステークホルダーを認識しておく（ドメインエキスパート、SRE、別チームのエンジニアなど）
- このタイミングで詰めきれていない仕様が発覚した場合は、ドメインエキスパートと仕様の確認・合意を行い、要件を整理し直す
- 実装方針はチームでレビューを通す
実装できる単位で分割する

実装する

実装方針をもとに実装を行う

振り返る

実装したものが要件を満たしているか確認する
- 事前条件が変わった時に正しく要件を満たすか（もしくはちゃんと満たさないか）も確認する
- 例. 正常系だけでなく、雨の日のユースケースが漏れていないか
受け入れテストを行う

補足

順番は大事。一番大事なのは「問題の理解」と「計画」だと思っている。逆にここさえ整理できればエンジニアのボールにできるので、あとはやるだけの状態に落とし込める。
先に実装方針に対してチームのレビューを通すことで、より良いプランを提案されたり、具体的な実装に対して認識が揃い、その後のレビューを通しやすくなるメリットがある。
事前条件の理解が浅い状態で実装を着手することは陥りやすいアンチパターン
- 人は具体的なことから着手しやすい（要出展）
- 要件が理解できていない状態で具体的にわかっている実装から着手すると、全体がぶれて手戻りが発生し、結果的にロスタイムが生まれる可能性がある
事前条件が足りず机上の空論で議論して先に進まない場合
- 具体的なものを見せることで前に進むことが多い。例えばPoCなどの叩きを作ってそれをベースに議論するなどが良い案だと思う。