より筋肉質なチームにするために、開発者が見るべき21のDevOpsアウトプット指標 - Qiita
1. はじめに システム開発にまつわるチームや組織の活動は、指標なんかで測れるわけないやろ～、という声は根強いです。ましてや、それが人の評価になろうものなら、感情的な反発さえありえます。Martin Fowlerもこちらよりです。 一方で、何らかの指標で測れるはずじゃないの？という声も根強い気がします。測れんかったら、良くなったかどうか、どうやって判断すんねん、という意見ですね。DORA Metricsを擁するGoogleはこちらよりですかね。 私はどちらなのかというと、後者で、測れるものは測りたいタイプです。もちろん、すべてが正しく測れるなどとは思っていません。そもそも定性的な指標と定量的な指標のバランスが大事であり、定量的な指標でさえも、現実世界では正確性と計測コストはトレードオフだと思ってます。 しかし、ではじゃあ、具体的にどうすればいいのか？それをまとめてみましたので、ご覧ください
サイバーエージェントのフィーチャーフラグを活用した高速開発 | CyberAgent Developers Blog
3月24日、サイバーエージェントのエンジニア・クリエイターによる技術カンファレンス「CyberAgent Developer Conference2022」を開催しました。本記事では「サイバーエージェントのフィーチャーフラグを活用した高速開発」の様子をお届けします。 目次 ■フィーチャーフラグと開発 ■フィーチャーフラグのメリット、デメリット ■社内フィーチャーフラグ基盤「Bucketeer」 ■「Bucketeer」のユースケース ■「ABEMA」におけるフィーチャーフラグの活用方法 ■フィーチャーフラグを管理する「Flagfit」 ■まとめ ■フィーチャーフラグと開発 フィーチャーフラグとは、静的または動的に機能のON/OFFを切り替える手法で、コードで表すと以下のようになります。 もしフィーチャーフラグがtrueであれば何かをして、そうでなければ別の何かを行なうといったコードを書くこ
ソフトウェア開発の見積もり入門
見積もりとは？ Wikipediaによると見積もりとは、以下のようにあります。 見積（みつもり。見積り、見積もりとも書く）とは、金額・量・期間・行動を前もって概算すること。見積もること。あらましの計算をすること。また、その計算。目算。「所要時間を見積る」、「一日の来客者数をざっと見積もった」など、おおよその感覚で数字の見当をつける場合の口語体表現でも使われる。 Wikipedia このように見積もりとは、なにかを行う前に事前にその結果を予想しておくことを言います。 見積もりを使うケースは、ソフトウェア開発に限った話ではありませんが、製造業であるソフトウェア開発においては『見積もり』というタスクは様々なケースで登場します。 見積もりが苦手な人は多い ソフトウェア開発では、「この機能を開発するときにどのくらいで完成できますか？」といったケースが見積もりのシチュエーションとしては多いかと思います
スタートアップが山型クロスファンクショナルチームでデリバリスピードを安定させる話
山型なスキルをもったメンバーがあつまる山型クロスファンクショナルチームを作りデリバリスピードを安定させるというテーマのスライドです。 XP祭り2021での発表資料です。 山型クロスファンクショナルチームは造語ですが、定義としては「スペシャリティをもちつつ周辺分野でも基本的な価値を発揮できるメンバーが集まるチーム」としています。 Spotifyのスクワッドなどに代表されるクロスファンクショナルチームが良いとされているのは昨今では定説となりつつあります。 本スライドではそこからさらに踏み込んで、山型なスキルを持ったメンバーでクロスファンクショナルチームを構成するとどのような効用を得られるか、またそのようなチームはどう作るべきかというところを説明していきます。
ソフトウェア設計についての原則や法則についてまとめてみた
ソフトウェア設計について、YAGNIやSOLIDなど多くの原則・法則があることが知られていますが、その解釈にはぶれが存在することが多いです。そこで、特に有名なものあるいは有用と感じることが多いものをいくつかピックアップして、その解釈やトレードオフについてまとめてみました。 注意としては、SOLIDが入ってることからわかる通り、主にOOPに関する文脈になります。また、各原則の定義については概ね知っている前提で書いているのであまり初学者向けの記事ではないかもしれませんのでご承知おきください。 YAGNI（You ain't gonna need it.） YAGNIは、予測による実装が実際に役立つことは少ないという経験則から生まれた原則です。 一般にオーバーエンジニアリングが利益をもたらすケースは限定的で、どちらかというとプロジェクトに害を与えることが多いとされています。YAGNIは日々状況の
技術的負債を返済するためのエンジニアリングとは？ VOYAGE GROUPの実践に学ぶ【デブサミ2021】
「ITエンジニア本大賞 2021」技術書部門大賞を受賞した『Engineers in VOYAGEー事業をエンジニアリングする技術者たち』。この書籍で紹介された技術的負債を返済するアプローチ手法であるリファクタリング、リアーキテクティング、リプレイスを、VOYAGE GROUPではどう実践してきたのか。そして、各システムの技術的負債に対し、どのように立ち向かってきたのか。同社のエンジニアが挑んできた課題や解決策を、実例を交えながら紹介する。 タワーズ・クエスト株式会社 プログラマ・テスト駆動開発者 和田卓人氏（左上）、株式会社fluct プログラマ 須藤洋一氏（右上）、株式会社VOYAGE MARKETING 福田剛広氏（左下）、元株式会社サポーターズ ねこや氏（右下） 技術的負債を返済するための3つのアプローチ まず和田卓人氏は、事業とシステムとの間の乖離から生まれる技術的負債を返済する
フィーチャーフラグ（Feature Flag）はなぜ必要なのか？
本連載は、最新のソフトウェア開発の課題点を解決する手段であるフィーチャーフラグ（Feature Flag）について、概要や導入方法、ベストプラクティスを紹介します。第1回は、フィーチャーフラグとはなにか、どのようにしてプロダクト開発を変えていくのか、そのメリットと導入の際の懸念点を説明します。 はじめに 本連載はフィーチャーフラグについての連載です。最新のソフトウェア開発の課題点を解決する手段であるフィーチャーフラグに焦点をあて、フィーチャーフラグとは何なのか、どういった機能を提供するのか。フィーチャーフラグのメリット・デメリットを、具体例を使って詳細に説明します。また、導入前に考慮すべきことや、フィーチャーフラグの実装、サービスの選定の際の注意点、効率よく、かつ継続的に使用していくためのベストプラクティスも併せて解説します。さらにはサードパーティー製のフィーチャーフラグサービスの比較を行
現代ソフトウェア開発の地図 - shimobayashiパブリック
独断と偏見で常に編集中です。 メンタルモデル ↑影響大 Amazon.co.jp： 世界標準の経営理論 eBook: 入山 章栄: Kindleストア 世界標準の経営理論 を読んで エンジニアリング組織論への招待 への理解も深まった - 下林明正のブログ 多くのIT業界の企業はシュンペーター型の競争環境にあり、常に不確実な事業環境に素早く柔軟に対応する戦略がマッチする 企業のガラパゴス化を見抜く「競争の3類型」 | 世界標準の経営理論 | ダイヤモンド・オンライン GAFA（※：グーグル、アップル、フェイスブック、アマゾン・ドットコム）は要するに、まずシュンペーター型で新しいものを生みます。そして、ＩＯ型に移行し、ネットワーク効果で、独占状況を築く。築いたら潤沢なキャッシュを得て、そのマネーを、またシュンペーター型の競争にばんばん投じてくる。その循環なのです。 私見: 特にシュンペーター型
How we ship code faster and safer with feature flags
EngineeringHow we ship code faster and safer with feature flagsAt GitHub, we're continually working to improve existing features and shipping new ones all the time. From our launch of GitHub Discussions to the release of manual approvals for GitHub… At GitHub, we’re continually working to improve existing features and shipping new ones all the time. From our launch of GitHub Discussions to the rel
【翻訳】 図解 プロダクトづくりの構造 - ykmc09 blog
訳者注 本記事は、Dan Schmidt 氏のブログ記事「A Visual Vocabulary for Product Building」をご本人の許可のもと日本語訳したものです。 ninjinkunさん、Koshiro Kumikoさんにレビューにご協力いただきました。的確かつ、建設的で思いやりのあるアドバイスとフィードバックに感謝します。 同一著者の関連記事としてこちらもぜひ合わせてご覧ください：【翻訳】プロダクトマネジメントトライアングル 以下、翻訳本文です。 プロダクトビルダー（訳注：プロダクトをつくる人たち）が自分のプロダクトに当てはめられるような、成功するプロダクトをつくる方程式はありません。これは、プロダクトが置かれている常に変化するコンテキストに、プロダクトづくりの詳細が大きく左右されるからです。あるプロダクトで成功した戦略が別のプロダクトではまったくあわないこともありま
Use HTTPS for local development | Articles | web.dev
Use HTTPS for local development Stay organized with collections Save and categorize content based on your preferences. Most of the time, http://localhost behaves like HTTPS for development purposes. However, there are some special cases, such as custom hostnames or using secure cookies across browsers, where you need to explicitly set up your development site to behave like HTTPS to accurately rep
Software development topics I've changed my mind on after 6 years in the industry - Blogomatano
Software development topics I've changed my mind on after 6 years in the industry Published: 2021-01-23 Things I've changed my mind on:Things I now believe, which past me would've squabbled with: Typed languages are better when you're working on a team of people with various experience levelsStandups are actually useful for keeping an eye on the newbies.Sprint retrospectives have their place so lo
生産性・技術的負債をMetabaseで可視化した話 - LIFULL Creators Blog
技術開発部の清水です。好きな食べ物は広島風お好み焼きと広島県産牡蠣と広島県産穴子です。 拡張に次ぐ拡張でサービスは便利なものに成長していく一方でソースコードは次第に複雑になっていきます。 そのまま放っておくと積み上げた技術的負債により開発コストが上がっていき、最悪の場合にはサービスの発展を停止させてしまう可能性もあります。 このような理由から、弊社では技術的負債を着実に返済していくべく生産性・技術的負債の可視化をMetabaseで行っています。 可視化する情報元はGithub API、CodeClimateQuality APIの2つのみです。 生産性の可視化 本流ブランチにマージされたPR数（生産数） 本流ブランチにマージされたPRによる意味のある変更行数（生産規模） 本流ブランチにマージされたPRの平均レビュー応答数（生産を助けた人員の労力） 本流ブランチにマージされた「1コミッターあ
テックリードになって気をつけていること - Qiita
フューチャーアドベントカレンダー2020の24日目です。 はじめに フューチャーに入ってテックリード（社内だとアーキリーダーと呼ぶことも多い）のような役割をし始めて4,5年ほど経過しました。 いくつかの案件を回して自分なりに汎化・パターン化してきた部分も増えてきたので、気を付けていることをまとめました。 テックリードとは エンジニアのためのマネジメントキャリアパス――テックリードからCTOまでマネジメントスキル向上ガイド によると、以下のように説明されています。 テックリードはエンジニアの階層におけるランクのひとつではなく、シニアのレベルに達したエンジニアが担うことのできる職責群である 技術的なプロジェクトの管理者 部下に効率良く仕事を割り振って自身の負担を適宜軽減するよ う心がける チーム全体の生産性に照準を定め、しかるべき成果を上げるよう全力を尽くさなければならない 管理やリーダーシッ
ちょっとしたシステム変更なのに時間と手間がかかるのはなぜ？｜森崎 修司
ソフトウェア開発の効率化や品質向上を研究しています。そこで感じたことを書いていきます。ITシステムに関するリテラシーが高まるともっとIT化が進むのではないかと思い、書いています。 ITシステムを利用していると改善したいことが出てきます。「こことここは同時に指定したい」「この順番が入れ替わると作業しやすい」といったこと要望を感じることは誰にでもあるのではないでしょうか。ご自身が開発に携わっていれば、変更することもできますが、社内のIT部門が管理していたり、開発会社にお願いしていたりすると、このブログエントリのタイトルのように思うことがあるかもしれません。 「ちょっとした変更なのに、なぜ時間がかかると言うのだろう。本当はそれほど時間がかからないのに、ひょっとして仕事が増えるのがいやなだけで、体よく断っているのではないか」と思ってしまうかもしれません。その可能性はゼロではありませんが、一般には次
ソースコードブランチ管理のパターン - Martin Fowler's Bliki (ja)
https://martinfowler.com/articles/branching-patterns.html 最新のソース管理システムには、ソースコードのブランチを簡単に作成できる強力なツールが用意されています。しかし、最終的にはこれらのブランチをマージしなければならず、多くのチームは混み合ったブランチに対処するのに膨大な時間を費やしています。複数の開発者の作業をインテグレーションし、本番リリースまでの道筋を整理することに集中して、チームが効果的にブランチを利用できるようにするためのパターンがいくつかあります。全体的なテーマとしては、ブランチを頻繁にインテグレーションし、最小限の労力で本番環境に展開できる健全なメインラインを作ることに注力すべきだということです。 ベースパターン ソースブランチング ✣ メインライン ✣ 健全なブランチ ✣ インテグレーションパターン メインラインイン
Loophole Labs
Open Source Developer tools to help you Design, Build, & Ship Amazing Code
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
The False Trade-off Between Quality and Speed
ベロシティを上手く使って 技術的負債を計画的に解消する
CakhiaTV | Trực Tiếp Bóng Đá Cakhia TV Link Full HD Số 1
