10年エンジニアリングマネージャーをやって気づいた4つの大事なポイント 【EMはもっと自由でいい】 - MonotaRO Tech Blog
はじめに ※この記事はEngineering Manager Advent Calendar の22日目の記事になります。前日はmtx2sさんの技術的負債に対するマネジメントの記事でした。個人的には「負債上限」「負債ベースライン」の考え方良かったです。 こんにちは。モノタロウでエンジニア組織のマネージャーをしております普川(@taipuka0)です。 自分は前職から通算10年以上してエンジニアリングマネージャーを続けた後、現在モノタロウでは8人のEMのみなさんと日々ソフトウェア・エンジニアリングの現場でマネージャーとして課題解決に向き合っています。これまで色々な壁にあたり、試行錯誤を繰り返して来ました。EMの難しさを痛感したことも多々ありました。 なぜEMが難しいのか？その一つとして、エンジニアからEMにジョブチェンジした際のギャップというのがあると思います。同じチーム、現場にいたとしても
エンジニアが改善に取り組んだ、スカウト運用のナレッジを公開 - Gaudiy Tech Blog
こんにちは。エンタメ領域のDXを進めるブロックチェーンスタートアップ、Gaudiyでバックエンドを担当しているkei（@kei32bit）です。 エンジニア採用は、どの企業も苦戦しているのではないかと思います。Gaudiyでも今年の4月頃から本格的にエンジニアのスカウト運用を始め、エンジニアと人事が協力して改善を進めてきました。 最初は苦戦していましたが、徐々に「どのようなスカウト文を書けば返信が返ってきやすいか」「エンジニアと人事でどう連携すると良いのか」がわかってきて、一時は週平均で20%近くまで低迷していたスカウト返信率が、ここ数週間は35〜50%にまで向上しています。（もちろん波はありますが、9月は月平均でも41%でした。） そこで今回は、「採用に関わっていきたいけど、どう関わればいいのかわからない…」「スカウトの返信率を高めたい」といった課題感をもつ方々のご参考になればと思い、G
組織の技術的負債の返済はなぜ進まないのか？ “工数確保の合意”に関わる意思決定層と現場視点の違い
クラウドネイティブ技術を日本にも浸透させることを目的に開催された「CLOUDNATIVE DAYS Spring 2021 ONLINE」。ここで原氏が「技術的負債とステークホルダーと説明責任と」をテーマに登壇。まずは、技術的負債とは何か、組織における技術的負債返済までの構図について紹介します。 組織と個人それぞれの技術的負債の解消方法 原トリ氏（以下、原）：こんにちは！ 今日はこんな話をします。（スライドを見て）なんだか面倒くさそうなキーワードばかり並んでいますね。どれも避けて通りたくなるものばかりです。 はじめまして。こんにちは。Tori、あるいは原トリと言います。ふだんはAWSという会社で、AWSのコンテナサービスをよりよいものにするために、いろいろな仕事をしています。 今日はタイトルのとおり、こんな話をしていきます。まずは「技術的負債って何でしたっけ？」という話を軽く整理していこう
【HR Tech】「複数システム x 複数体系 x 独自ルール 」の超混沌とした暗黙知を整え、適切な権限設定で形式知として提供する仕組みづくり | BLOG - DeNA Engineering
2020.08.03 カルチャー・環境 【HR Tech】「複数システム x 複数体系 x 独自ルール 」の超混沌とした暗黙知を整え、適切な権限設定で形式知として提供する仕組みづくり by Masaki-Sawamura 概要と想定読者 この記事ではDeNAにおける人事領域でのエンジニアリング事例を解説します。DeNAでは2018年４月より内製のテクノロジーチームを置き、現場のマネジメントで活かされるよう、暗黙知を形式知にするというテーマでとりくんできました。人事情報は基幹システム、勤怠、給与、会計などなど様々なシステムとの連携が必要です。そしてそれらはどれも独自のローカルルールや特殊事情を抱えています。データ集約自体は数年前からとりくんできていましたが、何度も改修を経て各処理が複雑にからみあい、頻繁に不具合がおきる状況となっていました。まず基盤としてそれらのアーキテクチャを整え、さらに、
正しさが、組織の息の根を止めていく。｜市谷 聡啓 (papanda)
新しい事業アイデアを育てるプログラムで、どうにかひねり出した仮説を経験豊富な上層部からコテンパンに叩きのめされる。珍しいことではない。よくある構図だ。プログラム伴走をつとめると、こういう局面を必ずといって良いほど目の当たりにする。 あいまいで、何も筋道がみえない中で、それでも仮説を整えて、どうにか最初の段階を乗り越えようと（この手のプログラムはステージ制の設計が織り込まれる）、手がかりを掴んで審判の場に臨む。そこで、即時ノックダウン。3カウントさえ要らない。むしろ早くリングから助け出した方が良いのではないかと思えてしまう。 洗礼の内容としては至極もっともで、正しい。さすが、年の功というべきだ。長年の領域であれば経験に裏打ちされた、確かな教えが洪水となって溢れでてくる。自分の知っている正しいことで、自分の認識している自分の役割（未熟なアイデアをバウンスするゲートキーパー）を果たそうとする。
サステナブルなエンジニア組織デザイン（前編） ～よくある設計とジレンマ～ | フューチャー技術ブログ
はじめにここ数年来で人材マーケットにおけるIT人材の需要が高まり人材獲得合戦が過熱しています。経済産業省が2018年に公開したレポート「2025年の崖」では2025年にはIT人材不足が約43万人まで拡大すると指摘しています。やや煽り気味だなーと思えるぐらいにメディアも一斉に取り上げました。「今のうちにIT人材を大量獲得せよ！」とトップダウン指示を受けて、人材の囲い込み合戦に参戦して大変になられている人事担当の方も多いだろうなと想像しています。 ※当社ではIT人材をコンサルタント＋エンジニア≒アーキテクトと呼称しますが、本稿では便宜上エンジニアと表記します。 エンジニアの住む世界迫り来る将来の危機が人材不足というエンジニアの量の問題なのかというとそれは湾曲した認識です。エンジニアはソースコードは短ければ短いほど美しいと思う人種で、クラウドネイティブな作品が増えてきてからはこぞってアーキテクチ
「1プロダクトをみんなで作る！」Rettyでの大規模スクラム(LeSS)導入記 - Retty Tech Blog
この記事は Retty Advent Calendar 2019 8日目の記事です。 qiita.com はじめに LeSSを選択した背景 LeSS展開のプロセス 1チームスクラム期(4月〜6月) テスト導入期 (7月〜9月) 全社展開期 (10月〜12月) 導入後の状況と今後の課題 おわりに はじめに マネージャーの常松です。 6月に入社して以来、開発プロセスの改善に携わってきました。 今年は大規模スクラム Large-Scale Scrum(LeSS) アジャイルとスクラムを大規模に実装する方法が刊行され、アジャイル開発・マネジメントの勉強会でも大規模スクラム(LeSS : Large Scale Scrum、以降LeSSと表記)の名前を聞くことが増えたように感じています。 しかし本だけを参考に自分の組織で大規模スクラムを導入していくのはまだまだ難しいのではないでしょうか? スクラム開
エンジニアを増やしていけば、うまくいくと思っていた––メルカリCTO名村卓氏が語る、開発組織の今とこれから
2019年9月24日、株式会社メルカリにて、エンジニア向けイベント「Mercari Bold Challenge ~CTOとエンジニアが赤裸々に語る 変化と挑戦~」が開催されました。社員数は1,800人を超え、40ヵ国以上の国から多様な人材が集まり急成長を続けるメルカリ。一方で、急成長に伴って新たな課題も生まれています。そこで今回は「Bold Challenge（大胆な挑戦）」というテーマで、メルカリのエンジニア組織の変化と挑戦について、そのリアルを語ります。プレゼンテーション「メルカリのエンジニア組織の今とこれから」に登場したのは、執行役員CTOの名村卓氏。講演資料はこちら CTO名村氏が語るメルカリのエンジニア組織の今 名村卓氏：こんにちは。CTOの名村です。僕からは、メルカリのエンジニア組織の話をさせていただきます。「今とこれから」ということで、これまでのことと、今抱えている課題と、
現役CTOが経営視点を持ったきっかけは？ CTO/VP of Eになれるエンジニア、なれないエンジニア - Part1
2019年3月6日、株式会社クライス＆カンパニーが主催する勉強会「汐留アカデミー」にて、「CTO/VP of Eになれるエンジニア、なれないエンジニア 」が開催されました。数々のスタートアップにメンターとして携わる及川卓也氏、WAmazing共同創立者でCTOの舘野祐一氏、FiNC technologiesの代表取締役でCTOも務める南野充則氏の3名が、エンジニアにおけるキャリアについて語ります。 CTO/VP of Eになれるエンジニア、なれないエンジニア 司会者：それでは、さっそく登壇者のみなさまにお入りいただきたいと思います。みなさま、拍手でお迎えください。どうぞよろしくお願いします。 （会場拍手） あらためてご紹介をさせていただきます。クライス＆カンパニー顧問の及川さんです。 （会場拍手） WAmazingの舘野さんです。 舘野祐一氏（以下、舘野）：よろしくお願いします。 （会場拍
DMM TECH VISION -DMMのテックカンパニー化に向けた、CTO松本の3年後に向けた取り組みを公開!!- - DMM inside
DMM Tech Vision -DMMのテックカンパニー化に向けた、CTOの3年後に向けた取り組みを公開!!-
FOLIO を支えるエンジニアリング組織の七転八倒記: 2018年冬 - TechとPoemeの間
この記事は何 昨日， Engineering Manager Advent Calendar 2018 にて 今，個人的に重視しているエンジニアリング組織のためのセオリーをまとめる - TechとPoemeの間 という記事を公開しました．その記事の続編かつ実践編として，本記事では， FOLIO が2017年から2018年にかけてどのようにエンジニア組織を形成し，課題を抱え，その解決のためにどのようなアプローチを取ってきて，更にその後どのような課題に取り組もうとしているかを紹介しようと思います．自分が FOLIO に入社するよりも前の頃の話も多く含まれていますので，その点はご留意ください． この記事は, FOLIO Advent Calendar 2018 14日目の記事です． adventar.org この記事は何 βリリースまで: 職能組織 プロジェクト体制 組織組成においてプロジェクト
全社的に会社用GitHubアカウントを廃止した件 - ZOZO TECH BLOG
はじめまして。2019年1月に入社したSREスペシャリストのsonotsです。最近MLOpsチームのリーダーになりました。今回の記事はMLOpsの業務とは関係がないのですが、3月に弊社で実施した会社用GitHub個人アカウントの廃止について事例報告します。 TL;DR 会社用GitHubアカウントを作るべきか否か問題 会社用GitHubアカウントの利用で抱えた問題 1. OSS活動時にアカウントを切り替える必要があり面倒 2. GitHubの規約に準拠していない 会社用アカウントを廃止した場合にセキュリティをどのように担保するか GitHubのSAML single sign-on (SSO)機能について 会社用アカウントの廃止およびSSO有効化の実施 会社用GitHubアカウントを使い続ける場合 私用GitHubアカウントに切り替える場合 Botアカウントの場合 Outside Coll
大規模スクラムにおけるプロダクトの定義 - TechとPoemeの間
単一のチームでスクラム開発を行う時と比べて，LeSS や Nexus といった Scrum of Scrums，または大規模スクラムを実践する際，「プロダクトは何か」という定義はより重要になります． LeSS の解説書である Large-Scale Scrum: More with LeSS (Addison-Wesley Signature Series (Cohn)) を読み進める中で，プロダクトの定義についての記述が結構良いなと思ったので，自分なりの例も交えつつ説明したいなと思います． なぜプロダクトの定義が重要なのか 大規模スクラムに限らず，スクラムにおいてプロダクトの定義が明確であることは極めて重要です．プロダクトの範囲が明確でなければ，プロダクトバックログがどこまでをカバーするべきかも，プロダクトバックログアイテムの受け入れ基準にどのようなことが書かれているべきかも判断すること
チームを自己組織化を促進するための「境界」の引き方 - TechとPoemeの間
最近，チームを自己組織化させるためにどうするかみたいなことをよく話したり考えたりするのだけれど，チームの自己組織化を考えるうえで，特に組織の「境界」をどこに引くかはとても重要なんじゃないかなあと思うので，今の考えをまとめておく． 基本的にはどのような組織にも当てはまる話ではあるが，主にソフトウェアシステム開発の現場での経験が元になっていることをご理解いただきたい． 自己組織化とは何か いろんな定義があると思うのだけど，自分は Scrum Alliance の認定スクラムマスター研修にて日本人唯一 *1 の認定スクラムトレーナーである江端一将さんが仰っていた定義がわかりやすいと思う． 1. チームのゴールが明確であること 2. チームの仕事や裁量の境界が明確であること 3. チームメンバーが，自分たちのやるべきことを自分たちで 0.1 秒以内に決定できること また，最近同僚と話していた中で出
今，個人的に重視しているエンジニアリング組織のためのセオリーをまとめる - TechとPoemeの間
株式会社FOLIO にてエンジニアリングマネージャーをやっています．FOLIO では この1年間，プロダクト開発を円滑に進めるための組織を目指し，様々な試行錯誤をしてきました．その中でも，適切なチーム・グループの境界設定やミッションに基づいた組織の構造化は現在進行系で大きなトピックの一つです． Engineering Manager は Engineer のマネジメントではなく Engineering のマネジメントだ，という指摘が今回の Advent Calendar でもありましたが，エンジニアリング組織の持てるポテンシャルを十二分に引き出せるかどうかを左右する変数のひとつが「組織のカタチ」だと思います。 本稿は，10月のあるタイミングで社内に向けた啓蒙活動の際に書き出した『組織づくりを考える上で知っておく必要のある概念たち』という wiki の内容を素にしています．私が今の仕事のコン
社員数が100人に迫っても社員と社長との距離を保つ「CEO Radio」の取り組み - TechとPoemeの間
今年の2月より、FOLIO という会社で働いています。本業はバックエンドシステム開発とかエンジニアリングマネージメントなのですが、それとは別に、「社長による社内向けの音声コンテンツ」の企画及びインタビュアーをやっているので、その話をしようかな、と思います。 この記事は、そんな FOLIO のアドベントカレンダー 2日目 の記事です。昨日は id:ken5scal による 『踏み台環境でテレポートする』でした。 adventar.org 組織の「100人の壁」 自分が入社したときの FOLIO は50人から60人という会社でしたが、私の加入後にも続々とメンバーが参画し、今では100人に迫ろうとしています。 一般に、組織には「100人の壁」と呼ばれる、会社規模が大きくなることで発現する組織課題があると言われています。実際に FOLIO でも、今年の初めには1フロアだけだったオフィスも3フロアま
メルカリは開発組織を拡大するためにマイクロサービスアーキテクチャを採用した（後編）。Mercari Tech Conf 2018
メルカリは開発組織を拡大するためにマイクロサービスアーキテクチャを採用した（後編）。Mercari Tech Conf 2018 メルカリはこの1年、マイクロサービスアーキテクチャにどう取り組み、実現のためになにをしてきたのか。技術面と組織面の双方に関する興味深い取り組みが、10月4日に都内で行われた同社主催の技術カンファレンス「Mercari Tech Conf 2018」のセッション「Microservices Platform at Mercari」で紹介されました。 （本記事は「メルカリは開発組織を拡大するためにマイクロサービスアーキテクチャを採用した（前編）。Mercari Tech Conf 2018」の続きです） DevOps文化を組織内に醸成する 次はDevOps文化の醸成です。 この1年で、マイクロサービスの開発者が自分たちでできるようになったことが大きくふたつあります。
メルカリは開発組織を拡大するためにマイクロサービスアーキテクチャを採用した（前編）。Mercari Tech Conf 2018
2013年から2017年のあいだ、スタートアップを含む2000以上の組織に対して、いかに組織のパフォーマンスを加速するかという聞き取り調査を行い、その調査結果をまとめたものです。 その調査結果のひとつにこのグラフがあります。 これは組織のエンジニアの人数とそのパフォーマンスを、組織の違いによって示したものです。 横軸がエンジニアの人数、縦軸はエンジニアあたりの1日のデプロイ数を指標としたパフォーマンスです。 これによると、パフォーマンスの低い組織はエンジニアが増えるとデプロイ数も減少しています。普通のパフォーマンスの組織はエンジニアが増えてもデプロイ数に変化はありません。 一方でパフォーマンスの高い組織はエンジニアが増えるほど指数関数的にデプロイ数が増えていきます。メルカリが目指しているのはここです。 これは単純にアーキテクチャをモノリシックからマイクロサービスへ移行するだけでは実現できま
メンバーがCTOを評価する「透明化」と「権限移譲」で自己組織化を――トクバイ前田卓俊CTOが取り組むエンジニアリング組織形成とは？｜TECH PLAY Magazine［テックプレイマガジン］
TOP マガジン インタビュー メンバーがCTOを評価する「透明化」と「権限移譲」で自己組織化を――トクバイ前田卓俊CTOが取り組むエンジニアリング組織形成とは？ チラシ情報のデジタル化によって、新しい買い物体験を提供するサービス「トクバイ」を開発するエンジニアたち。今や全国で51000店舗以上の小売業者が利用するまでに急成長してきたが、それに伴ってエンジニア組織をどうマネジメントしていくかが、大きな課題として浮上してきた。前田卓俊CTOが課題として取り組む、組織の「透明化」と「権限移譲」はどのようなプロセスで進んできたのか。 サービスをユーザーに届けることに燃えるエンジニアたち エンジニア組織が、プロダクトやサービス、あるいは事業の拡大スピードにいかに追いつくか、あるいはエンジニア組織その成長をいかにリードしていくのか——。これはあらゆるWebサービス企業の課題であり、とりわけ技術部門を
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
開発者のための GitHub Organization の安全な運用と 継続的なモニタリング
