ソフトウェア開発で目撃したものを説明するために、私は造語を作る習慣があります。 便利な用語が少ないので、ソフトウェア開発の分野の書き手はこのようなことをよくやります。 造語を作るときの問題は、意味の希薄化により本来の意味が失われ、別の意味が追加されてしまうことです。 意味の希薄化が発生するのは、個人やグループが作った用語があり、適切に定義されていたにもかかわらず、歪められた定義がコミュニティに広まったときです。 これにより、用語の定義が完全に失われる危険性があります。 また、それに伴い、用語の利便性も失われてしまうでしょう。 私が本記事を書こうと思ったのは、「アジャイル」と「Web 2.0」に意味の希薄化が発生しているからです。 いずれも数年前に作られた用語であり、しっかりとした定義があります（アジャイルにはアジャイルマニフェストがあり、署名者たちが執筆した書籍や記事も多数あります。Web
前からずっと言いたかったことがある。同じ過ちを犯すゲーム開発者に。あるいは、「ゲームを完成させた体験が無い人」に。 あなたのゲーム開発に対する予測は、ほとんどの場合正しくない。それも、20%や40%などの振れ幅ではない。200%とか400%のスケールで大きく間違っている。 私はその感覚を確かめるべく一つのアンケートを実施した。結果は火を見るより明らかな傾向を示した。 個人ゲーム開発者に質問です。「１年で完成させる」と思って作り始めたプロジェクト、実際に完成したのは？ — じーくどらむす/岩本翔 (@geekdrums) June 4, 2024 Twitterアンケートの統計的な正しさは保証しない。そもそも母集団が偏っているし、最後の選択肢が「未完成」を含めていることに対して「４年以内に諦めて未完成」の人も含めているかもしれない。が、エターナったという意味では４年以上完成しないもの、に含め
バスケットボール男子・Bリーグの年間王者を決める、日本生命チャンピオンシップ（CS）がいよいよ10日開幕します。 今季は最終節（第36節）まで地区順位・CS進出クラブ決定がもつれ込む混戦のシーズンでしたが、中地区ではBリーグ発足2シーズン目（2017-18）以降、下位に低迷し続けてきた「三遠ネオフェニックス」が早くから首位を独走し、第31節・4月10日に初の地区優勝を果たしました。 この快挙の裏には、2011年にブラッド・ピット主演で映画化された『マネーボール』*さながらのデータ分析を活用したクラブの大改革がありました。 昨シーズンに三遠に加入し、ビデオアナリストとしてデータ活用を推進してきた木村和希氏が、早くも大きな成果をあげたプロジェクトの取組みとCSへの挑戦について、お届けします。 * MLBオークランド・アスレチックスのGMビリー・ビーンが統計の専門家を雇い、当時MLBでも主流では
TOPインタビュー実は相性が悪い「開発生産性」と「アジャイル」。うまくいかない開発を好転させるためにPMがやるべきこととは【ryuzee|吉羽龍太郎】 実は相性が悪い「開発生産性」と「アジャイル」。うまくいかない開発を好転させるためにPMがやるべきこととは【ryuzee|吉羽龍太郎】 2024年3月26日 株式会社アトラクタ Founder兼CTO／アジャイルコーチ 吉羽 龍太郎 1973年生まれ。野村総合研究所、Amazon Web Servicesなどを経て、2016年1月から現職。アジャイル開発、DevOps、クラウドコンピューティング、組織開発を中心としたコンサルティングやトレーニングを専門とする。著書に『SCRUM BOOT CAMP THE BOOK』（翔泳社）、訳書に『チームトポロジー』（日本能率協会マネジメントセンター）、『プロダクトマネージャーのしごと』『エンジニアリング
ウクライナ軍に入隊したアジャイルコーチが、さまざまなメソッドを駆使して中隊長としてのリーダーシップを実現した話（前編） アジャイル開発の代表的な方法論であるスクラムをテーマに、都内で1月に開催されたイベント「Regional Scrum Gathering Tokyo 2024」で、経験豊富なアジャイル開発のエキスパートとしてウクライナを拠点にアジャイルコンサルタントをしていたドミトロ・ヤーマク（Dmytro Yarmak）氏が、ロシア軍の侵攻後にウクライナ軍に入隊し、中隊長としてリーダーシップを発揮するためにさまざまなメソッドを駆使して軍隊の組織を変革していった経験を語ったセッション「A True Story of Agile Coaching in Ukrainian Armed Forces」が行われました。 軍隊という、企業とは異なる構造や目的を備えた組織で、しかも多くの民間人が入
スライド概要 なぜ、安定したチームが必要なのか？ 安定したチームを維持しづらい時代に、どうすればよいのか？ ダイナミックリチーミングを意識して組織を成長させ、弾力的で柔軟な構造を作ったり、ダイナミックリーチングを可能にするために既存の組織を調整して、安定したチームが維持しづらい時代を乗り越えるためのヒントになればと思います。
プロダクトが成長し、ビジネスが成長すると、どれだけ今のチームが素晴らしくても、チームを大きくする力がどうしても働き始めます。 ほうっておいたら、いつのまにか良いチームがたくさんできていた！ 実際は、そんなに都合の良いことは起こりません。残念。。。 チームも植物のように手をかけなければ、すぐに枯れてしまったり、栄養が行き届かないと成長できずに、おいしい実をつけられなかったり、また大きくなったからといって安心して放っておくと、いつのまにか実をつけなくなったり。 チームにとって快適に育つ環境を整え続けることで、大きな実がなる可能性が上がります。 「Dynamic Reteaming: The Art and Wisdom of Changing Teams」という本のご紹介。 著者のHeidiさんがいろいろな組織で経験したり、興味深い組織にインタビューをする中で、適応力の高い組織が行っていたリチ
Have you been in any of these situations? Managers make decisions that’s out of their leagues and everyone else in the team ends up paying for it. Knowledgeable people passively observe without bothering to contribute. Sometimes they are denied access to the room. Developers act like code monkeys, throwing the code over a metaphorical wall for the QA to test and “DevOps” to run. In “you build it,
こんにちは。シニアスクラムマスターの天野 @ama_ch です。 サイボウズの開発組織において、今後の成長を加速させるためには、組織の基本単位をスクラムチームのような自律的な小さなチームにしてスケールさせることが非常に大切だと考えています。サイボウズは比較的スクラムが普及している組織ではありますが、組織内のすべてのチームがスクラムを採用しているわけではありません。 フレームワークとしてスクラムを採用するかどうかはチームの自由です。しかし、健全なチーム環境を整えることはすべてのチームにとって重要です。チームやチームワークに関する情報は巷に多く存在しますが、我々のようにすでにある程度の規模で活動しているプロダクト開発組織で、チーム環境を整えるために実践的に使える情報がないことが悩みでした。 そこで、これまでのチームに関する学びと実践を踏まえ、サイボウズの開発組織の文脈において、スクラムを実践し
こんにちは、サイボウズの永田です。 私は、サイボウズの開発本部、アジャイル・クオリティで、アジャイルの品質を探求する活動をしています。 この記事では、2023年3月9日、JaSST Tokyo 2023のテクノロジーセッションで発表させていただいた内容を、より解説を入れながら紹介します。 結合テストの自動化にQAはどうかかわっていったか 今回取り上げる事例では、kintoneのフロントエンド刷新プロジェクト（フロリア）で結合テストの自動化を決定した際に、QAメンバーがどのように関与し、困難に直面しながらも、信頼性の高いテストコードを作成するに至るまでの過程をご紹介します。 フロリアについては次のブログをご覧ください。 blog.cybozu.io テストのポリシー ~このミッションにおけるQAのチャレンジ~ フロリア内で新しく3つのチームが立ち上がった際、各チームのテスト戦略の中心を、自動
Listen now If you’ve been following along with the podcast, you’ve heard the mention of two-person teams and how 37signals makes the most of its software features and productivity with just two people working together—one programmer and one designer. In this episode of the REWORK podcast, 37signals co-founders Jason Fried and David Heinemeier Hansson sit down with Kimberly Rhodes to dive deeper in
自分はDMMプラットフォーム内のマイクロサービスアーキテクトグループという組織の責任者をしているが、 最初に比べると組織がそれっぽく拡大したこともあり、 ここ最近テックリードを立てる機会が増えてきた。 一度自分がテックリードに求める役割と適切なチームサイズについてアウトプットしてみようと思う。 DMMプラットフォームのマイクロサービスアーキテクトグループとは? pospomeがテックリードに求める役割 技術領域をリードする プロジェクトマネージメント 他チームとのコミュニケーション チームメンバーの評価 なんだかんだで総合力 pospomeがテックリードに求めない役割 ピープルマネージメント よく分からない政治的なコミュニケーション 適切なチームサイズについて 新規チーム設立を考慮する場合 おまけ：テックリードに求める役割と適切なチームサイズ以外のあれこれ No.2 の重要性 立場が人を作
イテレーション・スプリントを使ってはじめて開発するチームがよく直面するのが、スプリントで仕事が終わらない問題です。はじめはそういう時期があってもいいですが、慢性的にこれが続くとなると、注意が必要です。 仕事を終わらせるために 仕事というものは、はじめるときに終わりを定義するものです。しかし、ソフトウェア開発の場合、予想外のことが結構起こります。 予想以上に仕様が複雑になった 予想以上に調査に時間がかかった 予想以上にはまってしまった これはどうしようもない要素なので、アジャイル開発において仕事が終わらない場合は、 予想以上に時間がかかりそうだから、スコープを減らして期限内で終わらせられるようにする 予想以上に時間がかかりそうだから、リリースから外して次のリリースに回す 予想以上に時間がかかりそうだから、チームメンバーに手伝ってもらってかたずける というように、終わらないと気がついた時点で調
スペシャルセッション 「その ＼よーいドン！／ デプロイが、あなたのサービスの信頼性を損ねている」 ◆登壇者 講師：Tori Hara (@toricls) 氏 (CTO, Kaminashi) 進行：杉本 晋吾（アマゾン ウェブ サービス ジャパン合同会社 ソリューションアーキテクト） パネリスト：福井 厚（アマゾン ウェブ サービス ジャパン合同会社 ソリューションアーキテクト）/ 下川 賢介 (アマゾン ウェブ サービス ジャパン合同会社 ソリューションアーキテクト）/ 野村 侑志 (アマゾン ウェブ サービス ジャパン合同会社 ソリューションアーキテクト）/ 林 政利 (アマゾン ウェブ サービス ジャパン合同会社 ソリューションアーキテクト）/ タメルラン トルガエフ (アマゾン ウェブ サービス ジャパン合同会社 ソリューションアーキテクト） ◆ セッション概要： 本セッシ
アジャイル開発に取り組むチーム向けのコーチングや、技術顧問、認定スクラムマスター研修などの各種トレーニングを提供しています。ぜひお気軽にご相談ください（初回相談無料） みなさんこんにちは。@ryuzeeです。 今日はTwitter経由で頂いた質問に回答したいと思います。 質問は以下になります。 スプリントで『自分が最初に取り組むプロダクトバックログアイテム（PBI）を終わらせば自分の仕事は終わり』という意識のメンバーが多いです。そのため、PBI每に担当を決めて複数のPBIを並列で進めているのですが、インクリメントが0になる可能性があるのでできればやめたいと思っています。スプリントプランニングで決まったPBIすべてをチームで協力して終わらせるという意識に変えるためにはどうしたらよいでしょうか？ 例えば、AさんとBさんとCさんが最初にPBI-1をやる場合、スプリントでPBI-1を終わらせればよ
Is the Spotify Model an Early Instance of Scrum@Scale®? Demystifying the relationship between Scrum@Scale and the Spotify Model with Dr. Jeff Sutherland and Avi Schneier | March 15, 2022 Organizations today are adopting new methodologies that span the gamut in hopes of finding the best competitive advantage for their business. Some look to mainstream Agile methodologies while others look to organi
ベロシティは、スクラムの要素だったことはありません。 ソフトウェア開発に「ベロシティ」を適用することは、エクストリーム・プログラミング（XP）の先駆者たちによって考案されましたが、今ではそれが良くないアイデアだと考える人たちもいます。 残念ながら、スクラムの世界では、いまだに 「4倍のベロシティ向上 」や 「超生産性」などの言葉を押し付けている人がいます。私はこれを恥ずかしく思っています。これは、私が ケン・シュエイバーから学んだ スクラムではありません。ケン・シュエイバーは代わりに、 厳格な完成の定義 と、守れない約束を避けるということを強調していました。 もし私たちが、 実験から学び、適応する能力 を促進するのであれば、特に私たちの近視眼性（木を見て森を見ない傾向）と短絡的な認知バイアスを考えると、従来の生産性重視の姿勢は（それがどのような理由であれ）有害となりえます。あなたが昔に書い
4プロダクトを成功させようと悪戦苦闘しているものの、プロダクトの行く末についてプロダクトオーナーやプロダクトマネージャといった一部の人の意思決定に依存しすぎてしまっていると悩んでいるチームが、彼らと共にプロダクトマネジメントを実行できるようにするセッションです。「プロダクトオーナーがボトルネック」という…
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
