2024-10-07 共有記事ログ

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

# 技術系
## [エラー監視の仕組みを強化した話](https://tech.high-link.co.jp/entry/error-monitoring-strengthen)
エラーを適切に監視して、適切に処理するためにやったことをまとめた記事です
当社でもエラーログの精査からでも取り入れていく必要がありますね

## [コードの削除しやすさを考慮した設計の重要性](https://blog.wh-plus.co.jp/entry/2024/09/30/172602)
不要になったコードをどのように削除しやすくしたかの記事です
当社でも PHP という動的型付け言語を利用しており、不要なコードの判断が難しい状態です
できるだけノイズをなくせるように、不要になったものを適切に削除できる環境を整えていきたいですね

## [コード品質のモニタリングに「Qodana」を導入してみた話](https://blog.wh-plus.co.jp/entry/2023/08/17/113956)
PHP の静的解析ツールについての記事です
PHPStan では検出できなかったデッドコードの検出と Cloud 上で問題のあるコードが検出できるのはとても良さそうだと思います！
全社で導入を検討してみても良さそうだと思いました！
https://www.jetbrains.com/ja-jp/qodana/buy/?billing=yearly

# マネジメント系
## [DevOpsとは](https://sreake.com/blog/devopsとは/)
最近よく聞く DevOps についての解説記事です
当社は運用と開発が分かれていないのであまり意識することはないかもしれませんが、最近の開発速度を意識するための考え方なので共有です

## [DevEXとは](https://sreake.com/blog/devexとは/)
開発者体験に関する解説記事です
DevOpsと重複した内容が多々ありますが、今後のエンジニア獲得と定着率を考える際には、DevEXについても考え、整えていく必要があります

## [スキルが全てじゃない！ 仕事の円滑さに影響を与える価値観の重要性](https://note.shiftinc.jp/n/n3283cd4b2178)
価値観についてフォーカスしたマネジメントについての記事です
実際にここに書いてある例も、続編の例もよくある内容だと思いました
ただ部下の視点で上司の価値観を知ることは難しいと思うので、部下が考えることは奪ってはいけないと思うが、上司の価値観に沿った働きをしてもらうためのシステマチックな取り組みは必要かもしれないと思いました
逆にこの記事を見て、少しでも上司の価値観を理解できると良いかもしれませんね
当社ではあまり上司部下の関係性が明確になっていないので、相手の価値観を理解する難易度は高いかもしれませんが…

# セキュリティ系
## [パスワードマネージャーは必要か? そしてなぜKeeperか?](https://qiita.com/ishiayaya/items/24f5f9d8fed28339671f)
パスワードマネージャーの必要性についての記事です
パスワードは実際には使い回されているものがとても多いと思います
もしくはどこかにメモをとっているかと。
そのような問題を解決するためにパスワードマネージャーがあったほうが良いというのと
この記事で Keeper を選定した経緯も語られているので参考になりそうです

## [AWS WAF を COUNT モードで動かしたはいいが、その後どうすればいいんだっけ？](https://kaminashi-developer.hatenablog.jp/entry/2024/10/01/090000)
WAF を運用するための記事です
当社でも AWS WAF を利用していますが、これを正しく運用するための一助となると思ったので共有です


# その他
## [要件定義｜3分で読める非機能要件について](https://qiita.com/ho_na/items/a84f9a0db793cb0411db)
非機能要件についての概要を記した記事です
今まで非機能要件については考えないようにしてきた（と勝手に思っている）部分がありますが
今後プロダクト、会社の成長を考えるのであれば、こういった部分にも工数を割く必要があります
そしてこれはエンジニアの独断で決められるものでも無いので、内製のプロダクトであっても各プロダクト毎にしっかり話し合う必要があると思います！

## [チームでやろう！「ルールズ・オブ・プログラミング」読書会](https://tech.classi.jp/entry/2024/10/01/170000)
「ルールズ・オブ・プログラミング」の読書会をおこなったという記事です
個人的に気になっている本ですが、こういったものは全員で理解して進めていかないと意味が無いものと思っています
なので当社でも部分的に気になったルールをピックアップした輪読会をやるのも良さそうだと思いました

## [Findyの爆速開発を支えるPull requestの粒度](https://tech.findy.co.jp/entry/2024/10/04/070000)
PR の粒度を細かくしてレビューしやすい環境を整えるためにやっていることの記事です
ここに書いてあるような取り組みを実現できると、開発もしやすくなるし、レビュー負担も下がりそうです
少しでもスムーズに開発できる環境を整えていきたいと思っています


