tl;dr ウォーターフォールという言葉を悪口として使うのは良くないんじゃない？ 空想上の開発手法ウォーターフォールと進化したウォーターフォール アジャイル開発の説明がされるとき、アンチパターンとして「ウォーターフォール」が使われることがあります。これは「ダメな開発現場」と同義で使われており、共通仮想敵としての空想上の開発手法とも言えます。 それは、曰く、硬直化していて変化や手戻りを許さず、一本道でフィードバックサイクルがない、数十年アップデートされていない古臭い手法のことらしい。 もちろんそういう開発をしている現場もまだ数多く存在するでしょう。ただ、ウォーターフォールをカイゼンし進化させている人達もいます。そういう人たちの話を聞くと、例えば以下のような話を聞きます。 一ヶ月で１ウォーターフォールを回す 前の手順に戻る手続きが定められている 初期フェーズから開発者を巻き込む 定期的なレビュ
アジャイル型開発における未完成の責任 東京地判令3.11.25（平30ワ25117） - IT・システム判例メモ
アジャイル型でアプリ開発を進めたところ、完成に至らなかったことについて、ベンダの不完全履行、プロジェクトマネジメント義務違反等が主張されたが、いずれも否定された事例。 事案の概要 eスポーツ事業の企画・運営等を行う原告（Ｘ）は、ゲーマー向けソーシャルアプリの開発を構想し、開発ベンダである被告（Ｙ）との間で、平成28年8月18日に、ゲームに参加する人をマッチングし、参加者同士がコミュニティを形成するソーシャルメディア機能を有するソフトウェア（本件ソフトウェア）を開発する契約（本件契約）を締結した。対価の額合計は、2450万円。その支払は1000万円、1000万円、450万円の3回にわけて行われることとされ、最後の450万円は、納品物を納入後に支払うこととなっていた。 本件契約の締結前には、Ｘは、検収に合格しなかったら、支払済みの代金を返金する条項を設けることを求めたが、Ｙは「返金を想定してお
アジャイルを実践する組織であってもウォーターフォールを学ぶことには価値がある - mtx2s’s blog
「すべてのライフサイクルモデルの祖は、ウォーターフォールモデルである」とは、スティーブ・マコネルの言葉だ1。また、ソフトウェア開発ライフサイクル（SDLC）に関するGitHubの文書では、広く採用された最初のSDLCがウォーターフォールモデルであるとされている2。 そこに、ウォーターフォールを学ぶことに対する価値がある。それは、スクラムを導入し、アジャイルソフトウェア開発を実践する組織にも言えることだろう。いや、そうであるからこそだ。どんなソフトウェア開発プロセスモデルであろうと、ウォーターフォールから派生したり、何らかの影響を受けていると考えられる。したがって、ウォーターフォールへの理解から、自分達がやっていることの本質を見いだせるのではないだろうか。 ウォーターフォールなんて誰でも知っていると思うかもしれないが、そうとも限らない。確かにウォーターフォール未経験のソフトウェア開発者は少な
Microsoftの専門家「ウォーターフォールは一切メリットがないのでやめておきなさい」アメリカでは、アジャイルやスクラムの進め方が「常識」としてソフトウェア開発の場で浸透している話
いぐぞー ✈️ 旅するプログラマー @igz0 旅とプログラミングをこよなく愛します。 アメリカ大陸🇺🇸を横断しました！！小学生からプログラミング→新卒SIer→Webに目覚め自社開発のWeb系エンジニア。テレビ出演経験あり。 個人開発者。読書・IT関連を中心にツイートします！！ネタツイート有。アイコンは@ixy先生に利用許諾済み。Amazonアソシエイト参加。 note.com/igz0/ いぐぞー ✈️ 旅するプログラマー @igz0 Microsoftの専門家「ウォーターフォールは一切メリットがないのでやめておきなさい」 > アメリカでは、アジャイルやスクラムの進め方が「常識」としてソフトウェア開発の場で浸透している これマジ？？ 日本のIT企業が、米国では「時代遅れ」のウォーターフォールを未だに信奉してるってコト！？ pic.twitter.com/jRofJKmAKM 202
（まだ書いてる途中）僕がシニアエンジニアとしてどのようにアジャイル開発を実践しているかの現在地を紹介します。アジャイルな開発に取り組んでいるみなさんにとって何かしら、ヒントや刺激になるようなものがあると嬉しいです。
ウォーターフォールの悪魔化とアジャイルの神格化、もうええでしょう - GoTheDistance
毎年必ずどこかでウォーターフォールとアジャイルを対立させ「ウォーターフォールwwwww」と味付けしたツイートに待ってましたと総ツッコミが入るムーブがあるように思います。 今シーズンは下記のツイートがK点超えの大ジャンプを記録しました。 今どきウオーターフォール型開発とアジャイル開発の違いをどうこう言う必要はないかと思うが、若手の技術者は間違ってもウオーターフォール型開発のほうに行ってはダメだぞ。失敗は絶対に許されないと連呼する世界と、とっとと失敗しようぜと言う世界では、どちらが成長できるかは明らか。 https://x.com/toukatsujin/status/1863023816290762841 Xでは多方面から「いやいやいやいや、どんな世界線ですかそれ？！」と突っ込みが入った。失敗の許容度がゼロか100かってなんぞ？っていう感じ。そらそうよ。 これを受けて木村氏は「批判の中で呆れ
ソフトウェアの開発手法としてアジャイルを採用したプロジェクトはアジャイル以外の手法を採用したプロジェクトに比べて失敗率が268％も高いという調査結果が発表されました。 268% Higher Failure Rates for Agile Software Projects, Study Finds - Engprax https://www.engprax.com/post/268-higher-failure-rates-for-agile-software-projects-study-finds 268% higher failure rates for Agile software projects • The Register https://www.theregister.com/2024/06/05/agile_failure_rates/ 今回の調査はコンサルタント会社「
敏腕PMのもとでアジャイル開発やってみた
これは何？ 最近業務でやってたプロジェクトのキリがよくなったので、少しでも開発プロセスの知見を残そうと思って書いた記事です。 弊社は基本アジャイル開発で案件を進めてるんですが、具体的な開発プロセス事例の紹介って案外アウトプットされないんですよね。 直近の案件の中で、長らくお世話になっている敏腕PMの方（以下Mさんとします）がいるんですが、直近の案件での事例を記事にしていいかと聞いたら快諾してくれたので、実際にやっていたことを書いていこうと思います。 はじめに アジャイル開発について語る際に、最も重要なのは 正解は一つではない ということです。 アジャイル開発の成功は、それぞれのチームの特性や状況に合わせて、柔軟にプラクティスを調整していくことにかかっています。この記事で紹介する内容は、あくまでも一例として捉えていただき、自分たちのチームに合った形を探る際の参考程度にしていただければと思いま
日本にルーツを持つアジャイルが、なぜ日本企業では機能しない（しにくい）のか、という長年の疑問に対して、渡辺雅子さんの「論理的思考とは何か」という書籍がヒントになるな、と思ったで紹介します。 「アメリカにおける経済領域の論理的思考を前提としたアジャイル」を「日本の社会領域の論理的思考を前提とした企業に適用する」には、アジャイルの外側に「チームと組織が価値観とすり合わせる時間」を作る必要があると思うのです。 論理的思考とは何か (岩波新書) 作者:渡邉 雅子岩波書店Amazon 論理的思考とは何か 本書の主張は「一般的に『論理的思考』を言われているものは、世界共通ではなく、その国の文化に大きく影響を受けている」というものです。特に初等教育における作文教育や歴史教育が影響しているそうです。この論拠や実例については書籍をぜひ読んでいただければと思います。 で、国と論理的思考の違いをまとめたのが以下
アジャイルの実践に必要だった大切な参考書 ── 開発者として深く成長させてくれた本は何ですか？ - Agile Journey
技術ブログやエンジニアセミナーなど、ソフトウェア開発に必要な情報を得る機会はたくさんありますが、系統だった知識をまとめて学ぶなら「本」は依然として便利ですし、繰り返し参照するにも適しています。 また本には人生を変える力があり、多くのエンジニアが書籍から知識を得るだけでなく、本と向き合うことでやり方や考え方を見つめ直しています。今回はAgile Journeyと関係のある8人の開発者に、エンジニアとして壁を乗り越え、アジャイルに取り組む契機になるような自分にとって大切な本を推薦してもらいました。 紹介する中には現在では入手の難しい本もありますが、機会があればぜひ手に取ってみてください。 アジャイルやXP・スクラムをどう実践すればいいのだろう？ アジャイルプラクティス 達人プログラマに学ぶ現場開発者の習慣 アジャイルな見積もりと計画づくり 価値あるソフトウェアを育てる概念と技法 塹壕よりScr
この記事では、「アジャイルはウォーターフォール時代の何を反省するのか」「アジャイルで何が改善するのか」について、個人的な考えを説明します 極端なことを言っている部分はあるので、誤解している箇所や異論があれば、やさしくコメントで教えていただければ幸いです 言いたいこと 「ウォーターフォール＝諸悪の根源」というのは誤解で、問題は請負契約にある 請負契約で「顧客の真の要望が実現されない」のは当然、インセンティブ設計がおかしい 日本版のアジャイルソフトウェア開発宣言には「外注よりも内製を」と書くべき 競争に勝つためには内製化は進む(でも内製化はとても難しい) ベンダーへ「君はアジャイルをやるか迷える立場じゃないよ」 目次 用語 ウォーターフォールは本当に諸悪の根源か？ 「ウォーターフォール＝諸悪の根源」という誤解 問題の原因は請負契約 なぜ請負契約は失敗しやすいのか？ ベンダーは「システム開発だけ
コードを書き始める前からテストをずっと考える ─ 継続的テストモデルとシフトレフトなテスト活動をアジャイルにどう取り入れるか - Agile Journey
読者の皆さんは、テストについてどのようなイメージをお持ちでしょうか。「開発の後に行う確認作業」といったイメージを持たれている方もいるかと思います。 しかし、開発しようとしているソフトウェアに不具合の混入を防ぐには、もっと早い段階でテストについて考えることが必要です。こういったテスト活動は、プログラムを1文字も書いていないときから始めることができるのです。 本記事では、2016年に提唱された継続的テストモデルを紹介しつつ、アジャイルとも親和性のあるシフトレフトなテスト活動について解説していきます。 DevOpsにおけるテストの考え方 DevOpsのループ図とは何か？ 継続的テストモデルとは何か 継続的テストモデルにおいてテストは「活動」である シフトレフトなテスト活動とシフトライトなテスト活動 シフトレフトなテスト活動としてのテスト駆動開発 コード実装を始める前から行うテスト活動 シフトレフ
なぜ石井食品は「日本一のアジャイルな食品工場」を目指すのか？ ソフトウェア開発の経験を社長業に生かす石井智康さんインタビュー - Agile Journey
お弁当の定番『イシイのおべんとクン ミートボール』などの商品作りを無添加調理で進める石井食品株式会社*1では、まだ40代の石井智康さんが代表取締役を務めています。石井さんは創業家の出身ながら、大学卒業後はIT業界に入り、フリーのスクラムマスターとして活躍するなど、石井食品とは距離を置いていました。 しかし、フリーランスとして働くなかで、改めて社会にどのような貢献ができるかを考えた結果、食の課題に取り組むため家業を継ぐことを決意。2018年に代表取締役社長に就任すると、それまで培ったソフトウェア開発やアジャイルの知見を生かして、さまざまな業務プロセスやコミュニケーションの改革に取り組んでいます。 企業を取り巻く環境が変化するなか、アジャイルに対する理解と知見を持つソフトウェアエンジニアが企業経営に取り組むことで、どのような変革をもたらすことができるのでしょうか。アジャイルとの出会いや石井食品
アジャイルを支えるテストアーキテクチャ設計/Test Architecting for Agile
高品質と高スピードを両立させるソフトウェアQA/Software QA that Supports Agility and Quality
ウォーターフォールとアジャイルは、それぞれ異なる前提と目的を持つマネジメント手法です。ウォーターフォールは全体計画の精度を前提に効率的な開発を目指し、アジャイルは変化に適応しながら試行錯誤を重ねることに重点を置きます。しかし、世の中ではマネジメント手法としてフェアな評価ができていないようにも感じます。 その要因は、アジャイルの説明が精神論や感情論に寄りすぎている点にあると思っています。そこで、そういった要素を排除し、双方をマネジメント手法として整理してみました。 前提条件 僕は、いわゆるエンタープライズ業界の人なので、SIerがいるような規模の組織を前提にしていますが、マネジメント手法としての考え方は、どの業界でも利用できると思います。 「ウォーターフォール」とは、大手SIerなどで定義されているウォーターフォール的なマネジメント手法のこと。V字と呼ばれる要件定義、基本設計、詳細設計、実装
受託開発でもアジャイル開発できました / Agile in Contract Development
AWS Developer Live Showにて。 https://aws-dev-live-show.connpass.com/event/331735/ プロフィールやお問い合わせはこちらからどうぞ！ https://agile-monster.com/profile/ https:/…
アジャイル開発の浸透？なんだそれは。 アジャイル開発という概念が世に出て二十余年（2001年「アジャイルソフトウェア開発宣言」による）、最早、この技術も最新とは言えない、成熟したものとなりました。あなたの職場でも「アジャイルに進めよう」的な、凝り固まらず柔軟なプロジェクト体制にして行こうという流れ、プロダクト開発の長大化を防ぎアウトプットを細かく出していこうという意識変革が内外から求められているかと思います。 しかしプレイヤーとしての皆様は、とはいえ作るものは変わっておらず納期が決まっているので大変になるだけ、だとか、現場ボトムアップな提案は通らずトップダウンにやることが降ってくるからやる意味なくね、だとか、果ては作るもの・仕様が決まってないけど予算がついたからいい感じにアウトプット出してね、の意味だとか、都合よく「アジャイル」を使われて疲弊することもあるでしょう。多くは会社の通例や予算検
安全最優先ゆえの新技術導入に慎重な体質 関電システムズは関西電力100％出資の子会社として、関西電力向けシステム開発を専門とする機能子会社だ。2019年4月より関西電力と関電システムズの合同でDevOps推進が始まったが、当時の関電システムズと関西電力の関係は、IT部門再編に伴い役割分担が大きく見直された直後であったこともあり、西内氏が「完全なる親子関係」と振り返るほど強い上下関係だったという。 株式会社関電システムズ テクニカルラボ DevOps推進グループ テクノロジスト（プロフェッショナル）西内 慶子氏 そのため関電システムズの開発体制は決められたことを計画どおり進めていくウォーターフォール型が基本方針であり、技術面では「枯れた技術」の使用が推奨されているなど、新技術の導入にあまり積極的ではなかった。 こうした体質は以前から課題認識されており、関電システムズではDevOpsの推進前に
なぜ、安易に「スクラムで開発します」と言わなかったのか？ - 結果整合的アジャイルを目指す開発 - カミナシ エンジニアブログ
プレイングマネージャー型のEMをしています、鈴木（@szk3）です。 今回は、私たちのサービスチームが新規プロダクト開発を始めるにあたって「スクラムを導入しなかった」経験について共有します。 このタイトルだけを見ると、スクラムに対して否定的な印象を持たれるかもしれません。しかし、これはスクラムへのアンチテーゼではありません。むしろ、スクラムの価値をリスペクトし、その実践に真摯に向き合いたいからこそ行った慎重な決断でした。実際、新規プロダクト開発の開始とほぼ同時期に認定スクラムマスター資格も取得し、スクラムについての理解を深めていく中で、この決断の意義をより一層実感しています。 新規プロダクトの開発において、アジャイル開発を取り入れることは当然の選択肢として考えられます。むしろ、アジャイル開発の実践にスクラムのフレームワークを使うことは、実質上のスタンダードとなっていると感じます。しかし、「
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? 先日The Registerを見ていたらアジャイル開発の失敗率は268%も高い Study finds 268% higher failure rates for Agile software projectsという記事が目に入りました。 The RegisterはITニュースサイトで、日本で言うところのITmediaやWIRED、GIGAZINEみたいなところですかね。 その記事は元記事を紹介しているもので、『元記事はImpact Engineeringの宣伝ではあるが、アジャイル開発は期待ほどうまくいかないという疑念を抱かせるのにも
目標設定は好きですか? アジャイルとともに目標と向き合い続ける方法 / Do you like target Management?
Developers Summit 2024 Summer での登壇資料です https://event.shoeisha.jp/devsumi/20240723/session/5111
失敗体験を突き詰めてたどり着いたスクラムの合理性 ─ 今井健男さんのはじめてのアジャイル - Agile Journey
Agile Journeyをご覧のみなさん、こんにちは。今井健男（@bonotake）と申します。「ぼのたけ」と名乗っていることもあります。普段はフリーランスのアジャイルコーチをしつつ、現在は国立情報学研究所という国の研究所でスクラムの研究をしています。 今回、「はじめてのアジャイル」という連載企画に声をかけていただき、僕がアジャイルの道に進むきっかけをこちらに書くことになりました。ただ、執筆の依頼をお引き受けはしたものの、正直なところ、僕の体験が皆さんにとって何かしら参考になるかは分かません。もともとずっとソフトウェア工学の研究をしている研究者だった、という特殊な経歴の持ち主だからです。 恐らく他の人とはかなり変わった視点からアジャイルを体験してきていて、あまり共感されるような内容ではないかもしれませんが、それでも読者の方のうち何人かは面白がってもらえるかもしれないと期待して、ひとまず筆
後輩に提案されたスクラムにうまく適応できなかった私が開発チームのアジャイルを先導できるようになるまでに考え実践したこと - Agile Journey
アジャイルに興味を持った1人あるいは数人から始めることは、アジャイルの導入においてよくあるストーリーです。とはいえ昨今では、例えばスクラムを導入する開発チームも増えているでしょうし、ほかのメンバーが主導した取り組みとしてアジャイルを受け入れる方も多いでしょう。そんな経緯でスクラムに触れ、既存の開発プロセスとの違いに戸惑い、むしろ積極的にアジャイルを学ぶことで克服した過程を、岸田篤樹（パウリ）さんに寄稿いただきました。 Agile journeyをご覧のみなさま初めまして。株式会社ビットキーでEM（エンジニアリングマネージャー）・スクラムマスター・技術広報をしているパウリ（@pauli_agile）です。私は2015年に新卒でプログラマーとしてキャリアをスタートしました。 その頃の世の中ではすでに、アジャイル開発がさまざまな開発組織に浸透しつつある状況にあったかと思います。ただ、実際に配属さ
フルリモート環境でのアジャイル開発って実際どうなの？ NeWork の取り組みを紹介 - NTT Communications Engineers' Blog
この記事では、NeWork の開発チームがフルリモート環境でアジャイル開発するにあたり個人的に重要だと感じた部分を紹介します。 目次 目次 はじめに 背景 NeWork のチーム構成と動き方 コミュニケーションの工夫 オンラインの人を取り残さない各種ツールの利用 各種打合せ アイデア出し・情報共有・レトロスペクティブ 開発作業 話しやすいチームの文化づくり オープンな打合せ 話しかけやすく・呼び出しやすい環境 常に会話できることで雑談 データでみるコミュニケーション量 まとめ おわりに はじめに こんにちは、NeWork 開発チームの加藤です。私は普段、オンラインワークスペースサービス NeWork の開発エンジニアをしています。 NeWork は、手軽に話しかけることを重視したオンラインワークスペースサービスです。従来の Web 会議ツールとは異なり、話したいメンバーとすぐに話すことがで
開発規模が拡大してもアジャイルであり続けるための「組織やチームに対するコーチング」 ─ ログラス松岡幸一郎さんインタビュー - Agile Journey
新規プロダクト開発チームやスタートアップにおいて、アジャイルの経験を積んだエンジニアが初期メンバーにいれば自然と開発プロセスにアジャイルが取り入れられ、スムーズにプロダクト開発にフォーカスできることがあります。しかし開発組織が拡大して経験の浅いエンジニアが増えてくると、今度はアジャイルのマインドやプラクティスそのものの定着がしばしば課題となります。どうすれば組織が拡大してもアジャイルであり続けられるのか？ その実例や情報の共有はまだまだ足りていません。 ドメイン駆動設計（DDD）に関する情報発信でも知られるエンジニアの松岡幸一郎（@little_hand_s）さんは、そうした「組織を対象とした課題」の解決にフォーカスするため、システムコーチングという組織やチームに対するコーチング手法を取り入れました。個人に対するコーチングはかなり知られてきましたが、組織に対するコーチングについては耳慣れな
失敗から学べることがアジャイルの本質。 最近学んだのでホテルの朝食ビュッフェからアジャイル開発を伝授する。 ビックバンリリースを避ける バイキング形式であるあるなのだけど、初手で取りすぎて後から食べようと思ったデザートなどの余力が残せない。 また多めに取った唐揚げが思ったのと違って箸が進まない。 このようなことを防ぐため、バッチサイズは小さくする必要がある。つまり1品1~2口程度の量に抑えて気になるメニューをピックアップしていくと良い。 美味しいなと思ったら2～3周とイテレーションを回せばよいのだ。 小さく始める。これはアジャイルの基本であり、バイキング形式の朝食の基本。 優先順位をつける 食べたいものは何か、を最初に知るためにもまず広く、深くIssue（品）を見て回ることが重要。 ドメインを知り、解くべきIssueに優先順位をつけるのだ。 つまり実行よりも計画が先。 計画をした上で小さく
「HRMOSタレントマネジメント」目標・評価チームでは日々スクラムを実践し、アジャイル開発を目指しています。 私たちのチームは開発の中で、以下の課題に直面しました。 🚨 開発者にとって、他の開発者やプロジェクトへのサポートや連携に入りづらい 仕様や見積ドキュメントが標準化されておらず、開発案件の進め方や知識が属人化していました。 これにより、開発者がどう他の開発者やプロジェクトへのサポートや連携に入って良いのかわかりづらくなっていました。 🚨 PO・EMにとって、開発の計画が立てづらい サポートへの入りづらさによるコミュニケーション工数の増加、および仕様見落としによる手戻り工数の増加により、ベロシティ見積の信頼性が低下していました。 これにより、プロダクトオーナー（以下、PO）・エンジニアリングマネージャー（以下、EM）は不測の事態に備えたバッファ工数込みで見積らざるを得ず、開発の計画
正直言って、日本のIT業界はここまでまずい状況だとは思わなかったぞ。以前からこの「極言暴論」で日本のIT業界のご用聞き商売や人月商売の愚かしさ、そして多重下請け構造の人でなしの構造を問題にしてきたが、今回の問題は別の話だ。技術者の発想が硬直化しているというか、ご用聞き商売や人月商売に毒されてしまっているというか、これじゃ新たな技術の開発やユニークなデジタルサービスの創出なんてできないぞ。困ったものだ。 ここまで読んで「いったい何の話をしているのか」といら立つ読者がいるだろうし、「ああ、例のやつね」とほくそ笑む人もいるかと思う。事の発端は2024年12月1日に、私がX（旧Twitter）に投稿したツイートである。内容はこうだ。「今どきウオーターフォール型開発とアジャイル開発の違いをどうこう言う必要はないかと思うが、若手の技術者は間違ってもウオーターフォール型開発のほうに行ってはダメだぞ。失敗
昨今、DXやアジャイル開発の流行により、「要件定義を無くそう」という声がよく聞かれる。 佐藤氏によると、要件定義を完全に無くすことは、一般的な開発プロジェクトでは難しい一方で、特定のケースでは要件定義を省略することも可能であるという。 「PoC（概念実証）レベルの開発や、個人レベルなどシンプルなソフトウェア開発であれば、要件定義を行わなくても、とりあえず作ってみて、実際に使い、修正を繰り返す、というケースもあります。たとえば、最近のノーコードツールであるbubbleなどを活用すれば、初期の要件定義を行わずにすぐにプロトタイプを作り、必要に応じて素早く修正できるため、手戻りが極端に少なくなります。このような開発手法では、動作検証を繰り返しながら、最適な形を見出していくプロセスが可能となり、要件定義を省略する選択肢も考えられるわけです」（佐藤氏） しかしながら、これらはあくまで例外であり、特に
デブサミ2025で品質に関するパネルディスカッションに参加してきました。アジャイル開発において「価値提供のスピードを落とさずに品質を維持するためにどうするか」というテーマにおいて、僕はアーキテクトという立場から「構造」の側面、ブロッコリーさんはQAエンジニアという立場から「プロセス」の側面から話をしました。 アジャイル開発で品質とスピードを両立するには、構造とプロセスの両面からのアプローチが必須です。 はじめに 参加したのはデブサミ2025での「開発スピードは上がっている…品質はどうする？ ～スピードと品質を両立させるためのプロダクト開発の進め方とは～」です。もう1人の登壇者である風間さん（ブロッコリー）からお誘いを受けてお話しさせていただきました。パネルは安達さんにまとめてもらい、良い形になったと思います。 ブロッコリーさんのブログ「Developers Summit 2025で企画作成
「しかたないスクラム」じゃないアジャイル開発を求めて - カミナシ エンジニアブログ
「しかたないスクラム」じゃないアジャイル開発を求めて はじめまして。1月からカミナシでエンジニアリングマネージャ（EM)を担当している @daipresents と申します。 カミナシでは新規事業開発のEMとして、絶賛全力で開発を支援しています。カミナシはとても現場に近い開発環境なので、ご興味のある方はぜひカジュアル面談 をお願いします！ この記事では、僕が関わる「新規事業開発」で実際に行われている「開発プロセス」と、そこに行き着いた経緯や意図をまとめたいと思います。タイトルにあるように、チームは「スクラムじゃないアジャイル開発を求めて」きたように感じています。 チームの立ち上げ期 僕は10ヶ月ほど前から業務委託として参加しており、現在のチームに入る前に、別のチームの支援も行っていました。そこではスクラムが採用されていて、試行錯誤しながら自律したチームを目指していました（今もがんばっていま
『アジャイルを採用したソフトウェアプロジェクトの失敗率はその他の手法と比べて268％も高いことが判明』は不明瞭 ~書籍「Impact Engineering」を読んでみた感想 ~ - Qiita
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? 「アジャイルを採用したソフトウェアプロジェクトの失敗率はその他の手法と比べて268％も高いことが判明」 という記事が話題になっています。 言及している著書がCEOを務めているイギリスの調査・コンサル会社であるEngpraxが挙げている元の記事はこちら（その調査自体を行なったのもEngprax社） 記事に書かれていることの考察や要約は下記で分かりやすく纏めて下さっています。 記事への反応 記事への感想・反応はだいたい下記のパターンのどれかに該当すると思います。 失敗の定義は？ そもそもアジャイルできてなくね？ 下記が失敗するのはアジャイル
「まずは経営の意識改革だ」「まずは内製エンジニアだ」。 確かに経営の理解、SIer依存やレガシーシステムの解決は重要ですが、それは簡単には解けないパズルです。待っていても何も変わりません。 DXを前に進めるには、「意識が変わりきらない経営層」「金のかかるレガシーシステム」「足りない人材」の中で、どう動くかを考えるべきです。そのためには現場のリーダーがアジャイルをはじめとすると様々な技術をどう活用し、どう適用するのかを理解し、行動する必要があります。 「まずは経営層が」という言説の誤謬 最近、繰り返しウォーターフォールとアジャイルの話をしていますが、きっかけはAmazonの書評に星1をいただいたことで、その後のいくつかの記事を書きました。 論理的思考の違いから考えた、日本でアジャイルが機能しない理由と解決 - arclamp ウォーターフォールとアジャイルをマネジメント手法としてフェアに評価
アジャイル開発やスクラムにもマネジメントは必要だ
Photo by Pixabay on Pexels.com 最近、よくお客さま向けに「アジャイル開発やスクラムにも、マネジメントやプロジェクトマネジメントは必要だ」と話すことが多い。事の背景はこんな感じ。 背景 よくあるのが「アジャイルチームは自律して動くからマネージャはいらない」という意見だ。この意見はおおむね正しいと思う。「おおむね」の理由は、マネージャという役割は自律型組織にとって必要なくなってくるだろうけど、マネジメントという仕事はなくならないからだ。 会社全体が自律型であれば、もしかしたらマネジメントすらいらなくなるのかもしれない。ただ、ほとんどの組織がそうではないのが現状だろう。よって、四半期ごとに目標設定と評価が発生するし、人材を採用したり育成する計画は必要だし、予算管理や体制変更も検討しなければならない。 こんな状況から「マネージャとマネジメント」を引っこ抜いてもうまくい
NEW! 2025.03.26 働き方 アジャイル牛尾剛えふしん 納期、不確実。 予算、不確実。 完成度、不確実。 アジャイル開発に対し、経営層*が眉をひそめるのは、こうした予測不可能な状況下での意思決定を迫られるからではないだろうか。 事実、「ウォータフォールはやめて2024年の開発をやろう！」と題された牛尾 剛さんのnoteでの発信に対し、「アジャイルはいいんだが、それだと経営者などの非エンジニアからの理解が得られないので納得できるように言語化してほしいんだよな」と懸念を示した藤川真一（えふしん）さんのポストは、テック界隈で大きな反響を呼んだ。 柔軟性とスピードを謳うアジャイル開発が成熟しつつある一方で、経営視点では「扱いづらさ」が拭えないのはなぜか。経営層と開発現場の溝にあるものとは？ 米マイクロソフトのエンジニアで『世界一流エンジニアの思考法』著者の牛尾さんと、BASEでエンジニア
「儲からない」のは誰の責任？アジャイルにおける「責任問題」とその解決策【ryuzee｜吉羽龍太郎】 レバテックラボ（レバテックLAB）
「儲からない」のは誰の責任？アジャイルにおける「責任問題」とその解決策【ryuzee｜吉羽龍太郎】 2024年6月17日 株式会社アトラクタFounder兼CTO アジャイルコーチ 吉羽 龍太郎 1973年生まれ。野村総合研究所、Amazon Web Servicesなどを経て、2016年1月から現職。アジャイル開発、DevOps、クラウドコンピューティング、組織開発を中心としたコンサルティングやトレーニングを専門とする。著書に『SCRUM BOOT CAMP THE BOOK』（翔泳社）、訳書に『チームトポロジー』（日本能率協会マネジメントセンター）、『プロダクトマネージャーのしごと』『エンジニアリングマネージャーのしごと』『スクラム実践者が知るべき97のこと』『プロダクトマネジメント』『みんなでアジャイル』『レガシーコードからの脱却』『カンバン仕事術』（オライリー・ジャパン）、『ジョイ
先日「アジャイル入門」的な内容でお話しする機会があったのだけど、その中で「アジャイルかどうかは、どうすればわかる？」ということに悩んでいる方が多く、「難しいな〜」と思いながら以下のリストを（一つの提案として）ひねり出した。 毎日、何度も「完成品」を「最終受益者（エンドユーザ）」に届けているか？ 毎日、学んだことを計画に反映し、最善の計画に更新しているか？ 計画変更のコストは、ゼロ（に限りなく近い）か？ 1〜3への答えが「No」なら、日々、少しずつ、この状態に近づいているか？（そのための努力を続けているか？） 「これが正しい指標だ」と言うつもりはまったくなく*1、あくまで僕がこれまで学習や実践を重ねてきた中で、「このへんちゃうかな〜」と考えた提案であり、試案だ。 あくまで、「取り組んでみているけど、手応えがない」とか、「アジャイルできてる気はするけど、本当にそうなのか知りたい」といった悩みに
AI時代のアジャイル開発（XP祭り2024版） / Agile Development in the AI Era in XPJUG
XP祭り2024にて。 https://confengine.com/conferences/xp2024 プロフィールやお問い合わせはこちらからどうぞ！ https://agile-monster.com/profile/ https://agile-monster.com/contact/
本連載では、さまざまなチームやプロジェクトにおいてプロジェクト管理手法や開発モデルを適用してきた経験から、現場からボトムアップによって、組織にあったアジャイル開発管理手法を取り入れていく方法を解説します。今回は「現場からみたアジャイル開発の難しさの原因」について、アジャイルとウォーターフォールの目的の違い、組織に適した管理手法などを整理しながら考察します。 はじめに 筆者は、金融会社でのシステムエンジニアからエンジニア人生が始まり、2000年からはWeb業界にて5回ほど転職をしてきました。そこでは、自社サービスの立ち上げや業務委託でのシステム開発やR&D（Research and Development）業務やその支援、そしてITプロジェクトにおいてトラブルが生じた場合の問題解決支援などを行ってきました。 数名の小さいチームから大手企業の数十名のチームまでさまざまあり、その度にプロジェクト
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
高度に発達したウォーターフォールはアジャイルと見分けがつかない - An Epicurean
10年ちょっとやってきた僕のアジャイル開発の現在地
アジャイルを採用したソフトウェアプロジェクトの失敗率はその他の手法と比べて268％も高いことが判明
論理的思考の違いから考えた、日本でアジャイルが機能しない理由と解決 - arclamp
ウォーターフォールの反省とアジャイルの成功に必要なもの - Qiita
ウォーターフォールとアジャイルをマネジメント手法としてフェアに評価してみる - arclamp
アジャイル専門部隊の一構成員が敢えてウォーターフォールを語るぞ - Qiita
アジャイル開発の推進において、必ずしも"すごい人"は必要ない──現場のエンジニアがDevOps推進で実現する組織改革
『アジャイル開発の失敗率は268%も高い』のコメント欄が面白かったので紹介するよ - Qiita
朝食から学ぶアジャイル開発 - そーだいなるらくがき帳
アジャイル開発の「安定感」を高める、「スプリントゼロ」
最も重要なのは「とっとと失敗しようぜ」、アジャイル開発は人月商売の毒が回ったか
「要件定義を無くそう！」…不毛な議論を巻き起こす「アジャイル開発への誤解」とは
アジャイルで品質とスピードを両立するには構造とプロセスが必要 - arclamp
それでも僕は手法としてのアジャイルを広めていく - arclamp
経営層がアジャイルにモヤるワケとは？ 牛尾剛×えふしん対談から探る
はじめに｜10年ちょっとやってきた僕のアジャイル開発の現在地
「アジャイルかどうかは、どうすればわかる？」 - この国では犬が
なぜアジャイルの導入は難しいのか？ アジャイルとウォーターフォールの目的の違いから考える