2024-12-23 共有記事ログ

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

# 技術系
## [ソフトウェアは捨てやすく作ろう](https://qiita.com/sanogemaru/items/40557c6db33dcec99cf1)
不要なコードを消しやすい設計をしましょうという記事です
デッドコードが増えると認知不可が上がるのは自明ではありますが
この記事でも書かれているようにデッドコードがあるからと言って結果に影響がないことで残り続けることもよくあります
でもそれでは今後の開発に支障がでてきますので、自分たちも積極的に捨てやすい設計を考えて
高凝集で低結合なプログラムとなるようにしていきましょう！

## [「リファクタリングの時間」を確保する技術](https://zenn.dev/loglass/articles/961e283e6fbe71)
リファクタリングの必要性と、エンジニア目線でどのようにリファクタリングの時間を捻出するかの記事です
当社も時間に追われて妥協したコードが沢山あったり、負の遺産によって改善が難しいコードが沢山あるかと思います
それでも少しづつ改善して行かなけれならないと思うので、日々のタスク、レビューで徐々にでも改善しながら、タスク見積もりでは改善時間も含む形で見積もるなど、小さな改善を積み上げていけたらと思います！


# セキュリティ系
## [AWSセキュリティ成熟度モデルで自社AWS環境を評価した話](https://zenn.dev/wn_engineering/articles/b5d0adcdd57c5f)
AWSが提供しているAWSセキュリティ成熟度モデルの紹介と、実施内容の紹介記事です
このようにセキュリティに関して定量的な判断ができるツールがあるので、まずは今を知る為に一度やってみる必要があると思いました！
こういったことを社内PJとしてできると、より安全な環境を全プロダクトで運用できるようになるのだと思います！


# その他
## [エンジニアの発信を資産化！技術広報が始めたこと - RAKSUL TechBlog](https://techblog.raksul.com/entry/2024/12/12/163426)
組織として発信する文化をどのように作っていっているかの記事です
個人的にはこういった支援があると嬉しく思いますが、無くても情報発信を積極的に行える組織文化になれたらと思いました！
一個人のこんな風であったら良いなを強制することはできませんが、少しでも共感してもらえたら嬉しく思います！

## [ペアプログラミングの体験がすごく良かったので布教したい - BASEプロダクトチームブログ](https://devblog.thebase.in/entry/2024/12/16/120000)
ペアプロの感想記事です
ペアプロをすることでお互いの思考方法や実装の引き出しが共有されるので今後の開発にプラスになる取り組みだと思います
特に新しい言語、新規参入のプロダクトなどに携わる際には一度取り入れてみても良いのかもしれないと思いました
また皆さんがどのように考えて実装しているのかも、とても気になります！

## [テスト項目作成の課題と改善への取り組み #HULFT - Qiita](https://qiita.com/Jun_Otake/items/f20d81f55329da94d1a4)
手動テストに関する記事です
当社も手動テストが主であるため、テスト手順書の改善につながるのではと思い共有いたします！
テストに関してはテスト管理ツールの導入も検討しながら改善できたらと思います！

## [インシデント対応を標準化するテンプレート活用事例](https://zenn.dev/loglass/articles/69d6aa4a5b5a8c)
インシデント対応のテンプレート作成の紹介記事です
エンジニア目線だけでは無く、サポート、営業目線でも必要な情報がそれぞれの視点であるかと思います
そのため村で認識を合わせながら、一度何が必要が、緊急時にどのように動くのかのテンプレートを作っていく必要があると思いました


