アジャイル開発に取り組むチーム向けのコーチングや、技術顧問、認定スクラムマスター研修などの各種トレーニングを提供しています。ぜひお気軽にご相談ください（初回相談無料） みなさんこんにちは。@ryuzeeです。 KPT（Keep, Problem, Try）はシンプルで使いやすいフレームワークとして知られていますが、スクラムのスプリントレトロスペクティブで繰り返し（毎回のように）利用することはお勧めしません。 なお、KPT自体が有効でないと言っているわけではありません。スプリントレトロスペクティブで繰り返し利用することに対する問題提起です。 たとえば何らかの大きな取り組みの最後に行ったり、プロダクトゴールを達成したあとや四半期ごとに長めの時間をとって全体を見たりするときには有効なこともあります。 また、ずっと改善を繰り返してきて非常に練度や能力が高くなっているチームの場合も有効かもしれません

「しかたないスクラム」じゃないアジャイル開発を求めて はじめまして。1月からカミナシでエンジニアリングマネージャ（EM)を担当している @daipresents と申します。 カミナシでは新規事業開発のEMとして、絶賛全力で開発を支援しています。カミナシはとても現場に近い開発環境なので、ご興味のある方はぜひカジュアル面談 をお願いします！ この記事では、僕が関わる「新規事業開発」で実際に行われている「開発プロセス」と、そこに行き着いた経緯や意図をまとめたいと思います。タイトルにあるように、チームは「スクラムじゃないアジャイル開発を求めて」きたように感じています。 チームの立ち上げ期 僕は10ヶ月ほど前から業務委託として参加しており、現在のチームに入る前に、別のチームの支援も行っていました。そこではスクラムが採用されていて、試行錯誤しながら自律したチームを目指していました（今もがんばっていま

「すべてのライフサイクルモデルの祖は、ウォーターフォールモデルである」とは、スティーブ・マコネルの言葉だ1。また、ソフトウェア開発ライフサイクル（SDLC）に関するGitHubの文書では、広く採用された最初のSDLCがウォーターフォールモデルであるとされている2。 そこに、ウォーターフォールを学ぶことに対する価値がある。それは、スクラムを導入し、アジャイルソフトウェア開発を実践する組織にも言えることだろう。いや、そうであるからこそだ。どんなソフトウェア開発プロセスモデルであろうと、ウォーターフォールから派生したり、何らかの影響を受けていると考えられる。したがって、ウォーターフォールへの理解から、自分達がやっていることの本質を見いだせるのではないだろうか。 ウォーターフォールなんて誰でも知っていると思うかもしれないが、そうとも限らない。確かにウォーターフォール未経験のソフトウェア開発者は少な

アジャイル型でアプリ開発を進めたところ、完成に至らなかったことについて、ベンダの不完全履行、プロジェクトマネジメント義務違反等が主張されたが、いずれも否定された事例。 事案の概要 eスポーツ事業の企画・運営等を行う原告（Ｘ）は、ゲーマー向けソーシャルアプリの開発を構想し、開発ベンダである被告（Ｙ）との間で、平成28年8月18日に、ゲームに参加する人をマッチングし、参加者同士がコミュニティを形成するソーシャルメディア機能を有するソフトウェア（本件ソフトウェア）を開発する契約（本件契約）を締結した。対価の額合計は、2450万円。その支払は1000万円、1000万円、450万円の3回にわけて行われることとされ、最後の450万円は、納品物を納入後に支払うこととなっていた。 本件契約の締結前には、Ｘは、検収に合格しなかったら、支払済みの代金を返金する条項を設けることを求めたが、Ｙは「返金を想定してお

2024/09/28「XP祭り2024」登壇資料 https://confengine.com/conferences/xp2024

tl;dr ウォーターフォールという言葉を悪口として使うのは良くないんじゃない？ 空想上の開発手法ウォーターフォールと進化したウォーターフォール アジャイル開発の説明がされるとき、アンチパターンとして「ウォーターフォール」が使われることがあります。これは「ダメな開発現場」と同義で使われており、共通仮想敵としての空想上の開発手法とも言えます。 それは、曰く、硬直化していて変化や手戻りを許さず、一本道でフィードバックサイクルがない、数十年アップデートされていない古臭い手法のことらしい。 もちろんそういう開発をしている現場もまだ数多く存在するでしょう。ただ、ウォーターフォールをカイゼンし進化させている人達もいます。そういう人たちの話を聞くと、例えば以下のような話を聞きます。 一ヶ月で１ウォーターフォールを回す 前の手順に戻る手続きが定められている 初期フェーズから開発者を巻き込む 定期的なレビュ

