概要

現職の開発部のメンバーに共有した記事のログ

技術系

【初学者向け】単体テストや結合テストで利用される代表的なテスト手法・技法メモ

テストの基本的な考え方をまとめた記事です
体感的にはそれはそうだろうなって思うことでも、テストを書いたことがない人にとっては、いざ書き始めるとどう書けば良いかわからなくなることもあるかと思います
テストに慣れていない人は一度目を通しておくと良いかもしれません！

SQL作成を効率化するために、まずはデータ構造のドキュメント化から始めてみた

AIにテーブル構造とModelファイルを学習させてドキュメント化してからSQLを構築する手法とメリットに関する記事です
当社でもAIを本格的に利用し始めましたが、こういったことは Claude Code などの AI Agent に任せるにはとても良いアプローチだと思いました
情報検索と整合性の調査はとても時間がかかるので、こういったことを積み重ねていくことでドキュメントを自分たちで作り上げていかなくても必要になったときにドキュメント作成も含めてAIで解決できるというのは資産としても時間的コストとしても有効な手段だと思いましたので共有いたします！

セキュリティ系

セキュリティアップデートは忘れたころにやって来る | docker 25 の tmpfs のデフォルトパーミッションが変わった件

セキュリティアップデートで docker のバージョンが自動的に上がったことで、デフォルトパーミッションが変更されて Auto Scaling 設定がされた EC2 が起動しなくなたったという記事です
セキュリティ的には自動アップデートは非常にありがたい機能ではありますが、自動でアップデートされたシステムでデフォルト値が変更されるというのは非常に怖い事象です
このような問題に直面して悩まされないように、デフォルト値と同じ値とわかっていても、明示的に値を設定するように心がけましょう！

コミュニケーション系

質問力はコミュ力だけじゃない——デザナレで得た気づきと、明日から使える「バフ」のヒント

質問力を上げるための工夫についての記事です
個人的には質問はどんどんするべきだと思っていますが、質問する側が結構大きな壁を作ってしまうこともよくあります
そういった壁を少しでも小さくできるように、ここに書かれているような補助輪を使いながら、相手が答えやすい・誤解しづらい質問を皆で心がけていければと思い、共有いたします！

その他

なぜリリース計画は遅延するの？「後ろめたくないバッファ」で解決する方法

どのようにバッファを設けるかについての記事です
バッファについては様々な考えがあるかと思いますが、自分はバッファは必要な考えであり、たとえ社内であってもバッファを考慮したスケジュールを考える必要があると思います
しかし中にはバッファを持つことに対してネガティブな考えを持つ人もいるかと思います
そういった際に説得力を持たせるために、この記事に書いてある考え方ややり方を参考に、健全な開発が行えるようにしていけたらと思います！

エンジニアの脳が壊れる瞬間 ─ 複雑性・認知負荷・計算量のメカニズム

認知不可に関する記事です
エンジニアの認知不可の観点から技術負債が与える影響と、良い設計が認知不可にどのように影響を与えるのかということの解説が個人的にしっくりきたことでリファクタリングのモチベーションになると思いましたので共有いたします！

To プロダクトチーム

Repro における組織横断した SLO 運用のはじまり

SLOの運用をするために、どういった流れで、何を定めたかの記事です
当社プロダクトにおいてもSLOの導入を考える中で参考になると思います
もちろん新規開発におけるアップデートは必要だと思いますが、同じように信頼性の担保と、担保されていることの計測は必要だと思います
来期は信頼性の部分でもしっかり取り組んでいけたらと考えております！

共有するほどではないけど興味があったもので読んだもの

