概要
現職の開発部のメンバーに共有した記事のログ
技術系
なぜもっと早く使わなかったのか...データベース系MCPでデータ分析が楽しい!
データベース系MCPについての紹介記事です
すでにある程度の知識を有している人にも手軽にSQLを作ってもらえる利点はありますが、特に新しくジョインした人や慣れていない人にとってデータベースから必要な情報を検索してもらえるというのはかなり助かるのではないだろうかと思います!
もちろんテーブルやカラムにコメントが正しく入っていないと難しい部分はあるかもしれませんが、Gemini CLI などで MCP を繋いで試してみても良さそうだと思い共有いたします!
p.s.
少し利用してみましたが、Gemini CLIでは「テーブルの構造を確認してください。」をはじめに入れないと MCP を使ってくれませんでした
ただ一度つながってしまえば、「table_name のカラムを確認して、どういった使い方がされているかを推察してください」といれるとそこそこ制度が高い推察が返ってきたので、結構便利かもしれません
なるべく安全に自宅サーバを公開したい(ゼロトラスト入門)
自宅サーバを公開するために考えることと、代替してくれるサービスの紹介記事です
先日サーバを構築してみたいというお話をされていた方もいたかと思います
そういった人には安全にサーバを公開するためにどのような手段が取れるのかといった部分や、サーバに関係なく自宅のIoTに対して外からどのようにしてアクセスしているのかの参考にもなると思い共有いたします!
マイクロサービス導入を決断する前に: モジュラーモノリスという選択肢
モジュラーモノリスを導入するメリットについての記事です
当社のシステムはかなりおおきなものになってきたかと思いますが、現状モノリシックな状態なので低凝集・密結合が簡単に作り込みやすく、CIにも時間がかかる状態になっております
そういったものを物理的に分割するマイクロサービスは大きな解決策となり得ますが、そのためのハードルもまた高いです
そこで、段階的にモジュラーモノリス→マイクロサービスと導入していくことで、一度に発生する負担を分散させることができるため、各プロダクトで一つの選択肢となるのではと思います!
セキュリティ系
セキュリティ月間から7ヶ月程経ったので改めてセキュリティについて考えてみた
代表的なWebの脆弱性の紹介記事です
iframe や リダイレクト先の指定に関しては、当社のプロダクト的に避けれない場合もあるかと思います
しかしながら、それが脆弱性となり得ることを知って許容したり、そのプログラム以外の場所で何らかの対策が行えれば良いのですが、仕様策定者が脆弱性となることを知らずに「便利だから」で仕様を決めてしまわないよう、そういった仕様書が出てきたら自分たちから「これはこういった危険性があるけど」という話ができるように、代表的なものは理解しておく必要があると思い共有いたします!
コミュニケーション系
新卒エンジニアが学んだ、伝わりやすい文章を書くための実践ポイント
伝わりやすい文章を書くための基礎の記事です
ここで言われているのは文章量を減らすと言うことですが、それはその通りだと思います
しかしながら(自分は)ついつい長くなってしまいがちですし、減らす情報の取捨選択が難しいとも感じております
基本的に書きたい事を書くのでは無く、読み手が素直に受け入れられるように書くことが大事だと思いますので、内容の取捨選択や構造や言葉選びなど、プログラミングにも通ずる部分はあると思いますので、みんなで意識していけたらと思い共有いたします!(スライドの方を見てもらいたい)
共有するほどではないけど興味があったもので読んだもの
-
「あなたはプロの〇〇です」をもうやめたい、 「メタプロンプト」から「コグニティブデザイン」へ
- このレベルで指示出しを常にする事を考えると、従業員と違って次の業務に活かせる学習とならないAIに対しては内容次第では指示コストの方が高くなる場合もありそう
- それも含めてどうAIと使っていくかを考える必要がありそう
-
【2025年最新】Anthropic公式が明かすClaude 4プロンプト最適化12のテクニック
- XMLタグは他のAIでも効果を発揮するのか気になる
- 詳細に要件を書けばそれだけ精度が上がるのは理解できるけど、毎度新しいチャットを開くと過去の学習が全て消えるので、毎回同じような事を伝えなければならないのが結構ストレスに感じる
-
「考え方」を変えたら、悩む時間が減ってプロダクトへの向き合い方が変わった話
- 何かを議論するときはどうしても自分の主張を正として臨んでしますけど、「自分の主張は一旦忘れる」ようにして話を聞くことが大事だと思った
- 「相談は一緒に考えを深める行為」という考え方も良いなと思う
-
PMの本質は「やらないことを決めること」
- やらない事を決めるというのはとても大事で勇気が必要。大体は上層部もユーザーも予算内・期限内に全てやれって思っているだろうから
- やらないと決めた事が可視化されると実働部隊は少なからず好感を持てそうな気がする
-
プログラミングの学習方法を聞かれたら、こう答える
- 同じテーマを違う方法で実装するという視点で伝えたことは今までなかったので参考にさせてもらおう
-
GitHub 使い方基本
- 新しい発見があるかと思って見てみたが特に無かった
-
全ての道は「つよつよエンジニア」に通ず
- リソースは有限なので、原理を理解して、主要な分野で強みを作る。自分の目的に沿わないことには学ばないことを決める。ということは理解できる
- ただ言い回しが難しく、今つよつよエンジニアではない人に向けるものとしては微妙かもという感想
-
読むだけじゃ終わらない、知識をチーム力に変える輪読会!
- 弊社と同じ形式の勉強会を行っているみたいだけど、弊社と同じような目的と効果があるようなので、業務外で読んでくることに合意が得られるなら価値あるやり方なんだなと実感
-
複数のデータ取得処理を高速にする
- ただ並列に処理するだけの紹介
-
パパママエンジニア必見!KTCパパエンジニアの1日
- こういった制度は弊社でもあるとは言われているが、キャリアと同時進行は難しそうな圧を自分は感じる
- 他の人はどうなのか一度アンケートをとって、他の人も同じように感じているなら心理的な部分の改善を図っていきたい
-
【エンジニアの日常】エンジニアの人生を変えたイベント Part2
- 登壇するということはやっぱり大きな影響があるんだなと感じるので、自分もどこかで登壇してみようかなと思った
-
楽しく開発するための私のターミナル設定
- 補完系とGhosttyが気になるので入れてみる
-
Git のブランチ操作で発生したトラブルと学び
- 確かに Revert は正しく理解していないと混乱するかも
- 変なマージは GIthubの設定で禁止できるかも
-
GitHub Actions: developからfeatureブランチへ自動マージする仕組みを作ってみた
- 現状の自分たちのチームでは feature ブランチの自動マージはそこまで必要ではない気がするけど、master や staging 用の branch への merge commit が Github の差分に出てくることには悩んでいるので、これを活かすことはできるかもしれない
- ただ一つ懸念点は、develop への直接 push は禁じているので、ここをうまく回避する必要がありそう
-
メンバーとチームが相互に成長する「丸投げ」しないタスク管理
- とても参考になった
- 挑戦的な割り振り:安定した割り振り=2:8は意識してみる
- チェックポイントを設けた報告ルールを設けるのも良さそう
- フォローの告知を徹底するのも良さそう
- リリース後は必ず振り返りを入れても良さそう
-
【資料公開】生成AIでセキュリティ運用を効率化する話
- AIはそれっぽいダミーデータを作る際はとても手軽に作れて良さそう
- それと雛形作成も結構強いイメージがある
-
kintoneエンジニアリングマネージャー1年目の振り返り - 失敗から学ぶアジャイル開発 -
- MVPの視点での開発はわかるけど、そのコスト管理がEMの責務というのはピンと来なかった
- アジャイルの理解不足というか、理解が合っても不満に思う点は弊社でも出てくるので、そこをどうカバーしていくのかが難しいところな気もする
-
ターミナルがダサいとモテない。trivy で mac を見てみる 編
- SBOM とか洗い出せるなら使ってみるのも良いかも
-
GeminiCLIでカスタムスラッシュ + VSCode(Gemini CLI Companion)
- PR の Description を書くのが地味に面倒だから、MCP と Slash Command の組み合わせである程度自動生成してもらえるなら結構使い勝手良さそう
-
レガシーシステムからの脱却 〜段階的リリースで挑むシステム刷新〜
- FE/BEの分離と段階的なリプレイスは考え方の参考になりそう
-
目標設定シートがToDoリストになっていませんか?
- 目標とは「理想の人材像とのギャップを埋める成長プロセスを描くこと」という言葉を念頭に目標設定を行っていきたい
-
なぜLambdaから直接他のLambdaを呼び出すのはアンチパターンなのか
- 現状 Lambda から Lambda を呼び出したいニーズは無いが、必要になったときの参考になりそう
-
Mago: PHP開発が爆速になる?次世代の静的解析ツールを試してみた
- 結構CIの速度がネックになっているので、これでカバーできるのであれば是非とも使っていきたいが、独自ルールがそれなりにある現プロダクトにおいての乗り換えるためのハードルがどの程度なのか気になるから検証しないと
- 超絶高速で感動した!
- けど、既存ルールを踏襲するのが簡単にはいかなさそうなので、すぐすぐの乗り換えとメンテナンスは難しそうな気がする…
- 現状のエラーを見る限り phpcs の領分と phpstan の領分が、きれいに lint / analyze に分かれていなさそうな感じがする
-
新しい期を迎え、改めて考える“リーダーシップの原点”
- 新たに部長という役割得た自分にとって、この自分の状態が与える影響というのはすごく響いた
-
今のうちに見直しておきたい“人を動かす聴く力”
- 心(気持ち)を意識した聞き方というのは自分には足りていないと思うので、そこを意識して1on1を行っていきたいと思う
-
神魔狩りのツクヨミ勉強会を実施しました
- こういった新しい挑戦を社内で共有するような勉強会も不定期に取り入れても良さそうだなと思った
-
AIに依頼するか、人間に依頼するか
- 何がうまく行って、何がうまく行かなかったかをちゃんと社内で共有できれば、人とAIの差別化ができていくようになりそう
-
NATゲートウェイとVPCエンドポイントのコストによる使い分けに関する備忘録
- こういったところのコスト差が生まれるというのをちゃんと調べていくと、それなりに利益率も高くなるのかもしれない