2024-07-02 共有記事ログ

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


# 技術系
## [良いコード悪いコードで学んだモデリングについて](https://lab.sonicmoov.com/development/learn-modeling/)
単一のエンティティでも複数の目的で利用することがあるので、単一の目的となるようにモデルを作成したほうが良いというお話です
今まで FuelPHP や SQLBoiler で Model 管理をする場合は Table と Model を 1対1 で考えていましたが
場合によっては Table : Model = 1 : 多 で考えても良いのかもと思いました

## [デザイナー間での桃色の共有化と改善による成果](https://tech.tabechoku.com/entry/2024/06/28/173000)
どの色を桃色とするのかを決めた理由などについて説明しています
各プロダクトでも全社的にでも良いですが、色の共通認識を作れると開発は捗りそうです

## [Software Design 2024年6月号 連載「レガシーシステム攻略のプロセス」第2回 ZOZOTOWNリプレイスにおけるIaCやCI/CD関連の取り組み](https://techblog.zozo.com/entry/software-design-202406)
SRE として取り組んだことについて説明しています
CI/CD で利用しているプラットフォームごとに、そしてその中で環境ごとに設定を Directory で切ることで変更の監視対象を絞れるというのは取り入れても良さそうだと思いました
まずは IaC 化から着手が必要ですが…

## [巨大なデータ負債を作らないための取り組み](https://tech.high-link.co.jp/entry/data-debt-attempt)
データ負債をつくらないために、積極的な見直しと Design Doc の作成をしているというお話です
現在時間的制約にとらわれて何もできていませんが、こういったことも順番に着手する必要がありそうです


# マネジメント系
## [開発生産性指標を向上させるためにやってはいけないアンチパターン](https://tech.findy.co.jp/entry/2024/06/24/090000)
開発生産性を定量的に計測するうえで数値目標のみを追ってはいけないという話です
自分たちも開発生産性に着目して、コストを掛けれるタイミングを見計らいながら取り組んでいきたいですね

## [個人/チームの不確実性に、目標設定を活用して立ち向かう](https://studist.tech/my-first-experience-setting-goal-as-a-manager-0378d7fe9706)
不確実性の高いチームでの目標設定の考え方について実例を元に取り組みを説明しています
① メンバーへの期待 (ここは会社? CTO?)
② メンバーの意思 (個別に 1on1 などで把握する必要がある)
③ 各メンバーのグレードで期待される振る舞い (グレードが明確になったので、どこに何を求めるかの定義が必要)
これらは前提として必要になってくるが、その上で不確実な目標設定の中で目指すべき目標が異なった場合も
変化を怖がらず前向きに捉えることができるようにできると良いのかもしれませんね

## [エンジニアの評価制度を徹底解説！課題・評価基準・構築方法を紹介](https://souken.shikigaku.jp/30610/)
紹介していただいた記事ですが、エンジニアの評価制度の作り方の概念の紹介です
特に評価基準と評価項目という部分でどういった分野のエンジニアなのかを理解したうえで基準を設ける必要がありそうだと感じました

## [「なぜ」と聞かずに理由を引き出す！「詰めてる」感を減らす言い換えテク](https://qiita.com/ynmc0214/items/068afccca9693baf298d)
なぜ？以外の4W1Hを使うことで詰めてる感が軽減できるというお話です
他責にできる(ような気がする)だけで話しやすさは上がりそうだなと思いました


# その他
## [疲れと上手に付き合おう！](https://studist.tech/health-hack-sleep-b1ed2c4cd04b)
疲れが取れるように良い睡眠をとりましょうというお話です

## [リモートワークでチーム生産性を上げるための工夫 3選](https://toranoana-lab.hatenablog.com/entry/2024/06/27/100000)
リモートワークで気をつけていることを3つ紹介しています
個人的には通話可能タイミングの事前アンケートはとっても良いのかもと思いました


