2025-07-07 共有記事ログ

概要

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

技術系

いまさら聞けないデータ削除の話

大量のデータを削除するのにCPU付加がかかりすぎないように対応した記事です
自分は深夜反映が基本で、多少負荷が掛かっても問題ない環境なので意識はしていないことが多いですが、削除も登録も変更も、今後はある程度データ量と実行コストは計算した方が良いなと学びになったので、皆様にも一つのきっかけになればと思い共有いたします！

Cookieだけじゃない！Webの裏側で“あなたの行動”はこう見られている

トラッキング技術についての記事です
ユーザの動向を把握することで必要な機能を拡張したり、不要な機能を削除したりと、広告のトラッキング以外にも利用価値がある情報だと思います
そう言った情報をどのようにして取得するのかの参考になるかと思い、共有いたします！

マネジメント系

なぜ、成果を出す人ほど「締め切り」を設定するのか？

期日を設定することが成果を出す要因になる可能性があるという記事です
考える時間と実際問題バッファは必要な時間だと思います
しかしながらバッファという言葉を明示的に使うと、良い顔はされないことが多いのではないでしょうか？
この記事であるようにリスクを明確にしてコストを算出し、心に余裕のある開発をしていきましょう！

新たにチームを立ち上げた後にやるといいこと

新チームや新部署を立ち上げた際にやっておくと良いことの紹介記事です
自分たちの場合は新しいチームという訳ではありませんが、ここに書いてある内容はいくつか取り入れても良いのではと思いました
例えばMVVですが、自分はずっと会社として用意するものだと思っていましたが、部署やチームとして作っても良さそうな感じなので、みんなで同じ方向を向くのに定義してみるのも良さそうだと思いました！
また、以前話していただいた考え方や目指したい姿などは明文化して公開情報として置いておく方が良いかもしれませんね！

コミュニケーション系

それって本当に「好みの問題」？

好みの問題という便利ワードを使って思考停止してはならないという記事です
自分もよく好みの問題で片付けることがありますが、ちゃんとメリットデメリットを洗い出して、議論して、何を重視して判断を行ったかを明確にできるようにしていかなければと思いました
相互にレビューする中で必ずそう言った場面に遭遇すると思いますので、そう言った時に思考停止しないで、より良くしていける環境のためには必要な内容だと思い、共有いたします！

「ふりかえりカタログ」の振り返り手法をチームで実践してみました

振り返りカタログから新しい振り返りを行ったことを記した記事です！
自分たちは一年くらいKPTをつづけていますが、いまだにネタが尽きないので振り返りに困ったことないですが、一度振り返りカタログを見てみるのも良いかもしれないと思いました
そしてここで紹介されている感情グラフ+タイムラインのハピネスレーダーは、週一朝会で話したい議題がない時には試してみるのも良いかもしれないと思いましたが皆様いかがでしょうか？

To プロダクトチーム

属人化を防ぎ自己管理型になるためにスクラムチームが始めた取り組み

属人化しないために行なっている取り組みの紹介記事です
この記事ではスクラムというフレームワークを用いているため自分たちとは状況は異なると思いますが、開発ではタスク分解と設計をする人と、実装をする人を分ける。サポートでは仕様策定者とレビュワーを分ける分けるなどで、属人化しないチームを作って行くことはできそうだと思いました！
現状ではタスクに追われた状況で、少しでも多くタスクを消化するという経営判断のもと開発を進めておりますが、いつ誰が事故や病気・退職などで働けなくなるかわからないので、どこかでそのリスクヘッジのために動き出した時の参考になると思い、共有いたします！

AI時代の組織変革：エンジニアリングマネージャーが見たメルカリグループの半年間の軌跡

