ソフトウェア開発上の問題や課題をビジネスリーダーや経営者らの関心事とするために - mtx2s’s blog
ビジネスリーダーをはじめ、ソフトウェアプロジェクトの関係者にとって、ソフトウェア開発上の関心事は、開発の進捗とシステムトラブルだ。ソフトウェアの内部品質や開発プロセス上の問題や課題なんて、開発者以外に興味を示す人などほとんどいない。だから、関係者ばかりか開発者自身も、開発の進捗とシステムトラブルにばかり注意を向ける。 そのような状況に、一部の優秀な開発者は我慢ならない。憂いている。「このままではまずい、積み上がった問題に取り組むために時間が欲しい」「まとまった時間でなくても、継続的に取り組むための少しの割り当てでも構わない」と。そんな願いも虚しく、使える時間はすべて、担当する開発を進捗させることにのみ費やすことを強いられる。 私たちエンジニアリングマネージャーやテックリードは、このような状況を見て見ぬふりをしていないだろうか。開発の進捗やシステムトラブル以外にも注意を向けるべき対象がある。
システム開発に銀の弾丸はないが「金の弾丸」ならある『人が増えても速くならない』
例えばソフトウェア開発において、 人が増えても納期が短くなるとは限らない 見積もりを求めるほどに絶望感が増す 納期をゴリ押すと、後から品質はリカバリできない これを見て、「だよねー」「あるあるｗ」という人は、本書を読む必要はない。 プログラミングは人海戦術で何とかならないし、「厳密に見積もれ」というプレッシャーは見積額を底上げするし、納期が優先されて切り捨てられた品質は、技術的負債として残り続ける。経験豊富なエンジニアなら、大なり小なり、酷い目に遭ってきただろうから。 だが、これらを理解できない人がいる。 要員を追加して、手分けしてやれば一気に片付くはず 厳密にやれば、見積りバッファーはゼロにできる 品質のことはリリース後にじっくりやればいい ……などと本気で考えている。これは、ソフトウェア開発とはどういうものか、特性を知らないからだ。こんな無知な人間が経営層にいたり、顧客の代表となった場
株式会社リクルート エンジニアコース新人研修の内容を公開します！（2021年度版） | Recruit Tech Blog
こんにちは！ Webフロントエンドエンジニアの眞野 隼輔です。 毎年大きな反響を頂いている、エンジニアコースの新人研修の内容を紹介させていただきます。 研修の概要 リクルートでは、エンジニアコースでスペシャリスト採用された新卒のエンジニアを対象に、現場で培われた「本当に必要な生きた知識・技術」を取り入れた新人研修を開催しています。 前半は研修では各分野に長けた社員による講義形式の技術研修を行い、後半は仮配属という形でそれぞれ別の部署に配属されて実際の業務を経験するOJTとなっています。 この技術研修はそのほとんどが内製されており、ベテラン社員による経験を元にした講義を通して生きた知識・技術を獲得できます。また、実際に手を動かす演習型の講義ではベテラン社員からのレビューやフィードバックを得られるため、知識の定着や更なる成長へと繋がります。 本年度の技術研修も、昨年度に引き続きフルリモートでの
事業価値とエンジニアリング・リソース効率性とフロー効率性 / Business Value and Engineering
2021年度リクルート エンジニアコース新人研修の講義資料です
Pull Requestから社内全チームの開発パフォーマンス指標を可視化し、開発チーム改善に活かそう - Hatena Developer Blog
こんにちは。id:shiba_yu36です。MackerelチームでWebアプリケーションエンジニアをしています。最近の開発合宿で、id:syou6162やid:polamjagと一緒に、社内の全チームの開発パフォーマンスを表す指標をGitHubのPull Requestから可視化し、開発チームの改善に活かせるようにしました。今回はその紹介をします。 説明するサンプルコードは、次のレポジトリで公開しているので参考にしてください。ここではGitHubのhatenaオーガニゼーションで集計していますが、forkして少し手直しすれば、別のオーガニゼーションの集計も可能になっています。 hatena/pull-request-analysis-sample 開発チームの改善におけるいくつかの課題感 開発チームのパフォーマンス指標に何を使うか 4つの指標のうち何からまず集計するか 変更のリードタイム
技術的負債とステークホルダと説明責任と / The Debt
Talked at CloudNative Days Spring 2021 Online #CNDO2021. https://event.cloudnativedays.jp/cndo2021/talks/801
「推測するな、計測せよ」 〜小さく始める生産性可視化と分析〜
2023/05/30に開催された「開発生産性を高める 〜ソウゾウ、Voicyの挑戦と苦労〜」( https://offers.connpass.com/event/283434/ )で発表した資料です。
「スクラムで生産性は上がらないしリリーススケジュールが狂いまくりなんですよ」とか言うお前らに告ぐ
前提 この記事は内製開発をしているSaaSの中の人であるエンジニアが、SaaSの内製ソフトウェア開発をする上での話として書いています。 前ふり 「スクラムで生産性は上がらないしリリーススケジュールが狂いまくりなんですよ」 「何が原因なんですか？どうすればいいんですか？」 という相談を受けました。 NDAを書いてから、どれどれとチームの状況を見てみました。 該当チームのスプリントゴール 該当チームのスプリントゴールはこんな感じでした。 QAフェーズのプロジェクトAを、QA作業を完了してリリースできる状態まで進める 実装フェーズのプロジェクトBを、フィーチャーの実装率を50%まで進める 設計フェーズのプロジェクトCを、要確認な点を除いて実装レディーな状態まで進める スプリントゴールが3つありますね。とても面白いですね。 思わずボンドルド卿みたいな反応をしたくなりますがここは先に進みましょう。
エンジニアの稼働率を上げれば上げるほど機能リリースが遅くなっていく｜mtx2s
組織内のメンバーを「リソース」として見始めると、それを100%使い切ることにばかり注力してしまいます。リソースの稼働率を下げることは、すなわち、生産性を下げること。マネージャーは、まるで強迫観念に取り憑かれたように、そのような考えに囚われます。 自社でのソフトウェアプロダクト開発において、その対象は特に、開発者に強く向けられます。その理由は明らかでしょう。バックログに積み上がり続けるアイデアをソフトウェアに変えられるのは、開発者だけです。より多く、できる限り早く、アイデアを市場投入したい。彼らに空き時間という無駄を作らせてしまうわけにはいかない。 しかし、そのような努力が、必ずしも良い結果につながるとは限りません。むしろ、開発者の稼働率を高めすぎたことが、リードタイムに悪影響を与えているかもしれないのです。そして言うまでもなく、アイデアの市場投入が延びれば延びるほど、ユーザーにとってもビジ
CTOの頭の中：技術を財務で表現する｜Shin Takeuchi｜note
会社の体制が大きく変わり、カオスの中に少しの静寂（暇）ができました。特に日々執行に勤しんでいる方々は皆そうだと思いますが、色んなこと考えているのにそのプロセスをアウトプットする機会があまりなく、結果や結論、最終的な決断のみが共有されるため、サクセッションプランに対する有効な情報を残すことも出来ていないことと思います。僕もその一人。 この時間を有効に活用するため、頭の中にあるイメージと考え方をここに、時間の許す限り吐き出していこうと思います。時折、言葉が足りないところも前提条件やバイアスの記述が足りないところもあるかと思いますが、混沌とした頭の中を曝け出すプロセスにはつきものですので、大目に見ながら読んでいただけると幸いです。 財務諸表と同じように見える化する会社は財務諸表によって経営されるものなので、経営者たるもの財務諸表を見ながら戦略を立てるべきであると僕は考えています。数字以外信じない
開発組織の貢献は売上として直接語るのはやはり無理があるのではないかという考察
先日サーバントワークスさんが公開した 計測によるスクラムチームのパフォーマンス向上 を読んで、 以前自分が書いた 開発の改善はKPIに翻訳しなければいけないのか をもうちょっと言語化することができそうだったのでメモ。 TL;DR 結論としては、開発の改善はKPIに翻訳しなければいけないのか でも書いた通り 開発組織はビジネスの実現を担っている職能であり、理想的には 「永久に持続性がある状態」で 「0秒 でしかも 並列数を無限」 でモノが実現されて、「不具合やパフォーマンスの劣化は 0」 であってほしい。もちろん現実世界ではどれも実現できないのでそこにいかに近づけるかということを目的に改善を実施すればよく、売上などのKPIに翻訳する必要性は必ずしもない から考え方は変わってないが、改めて整理して 開発組織は、Ability to Innovate と Time to Market 2つのケイ
私がもはやベロシティについてほとんど話さない理由
ベロシティは、スクラムの要素だったことはありません。 ソフトウェア開発に「ベロシティ」を適用することは、エクストリーム・プログラミング（XP）の先駆者たちによって考案されましたが、今ではそれが良くないアイデアだと考える人たちもいます。 残念ながら、スクラムの世界では、いまだに 「4倍のベロシティ向上 」や 「超生産性」などの言葉を押し付けている人がいます。私はこれを恥ずかしく思っています。これは、私が ケン・シュエイバーから学んだ スクラムではありません。ケン・シュエイバーは代わりに、 厳格な完成の定義 と、守れない約束を避けるということを強調していました。 もし私たちが、 実験から学び、適応する能力 を促進するのであれば、特に私たちの近視眼性（木を見て森を見ない傾向）と短絡的な認知バイアスを考えると、従来の生産性重視の姿勢は（それがどのような理由であれ）有害となりえます。あなたが昔に書い
開発生産性について議論する前に知っておきたいこと - Qiita
はじめに 事業としてソフトウェア開発を行う企業にとって、自分たちの開発チームの生産性が十分に高いのか、あるいはそうでないのかについては大きな関心があります。 そのこと自体は、何かを計測し、改善するというのは営利企業としては健全です。一方で、ソフトウェアエンジニアリングの世界で「生産性の高さ」だと主張できる汎用性の高い指標は存在しません。こういった状況の中で、「生産性」を巡る議論は経営やビジネス部門とエンジニアチームとの間で繰り広げられ、場合によっては大きな不和や不信感につながることも珍しいことではありません。 今回は、エンジニアの開発生産性について、さまざまなステークホルダーと議論する上で把握しておきたいさまざまな論点について解説します。それによって、「我々が本当に議論すべきテーマは何か」についての共通認識をつくるための土台を構築することを目的としています。 もしかしたら改善したいことは「
答えが分からないものを模索しながら作り続ける世界に我々は突入した。和田卓人氏による「組織に自動テストを根付かせる戦略」（その1）。ソフトウェア品質シンポジウム2022
答えが分からないものを模索しながら作り続ける世界に我々は突入した。和田卓人氏による「組織に自動テストを根付かせる戦略」（その1）。ソフトウェア品質シンポジウム2022 9月22日と23日の2日間、一般財団法人日本科学技術連盟主催のイベント「ソフトウェア品質シンポジウム2022」がオンラインで開催され、その企画セッションとして行われた和田卓人氏による講演「組織に自動テストを書く文化を根付かせる戦略（2022秋版）が行われました。 講演で、企業の業績はソフトウェアの開発能力に左右されるようになってきていること、その開発能力を高める上で重要なのがコードの「テスト容易性」や「デプロイ独立性」であると和田氏は指摘。その上で、それを実現させるような「自動テストを書く文化」をどうすれば組織に根付かせることができるのか、講演の後半ではこの本質的な議論へと踏み込みます。 本記事は、2時間におよぶこの講演をダ
開発組織の生産性を可視化するState of DevOpsとFour Keysとは(増補改訂版) / Introduction to State of DevOps and Four Keys for Visualizing Productivity in Development Organizations expanded and revised edition
以下のイベントの発表資料です。 https://phpcon.php.gr.jp/2022/ 想定課題 開発がスケールしたり、開発年数が経過すると、様々な要因で開発生産性の低下が起こります。 そこで現場のエンジニアは改善をしたくなるかと思いますが、大抵の場合、ステークホルダーと工数確保の合意が必要になります。 その際にこのようなことを言われがちではないでしょうか？ 今動いているものを直す必要ある？ 効果測定どうやんの？ 費用対効果はどれくらい？ パフォーマンスチューニングの世界には「推測するな計測せよ」という言葉がありますが、開発組織における生産性についても測定してモニタリングする必要があると思います。 本セッションの目標 以上を踏まえ、本トークでは開発組織とステークホルダーの間の共通言語を獲得することを目標に以下の内容についてお話します。 State of DevOpsとは Four K
フロー効率性とリソース効率性、再入門 #devlove #devkan
DevLove関西の以下のイベントのスライドです https://devlove-kansai.doorkeeper.jp/events/75644
開発速度が速い #とは（LayerX社内資料）
Cloud Festa 2021 Winter 「デザイナー、データサイエンティスト、 クラウドエンジニア、で実現する共創の世界」 Tsuyoshi Hirayama
品質を犠牲にすることでソフトウェア開発のスピードは上がるのか？ 和田卓人氏による 「質とスピード」（前編）。デブサミ2020
品質を犠牲にすることでソフトウェア開発のスピードは上がるのか？ 和田卓人氏による 「質とスピード」（前編）。デブサミ2020 ソフトウェア開発のプロジェクトにおいて、リリースに間に合わせるために開発スピードを優先させ、ひとまず質には目をつぶろう、という判断がしばしば行われることがあります。 はたしてその判断は正しいのでしょうか。2020年2月13日と14日の2日間、都内で行われたイベント「Developers Summit 2020」（デブサミ2020）」の和田卓人氏のセッション「質とスピード」は、これを深く考察したものでした。 この記事では、会場に立ち見がでるほど大人気だった本セッションの内容をダイジェストで紹介します。本記事は前編と後編に分かれています。いまお読みの記事は前編です。
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
アジャイル開発は本当に必要なのか、何を解決するのか
アジリティを支える品質特性 / Agility and Quality Characteristics Developers Summit 2021 Summer