ChatGPTの「良い人フィルター」を外して本音を引き出してみた
- 用途にもよりそうだが業務においてはこういった指示は有効そうだと思ったが、コメントされていたプロンプトの方がより良さそうだと思った
エンジニアが覚えておきたい英単語 - AIコード読解時代の必須語彙
- 高度な概念に出てくる英単語は初耳のものもあって勉強になった
Claude CodeでBacklogのチケットから自動実装する仕組みが快適すぎた
- 既に仕様書のみで自立して動く環境が整っているのであれば、こういった運用も可能そう
【コピペでOK】Gemini RAGはこんなに簡単！寝てる間にGitHub Actionsが最新ドキュメントを学習するAIアシスタントを作ろう
- 手軽に自動で作れるのは魅力的！
C++は常に進化している！ C++26・C++23の新機能と今後のトレンド
- 長らくC++を書いてなかったから追ってなかったけど、すごく進化していて驚いた
決済実装は怖くない！テストカードという存在
- テストカードという共通規格があるわけでは無く、各社独自にテストカードを用意していると認識している。この記事だけだと勘違いしそう
AIがプログラマを滅ぼすというのは、幻想やったかもしれん
- AIは銀の弾丸ではなく、あくまで道具である以上は使いこなせる人間は必要になる
あかんかった人生をやり直す
- 好きな人はAIが出来るようになってもやるというのはその通りだなと思った。そういう人がAIでは表現できない何かを生み出すのかもしれない
【Docker】Docker用語が分からない人のための超入門ガイド
- 個人的にレシピ・型・実物の例えはわかりやすい
開発効率が上がる！最強のプログラミングフォント5選
- 日本語完全対応の源ノ角ゴシック Code JP（Source Han Code JP）を使ってみようかな
超絶わかりやすい！正規表現で詰まったときのチートシート
- 基礎的なことが理解できていない人には便利そう
組織横断で取り組む開発生産性：失敗から学んだ本当にやるべきこと
- アジャイルでいうストーリーを最小単位に分割して提供し続けるという考え方は良いなと思った
- まずレベル1ですらできていない自社は、レベル1の計測から始めるべきなのだろうと思う
2025/11/14 Qiita Bash 「キミたちはClaude Codeをどう使いこなす？」 LT 登壇資料
- 色々なグラフで利用状況を可視化できることはわかるが、そのグラフで何を伝えたかったのか、スライドだけではわからない…
品質とセキュリティの境界線をどう設計する？
- 「品質＝正常系の保証」「セキュリティ＝異常系の防衛」という考え方はわかりやすいと思った
セキュリティ棚卸し - ハウテレビジョン技術ブログ
- 当社でもセキュリティリスクの洗い出しと分析はしっかりやっていかなければと思う
ユニットテストに時限爆弾を作らないためのベストプラクティス
- 相対日時でテストするか、今日を固定してテストするべきというのは当たり前のことだけど、たまに忘れてテストしてしまうことがあるので気をつける
エンジニア評価制度を再設計した1年の軌跡とこれからのチャレンジ
- 絶賛自分も部長としてエンジニアの評価制度を改善中なので、参考にしながら来期の評価制度を作っていく
たぶん、読んでない
- 何故これがテックブログの中に流れてきたのか不明だが、個人的にこういうの読むの好きw
「運がない」を「運を呼ぶ」に変える-確率が教えてくれる“楽観思考”｜義務教育で紐解く仕事術
- 自分は運が良い方だと思っているが、特別意味付けして運が良いと感じているわけではないので、普段からなにか特別な意味を見出すことができれば人生もっと幸せになるのかもしれない
社内資料「速習 AIエージェント入門」を公開します
- このスライドを勉強会でやってもあまり業務として使いこなせるようにはならなさそうだけど、用語の認識合わせとセキュリティくらいは知っておくと良さそう
社内コミュニティ発！「子育てシフトガイド」と、社外発信へふみきった理由
- 自分もつい先日育休を取得したけど、申請方法から引き継ぎ、復帰後の流れまで未知が多かったので、こういったものを社内向けに作っていけたら今後の当社社員にもプラスに働きそう
noteエンジニアの買ってよかったもの2025
- 他の人の買ってよかったものが、自分には刺さらなかったので残念…
落ち着いて上司！産休の相談をもし受けたら…
- 部長という役割を担いながらも、メンバは基本的に事業部に属しているので自分に直接報告は無いだろうとは思うが、もし有ったときはしっかり対応できるようにしておきたい
AWSデータベースサービスまとめ — 各サービスの特徴と用途
- 今のプロダクトの新しい要件の一つに DynamoDB が使えそう
Googleが発表したAIエディタ、Antigravityを触ってみた。~指示・実装・動作確認~
- Antigravityはフロントエンドを開発するのにかなり良さそう
【保存版】Google Antigravity 完全攻略ガイド｜次世代 "エージェント型" IDEのすべてを使い倒すチートシート
- 会社のPCはIntelだから使えないじゃんw
VSCode派生IDE「Google Antigravity」が、AI駆動開発の新しいパラダイムを切り拓いている
- JulesをIDEとして実用化したイメージなのかな？？
【セキュリティ】初めてアプリをつくる人がまず抑えておくべき基本的事項
- セキュリティ対策を知らない人にとっては最低限やるべきことのメモになる
コードレビューをゲーム化しました
- コードレビューが重要視される現代だからこそ、こういったものが流行っていくかもしれない
【TOON】JSON時代の終わり？話題のTOONを解説してみた
- これから実装する人たちは一旦は JSON で実装して、その後 TOON を試してみるという使い方が良さそう
- その方が効果を実感できるだろうし、コスト削減に貢献したという実績として目に見える
「謝罪」しすぎない技術
- 枕詞のように謝罪から入ってしまうので自分も気をつけなければと思った
Antigravity使ってみた - Claude Code&CursorユーザーがGoogleの新IDEを触った感想
- 使ってみた記事を見るたびに、これなら自分でも使えるかもという気持ちになってくる
AIファーストなドキュメント戦略 - DocCommentにユビキタス言語を書くだけのシンプルなアプローチ
- この方法も SDD も一長一短だなと感じる
- 仕様書一覧で全貌が掴めるならその方が効率よく開発できる場面もあれば、コメントベースで残すほうが効率が良い場面もある
- 個人的に良さそうだと思ったのはUIにユニークな番号を降ること
エンジニアとして何を学ぶか
- エンジニアの注力するべき役割は変わっていくかもしれないが、エンジニアが学び続ける必要が有る点は変わりなさそう
Repro における SLO の利用拡大〜0→1のその後〜
- SLI, SLO を決めていくのは必要なことなんだろうけど、ここを一からしっかり勉強して決めていかないと意味がないものになったり形骸化する可能性もあるだろうなと思った
「Antigravity」使い方入門｜Google発の最新AIモデルも使える統合開発環境（IDE）
- 現段階でも UI は Antigravity, API は Claude Code といった棲み分けで利用しているのはありかもしれない
開発生産性指標に判断基準を作ったら、チームの自律的な改善が始まった話
- 開発生産性に限らないだろうけど、まずは計測、そして次に判断基準を明確化する。そしてより良くするための議論を行う。という流れで取り組んでいくのが良さそう
エンジニア組織で推進してきたAI導入までの振り返り
- AIの導入の壁は当社でも理解の壁と組織の壁は乗り越えつつ有ると思いますが、人の壁はまだ抵抗が大きい人が多いと感じるので、どのように対策していくかを考えていかなければと思う
開発生産性を持続性とアウトカムの観点から考え直した
- 開発生産性をアウトカムを含めて考えるとビジネスサイドの理解も得やすくなりそうで、この考え方は良さそう
- CEOがPdMを兼任しているとアウトカム最優先の考え方になってしまうので、ForKeysだけの開発生産性だと導入自体が難しい
機能開発チームによる自律的な SLO 運用と、SLO を考慮した新機能開発プロセスの整備
- SLOをリリースフェーズ毎に精査して閾値を決定していくというアプローチを試してみるのは良さそうかも