先日CTOより共有がありましたメルカリのAI導入についての記事です
CTOは先日からCursorを利用されていましたがいかがでしょうか？
メルカリのような大規模な会社が全社的に大きな成果を挙げているのは、導入事例の成功例として大きな意味を持つのではと思います
大きな会社が率先して人柱となり成功事例を上げてくれた現在、自分たちのような小規模な会社はそれに倣う事でリスクを減らしてメリットを享受できる良い機会だと思います！

既に導入を進める方向になっているようなので共有なし

共有するほどではないけど興味があったもので読んだもの

• キャリアプランはもういらない？キャリアの横道が本線になる時代
  • 今までは人との差別が必要だったけれど、最近はAIとも差別化が必要になったと感じる
• Claude Code どこまでも/ Claude Code Everywhere
  • 倫理的、法律的に問題があるもの（セキュリティ会社のオフェンシブやレッドチーム）以外は実装力よりも設計力が求められるようになったと実感
• どんな評価基準で、どこまで満たせばよいのか？を考える第一歩
  • MVVはやはり定めるべきだと思う。色々なことの判断基準になる。仮に全て社長が直接判断するのであっても、透明性のある判断は信頼につながる。対外的には用意しているけど、内部的にそれを方針としない運用にはモヤる
• 「技術的負債への向き合い PHP編｜10年越えプロダクトを提供する3社が語ります！」を開催しました
  • 合同でオフラインイベントが行われる企業も面白そうだと思う
  • 技術的負債とテストは切り離せないものだよなと改めて実感
• PHP 8.5の新機能「パイプ演算子」
  • 関数の引数に関数の返り値を渡す入れ子構造は可読性が低いから避けたいが、一時変数を使うと再代入を許容するか、完成系で名前がつくものに対して未完成状態の名前を考えるコストがかかってくる。それを避けて可読性を担保できる機能なので早く使ってみたい
• UI実装で遭遇する“あるあるバグ”とその解決方法
  • 使うまで覚えておかなくても良いだろうけど、こんな問題があるということを知っておくことに意味はありそう
• Burp AI : セキュリティ診断にAIの力を借りる
  • オフェンシブセキュリティに対してもAIが有効そうな感じがしているので、本当に様々な分野で活用されているのだなと思う
• メルカリグループの全社的なDevEx改善の仕組みづくり
  • エンジニアだけでなく、組織横断的にDevExを考えて改善していくことが重要なのかもしれないと思った
• Gemini cli が出たっぽいので cloud run deploy までやってみるぞ
  • GCP使ってないと恩恵はあまりなさそう？というか他の選択肢の方が適してそうなのかも
• 感情を大事にしていますか？感情を言語化することのメリット
  • 感情とその状況の言語化と、その言語化した内容を残すのは振り返りに良さそう。感情専用のXアカウントとか作っても良いかもw
• 1年間EMとして取り組んだことと悩みや葛藤
  • 観察の重要性を念頭にコミュニケーションを取るために、どのように行動に移すべきかを考えさせられる内容だった
• 値の不変性と変数の不変性についての整理
  • PHPのconstは確かに不変ではあるけど、const指定したら配列であっても値も不変になる定数の定義となる
  • しかしそもそも代入可能な型がスカラー型に制約があるので、不変性を同列に語っても良いのか疑問
• 生成AIの登場によって考えたこと。～決断力・意思～
  • 確かにAIの答えに対して、採用するかどうかは人が持っていて、その決断をAIに肩代わりさせてもその責任を取るのは自分なので、AIに委ねるという決断をしなければならない
• AIサービス導入時にまずチェックすべき3つの観点
  • 利用規約などの確認は必要なのかもしれないけど、法務部門で無い人が正しく規約やリスクを把握できるのかは疑問なので、規約関係は下手に担当者が確認するよりも専門家に任せる方が企業としても安心できる気がする
• 【実体験】Claude CodeとCursor、1週間使い倒して分かった本当のコスパ
  • どこかのタイミングで個人でも課金していった方が良いのだろうとは思うものの、Maxプラン$100/Monthはやっぱり抵抗があるなと…