# 共有するほどではないけど興味があったもので読んだもの
* [GitHub Actionsを使ってFeature Flagの削除漏れを通知する仕組みを作りました](https://tech.pepabo.com/2024/09/27/check-stale-unleash-flag/)
    * Feature Flag は便利だけど、やっぱり残り続ける問題はでるなと。その対策の参考にはなりそう
* [頻出利用パターンで攻略するIAMロール（前編）](https://techblog.booklista.co.jp/entry/2024/09/27/111559)
    * RBACに慣れてないなら参考になるかも
* [AWS超入門〜Amazon EC2編〜](https://qiita.com/1998_i-airi/items/c8b84b4ea5743376dd18)
    * 初見の人向け
* [社内の9個のリポジトリの CI/CD を CircleCI から GitHub Actions に移行した際に考えたこと](https://tech.classi.jp/entry/2024/09/27/190000)
    * CI/CD設定の参考にはなりそう
* [複数の AWS アカウントに対して IAM ロールが特定のアクションを許可しているかどうか確認するシェルスクリプトを作成してみた](https://dev.classmethod.jp/articles/multi-account-iam-policy-simulator-script/)
    * AssumeRoleを用いるなら用途はかなり限られそう
* [AWS IAMについて](https://qiita.com/sis_r-ymd_in/items/09b940e1ce8507f46de8)
    * 初見の人向け
* [上司・部下それぞれの目線で知るビジネスライクな価値観](https://note.shiftinc.jp/n/n61b2bc1d1781)
    * 結構ありがちだと思う
* [JavaScriptにおける配列の破壊的操作とその代替策](https://tech.iimon.co.jp/entry/2024/09/30/183642)
    * 使い分けが大事だと思う
* [新卒社員が"はてな卒業生訪問企画ブログ"をきっかけに「なんでも技術共有場所」を爆誕させるまで](https://blog.cybozu.io/entry/2024/09/30/192206)
    * 当社にもそういう板は用意したけど自分以外の投稿が少ないのは少し悲しいかも
* [[アップデート] AWS Lambdaのイベントソースマッピングとコード署名設定がタグをサポートしました](https://dev.classmethod.jp/articles/update-aws-lambda-support-tagging-esm-csc/)
    * イマイチタグを使いこなせてないから恩恵が微妙
* [これからWebエンジニアになる人向け、これだけはやってほしい知識一覧](https://qiita.com/yamadagenki/items/3b8b0ce8df0117b9af8e)
    * 参考記事の中で暇ができたら読んでみるのも良いかも
* [単純なのに間違える！？Pythonコードの落とし穴](https://qiita.com/nucoyuyu/items/c6f433226f680eb6a95e)
    * Python 書く人は気をつけたほうが良さそう。PHP と Python ではかなり言語仕様が異なるので使い慣れていないとハマるかも
* [記事600本、だからエンジニアとして変われた](https://qiita.com/Sicut_study/items/3aff558ec4f4f2dcbe27)
    * 過去に似たような内容のものを見た気がする。そして青文字が非常に見辛い
    * https://gyazo.com/e5585ae0044d9b7bb7c20c99590f950c
* [コードの綺麗さにおける２つの観点（部品と構造）](https://qiita.com/SFITB/items/32dc8e137f9db0f0bccc)
    * 関数を小さくは心がけたいです
* [採用担当者が見る就職・転職活動のポイント](https://qiita.com/genimura/items/4499500451d8567c05e7)
    * 転職する際の対策だけでなく、面接する側としても参考になりそう
* [React(next.js)とかで開発してる時に深い階層のObjectデータをデバッグ用に吐き出すならconsole.log()ではなく、console.dir()](https://qiita.com/manji6/items/ba26215ca2c0bb43ec30)
    * console.log("%o",targetVariable) この書き方は知らなかった
* [歴戦のSE向け手順書を作成する際に気をつけたこと](https://qiita.com/prelude_op3-2/items/ae8caed334f47b93b007)
    * 「手順書や取説は言葉以上のものが読み取れないもの」という言葉を意識してドキュメントを書くようにしたいです
* [Webアプリでの長押し機能の実装は意外と難しい](https://qiita.com/yoruaki/items/65f06a83e49d63aad959)
    * 確かに長押し対応は大変そうだけど、Webで対応が必要なのか？という疑問も確かに残る
* [Qodana Cloud](https://zenn.dev/masakura/articles/00246e4f5647ce)
    * Qodona Cloud の使い方記事
* [マルチスタックに開発して感じたこと](https://developers.cyberagent.co.jp/blog/archives/49873/)
    * DB 処理に責任を持たせるサーバを置くというのはフレームワークによってはありなのかもしれないが Laravel の Model は活かせないような…
* [Four Keysを活用してチームの開発生産性を改善した時のふりかえりの考え方と手法を紹介します](https://techblog.zozo.com/entry/improve-mlops-team-capability)
    * Four Keys の指標を取り入れて改善させるためには、まず開発全員で Four Keys を理解するところから始める必要があるなと思った
* [社内勉強会を少人数でおこなう理由と工夫](https://zenn.dev/geniee/articles/39b799f65cacbf)
    * ニーズに応じて少人数勉強会という考え方もありかもしれない
* [自分の利益だけではなく、関係者の利益を踏まえて考える](https://dev.classmethod.jp/articles/win-win-thinking/)
    * できるだけこうなるようにしたい
* [GitHubのSub-Issues機能(Public Preview)を試す](https://dev.classmethod.jp/articles/github-sub-issues-public-preview/)
    * Github でのタスク管理をメインとするなら良さそうな機能
* [テストコードについてざっくり解説！テストの種類や重要性もまとめて紹介します](https://lab.sonicmoov.com/development/testcode-importance/)
    * UT or AT だけでもあると変わる