はてなブックマーク

株式会社カミナシで VPoE を務めている pospome です。 (´・ω・`) 先日 "Chrome DevTools MCP" というMCP Serverが存在することを知りました（チームメンバーが教えてくれた）。 これによって日々沼っていたCSS修正の効率が上がって嬉しかったので記事として残します。 CSSの実装に沼る日々 "Chrome DevTools MCP" を使うと嬉しい まとめ 宣伝 CSSの実装に沼る日々 自分は最近プライベートの時間をつかって TypeScript, React の勉強をしています。 GitHub Copilot を使いながら簡単なアプリケーションを作っていて、 コードを実装してもらったり、不明点を説明してもらったり、Copilotさんのお陰で勉強効率がグッと上がった気がします（AIってすごいですね・・・）。 Copilotさんは自分が作る簡単なアプ

株式会社カミナシで VPoE を務めている pospome です。 (´・ω・`) 最近非同期処理について考えることがあったので、そのときに考えたことをサクッとまとめようと思います。 非同期処理について体系的にまとめたものではなく、あくまで "その時に考えた限定的な内容" になります。 Webサービスにおける非同期処理とは 非同期処理はめんどくさい 同期処理では要件を満たせないケース 非同期処理の面倒なポイント 1. メッセージキュー/タスクキューに対する理解 2. ワーカー処理が失敗したときのリカバリ方法を考える 3. ボトルネックの確認と対策 補足：非同期処理を上手く扱えるようになろう まとめ 宣伝 Webサービスにおける非同期処理とは 本記事を読み進めるにあたって、 "非同期処理" の認識を合わせておきましょう。 Webサービスにおける非同期処理は AWS SQS, Google C

株式会社カミナシで VPoE を務めている pospome です。 (´・ω・`) 働いていると、複数のチームを横断したり、会社全体で「これやりたいな」と思うことがあります。 対象の組織規模が大きくなればなるほど難しくなりますが、 自分のやり方は一貫しているので、それを書いてみようと思います。 ザックリとして流れの説明 1. 勝ち筋を見出す 2.ステークホルダーを確認する。 3. やりたいことをドキュメント化する。 4. ステークホルダーにレビューしてもらう。 ポイント1. レビュー期限を決めること ポイント2. レビューしない人は同意したとみなす ポイント3. 決定事項ではないことを明示する ポイント4. 必要に応じて同期的に共有する 5. 自らオーナーシップを持って進める 補足: "Disagree & Commit" を徹底できない組織は "詰み状態" 補足: こーゆー動き自体を部下

株式会社カミナシで VPoE を務めている pospome です。 (´・ω・`) たまに「エンジニアとして成長するには何が必要ですか?」という質問を受けますが、 自分はこういった質問に対して、一貫した回答をしているので、それをアウトプットしようと思います。 エンジニアとして成長するには何が必要か? 才能 努力 環境 才能以外をどう活用するか? まとめ 宣伝 エンジニアとして成長するには何が必要か? 結論から言うと、以下の変数のかけ合わせで決まる。 才能 努力 環境 才能 "才能" は説明不要だと思う。 才能があればあるほど、エンジニアとしての成長は早い。 才能は "ある or なし" ではなく、グラデーションになっているので、"どのくらいあるのか" という話になる。 自分が今まで交流してきたエンジニアの中には、 知識と経験は不足していても「こいつはセンスあるな」と思った人がいる。 こーゆ