• 生のターミナルから卒業しませんか？【oh-my-zsh】
  • カスタマイズしまくっているzshとどこまで共存できるかで使うかどうかが変わりそう
• エンジニアのキャリアパス　〜王道３パターンとその先〜
  • なんだかざっくりしたキャリアパスで想像するのが難しそうだなと思った
  • CTOやVPoE、EMなどのキャリアパスはどこに属すのだろうか？？
• 活躍したいが会社が嫌だ。そうだQiitaに記事を投稿しよう。
  • 自分もそうだったけど、やりたいことがある中で会社を選んだのに、それができない環境だとどうしても悪い部分だけ目についてしまうけど、ちょっとしたきっかけで少しだけ視点を変えて見てみると、意外と良い部分は沢山あると気付ける
• Cursorから始まったAIコーディング体験とClaude Codeとの使い分けで見えたコンテキストスイッチの最適化
  • 利用ケースによって使い分けれるのが理想なんだろうと思ったけど、その分個人で契約するにはコストがかかる…
• 開発チームを自己組織化するために取り組んだ5つのTRY
  • 自己組織化することで、各々がより責任を持って改善に取り組める環境を作っていくことができるので、自分たちにも当てはまりそうな内容はどんどん取り入れていきたいと思う
• チームの垣根を越えて実現！マネーフォワード関西拠点CTFイベント 〜マネージャーたちが語る企画のプロセスと展望〜
  • CTFで各チームの特色や人となりを知る良い機会になるのであれば、規模の大きな会社ではこういった取り組みをしてみるのも面白いのかもしれないと思う
• サービスを提供する際、アプリ側はどう守る？ 不正な解析・改ざん行為からアプリを守る、DNPハイパーテックによるアプリ保護Q&A
  • オンラインゲームでのチート対策にも使える内容な気がするけどチートが無くならないのは、ゲーム会社がここにコストをかけられないのか、チートをある程度容認しているのか、取り入れても攻撃者が解析してしまうのかどれなんだろう？？
• [入門] Linux 誕生の瞬間 1991/09/17 1万行を読み解く
  • 大学院時代に学んだOSの仕組みの復習になって面白かった
  • 機会があればこう言った場所の実装に携われると嬉しなと思う
• 【CSS】まだ width: 100% つかってるやついる⁉︎ いねぇよな⁉︎
  • 使える環境が限られているから実務で使うかは怪しいところだけど、便利そうではある
• Ctrl + Cでなぜプログラムが終了するのか？
  • シグナルセーフな関数が定まっていることを知らなかったので勉強になった
• DDoS攻撃をちゃんと理解したい人のための入門と設計整理メモ
  • 攻撃コストが想像以上に安かったから、悪意を持って攻撃されたら、ちゃんと対策しておかないと簡単にサーバが落ちてしまいそう
  • 焦る人間ほどルールを緩める。肝に銘じておこう
• AI時代にエンジニアは不要になるのか？
  • エンジニアという職は当分なくなりそうになく、エンジニアが不要になる前に、それ以外の多くの職がなくなってそうだなと思う
• 【Claude Code】初心者向け備忘～要件定義を1人で抱え込まないで～
  • ヒアリングしてもらうというのも一つの使い方の選択肢なのかもと思う
• Gemini CLIの"強み"を知る！ Gemini CLIとClaude Codeを比較してみた
  • 無料枠万歳！！笑　早速使い倒して見たいと思う！
• 10歳娘「凡ミスの多い人ってプログラマーに向いてるよね」
  • 自分もかなり凡ミスが多い方だからわかるけど、気をつけるではほとんど解決しないから、個人として、チームとして、ミスが発生しない仕組みを作ることが大事だと思う
• 【GitHub Copilot】最大限活用するためのTips紹介
  • CopilotのメリットはGithub UI上で色々出来ることだと思った
  • 最後に色々調べてからかなり時間が経ったので改めて今何ができるのか確認した方が良さそう
