2025-10-20 共有記事ログ

概要

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

技術系

美しいソースコードの基本原則 | 『AI時代のきれいなプログラムの教科書』より

綺麗なプログラムを書くための考え方の記事です
以前「良いコード/悪いコード」で学びましたが、その学んだ内容をより深く理解できるのではと思い共有いたします
この記事を読んでいての所感ですが、メソッドやクラスを分けることで、処理内容を辿るコストがかかって非効率と感じる場面は、命名が適切では無いか、テストがないので呼び出すクラスやメソッドが信頼できないことに起因している気がしましたので、そこを重点的に力を入れると、今抱えている課題も改善するかもしれないと思いました！

APIを5倍高速化！インデックス活用のSQLチューニング

Indexを利用できるSQLを考えることでパフォーマンスが改善するという記事です
カーディナリティを意識したIndexの作成とSQLの構築ができれば、今よりもより高速なレスポンスを返せるようになるかもしれませんので、パフォーマンスが気になった場合はこういった場所にも意識を向けながら改善できればと思います！

Chrome DevTools MCPでWeb開発のチェックを自動化！Playwright MCPとの違いは？

Chrome用のMCPサーバの紹介記事です
既存のセッションは維持されないのである程度テンプレート化したログインフローの記述は必要だと思いますが、今まで手動でやるには手間がかかっていた繰り返し内容やネットワークの通信結果の解析をAIがやってくれるようになるので、設定しておけば開発効率が上がりそうだと思い共有いたします！

To プロダクトチーム

Claude Codeで開発する時こそ「ユビキタス言語辞書」を作ろう！

ユビキタス言語をAIにメンテナンスさせる記事です
ここではClaude Codeというエンジニア向けのCLIツールを利用しておりますが、Gemini + スプレッドシートなどで管理できれば、みんなが楽にユビキタス言語を管理・参照できるのではと思います
人がメンテナンスするのはなかなか難しいですが、常にAIに参照させながら、会話の中で自動的にメンテナンスしてくれるのであれば、今後活用していけるのではと思い、共有いたします！

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

• 第５回：とはいっても難しいキャリア形成とそのための活動【キャリア形成シリーズ】
  • 「できるけどやりたい仕事ではない」はすごく感じるが、給与をある程度もらってしまうと、やりがいとのバランスが難しい問題でもある
• 最終回：ピーターの法則とBig-Fish-Little-Pond Effectから学ぶキャリア形成【キャリア形成シリーズ】
  • 「自分の」幸福感は家庭を持つと自分だけで閉じれなくなるから難しい
• Platform Engineering Maturity Modelってなに？
  • このモデルを用いながら役員と対話してみるのも良さそう
• 流れ橋マインドで生きる｜人生100年時代をずっと学ぶための、とても簡単なたった一つの答え
  • 新しい考えを否定せず、今の自分とは異なるけどそういう考え方もあるんだねって感じでいることを「ほー」って表現しているのかなと思う
• 「やりたいことが見つからないあなたへ」心のモヤモヤを解消する6つのヒント
  • 自分の場合はやりたい事と、そうでない事が割と明確で、その中でもやりたい事が沢山ありすぎて困っているのが現状
  • まずは上司に相談するところからやってみる
• なぜエンジニアがお客様の現場に訪問する必要があるのか
  • アジャイル開発ではこういったお客様のことを良く知る事と、お客様自身に協力してもらう事でより良いプロダクトを作れるんだなという事がわかる記事だった
• 生成AIに課金するのって意味あるの？
  • ChatGPTの無料版が優秀なのと、Geminiの有料版がメリットが大きいとのことで、メインで使うAIをGeminiに乗り換えようかと思った
• 橋渡し役としてのマネージャーの役割
  • おそらく今の自分に求められているのは組織内部の橋渡し役だと思うので、関係性作りにも力を入れていきたい
• 初学者向けリファクタリング術
  • 部分的にメソッドやクラスを分けることはあっても、ついつい抽象度が異なる実装をしてしまうので、メソッド分割も気を付けながらやっていく必要がありそう
