SREチームがNew Relicを使って AWSコスト最適化に貢献した話 株式会社ニューズピックス 安藤 裕紀 NRUG (New Relic User Group) SRE支部 Vol.3 - 2023.6.27(Tue)

プロジェクトマネジメントといえば「進捗確認」と思っている人も沢山いると思いますが、私は進捗確認という行為そのものに否定的です。 このエントリでは、進捗確認という行為がいかに無意味であるかという話および、進捗管理として行うべきことを書いていきます。 誰かのプロジェクトマネジメントの参考になればと思います。 ※ 進捗管理が不要という話ではありません 進捗確認の定義このエントリでの進捗確認は下記の定義とします。 複数人が関わるプロジェクト等において、プロジェクト等をマネジメントするべき立場にある人間が、プロジェクトの所属メンバーに対してタスクの進捗状況を口頭・テキスト等で直接確認する行為 少し難しい言葉で書きましたが「進捗どう？」といった質問およびその回答からなる一連の流れだと思ってください。 なぜ進捗を確認したくなるのかプロジェクトマネージャー（PM）の仕事のひとつに納期の管理というものがあり

フリーランスのWebエンジニアとして仕事をする上で、いつも気をつけていたことをつらつらと書いてみます。 フリーランスやっている人、興味ある人の参考になれば。 自分についての情報フリーランスのWebエンジニアを2年半 当時はRails, Vue.js, Reactがメイン(2018-2020) 情報系の大学院 → メガベンチャー2年 → スタートアップ2年からの独立 今はSALESCOREのCTO 単価は相場の最高額くらい お金の話あんまりしたくないが、みんな興味あると思うので一応 一度お世話になったFindy Freelanceさんの募集を数年ウォッチして、自分がFindyさんで受けた案件が頭を抜けて最高額だった ややボカすため最低限の目安だけ書くと、時給1万円〜（人月160万円〜）以上 技術顧問業を上手くやると、もっともらえると思う 準委任契約、月N時間稼働って感じで契約 シードA〜シリ

先日は住所の件でお楽しみでしたね。 私も楽しくなってしょうもないツイートをしたところ、@masanorkさんから有用な情報をいただいてしまいました。 異体字に加えて外字も根深いですし、日付型に収まらない住基の生年月日とか、屋号を含んだ個人事業主の口座名義とか、外国人氏名における住民登録のアルファベットと口座名義のカタカナとの解離とか、旧姓併記の例外処理とか、文字列型に刻まれたバッドノウハウの塊ですね https://t.co/GOaytijfst — Masanori Kusunoki / 楠 正憲 (@masanork) June 6, 2023 このとき、私はごく簡単な「名寄せの難しさ」の社内研修資料を作っている最中だったのですが、この情報が大変参考になりました。 一方、私だけが得をしているのがなんとなくムズムズしてきたので、ここにアウトプットしてスッキリしようと思います。 なお、住所

みなさんこんにちは。ジメジメとした日が続きますがいかがお過ごしでしょうか。SmartHRのプロダクトマネージャーryopenguinです。 今回は、私が複数のプロダクトチームを経験して学んだ「兼務のコツと反省」をお届けします。 「プロダクトに対してPMが少ない」「PMの採用に苦労している」といったみなさまの参考になれば幸いです。 なぜ兼務をはじめたか 2022年9月から、私はタレントマネジメントプロダクト「従業員サーベイ」と、現在未公開の新しいプロダクトのPMを兼務しています。 弊社では、単一のプロダクトに注力するのではなく、連携を前提に複数のプロダクトを提供する「マルチプロダクト」化を進めています。昨年の夏ごろ、とある新規プロダクトが必要と判断され、開発チームを組成することになりました。 弊社の新規プロダクトはSmartHR基本機能との連携が前提であり、その基礎的な知識が必要です。さらに

NTT Comの技術顧問が「目標設定の基本」について講演する「エンジニアリングマネージャーと目標設定」。ここで株式会社アトラクタ Founder兼CTO / アジャイルコーチ兼NTT Comの技術顧問の吉羽氏が登壇。目標設定のやり方とその運用方法について話します。 「定量的に判断できる目標が良い目標」なのかはまぁまぁ怪しい話吉羽龍太郎氏：さて、本題に入っていきたいと思います。今日はどういう方が（このセッションを）聞いているかはわからないんですが、目標設定の時に、特に上司の方からよく言われる話ってこういう話なのかなと思います。 「目標を設定する時は、達成できたかどうかを定量的に判断できるようにしましょう」。「定量的に判断できる目標が良い目標なんだ」と。（言われたことがある方は）リアクションとかで教えてくれるとうれしいです。 僕もいろいろな会社に勤めましたが、若い頃とかによく言われた記憶があり

Lizさんに届け！�AWS Jr. ChampionとTop Engineerが�書籍コンテナセキュリティを読んで感じたこと

