SREチーム発足と今期の取り組みについて - Findy Tech Blog
はじめに 皆様、はじめまして。Findyでプロダクト開発部/SREとしてジョインしました安達（@adachin0817）と申します。今年の6月に入社し、ちょうど3ヶ月が経ちました。本日は、SREチームの立ち上げに関する0から1のプロセスと、今期の取り組みについてご紹介させていただきたいと思います。 SREチーム発足 2023年までは、バックエンドチームがインフラを担当していました。しかし、サービスの拡大に伴い、バックエンドチームのリソースが不足し、SRE的な改善が十分に行えない状況が続いていました。そこで、昨年からSREの大矢とチームリーダーの下司（@gessy0129）がジョインし、現在は3名体制で活動しております。 SREチームの位置づけとミッション SREチームは横断的なSRE活動をしており、これを「横断SRE」と指しています。一方で、各プロダクトにおいてSRE的な役割を担っていたメ
抽象度の高い仕事の進め方 - Konifar's ZATSU
仕事をしていると、だんだんと抽象度の高いことを任されるようになる。 たとえば、方針も明確な小さな修正タスク => 修正方法がいくつか考えられるタスク => そもそも何をやるかから明確にしないといけないタスク といった感じで次第にふわっとした依頼になってくる。いわゆるグレード制を採用している会社において、"どれだけ抽象度の高い仕事を任せられるか" がグレードの違いの要素のひとつと言ってもいい。 抽象度の高い仕事を安心して任せられる人は何が違うのか自分もよくわからないので、自分のまわりの人がどういう動きをしているかを雑にまとめてみる。 1. なぜやるかを明確にしている わからないときはドキュメントやチャットのやりとりを探し、直接聞いたほうがよい人には自分でコミュニケーションを取っている やる理由がないと判断したら依頼者に話をして、実際にやらないこともある あとで「自分はこう言われただけなので」
プロダクト目線とエンジニア目線でストーリーを紡ぐ「全体マップ」の作り方 - KAKEHASHI Tech Blog
カケハシでエンジニアリングマネージャーを担当しているいくおです。 今回は、私たちのチームで中規模以上（複数スプリントにまたがるもの）の機能開発を行うときに作成している「全体マップ」について紹介します。 全体マップを考案したのはチームメンバーの椎葉さんなのですが、「いくおさん言語化うまいからブログにしてください！」とおだてられたので、それを真に受けて私がブログに書きます。 全体マップを作るようになってから、中規模の開発で自分たちの状況を把握しやすくなりました。また、全体マップを通して関係者全員がコミュニケーションすることで、なめらかな協働関係を築けるようになりました。こういった実体験からも、ぜひ多くの現場で全体マップを試してみたいと思っています。 では、全体マップとは一体なんなのか、どうやって活用するとよいのか、解説します。 この記事は秋の技術特集 2024の6記事目です。 ユーザーストーリ
資料生成AI「Napkin」がマジすごすぎる。
以下の記事などで既にかなり話題になっていますが、ぼくも触ってみました(使い方などの詳細はこちらの記事を参照してください)。 結論としては、マジすごくてかなり衝撃的です。すべてのホワイトカラーワーカーにとって、かなりディスラプティブなツールになるのではないでしょうか。 自分はコンサルタントでして、これまでにたくさんの資料を作ってきてスキルを磨いてきたつもりだったので、AIポン出しでここまでのものが出てきてしまうと、正直、人生について考えさせられちゃいますね。 この記事では、Napkinを使ってどういう資料ができたのか共有したいと思います。 ポストモーテムの勉強会をしたいなと思っていたので、まずはChatGPTで資料の骨子を出力し、それをNapkinに入力してみました。それで得られたのが、以下の資料です。 スライド1: タイトルスライド タイトル: ポストモーテムの教科書 副題: SREにおけ
「居心地が悪い」状態を「楽しめる」かが、自分の成長のコツかもしれない｜牛尾 剛
先日、自分の同僚の Anjana を観察していてふと気づいたことがあったのでシェアしたいと思う。彼女は比較的新しいメンバーで大学も出たてだが、めっちゃ優秀で、たまに彼女のメンタルモデルを質問して学ばせてもらっている。 新しい Http Scaling の Buddy 最近 Anjana が自分の担当している、Http Scaling の領域を私と一緒に受け持つようになってきた。この領域は最近まで私しか担当が居なかったので、Pull Request のレビューで苦労したり、一人だったら休暇もとりにくい。だから Buddy 制をとっているのだが、私の Buddy は居なかったので、Pragna が彼女をアサインしてくれた。 もちろんめっちゃくちゃ優秀な人であっても、初めてなので、 最初から難しいタスクは厳しいだろうということで、これ修正箇所もすくなそうだし、簡単そうだなぁ。というタスクが彼女に
1億人が愛用、Notion新CTOが語る「チームワークによる開発を徹底する理由」 | Forbes JAPAN 公式サイト（フォーブス ジャパン）
Notion（ノーション）は、パソコンやモバイル端末によるドキュメントにメールの作成、ユーザー個人のタスク管理や社内Wikiの活用による企業内での情報共有など、仕事や創作などに幅広く使えるコネクテッドワークスペースだ。2024年7月時点でそのユーザー数は全世界で1億人を突破している。 日本語版Notionは22年11月に正式ローンチされた。矢継ぎ早、23年2月には生成AIに対応する拡張機能が加わる。ますます充実するNotionのエンジニアリングチームを統率する、新しいCTO（チーフ・テクニカル・オフィサー）に就任したFuzzy Khosrowshahi（ファジー・コスロウシャシ）氏にこれからの戦略を聞いた。 グーグル・Slackとの違いは「スピード感」、Notionの開発環境 2024年8月現在、NotionにはWindowsとMacに対応するデスクトップアプリ、ウェブブラウザ版（Chro
テストを書く方針と原則の備忘録 - Qiita
こんにちは。サーバエンジニアのnsym-mです。普段はGoでバックエンドの開発などをしています。 最近テストに関する書籍や記事などを色々読み漁ったので、現時点での自分のテストについての考え方を備忘録として残しておきます。 今回の話はWebフロントエンドやiOS/Androidなどでも適用できる汎用的な考え方として記載していますが、ベースの文脈はバックエンド開発になりますのでそのつもりで読んでいただけますと幸いです なお、本記事では主にGoogle、『単体テストの考え方/使い方』、@t_wadaさんの発表されている考え方（いわゆる古典学派）に倣っています。 用語整理 よく使われるテストスコープ 単体テスト（ユニットテスト） 人によって定義に差がある 統合テスト（インテグレーションテスト） 結合テスト（E2Eテスト） 単体テストの定義がブレることから、スコープではなく実行時間で判断するテストサ
「詳解 AWS Lambdaコールドスタート」というテーマでClassmethod ODYSSEYに登壇しました #cm_odyssey #devio2024 | DevelopersIO
「詳解 AWS Lambdaコールドスタート」というテーマでClassmethod ODYSSEYに登壇しました #cm_odyssey #devio2024 Classmethod ODYSSEY OnlineとDevelopersIO 2024 OSAKAで「詳解 AWS Lambdaコールドスタート」というテーマで登壇させて頂きました。このブログでは登壇内容を抜粋しながら紹介していきます。 内容 コールドスタート時のLambdaのライフサイクル Lambdaのコールドスタートはざっくり以下のような流れです コールドスタートの過程で以下4つのフェーズが実行されています Create execution environment... Lambda実行環境が構築される Download code... 我々ユーザーがデプロイしたコードがLambda実行環境にダウンロードされる Start
GitHub Modelsのご紹介：GitHub上に新世代AIエンジニアを
Author Thomas Dohmke 私たちは、適切なツールとトレーニングがあれば、すべての開発者がAIエンジニアになれると信じています。GitHub Modelsは、GitHub Codespacesでモデルを使ったプレイグラウンドからコード生成、Azure経由でのデプロイまで、いかにシンプルに行えるかをお見せします。限定パブリックベータへのサインアップはこちらから。 家庭用コンピュータの黎明期から、開発者の創作の主流はコードを使ってソフトウェアをビルド、カスタマイズ、デプロイすることでした。AIの時代となった今日、機械学習モデルを活用する能力という、二次的かつ同様に重要な創造様式が急速に台頭しています。バックエンドとフロントエンドのコードと1つ以上のモデルを含むフルスタックで、生成AIアプリケーションを構築することが増えていながら、ソフトウェア開発者の多くはオープンモデルやクローズ
SLI、SLO、エラーバジェット導入の前に知っておきたいこと | sreake.com | 株式会社スリーシェイク
1. はじめに こんにちは、「信頼性は可用性ではない」を標語にしているnwiizoです。 近年、サービスの信頼性向上に向けた取り組みとして、SLI（Service Level Indicator）、SLO（Service Level Objective）、エラーバジェットという概念が注目を集めています。これらは、Google発祥のSRE（Site Reliability Engineering）プラクティスの中核をなす考え方であり、多くの組織がこのアプローチを採用し始めています。また、関連するツールも成熟し始めており、実践的な導入がより容易になってきています。 本ガイドでは、SLI、SLO、エラーバジェットを導入する前に知っておくべき重要なポイントについて詳細に解説します。各概念の定義から実践的な導入ステップ、さらには組織文化の変革まで、包括的な情報を提供します。 2. SREにおける基本
変化に強い会社であるための経営における内部品質という発想、あるいは人的資本経営 | Social Change!
ここ数年、これまでの経済活動では想像しえなかった状況が世界で起きています。この先も何が起きるかわからない、それが多くの人の感じているところではないでしょうか。意思決定が仕事の経営者にとっても受難の時代です。 そうした中で持続的に経営を続けていくためには、変化に対して柔軟に適応できる組織であることは欠かせません。外部環境は予測もコントロールもできませんが、変化に強い会社や組織作りなら取り組むことができるはずです。 それは、私たちの目指すソフトウェア開発でも同じスタンスです。変化を予測して備えるよりも、変化に柔軟に適応できるソフトウェアの開発を志向してきました。そこで大事なことは外から見えない内部品質を高めることです。 本稿では、ソフトウェア開発における外部品質と内部品質をメタファーにして、会社経営に応用することを考えてみます。そのことは昨今よく言われるようになった「人的資本経営」にも繋がる話
リファクタリングはエンジニアの福利厚生であり管理指標への影響はほとんどないんでは - きしだのHatena
おそらくリファクタリングの工数を確保する説得力のある材料がほしくて、リファクタリングの効果をどう示すか悩んでる人がいたのですが、リファクタリングって非開発者に示せるような数字だすのは難しいよねという結論になったので、そのまとめ。 工数としてはコード管理費みたいな感じで乗せるのがよさそう。 まず、リファクタリングはそれ自体では価値を示せません。人工衛星に搭載するプログラムで、動きだしたらメンテナンスできないようなコードを最後にリファクタリングしたとして、どのような価値を示せるかと考えると想像できるのではないかと思います。 なのでリファクタリングの価値というのは、その後で新しいコードを追加したり既存のコードを変更したりといった作業がどれだけ作業時間短く品質高くなったかという間接的な指標で測ることになります。 ここでまず、最初のコードを書いた人とリファクタリングする人が同じなら、そこまで保守性か
内部品質の低下を「実装前」にキャッチする「設計レビュー」のすすめ【Sansan笹川】 レバテックラボ（レバテックLAB）
Sansan株式会社 技術本部 Sansan Engineering Unit 部長 笹川 裕人 大学院でコンピュータサイエンスの博士号を取得後、リクルートを経て、2018年4月にエムスリーへ入社。AIチームでデータ基盤の整備と、バックエンド、クラウドインフラを担当。 2023年4月にSansan株式会社へ入社し、現在はSansan Engineering Unit 部長として営業DXサービス「Sansan」の強化を担う。 X Profile インボイス管理サービス「Bill One」や契約データベース「Contract One」など、近年続々と新たなDXサービスを立ち上げているSansan。それに伴ってプロダクト開発組織である技術本部も拡大し、いまや総勢500名のエンジニアと13のチームを抱える大所帯になっています。 一般的にプロダクトの数や組織の規模が急拡大すると、リソースが追いつかず
完全ペアプロは「やりすぎ」だった。失敗を経て辿り着いた、ペアプロ×開発組織の最適解【Tebiki渋谷】 | レバテックラボ（レバテックLAB）
Tebiki株式会社 取締役CTO 渋谷 和暁 神戸大学法学部卒業後、SIerを経てWebシステムの開発会社に入社。ECなどの受託開発やゲームアプリ開発のリードとして従事した後、コーチ・ユナイテッドに転職。クックパッドによる吸収合併のタイミングでCEO貴山氏とともにTebiki社を起業し、取締役CTOを務める。 GitHub Medium アジャイルなプロダクト開発において、コード品質・学習効率・チームワークの向上に効果があるとされる「ペアプロ」。1人でプログラミングすること（＝ソロプログラミング、以下ソロプロ）が主流の中で、ペアプロをどうやって組織に浸透させるべきか、困っている組織は少なくないのではないでしょうか。 かつてのTebiki社も、同じ悩みを抱えていた組織の一つでした。2018年3月に創業し、小売、製造、サービス、物流などの現場マニュアルのDXを目的としたSaaSを開発する同社
売上2兆円、ドン・キホーテ創業者が「日本経済を決定的にダメにした」と断言する“A級戦犯”とは？ | 大企業の光と影 | 文春オンライン
34期連続で増収増益を成し遂げ、売上2兆円のドン・キホーテ。無一文から日本を代表する創業経営者へ――そんな大成功の裏には「運」の存在があった。 ここでは、ドン・キホーテ創業者・安田隆夫氏の新刊『運』（文春新書）を一部抜粋して紹介する。安田氏は「運には2種類ある」と提唱する。個人にまつわる「個運」、そして会社や組織にまつわる「集団運」。この2つを徹底的に磨き上げることで現在の地位を確立したという。カリスマ経営者が生涯をかけて学んだ、人生とビジネスにおける「勝利の法則」とは？（全2回の1回目／続きを読む） 私はこれまで、「戦略や戦術を語る前に、まずは戦闘モードを全開にせよ」と、口を酸っぱくして現場に、戦う姿勢の重要性を唱えてきた（いまだに唱え続けている）。 私が嫌いなのは、戦略や戦術をごちゃごちゃ言うわりに、実際には戦闘をしないタイプの人間である。こういう輩が社内で幅をきかせるようになるのを、
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Functional TypeScript
開発者の生産性向上だけではなく職場満足度向上にも大きな効果、トライアルでの評価を経て開発現場全体に GitHub Copilot を導入
AWSのコストを４桁万円削減して円安をなかったことにした話
食べログのモジュラモノリス化戦略
なぜ宣言的 UI は壊れにくいのか / Why declarative UI is less fragile