• 『Platform Engineering (O’Reilly)』輪読会レポート第二弾 ～ 第8章から第14章で語られるプラットフォームチーム設計と、組織に受け入れられるプラットフォームとは
  • プラットフォームチームは信頼関係を築き、愛される事が大切なことや、陰のプラットフォームをやめさせるべきではないといったアンチパターンなど、学ぶべき事が多いので、将来そういった役割を作っていきたい身としてはしっかり学んでいきたい
  • セキュリティもプラットフォームも直接的利益を生み出さないという点では共通していて、自分自身がそういった領域に興味を持ってしまっているんだなと思った
  • しばしば思うが、こういう超絶長い記事は章ごとに分割して投稿して欲しいw
  • 一気に全部見切れないから飛び飛びでみるけど、一度中断すると再度開いた時にリロードされて、続きの場所を探すのが大変
• プロジェクトで境界づけられたモジュールから、コンテキストで境界づけられたモジュールへ
  • 少しずつ層を分けて、Modelの直アクセスではなくEntityやRepositryを作るなど、責務の分離をしながらリアーキテクトしていく参考になる
• 部下をワクワクさせたい！！~できるリーダーのコツ~
  • 任せたいとは思っていても、やりたい人って聞くと絶対に手が上がらない…
  • 先に誰に任せるかを決めて詳細を話していく必要があるのだろうなと思う
  • あと致命的なものをしっかり確認してチャレンジしていくのはありかもしれない
• GitLabに学ぶ パフォーマンスを最大化させるドキュメンテーション技術の紹介
  • 以前GitLabに学ぶ世界最先端のリモート組織のつくりかたという本を読んだけど、組織レベルで取り組むのであればとても参考になる本だと思ったが、個人で取り組むには難しいと思った記憶がある
  • ここで紹介されている本は個人でも十分活かせる内容な雰囲気を感じたので、一度読んでみようと思う
• 人格を否定せず行動を変える！リーダーのフィードバック術
  • 指導する時は「行動・能力」に焦点を当てるは比較的意識できていると思うけど、褒める時は「存在」まで承認するはあまりできていない気がするので意識していきたい
• ターミナル派待望の GitHub Copilot CLI 使い方まとめ
  • 当社ではGithub Copilotは有料版を利用しているので、CLIもメインで使っていけたらと思った
  • Claude CodeやGemini CLIとの性能比較があれば嬉しいなとも思う
• AI時代にVimを学ぶ意味 - Vim初心者が過ごした夏の記録
  • 最近はVSCodeやCursorが主流になっていて、なかなかVimやNeoVimの人権が無くなってきているけど、こうやってVimの良さを実感してくれる人がいると少し嬉しいw
• プロジェクトにおける「全体像の可視化」の重要性
  • しっかり研修期間を設けられる企業ならではの学びだなと思った
• 心理的安全性から具体的な改善アクションまでを行う、一開発チームの振り返り方法を公開
  • 当社では振り返りはKPTでやっているけど、またには異なるフレームワークを試してみても良いかもしれない
• 【エンジニアの日常】これが私のご褒美ランチ！〜日々の開発を支えるおすすめの店〜 Part1
  • 大崎の天麩羅は今度行ってみる