(2025年12月) 第４部「細かすぎて伝わらない編（仮）)」を試験的に公開。現在 GitHub スポンサーの仕組みを利用したサポーター限定公開です。 (2025年12月) 書籍版の内容を基に全面的に更新。 (2024年9月) 書籍『普通の人が資産運用で99点をとる方法とその考え方』が日経BPから出版されました。詳しくはこちら。 今後もこの記事の内容は必要に応じてアップデートする予定です。質問等は、GitHub Issues までお願いします。 更新履歴 直接、ここ (Blame の結果)をみてもらうのが一番早いです。以下の更新履歴はおまけ程度です。 [2025-12-17 Wed] 第4部「細かすぎて伝わらない編(仮)」 を仮公開 [2025-12-17 Wed] 書籍版の内容に更新 (Issue #79) [2024-10-23 Wed] 目次を追加。内容は同じ。 [2024-08-0

前提 この記事は内製開発をしているSaaSの中の人であるエンジニアが、SaaSの内製ソフトウェア開発をする上での話として書いています。 前ふり 「スクラムで生産性は上がらないしリリーススケジュールが狂いまくりなんですよ」 「何が原因なんですか？どうすればいいんですか？」 という相談を受けました。 NDAを書いてから、どれどれとチームの状況を見てみました。 該当チームのスプリントゴール 該当チームのスプリントゴールはこんな感じでした。 QAフェーズのプロジェクトAを、QA作業を完了してリリースできる状態まで進める 実装フェーズのプロジェクトBを、フィーチャーの実装率を50%まで進める 設計フェーズのプロジェクトCを、要確認な点を除いて実装レディーな状態まで進める スプリントゴールが3つありますね。とても面白いですね。 思わずボンドルド卿みたいな反応をしたくなりますがここは先に進みましょう。

“曖昧さ耐性”が高い人は、何を見ているのか？伊達洋駆氏（以下、伊達）：では、神谷さんにバトンタッチしたいと思います。よろしくお願いします。 神谷俊氏（以下、神谷）：伊達さん、ありがとうございました。みなさん、こんにちは。株式会社エスノグラファーの神谷俊と申します。後半パートは、今から20分間ぐらいお時間をいただいて、私からレクチャーをさせていただきます。 先ほどもあったように（質問を）すでにいくつかいただいてますが、私のパートでも聞いてみたいことなどあれば、よろしくお願いします。 さて、私のパートを進めてまいりますね。こちらのタイトルでお話をしていきたいと思います。「“曖昧さ耐性”が高い人は、何を見ているのか？」ということですね。伊達さんのパートでは、曖昧さ耐性の概念を捉える話（をされていました）。 多義性が高くて、情報不足の状態。こういう、曖昧さの高い状態に対する耐性を持っている人はどう

Ruby on Railsの作者として知られるDavid Heinemeier Hansson（DHH）氏が自身のブログに5月4日付けで投稿した記事「Even Amazon can't make sense of serverless or microservices」（Amazonでさえサーバレスやマイクロサービスを理解できない）が話題になっています。 これはAmazon Prime Videoの技術部門が3月に自社ブログに投稿した記事「Scaling up the Prime Video audio/video monitoring service and reducing costs by 90%」（Prime Videoの音声映像監視サービスにおけるスケールアップと90％のコスト削減の実現）で紹介された、AWS Lambdaのサーバレスで作られたPrime Videoの監視サービス

転職・求人情報サイトのtype エンジニアtype 働き方 良かれと思ってやったのに…元Google人事が説く、日本の管理職がやりがちなエンジニアの心理的安全性を下げるNG行動四つ 2023.05.12 働き方 GoogleCEOチーム ここ数年で「心理的安全性」という言葉の認知が広がっている。 特に、人材不足が課題となっているIT業界においては、エンジニアのエンゲージメントを高めたり、離職率を下げたりするために心理的安全性の高い職場づくりに取り組むマネジャーも多いのではないだろうか。 しかし、「心理的安全性の高い組織」を、「対立のない組織」「チームみんなの仲が良い組織」だと考えているとしたら、認識のアップデートが必要だ。 「エンジニアが意欲的に働ける組織とは、何に対しても『いいね、いいね』と肯定することを良しとする『Nice』なチームではなく、時には否定することも恐れず、率直な意見のやり

2023/5/10(水)に開催されたTechFeed Experts Night#18での登壇資料です。 https://techfeed.io/events/techfeed-experts-night-18

以下イベントのプレゼン資料です。 https://forkwell.connpass.com/event/279042/

「プログラムを設計するときに行った技術的な判断や選択が、後日大きな制約となる」これはプログラマなら誰しも経験したことのあることでしょう。本書は、そんなプログラミングにおける各種の設計上の選択について、トレードオフの内容やそれがどのような誤りを招きうるのかという点を踏まえて紹介する書籍です。 コードの重複、エラーや例外処理、柔軟性と複雑性のバランスのようなコードレベルの選択から、APIの設計、時刻の扱い、データローカリティのようなシステム寄りの話題、またライブラリの選択、分散システムの一貫性と原子性、バージョニングのようなより抽象度の高い内容まで、さまざまなシチュエーションにおけるトレードオフの実態と、その失敗例をとり上げます。 本書は日々のプログラミングにおける解決策のヒントを得るだけでなく、より幅広い設計上の知見を広める上でも役に立つでしょう。 献辞 はじめに 1章　イントロダクション

ここ1年ぐらい感じていた「学びに関する格差」の話を書く。 最初にまとめ・勝手に学ぶ人は、自分の周囲にある「学びに使えそうな仕事」を探して自分の仕事にすることを繰り返す ・期待されて学ぶ人は、上司とかの期待に応えて新しいことを学ぶ ・「勝手に学ぶ人のスピード」＞「期待されて学ぶ人のスピード」なので、格差が開いていく ・「早く行きたければ一人で行け、遠くへ行きたければみんなで行け」が実現できない ・勝手に学ぶ人を止める理由も見つからない ・困ったなあ（解決策わからない） では詳細を書いていく。 勝手に学ぶ人：自分の周辺にある「誰も手をつけてない仕事」を発見し、自分の学びに利用するそれぞれが自分の担当範囲の仕事をしているとする。 それぞれが自分の担当範囲の仕事をしている勝手に学ぶ人は、「誰も手をつけてない」かつ「自分の学びになりそうな」仕事を自ら発見して、自分の仕事として取り組む。 勝手に学ぶ人