「開発生産性の教科書」という本を執筆しました - Findy Tech Blog
こんにちは！ファインディ CTOの佐藤(@ma3tk)です。 表題の通り、約1年半ほどの期間をかけて「エンジニア組織を強くする 開発生産性の教科書 ～事例から学ぶ、生産性向上への取り組み方～」(以降、開発生産性の教科書)という本を執筆しました。 本日(2024年7月11日)発売となりましたので、改めて「開発生産性」に対する思いをお伝えしたり、本の内容の一部をご紹介したいと思います。 「開発生産性の教科書」のご紹介 エンジニア組織を強くする 開発生産性の教科書 本の概要は次のとおりです。 項目 詳細 タイトル エンジニア組織を強くする 開発生産性の教科書 ～事例から学ぶ、生産性向上への取り組み方～ 著者 佐藤 将高、Findy Inc. 発行 技術評論社 定価 2,860円（税込） 発売日 2024年7月11日 ISBN 978-4297142490 購入 Amazon / 楽天ブックス 全
評価の満足度を劇的にあげた秘訣。Continuous Feedbackのすすめ | メルカリエンジニアリング
誰向けの記事？ EM（Engineering Manager）の方に向けた記事です。 ただ、一般的な評価者全般にあてはまる内容を書いているので、評価を行う方なら誰でも参考にできると思います。 評価をする側ではないけど、どんな気持ちで自分のマネージャーが評価しているのか知りたい！といったエンジニアの方にも楽しんでいただけるかもしれません。 要約 メルカリエンジニア組織で、評価の負荷を削減しつつ、品質をあげるために、「Continuous Feedback」という仕組みを導入しました。 Continuous Feedbackは、通常よりも高い頻度でフィードバックを行うことで、負荷分散や、フィードバックサイクルの高速化などをはかる手法です。 導入した結果、評価に対する満足度や、評価を自身の成長に使えてると感じるようになったメンバーがとても増えました。現在では多くのEMの方が、評価に利用してくれて
優秀な技術者を追い出してしまう方法 - Qiita
若手エンジニアを不幸にしないための開発の「べからず」集 組織運営編から記事を独立させました。 優秀な技術者ほど辞めてしまいやすいのは、多くの会社に共通していることです。 この文章では、どうして優秀な技術者が辞めていってしまうのか、その理由を探るとともに、そうならないようにするための対処方法を少しずつ書き足していきたいと思っています。 マネジャーのみなさんへの前書き 会社の資産であるソースコードはきちんと管理されてますか？ 「きちんと金庫にしまってある」ではありません。 開発が進みやすく、今のソースコードはどのように品質が保たれているのかがわかるようになって 管理されてますか。 ソフトウェアの開発などで生じている課題は、どのように管理されていますか。 「去年の△月ごろに問題になっていたあの件は、結局どうなったのかい。」 「担当していた○○さんがだったら知っているんですけれども、もうやめちゃい
このタイミングで知っておきたい 開発生産性の高いエンジニア組織の特徴とは / dev-sumi-20220721-productivity-features
Findyは2021年より「エンジニア組織支援クラウドFindy Teams」の提供を開始し、数多くの経営層やマネージャー陣とエンジニア組織に関するディスカッションを重ねてきました。その中で多くの企業が開発生産性に課題感を持っており、さまざまな角度から取り組みを行っております。そこで本セッションでは、多くの組織を顧問として支えてきた広木氏をお招きし、開発生産性の高い企業の特徴を事例ベースで紐解いていきます。 Findy Teams https://findy-teams.com Developers Summit https://event.shoeisha.jp/devsumi/20220721
技術的負債は開発者体験を悪化させる - mtx2s’s blog
ソフトウェアエンジニアにとって、技術的負債が増え続けるソフトウェアプロダクト開発現場に身を置くことがどれほど苦痛なことであるか。エンジニアリング組織のマネジメントを長年担ってきて、それは強く感じるところだ。 中途採用の選考プロセスに面接官として参加し、これまで数多くの退職理由を見聞きしてきた。その中で、レガシーシステムをリファクタリング・リアーキテクティング・リライトできないことへの不満を理由として挙げるエンジニアは多かったように思う。裏を返せば、自社のソフトウェアプロダクトが技術的負債にまみれたまま放置されているなら、優秀な人材が他社に流出するリスクがあると認識すべきだ。 本稿では、技術的負債と開発者体験の関係について紐解くとともに、それに対してソフトウェアエンジニアリング組織を預かるマネージャーが取るべき行動について考えてみたい。 ※これは、Engineering Manager Ad
LINEのエンジニア組織が大切にしている3つのこと 良い開発文化を生み出すための仕組みと工夫
LINEのエンジニア組織が大切にしている3つのこと 良い開発文化を生み出すための仕組みと工夫 LINEのengineer culture #2/2 2019年12月8日、エンジニアの知的興味を満足させるエンジニアのための祭典「JULY TECH FESTA2019」が開催されました。今回のテーマは「Share! Your Engineering Culture!」。さまざまな業界で活躍するエンジニアたちが、自社の開発文化にまつわる知見を語ります。プレゼンテーション「LINEのEngineer Culture」に登壇したのは、LINE株式会社 上級執行役員 LINEファミリーサービス開発統括の池邉智洋氏。LINEが大切にしているエンジニア文化のこれまでとこれからについて語ります。後半パートとなる今回は、LINEが大切にしている3つのキーワード「Take Ownership」「Trust ＆
ITエンジニアが書く・喋る意義 | Recruit Tech Blog
本記事はRecruit Engineers Advent Calendar 2018の14日目の記事です。 こんにちは、インフラエンジニアの藤原です。 今回のブログでは、”ITエンジニアが書く・喋る意義”と題して、ITエンジニアが組織および個人での取り組み内容や、取り組みたいことについて外部発信することの意義について個人的な意見を書きたいと思います。 対象読者 自身および組織の取り組みについて情報発信すべきか悩んでいるITエンジニアの方 どんな情報発信をしているのか 自己紹介も兼ねて筆者がどんな情報発信をしているのかということを紹介しておきたいと思います。私の活動領域はDocker/Kubernetesを中心としてコンテナ仮想化です。 今年は主に以下の3つの活動(個人的活動含む)に取り組みました。 イベント登壇 Japan Container Days v18.12 への登壇 Japan
Infrastructure as Codeと組織構造
2. 吉羽龍太郎 / Ryuzee.com ✤ アジャイル開発/DevOps/クラウドに関する従量課 金型コンサルティングサービスを提供 ✤ http://www.ryuzee.com @ryuzee 3. コンテキスト設定 複雑な領域 探索 理解 反応 カオスな領域 行動 理解 反応 込み入った領域 無秩序 な領域 理解 分析 反応 明白な領域 理解 分類 反応 ✤ 1チーム〜数10チームくらいの規模を想定 ✤ とてもお硬い領域というよりは変化の大き い領域の話 4. Infrastructure as Code (1) ✤ なんらかのアプリケーションを動かすためのインフラをコードで記述すること ✤ コードで書くことで再現性を高められる (はず) ✤ コードで書くことによって、ソフトウェア開発のプラクティスがインフラにも適用可能 になる
良いテックリード、悪いテックリード - 小さなごちそう
本記事は、下記の記事の翻訳です。著者の許可を得て翻訳しました。 この記事はフォースクエアの技術的リーダーシップを簡潔に説明したガイドだ。 ベン・ホロウィッツの「良いプロダクトマージャー、悪いプロダクトマージャー」からインスピレーションを得ている。 チームワーク / Teamwork 良いテックリードはチームの一員として振る舞い、自分の成功とはチームが成功することだと考える。面倒で退屈な仕事の一部を担って障害物を取り除き、チームが100%のパフォーマンスで稼働できるようにする。チームの技術的能力を拡大し、システムの重要な知識が属人化しないように務める。 悪いテックリードは注目の集まる仕事で自分の成果を示すことを好む。その成果は部分最適に留まり、開発チームのアウトプットを増やすにはエンジニアの人数を増やすしかない、という状況から脱することができない。 技術的ビジョン / Technical v
優れたエンジニアが集まり継続的に成長する会社にする方法 ～組織を急拡大させる採用育成評価ガイド～/Concise Guide to Finding the Best Technical Talent
CEDEC2017「優れたエンジニアが集まり継続的に成長する会社にする方法 ～組織を急拡大させる採用育成評価ガイド～」講演資料です。
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
なぜ変化を起こすのが難しいのか？ - 数年以上にわたって難しさに向き合い・考え取り組んできたこと / The reason why changing organization is so hard - What I thought and faced for more than several years
ボトムアップとトップダウンの 技術組織への変革をしている話 // Speaker Deck