• 「どうして伝わらないの？」部下との価値観ギャップに悩んだら
  • これは非常に難しい問題だと思った。大切にしている価値観だからこそ、お互いに分かってもらいたいし、言葉に熱が籠る。だからこそ衝突もしやすいのかと思う
• 【QAチームの知を結集！】読書会でスキルアップとチーム力向上を実現しよう
  • 勉強会の題材は異なるけど、弊社勉強会とやり方が似ていて、得られた効果も似ていると思うので、今後も続けていこうと思う
• 開発者体験を爆上げするPlatform Engineeringへの挑戦 ー 汎用化のための設計編
  • イメージしていたプラットフォームエンジニアリングとは異なるけど、こういった既存システムの仕様変更を繰り返した後の最適化やリファクタリングをする時間は必要だなと思う
• 最速振込の舞台裏：プロジェクトのリードの実践と学び
  • プロジェクトが予定通りに進むことの方が稀で、必ずバッファは必要になると思うけど、それを食い潰した時のリカバリ案を残業以外で考えられる人がリードする立場にあって欲しいと思う
• AIがコードを書く時代、この先エンジニアに求められることとは？
  • AIと共にある文化を作るという視点は新しいなと思った
• 【PMOノウハウ 02】危機を招いた課題管理の失敗
  • 最近は自分が担当するプロダクトでも些細な問題もチケット管理されるようになったけど、今まではチャットベースでやり取りして、解決したら放置されることが多かったので、このような失敗につながらないようにちゃんと管理することが大切だと思った
• コマンド紹介シリーズ：kdash
  • k8s使っていないのでこのコマンドは今のところ出番なさそう
• 20日で鍛える読解力：Day16｜すべてを読まなくていい
  • 本質とは関係ない内容や、同じことを何度も書いてある場合など、読まなくても良い内容は意外と多いのではと思う
  • 特にテックブログ見ていると無駄に冗長な文章を書いている記事を多く見かける
• 経営的思考への階段 - エス・エム・エス エンジニア テックブログ
  • マネジメント層が一般的な経営層としての役割を求められていて、一般メンバーが一般的なマネジメント層の役割を求められる環境は船頭多くして船山に上る状態にならないのか疑問に思う
  • もちろんマネジメント層や経営層の考え方をして、それらの視点で見ること自体は良いことだと思う
• EMは「人とチームの可能性にレバレッジをかける仕事」 —— はてな・daiksyさんとの対談から考えるEMとスクラムマスターの関係性
  • スクラムマスターとの関連性は今まで視点に無かったけど、AIとの付き合い方を考えた今後のEMの役割としては、自分のイメージと大きな差異は無さそうだと確認できた
• 20日で鍛える読解力：Day17｜速く読む＝読解力が高い？という誤解
  • 早く読めて、ちゃんと理解できている状態が理想ではある。それだけたくさんの情報を処理できているということなので、仕事においても学習においても早く読めて理解できることは大きなアドバンテージだと自分は思う
  • ただし理解が追いつかないくらいなら遅くても理解する方が良い
• “たった2文で心が動く” 同僚が感じた育成的リーダーシップの真髄
  • 自分で決めたと感じれるようなリーダーシップを心がけて臨むようにしようと思った
• 奈良女子大学の講義に登壇！虎の穴ラボCEO・EMが語る現場のリアル - 虎の穴ラボ技術ブログ
  • マネジメントの方法や考え方は組織によって変わるだろうけど、そのサンプルとしてスライドを見ておくのは良さそう
• 脳に収まるコードを書くために
  • デザインパターンやインタフェースの利用はかなりのif分岐を減らすことができそうなので、積極的に利用を検討しても良さそう。ただしクラスが増えることを嫌う人も一定数いるので、あらかじめ合意を取る必要はありそう