「開発生産性」はエンジニア"だけ"のモノではなくなった？──開発組織から経営層までが開発生産性を考える時代へ
「開発生産性」がホットな話題となっています。Four KeysやSPACEといったスタンダードと言える指標もできあがりつつあり、エンジニアリングの成果が直接ビジネスの成功に結びついている例も少なくありません。しかし、開発生産性の評価を行う際にはエンジニア側の視点だけでなくビジネス側の要求と、期待をもとに逆算することが不可欠になっていますが、エンジニア側の視点に閉じてしまう例がしばしば見受けられます。本連載では、開発生産性を起点にビジネスとエンジニアリングの課題に切り込み、ビジネス側からの逆算の意義や可視化の方法、エンジニアと事業側が抱く開発生産性に対する異なる視点とそのギャップの埋め方に焦点を当てていきます。 はじめに 本連載は、ソフトウェア開発における「開発生産性」にスポットを当てていきます。タイトルにもある通り開発生産性の多角的視点をテーマにしています。単なる生産性を上げる方法ではなく
開発コストを10％削減、NRIのすごい生産性向上策
SIerの人手不足が深刻だ。旺盛なDX（デジタル変革）需要に対応するため、人材獲得競争が激化している。 人手不足への対処策の1つとして各社はサービス型への事業モデルの転換を進めている。事業モデルの転換とは別にもう1つの重要な取り組みがある。開発生産性の向上だ。技術者1人当たりの生産性を高めることで、より少ない人数で多くのシステムを開発できるようにする。 開発生産性向上への取り組みは今に始まったことではない。数々の開発手法や開発ツールが生まれてきたのはそのためだ。SIerも独自の開発標準や開発環境などを整え、効率のよい開発を進めてきた。 その中でもクラウドやコンテナといった最新技術を活用することで成果を上げたのが野村総合研究所（NRI）である。複数の企業で共通して使えるソフトをつくり、別のプロジェクトでも利用する。つくらない部分をなるべく増やすことで生産性を向上させる。実施した事業本部内での
私がもはやベロシティについてほとんど話さない理由
ベロシティは、スクラムの要素だったことはありません。 ソフトウェア開発に「ベロシティ」を適用することは、エクストリーム・プログラミング（XP）の先駆者たちによって考案されましたが、今ではそれが良くないアイデアだと考える人たちもいます。 残念ながら、スクラムの世界では、いまだに 「4倍のベロシティ向上 」や 「超生産性」などの言葉を押し付けている人がいます。私はこれを恥ずかしく思っています。これは、私が ケン・シュエイバーから学んだ スクラムではありません。ケン・シュエイバーは代わりに、 厳格な完成の定義 と、守れない約束を避けるということを強調していました。 もし私たちが、 実験から学び、適応する能力 を促進するのであれば、特に私たちの近視眼性（木を見て森を見ない傾向）と短絡的な認知バイアスを考えると、従来の生産性重視の姿勢は（それがどのような理由であれ）有害となりえます。あなたが昔に書い
開発者の生産性を測るためのフレームワーク`SPACE`について
LeanとDevOpsの科学の著者の一人であるNicole Forsgren氏が著者に入っているThe SPACE of Developer Productivity: There's more to it than you think - Microsoft Researchで提唱されているSPACEについて 以下記事も Four Keysだけじゃない開発者生産性フレームワーク 開発生産性の可視化フレームワークであるSPACEを活用するために、どのようなメトリクスをどう取得するかについて考えてみる 要約 SPACEは開発者の生産性を計測するためのフレームワーク 推奨されている測定指標のカテゴリ(本文ではディメンションと定義)の頭文字 satisfaction and well being performance activity communication and collaborati
PullRequestからチーム開発の生産性・健全性を測るCLIツールを書いてみた - $shibayu36->blog;
最近、開発チームの生産性や健全性をどのように計測したら良いかについて興味を持っている。その中で「LeanとDevOpsの科学」の中に書いてあるようなデプロイの頻度・変更のリードタイム・MTTR・変更失敗率の4指標や、開発チームの生産性・健全性を客観的に知るためにリポジトリ履歴から機械的に可視化するツールを作った - Qiitaに興味を持った。 一方、それらの指標を考えてみた時、以下のような点について悩んでいた。 マイクロサービスなどで複数レポジトリとなり、さらにデプロイ手法がそれぞれ違う状況の場合、変更のリードタイム = コミット〜本番稼働までの時間を計測するのがなかなか難しい コミットという単位だとかなり小さく、個々人のばらつきも大きすぎるように感じるので、もう少し良い単位はないのだろうか このような悩みから、PullRequestの単位で集計することで、生産性や健全性をもう少し測りやす
開発チームの生産性・健全性を可視化できるgilotを触ってみた - Activ8 Tech Blog
こんにちは。 株式会社 Synamon でエンジニアをしております、渡辺匡城(@mochi_neko_7)と申します。 今回はソフトウェアの開発チームの生産性・健全性を可視化できる gilot というツールを触ってみたのでレポートします。 ツールの作者の広木大地さん(@hiroki_daichi)は エンジニアリング組織論への招待 の著者であり、EM.FM などでも開発組織の話を発信されています。 そんな広木さんがツールを作成したと目にしたので、実際に触ってみて、弊社のプロダクトに適用してみました。 日本語での使い方やグラフ、指標の解説は Qiita にもまとめられていますので、こちらも参照ください。 qiita.com 上記の内容の補足として、環境のセットアップや Windows 環境ではまったところ、弊社のプロダクトの簡単な解析結果の紹介をします。 gilot gilot（ジロー）は
個人開発を加速させるツール群
俺コン Vol.1 / Day. 2 https://orecon.connpass.com/event/64285/ Firebase, Google Analytics, Fabric, Apple App Analytics の個人的使い分け http://starhoshi.hatenablog.com/entry/2017/07/04/Firebase%2C_Google_Analytics%2C_Fabric%2C_Apple_App_Analytics_%E3%81%AE%E5%80%8B%E4%BA%BA%E7%9A%84%E4%BD%BF%E3%81%84%E5%88%86%E3%81%91 Rails サーバから Google Analytics API で情報を取得する手順 http://bekkou68.hatenablog.com/entry/2014/08/20
フロー効率性とリソース効率性について XP祭り2017で発表してきた #xpjug - @i2key のBlog
先日、開催された XP祭り2017 にて発表してきました。スライドは以下になります。 フロー効率性とリソース効率性について #xpjug from Itsuki Kuroda www.slideshare.net また、上記発表のベースは以前のポストである「 フロー効率性とリソース効率性について（QCDのトレードオフなんて本当は無かったんだ） - @i2key のBlog 」がベースとなっております。また、Slideshareに上げたスライドが画像が若干ガビガビになってて見にくいので補足がてら要点だけ記載します。（と思ったら、元のポストより完成度高まってしまった。ので今後、誰かに説明するときはこっちをオリジナルにしよう。。。。） フロー効率性とリソース効率性についてかんたんな説明 リソース効率性について リソース効率を高めるということは稼働率を100%にあげていくことであり、リソースに空き
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
開発生産性 実践入門