今回の記事は特に私の意見であり、所属会社の意見ではないことをお断りしておきます。 最近になってまたウォータフォール vs アジャイルの議論を見かけることが多くなってきたので、私が勤務する米国の世界規模のクラウドプロバイダーでは2024年現在どんな開発をしているのかをご紹介したいと思います。私はこれが「正解」といいたいのではなく、何らかのポイントが皆さんの何らかの参考になったらいいなと思って筆をとりました。 ちなみに、2016年時点で私のウォータフォール開発に対する考え方は下記のブログの通りで今も変わっていません。ただ、2024年現在だからといってアジャイルをやるべきと思っているわけでもありません。 もし、今ウォータフォールをやっている人がいたら「そんなこと言ってもどうしたらええねん」となると思うので、自分なりの解決方法も考えてみました。 最初に自分的な結論を書いておくと「2024年の開発と

アジャイル・スクラム開発とウォーターフォール開発──開発手法を巡ってしばしば対立項に置かれるこの二つのスタイルは、考え方はもちろん、段取りやマネジメントの方法もまるで異なります。そんな全く異なるスタイルをとる二つのチームがコラボレーションし、開発プロジェクトを推進していくことは現実的に可能なのでしょうか？ そんなコラボレーションを、決済というミッションクリティカルな領域で実現し、新たなシステムのリリースにこぎ着けた実例がリクルートにはあります。 英語や英会話の学習を支援する『スタディサプリENGLISH（以下、スタサプENGLISH）』では、今や主流となりつつあるサブスクリプションモデルに決済システムが対応できていないという課題がありました。そこで、決済・金融関連のシステムを開発するチームと共同で、新たな決済システムの開発に取り組みました。 『スタサプENGLISH』のチームは、内製の開発

「スクラムマスターがいることでどんな利益があるの？」と言われた時点で専任のスクラムマスターは不要なのかもしれない。でもその先の話がしたい。 はじめに 「スクラムマスターがいることでどんな利益があるの？」 スクラムマスターをやっていると時々この質問を受けることがあります。 スクラムを始めたばかりのチームや組織はもちろん、広報BLOGに「専任のスクラムマスターをおくことにこだわってます。」とCTOが書いているような企業の中にいても こうした問いかけを受ける事があります。 この記事では私が実際にこの問いかけを受けてから、ずーと考えていたことを、なるべく整理してまとめています。それでも雑な文章になっていること、そして個人的な見解でしかない事はご承知おき頂けますと幸いです。 この記事の概要 この記事をまとめるこんな感じです！ 「スクラムマスターがいる事でどんな利益になる？」と言われたら信頼されていな

Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? 前置き この度、ご縁あってこちらの記事の内容でFindyさん主催の 『「脱！なんちゃってスクラム」実践事例から学ぶ Lunch LT』 に登壇しました！ もし、よろしければアーカイブご視聴ください！ 当日、発表で使用したスライドも載せておきます。併せてご確認いただけるとより理解が深まると思います。 はじめに 今の会社に転職してきて２ヶ月が経ち、まだまだ分からないことも多いですが少しずつ環境にも慣れてきたので頭の中を整理するためにも今感じていることをアウトプットしたいなと思い書きました！ 現在、私が参画しているチームはスクラムをベースとし

Scrum Fest Fukuoka 2024にて。 https://confengine.com/conferences/scrum-fest-fukuoka-2024/proposal/19555/5 プロフィールやお問い合わせはこちらからどうぞ！ https://agile-monste…

ソフトウェア開発において、アジャイルという考え方はかなり浸透しています。多く出版物やWebコンテンツ、さまざまなコミュニティやセミナーが存在し、アジャイルの情報には触れやすい状況になってきました。一方で企業においてアジャイルを導入しようとする際に開発チームのどこを変えるべきか、組織固有のルールとどう折り合いを付けるかなどに頭を悩ませる方も多いでしょう。 『SCRUM BOOT CAMP THE BOOK』などの著作で知られ、アジャイルコーチとして企業の組織づくりを支援する永瀬美穂（@miholovesq）さんは、これまで複数の大学で授業におけるアジャイル導入も支援し、その成果を発表する「Agile PBL祭り」を主催してきました。永瀬さんによると、学生は前提知識もないところからソフトウェア開発を学ぶため、社会人エンジニアより自然とアジャイルに取り組める面もあるそうです。 大学はなぜ教育にア

Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? 『Driving Value with Sprint Goals』は、スクラムのスプリントゴールに絞ってまるまる1冊書かれた本です。 不確実性とプランニング 第1章では非常に重要なことが述べられています。「手前の霧」と不確実性を霧というメタファーで表現していますが、ソフトウェア開発においても霧に覆われた状況に置かれることがままあります。この時に本物の霧に対してはやらないのに、何故かソフトウェア開発では、霧が存在しないかのように振る舞ったり、霧を取り除こうと考えたり分析したりできると信じたりしてしまうことがある、と指摘しています。実際に目