• [問いかけがチームの思考を整える](https://blog.ingage.jp/entry/2025/10/08/111046
  • コーチングにおいてコーチの意見は不要という意識を持って動けるようになるようにする
  • 認識の齟齬は減らすためにメモは受けてに作らせてから確認するのを試してみようと思う
• 【AWS構成設計】ElastiCacheを含む3パターンのWebサイト構成を設計してみた
  • Redis利用を検討できるなら、RDSのレプリカ利用も検討しても良いのかと思ったがどうなんだろうか？
• フルリモートでも“超”自律を加速させるコミュニケーション運用術
  • 雑談会を明確に設けたり、オープンなチャットのやり取りを推奨している事を明確にしていたりと、内容とそうだけど、全体に周知しながら実施していくスタイルは見習っていきたい
• FindyTeam+（Four Keys）で見る、開発プロセス改善の確かな成果
  • PRを小さくというのが意外と難敵で、Feature Flagを使えばある程度は実現できるということは分かりながらも、影響範囲が広範囲になるとそれを使うのも手間でレビュワーに負荷をかけてしまう傾向にあるので、もっとうまく細分化できる方法を探していきたい
• 2025年版 エンジニアのためのAI連携チートシート + カスタムスクリプト集
  • 人がやる部分の切り分けと、チームで継続的に改善していく姿勢が大事
• 気づきが「実は本に書いてあった」となるメモ術
  • 読書が好きな人は試してみると良さそうかも
• 短編: Vibe Codingについて個人的な考えを述べてみる
  • 成長機会という面や、AIを使える使えないという組織的な問題、そして金銭的コストの問題などは存在するが、これからAIを使うことが当たり前の世代が多くなると、過渡期に悩んだ中途半端な世代よりも効率的な運用ができるかもと思うので、ジュニアやこれからエンジニアを目指す世代にはもっと積極的に利用してもらえたらとも思う
• フルリモートワークの長所と短所〜北海道より愛を込めて
  • フルリモート・フル出社・ハイブリッドどれをとってもメリット・デメリットは存在すると思うけど、そこにある程度の自由があればメリットを最大化させることもできそう
  • ただ個人での自由なのかチームでの自由なのかで享受できるメリットに差は生まれそうだけど
• 読解力を分解してちゃんと文章を読む。 - じゃあ、おうちで学べる
  • 認知バイアス・わかったつもりになる。めちゃくちゃわかる。こういった壁を乗り越えられるようにしなければと常々思うが、最近はAIがこのバイアスを否定してくれることも多いので助かっている
  • 読解力が衰えた結果長文が読めなくなると言っていたので、それを鍛えるためにあえて長文記事にしたのだろうか？？w
• LLMが突然賢くなった理由を紐解く - 5つの革新とその影響度
  • 様々な研究が重なり合って今のAIの進化があると思うと、世の中の研究というのは本当に面白い
• [スペック駆動開発] 品質を担保した AI 駆動開発セッション受講メモ #JAZUG
  • はじめに出てきた「AI駆動開発はマイクロサービスに向いててモノリスには向かない」が実感としてもそうなので、今後の社内の開発スタイルについて考え直すよい記事だった
• 【コピペOK】AIエージェントで良いコードを書く！誰でも使える品質向上ルールの設定方法
  • 一から自分で作るのは大変なので、こういったとりあえず使えるテンプレートを用意してもらえるのはありがたい
  • ここから自分なりの拡張を繰り返せば、各々の環境にカスタマイズされたものが出来上がっていくだろう
• 「散歩は最高のデバッグ時間」──エンジニアの集中力・作業効率・睡眠が劇的に改善する理由
  • 真夏は散歩するにも危険が伴うので避けていたが、最近は涼しくなったので整体の帰りは散歩するようにしている
  • 個人的には昼寝と整体はパフォーマンスがめちゃくちゃ向上すると思っている
• 良いテストとはなんだろう？ - （good code, bad codeより）
  • 既存のテスタブルではないコードをテストするのにはある程度のリファクタリングが伴うでコストが高いが、今後書いていくコードに関してはしっかりテストをかけるようにしていきたい
• コマンド紹介シリーズ：chafa
  • サンプル画像がリンク切れな上に brew でインストールできない系のコマンドか…
  • 気になって調べてみたけど微妙すぎない？ｗ
• ターミナルがダサいとモテない。bash command-line framework rerun編
  • いまは Git でスクリプトを管理して独自の方法を取っているけど、こういったもので管理するのは一つかもしれないと思った
• 人に興味が持てない人へ ― 会話を続けるシンプルな方法
  • 個人的には具体的な目的があれば会話は続くと思うけど、大抵は「仲良くなる」「場を繋ぐ」みたいな抽象的な目的しか作れず、根底に「興味がない」があるから何を話せば良いのかすらわからず、更には相手も同タイプだと話しかけても話が広がらないとなることで、雑談の苦手意識が加速するのではと思った
• その「当たり前」、本当に当たり前ですか？
  • 「自分の当たり前は、相手の当たり前とは限らない」は日常生活においても非常に納得できる部分だけど、ついつい忘れて会話してしまうことがあるから気をつけなければと思った
• 生成AIが先？開発生産性が先？生成AI時代を走り抜けるための最初の一手
  • 人間の開発生産性を上げることが生成AIでの生産性に向上すると言われて、なぜ新規プロダクトは生成AIが使いやすく、既存のレガシーなプロダクトは使いづらいのか理解できた気がする