1 - 40 件 / 118件
新規事業立ち上げのアンチパターンについて考えてみる。 このアンチパターンは、完全な飛地の新規事業だけではなく、複数プロダクトを経営する中での隣接領域の新規プロダクトの立ち上げのときや、あるセグメントにPMFした状態から次のPMFを探すときも同様のアンチパターンが適用されうる。 ここでのアンチパターンは、1つ目の事業立ち上げ・プロダクト立ち上げで起こることはない。2つ目の事業や2つ目のプロダクトを立ち上げる際に留意する点であり、コンパウンドスタートアップを正しく経営するには必ず頭に入れておきたい内容である。 規模からの逆算と顧客インサイトの軽視新規事業における市場選択のアンチパターンである。 例えば、売上の30%成長を続けるための、計画と現実のギャップを埋めるために新規事業を規模から探してしまうみたいなケースで見られる。 大前提として、市場規模の推定は重要である。実際に事業をやっていると、い
私たちソフトウェアエンジニアは、コード品質についてしばしば論ずるけれども、ではコード品質の良し悪しがどれほどビジネスに影響するのかと問われると、回答に窮する。只々、「コード品質が悪いと変更により多くの時間がかかります」だとか、「欠陥の修正に追われて開発時間が奪われます」だとか、個人の経験やエンジニア的一般論に頼った定性的な説明に終始するしかない。ソフトウェアを繰り返し変更する頻度が高いほど、コード品質が開発時間に影響を与えるのは確かにそのとおりだと思えるが、はたしてそれは、どれほどのインパクトなのだろうか。 2022年の研究論文 "Code Red: The Business Impact of Code Quality – A Quantitative Study of 39 Proprietary Production Codebases" では、コード品質がビジネスに与えるインパクト
#共有する 開発生産性カンファレンス https://dev-productivity-con.findy-code.io/2025 2025年07月03日 Keynote: 開発生産性測定のトレードオフ 「グッドハートの法則」はもっと悲観的に捉えるべきだった はじめに:25年ぶりの来日と生産性への問題意識 25年ぶりに来日しました。かつて『エクストリーム・プログラミング(XP)』の本が日本の書店に平積みされているのを見て、とても嬉しかったことを覚えています。(サインしようとして店員に怪しまれ、逃げたという面白いエピソードもありましたが。) 今日は「開発生産性」について話します。より多く、より早く作れば生産性は向上するのでしょうか?ドイツには「物事を良くしようとして、かえって悪化する」という趣旨の言葉がありますが、まさにそれが生産性の議論で起きています。特にAIの登場は、この問題をさらに悪化
登壇資料 HackFes.2025 | 日本ハッカー協会 https://hackfes2025.hacker.or.jp/
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
先日サーバントワークスさんが公開した 計測によるスクラムチームのパフォーマンス向上 を読んで、 以前自分が書いた 開発の改善はKPIに翻訳しなければいけないのか をもうちょっと言語化することができそうだったのでメモ。 TL;DR 結論としては、開発の改善はKPIに翻訳しなければいけないのか でも書いた通り 開発組織はビジネスの実現を担っている職能であり、理想的には 「永久に持続性がある状態」で 「0秒 でしかも 並列数を無限」 でモノが実現されて、「不具合やパフォーマンスの劣化は 0」 であってほしい。もちろん現実世界ではどれも実現できないのでそこにいかに近づけるかということを目的に改善を実施すればよく、売上などのKPIに翻訳する必要性は必ずしもない から考え方は変わってないが、改めて整理して 開発組織は、Ability to Innovate と Time to Market 2つのケイ
スクラムを開発方法論に採用しているチームで開発者をしています。最近たまたま見積もりについての話題がチームであがり、私の経験や考えを整理してみる機会にしようと考えました。お断りとして、本稿の考え方が正しいと主張する意図はありません。世の中にはさまざまなチームや開発スタイルがあります。私が経験していない業務においては他のやり方もうまくいくケースがあると考えています。 スクラムガイド には見積もりの実践について明確な指針を提供していません。一方でスプリントを設定し、スプリントプランニングを行う上で通常はその期間内にスプリントゴールの達成を図ることから、必然的になんらかの見積もりを行うことを前提としています。インターネットを検索すると、プランニングポーカーとストーリーポイントを用いた見積もりの記事も多くみつかります。私の立場として、ストーリーポイントという見積もり手法をやや懐疑的にみています。この
こんにちは。id:shiba_yu36です。MackerelチームでWebアプリケーションエンジニアをしています。最近の開発合宿で、id:syou6162やid:polamjagと一緒に、社内の全チームの開発パフォーマンスを表す指標をGitHubのPull Requestから可視化し、開発チームの改善に活かせるようにしました。今回はその紹介をします。 説明するサンプルコードは、次のレポジトリで公開しているので参考にしてください。ここではGitHubのhatenaオーガニゼーションで集計していますが、forkして少し手直しすれば、別のオーガニゼーションの集計も可能になっています。 hatena/pull-request-analysis-sample 開発チームの改善におけるいくつかの課題感 開発チームのパフォーマンス指標に何を使うか 4つの指標のうち何からまず集計するか 変更のリードタイム
スクラムフェス福岡2024での講演資料です。 --- 皆さん、職場でFour Keysを導入していますか? Yesと答えた皆さん、『LeanとDevOpsの科学』は読みましたか? あくまで僕の周囲のみの観測で語るのですが、Four Keysを職場で導入しているという人はとても多いので...
2018年新卒入社。名古屋支社にてSI中心にお仕事をするエンジニア。仕事ではサーバやミドルウェアを、趣味ではウェブやアプリを弄っています。 【IIJ 2022 TECHアドベントカレンダー 12/21(水)の記事です】 はじめに 名古屋支社の kmmt-t です。 今年の夏頃、インターネットの回線速度を測定するブームがありました。(なぜ?については触れませんが・・・) 俗に言われる「回線速度」というものは、時間帯やご近所さんの利用状況などの様々な要因で変化するものなので1回だけ測ったところで大した意味は持たないでしょう。先日公開された弊社のハンズオン研修の1つである「監視Overview」でも述べられている通り、何かのシステムを監視するのであれば「可視性」「通知性」「特定性」「分析性」を重視しなければなりません。・・・例えそれが自宅のインターネット回線であっても! というわけで今回は、以下
ベロシティは、スクラムの要素だったことはありません。 ソフトウェア開発に「ベロシティ」を適用することは、エクストリーム・プログラミング(XP)の先駆者たちによって考案されましたが、今ではそれが良くないアイデアだと考える人たちもいます。 残念ながら、スクラムの世界では、いまだに 「4倍のベロシティ向上 」や 「超生産性」などの言葉を押し付けている人がいます。私はこれを恥ずかしく思っています。これは、私が ケン・シュエイバーから学んだ スクラムではありません。ケン・シュエイバーは代わりに、 厳格な完成の定義 と、守れない約束を避けるということを強調していました。 もし私たちが、 実験から学び、適応する能力 を促進するのであれば、特に私たちの近視眼性(木を見て森を見ない傾向)と短絡的な認知バイアスを考えると、従来の生産性重視の姿勢は(それがどのような理由であれ)有害となりえます。あなたが昔に書い
ソフトウェアエンジニアとして働き始めて以来、ずっとソフトウェアデリバリーのパフォーマンスに興味を持って、さまざまな改善活動をしてきた。当初はスクラムを中心としたプロセスの改善に注力したが、最近はチームの成熟に伴って技術的なプラクティスに興味が移りつつある。より広い視点からデリバリーについて考えるのは非常に楽しい仕事だ。 デリバリーのパフォーマンスを改善していくには、定量指標として確立されたFour Keysを計測し改善するのが業界標準となりつつある。恥ずかしながら、私はこれまでこのFour Keysが腹落ちせず、積極的に計測してこなかった。しかし、多方面に興味が向いて知識や経験が蓄積するにつれて、猛烈にFour Keysの重要性が腹落ちしてきた。この記事では、現時点における自分のFour Keysに関する理解と解釈を整理してみようと思う。 Four Keysとは Four Keysの妥当性
以下のイベントの発表資料です。 https://phpcon.php.gr.jp/2022/ 想定課題 開発がスケールしたり、開発年数が経過すると、様々な要因で開発生産性の低下が起こります。 そこで現場のエンジニアは改善をしたくなるかと思いますが、大抵の場合、ステークホルダーと工数確保の...
2024年2月15日 Developers Summit 2024 登壇資料 https://event.shoeisha.jp/devsumi/20240215
本稿は Ron Jeffries 氏によって書かれた次の記事の日本語翻訳です。著者に翻訳の許可を得て公開しています。 ronjeffries.com また本稿は DeepL Pro を使って下訳したものに手を加えています。日本語翻訳の不具合または誤訳については Ron Jeffries 氏ではなく、本稿のコメント欄にお願いします。 ここから本文です。 ストーリーポイント再考 私はストーリーポイントを発明したかもしれない。もしそうだったとしたら、いまは申し訳なかったと言いたい。ストーリーポイントに関する私の現在の考えを探ってみよう。少なくとも何人かは私の考えに興味をもっているでしょう。 もちろん、ストーリーは XP のアイディアであり、スクラムのアイディアではありません。どういうわけか、スクラムの実践者はこのアイディアを採用しています。公式のスクラムガイドではバックログアイテムに言及している
DevOpsDays Tokyo2022 ファクトから始める改善アプローチ 〜「LeanとDevOpsの科学」を実践して〜 #DevOpsDaysTokyo #DevOps #4keys #cloud #cicd #Accelerate #LeanとDevOpsの科学
品質やテストといった活動が「本質的にアジャイルになって変わらなければならない」といった問題を定義し、その解決手段を提案する「今、全エンジニアに求められる『アジャイル開発での品質視点の変化』」。ここで株式会社デジタルハーツホールディングスの高橋氏が登壇。最後に、あらためて参加者からの質問に回答します。前回はこちらから。 どうすればうまくリファクタリングができるか 高橋寿一氏(以下、高橋):じゃあここでもう1回Q&Aタイムを取ります。 高木陽平氏(以下、高木):ありがとうございます。今Q&Aにまだ質問が上がっていないみたいなので、ちょっと私から質問します。リファクタリングをしなければいけないところって、逆に手をつけられないようなけっこう複雑怪奇な部分だと思うんです。そこらへんはどうすればうまくリファクタリングができるんでしょうっていう(笑)。 高橋:まず、日本人がすごくリファクタリングが嫌いな
ひとつのソフトウェアコンポーネントが多くの開発者によって変更されると、品質に悪い影響を与えると経験的に感じている。設計に一貫性が失われることや、知識の浅い状態で変更することによるバグ混入の可能性が高まるからだ。 2011年9月に公開されたマイクロソフト社の調査結果、"Don’t Touch My Code! Examining the Effects of Ownership on Software Quality" は、この「コードのオーナーシップはソフトウェアの品質を左右する」という経験則を裏付けるものだった。全体のコミット数のうち5%未満の貢献にとどまる開発者が多いコンポーネントは、リリース前後における故障が増加するというものだ。 本稿では、このマイクロソフトによる調査結果を紹介し、それを踏まえた上で、ソフトウェアプロダクトの品質悪化を抑えるための組織やプロセス、アーキテクチャについ
ソフトウェアアーキテクチャメトリクス - Forkwell Library #44 での発表資料です https://forkwell.connpass.com/event/309739/ 動画: https://www.youtube.com/watch?v=C52rYX_E9bA ...
この記事は前作 開発生産性の可視化サービスから何を見いだして何ができるのか、あるいはすべきで無いこと に続き、開発生産性へのスタンスを整理したい2作目です。 効果・成果よりも効率を優先することは生産性か? 開発生産性と言いながら単なるアクティビティの量や時間を見て効率改善を志してしまういくつかの状況、一部の風潮に対して疑問を呈したい。 例えば、PRやイシューの起票数などアウトプット量の高低に一喜一憂する 例えば、変更のリードタイムやデプロイ頻度の増進を過度に重視する 例えば、サイクルタイムの各時間を人間の努力のみで短縮しようとする それにも関わらず、開発がもたらしたユーザーへの効果やビジネス上の成果に無関心というのは順序おかしいよね、という話。 などと考えていたら開発生産性カンファレンス2024 - 登壇資料まとめ|610を見る限り、近しい主旨の論説を散見するに至り、もしかしたら世間の議論
2024年2月16日 Developers Summit 2024 登壇資料 https://event.shoeisha.jp/devsumi/20240215 ■しかく ZOZOエンジニア向け会社説明資料 https://speakerdeck.com/zozodevelopers/company...
エンジニアリング戦略室の高井といいます。 みなさん、GitHub Copilot は利用されていますか? GitHub Copilot は GitHub と OpenAI が共同で開発した生成 AI を活用した開発支援ツールです。コードの自動補完、コード生成、ドキュメントの提案など、多岐にわたる機能を提供し、開発者の生産性を向上させることを目的としています。 マネーフォワードでは、昨年度にトライアルとして Copilot の利用を開始しました。本記事では、Copilot を利用して半年以上経過して、その利用がどのような効果をもたらしたかをレポートします。なお、ここで GitHub Copilot として言及されている Copilot のプランは GitHub Copilot Business です。 Copilot 利用状況・分析対象 なお、分析にはエンジニアリング組織のパフォーマンスを可
www.eleken.co ユーザーエクスペリエンス(UX)は、ウェブサイト、アプリケーション、またはプロダクトの設計と使いやすさに焦点を当てています。優れたUXとは、ユーザーがそれほど困難なく問題を解決したり、ニーズを満たしたりできることを意味します。これは、ユーザーの満足度を高め、コンバージョン率を向上させ、ビジネスコストを削減することにつながります。 しかし、UXの良し悪しを決めるのはユーザーであることは、誰もが知っていることです。では、あなたやあなたのデザインチームがすべてを正しく行い、プロダクトが素晴らしいユーザー体験を提供しようとしていることを理解するには、どうすればよいのでしょうか? ここで役に立つのが、UXデザインのKPI例です。Elekenはプロダクトデザイナーのチームであるため、KPIパフォーマンスの測定は、プロジェクトでの作業における構成要素の1つとなっています。UX
@Pepabo Tech Conference #15 - ECプラットフォームSUZURIの開発の裏側 https://pepabo.connpass.com/event/215058/
※(注記)この記事は 開発生産性 Advent Calendar 2022 のカレンダー2の13日目の記事になります。 前回は1日目は hiroshinishio さんの 『より筋肉質なチームにするために、開発者が見るべき21のDevOpsアウトプット指標』 で、個人的には指標それぞれの分析や改善の方法が書かれていて勉強になりました。 こんにちは。 モノタロウで主に DevOps エンジニアとして活動している伊藤です。 休日はジムに節制した食事、サウナと健康を意識するおじさんとしても活動しています。 (最近だと渋谷の改良湯さんのサウナと外気浴スペースの具合が最高でととのいました) 今回は DevOps Four Keys*1 (以降 4keys と呼称) というソフトウェア開発チームのパフォーマンスを示す4つの指標を導入し、部門の目標として掲げたここ1年の取り組みを紹介できればと思います。 背景
オリジナルグッズ作成・販売サービス「SUZURI」に関わるエンジニアメンバーや事業部長が登壇し、SUZURIの開発の今や、現在の課題・今後の取り組みについて話す「43万人超のクリエイターの表現活動を支える!ECプラットフォームSUZURIの開発の裏側」。ここで技術部の近藤氏が登壇。生産性をすることになった背景と、具体的な測定方法を紹介します。 自己紹介近藤宇智朗氏(以下、近藤):では、お願いします。「生産性を可視化したい」と題して発表します。ということで、自己紹介します。私は技術部に所属している、近藤といいます。ふだん、インターネットなどでは"うづら"と呼ばれているので、お気軽にうづらと呼んでください。現在、技術基盤チーム兼データ基盤チームという感じで働いていて、SUZURIの事業部には直接所属していませんが、お手伝いという感じで今回はお話しします。 ちなみに、福岡市のエンジニアカフェとい
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? 1. はじめに システム開発にまつわるチームや組織の活動は、指標なんかで測れるわけないやろ〜、という声は根強いです。ましてや、それが人の評価になろうものなら、感情的な反発さえありえます。Martin Fowlerもこちらよりです。 一方で、何らかの指標で測れるはずじゃないの?という声も根強い気がします。測れんかったら、良くなったかどうか、どうやって判断すんねん、という意見ですね。DORA Metricsを擁するGoogleはこちらよりですかね。 私はどちらなのかというと、後者で、測れるものは測りたいタイプです。もちろん、すべてが正しく測
はじめに こんにちは。プロセス改善・アジャイルコーチで、Tech Blog編集長の高橋(@Taka_bow)です。 皆さんは、2021年6月に生まれたGitHub Copilotを利用していますか? この生成AIベースのコーディング支援ツールは、コードの自動補完や生成、関数の自動生成、エラー修正支援など、開発者の作業を多面的にサポートします。 ファインディでは2023年3月から導入し、開発チーム全員が日常的に活用しています。Findy Team+で効果を測定した結果、コーディングの効率化やコミュニケーションコストの削減、さらには開発者の満足度向上など、多くの利点が確認されました。 今回は、このようなソフトウェア開発における生成AIの影響を分析した最新の論文を紹介します。GitHub Copilotが開発プロセスにもたらす変化や、開発者の生産性への影響についての研究が書かれた、興味深い論文で
こんにちは。ブランドソリューション開発本部フロントエンド部の御立田です。フロントエンド部の部長とWEAR Androidのブロック長を兼任しており、普段は部署全体の管理・リスクマネジメントや、Android開発における設計などを行っております。 本記事では、運用改善によるチームパフォーマンス向上のための取り組みについてご紹介します。なお、フロントエンド部WEAR Androidブロックで実施した内容となっており、一部アプリ開発向けの施策ですのであらかじめご了承ください。 目次 目次 はじめに 生産性に対する課題感 改善結果 サイクルタイム平均値 スタッツ 数値分析 問題点の推測 問題点の認識 対応策 レビュー環境への対応策 レビュー会の開催 PR単位でビルドの共有 巨大なPRへの対応策 サブタスクで粒度を下げる 常にアップデートすることへの対応策 開発者リソースの再配分 PRテンプレートを
この記事は2024年3月に書かれたものです。この警告を記載している2025年3月現在、筆者のオブザーバビリティバックエンドの評価軸はかなり変わりました。 筆者が暇なら書き直したいのですが、あいにくその時間的コストは払えないためそのまま残しています。 依然として筆者にとってHoneycombがほかとは一線を画する最強であることには2025年現在も変わりがありませんし、お読みいただくことに一定価値があるとは思いますが、評価の一部が現在の筆者にとって無意味となっていることだけ明記しておきます。 背景 2024年現在、OpenTelemetryが盛り上がっており、ベンダへの依存度を下げてテレメトリを収集・送信することがトレンドになってきているように思います。多くの企業様で、OpenTelemetry対応のオブザーバビリティバックエンドを選定されているのではないでしょうか。 一方で、E2E自動テスト
ソフトウェア開発において急速に生成AIが導入されるなか、デベロッパーの生産性を測定する方法の課題が問われてきています。本稿では、生成AIを活用したソフトウェア開発した際の生産性測定のメトリクスを説明していきます。 ソフトウェア開発における生成AIの現状と課題 2024年は、生成AIにとって、熱狂、楽観、そして慎重さが交錯する節目の年となりました。生成AI搭載の生産性向上ツールを使用すれば、反復的なコーディングや面倒な作業、さらにコード生成を自動化して効率を高めることができます。しかし、約1年が経過した今、多くの組織が生成AIを活用した取り組みから得られる成果を定量化することに苦労しており、組織が求めるビジネス成果が反映されるように生産性測定のメトリクスの見直しを進めています。 これまでも、生成AI搭載のデベロッパーツールの有無にかかわらず、デベロッパーの生産性を測定することは難しい課題とさ
CVSS(Common Vulnerability Scoring System)は、脆弱性管理における基本的な仕組みとして広く利用されており、業界全体のデファクトスタンダードになっています。CVSSはFIRST(Forum of Incident Respones and Security Teams)内に設置されたCVSS-SIG(Special Interest Group)1によって策定され、2023年7月現在の最新バージョンは3.1となっています。2023年6月に次バージョンである4.0のパブリックプレビュー版2が公開されており、寄せられたコメントをレビュー・反映した後、2023年10月を目途にバージョン4.0の公開が予定されています。本稿ではパブリックプレビュー版に基づいて、現行のバージョン3.1との変更点を解説します。また、SSVC(Stakeholder-Specific
こんにちは。AIアシスタントチームでプロダクトエンジニアをしているmizunaoです。 SmartHRでは先日、人事・労務に関する問い合わせにAIが回答するAIアシスタント機能をリリースしました。 この機能では裏側でLLM(大規模言語モデル)を利用していますが、開発にあたって「LLMの精度をどう評価するか?」という課題に直面しました。 実は私たちAIアシスタントチームでも、まだLLMの評価指標を体系的に活用できていない状況で、これから本格的に取り組んでいく必要があります。そこで今回、LLMの評価指標について調査・整理したので紹介します。 LLM評価指標とは? LLMの出力を評価するには、人の目だけでは限界があります。そこで登場するのがLLM評価指標です。これは入力・出力・コンテキストといった情報をもとに評価器(Scorer)がスコアを算出し、そのスコアが一定の基準(閾値)を満たしているかど
これは何? 開発生産性Conferenceに参加し,Kent Beck氏の講演を聞いてきました。 とても興味深い内容だったので備忘録も兼ねてQiitaに感想をまとめます。 一回聞いただけなので間違っている箇所や加筆点があればコメントや修正リクエスト等いただければ嬉しいです。 この記事について グッドハートの法則について 良くしようとした結果悪くなる 講演の中でKent Beck氏は,ものごとを良くしようとした結果悪化してしまうことがあるという話をしていました。 また,生成AIの登場により,この傾向が強まるのではないかという見解も述べられていました。 この話を聞き、自分は最近xでみるような,AIに開発を任せすぎて保守できなくなり、人間のソフトウェアエンジニアが呼ばれるのではないかという話を思い出しました。以下はその例です。 開発者の生産性をあげるためにAIを導入した結果,開発者のシステムに対
デプロイ頻度とリードタイムは、開発チームが自らのパフォーマンスをモニタリングするうえで欠かせないメトリクスである。それらが、収益性や市場占有率といった組織パフォーマンスに影響を与えるからだ。その調査結果は、DevOps Research and Assessment(DORA)が特定した4つのキーメトリクス、いわゆる「DORAメトリクス」の要素として浸透した(後述するが、DORAメトリクスで扱うのは、リードタイムではなく「変更のリードタイム」である)。 その重要性ゆえに、チームや組織はこれらのメトリクスの計測と可視化に努める。可能な範囲で正確な値が欲しい。そうして、チケット管理ツールやバージョン管理システムからテレメトリを収集、集計し、チームのモニタリングダッシュボードにその実績値を可視化するのだ。 しかし、しばらくメトリクスを運用してみると、その扱いづらさに気づく。計測値や集計値のばらつ
技術本部 Mobile Applicationグループの山本です。名刺アプリEightの開発を行っています。 今回はMobile ApplicationグループのEight開発チームの生産性指標をFour Keysからベロシティを含む別の値に変更した話をします。 一般的にはベロシティは生産性指標にすべきではない、Four Keysは生産性指標として適切であるという評価だと思います。もちろんそれは理解した上でこの選択をしています。その理由について説明します。 なお組織全体がこのように考えているわけではないということに御注意ください。例えば同じMobile ApplicationグループでもSansan開発チームはFour Keysを生産性指標にしています。 生産量2倍計画 現在技術本部では中期的な課題として1年で単月の生産量を2倍にするという目標を掲げています。 ポイントとして、技術本部のレ
State of DevOps Report 2021を日本語で解説 ーTeam Topologies Model、プラットフォームが重要な要素ー はじめに State of DevOps ReportはDevOpsの成熟度についてアンケート形式で調査しているレポート資料です。毎年アップデートされているので、直近の動向などを理解し、かつ課題解決の活路を見出すのに良いレポートです。2021版が先日リリースされていました(もとのレポートはこちら)。 デジタルトランスフォーメーションの文脈の中で、ソフトウェア開発がますます増えてきていますが、単に一発作っておしまいではなく、継続的に進化させることが求められます。継続的にサービスを進化させていくことがビジネス力の根源となるということをアンケート調査から証明したのが、このレポートで、調査内容については、『LeanとDevOpsの科学』をご一読いただく
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く