2025-04-24 共有記事ログ

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

# 技術系
## [【JavaScript】MDNが推奨する最強の書き方](https://qiita.com/TechForGood/items/0cc492ea3f8f3d6638e7)
JSでの書き方の参考例を示した記事です！
基本的に自分達はJS Standard に従っているので今から帰る必要はありませんが、こう言ったものを規約とするのも一つの選択肢としてあると思い、共有いたします！

## [「読ませる力」がエンジニアの価値を上げる](https://ramble.impl.co.jp/8568/)
可読性についての記事です
実例に関しては勉強会でやった内容なのでみる必要は無いですが、「自分ならわかる」は未来の自分すら裏切るというのは肝に銘じておくべきだと思い共有いたします！
理想はシンタックスは全て理解しているけど、プロダクトのことは何も知らない中学生がストレスなく読めるコードかもしれないなと思います！

## [Webエンジニアなら知っておきたいレンダリング方式4選](https://engineers.fenrir-inc.com/entry/2025/04/15/141038)
現在主に使われているレンダリング方式についての記事です
SSRだからといってフロントとバックエンドが分離できないことはないという前提のもと、単純にレンダリングに焦点を合わせた際のメリットデメリットが述べられていますので、今後の開発の参考になるのではと思います！

## [オーバーエンジニアリングを考える](https://engineer.retty.me/entry/overengineering)
オーバーエンジニアリングについての記事です
これは今必要ないものは作らないという考え方に似ています
設計に関しても必要以上に抽象化、汎用化、共通化はしない方がトータルのコストは低く済むという内容でした
自分もパブリックAPIの汎用化などを考えてしまっていますが、汎用化が必要になるまでは汎用化しないように気を付けたいと思います
ただし汎用化されていないのに既存のAPIを無理矢理ハックしないようには気を付けなければとも思います


# セキュリティ系
## [継続的な脆弱性管理と改善への取り組みのはなし](https://techblog.hacomono.jp/entry/2025/04/15/110000)
脆弱性を管理するする方法と、どのようにして浸透させるかの記事です
まずは自分達のシステムがどれだけ危険かを把握する必要があります
把握した情報を可視化することで経営層への危険度を伝えると共に、エンジニアも対応を急がなければいけない状況になると思います
そして経営層が脆弱性対応を評価することでより安全なシステムの構築が行えるのではと思います

## [パッケージ管理方法を知る！〜依存関係アップグレードの詳細編〜](https://note.com/dev_onecareer/n/n30f0103c750c)
パッケージのアップグレードを行う際に実際にやるべき事と注意点に関する記事です
脆弱性が発見された場合は即座に対応する必要がありますが、対応後はバージョンを上げた事で問題なく動作していることを検証する必要があります
そういった作業の参考になるかと思い共有いたします！


# その他
## [自分流・ファシリテーション７ヶ条](https://tech.smarthr.jp/entry/2025/04/16/170143)
ファシリテーションを行う際に気をつけると良い内容の紹介です
自分は時間管理を意識しながらも中々うまくできなかったり、平等に意見や発言を求めるのが難しかったりします
皆さんもそういった得手不得手があると思いますが、スムーズな進行のために役立つかと思いますので是非目を通してみてください！


# 共有するほどではないけど興味があったもので読んだもの
* [PG（プログラマー）とSE（システムエンジニア）の違いって？ ](https://qiita.com/ryoheiiwamoto/items/73f74b76a23236ff9d5e)
    * 役割の違いでしかないのに上流工程を担う人の方が偉い的な考え方に読み取れる
    * PGとしてのスペシャリストというキャリアは日本の経営者は考えないのだろうか？
* [ディレクトリ構成の基本原則](https://sreake.com/blog/directory-structure-good-practice/)
    * クラス分離と同じ考え方
* [セーフィーのサイバーセキュリティ戦略の作り方](https://engineers.safie.link/entry/cyber_security_strategy)
    * セキュリティを事業戦略上の重要な差別化要素とするという考え方はとても良いと思った
    * 経営者にこそみてもらいたいかも
* [GitHubの「CODEOWNERS」で効率的なコードレビューを実現する](https://dev.classmethod.jp/articles/github-codeowners/)
    * モノレポ構造を取っていると活躍しそう
* [防御力の高い技術ブログを書こう - じゃあ、おうちで学べる](https://syu-m-5151.hatenablog.com/entry/2025/04/15/101247)
    * 多くの人の目に留まり、批判が出るようになってから考えても良さそう。ほとんどの記事は批判されることすら無いのだから
* [「なんでできないの？」と感じたときに、そっと読みたい話](https://note.shiftinc.jp/n/na1b8d0562ae3)
    * 他人に期待しすぎない事がストレスレスの第一歩かも知れない
* [技術ブログに書けることがないわけない！](https://zenn.dev/coconala/articles/0f2f02a8a7bea2)
    * その気になればいくらでもかけることはありそう。ただし企業ブログなら書く時間を業務時間内に確保できるならだけど
* [「悪いのは自分じゃない」と思ったとき、何が起きているのか？](https://note.shiftinc.jp/n/n166bd1498edf)
    * この自己奉仕バイアスは自分自身気を付けていてもすぐにこの思考になってしまって嫌になる
* [PHPエンジニア実態調査を行いました！](https://creators-note.chatwork.com/entry/2025/04/17/100804)
    * キャリアパスのアンケートは面白い
* [データ移行のテストに私たちはどう向き合ったか](https://tech.legalforce.co.jp/entry/2025/04/17/151712)
    * データベースを単体でテストする考え方もあるのか
* [【OCI】初学者向け学習コンテンツの紹介](https://techblog.ap-com.co.jp/entry/2025/04/17/184838)
    * 仕事で必要になったら改めてみてみるのもありかも
* [エンジニア向け制度をアップデートしました](https://zenn.dev/moshjp/articles/24a23b7c664d8a)
    * アウトプットすると特典がある精度は面白い
* [部署、職種を越えた新たな社内コミュニケーションの取り組み〜PRONIでOSTやってみた件〜](https://note.com/m_shimokawa/n/n4aaa96af7840)
    * 任意参加なのに人があつまったことがすごいという印象
* [おすすめgitコマンド](https://zenn.dev/akasan/articles/17fdafb60e39fc)
    * サードパーティ製のgitコマンドの紹介。git-openは使えるかも？
* ["レッテル貼り"があなたの人間関係を壊す前に](https://note.shiftinc.jp/n/nc491db0d6161)
    * 自分にも他人にもやりがちなことな気がする。特に一度思い込むと意識的に変えないとレッテルが定着してしまう
* [セキュリティの未来を創る2つの技術戦略の柱](https://zenn.dev/securenavi_tech/articles/8828df088e66b0)
    * セキュリティファーストで「セキュリティに取り組めば、売上が上がる世界」という考え方が素晴らしい
* [DB負荷改善の道のり：技術的負債解消から始まった挑戦](https://zenn.dev/wn_engineering/articles/1b0f2b7f2d53f6)
    * 読み込みしか発生しない処理は Read レプリカをちゃんと利用するようにしたほうが良いかも。ロックの影響も回避できるだろうし