2025-05-27 共有記事ログ

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

# マネジメント系
## [ストーリーポイントの「なんとなく」から脱却する](https://qiita.com/tetsuya-ito-hulft/items/69490538720793d28fe5)
スクラムで利用されているストーリーポイントについての解説記事です
ストーリーポイントは規模感を示す指標と認識していますが、この規模感をどのように算出するべきかを解説してくれています
当社の場合ついついマネジメント層から求められるのが時間なので、時間を基準に設定されがちですが、担当者によってブレる時間ではなく、属人的ではないものを基準とする例が紹介されていましたので共有いたします！
というか理想的な設計やプログラムになっていて、仕様は誰が見ても明確で他の解釈のしようがなく、実装対象が変更数十行くらいにおさまるスコープでもない限り、時間の見積もりが厳密に出せるわけないでしょって思ってますw

# セキュリティ系
## [CTEMがなぜ今重要なのか、そしてどのように企業のセキュリティを強化するのかを、超入門レベルでわかりやすく解説します。](https://techblog.ap-com.co.jp/entry/2025/05/21/100000)
セキュリティのフレームワークであるCTEMについての記事です
実際の経営層の考えはわかりませんが、末端社員として感じるのはセキュリティリスクを比較的許容しているのかな？と思うところは多々あります(会社全体で何かしらの対策はしているけれど、自分が知らないだけの可能性もありますが)
そんな中でも、特に重要視するべきセキュリティリスクの洗い出しと対策をするために、その重要視するべき内容の洗い出しに使えるフレームワークだと思いますので、軽く知識だけでも持っていると良いかと思い、共有いたします！

## [安全なMCPへの第一歩 : Authorization の仕様を理解する](https://qiita.com/icoxfog417/items/ef2c3382056968032dd5)
MCPサーバが認証認可の仕組みを利用できるようになったため、その仕組についての解説記事です！
内容を理解する必要はありませんが、AIを使う際に今までガバガバだったセキュリティの部分が整いつつあるようです
今後はAIを利用する際も、当たり前にセキュリティが考えられるようになっていき、安全性が担保されていくようになると思います
現状当社では開発業務以外ではAIがそこまで活用できていないかと思いますが、今後AI利用時・設定時に少しでもセキュリティのことを意識してもらいたく、共有いたします！

# その他
## [「相手の顔色を気にしすぎてしまう…」から抜け出す会話のコツ](https://note.shiftinc.jp/n/n13d6dc0a9bc4)
自分が誰かに向けて話しているときに、その人たちの顔色を伺いすぎる人たちに向けて、どう考えて行くのが良いのかを解説してくれています！
みんな相手のちょっとした言動は気になるものだと思います。その言動から勝手な思い込みで凹むこともあると思いますが、現実は自分が凹む要素はなかったりするものです
そんな時にこの記事にあるように、自分の感情を言葉にして、自分の心を守りながら、より良い関係を築けるようになると良いですね！

## [見えないチャンスを見つけて活かす方法](https://dev.classmethod.jp/articles/taking-advantage-of-opportunities/)
様々な機会（チャンス）はどんなものがあるのか、どのように発見するのか、どのように掴み取るのか
そういったことを紹介している記事です
この記事を見ていると、やっぱり機会は人と人との関わり合いが強く出るのだなと感じました
権力者と関わり合いを持ち、良い関係を築きながら意見を述べることで、信頼を得ることで様々な機会を得ることができるのだと思います！
逆に受け身一辺倒だとその機会を得る事自体が難しくなるのだろうなと感じましたので、皆様のキャリアの一助となりますよう、この記事を共有いたします！

# To Intern
## [エンジニア向けオフラインイベントの楽しみ方](https://tech.layerx.co.jp/entry/2025/05/13/131431)
勉強会などのオフラインイベントがどういうもので、懇親会などでどのように振る舞えば良いかを教えてくれている記事です
勉強会の内容には興味があるけど、知らない人と話すのが苦手という人は多いのではないかと思います
後半ではそう言った人のために、どのように振る舞えば良いかを解説してくれておりますので、興味があれば目を通してみてください！
そしてオフラインイベントで繋がるためのSNSを作るのもありかもしれませんね！

