概要
現職の開発部のメンバーに共有した記事のログ
技術系
新しい curl コマンドの使い方 完全ガイド（2025年版）
curl の説明記事です
全てを読む必要はありませんが(というか全てちゃんと理解しながら読むと1時間くらいかかる)良く使うコマンドなので、ざっと流し読みくらいはしても良いかと思い共有いたします！
リレーショナルデータベース設計の完全ガイド
RDBに関する基礎知識の記事です
個人的な考えとしては、基本的には正規化は徹底的に行うべきだと思っています
今楽だけどでサボると、バグが生まれてからの対処はかなり大変です
もちろんパフォーマンスとして問題が発生したら非正規化も検討する必要はありますが、まずは不整合が物理的に起こらないようにする方が良いと考えます！
そして非正規化する場合でも基本は一対一関係のものにとどめるべきかと思います
indexでの調整が不可能になってから一対一以外の非正規化を考えた方が良いと思います
また複数の情報をまとめてRDBのカラムに入れるのは必ず避けるべきだと思います
その対応が必要になるのであればNoSQLを検討する方が良いでしょう！
検索結果に表示させない技術 robots.txt と X-Robots-Tag を正しく組み合わせよう
検索結果の制御に関する記事です
自分はX-Robots-TagといつHTTPヘッダは知らなかったので勉強になりました
各プロダクトで方針は様々かと思いますが、必要に応じて使い分けれるように共有いたします！
マネジメント系
部署間の壁を乗り越える！企画を通じた合意形成のポイント
複数のクラスタ間でうまく合意を取るためのポイントを5つあげています
この中でも特に、相手のメリットを提示することと、根回しをすること
個人的には特に重要なことのように思えました
開発部の意見は部外からみると共通認識が無かったり、未知の領域だったりするため、あらかじめお互いにとってのメリットを共有して納得してもらうことが、共にプロダクトを作り上げる中で必要なことなのかもしれないと思い、共有いたします！
セキュリティ系
EventBridgeとStep Functionsを使ってSecurity Hubの結果をBacklogに自動起票する構成を考えてみた
AWSのSecurity Hubの通知を自動起票する仕組みの構築に関する記事です
構築手法は置いておいて、このように検知したものを正しく運用するための管理手法は必要になってくると思います
検知系は導入して満足することが多いですが、それでは意味がないので、どのように運用していくかも併せて議論していく必要がありそうですね！
その他
効率的にアウトプットするために実践してること
アウトプットするための取り組みについての記事です
個人的にはPRを小さくすることは双方にとってメリットのあることだと思います
一つの課題が大きくなりがちな当社ですが、それを可能な限り細分化して、意味のある単位の子課題として用意することで開発効率が上がるのではと思います
そのためにはレビュワーもレビューを溜め込まないようにする必要があるとは思います！
【QAエンジニア考案】スクラムチームの品質保証を強化する「不安ニングポーカー」
テストに関する不安を数値化するアプローチに関する記事です！
自分たちも開発していく中で、この設計や書き方で問題ないのかな？
ここの影響範囲はこれで大丈夫かな？
これどうやってテストしよう？
みたいなたくさんの不安を抱えていると思います
これらを数値化することで不安解消してから進むのか、先にある程度解消してから進むのか、外部に相談が必要なのかなど、指針となりそうなので、こういった考え方もあるのだと思い、共有いたします！
To プロダクトチーム
マネージャー全員でマネジメントポリシーを作りました
共有できる目標、共通言語として、マネジメントポリシーを作成した経緯と運用についての記事です
『チーム一丸となってパフォーマンスを高めていくためには「チームのあるべき姿」や「チームの目標」を共有することが鍵になる』という言葉がとても自分には刺さりましたので共有いたします！
この記事ではマネージャー陣のはなしとなっておりますが、これはプロダクトチームでも同じことが言えるのでは無いでしょうか？
あるべき姿や目標を言語化した上で共通認識を持ち、行動に迷った時に選ぶべき道の指針となるようにできると良さそうです！
MTGで一度伝えたら終わりみたいになると希薄になっていくので、指針がぶれないように、言語化した内容をいつでも目につくところに残せると良さそうです！
共有するほどではないけど興味があったもので読んだもの
-
Webアプリ開発の変遷：1995年頃～2023年までの手動開発、2024年以降のAI駆動開発の普及（2025年2月）
- AIによってエンジニアの在り方が変わるのは間違い無いと思う
- あとはAIを忌避しないでうまく付き合っていく必要があるだろう
-
低レイヤー技術を教えるにあたって Part 1: 用語集
- たまに聞かない言葉が出てくるから勉強になった
-
エンジニアリーダーとして使っているAIツール群を紹介：2025年02月
- AI関係はまだまだコストが高いのが、個人で使うのにはネックだと思う
-
チームがうまくいっていない時にとる泥臭いリーダーシップ
- 少しずつステップアップしていくというかんがえは大事だと思う。一気に理想に近づくにはそれ相応のコストがかかるから
- 失敗をして改善できる環境というのは良いものだと思う
-
PSIRTを立ち上げました！プロダクトセキュリティを組織的に強化する仕組みづくりに向けて
- PSIRTにコストを割ける組織が羨ましい。セキュリティの担保を全社的に行えるのは素晴らしいと思った
-
コミュニケーションにおけるコンテキスト共有とその種類
- 様々なコンテキストが必要な中で、必要最低限を見極めるのは難しそうだけど、足りないより多い方が良いと思うので、しっかり伝わるようにコミュニケーションをとっていきたい
-
「徹底的にパクる」で開発生産性を最大化！他社の知見を活かす方法 - ACES エンジニアブログ
- Findyの開発生産性向上記事は自分もよく読むので参考になるけど、確かに自分たちの環境に合っているのかは考えたことがなかったから、改めて会社として、開発部として考える必要があるかもしれない
-
「それ、地雷？」相手を傷つける言葉を避けるには
- 誠実さは大事ですね。それ以上に謝る時は自分を守ろうとしない事が大切なのかもと思った
-
教育×開発×PMO 新しい組織づくりに挑戦する仲間を求む！
- 規模が大きくなるとこういう部署にも価値が出てきそう
-
GitHub Pull Request のブランチを可視化する地味便利コマンドを公開しました
- branchの変な生え方チェックは良さそうw