# 共有するほどではないけど興味があったもので読んだもの
* [なんぞこれ #fffより 白い色（iPhone css hack, HDR）](https://qiita.com/set0gut1/items/be267df19c102e3a1ba0)
    * 超白という概念を初めて知ったw
* [X(Twitter)連携サービスを運営していたら警察から事情聴取された](https://qiita.com/schwarzewald/items/e5fa551119413ca6060d)
    * 外部連携結構怖いな…
* [【2024年版】エンジニア必見！！おすすめYouTubeチャンネルまとめ](https://qiita.com/K3n_to_n17/items/64b22179a12a5dd991df)
    * 英語のチャンネルはそのまま聞いて理解しているのだろうか？
    * https://www.youtube.com/@Computerphile 気にはなったが、英語が聞き取れない…
* [【図解解説】これ1本でGraphQLをマスターできるチュートリアル【React/TypeScript/Prisma】](https://qiita.com/Sicut_study/items/13c9f51c1f9683225e2e)
    * GraphQL が一切わからない人にとっては結構わかりやすいかも
    * 書き方的に JS や TS との相性も良さそうだなと思った
* [【2024最新版】個人開発で成功した 12 人のプロダクトとアドバイスを総まとめ](https://qiita.com/Michinosuke/items/1432589cb51ce3a9787e)
    * 自分が使いたいものを作る。これが一番だと思うが、それが収益につながるかどうかはまた別の問題
* [2024年末にデザインパターンについて考える](https://qiita.com/shibukawa/items/b89c0f857e07411951dc)
    * デザインパターンは確かに不要になったり存在意義が少ないものもあるかもしれない
    * しかしそのパターンがあるからこそ拡張容易性が上がったり、再利用性が向上したりするので、必要に応じて取り入れていくべきだし、知っていて損はないと思う
* [Webデザインの定番UIパーツ完全ガイド【用語解説＋実装付き】](https://qiita.com/nucoyuyu/items/49c3f9805d9c7e1f5c11)
    * UI に関する勉強になった
* [プログラミングスクールに200万円課金してつよつよエンジニア(笑)になったお話](https://qiita.com/torihazi/items/1ddf136a1d5800a814fe)
    * 全然関係ないけど、1行ごとに改行入っていると結構読みやすいｗ
* [Qiita を ECS 化しました](https://qiita.com/tomoasleep/items/e7f919c7b4d0f091d458)
    * 現時点で Docker 運用ができているのであれば ECS に乗せるのはありだなと思った
* [クラウドエンジニアになるために必要な技術 5選（ハンズオン付き）](https://qiita.com/hiyanger/items/ff84c71775f6bc36363b)
    * IaC以外はクラウドエンジニアでなくても必要な知識かも
* [ClaudeのMCPを徹底解説！ & gpt-4o+MCP+YouTube APIの動画推薦チャットAIも作る](https://qiita.com/sakasegawa/items/b091ad9931cea378099b)
    * AIが使えるツールを標準化するイメージかな？
* [エンジニア魂が刺激される！ITと社会を描いた名作映画](https://qiita.com/tsukasa_nakajo/items/8e3ff6f3428b0167b69c)
    * Winnyは結構気になっている
* [社内勉強会に人を集めるための tips](https://qiita.com/hoto17296/items/6db52ad902c75958ec38)
    * これは確かにって思った。勉強会以外にも活用できそう
* [リードエンジニアの仕事って何？](https://zenn.dev/sun_asterisk/articles/d78f1555d05ce0)
    * 緊急事態の対応以外はマネージャの仕事な気がしたけど、環境によってその辺りは変わるかな？
* [部署を横断した優先度判断の合意形成のつまづきと学び - コドモン Product Team Blog](https://tech.codmon.com/entry/20241211)
    * 優先順位の基準の明確化があれば、各ステークホルダーにとってメリットがある施策の優先度の納得感が上がりそう
    * 意思決定フローも明確になっているのも納得感が上がりそう
* [CATの導入効果はどこに出る？｜SHIFT Group 技術ブログ](https://note.shiftinc.jp/n/n9840d0fc7e82)
    * ここで挙げられている事例はピンとこなかった
    * テスト管理ツールは過去にどのようなテストをしたのかをリアルタイムで把握・更新ができることにメリットがありそうだと思う
* [プロダクトマネージャー向け野良ダッシュボードの活用方法 - 10X Product Blog](https://product.10x.co.jp/entry/noradashboard)
    * ダッシュボードでの可視化は良さそう
* [良いコードを書くための試行錯誤~リファクタリング~ #初心者 - Qiita](https://qiita.com/genimura/items/08d4d86818249d511d73)
    * 計算ロジックを外出しして、計算用のロジックを注入する方式は確かに拡張性が高そう
    * 見たらわかるが、それを設計するのはとても難しい
* [「開発スピード」と「プロダクト品質」 - kubell Creator's Note](https://creators-note.chatwork.com/entry/2024/12/13/090923)
    * 定数と変数の考え方で落とし所を探るのはとても良さそう
    * ただ一つ問題なのは、大抵の場合エンジニアよりステークホルダーの方が立場が強く、意見を通しやすい場合が多いということ
* [リモートのエンジニアチームに捧ぐ！今年使ってみて便利だったツールを厳選してみた - ABEJA Tech Blog](https://tech-blog.abeja.asia/entry/advent-2024-day13)
    * Meet自動で開いてくれるのとても良さそうだから入れてみる
* [複雑なものを複雑なまま扱う](https://zenn.dev/coconala/articles/complexity-complexity)
    * かなり大規模なチーム構成の場合の話だなという印象
* [PM定例のアジェンダ公開 - SmartHR Tech Blog](https://tech.smarthr.jp/entry/pm/teirei/2024)
    * PMとしての相談ができる環境が整っているの羨ましい
* [新しいチームで始めた感情を重視した振り返りの取り組み](https://zenn.dev/counterworks/articles/5797b2cb18be29)
    * Happiness Radar 試してみるの良いかも
* [ハックアワーのすすめ ── チームに「遊び」を取り入れ、中長期的な成長につなげよう！ - SmartHR Tech Blog](https://tech.smarthr.jp/entry/2024/12/13/140045)
    * 面白い取り組みではあるけど、こういったイベントをどれくらいの頻度でどれくらい取り入れられるかは会社によりそう
* [GitHubでのPull Requestのオプション指定と罠 | KINTO Tech Blog | キントテックブログ](https://blog.kinto-technologies.com/posts/2024-12-12-github-pullrequest-options-and-pitfalls/)
    * hotfix で同じbranchから各環境用のbranchにPRを出している場合にRebase and merge をすることで、各環境用のbranchがマージされるタイミングでコンフリクトしないならめちゃくちゃ有用かも
* [【評価制度】1年で2等級上げたエンジニアの話](https://zenn.dev/collabostyle/articles/9f1ba0e22b784e)
    * 評価されるのは純粋に嬉しいよね。自分が進みたい道を掴み取れるって素晴らしい
* [テスト管理ツールが必要になるプロジェクトの要素とは？｜SHIFT Group 技術ブログ](https://note.shiftinc.jp/n/n8c0c8e570132)
    * テストケースの把握と再現性の確立にとても価値を感じる
* [生成AI業務活用プロジェクトの立ち上げを成功に導く三種の神器 - Tabelog Tech Blog](https://tech-blog.tabelog.com/entry/advent-calendar-20241214)
    * 生成AIの導入はしっかりと検証できる環境を作らないと無駄金になりそう
* [なんちゃってアジャイルの卒業：経験から学んだ教訓｜SHIFT Group 技術ブログ](https://note.shiftinc.jp/n/n4202cd281030)
    * 認識合わせとコミュニケーションは特に大事だなと思った
    * あと弊社の場合は顧客からのフィードバックを受けての改善では無く、顧客の要望に言いなりになっている部分が少なからずある気がする
* [絶対に失敗してはいけないバッチ処理の作り方](https://zenn.dev/neinc_tech/articles/8d96fb50a696a3)
    * バックアップ取っておいて、問題なく削除できたことを確認したらバックアップも削除じゃダメだったのだろうか？
* [KTC クラウドセキュリティエンジニアのとある一日 | KINTO Tech Blog | キントテックブログ](https://blog.kinto-technologies.com/posts/2024-12-14-CloudSecurityEngineer/)
    * セキュリティエンジニアって地味だけどやりがいある仕事だろうなと、その道よりもお金を優先した自分は思う
* [ストレスを感じやすいママエンジニアが2回目の育休&復職で鍛えるべきは心の防御力だと気付いた話 - Retty Tech Blog](https://engineer.retty.me/entry/2024/12/15)
    * 軸を定めて心の防御力をあげる。この考え方はお嫁さんにも共有しよう
* [AWS OrganizationsからAWS Organizationsへ移行した話](https://zenn.dev/loglass/articles/c023d22590d5ad)
    * 今後のアカウント分離の参考になる
* [バリューデザインのリニューアル - ユニファ開発者ブログ](https://tech.unifa-e.com/entry/2024/12/15/080000)
    * バリューを定めるだけではなく、それを浸透させる為にデザインも考えるというのは参考になる
* [きれいな設計を目指したい！ ちょうぜつ ソフトウェア設計入門 - 虎の穴ラボ技術ブログ](https://toranoana-lab.hatenablog.com/entry/2024/12/15/120000)
    * 気になる本だけど、圧倒的に時間が足りない…
* [プロダクトエンジニアとしての観点を詰め込んだ開発設計書のテンプレートを公開します - hacomono TECH BLOG](https://techblog.hacomono.jp/entry/2024/12/16/000000)
    * ちゃんと時間を取ってみんなで認識合わせながら進められる環境が羨ましく思う
* [プログラムを約3200倍高速化して、社内業務のボトルネックを解消したお話 - Tabelog Tech Blog](https://tech-blog.tabelog.com/entry/advent-calendar-20241216)
    * パフォーマンスの改善は通常の開発業務にも大きな影響があると思う
    * しかしパフォーマンス改善は調査とデータの用意と根気が必要な作業だと思う
* [不具合の可視化のためにやっていること - 弥生開発者ブログ](https://tech-blog.yayoi-kk.co.jp/entry/2024/12/16/000001)
    * 基本的に可視化は大事
    * だけどこの手の内容はどのように活用するのかもセットで大事
* [虎の穴ラボのエンジニアリングマネジメントの役割と歴史 - 虎の穴ラボ技術ブログ](https://toranoana-lab.hatenablog.com/entry/2024/12/16/120000)
    * 弊社もこの自然発生的なものを狙っているのだろうか？
    * ロールを明示したほうが動きやすいだろうと思うのだが…