こんにちは。カケハシでソフトウェアエンジニアをしている椎葉（@bufferings）です。私の所属するチームでは先日「質とスピード」についてのふりかえりを実施しました。この記事では、チームが「質とスピード」をふりかえってどのようなことを話し合い、何を決めたのかご紹介します。 この記事は カケハシ Part 1 Advent Calendar 2023 10日目の記事です。今年のカケハシのアドベントカレンダーにはPart 1とPart 2があるので、両方とも楽しんでいただけると嬉しいです。 カケハシ Part 1 Advent Calendar 2023 カケハシ Part 2 Advent Calendar 2023 「質とスピード」の社内講演会 カケハシでは、9月に和田卓人さん（@t_wada）をお招きして「質とスピード」の社内講演会を開催しました。 講演中には社内のSlackで「わかる
DevFest Tokyo 2023: Google Cloudでチームで安全にデプロイをする
DevFest Tokyo 2023: Google Cloudでチームで安全にデプロイをする https://gdg-tokyo.connpass.com/event/301690/ サンプル https://github.com/sakajunquality/devfest-2023
EMのスケールとマネジメントがチームになるということ / Team Building And Scaling Engineering Managers
https://increments.connpass.com/event/300472/
フルサイクルエンジニアリングの第一歩を進める - BASE BANKでの新たな挑戦 - BASEプロダクトチームブログ
この記事は BASE Advent Calendar 2023 の9日目の記事です ごあいさつ はじめましての人ははじめまして、こんにちは！BASE BANK Divisionのフロントエンドエンジニアのがっちゃん（ @gatchan0807 ）です。テックブログに出てくるのは半年ぶりぐらいですね。お久しぶりです ちょっと大それた感じのタイトルを付けてしまいましたが、今回の記事では、先日 BASE BANK Divisionに社内公募という制度で異動して感じた BASE 組織との違いと、オンボーディングタスクでAWS ECSと格闘した記録をご紹介していこうと思います！ また、20日の記事では私も含む、実際に社内公募制度を使って異動したメンバーの体験談や感想などをまとめたものが公開される予定ですので、そちらもぜひご覧ください！ BASE組織とBASE BANK組織の違い まずはBASE BA
こんにちは。メルカリのBackendエンジニアの@osari.kです。 この記事は、Mercari Advent Calendar 2023 の9日目の記事です。 一般に大きなプルリクエストはレビューが大変で、マージまでに時間がかかります。一方で複数の小さいプルリクエストに分割するとコードレビュー待ちの間、関連する開発がブロックされることがあります。今回は機能の開発時間を短くするために、チームで試したGitのブランチ戦略の1つであるStacking手法をケーススタディを交えて紹介します。 大きなプルリクエストがもたらす問題点 大きなプルリクエストがもたらす問題とは何でしょうか？ コードレビューで読むサイズが増える コードレビュー中の修正回数が増える（可能性が増える） コードレビューで必要な知識の範囲が広がる（可能性が増える） 変更箇所が多いのでリリースのリスクが増加する プルリクエストが大
こんにちは！株式会社JMDCでプロダクト開発部に所属しているフロントエンドエンジニアの末信です。 今年、JMDCではアドベントカレンダーに参加しています。 qiita.com 本記事は、JMDC Advent Calendar 2023 9日目の記事です。 9日目を担当するにあたって、12月9日は何の日だろう?と思って調べてみると、なんとパソコンのマウスが世に出回った日でした👀気になっているマウスがあれば新調したり、お手入れしてみてはいかがでしょうか？ さて、今回の記事では部署全体でおこなっている取り組み「組織改善スクラム」の紹介をさせていただきます！ 組織改善スクラムとは？ 導入の背景 組織の変更 皆がスクラムに触れる機会をつくる 部署同士の交流 実際にどんなことを改善しているの? 組織改善スクラムの実施方法 メリット 普段一緒に業務を行わない人と話す機会ができた 1人の負担を軽減しな
概要 全般 何はともあれコストタグ Cost Explorer でリソース別にコストを見よう IaC化しよう QuickSight も使おう 稼働時間対応する際はマスタカレンダを用意したい コンピューティング、コンテナ関連 EC2 定時バッチはマネージド化しよう EBS, Snapshot, AMI, EIP を消す ECS Container Insights の有効/無効を使い分けよう 何でも Fargate を選択すれば良いわけではない Fargate スポットを活用しよう Lambda Graviton対応しよう ECR イメージサイズを抑えよう ライフサイクルポリシーを設定しよう ネットワーキング VPC VPCエンドポイント入れ忘れに注意 VPC Flow Logs のS3バケット設定に注意しよう ストレージ系 RDS スロークエリ出てないかAPMを使って確認 DynamoDB
はじめに 今回は無料で公開されているエンジニア向け修資料をまとめました。 資料の作り方も勉強になるので「勉強会で登壇している人」「企業の研修担当の人」にも参考にしてほしい内容になっています。 記事の主な対象者 研修資料を網羅的に見たい人 エンジニア初心者から中級者 研修資料の作成をしていきたい人 MIXI23卒新人研修 毎年更新をしているMIXIさんの資料は量と質が凄いです。各資料において、動画による解説もついているので、初心者でも理解しやすい構成になっています。 2023年版のMIXIさんの研修資料は下記の内容が学べます Git研修 データベース研修 設計・テスト研修 コンテナ研修 iOSアプリ開発研修 Androidアプリ開発研修 フロントエンド研修 ゲーム開発研修 Flutter研修 AI研修 セキュリティー研修 インシデントハンドリング研修 チーム開発研修 GMOペパボ GMOペパ
この記事は エムスリー Advent Calendar 2023 の 8 日目の記事です。 前日は小栗さんによる kannonを実プロダクトに組み込んで3倍高速化を達成した話 でした こんにちは、SREチームの後藤です。 エムスリーでは各チームのSREが集まって情報共有をする SRE Meetup という共有会を7月から新たに始めました。 このように情報共有のために集まるということは一般的に良くあることかと思いますが、効果的に運営していくには実は考えることが多いです。 今回はSRE Meetupの企画から実施までに意識して取り組んだ工夫を紹介していきたいと思います。 背景：エムスリーのSREを取り巻く組織事情 SRE Meetupの開催へ向けて 1. 目的意識をしっかりと持って集まる。 2. 双方向のコミュニケーションを重視する 3. 主催者が情熱をもって取り組む 実際にやってみてどうだっ
この記事は一休.com Advent Calendar 2023 8日目の記事です。 2023-09-25に入社して2か月半が経ったので、既存のWebサービスの開発にソフトウェアエンジニアとして参加するにあたって役立ったことを書いておく。 『Webサービスのソフトウェアエンジニアとしての転職活動で役立ったこと』の続編といえるかもしれない。 前提 観点 どのようなサービスかを調べる どのようにデータを保持するかを調べる どのようなコードかを調べる 「未知の未知」をできるだけ早く減らす チームの開発体制に興味を持つ 所感 前提 レストラン予約のサービスの開発に参加した 歴史が長い（2006〜） Webアプリケーションを開発する 技術スタックは転職前後で完全に変わった 前: Rails, PHP, Nuxt, MySQLなど7年 後: Rust, Next.js, Python, Microso
いろいろな事業の起ち上げやグロースに関わっていると、時々思うことがあるんで今日はぼんやりそれについて書きます。ぼんやり。 事業やサービスを伸ばすのに、ともかく手数が大事なときがあるなーと思うこともあれば、急がば回れ的に、無理せず安定させることが大切な場合もあるなあと。 色々な状況があるのは当たり前のはずですが「ともかく行動」とか「ストレッチした目標がある方が良い」なんていう固定化された考えを持っている人も多い気がします。 そんなのは事業のフェーズによって戦略や必要な考え方は変化するもので、この考え方が正しいなんてものではなく「この考え方はこの事業のこのフェーズに合っているか」という観点が割と大事なんじゃないかなと思っています。 サブスクのSaaSなんかを売っていくときには、どこからリードが来て、そこからユーザーになるまで(また、その後も)どういう変化があるのか考えてモデル化したりするのです
マネージャーに全てを決められたくない vs マネージャーには答えを持っていてほしい問題について - yo-log
Engineering Manager Advent Calendar 2023 7日目の記事です。 結論ファーストで書きます マネージャーは答えを持っていません。 大事なことなのでもう一度言います。 持っていません。 この問題ってそもそもなに？ 細かくみてみましょう。 マネージャーに全てを決められたくない マネージャーがHowまで決めてくるケースや、現場チームが決めたHowに対して口出ししてくるようなケースにおいて発生する事象です。 ものによってはWhyやWhatまで現場で考えたいんだ、というケースもあるかもしれません。 「私考える人、あなた作業する人」を越えて、プロダクトマネジメントがあたりまえになるチームを明日から実現していく方法/product management rsgt2023 - Speaker Deck こちらのスライドにあるような「私考える人」的な動きになっているマネー
要件定義、基本設計、詳細設計の流れを総復習
はじめに 📘 この記事は ラクス Advent Calendar 2023 の7日目の記事になります。 要件定義から基本設計、さらに実装や保守運用に至るまでの一貫した経験を何度か積んできましたが、毎回 「要件定義って具体的に何の項目が必要だっけ？」 「基本設計との違いって何だったっけ？」 「基本設計と詳細設計の区別って？」 といった疑問が頭をよぎってきました。 そんなわけで、これまでの経験を振り返りつつ、開発プロセスについて１からまとめていくことで頭の中の大掃除を行なっていきたいと思います🧹 この記事の対象者 🎯 開発プロセスについて学びたい方 要件定義の基本を学びたい人 要件定義と基本設計の違いがわからない人 一緒に開発プロセスについて復習したい方 前提 記事中の一部（特に要件定義や基本設計、詳細設計のサンプル）を自動生成で作成してます。一貫性の無い内容があるかも知れませんが、あく
以前会社で「Team Topologies読書会」に参加した際に、認知負荷には3つの種類があることを知りました。それ以降新しいメンバーのキャッチアップについて考える際に毎回この3つの種類について思いを馳せるようになっています。 チームトポロジー 価値あるソフトウェアをすばやく届ける適応型組織設計 作者:マシュー・スケルトン,マニュエル・パイス日本能率協会マネジメントセンターAmazon 心理学者ジョン・スウェラーが提示する三つの種類とは「課題内在性負荷」「課題外在性負荷」「学習関連負荷」です。Team Topologiesにも書いてあったようなことを元に軽く紹介します。 課題内在性負荷とはタスクに直接関連する負荷であり、プログラミング言語そのものの知識などを含むそうです。 課題外在性負荷とはそのタスクというよりは周りの環境に関連する負荷であり、覚えにくいコマンドの羅列だったりするそうです。
ベンチャー企業でQAチームを立ち上げました
1. はじめに Social Databank Tech Blog Advent Calendar 2023の5日目です。 今回はSocial Databank（以下SDB）でQAチームを立ち上げた話をします。 SDBにQAチームができたのが1年前。それまでQAという組織が存在せず、各メンバーがそれぞれの機能・コードをレビューし、リリースを行なっていました。 そのため、サービスの規模や開発メンバーが増えるにつれて以下の課題が発生しました。 品質が各メンバー・PJに依存する a. 検証項目が作成する人によって粒度が変わる b. テストコードを書くPJとそうでないPJがある c. 仕様が特定のメンバーに属人化している 品質に関するルールや規定がない a. 障害が発生しても有識者が場当たり的に対応している b. リリースに関する判定基準がない 以上の理由から、QAチームを立ち上げ組織全体の品質向
スクラムマスターを兼任して見えてきた、シフトレフトのための立ち回りとやってきたQAの活動 - freee Developers Hub
こんにちは。決済プロダクトでQA兼スクラムマスターをしているbarusです。 本日はfreee QA Advent Calendar2023 7日目です。 adventar.org 今回は「スクラムマスターを兼任して見えてきた、シフトレフトのための立ち回りとやってきたQAの活動」と題してお話させていただきます。 freeeカードUnlimitedの立ち上げ期から現在に至るまで、各チームを転々としながら、いずれもスクラムチームの一員としてアジャイルQAを行ってきました。 今年の9月からスクラムマスターを兼任しながら、日々品質とスピードの両立に取り組んでいます。 本記事ではスクラムマスターを兼任して見えてきた視点を交えながら、より早期にシフトレフトをしていくためにQAがどのように立ち回るべきか、そして実際に自分たちのチームがやってきたことをお話しようと思います。 ここではQAプロセスの最適化と
ご挨拶 本記事はリンクアンドモチベーション Advent Calendar 2023の6日目です。 こんにちは、市原と申します。 開発をしていて見通しが立たないことって多いですよね。 今までやったことのある開発をすることの方が少なくて、大体は初めてのこと、初めてのメンバー、初めてのシチュエーションだと思います。 ある種の不確実性を抱えた仕事がほとんどではないでしょうか。 そんな見通しが立たない状況を偉大にも日々開拓してきた先人がいます。 ギャルです。 ギャルはいつの世も変化を当然のように受け入れ、適応し、さらに大きな変化を生み出してきました。 その上ギャルは楽しそうです。 プロジェクト乗り越えるためにギャルマインドを憑依させればうまくいくんじゃね？と思っちゃったので、 日常のプロジェクトで使えるギャルマインド3選を紹介していきます🫰👗✨ ※この記事は筆者のイマジナリーギャルに基づいて書
こんにちは！バクラク事業部 Platform Engineering 部 DevOps チームの id:sadayoshi_tada (@tada_infra)です。趣味でボディビルディングの大会に出ているのですが、フィジークという部門で今年初めて入賞することができました。来年は更に良い成績を目指してデカい男になりたいです 💪 この記事は SRE Advent Calendar 2023 5日目の記事です。4日目は@egmcさんのIaC、あるいはインフラ抽象化レイヤー導入時に考えたらいいんじゃないかと思うことを雑多に書くという記事でした。本記事では、私とプロダクト開発チームで行った、プロダクトの課題改善の取り組みについてお話を書いていきます。 qiita.com DevOpsチームのプロダクト開発チームとの関わり方 バクラク請求書受取・仕訳チームとの取り組み紹介 CUJ を使った課題の精
本記事は BASE アドベントカレンダー 2023 の5日目の記事です。 はじめに こんにちは。 Shop to Shop チームでマネージャーをしている髙嶋です。 役割としてはエンジニアリングマネージャー（以下 EM）と言われるものを想像していただくとイメージしやすいかもしれません。 そんな私から、開発チーム内で取り組んだ10個の実験もとい取り組みについてご紹介させていただきます。 開発プロジェクトを遂行するチームの開発現場をスコープにした話になりますが、一つでも参考になるものがあれば幸いです。 ちなみにチーム構成としては PdM 1名、デザイナー1名、エンジニア5名、EM 1名（私）の総勢8名となります。 最後まで読むのが億劫になる可能性もあるので、この記事で伝えたいことだけ先に列挙しておきます。 出社（オフライン）とリモートワークの使い分けが難しいためにチームとしての活動はリモートワ
この記事は NTTコミュニケーションズ Advent Calendar 2023 の5日目の記事です。 こんにちは、イノベーションセンター所属の岩瀬(@iwashi86)です。普段は生成AIチームのエンジニアリングマネジメントをしています。 この記事では「組織の遠心力」をテーマに組織を強くする方法について書いていきます。本記事を読むことで、組織改善策の一案が得られることを狙っています。 なお、本記事は一人のエンジニアリングマネージャーである @iwashi86 の主観を多く含みます。NTT Com内には多くの考え方があり、その1つとして受け取っていただければ幸いです。 組織の遠心力って何だろう？ 同じ組織の @mizuman_ が社内講演した「最強のチームが最高のプロダクトを作る」というスライドがあります。 詳細は上記スライドをぜひご覧いただければと思いますが、チームが良ければ良いほど、プ
あなたの上司は異世界転生してきた能力者ではないし、あなたができることをあなたより上手くできる必要もない。 - フジイユウジ::ドットネット
先日、『質の高い課題解決できる人が「こうすべき」を主張すべきだけど、それが苦手な人も多いからチームで解決したら良いのでは』という雑な考えを書いたのですが、僕のブログにしては多くの人に読んでもらえました。 読んでくれた人、ありがとうー fujii-yuji.net ただ、この記事へのコメントで「質の高い決定ができない上司や社長はダメだろ」みたいな意見もそれなりに多くあって、けっこう驚いたのですよね。 僕が雑に書いたわかりにくい文章だったことが原因で誤解されてしまったのでしょうけれど、今日は補足として「部下がやれることを上司もやれる必用はないですよね」的な話を書きます。 上司が「自分ではできないからお前に頼むわ」と言ってくれたお陰で、"上司のして欲しいこと探し"をしなくて済んだ。 僕が若いころお世話になった上司はよく「自分ではできないからお前に頼むわ」と言っていました。 実際のところ、その上司
この記事はクラスターAdvent Calandar 2023の1日目の記事です。今年もやっていきましょう！ --- さて、この12/1で入社から丸5年になる。clusterというプロダクトで PM役をやりはじめてからは4年ほど。今日はclusterにとっての PM職を振り返りたい。 clusterとPM 現在 PM職は10名。1プロダクトの事業会社にしては多めの人数と言えると思う。この人数には理由がある。 clusterというプロダクトは「人類の想像力を加速する」というミッションに対して、「身体性を含めたオンライン体験」の場をユーザーの皆さんに提供している。2021年のブーム以降は「メタバース」ジャンルの参加者として語られることも多いプロダクトだけれども、この単語が説明していることはとても少ない。多人数参加型の社会空間くらいが共通認識だろうか。クラスターとしてもユーザーの皆さんや社会に対し
このエントリは、SmartHR Advent Calendar 2023 シリーズ1の3日目です。 シリーズ1の前日のエントリはalpaca sanの佐渡島の物件情報を集める方法 - alpaca- tcでした シリーズ2の前日のエントリはasonas sanのE03との戦いでした これは何 当初、Rubyを取り巻く型情報に関するツールの関係性についてまとめようと思ったのですが、既に良いドキュメントがあり、自分が満足してしまったので別の話題として認知負荷をテーマに筆をとっております。 ツールの関係性については↓のエントリをご覧ください Ruby 3の静的解析機能のRBS、TypeProf、Steep、Sorbetの関係についてのノート - クックパッド開発者ブログ 閑話休題 認知負荷という言葉、よく聞きますよね。私もよく言いがちでした。しかし、「認知負荷」という言葉をふわふわな認識のまま「
この記事は Money Forward Engineering 2 Advent Calendar 2023 の記事です。 こんにちは！tatsuo48 です。 マネーフォワードのサービス基盤本部には私が所属する Enabling SRE というチームがあります。 この記事では、以前に紹介された組織に SRE の文化を作り上げていく Enabling SREの内容にも触れながら、Enabling SRE の現在地点と今後の方向性について詳しくお話ししていきます。 Enabling SRE とは Enabling SRE の目的は組織に SRE の文化を作り上げていく Enabling SRE にある通り、以下のギャップを埋めていくことにあります。 各プロダクトの開発チームは、自分たちで開発のサイクルを回し、非機能面も含めて見るべきだと考えている。しかしながら、権限を渡されても非機能面を見て
この記事の初出は、Software Design 2023年10月号です。 リモートワークでも新人育成はできる？筆者のチームは、リモートワーク中心の開発チームで、新人育成もリモートワーク中心で行っています。 リモートワークにおける新人育成は、コミュニケーション不足になりやすいため、スキルや業務知識を習得しづらい、職場の人間関係になじめないなどのことが起きやすいと思います。 ただ、コミュニケーション不足を補うプラクティスを行うことでその課題は解消できると考えています。 今回は、新人配属後のフェーズごとに筆者のチームで行っている新人育成のプラクティスを紹介します。 配属初日 [初日にモブプロで業務を体験]新人は配属後しばらくは学習期間が必要であるため、すぐには業務に入れません。 しかし、これから学ぶことが実際の業務でどう使われるか知らずに学習を進めても効率が良くないと考えます。 そこで、配属初
1. はじめに ソフトウェア開発のチームに、新しいメンバーが入ってくることはよくあります。 以前に新卒社員がチーム入ってきた場合の育成方法を紹介しました(こちら)。 今回は、新卒社員ではなく、他の会社から中途入社か同じ会社の部署異動で来る新メンバーの話です。 (エンジニアが数百人などで規模が大きい会社の場合、部署が違うと仕事のやり方が全く変わる場合があるので、今回は中途入社と他の部署からの異動を同じように「新メンバー」として扱います) 会社や部署が変わると仕事のやり方が大きく変わるため、仕事のやり方に戸惑うことが多いと思います。 本稿では、そのような「新メンバー」を活躍しづらくしてしまうアンチパターンとその対策を紹介します。 2. 中途入社や部署異動で来た新メンバーが適応することの困難さを理解する 中途入社や部署異動で来た新メンバーが組織に適応することは、新卒社員のそれとは別の難しさがあり
SRE を立ち上げた4ヶ月後の世界
この記事は、Magic Moment Advent Calendar 2023 4 日目の記事です。 こんにちは! Magic Moment で Senior Engineering Manager 兼 SRE Engineering Manager をやっている 木村 (@ryurock) です。 Magic Moment アドベントカレンダー 4 日目では、2023年9月に SRE チーム を立ち上げた 4 ヶ月後の世界。 というテーマでアドカレやっていきたいと思っています。( ｰ`дｰ´)ｷﾘｯ SRE チームの立ち上げの経緯 遡る事、2023年7月頃に弊社が提供しているサービス Magic Moment Playbook のコアデータが立て続けに更新できない障害が相次ぎました。 Sales Operation を行う上で、大切なデータが頻繁に反映されないこの由々しき事態はユーザー様
はじめに 今年の 2023年5月に Next.js の v13.4 がリリースされ App Router が Stable になり Vercel 推奨の実装方式となりました。 さらに10月 Next Conf にて、 Next.js v14 がリリースされ App Router を代表する新機能である Server Actions が Stable になりました。 App Router はこれからのWeb開発の未来を担うフレームワークになっていくことが予想されており注目度の高い技術です。一方、これまでの Pages Router からの変更点の多さ、機能の興味深さ、設計の複雑さ、動作の不安定さなども含め、さまざまな要因でいまでもたくさん議論になっています。 今後どこかのタイミングで App Router へ対応する必要があることは明らかなものの、技術の不安定さが気になる上に、ある程度規模の
CTOのishkawaです。 この記事は10X アドベントカレンダー2023の3日目の記事です。 先日、サーバーサイドのメンバーを中心として、コードをどのように分割管理していくか話すオフサイトを実施しました。オフラインで1日中話していたこともあり、話題は色々な方向に進んだのですが、その中でもモノリス解体にトピックを絞ってシェアしたいと思います(他の話は他のメンバーが書いてくれるはず！)。 前提 10Xには4つの開発チームがあります(お買い物チーム、お会計チーム、お届けチーム、マスターデータチーム)。今年の4月にチーム分割が始まり、コードやデータのオーナーシップも各チームにアサインしてきました。 この組織移行によってオーナーシップ分割は進んでいるものの、依然としてモノリスのパッケージ(Dartのパッケージ)は大きいままで、ほとんどのコードがそこにある状態でした。領域ごとのディレクトリ分割は進
コードレビューの思想や心構え - Qiita
株式会社ブレインパッドでデータサイエンティストをしているasanoです。 この記事はBrainPad Advent Calender 2023 1日目の記事シリーズ2です。 ※シリーズ1は@fuyu_quantさんの入力プロンプトを復元する技術 #ChatGPTです！ 今日はコードレビューの思想や心構えについて書きます。 はじめに コードレビューをより生産的に進めるには単にコーディングのスキルだけでなく、そもそものコードレビューに対する思想や心構えについても一定のリテラシーを求められると考えています。 コードレビューはどうしてもロジカルな話になるため伝え方にも気を付けないとモチベーションの低下に繋がりやすいと考えています。 そうなると当然パフォーマンスも下がってしまいます。 これを防ぐために自分は「コードレビューの思想・心構え」をまとめてチームのガイドラインとして使っています。 あくまで主
認可のベストプラクティスとDDDでの実装パターン
最近、少々複雑な権限機能の開発を担当している中で、対応方針を悩んでいたことがありました。 権限機能というものは取り扱いが難しく、影響範囲が広いにも関わらず、対応漏れや考慮不足があると情報漏洩に繋がってしまいます。 また、機能拡張をしてく中でも対応漏れを起こさないようにする必要があるなど、考えることも多く頭を悩ませておりました。 そこで、認可処理の設計のベストプラクティスやDDDの実装パターンに認可処理を組み込む方法など、色々と調べていたのですが、その中でいくつか知見を得られたのでまとめようと思います！ 権限と認可 権限と切っては切れない関係にあるのが認可です。 権限はある操作を実行できる権利を指します。 それに対して、認可は操作を実行する許可を出すため仕組みのことを指します。 例えば、ブログ投稿サービスで考えてみると、以下のような感じです。 権限: 投稿者はポストを編集できる。 認可: ユ
いろんなやり方の読書会をやってみたら当日音読その場でまとめ方式が最高だった話 - Gunosy Tech Blog
こんにちは、SRE チーム マネージャーの TksYamaguchi です。 こちらの記事はGunosy Advent Calendar 2023の3日目の記事です。 前回の記事は森田さんの LLM 論文の探し方でした。 概要 SRE チームは、シニアエンジニアとジュニアエンジニアで構成されているチームで、チーム内の技術的な知識の偏りの解消や、知識のタコツボ化の解消を目的として読書会をしてきました。 その過程でいろいろな読書会のパターンを行ってきましたので、その結果を共有します。 概要 読書会開始前の SRE チームの課題感 読書会 のやり方の整理と評価の観点 やり方 評価の観点 当日音読・Slack に投下する方式 実際のまとめ 方式詳細 評価 メリット デメリット 事前に読んで Miro*1 に付箋・当日議論する方式 実際のまとめ 方式詳細 評価 メリット デメリット 当日黙読・その場
はじめにatama plus の深澤 (@qluto) です。 2019年入社で一人目のエンジニアリングマネージャーとして活動をし始め、採用・組織作り・制度づくり・技術的負債の解消といった課題に向き合いながら組織運営全般の活動を推し進め、最近その全バトンを新たな人に受け渡しました。 この記事は atama plus Advent Calendar 2023 の3日目です。 この4年間を振り返るのにちょうどいい機会だったので筆をとっています。 この文章はどんな人向け？特にスタートアップのような変化の激しい開発組織において、これから分業や仕事間の調整を図って組織をスケールさせていく必要を感じているがどのように考えをまとめればいいか探りかねている人、分業や調整をしているけれど課題を感じている人向けです。 エンジニア人数15人ほどの開発が50人ほどの体制になるまでの4年間で進めてきたことの要点をか
11月25日に開催されたISUCON13でチームNaruseJunとして参加し優勝しました。 メンバーはここ4年同じで、大学時代のサークル仲間の@sekai・@takashi・とーふとふの三人です。 昨年のISUCON12でも優勝したので、チームNaruseJunは二連覇となります。 最終スコアは468,006点でした。 スコアの推移は以下の通りです。 かなり順調にスコアを伸ばしていますね。後述しますが17時直後にめちゃくちゃ伸びているのは、ログを止めた結果です。 その他のスコアは↓ ISUCON13 受賞チームおよび全チームスコア : ISUCON公式Blog 事前準備 今年はチーム全員が忙しかったので、チームで最初に集まったのは11/14でした。 その日は30分くらいで今年の流れの確認と、素振りの日（11/18）を確定して解散しました。 ありがたいことに過去優勝チームとしてLodgeで
はじめに こんにちは、マッチング領域でバックエンドエンジニアをしているぽこひで ( @pokohide ) です。 タイミーのアドベントカレンダー2日目の記事です。 今回は、タイミーのプロダクト組織で毎週開催している技術的な雑談を行うテックトークの紹介をします。なぜ開催しようと考えたか、どのように運用をしているかなどをお話しします。 はじめに 開催の背景 毎週ゆるく開催するテックトークについて テックトークの仕組み化 会の説明や目的の共有 WINの共有 ポストモーテムの学び共有 雑談タイム やってみて さいごに 開催の背景 タイミーのプロダクト組織では、働き方の柔軟性を担保する観点などからフルリモートという働き方を選択しています。また、タイミーではチームトポロジーを採用しており、それに沿ってチーム構成などを考えています。 チームトポロジーの変遷や取り組みについてはCTOとCPO（発表当時は
こんにちは。 AI在庫管理というプロダクトでフロントエンドの開発を担当している大村です。 AI在庫管理開発チームでは、顧客に素早く価値を提供するためにフロー効率を重視した開発を行っています。 本記事では、なぜフロー効率を高めようとしているのかと、どのような取り組みによってフロー効率を高めているかについて紹介します。 リソース効率とフロー効率 生産性の効率の考え方として「リソース効率」と「フロー効率」があります。 複数人の開発者がチームでソフトウェアを開発するシーンを想定し、リソース効率とフロー効率それぞれを重視した場合の仕事の流れを単純なモデルとして表現してみました。(ここでは仕事の1つ1つをタスクと呼ぶことにします) これだけ見ると、リソース効率重視の方がムダなくタスクを消化しているように思います。 しかし、ソフトウェア開発の現場では以下のような状況が頻繁に発生します。 他の開発者のレビ
部下の力を最大限に引き出す育成をするためには、どのような関わりをすればよいのか。褒める・叱るではない「行動承認マネジメント」のノウハウを、株式会社シンプルプランの丸茂喜泰氏が解説します。本記事では、生産性の高いチームの特徴をもとに、自社でオープンなコミュニケーションを作り上げていくためのポイントを解説しました。 前回の記事はこちら 管理職が担っている3つの役割 丸茂喜泰氏：あらためて本日のゴールです。私としましては、みなさまがご自身の日頃の行動に照らし合わせた際に、「できているか？」を点検する機会にしていただければなと思って、進めていければと思っております。 では、今日のテーマである「行動承認マネジメント～褒める叱るじゃない若手社員の育て方～」をお話ししていければと思います。この話に入る前に、一応確認でございますが、今回のテーマはマネジメントです。管理職や職場のマネージャーと呼ばれるような
はじめに 本記事ではログラスにおけるスクラムマスターの考え方、そして専任化についての取り組みの現在地点をお伝えできればと思います。 なぜこのテーマを選んだか？というと、この1年を振り返る過程において、スクラムマスターという役割が改めて重要な役割を果たすのではないか？と考え、直近で専任スクラムマスターを置く取り組みを実施しておりました。 こちらの取り組みから、どんな仮説を立てたか？現在どんな状況か？などをまとめることで、同じくスクラムマスターの位置付けについて悩んでいる企業があれば参考にしていただけるのではないかと考えたためです。 この記事では私がエンジニアリングマネージャー（以下EM）として、スクラムマスターとEMの責務の切り分けをどうすればお互いがパフォームできる状況を作れるのか？という視点から話を進めていきます。 ログラスのスクラムについて ログラスでは創業時の1チームのスクラムチーム
質の低い決定しかできない上司や社長に「どうしますか」と決定を丸投げするのは悪手だよ(パート2) - フジイユウジ::ドットネット
以前、質の高い打ち手を選択できる人が判断をせず、質の低い決定しかできないような上司や社長に「どうしますか」と委ねるのはチームがダメになる要因なんよという記事を書いたのですが、今日はその逆で課題解決に必要な能力と情報を持っている人が判断をしなくても上手くいったことについて雑に語ります。 先日、会議に参加してたんですよ。 その会議では、ある課題をどう解決するか話し合って打ち手を決定するというものだったのですが、参加者のひとりが僕より明らかに専門性を持っているプロフェッショナルだったのですね。 なので僕は「どうするかは専門性のある人に決めてもらった方が質の高い意思決定になるし、僕は相手がそれをしやすいよう情報を渡すような役割に徹しよう」と考えていました。 しかし、実際の会議を進めてみると、一番質の高い打ち手を決められる能力があるはずの人が「フジイさんどうするか決めて欲しいです。」と言ってくるので
Google Cloud Japan Advent Calendar 2023 1 日目です！ 昨年の 2022 年度版 に続き、今年度版のレポートまとめをお届けします。 DORA DORA は DevOps を軸に、2014 年から 組織やチームを成功に導く能力やプラクティスを研究 能力やプラクティスから組織のパフォーマンスを予測 といった調査研究をする Google Cloud のチームです。 State of DevOps Report 過去 9 年間、延べ 36,000 人に協力いただき調査を実施してきました。実践から期待できる成果と、その成果に大きく寄与する要因を分析しています。 本記事でまとめをお届けする 2023 年度版の全文は こちら からダウンロードできます！ 2023 年度サマリー 5 行でまとめるとこんな結果です。 開発速度と製品安定性は両立できます ユーザーにフォー
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
質とスピードとゆとり - KAKEHASHI Tech Blog
Gitブランチ戦略 Stacking手法のケーススタディ | メルカリエンジニアリング
「組織改善スクラム」に取り組んでいます！ - JMDC TECH BLOG
2023年のSREチームのAWSコスト削減を振り返る - Uzabase for Engineers
【2023年版】エンジニア向け読むべき資料まとめ - Qiita
共有会をより効果的にするために考えたあれやこれ - エムスリーテックブログ
中途入社のソフトウェアエンジニアがWebサービス開発に参加するとき役立ったこと - kymmt
「この考え方は正しいか」ではなく「この状況に合っているか」で考えたい - フジイユウジ::ドットネット
認知負荷とキャッチアップ - stefafafan の fa は3つです
開発プロジェクトはギャルマインドで乗り切ろ🤟💫 - Qiita
プロダクト開発チームとDevOpsチームでのプロダクト課題改善の取り組み - LayerX エンジニアブログ
開発チームで取り組んだ働き方の実験10選（前編）〜 出社とか雑談とか - BASEプロダクトチームブログ
組織の遠心力への立ち向かい方 - NTT Communications Engineers' Blog
clusterとPM - htomine's box
認知負荷の種類と対策と組織文化について - すがブロ
Enabling SREの現在地点 - Money Forward Developers Blog
リモートワークで新人が楽しく成長できるようにする(#19)｜小島優介
中途入社や部署異動で来た新メンバーを活躍しづらくするアンチパターン - Qiita
Next js v14 で考える開発チームの事業的貢献 - とろろこんぶろぐ
モノリス解体に向けたパッケージ構成 - 10X Product Blog
スタートアップのエンジニアの集まりが"組織"になるまでの過程から学んだこと｜Qluto
ISUCON13で優勝しました(チーム NaruseJun)
技術的な雑談をするテックトークを開催して半年が経ちました - Timee Product Team Blog
フロー効率を重視した開発のすすめ - KAKEHASHI Tech Blog
“仲が良すぎる会社”は1人の影響が組織全体を揺るがすことも Googleの調査結果から考える「心理的安全性」の本質
専任スクラムマスターを置くまでの思考過程と置いてどうなったか？
DORA 2023 度版 State of DevOps Report