2025-05-09 共有記事ログ

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

# 技術系
## [LGTM！](https://tech.iimon.co.jp/entry/2025/04/22/172330)
コードレビューに関する記事です
PRの変更は500行以下・20ファイル以下で小さければ小さい方が良いという明確な基準や、何も知らない人が読んでも理解できるレベルの内容を書くなど、明確なアクションとして記載されていました
コードレビューに関しては頻繁に議題に上がりますがなかなか良いルール・ガイドラインが作れていないので参考にしながら開発部全体で合意できるものを作れたらと思いましたので共有いたします！

## [【chiica】FuelPHPのLogクラスを改修してみた](https://tech.trustbank.co.jp/entry/2025/04/23/163500)
FuelPHPのログをコンテナ対応のために標準出力に変更するための手順をまとめた記事になります
当社でも今後コンテナでの運用をする際には必要な内容だと思いますので共有いたします！

# その他
## [悩みにハマる人と、抜け出せる人の違いは“視点”にある](https://note.shiftinc.jp/n/n93150cade99a)
悩みがある時は目的を考えると解決できるという記事です
生きていると悩みは絶えないものかと思いますが、その悩みとの向き合い方は大切だと思いました
悩みにばかり目を向けると良くない思考が深掘りされ、最終的には何の解決にもなっていないけど自分が傷つかない結論で自分を納得させようとする事が多いのかなと思います
そうならないように、その悩みの結果どうなっていたいかを考える癖をつけることは、とても大切なことだと思いましたので共有いたします！

# 共有するほどではないけど興味があったもので読んだもの
* [プルリクエストを作るだけで検証環境が自動生成！ArgoCDとk8sで実現する開発者体験の改善](https://tech-blog.monotaro.com/entry/2025/04/22/090000)
    * コンテナをうまく使うとレビュー環境をPR毎に作れるので、こういった環境構築を行えたら良いなと思った
* [GitHub Actions で開発環境デプロイをしよう](https://engineering.nifty.co.jp/blog/32216)
    * EC2からECSやEKSに乗り換えた方が色々と楽になりそう
* [BacklogのMCPサーバーを作ってローカル動かしてみた](https://qiita.com/Hiroto_Aso/items/7db2b9cf33827db4c298)
    * 便利なのだろうか？自分だけが使うなら試してみるのもありかも知れない
* [MCPを超理解する](https://qiita.com/ak-sasaki0919/items/b216a06b0ef33536fc3b)
    * 標準化されれば作る方も使う方も楽にはなるので、しっかり定着してもらえたらと思う
* [優しいMCP入門](https://speakerdeck.com/minorun365/yasasiimcpru-men)
    * MCPについて理解が深まったが、このAI利用のコストがどうしても高いと思ってしまう…
* [サトシ:「行け!!ピカチュウ!!」はFactory Methodだったのか...。](https://qiita.com/umekikazuya/items/b0adacee33b2774d7089)
    * 自分が思ってるFactoryPattern, FactoryMethodと微妙に違うから勉強し直さないと
* [[MCP再入門]「MCPはAIアプリにとってのUSB-C」がしっくりこなかったあなたに](https://qiita.com/takashiuesaka/items/49559b830366255d1216)
    * サーバーの実装は何処まですれば何ができるのだろう？
    * もう少しちゃんと調べないと
* [元ヤフーエンジニア社長が考える、新人エンジニアの成長を阻害する悪習5選  ](https://qiita.com/ryoheiiwamoto/items/25851a3663c5b224d275)
    * エンジニアである前にビジネスパーソンというのはその通りなのかも知れないが、エンジニアリングとマネジメントが両方スペシャリストになれる人は極一部なので、どちらかのスペシャリストになるという考えもありなのではと思ったが、それは価値がないのだろうか？
* [TypeScriptの危険性](https://qiita.com/MadakaHeri/items/45e514dfbbc85fd64c77)
    * TSの盲信はよくないかもしれないが、だからJSにすべきと思える内容は少ない
    * 速度も初速は確かに速いかも知れないが、その後のメンテナンスコストはそれこそ型がない分上がる可能性があることと、JSDocは最悪メンテナンスしなくても動くだけに不安が残りそう
    * 個人的にこの筆者は言葉が強いので、個人の意見を述べるというより喧嘩を売りに行っているように感じ取れて少し不快な文章
* [GitHubにてPushできるブランチ名に規則を持たせる方法](https://qiita.com/uenok0108/items/b0fa3024862a8ac6e958)
    * 厳密なルールに則っている方が管理はしやすいだろうけど、個人的に今の環境ではそこまでしなくても良いかなと思っている
* [ターミナルがダサいとモテない。IT エンジニアの成長に必要な要素](https://blog.grasys.io/post/yusukeh/elements-growup-itengineers/)
    * ターミナル関係ある？って思っちゃった笑
    * キャリアを考える際の参考にさせてもらう
* [自分用コマンドにはプレフィックスつけるとよさげ](https://blog.atusy.net/2025/04/24/prefix-personal-commands/)
    * 確かに補完には便利そう
* [GitHubプライベートリポジトリでもかっこいいバッジを付けたい](https://engineering.nifty.co.jp/blog/32967)
    * LintErrorの数とかを表示させても面白いかも
* [2025年4月版読んでいて良かった本紹介](https://zenn.dev/akasan/articles/9b2e5528548353)
    * 読み終えてないんかいw
* [その“仲間意識”が、可能性を閉ざす？](https://note.shiftinc.jp/n/ndfe57413e0da)
    * 最近よく感じる部分
    * 相手の視点で見る。相手を知る。言葉では簡単だけど、そのための行動がとても難しい
* [明日からできる！GitHub Copilot + GitHub MCP Serverで始めるAI駆動開発](https://zenn.dev/10q89s/articles/ecb9d205f4dbec)
    * 今後は実装力より設計力と指示する能力、そしてレビュー力がより求められる様になりそう
* [ブレインストーミングの4原則とは？具体的なやり方や注意点について解説](https://solution-blog.sonicmoov.com/direction/blainstorming-rule/)
    * ブレスト自体は賛否両論あるみたいだけど、うまく活用できれば有意義な時間にできそう
* [【VPoE×EM対談】仕組みづくりと機会の提供で、プロダクトの価値を追求し続けるエンジニア組織を目指す](https://note.com/canly/n/nb7871dfc49b5)
    * プロダクトエンジニアを作るのは難しそう
    * プロダクトや顧客に興味を持つエンジニアはどれくらいのいるのだろう？
* [エンジニアの成長を"全社共通の評価制度"で本当に測れるのか？](https://xmart-techblog.hatenablog.com/entry/2025/04/28/120000)
    * 全社で一つの方向を向くために共通評価を作るのは良いと思うが、それをエンジニア向けに具体化したものは必要だろうなと思う
* [Vimでステータスラインプラグインを遅延読み込みする](https://blog.atusy.net/2025/04/30/vim-ekiden-lazy-load-statusline-plugins/)
    * 現状起動時の速度は気にならないので保留