# 共有するほどではないけど興味があったもので読んだもの
* [奥野さんと社員のリファクタリング部屋 -ディレクトリの名付け方](https://tech.toreta.in/entry/2024/06/24/奥野さんと社員のリファクタリング部屋_-ディレクト)
* [Google Chrome のデベロッパーツール【Network編】について調べてみました。](https://tech.iimon.co.jp/entry/2024/06/24/102618)
* [エンジニア採用担当者の1日💻フルリモートワークの実態](https://toranoana-lab.hatenablog.com/entry/2024/06/24/120000)
* [ロジカルシンキングで問題解決をしよう！](https://note.shiftinc.jp/n/ne37ab6338ed6)
* [メンバー全員が開発リードになれる、「エピック主管」という仕組み](https://engineering.visional.inc/blog/572/epic-lead/)
* [読まないと後悔する技術書30選](https://qiita.com/Sicut_study/items/0b27dca18af96c80bec8)
* [リモートワークで気をつけているチャットのささやかな文末表現](https://toranoana-lab.hatenablog.com/entry/2024/06/25/120000)
* [Webサービスにおけるメモリリークの原因調査と解決](https://blog.kinto-technologies.com/posts/2024-06-25-Webサービスにおけるメモリリークの原因調査と解決/)
* [SRE(Site Reliability Engineering)とは？： Hope is not a strategy](https://zenn.dev/gmomedia/articles/b319fb4639810d)
* [AWS Config ルールの自動修復を利用して一定期間未利用の IAM ユーザーを無効化してみた](https://dev.classmethod.jp/articles/automation-revoke-unused-iam-user-credentials/)
* [意識低い系エンジニアのための人生の変え方](https://tech.kikagaku.co.jp/entry/2024/06/26/090000)
* [Backlogをスクラム開発のタスク管理に最適化するためにした事](https://toranoana-lab.hatenablog.com/entry/2024/06/26/120000)
* [ネットワーク脅威を検知するXDR](https://techblog.ap-com.co.jp/entry/2024/06/26/151430)
* [書類選考における課題の傾向と対策](https://dev.classmethod.jp/articles/yield-of-recruiting-resume-selection/)
* [生成AI活用プロダクトのための継続的なセキュリティ担保](https://studist.tech/ai-security-74725850af84)
* [マクアケ開発の日常に密着！チーム内コミュニケーションの特徴とは？(前編)](https://note.com/dev_makuake/n/nc699ec0cc62b)
* [キーボードへのこだわりを聞いてみた ── 人生の1/3の時間は打鍵！](https://tech.smarthr.jp/entry/2024/06/27/165121)
* [Belong の開発生産性の取り組み](https://belonginc.dev/members/ttyfky/posts/belong-developer-productivity-2024)
* [『アジャイル開発の失敗率は268%も高い』のコメント欄が面白かったので紹介するよ](https://qiita.com/rana_kualu/items/eb308823193e9539f103)
* [元々は /usr は user の略に決まってるじゃん？ホームディレクトリを置く場所だったんだから](https://qiita.com/ko1nksm/items/0aeb7eaa2c2d64c1ddef)
* [【HTML】ボタン要素にdisabled属性をつけるのをやめませんか？](https://qiita.com/degudegu2510/items/319226d98e05a348b204)
* [「気づいた人がやるタスク」をなんとかするためにマネージャーが実施した3つの施策](https://toranoana-lab.hatenablog.com/entry/2024/06/28/120000)
* [インシデント発生時に電源を入れたままにすべきか問題](https://qiita.com/log0417/items/6bd95bc5217a23fdaad3)
* [そのuseRef+useEffect、refコールバックのほうが良いかも？](https://qiita.com/uhyo/items/abacedd7d4b8370688c5)
* [自分のAWS環境について何でも教えてくれるエージェントが作れそう（Agents for Amazon Bedrock + Knowledge bases for Amazon Bedrock）](https://qiita.com/moritalous/items/65120fe3cc7404ab2d0f)
* [継承、誤って使っていませんか？](https://qiita.com/kom-0924/items/c9bd0fa3ff45fef85dee)
* [GPT-4oを超えた？ Claudeの最新モデル3.5が登場！ AWSのBedrockで早速使ってみた](https://qiita.com/minorun365/items/cd46235d5e446b1f41c5)
* [出来ないとヤバい！タイピング能力を鍛える](https://qiita.com/ryoheitakahashi/items/06d5fec2d35befce5f26)
* [「AWSが分かっていない」のではなく、コンピュータサイエンスが分かっていなかった](https://qiita.com/mkt_hanada/items/f04131b427f90796f8e8)
* [フルリモエンジニアのデスク環境!!劇的ビフォーアフター](https://tech.smarthr.jp/entry/2024/06/28/140000)