開発生産性を標榜して効率に拘泥するチームはゆるやかに衰退する
この記事は前作 開発生産性の可視化サービスから何を見いだして何ができるのか、あるいはすべきで無いこと に続き、開発生産性へのスタンスを整理したい2作目です。 効果・成果よりも効率を優先することは生産性か？ 開発生産性と言いながら単なるアクティビティの量や時間を見て効率改善を志してしまういくつかの状況、一部の風潮に対して疑問を呈したい。 例えば、PRやイシューの起票数などアウトプット量の高低に一喜一憂する 例えば、変更のリードタイムやデプロイ頻度の増進を過度に重視する 例えば、サイクルタイムの各時間を人間の努力のみで短縮しようとする それにも関わらず、開発がもたらしたユーザーへの効果やビジネス上の成果に無関心というのは順序おかしいよね、という話。 などと考えていたら開発生産性カンファレンス2024 - 登壇資料まとめ｜610を見る限り、近しい主旨の論説を散見するに至り、もしかしたら世間の議論
GitHub Flow with GitOpsの導入 - ZOZO TECH BLOG
はじめに こんにちは、計測プラットフォーム開発本部SREブロックの近藤です。普段はZOZOMATやZOZOGLASS、ZOZOFITなどの計測技術に関わるシステムの開発、運用に携わっています。 計測プラットフォーム開発本部では、複数のプロダクトを開発運用していますが、リリース作業はプロダクト単位で行っています。プロダクトによってローンチから数年経過し安定傾向のものもあれば、ローンチしたばかりで機能開発が盛んなものもある状態です。 複数のプロダクトを管理する上では当然の状況ですが、プロダクト単位でリリース作業手順が異なり、手順そのものにも課題がある状態でした。 本記事では、リリース作業で課題となっていた部分の紹介と、それぞれの課題に対する対応策についてご紹介します。 目次 はじめに 目次 現状 課題と対応方針 リリース作業の自動化 リリース作業の自動化をする上での必須条件の確認 自動化が必要
フルスタックエンジニアから「フルサイクルエンジニア」へ。和田卓人氏による「組織に自動テストを根付かせる戦略」（その3）。ソフトウェア品質シンポジウム2022
フルスタックエンジニアから「フルサイクルエンジニア」へ。和田卓人氏による「組織に自動テストを根付かせる戦略」（その3）。ソフトウェア品質シンポジウム2022 9月22日と23日の2日間、一般財団法人日本科学技術連盟主催のイベント「ソフトウェア品質シンポジウム2022」がオンラインで開催され、その企画セッションとして行われた和田卓人氏による講演「組織に自動テストを書く文化を根付かせる戦略（2022秋版）が行われました。 講演で、企業の業績はソフトウェアの開発能力に左右されるようになってきていること、その開発能力を高める上で重要なのがコードの「テスト容易性」や「デプロイ独立性」であると和田氏は指摘。その上で、それを実現させるような「自動テストを書く文化」をどうすれば組織に根付かせることができるのか、講演の後半ではこの本質的な議論へと踏み込みます。 本記事は、2時間におよぶこの講演をダイジェスト
“生産性向上に投資するため”のデータの可視化 生産性測定から組織の仕組み作りをサポート
オリジナルグッズ作成・販売サービス「SUZURI」に関わるエンジニアメンバーや事業部長が登壇し、SUZURIの開発の今や、現在の課題・今後の取り組みについて話す「43万人超のクリエイターの表現活動を支える！ECプラットフォームSUZURIの開発の裏側」。ここで技術部の近藤氏が登壇。生産性をすることになった背景と、具体的な測定方法を紹介します。 自己紹介 近藤宇智朗氏（以下、近藤）：では、お願いします。「生産性を可視化したい」と題して発表します。ということで、自己紹介します。私は技術部に所属している、近藤といいます。ふだん、インターネットなどでは“うづら”と呼ばれているので、お気軽にうづらと呼んでください。現在、技術基盤チーム兼データ基盤チームという感じで働いていて、SUZURIの事業部には直接所属していませんが、お手伝いという感じで今回はお話しします。 ちなみに、福岡市のエンジニアカフェと
体験の良いSelf-Serviceを提供するために必要な3つの心構え - これはただの日記
本記事は、SRE Advent Calendar 2019の20日目の投稿です。@katsuhisa__ がお送りします。 今年の6月に登壇した際に、Self-Serviceで物事を進めることの大切さと、SREがSelf-Serviceを構築することに責務の一端を持つことについてお話しました。 speakerdeck.com 「class SRE implements DevOps」という言葉もありますが、私はSREがDevOpsを実装するにあたって大切なことの1つは、開発者によるSelf-Serviceを構築することだと考えています。 www.youtube.com Envoy開発者のMattが「DevOpsとは、開発者が24/365でサービスの運用に対する責任を負う慣行である」としたことは有名です。私もその言葉に影響を受け、SREが開発者による運用を支えるツールやPlatformを開発
Infrastructure-as-Code-is-very-tired
ChatGPT関連情報の追い方、個人・業務での使い方、サービスへの組み込み方、 ABEJAでの取り組み4例、ここ2週間のトピックなど行けるところまで
「なんにもしない」スクリプトを書く: 段階的な自動化を進めるために | Yakst
[SRE]原文 Do-nothing scripting: the key to gradual automation – Dan Slimmon (English) 原文著者 Dan Slimmon 原文公開日 2019-07-15 翻訳依頼者 翻訳者 meiq 翻訳レビュアー doublemarket 原著者への翻訳報告 1724日前 Twitterで報告済み 編集 どんな運用チームにも、まだ自動化するところまで手が回っていない手作業があるものです。 トイル (toil) が完全に無くなることは決してありません。 成長企業のチームに非常にありがちなのが、インフラの変更手続きやユーザーアカウントのプロビジョニングが、最大のトイル源となっているケースです。 後者の例について手順の一部を書き出してみると、たとえば以下のようになるでしょう: ユーザーのSSHキーペアを作成する 公開鍵をGitに
Netflixにおけるフルサイクル開発者―開発したものが運用する - CARTA TECH BLOG
こんにちは。fluctでiOS/Android向けSDKの開発をしているarimuraです。この記事ではPhilip Fisher-Ogden、Greg Burrell、Dianne MarshによるFull Cycle Developers at Netflix — Operate What You Buildを私が翻訳したものを著者の許可のもとに掲載しています。元の記事は弊社の技術力評価会のインプットの一つとして共有されており、そこで興味を持ったのが翻訳するきっかけとなりました。 以下、2018年5月時点における情報を記載したものであり Netflix TechBlog「Full Cycle Developers at Netflix」より引用したものである。 Netflixにおけるフルサイクル開発者―開発したものが運用する 2012年―Netflixでの重要なサービスの運用は骨の折れ
闇のDevOps DevOpsと業績評価 – ところてん – Medium
ここから、DevとOpsが協力すればより効率的になる＝DevOps、という言葉が生まれました。 当時は大企業においてはDevとOpsが分かれていることが当たり前だったのです。そして、大企業における当たり前が、当たり前ではないことに気付き始め、DevOpsを実現するためのツールができ始めたころでもあります。 ではなぜ、大企業ではDevとOpsが分かれているのが当たり前だったのでしょうか？ ハードウェアの時代その昔、産業の主役はハードウェアでした。 そのため、多くの企業はハードウェアを作ることに対して最適化が行われました。 ハードウェアには研究開発、製造、運用サポートといった大きな区分けが存在します。そして、それぞれの仕事において要求する人材レベルは異なります。 加えて、大量生産された製品の運用サポート（設置作業員、サポートセンタ）には、大量の人員が必要になってきます。 したがって、組織を研究
DevOpsとSREの違いとは?
ビズリーチのSREチームでJenkinsおじさんとマネジメントを担当している阪本です。もう先月の話になりますが、サンフランシスコで開催されたGoogle Cloud Next ‘18に参加してきました。今回はその場で何度も聞いた class SRE implements DevOps という考え方を紹介させて頂きます。DevOpsとSREの関係性を理解する上で大変参考になりました。 DevOps、SREという単語が使われるようになって時間が経ちましたが、若干のバズワード感も否めず私自身混乱していました。そのような中でSREの草分け的存在であるGoogleが新たに class SRE implements DevOps というメッセージを発信し始めました。これは「SREはDevOpsというinterfaceの実装である」という意味で、いわゆるプログラミング言語の抽象化機能であるinterfa
Google、書籍「Site Reliability Engineering」の無料公開を開始。インフラや運用をソフトウェアで改善していく新しいアプローチ
Google、書籍「Site Reliability Engineering」の無料公開を開始。インフラや運用をソフトウェアで改善していく新しいアプローチ 「Site Reliability Engineering」（SRE）とは、GoogleのシニアVPであるBen Treynor氏が提唱した、高い信頼性や性能を発揮するシステムインフラを実現し、改善していくアプローチのひとつです。 これまでの運用チームやインフラチームによる運用や改善とSREが異なるのは、SREでは積極的にコードを書き、ソフトウェアによって目的の達成を目指している点にあるといえます。 Googleが公開しているSREのWebサイトでは、SREを次のように説明しています。 Like traditional operations groups, we keep important, revenue-critical syst
Netflix Open Source Software Center
JAX 2015 Award Industry Awards! Netflix is honored to receive the Jury's choice award for Innovation at JAX 2015 conference. We would like to thank all of those who contribute to the Netflix open source community including our Netflix developers, all external contributors, and our active user base. Netflix Open Source won the JAX Special Jury Award. Jury member Neal Ford was quoted as saying "that
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
アプリケーションエンジニアこそ「監視」だよね！と私が考える訳 #phpkansai
Feature FlagsのDX/UXの 頂点「 DevCycle 」に 辿り着くまでの道のり
Kubernetes anti-patterns: Let’s do GitOps, not CIOps!
DXとかDevOpsとかのなんかいい感じのやつ 富士通TechLive
マスタデータの管理と運用について
https://tech.trivago.com/2019/12/20/makefiles-in-2019-why-they-still-matter