# 共有するほどではないけど興味があったもので読んだもの
* [プログラマーの時間を無駄にする7つの"スマート"な作り話](https://qiita.com/RepKuririn/items/1d8a649b0bd9cdbdb034)
    * マイクロアーキテクチャはモノリシックな構造でも依存関係を粗に保てるなら良いかもしれない。逆に密にしか設計できないないなら、初めから物理的に分離して実現可能性を考えさせた方が良いかも
* [（ほぼ）同じスキルセットでも働き方が劇的に変わった1年を振り返る](https://qiita.com/ebichan_88/items/3be5e7319ed029385ab4)
    * times文化は少し良いかもと思った
* [curl使い方についてまとめてみた](https://zenn.dev/akasan/articles/4248554eb4797b)
    * curl は色々なプロトコルに対応していることは知っていたけど、HTTP(S)意外使ったことないな…
* [CTO室が描くエンジニア部の未来とは？ CTO室のミッションは、自走できるチームを作ること](https://note.com/canly/n/n27b634b2c98c)
    * 特定チームの課題解決方法を全社に展開できる仕組みづくりを行っていく方が良いのだろうなと思った
* [標準サポート期間が終了した RDS インスタンスを、延長サポート無しで使い続けることはできますか？](https://dev.classmethod.jp/articles/tsnote-rds-Can-I-continue-to-use-an-RDS-instance-that-has-reached-the-end-of-its-standard-support-period-without-extended-support/)
    * 分かってはいたけどやっぱりダメなんだね
* [通勤中に”ゆるく”勉強しよう](https://ramble.impl.co.jp/8589/)
    * 自分は Audible で聞いているけど、PodCast というのも選択肢の一つかもしれない
* [キャリアは偶発？計画？：IT企業6社を経た足跡](https://tech-blog.rakus.co.jp/entry/20250519/pdm_career)
    * セキュリティに携わりたいというキャリアを未だに諦められずにいるけど、キャリアは偶発的なものだろうなと自分も思う
* [事業会社でマルウェア解析環境を構築 → 実際にフィッシング検体を解析してみた](https://zenn.dev/wn_engineering/articles/e0f0e95d12053d)
    * 先日大学の授業でやった内容だが、講義内では攻撃者に解析していることを悟らせないために極力アクセスはしないようにすると聞いていたが、この人は結構がっつりアクセスする前提で解析しているよう
* [動的にSQLを生成する複雑なロジックに立ち向かい、開発スピードを向上させた話](https://tech.plaid.co.jp/complex_logic_to_dynamically_generate_sql)
    * 新規メンバーが簡単にキャッチアップできるようになったのは素晴らしいことだと思うので、自分たちもそうなっていけるように努力が必要だと思った
* [Web エンジニアなら知っておきたいシステム開発におけるドキュメント](https://engineers.fenrir-inc.com/entry/2025/05/20/161623)
    * ドキュメントの重要性は重々理解しているが、その重要性を最も理解するべきは、コストを払う経営者や工数を管理するマネジメント層なのかもしれないと思った
* [テスト漏れによる責任追及を回避するための自己防衛術（テストケース算出手法の紹介とtips）](https://qiita.com/yu-saito-ceres/items/b40b0ddbdd882c90a5e6)
    * 企業で開発しているのであれば、少なからず責任追及から逃れる証跡の一面は末端の人間には確実にあるだろうなと思った
    * ファジングテストは候補には入らないのかな？
* [新人教育を怠ることは会社の成長を止めるから、全力で研修を作成した話（一部資料公開）](https://qiita.com/t-iino/items/1088c82bf111c2a2b5a1)
    * 新卒がたくさんいる会社であればしっかり研修できる土台を作ることに意味はありそう
* [チーム内リーダーのすすめ](https://qiita.com/kikng0526/items/466fb7f67e7aba2ae5e2)
    * リーダーという立場でプレイングマネージャーとしての役割を求められていないなら、この立ち回りは良さそう
* [元ヤフーエンジニア社長がオススメする、人生に影響を受けた本4選  〜「成長したいすべての人」に向けて〜](https://qiita.com/ryoheiiwamoto/items/b334608674423f1591a8)
    * 今の経験を大事にする。面倒くさいが最大の敵。どうなりたいかに集中する。行動と信念が人と仕事を動かす。どれも良い言葉だと思った
* [ハッキングの始め方　②ハッキングを学ぶためのロードマップ](https://qiita.com/hk4zushi0701/items/a1e976952d8a3acb4c71)
    * Kali Linuxの環境はとりあえず構築してみようと思う
* [命名レビューでトラウマ植え付けられてそうな新人に贈る処方箋](https://qiita.com/buta_karubi/items/d3ce3d0aa378f74b41b2)
    * 目的指向での命名とまでは行かないが、今まで勉強会でやっていた内容の一部を簡単に説明してくれている
* [レビュアーの負荷を軽減して、コードの品質をチームで高めるためのプルリクエストテンプレート活用](https://zenn.dev/chot/articles/fc877bc0214ac4)
    * 以前チームで相談してテンプレートを作ったけど、必要な情報に合意があると、PR作る人も迷わずに済むし、レビュワーも楽になるしで、やってよかったと思った
* [【エンジニアの日常】エンジニア達の人生を変えた一冊 Part4](https://tech.findy.co.jp/entry/2025/05/22/070000)
    * 次の勉強会の題材に良さそう
* [githubのヒストリーを楽にきれいに保つためにしていること](https://qiita.com/tetsuya-ito-hulft/items/b6d81cc41a9a90805dff)
    * Github Actionsとブランチルールの参考になりそう