アジャイル開発チーム向けのコーチングや、技術顧問、Scrum Alliance認定スクラムマスター研修などのトレーニングを提供しています。お気軽にご相談ください（初回相談無料） みなさんこんにちは。@ryuzeeです。 「フィーチャーファクトリー」は、プロダクトマネジメントの専門家であるジョン・カトラー（John Cutler）1が2014年に使い出した単語です。日本語にすると機能工場となり、単に与えられた要求をひたすら作り続けたり、アウトカムやインパクトよりも、作った機能の量や出荷スピードだけに注目したりするチームや組織を指します。 複雑で変化が激しい環境においては、事前に考えたことがすべてそのとおりになることはありません。 端的に言うと、多くのものは外れます。外れることを前提にすると、成功するために数を打つこと、そして素早くそれを実行することはとても重要です。でも、それ「だけ」に注目す
毎年必ずどこかでウォーターフォールとアジャイルを対立させ「ウォーターフォールwwwww」と味付けしたツイートに待ってましたと総ツッコミが入るムーブがあるように思います。 今シーズンは下記のツイートがK点超えの大ジャンプを記録しました。 今どきウオーターフォール型開発とアジャイル開発の違いをどうこう言う必要はないかと思うが、若手の技術者は間違ってもウオーターフォール型開発のほうに行ってはダメだぞ。失敗は絶対に許されないと連呼する世界と、とっとと失敗しようぜと言う世界では、どちらが成長できるかは明らか。 https://x.com/toukatsujin/status/1863023816290762841 Xでは多方面から「いやいやいやいや、どんな世界線ですかそれ？！」と突っ込みが入った。失敗の許容度がゼロか100かってなんぞ？っていう感じ。そらそうよ。 これを受けて木村氏は「批判の中で呆れ
アジャイルに興味を持った1人あるいは数人から始めることは、アジャイルの導入においてよくあるストーリーです。とはいえ昨今では、例えばスクラムを導入する開発チームも増えているでしょうし、ほかのメンバーが主導した取り組みとしてアジャイルを受け入れる方も多いでしょう。そんな経緯でスクラムに触れ、既存の開発プロセスとの違いに戸惑い、むしろ積極的にアジャイルを学ぶことで克服した過程を、岸田篤樹（パウリ）さんに寄稿いただきました。 Agile journeyをご覧のみなさま初めまして。株式会社ビットキーでEM（エンジニアリングマネージャー）・スクラムマスター・技術広報をしているパウリ（@pauli_agile）です。私は2015年に新卒でプログラマーとしてキャリアをスタートしました。 その頃の世の中ではすでに、アジャイル開発がさまざまな開発組織に浸透しつつある状況にあったかと思います。ただ、実際に配属さ
おことわり 最初に断っておきますが、私はスクラム開発反対の立場をとっているわけではないです。また、スクラムマスターでもないのでスクラム開発について誤った見解を持っている可能性も大いにあります。 また、これから記載するスクラム開発のペインはあくまでも筆者の独断と偏見に基づいて記載されております。そのため、ペインの原因がスクラム開発ではなく、単にその所属組織の構成員の性質や文化的な要因であることも考えられます。おそらく、スクラム開発でなくても起こり得る問題も多く挙げていると思います。そういった側面も踏まえてご意見あれば忌憚なく反論異論いただければ幸いです。 なぜこの記事を書いたか チーム内で密なコミュニケーションをとりながら、個人ではなくあくまでもチームとしての成果を重視するスクラム開発の開発フローは、割と個人の活躍と成長機会を奪ってしまい、結果として組織としても開発成果が縮小均衡になってしま
前提 この記事は内製開発をしているSaaSの中の人であるエンジニアが、SaaSの内製ソフトウェア開発をする上での話として書いています。 前ふり 「スクラムで生産性は上がらないしリリーススケジュールが狂いまくりなんですよ」 「何が原因なんですか？どうすればいいんですか？」 という相談を受けました。 NDAを書いてから、どれどれとチームの状況を見てみました。 該当チームのスプリントゴール 該当チームのスプリントゴールはこんな感じでした。 QAフェーズのプロジェクトAを、QA作業を完了してリリースできる状態まで進める 実装フェーズのプロジェクトBを、フィーチャーの実装率を50%まで進める 設計フェーズのプロジェクトCを、要確認な点を除いて実装レディーな状態まで進める スプリントゴールが3つありますね。とても面白いですね。 思わずボンドルド卿みたいな反応をしたくなりますがここは先に進みましょう。
こうしてふりかえりは終わってしまった / A Demise of a retrospective ふりかえりカンファレンスで一番面白かった発表資料です。 資料をざっくり要約すると ふりかえりは最初は順調に機能するがある段階で停滞し、次第に「効果が出ていないもの」と判断されて廃止されてしまう、という話です。 理由として最初は低コスト高リターンの課題を倒していけるが、それらをすべて解決すると残るのは「リターンはあるが、コストが高すぎて解決できない課題」と「コストは低いがリターンもほぼない課題」だけになります。 開発チームは前者を「コストが高すぎて解決できない」と忌避し、後者だけに打ち込んだ結果、リターンが出ずに振り返り事態を無価値を判断してしまうからです。 ふりかえりを廃止することでチームの成長は停止してしまうでしょう。 これを防ぐために「コストが高すぎて解決できない」課題を解決する方向に頑張
私はこれまで６年間日本で働いてきましたが、昨年11月にプロフェッショナル・スクラム・トレーナーになってから、日本のスクラムやアジャイル開発の現状と今後の展望についてよく質問を受けるようになりました。そうした質問に触発されて私自身もこのテーマについて掘り下げて調べたり考えたりするようになりましたので、この記事にまとめました。（English version here） スクラムとアジャイル開発の現状 1986年、当時 一橋大学教授であった野中郁次郎氏と同大学の竹内弘高氏は「The New New Product Development Game」(Harvard Business Review) という非常に有名な研究論文を発表しました(1)。この論文は日本企業による新製品開発プロジェクトの成功事例を紹介すると共に、これらのプロジェクトに共通する特徴として「自己組織化されたチーム」「開発フェ
結論から言うと受発注の関係性でアジャイル開発やるのは完全に間違えてる 受注側が優秀だと発注側の意思決定の遅さにイライラするし 受注側が未熟だと発注側のイメージが具現化されない 第三者的に両方の場合に遭遇したんだが記録しておきたい 受注側が優秀な場合スプリントのスピードが速すぎて発注側の意思決定が間に合わない 評価用のボタンを作成するときにGood/BadにするかGood/Normal/Badにするかを決めるだけで2週間かかる 本来なら意思決定者がミーティングに出て欲しいが日本企業は権限委譲しない会社ばかりなので 最終決定は上役の偉い人になるが、そういう人はなかなか捕まらないので意思決定が遅くなる 「意思決定を早くしよう」ということでミーティング時間を10分に制限するとか意味不明なことをしてる 責任を下位の役職まで委譲しないとアジャイルは成り立たない まぁなのでこういう組織にはアジャイルは向
no plan株式会社では、自社プロジェクトは全てスクラム開発を行っています。 そこで大事にしていることや、他のチームを見た時に取り入れたいと思ったことも書こうと思い筆を取りました。 今回はスクラム開発用語がわからない人でも読めるようにあえて用語を使わないようにしてみたいと思います。 スクラム開発とは スクラムは「問題に対する解決策を列挙」「高優先度の策を一定期間でチームで実行」「結果の検査に基づく調整」「その繰り返し」を実現できる環境を生み出すシンプルなアプローチである。スクラムのカギとなる基本原則は、プロジェクト開発の途中で、顧客は、要求や必要事項を変えられるという認識である。予想できない変更について、計画に基づく方法で対処することは、容易ではない。したがって、スクラムは経験に基づくアプローチを採用する。 (引用: Wikipediaより) スクラム開発についてもっとざっくり スクラム
Retty、アカツキゲームス、atama plus 3社のVPoE、エンジニアリングマネージャー、スクラムマスターが大規模スクラム「LeSS」導入の最前線を語り合った「【Retty x アカツキゲームス x atama plus】LeSS導入の最前線、リアルとこれから」。「LeSS」を導入した背景や苦労、未来について話しました。全3回。1回目は、「LeSS」を導入した経緯について。 LeSS推進者3名によるパネルディスカッション常松祐一氏（以下、常松）：パネルディスカッションに入っていきたいと思います。では、石毛さんと深澤さんにまず自己紹介をお願いしたいと思います。先に石毛さん、お願いします。 石毛琴恵氏（以下、石毛）：株式会社アカツキゲームスでエンジニアリングマネージャーをしている石毛です。よろしくお願いします。 常松：では、深澤さんもお願いします。 深澤良介氏（以下、深澤）：atama
アジャイルソフトウェア開発を企業が導入する際に、スクラムと並んで名前が挙がる開発手法にエクストリームプログラミング（XP）があります。ガイドブックや研修が存在するスクラムに対して、ペアプログラミング（ペアプロ）やテスト駆動開発といったプラクティスをエクストリーム（極限的）に実践しようというXPの導入には、どこから始めればよいのかと戸惑う開発組織もあるようです。 2022年6月に開催されたユーザベース主催の勉強会「エクストリームプログラミングで見える開発風景」では、XPの提唱者であるケント・ベックの著作などの翻訳者として知られる角征典さんと、XPを導入しているユーザベースのソフトウェアエンジニアである野口光太郎さんが講演したのち、XPの始め方やエンジニア以外との体制づくりなどについて、視聴者の質問をもとにパネルトークが行われました。 本記事では、組織にXPをどのように導入するか、またスクラム
はじめにこの記事の対象読者は「機能しているスクラム開発チームのメンバーないし関係者」をイメージしています。 また会社のフェーズや資本状況、フルタイムでないメンバーを雇いたいなどのコンテキストもあるので業務委託が一概に悪とは言いません。 単純に相性が悪いってだけです。 また相性が悪くてもチームが即崩壊するとかそう言う話でもないです。 僕は業務委託の人が嫌いなわけではありません。ただスクラム開発と相性悪いな（主に単価的な意味で）と思っています。 あとここで言うSES的に送り込まれる業務委託の人の単価は月100万~150万円くらいです。 実は「業務委託契約」とは限らないWeb界隈の一部の慣行として「協力会社(個人を指す)」とほぼ同義語として「業務委託」は使われています。「業務委託」と呼ばれる個人に対してリーダーが指揮命令権を持ちます。契約形態は関係ありません(パねぇな)。 実態の契約形態が業務委
仕様書の通りのITシステムをカッチリと時間をかけて作っても、顧客に「依頼したものと違う」と言われてしまう。ソフトウェアエンジニアの「いいものを作りたい」という気持ちがビジネスに生かされていない。そう感じていた平鍋健児さんは、ピラミッドのように大きな建築物を数十年かけて作るやり方ではなく、生鮮食品のように鮮度を大切にしたアジャイルの開発手法に出会い、この20年を実践と普及に取り組んできました。 近年はビジネスの立場からも語られる「アジャイル」ですが、このインタビューではアジャイルを導入する企業がステージや事業規模に応じてどのような課題に直面するのか？ とくに、小さなスタートアップ企業がアジャイルネイティブから大きくなったメガベンチャーだけでなく、旧来の開発手法を続けてきた既存の企業が、自分たちにフィットしたアジャイルを見つけるときに参照できるいくつかの事例とあわせて紹介します。 アジャイルが
こんにちは、コミューン株式会社でスクラムマスターを担っているヤマシタ（@yama_sitter）です。 前回「スプリントの属人性を減らしたらベロシティが安定した話」という記事を書きました。 この記事で紹介した取り組みに至るまでの過程に興味がある、という声を頂いたので、その過程、及び過程を振り返って得られた気付きを紹介させて頂きます。 ちなみに少し長いです。 ご了承下さい。 まずは結論から 取り組みの出会いから定着に至るまで 「WIP制限の導入」に至るまで 出会い 導入 定着 「タスクサイズの制限の導入」に至るまで 出会い 導入 定着 「死亡前死因分析（プレモーテム）の導入」に至るまで 出会い 提案 定着 改めて振り返ってみて まとめ 取り組みに出会えたのも上手くハマったのも正直偶然 「気付いてもらう」ことが大事。最後に決めるのはメンバー 「とりあえずやってみよう」くらいの気持ちで改善に取り
このブログではあまりこういう話は書いてこなかったけど, 以前少しだけ触れたように, 僕はここ最近エンジニアリングマネージャをやっていて, こういう話題を考える機会はけっこう多い. 具体的には, エンジニアリングマネージャとして複数チームのテクノロジ/プロセス/プロダクト/ピープルのマネジメントを日々やっていて, そのうちのプロセスマネジメントとして, 各チームのスクラムマスタ的な人に助言したり, 開発プロセスの改善のためにチームが起こそうとしている変化を受け入れるようラインマネージャを説得したり, といったことにけっこう時間を割いている. スクラムに関して以下のような話を見かけて, これはまさに日々悩まされていることだった. 一言で言うと「ベロシティの安定化でみんな躓く」という話. これは僕の経験上も納得できる. この記事に寄せられたコメントを見ると, 「で, じゃあどうやってベロシティを
タイトルの議論はよく見られるもので、スクラムコーチの間ですら（一見すると）意見が分かれることがあるようです。自分は「安定させる」派だったのですが、CSPO研修を受講したチームのPOが「上げる」派のコーチングを受けてきて、改めてチームとしてどういうスタンスを取るか考える機会を得ました。結論から言ってしまうと、そもそもこれは二項対立ではなく、「上げる」派の人も「（安定させた上で）上げる」と言っているだけで、単に目指している高さが違うだけだろうと解釈しました。その上で、チームの現状に合わせて適切な目標設定をすれば良いと考えました。以下でもう少し掘り下げてみます。 大前提 まずソフトウェア開発の大前提として、開発チームには常にベロシティを下げる方向に様々な力がかかっています。これは「変化」と呼ばれて恐れられ、プロダクトや開発チームに次々と襲い掛かります。例えば以下のようなものです。 市場が求めるも
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
