こんにちは。Findy Freelanceの開発チームでエンジニアをしている2boです。 この記事では私が開発生産性を上げるために開発をする前に考えていることについて書きます。 ここで「開発をする前」というのは次のようなタイミングを指します。 PdMなどから新規施策の仕様について相談を受けたとき 起票された開発Issueを最初に確認するとき 自分がIssueを作成するとき なぜこのタイミングで考えるかというと、開発を進める上での方向性を間違える可能性を減らし後から軌道修正をしやすくするためです。 なおこの記事においては、開発生産性を「開発成果物の提供価値を投入リソースで割ったもの」とします。 いくら頑張って開発をしても、そもそもやるべきことの方向性を大きく間違えると提供価値が0に近づくため開発生産性が低下します。 特に開発が高速なチームで方向性を誤ると高速に間違った方向へ進んでしまうことに
開発生産性、上から見るか 下から見るか / development productivity and cognitive science
Another works社が主催した Developers Meetup 急成長ベンチャーが向き合う「開発生産性」 というイベントでの登壇資料です https://anotherworks.connpass.com/event/294517/ SmartHR基本機能というプロダクトにおいて取り組んできたことを認知科学の観点から見てみる、というお話でした。
株式会社overflowによって開催された、開発組織のあり方について考える1ヶ月「CTOWeek 2023 by Offers」。Week2に登壇したのは、株式会社LayerX 執行役員の名村卓氏。開発スピードを落とさないために必要な、イネーブルメント組織について話しました。全3回。1回目は、開発の生産性に大きく影響する、「チームの認知負荷（Team Cognitive Load）」について。 名村卓氏のキャリア変遷 大谷旅人氏（以下、大谷）：それでは本日のメインの名村さんのお話に入りたいと思います。LayerX 名村さん、ご登壇よろしくお願いします。 名村卓氏（以下、名村）：はい、よろしくお願いします。LayerXの名村と申します。今、LayerXでEnabling Teamという、Enablementをやっている組織にいるのですが、今日はそこでの経験と諸々含めてお話できればと思っていま
30代後半から発信活動を始めて人生が楽しくなりました。 主にC#/設計技法/マネジメント/チームビルディングの情報を発信します。 デブサミ2020関西ベストスピーカー賞1位。 Microsoft Build 2022 スピーカー。 ITエンジニア向けの月刊誌「Software Design」2022年4月号より連載記事を執筆中。 デンソークリエイト所属。発言は個人の見解。
1. アジャイルについて マネージャーが知るべき 97 のこと 株式会社アトラクタ 取締役CTOアジャイルコーチ 吉羽龍太郎 (@ryuzee) 2. イントロダクション 吉羽龍太郎 / YOSHIBA RYUTARO ▸ アジャイル開発、DevOps、クラウドコンピューティング、 インフラ構築自動化、、組織改革を中心にオンサイトでの コンサルティングとトレーニングを提供。著書訳書多数 2
プロダクトマネジメント私記
2 年前にソフトウェアエンジニアからプロダクトマネージャーにロールチェンジした。ソフトウェアエンジニア時代は割と頑張れてたし成果を出せてた気がするのだけど、プロダクトマネージャーになってからは正直かなり苦戦した。プロダクトマネージャー 3 年目を迎えてようやく仕事に自信が持てるようになってきた気がするので、振り返りを兼ねて、これから同じようにプロダクトマネージャーにコンバートしたいと思っている人の役に立てばと思って書きます。 Table of Contents プロダクトマネージャーになった理由 プロダクトマネージャーの役割 1. 何がユーザーの問題かを特定する 2. その問題を解決する製品を定義する 3. 製品がリリースされるまで開発チームに帯同し、リリースを成し遂げる 4. 製品が「正解」であったかの評価を行う 実際になってみてのギャップ プロダクトマネジメントの認知度が原因？ 一体型
https://dev-productivity-con.findy-code.io/ 株式会社SODAのセッション資料です。
エンジニアリングマネージャーの最初の学び - このロールは何なのか - yigarashiのブログ
2023/6/16付の人事異動で正式にエンジニアリングマネージャー（以下EM）になりました。2021/8に「エンジニアリングマネージャーを目指す若者の戦略」という記事を書いて明確にEMを目指し始め、2022/12には「EMキャリアを切り拓く「最強の現場リーダー」という働き方」という記事でEMに近づく様子を書きました。さらにそこから半年余り、ついに会社からも正式にEMと呼ばれることになりました。実際には3ヶ月ほど前から強くEMを志向した動きにはなっていましたが、やはり正式な職位は特別なもので、キャリアにおける重要な実績をひとつ解除したと感じています。 これほどEMというロールを志向し色々とやってきたのですから、EMとしての振る舞いもさぞスムーズに立ち上がるかと思いきや、実際にEMとして動くのは非常に難しいことでした。書籍やブログ記事を読んで頭で理解したEMという働き方と、自分がチームでEMと
スクワッド体制における留意点として、「Spotifyは "Spotifyモデル "を使っていない [3]」で以下のように述べられているように、単に方法論を真似るのではく、自分の組織と向き合い、学習して、進化し続けることが大切であると思います。READYFORにおいても日々、組織体制について議論し、改善を進めています。 ビジネスユニット、部門、チーム、マネージャーは、Spotifyの失敗した方法論に固執してはいけません。彼らはSptifyのモノマネよりも効果的に組織構造の役割と責任を伝えることができるのです。 あなたがSpotify Modelを見つけたのは、自分のチームをどのように構成するかをいつも考えていたからでしょう。でもここで止まってはいけません。学習を続けてください。 1-2. READYFORのスクワッド体制 READYFORの場合、どのようなスクワッド体制を敷いているか？ ひと
プロジェクトのスコープ調整を考える - 開発チームが信頼を獲得し変化に対応するためのアプローチ - Agile Journey
日々、懸命に開発にあたっていても、スコープ調整は否応なく発生します。Agile Journeyの読者の方も、「予定していた機能開発を削らないといけない」と判断せねばならない経験をお持ちかもしれません。こうした判断をネガティブなものではなく、「変化への対応」と捉えて前向きにプロジェクトを進めるためには、なによりも信頼が必要、と語るのは、10年以上、アジャイルコーチとしてさまざまなチームに関わってきた安井 力さんです。安井さんが信頼を積み重ね、「変化に対応できる」チームになるために必要なことを解説してくれました。 プロダクト開発の中で「あれがほしい」「いつまでにほしい」「もっと早くほしい」とリクエストされることは珍しくないでしょう。また一方で、開発側から「これは難しい」「それまでにはできない」「思ったよりも時間がかかる」と伝えないといけない状況も、これまた珍しくはありません。さまざまなツールや
事業への共感は、エンジニアの面接で加点ポイントにすべきか - SOELU Engineering Blog
SOELU株式会社というスタートアップでCTOをしている id:p__oka といいます。 オンラインフィットネスサービス『SOELU』を開発しています。 私たちがエンジニアを採用する目的は、以下の事柄に集約されます。 いまいるメンバーでは解決できない仕事を担ってもらうこと 自分たちの仕事を楽にすること この目的を果たすために、面接では以下のことを確認しています。 特定の仕事に関して、いまいるどのメンバーより上手くやれること 過度なマネジメントが必要な手間のかかる人格を持たないこと 業務の中で内省を繰り返しながら自己研鑽ができること 上記目的を達成する上で、私は「事業やビジョンへの共感を加点ポイントにしない」と決めています。 このことについて、詳しく説明してみます。 社員の事業共感やビジョン共感を大事にする会社は、その前提に「事業に共感する人は、仕事を自分事として捉え、モチベーション高く働
Title: Why we must do engineering? Forkwell #25
PMF(プロダクトマーケットフィット)の大切さと実例、はかり方、見つけ方: 基礎編｜原健一郎 | Kenichiro Hara
昨日TwitterでPMF(プロダクトマーケットフィット)に大切さについて書いたので、それについて、PMFがあるとどういう状況になるかという具体例、PMFのはかり方と見つけ方、を加えてNoteにします。この記事を書く理由は、PMFの大切さを伝えたい、多くの起業家にPMFを見つけてほしい(すなわち成功してほしい)からです。 1) 米国ではシリーズAの絶対条件がPMFでPMFがないとどんなにピカピカ優秀な経営陣でも無理。なぜならPMFが事業成功の唯一の必要条件で会社が潰れる最大の理由もPMF. PMFがあるかどうかは人に説明するものではなく、数値を見れば誰の目にも明らかなもの。Y conの教えを一言で言うとPMF見つけろ、です https://t.co/FsKxk7242d — Kenichiro Hara| DCM Ventures (原健一郎) (@kenichiro_hara) Janu
はじめにこれはEngineering Manager Advent Calendar 2023 25日目の記事です。 毎日良質な記事がアップされて、完全に俺得な一ヶ月でした。ご参加いただいたみなさんありがとうございます。 最終日の記事では、EM Advent Calendarを俯瞰しながら執筆している私のEMキャリアをふりかえり、結局のところEMとは何なのか、ということを考えてみます。 Advent CalendarにおけるEMの多様性と共通点LLM時代におけるEMという、実に2023年的な切り口から始まったこのAdvent Calendarには、実に多様なコンテンツが集まってきました。 新任EMの方の奮闘の記録、手を動かしてなんぼという考え方、スクラムとの接近、プロジェクトマネジメント的アプローチ、オブザーバビリティのEM業への援用、キャリア論・・・。 共通しているのは「マネジメント対象
Developer Summit 2020にて、「noteの決して止まらないカイゼンを支える、エンジニアリングへの挑戦」という発表をしました。そのスライドや補足など。 この発表では、下記のようなことについて話させていただきました。 ・noteチームが重視するサービスのグロースサイクルとは？ ・そのグロースサイクルを円滑に回すために、開発チームをどう組織したか？データをどう活用したか？ noteのグロースサイクル noteをどう伸ばしていくかが表現されたのがこのグロースサイクル図です。"ブロック"が達成したい指標で"矢印"が具体的な施策にあたります。作者が集まれば、コンテンツが増え、読者も集まり、さらに作者が増え……という構造です。各指標をバランス良く伸ばすことでサイクルが回り、正のフィードバックでどんどんグロースしていきます。 ですので、単一のKPIだけを追うことはしません。たとえば売上だ
Findy 開発生産性 Conference における発表です
Kyash Tech Talk #5 マネジメント LT https://kyash.connpass.com/event/265560/
エンジニア採用・組織づくりのトレンド予測2023〜開発生産性がエンジニア採用の鍵に。DX内製化や外国人採用なども〜｜山田裕一朗（CEO at Findy Inc.）｜note
エンジニア採用・組織づくりのトレンド予測2023〜開発生産性がエンジニア採用の鍵に。DX内製化や外国人採用なども〜 新年あけましておめでとうございます！ 年明けということで2023年のエンジニア採用・組織づくりのトレンド書いてみました。（どちらかという採用メインのトレンドの点、ご承知おきください！） 「採用力の強化だけでは戦えない。開発生産性の高い組織にエンジニアが集まる時代へ。」このテーマでメディア向けの発表会を10月末に開催しました。 6年以上エンジニア転職やエンジニア組織づくりに向き合ってきた中で、今大きな流れとして採用力の高い会社は開発生産性も高いという連動が始まっています。 詳細は図の通りですが、エンジニア採用自体の難易度が景気変動関係なく上がっていく中で、採用をするために良い組織づくりにも力を入れていく必要が出てきています。 また、転職するエンジニアにとっても、開発者体験・環境
エンジニア採用市場の未来予想｜shy.tnk
（Meety、日頃よりお世話になっています。ちなみに以下プレスリリースにあるカジュアル面談の解釈が人それぞれ。それ、本当にカジュアル面談ですか？という問題提起がすごく好きです。） さて今回のnoteは、中村さんの転職・採用市場についての所感に共感するポイントが多く、思わず自分も発信したいなと思い、書き始めました。 （稚拙な文章です。ご容赦ください。） 僕はエンジニアと企業のマッチングサービス「Qiita Jobs」をつくっています。2022年現在、自分が携わっている転職・採用市場においてどんな未来を予想し、これから何が起きていくのかを想像して書いてみます。今回は採用側に絞って書きます。 対象読者主にエンジニア採用やデザイナー採用など、売り手市場にて採用を担当されている方 候補者とコミュニケーションを取っている方・採用担当者 今回は採用担当者の方・採用に関わる方にお読みいただくことを念頭に文
50人で評価額2,100億円を越えたNotionに聞く、少数精鋭のプロダクト組織のつくりかた：連載「クリエイティブ組織の要諦」第3回 | CULTIBASE
50人で評価額2,100億円を越えたNotionに聞く、少数精鋭のプロダクト組織のつくりかた：連載「クリエイティブ組織の要諦」第3回 本記事は、デザインビジネスマガジン“designing”との共同企画で、双方の媒体に掲載されています。 連載『クリエイティブ組織の要諦』では、デザイナーをはじめとしたクリエイティブ職の組織作りのヒントを得るため、注目企業にインタビューを重ねています。デザイン組織立ち上げを支援してきたMIMIGURI CO-CEO ミナベトモミを聞き手に、組織デザイン／組織開発の両面からヒントを探っていきます。 第3回に登場するのは、『Notion』を開発するNotion Labs（以下、Notion）です。2020年4月に企業評価額約2,100億円に達した際、従業員数は50〜60人だったという同社（2020年7月時点）。つい先日の2021年10月9日（日本時間）には
『チームトポロジー』と、『How Do Committees Invent?』を読み直して「コンウェイの法則」について考え直した - Magnolia Tech
「コンウェイの法則」というのがある。 Melvin Conwayが『How Do Committees Invent?』という論文にて発表した考え方を指す言葉。筆者自身による論文の紹介文に書かれている、以下のくだりが端的にその内容を表している。 Any organization that designs a system (defined more broadly here than just information systems) will inevitably produce a design whose structure is a copy of the organization's communication structure. システムを設計する組織（ここでは情報システムだけでなく、より広い意味で定義する）は、必然的に組織のコミュニケーション構造をコピーした構造を持つ設計を
【資料公開】30分で分かった気になるチームトポロジー
みなさんこんにちは。@ryuzeeです。 2022年3月16日に「チームトポロジーを成功させる実践方法の探求」というイベントで登壇した際の資料を公開します。 セッション内容は、書籍の内容をかいつまんでまとめたものになっており、とりあえずチーム内や社内でチームトポロジーの概要をさくっと押さえるのに使える資料になっていると思います。 スライドを見て興味を持った場合は、是非書籍をご覧ください。紙とKindle版の双方が発売されています。 チームトポロジー 価値あるソフトウェアをすばやく届ける適応型組織設計著者／訳者：マシュー・スケルトン、 マニュエル・パイス、 原田 騎郎、 永瀬 美穂、 吉羽 龍太郎出版社：日本能率協会マネジメントセンター発売日：2021-12-01単行本：280ページISBN-13：9784820729631ASIN：4820729632
「何も分かっていないのに理想論ばかり押し付けてくる」「深い考えもなく、思いつきの無理難題を部下にふっかける」。上司に対してこんな不満を抱いた経験はないでしょうか。 部下に慕われるリーダーを目指すなら、自分が不満を感じる上司を反面教師としたいものです。今回は「想像力」という観点から、ダメなリーダーにならないために意識したい思考法をご紹介します。 想像力がないリーダーと想像力があるリーダー 上司が理想論ばかり押し付けたり、やたらと無理難題をふっかけたりするのはなぜでしょう。その人に想像力がないからです。現実に実行するのはどれだけ大変なのか、どれだけ時間がかかるのかを想像できる人ならば、部下にこのような不満を持たれることはありません。 上司に求められる想像力を、筆者は「四隅の情報から、中身を想像できる力」と表現しています。想像力のないリーダーは、部下からもたらされた断片的な情報（四隅の情報）を基
この半年で変わったものと変わらないもの - SaaS開発の現場より / Developers Summit 2020 Summer
SaaS 最重要 KPI まとめ
Do you want to subscribe to the notification email? Once subscribed, notification emails will be sent to your registered email address when the insight is republished or refreshed by the scheduling.
プロダクトの価値を最速で最大化し続けるために取り組んでいる、SaaSスタートアップのモニタリングLT https://dinii.connpass.com/event/247726/ で発表させていただいた内容です。 当日のYouTube Liveはこちらです。 https://www.youtube.com/watch?v=G7bCG4y5Udg&t=3932s --- Tebiki株式会社 https://tebiki.co.jp/ Tech Blog https://techblog.tebiki.co.jp/
【プロフィール】田村 祐樹（たむら ゆうき） 1979年生まれ。ネバーランドカンパニーにてゲーム開発に従事。gumiにて技術担当執行役員CTOに就任し、ソーシャルゲーム開発を牽引する。 その後、ディライトワークスにてFGOをはじめとしたスマートフォンゲーム開発を担当。直近ではSmartNewsにてEMを務め、その後、不動産テックのCTOに着任。 2023年9月よりestieに参画。2024年2月に事業部CTOに就任。 エンジニアリングマネージャーの仕事といえば一言で言えば何でしょうか？ マネジメント？ 1on1？ ミーティングにでること？ 違いますね。 そう、マネージャーの仕事は「マネージャーのアウトプット＝チームのアウトプット+影響を与えた他のチームのアウトプット」ですからこのアウトプットを最大化することです。 （かの有名なアンディ・グローブの定義を持ってきました） このアウトプットの影
リモートワークが一般的になり、課長をはじめとするリーダー層は、“目隠し”をされた状態でマネジメントをしなければならなくなりました。離れた場所で働いているメンバーにどう働きかけて、チームとして結果を出したらいいのか？ 「いま、リーダーに必要な伝え方」というテーマで、『AI分析でわかった トップ5％リーダーの習慣』著者の越川慎司氏と、『課長2.0』著者の前田鎌利氏が対談。本記事では、「伝える」ではなく「伝わる」プレゼンを目指すためのコツを解説しています。 「伝える」ではなく「伝わる」コミュニケーションを目指す 堀口友恵氏（以下、堀口）：今日は「伝える」イベントということで、越川さんが伝える際に意識していることにフォーカスしながら話をしていきたいと思います。テーマを3つご用意してるんですが、その後2人でディスカッションをしながら進めていただきたいと思います。 まず1つめ、「メンバーへ伝える」とい
エンジニアの「生産性」を、どのように測れば良いのだろうか？ 2014年に創業し、建設・建築現場で使えるクラウド型のプロジェクト管理サービス「ANDPAD」を提供する株式会社アンドパッド。 2020年には合計約60億円の資金調達を行い、2022年4月時点でおよそ600名の従業員を有するなど、急成長を続けている。 同社のアカウント基盤チームでは、エンジニアのパフォーマンスを解析するSaaS「Findy Teams」を活用し、組織の生産性を可視化。チームの課題を特定した上で複数の施策を実施した結果、「平均プルリクエスト クローズ時間」の指標が、120時間から23時間ほどに激減したという。 この取り組みの中心となったテックリードの柴﨑 優季さんは、改善を行うにあたり「指標だけではなくチームの観察からボトルネックを特定する」「敢えて大きな課題から取り組まない」「自分一人がチームを変えるのではなく、チ
![エンジニアの「生産性」どう測る？ 開発サイクル改善の次の一手に挑むアンドパッドの挑戦 | SELECK [セレック]](https://cdn-ak-scissors.b.st-hatena.com/image/square/fb26aea0e63f694bb12bb986be86be62f44662bb/height=288;version=1;width=512/https%3A%2F%2Fdpd29bjwmgbr8.cloudfront.net%2Fwp-content%2Fuploads%2F2022%2F06%2F06104511%2F8756cab8425c62d97a74231f915548b9.jpg)
なぜ Four Keys を改善するのか？/productivity-con-link-and-motivation
【開発生産性Conference】 リンクアンドモチベーション登壇資料（2023/07/13） 『なぜ Four Keys を改善するのか？ 〜How ではなく Why を重視したメトリクス改善活動〜』 #開発生産性con_findy #リンクアンドモチベーション #リンモチ ============================================= 【イベント情報】 ■イベントページ https://findy.connpass.com/event/283417/ ■特設サイト https://dev-productivity-con.findy-code.io/ 【株式会社リンクアンドモチベーション】 ■お問い合わせ engineer_pr@lmi.ne.jp ■Entrancebook https://note.com/lmi/n/n179505e048f4 ■テック
自己組織的な開発チームを如何にして作り上げるか / how to build self-organizing team
Developer Summit 2020 での発表資料です https://event.shoeisha.jp/devsumi/20200213/session/2417/
TOPインタビュー「3年前に戻れるなら、同じ意思決定はしない」マネージャーをなくしたサイボウズから学ぶ、フラット型組織でできないこと サイボウズ株式会社 開発本部副本部長 兼 New Business Division 副本部長 岡田 勇樹 2007年に新卒でサイボウズに入社。エンジニアとして「サイボウズ Office」や「kintone」の開発に参画。2014年に東京から地元大阪にUターンし、マネージャーとして大阪開発拠点の立ち上げを主導。現在はエンジニア採用に携わりつつエンジニア組織のマネジメントに注力。阪神タイガースのファン。 3年前、「kintone」や「Garoon」などを手掛けるサイボウズの開発本部が発した「マネージャーをなくす」宣言。多くのエンジニアを抱える大所帯で、業界でも先駆けとなる組織階層の撤廃は、大きな驚きをもって受け止められました。職能ごとに整理された組織から、プロ
議論が噛み合わないと思ったら、「問題解決の5階層」でどこがずれているのか確認する - little hands' lab
チームで議論するときに常に心がけているのが、「問題解決の5階層」です。 この図で重要なことは、 下の階層で認識が一致していないと、上の階層では絶対認識があわない ということです。 「あれ、議論が噛み合っていないな？」と思ったら、この階層に照らし合わせて認識があっていないことがないか確認しましょう。 問題認識のすれ違い 例えばこのように問題の認識の違いがあったとします。 なぜ違いが生まれたのでしょうか？ コードの保守性に関する経験や、スキルの違い？と考えてしまうかもしれません。 でも実際は、こうでした この話題に出てきたときの、認識していたコードが違うものだったのです。 このような場合、事象の認識を合わせて初めて、問題の認識を合わせることができます。 このようなケースは非常に多いです。 普段一緒の空間で仕事をしていても、個人作業をしている時間は多いほど、人によって見えているもの、体験したこと
プロダクトマネジメントを最近は生業としていますが、プロジェクトマネジメントについても必要となることが多くあります。 最近、周囲でもプロジェクトマネジメントが必要な機会を見聞きすることがあり、需要はあるのではないかと思い、私が学んできた知識や経験を書き記してみます。 仕事の終わらせ方は2つしかない プロダクトマネジメントとの違い プロジェクトマネジメントの３種の神器 プロジェクトマネージャーの仕事は不確実性を潰していくこと チームマネジメントについて 「運用でカバー」は最終手段 まとめ 仕事の終わらせ方は2つしかない 新人研修で、仕事の終わらせ方は2つしかないという話を教えてもらいました。その2つは「成果で終わらせるか」、「期限で終わらせるか」です。 （こちらの企業の研修だったと思います http://www.onevision.jp） 言い換えると、あらかじめ定めた成果物が完成した時、ある
アジャイルリーダーシップの実践 - 権力ではなく影響力でアジャイルな組織をつくるために【対談】 - Agile Journey
「アジャイルリーダーシップは、これからのリーダーシップです」 変化の速度が速まり、また、複雑化した現在のビジネス環境に適応し、価値を創出し続ける組織であるためには、旧来的ではない、新たなリーダーシップが必要になる。 こう説く書籍『アジャイルリーダーシップ』が2022年秋に刊行されました。著者であり高名なアジャイルコーチであるZuzana Šochová（ズザナ・ショコバ / @zuzuzka）さんは、自身の経験と多くの情報を融合し、変化に適応するアジャイル組織を形作るうえで重要な要素である、アジャイルリーダーシップを具体化し、それを体現するために必要なコンピテンシー（行動特性）やエクササイズを同書にまとめました。 書籍で語られる、アジャイルリーダーシップの価値はどこにあるのか、組織内で浸透させるための課題は何か、いかにして現場で発露するか。こうした「アジャイルリーダーシップの実践」を、同書
Sansanの@m_nishibaさんを雑談に誘ってお話ししている中で、自分がふと「ちょっとキャパオーバー気味なんですよねぇ」と口にしたところ、それはちょっと"臭う"兆候だよねという話になったので雑にまとめておきたい。 3行でまとめるとこんな感じ。 (一般論として) マネージャーはやることを自分で決められる裁量がある キャパオーバーではなく、"優先順位を下げてやらない"判断であるべき キャパオーバーという言葉が出てきたら一度立ち止まって優先順位の見直しをするとよい たしかに~~~~。ポロッとキャパの話してしまうことがあるんだけど、本来は何をやるか/やらないか (≒キャパ) を決めるのもマネージャーの役割なので、キャパオーバーはおかしい。キャパオーバーという言葉が出てきたら、それは優先順位づけがうまくできていないサインと思う方がよい。 とはいえマネージャーはやること多すぎて自分でキャパ決める
私は，あるスタートアップ企業でエンジニアリングマネージャー（の，1人）をしている。toB向けSaaSを提供している数百名規模の会社で，社名が少しずつ世の中に知られるようになってきたくらいのフェーズ。会社からはDirectorという肩書をもらっていて，トラディショナルな日本企業だといわゆる部門長の層にあたる。中間管理職の中では上のほうで，執行役員の下あたり，というと伝わりやすいだろうか。 様々な事情（会社が大きくなった，比較的社歴が長い，そこそこの業界経験値がある，自分の専門領域(*1)に社内のフォーカスがあたるようになり，チームをスケールする必要が出てきた，etc.）から，半ば必要にかられて，重い腰を上げてエンジニアリングマネージャーとして活動を始めたのがちょうど1年ほど前。 決してマネージャーとして早咲きのほうではなく，IT業界でのキャリアは15年くらいで，これまではずっとプレイヤー，ま
大規模にアジャイルをやるにはどうしたらいいですか？ 答え 大規模にしない 以上終わり。 先日大規模な組織レベルでのアジャイル導入をするという人と話す機会があったのだが、どうするのがいいですかね？って聞かれて出た感想が、「大規模にしない」だった。 ドメインも違う、プロダクトも違う、顧客も違う、作るチームも違う そんなチームのプロセスを同期や依存させる意味あるのかと。 「DB にアクセスするときは必要ないけどこっちの DB へもコネクション確立してね！」 って言われたらどう考えても頭おかしい人でしょ。 依存がいらないところをわざわざ依存させない。 偉い人が同じ？組織上同じだから？ 依存を増やしてどうやって変化に対応するのか？ 変化に対応するコストを高めるだけの価値がその偉い人が気持ちよくなることにあるのか？ そんなことを感じないでもない。 アジャイル界隈で悪名高い？Scaled Agile F
開発生産性カンファレンスの講演内容です。
こんにちは。エンタメ領域のDXを進めるブロックチェーンスタートアップ、Gaudiyでバックエンドを担当しているkei（@kei32bit）です。 エンジニア採用は、どの企業も苦戦しているのではないかと思います。Gaudiyでも今年の4月頃から本格的にエンジニアのスカウト運用を始め、エンジニアと人事が協力して改善を進めてきました。 最初は苦戦していましたが、徐々に「どのようなスカウト文を書けば返信が返ってきやすいか」「エンジニアと人事でどう連携すると良いのか」がわかってきて、一時は週平均で20%近くまで低迷していたスカウト返信率が、ここ数週間は35〜50%にまで向上しています。（もちろん波はありますが、9月は月平均でも41%でした。） そこで今回は、「採用に関わっていきたいけど、どう関わればいいのかわからない…」「スカウトの返信率を高めたい」といった課題感をもつ方々のご参考になればと思い、G
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
開発生産性を上げるために開発をする前に考えていること - Findy Tech Blog
プロダクトが大きくなると、なぜ生産性は下がるのか？ 『Team Topologies』から読み解く、「認知負荷」という考え方
主体性を失わせるアンチパターンをやってしまっていた話 | ドクセル
アジャイルについてマネージャーが知るべき97のこと
フロー効率を重視して「2年半でエンジニア2名→35名」の急拡大組織で高い生産性を実現した話
エンジニアリングマネージャーとしての開発力向上の取り組みついて - Qiita
エンジニアリングを推進する必要性
結局のところ、エンジニアリングマネージャーとは何者なのか｜dora_e_m
noteの決して止まらないカイゼンを支える、エンジニアリングへの挑戦｜こんぴゅ
組織をスケールさせるための Four Keys とチームトポロジー
VPoEとして1年 もっとこうすればよかった3選 / VPoE Retrospective
部下に不満を持たれるリーダーの傾向3つ、共通する原因とは
プロダクトを10年運用する チームをつくる / DevSumi2020
エンジニアの成長機会はリリースサイクルの計測にあった
エンジニアリングマネージャーのやるべきこと！ - estie inside blog
商談や1on1の一言目で「よろしくお願いします」は絶対にNG 相手の共感を引き出し、「対話」を生むプレゼンのコツ
エンジニアの「生産性」どう測る？ 開発サイクル改善の次の一手に挑むアンドパッドの挑戦 | SELECK [セレック]
「3年前に戻れるなら、同じ意思決定はしない」マネージャーをなくしたサイボウズから学ぶ、フラット型組織でできないこと
実践プロジェクトマネジメント - SaaSベンチャーで働くエンタープライズ部長のブログ
マネージャーに"キャパオーバー"はない - Konifar's ZATSU
エンジニアリングマネージャーになって1年がたった
大規模にアジャイルをやるにはどうしたらいいか、に対する答え - 海と山が好き
大規模言語モデル時代の開発生産性
エンジニアが改善に取り組んだ、スカウト運用のナレッジを公開 - Gaudiy Tech Blog
x.com
search.app
manami.nk.awe.jp
president.jp
www.gadget2ch.com
tech-blog.cloud-config.jp