やりたことはたくさんあるけど、できない じゃあどうする? 考え抜くことの大切さ まとめ 宣伝 株式会社カミナシで VPoE を務めている pospome です。 (´・ω・`) やりたことはたくさんあるけど、できない 働いていると、やりたいことがたくさんでてくる。 あれもやりたい、これもやりたい、自分のタスクリストには、そんなものが多く載っている。 さらに、やろうとしていることの難易度が高い場合、そう簡単に物事は進まないし、結果も出ない。 中長期的に取り組んで、結果を出す必要がある。 しかし、それ以外にも "やらなければいけないこと" があるので、 自分がやりたいと思っていることに割ける時間というのは、意外と少ない。 あれもこれもやろうとして、ふと気づくと、何もやらずに3ヶ月経過していました・・・なんてことも少なくない。 なんとなーく仕事をしていると、こーゆーことの連続で、組織をぐっと強く

今まで面接をしてきて「この人優秀だなー」と感じる人になんとなーく共通点があるような気がしたので、 それを書いてみようと思った。 面接対象の職種について 「この人優秀だな」と感じる人はどんな人か? 自分で課題を見つけて、解決した人 大きなインパクトを与えた人 視座を高く持ち、行動することを意識しよう まとめ 宣伝 面接対象の職種について 自分が面接するのはエンジニアとEMです。 「この人優秀だな」と感じる人はどんな人か? 優秀だと感じる人について説明する。 自分で課題を見つけて、解決した人 面接を通して、候補者の今までの業務内容を確認するときに、"自分で課題を見つけて、解決した人" は話の深さが違うなーと感じる。 具体的には "なぜその課題が存在したのか", "その課題を解決する際にどのようなことを考えたのか", "実際にやってみてどうだったか" みたいなことを聞いていくが、 その課題に当事

Vibe Coding をしてみた背景 Copilotをどのように使ったか? 実装系 質問系 問題点を探す系 感想 作業効率は良いと思う 意外と楽しい 疲れない AIの作業を待っている時間を有効活用できる??? 誰でも品質の高いコードが書ける? エンジニアとしての価値の出し方が難しくなる 実装が複雑で込み入ってくるとどーなる? まとめ 宣伝 Vibe Coding をしてみた背景 ちゃんと触ったことないので、触ってみたいなという気持ちになったのがきっかけです。 以前 GitHub Copilot Edit を使って TypeScript を書いたことがあって、 簡単なアプリケーションであれば、動くものを作ることが可能なことは分かっていました（結構衝撃的でしたけど）。 ただ、自分は TypeScript 初心者なこともあり、Copilot が書くコードの良し悪しは分かりませんでした。 そこで

単なる感想です。 背景 緊急なことに振り回されていると組織の成長が頭打ちになる どのように時間を作るか? まとめ 宣伝 背景 最近EMに「"緊急じゃないけど、重要なこと" に取り組めるかどうかが重要です」みたいな話をしたので、ブログに書いておこうと思う。 緊急なことに振り回されていると組織の成長が頭打ちになる 自分が "今やらなければいけないこと（緊急なこと）" はどのくらいあるだろう? これは立場によって変わると思う。 ICであれば、日々の開発業務や運用業務が支配的になるので、"緊急なこと" が多くなる。 一方でCTO, VPoEはそういった業務にはタッチしないので、どちらかというと "重要なこと" に取り組み、組織をより成長させるための何かに時間を割くべきである（CTO, VPoEの役割は会社のフェーズによって変わるので、必ずしもそうとは限らないけど）。 EMはICのように開発アイテム

単なる感想です。 裁量を持つ/持たせると人は成長する 裁量を持つ/持たせると、人は考える機会が多くなったり、深く考えるようになる。 これによって自身の意思決定が成功しても、失敗しても、良い知見となり、強くなっていく。 単に言われたことをやっているだけだと、このサイクルが働かないので、強くなるスピードが鈍化する。 自分は「立場が人を作る」と思っていて、実際に人が育った様子を見てきたし、自分もそうだなと感じる。 この「立場が人を作る」というのは、裁量を与えることによる人の成長だったんだなと、最近ふと思った。 どの程度裁量を持たせるか では、「裁量を持たせればいいのか」というと、当然そーゆー簡単な話ではない。 その裁量を与えるに相応しい能力がないと、何も分からず意思決定をして、成功も失敗も「なぜこうなったのか分からない」みたいな感じになる。 ただこなしているだけで成長するかどうかがギャンブルにな

単なる感想です。 セカンドラインマネジメントをやっているという話 セカンドラインマネジメントは難しい 組織を制御しきれない感覚 優秀な人材は大事 まとめ 宣伝 セカンドラインマネジメントをやっているという話 セカンドラインマネジメントというのは、ファーストラインマネージャーをマネジメントするポジションのことで、いわゆる部長以上のポジションが該当する。 カミナシのエンジニア組織は以下のような体制になっているので、VPoEの自分はセカンドラインマネジメントをしていることになる（セカンドラインマネージャー）。 VPoE（セカンドラインマネージャー） ↑ EM（ファーストラインマネージャー） ↑ IC セカンドラインマネジメントは難しい 実際にセカンドラインマネジメントをやってみて "難しいな" と感じる（自分は前職でファーストラインマネージャーだったので、余計にそう感じるのかもしれない）。 とい

最近TS, React の勉強をしているのですが、その過程で思いました。 単なる感想です。 今までのキャリアパス 自分のことを知らない人もいると思うので、自己紹介がてら自身のキャリアパスについて簡単に説明します。 ソフトウェアエンジニアとしてのキャリアを積んだ後、 2016年より株式会社ディー・エヌ・エーでソーシャルゲームプラットフォームの開発に携わる。 その後、2018年より株式会社メルペイでテックリードとして認証認可基盤の開発・運用を担当。 2020年に入社した合同会社DMM.comではアーキテクトとして 100名規模の開発組織で技術戦略を主導する。 2024年10月に株式会社カミナシに入社し、2025年1月 VP of Engineeringに就任。 簡単に言うと "IC -> テックリード -> マネージャー/アーキテクト->VPoE" という感じで、 新卒から今までエンジニアリン

単なる感想です。 タイトルの通り、カミナシという会社において自身が納得いく働きができていないと感じているので、 それについて書こうと思います。 posopmeの経歴について カミナシのVPoEは何をする人なのか? 何に納得がいっていないのか? どうすれば納得いく働きができるようになるのか? そもそもそういった動きを求められているのか? 実はあまり悩んでないし、やりがいはある まとめ 宣伝 posopmeの経歴について サクッと説明すると以下になります。 ソフトウェアエンジニアとしてのキャリアを積んだ後、 2016年より株式会社ディー・エヌ・エーでソーシャルゲームプラットフォームの開発に携わる。 その後、2018年より株式会社メルペイでテックリードとして認証認可基盤の開発・運用を担当。 2020年に入社した合同会社DMM.comではアーキテクトとして 100名規模の開発組織で技術戦略を主導す

1日中仕事をしていると進捗は出るかもしれないが、心が荒んでいくので、ある程度の遊びは必要かなと思う。 遊びの一例は以下のような感じ。 チームメンバーとの雑談 ちょっとした不具合修正 業務とは関係ない調べ物 挙げればキリがないけど、こういった遊びが仕事に対する気持ちの回復につながったり、自己成長につながったりする。 自分がプレーヤーのときは "業務とは関係ない調べ物" をよくしていた気がする。 仕事に疲れてきたら、ツイッターを少し眺めて、面白そうな技術を見つけたら、それをちょっと調べる（時間にすると数十分かな）。 こーゆー遊びの積み重ねで業務によって "成長する余地がない部分の成長" を獲得できたりする。 遊びが多すぎると業務に支障が出るので、程度が難しいんだけど、こーゆー部分も考慮して仕事をしつつ、結果を出したいなーと思いました。 今は組織を作る側なので、そーゆー組織を作りたいな・・・って

以下のエントリーで「書籍を読むときにメモを取っているんだけど、重い要約みたいな感じになっていて、読書スピードが遅い」って話をしたんだけど、 最近はそれを少し変えた。 www.pospome.work 具体的にどうしたかというと、以下の2ステップに分けるようにした。 Step1. 本を読む Step2. 再度本を読みながら要約する Step1で本を読むときは、さらっと、なんとなーく読む。 "パラパラめくる感じ" って言うと言い過ぎなんだけど、 「どーせ Step2 で読むことになるしな」って感じでサーッと読む。 これによって本を読むスピードが早くなる。 今までは要約するために1文字1文字ちゃんと読んでいたけど、 それが不要になったので心理的ハードルが下がり、 テキトーに読んでいる。 要約する必要ないので、Kindleを使って寝転がりながら読んだり、電車の中で読んだり、読書時間が増えた。 St

自分は本を読むときに "気になった部分" を Google Doc にメモしている。 メモをする目的としては以下の2つ。 本を後で見返すときにメモを読むだけで済むのでタイパがいい。 メモには自身の感想や意見も書くので、あとで見返したときにそれ自体が参考情報として活用できる。 メモをすることで記憶の定着率が良くなる気がしなくもない。 ただ、10年以上コレをやってきた割には本を後から読み返す機会がほぼないし、 記憶の定着率が上がった実感もない。 そして、なにより メモといいつつもほぼ要約レベルのボリューム感のあるものになるので、要約に時間を取られ、本を読むスピードが遅い。 なんかコスパ悪くね? と思ってきた（今更だけど）。 こんな背景もあり、最近はメモせずに本を読むことも多い。 みなさんはどーゆースタイルで本を読んでいるのでしょうか・・・?

TiDBを触ってみて個人的に面白いと思ったものを雑にまとめます。 TiDBのことはある程度知っている人向けの話です。 HTAP（TiFlash） リソース制御機能 Stale Read Follower Read プッシュダウン レコードTTL コメント構文 sync-diff-inspector ローカルPCでTiDBを起動する まとめ HTAP（TiFlash） TiDBといえば、HTAPが有名だと思う。 https://docs.pingcap.com/ja/tidb/stable/explore-htap https://docs.pingcap.com/ja/tidbcloud/tiflash-overview TiDBが苦手とするOLAPを高速に処理するために、 TiFlashという列指向NoSQLを外付けし、 OLAP系のクエリをそこに対して実行するという、 なんとも力技感が

最近「いかに運用作業に手を抜くか」というのを考えているので、なんとなーくアウトプットしてみようと思う。 運用作業とは? 運用作業はゼロが理想だけど、そーもいかない 運用を頑張りすぎてしまうエンジニア pospomeはどうしているか? まとめ 運用作業とは? 自分が想定する "運用作業" というのは機能開発に関係ない作業全般である。 例えば以下の作業は "運用" にカテゴライズしていいと思う。 ソフトウェアのバージョンアップ ユニットテストの実装・保守 問い合わせ対応 リファクタリング 運用作業はゼロが理想だけど、そーもいかない 自分は運用作業がゼロになるのが理想だと思っている。 可能であれば、機能開発にすべての工数を投じて、自身が開発するプロダクトを進化させていきたい。 ただ、運用作業をゼロにするのは不可能である。 ソフトウェアのバージョンアップは定期的にしなければいけないし、リファクタリ

以下の記事でマイクロサービスアーキテクトグループについて紹介しているが、 SREチームのアウトプットをここにまとめる。 www.pospome.work アウトプット一覧 DMMプラットフォーム ゼロから始めるKubernetes運用 課題と改善 DMMプラットフォームのマイクロサービス戦略 オーナーシップの落とし穴 マイクロサービスとk8sにおける責任境界設計とリソース管理 マルチテナント型EKSを活用したプラットフォームエンジニアリングの光と闇 マルチテナントKubernetes環境のKubernetes External Secrets が非推奨になるので External Secrets Operatorへ移行した話 社内で提供しているマイクロサービスの参考実装について Amazon EKS に Node Local DNS Cache を導入した際にハマった話 GKEでCloud

最近「マイクロサービスって大変だな」と感じることが多いので、書いてみた。 単なる感想です。 pospomeのマイクロサービス歴 面倒なのは技術ではない モノリスだと厳しい 楽しくもある 宣伝 pospomeのマイクロサービス歴 以下の企業で7年ほどマイクロサービスに携わっている。 DeNA（ゲームプラットフォーム） メルカリ（認証認可基盤） DMM（DMMプラットフォーム） DeNA, メルカリではサーバサイドエンジニアとして仕事をしていて、 DMMではプラットフォーム事業本部という120人のエンジニアが在籍する開発組織のアーキテクトとして仕事をしている。 それぞれの会社で開発の規模感、開発体制、自分の役割などが異なるので、 直接比較できないが、やはりポジション的に今のDMMが一番大変だなーと感じる。 面倒なのは技術ではない マイクロサービスというと "分散トランザクション" とか "通信

自分はDMMプラットフォーム内のマイクロサービスアーキテクトグループという組織の責任者をしているが、 最初に比べると組織がそれっぽく拡大したこともあり、 ここ最近テックリードを立てる機会が増えてきた。 一度自分がテックリードに求める役割と適切なチームサイズについてアウトプットしてみようと思う。 DMMプラットフォームのマイクロサービスアーキテクトグループとは? pospomeがテックリードに求める役割 技術領域をリードする プロジェクトマネージメント 他チームとのコミュニケーション チームメンバーの評価 なんだかんだで総合力 pospomeがテックリードに求めない役割 ピープルマネージメント よく分からない政治的なコミュニケーション 適切なチームサイズについて 新規チーム設立を考慮する場合 おまけ：テックリードに求める役割と適切なチームサイズ以外のあれこれ No.2 の重要性 立場が人を作

DMMプラットフォームではアラートモニタリングにDatadogを利用しているが、 最近Sentryを導入しようと思っている（自分のチームだけ2年前くらいから先行して導入しているけど、良さそうなので組織全体で利用しようと思っている）。 この記事はDMMプラットフォームのエンジニアにSentryを紹介した際のドキュメントを加筆修正したものである。 Sentryとは? なぜSentryを導入するのか? Sentryの機能紹介 エラートラッキング機能 1. エラーをグルーピングしてくれる 2. グルーピングしたエラーごとに対応優先度を決めることができる 3. グルーピングしたエラーごとにリクエスト情報、クライアント情報を可視化してくれる 4. エラーごとに対応記録（Activity）を管理することができる 5.Datadogでは補足しづらいエラーを可視化することができる アプリケーションモニタリン

"Cloud Operator Days Tokyo 2022" の登壇資料です。 トークなしのスライドだけでは内容が伝わりきらないとは思いますが、一応公開しておきます。 20minの発表にも関わらず、"ゼロから" というテーマにしてしまったので、話をまとめるのに苦労しました。 結果的に広く薄い内容になってしまったのですが、 なんとなーく自分がやっていることを伝えることはできたかなと思います。 ここで紹介している課題は "ゼロから" という関係上、初期のものが多いですが、 現在は別の課題があったり、実は改善しきれていない課題もあったり、問題は山積みです。 speakerdeck.com DMMプラットフォームのマイクロサービスアーキテクトチームではサーバサイドエンジニアとSREを募集中です。 興味のある方は連絡ください。 これまだ募集しています。GKEとEKS（GCPとAWS）両方触りたい

エンジニアのスキルレベルチェックという文脈で System Design Interview が気になっていたので、自チームのエンジニアにやってみた。 System Design Interview とは? どうやって実施したのか? 実際にやってどーだったか? エンジニアとしてのレベル感がそのまま結果として出る傾向にある コミュニケーション能力 得意分野と不得意分野が明確に出る 出題する側も難しい Spannerへの圧倒的な信頼 まとめ System Design Interview とは? ググれば出てくるので説明は割愛します。 どうやって実施したのか? チームメンバーには System Design Interview のことは伏せて、 ミーティング開始時に「System Design Interview をやります」って感じで始めたので、 System Design Intervie

自分はDMMプラットフォームのマイクロサービスアーキテクトチームというチームのテックリードをしているが、 このチームが "DMMプラットフォームの組織的な技術戦略を策定、実行する" という目的を持っているということもあり、 普段の業務でDMMプラットフォーム内の各チームとやりとりすることが多い。 その中でも "成果物のレビュー" が自分の作業時間を圧迫し始めたので、同期レビューを導入した。 レビュー対象の成果物は? レビュー多すぎ問題 同期レビューとは? 同期レビューのメリデメ メリット デメリット そもそも守備範囲が広いのが問題 宣伝 レビュー対象の成果物は? 現在は主に以下をレビューしている。 DMMプラットフォーム内の Product Requirements Document(PRD), Design Doc 自チームの成果物 他チームのGoのコード PRD, Design Doc

k8s のCDツールがいくつかあるので、それらの特徴についてまとめる。 一応CDツールの定義は"k8sにWebアプリケーションをデプロイするツール"を想定しているが、 k8sにおけるデプロイはマニフェストファイルを apply することなので、 そういったものはすべてCDツールとみなして調べた。 すべてのツールをちゃんと調べたわけではないので、ものによってはサラッとした紹介になっている。 Flux Tekton(Tekton Pipeline) Jenkins-X PipeCD GCP Cloud Deploy AWS Code Pipeline Spinnaker Pipeline & Stage 動的なパイプライン Managed Delivery Spinnaker を使いこなせるか? ArgoCD Single Source of Truth(SSOT) 複雑なCDパイプラインは作

DatadogのMonitorでSlackに通知を送る際にUserGroupへのメンションをセットしようと思ったが、 以下のようにSlackのUserGroupのIDで指定する必要があるのでUserGroupのIDを取得した。 <!subteam^12345> https://docs.datadoghq.com/integrations/slack/?tab=slackapplicationus#-mentions-in-slack-from-monitor-alert Datadogのドキュメントには以下のSlackのAPIを利用してIDを取得するように書いてある。 usergroups.list method | Slack 一応APIを使ってみたが、usergroup名でフィルタリングできなさそうなので、結局APIからIDを取得することは諦めた。 すべてのusergroupを取得し