はじめに
こんにちは！イタンジの賃貸管理支援プロダクトを開発している、「Unit5」という開発チームです。 Unit5では、普段の業務においてメンバーは開発業務に携わる時間が多いので、自分の考えや学んだことを発表する場が少ないなと以前から感じていました。
また、Unit5というユニットは、いくつかのプロダクトを開発する複数のチームのまとまりでもあることから同じユニットなのにチーム間の情報共有が足りていないという課題も潜在していました。 これらの課題を解決すべく、2025年8月から社内（Unit内）のLT会の取り組みを開始しました。
下記のようなスタイルで実施しています。
発表形式
- テーマは何でもOK
- 資料の形式もスピーカーにお任せ
- 発表時間は1人あたり7〜8分を目安に柔軟に対応
テーマ例
- 最近やっていること
- 最近勉強になったこと / ノウハウ / 気づき
- 読んだ本の考察・まとめ・共有
- 最近思うこと
- アンチパターンの紹介
- 個人的によかったと思う取り組み
- etc...
実施の目的・背景
- 日々考えていることを、あまり事前情報がない人でもわかるように言葉で表現して伝える練習
- 日々忙しい中で集まった知見や情報を整理してアウトプットすることで自分に定着させる
- チームを跨いでどんなことをやっているか / どんなことを考えて仕事しているかをざっくり把握してお互い活かせるところを探す
毎回盛り上がってタイムボックスに収まりきらないこともありながら、この取り組みにより他のメンバーが工夫していることが可視化されたり、発表の内容を受けて自分の業務に取り入れてみたりという動きがチームとして見られ、チーム内のコミュニケーションも増えたように思います。
直近では半年分のLT振り返り会を実施しました。今回はその中で、この半年にあったLTの中で特にメンバーから「タメになった！」と好評だったLTを4つ紹介します。 各LTについて、振り返り会で集まったコメントも掲載していますので、チームの雰囲気が伝わると嬉しいなと思います。ナイスLT！
1. COLLATIONを指定したLIKE検索の落とし穴
資料概要
MySQL 8.0系のutf8mb4_0900_ai_ciを指定したDBレベルのLIKE検索では、本来は半角と全角を区別せずヒットするはずですが、濁点を含む半角カタカナを検索条件に使うと、保存されている全角データがヒットしない場合があります。
これは、保存済みの全角「ガ」が1文字の合成形であるのに対し、入力された半角「ｶﾞ」が「ｶ」と濁点の2文字からなる分解形として扱われ、LIKE の照合時に文字数の解釈がずれてしまうことが原因です。
この問題から、DBに保存する前や検索を行う前に、アプリ側でNFKC正規化を行い、文字数の解釈違いをなくしておくことの重要性を学びました。
メンバーからのコメント
- 類似の事象の問い合わせ対応時にまず疑う観点の一つとして頭にインプットされました！
- 原因を論理的に分析する思考プロセスが印象的でした！
- 自分も以前同じ問題に詰まったことがあり、当時はなんとなくの理解で進めていました。それをちゃんと体系的に解説してもらえてとてもありがたかったです！
- チームのナレッジとしても蓄積された実感があります。
- このような知見を組織やチームのナレッジとしてもっと溜めていきたい！
2. 基幹システムの削除について考える
資料概要
Webサービスやシステム開発において、当たり前のように行われる「削除」という操作。 しかし、企業の屋台骨を支える「基幹システム」の世界では、一つのデータの削除が致命的なリスクを孕むことがあります。 今回は、社内LT会で発表したスライドをもとに、基幹システムにおけるデータの重みと、削除の設計思想について振り返ります。
メンバーからのコメント
- 物理削除と論理削除の違いを改めて振り返る良い機会になりました。基幹システムにおいて、どのような場面で物理削除と論理削除を使い分けるべきか、その判断基準を整理するきっかけにもなったと感じます。
- リファインメントなどの上流工程でも、物理削除・論理削除・無効化機能のどれを選ぶべきか、また Rails / ActiveRecord の
destroyによって関連レコードまで連鎖的に削除されてしまわないか、といった点を重要なレビュー観点として意識するようになりました。資料をきっかけに、削除に伴う影響範囲を見る視点がより強くなったと思います。 - この発表以降、削除してはいけないリソースを誤って消していないか、データ消失のリスクをこれまで以上に考えるようになりました。PdMや開発メンバーとの議論でも「本当に物理削除でよいのか」を立ち止まって検討する場面が増え、物理削除に対する慎重さがチーム全体で高まったと感じています。
3. 単体テストの考え方/使い方
資料概要
- 書籍『単体テストの考え方/使い方』をもとに、単体テストの本質や目的を解説したスライド
- 「古典学派」や「ロンドン学派」のアプローチについて紹介
- 単体テストの究極の目的や良い単体テストを構成する4本柱や、テストのしやすさとコード設計の関係を紹介
- 実装の詳細ではなく「観察可能な振る舞い」をテストすることの重要性を説明
メンバーからのコメント
- これまでテストに対して曖昧だった考え方やアプローチが、今回の発表を通じて言語化され、自分の中でテストに対する判断基準を持てるようになりました。迷ったときの判断基準が明確になったと感じました！
- 資料にあった「テストのしやすさとコード設計の関係」についての話は非常に参考になりました。テストが書きにくいと感じた時は無理にテスト側で解決するのではなく、「設計が密結合になっているのでは？」とプロダクトコードの設計自体を見直す視点を持っていきたいです！
- 「理想的なテストを妨げる偽陽性（本来問題ないのにテストが落ちること）と偽陰性（問題があるのにテストが通ること）」の解説を通じて、実装の詳細に依存したテストはリファクタリング時にテストが落ちる「偽陽性」を生み出しやすいという点を改めて認識できたと思いました。
- 上記を踏まえ、今後は内部ロジックではなく「観察可能な振る舞い（＝最終的な結果）」に焦点を当てた、壊れにくいテストを意識して実装を進めたいと思います。
- 良い単体テストを構成する「4本柱（回帰に対する保護、リファクタリング耐性、迅速なフィードバック、保守のしやすさ）」のトレードオフを常に考慮し、単にカバレッジを追うのではなく、プロダクトを確実に守る「質の高いテスト」の作成に努めていきたいと思いました！
4. DDDで整理するプロダクトのドメイン
資料概要
不動産領域のシステムは、多様なステークホルダーや業務が関わるため、ドメインが複雑になりやすいです。 そうした前提のもとで、書籍『ドメイン駆動設計をはじめよう』（O'Reilly）を参考に、プロダクトのドメインを「中核」「一般」「補完」に分類する考え方を紹介しました。 DDDの具体的な設計手法（実装パターン）を実践するのはハードルが高くても、まずはドメインの性質を正しく理解することから始めることで、設計や開発タスクの優先度の判断に役立てられるのではないか、という提案です。
メンバーからのコメント
- 業務領域（サブドメイン）を3つのカテゴリに分類して捉える視点を、これからより意識していきたいと感じました。分類して整理することで、日々の業務理解や意思決定にどのような変化が生まれるのかも、今後あわせて検証していきたいです。
- 実際に現在取り組んでいるプロダクトを題材に、業務領域（サブドメイン）を3つのカテゴリに分類してみるワークショップをやってみたいと思いました。具体的な業務に当てはめて考えることで、DDD の理解がさらに深まりそうです。
- DDDの話をするとだいたいパターンの話になりがちですが、「ドメインを理解して整理する」ことを意識することは今日からできそうという記述がとても良かったです。まずはここから意識してみるのが大事だなと感じました。
おわりに
今回は4つのLTを紹介し、LTの振り返りコメントもあわせて掲載しました。
振り返り会は今回初めて実施してみたのですが、LTの内容を思い出すために発表資料を再度読んだりLT会の際に取ったメモを再度確認したりする必要がありました。
半年分のLTの振り返りという重いタイトルではなく、毎回のLTが終わった後や少し経ってからのタイミングで感想のコメントを交換したり、どう業務に活かせているかフィードバックし合ったりと、 記憶が鮮やかなタイミングで学びを共有できる場を持つことも良さそうです。
今回の振り返りを通じてチームの誰かの試行錯誤が個人の苦労として消えてしまうのではなく、チーム全員が利用できる共有ライブラリのように機能する組織を目指したいと思いました。 一人だけで10時間を苦労して得たノウハウと知識を5分で10人のメンバーに共有すると、チーム全体で約90時間の時間的メリットを得ることになります。
解決した問題を(N(人数) × 10 時間)ではなく(10 時間 + N(人数) × 5 分)の効率でチームのライブラリに組み込むと、経験はデータになり、文化として残り、知識のインフラになるはずです。
今日あなたが一人で解決した課題は組織において何時間×人数のレバレッジ効果を期待できるものでしたか？皆さんのチームでもLT会を始めてみませんか？ 最後までお読みいただき、ありがとうございました。
