スクラムガイドの「確約」 とりとめもなくメモ的に書く。 スクラムフェス大阪2025でジム・コプリエンに説教された 「スクラムガイド」のcommit/commitmentの日本語訳を「確約」にしているが、これはpromise（約束）の意味なので間違いである スクラムのような不確実な世界では、未来を予測できないのだから、何かを「約束」することはできない （現代物理学では因果関係は不確定みたいなことも言っていたが、よくわからんかった……） 言い換えれば、promiseは結果責任（accountability）であり、commitmentは実行責任（responsibility）である また、commitmentには心から取り組むという意味合いもある（当事者意識） マネージャーが『スクラムチームは結果を「約束」している』と思ったらかなり厄介である 結果責任は「反省」を促すだけだが、実行責任は「検査
こんにちは。ヘンリーでエンジニアをしている agatan です。 私は現在医事会計チームに所属し、医療事務の皆様が使う会計システム（レセコン）としての側面について Henry の開発に携わっています。 日々開発をする中で、「デリバリーが3倍速ければいろんな問題が解決するのになー」と考えていることがよくあり、そのための障壁や打ち手を考えるために現状の開発の課題感を整理していました。 実はこれはヘンリーのソフトウェアエンジニアリングの向き合っている難しさ（とそこに挑戦する面白さ）の芯の一つなのではないかと思い、せっかくなので記事にしてみることにしました。 （弊社の行動指針に「ドオープン」（自身の考えを積極的に共有する）というものがあるのですが、同僚から「もっとこうするべきだという考え方を出していくのがリーダーシップですよ」とドオープンにフィードバックされました。この記事は、その通りだなと思って
自分は2020年に初めてマネージャーという役割になってしばらくの間、メンバーに寄り添う意識が強くてあまり職責を果たせていなかったと思う。「今思うと」という話で当時はそう思っていなかったのが黒歴史と言える。過去の自分のことを思い出しながら、この「メンバー思い"風"マネージャー」だった自分に向けたフィードバックを雑に書いてみる。 お前は"メンバーを守ること"が目的になっていて、経営や他部署との対立構造を自ら作ってしまっている。 たとえば、ビジネス上満たしたいリリースターゲットを共有された時、メンバーの負荷を勝手に想像して初手で噛みついてしまっているな。マネージャーとしてきちんと"断る"ことも仕事といった感じで、どこか使命感に近い感覚を持っていないか。お前がやっていることは、結果として経営との接続どころかむしろ最初のブロッカーのような立ち振る舞いにしかなっていない。 人事制度の変更アナウンスに対
Tebiki株式会社でエンジニアをしている二瓶です。私は Tebiki株式会社の Web アプリケーションエンジニアとして入社し、製造業向けデジタル帳票サービス 「tebiki現場分析」 の開発を担当しています。また、チーム内では「チームリーダー」という役割を担っています。弊社のチームリーダーのミッションは要約すると「生産性とプロダクトの品質を最高の状態に保ち、プロダクトの価値を最大化できるような『チームの状態』をつくること」です。 私たちのチームはプロダクト立ち上げ当初からスクラムを導入し、私は2年前からスクラムマスターを務めています。しかし、昨年から開発者も兼任することにしました。この兼任の目的を一言で表すと「私自身がチームの状態をよく知り、生産性とプロダクトの品質を最高の状態に保ち続けることにコミットするため」です（本記事ではスクラムにおける役割についての説明は言及しません。スクラム
2024/01/07から2024/01/10に開催されたRegional Scrum Gathering Tokyo 2025（以下、RSGT2025）のスライドまとめです。 2025.scrumgatheringtokyo.org 本ブログでは、RSGT2025のセッションの発表資料をまとめています。 個人で発見した発表資料のみですので、掲載していないセッションの発表資料がありましたら、コメント欄やSNSなどで教えていただけるとさいわいです。 0日目 18:40からのセッション カンファレンスでリフレッシュ！無理なく楽しむカンファレンス参加術 19:00からのセッション RSGTを一緒に楽しむ仲間を増やすための会 1日目 ketnote The Best Product Engineering Org in the World 13:00からのセッション 失敗を学びに変えるアジャイルなマ
2024.12.11 エンジニア組織のリアルな失敗経験から学ぶ！ 生産性向上＆チーム強化Tips
この記事は JMDC Advent Calendar 2024 10日目の記事です🌲 9日目は大出さんによる JMDCに入社してPMをやっている話 でした。 qiita.com JMDC で Mobile App EngineerとScrum Masterをやっている @mrtry です🍺 ヘルスケアプラットフォーム Pep Up の開発チームでは、開発手法としてスクラムを採用しています。その流れで、株式会社アトラクタさんが行っている認定スクラムマスター研修に参加し、晴れて認定スクラムマスターになりました🥳 本記事では、株式会社アトラクタさんの認定スクラムマスター研修で最高だったことについて紹介したいと思います💪 スクラムガイドについての暗黙知の言語化と解説が最高 研修では、スクラムガイドをベースに基本的な概念やプロセスについて学びました。 スクラムガイドは日頃から読んでいましたが
うまくいったらどうなるの 朝会でチケットを読み合わせていると、誰かがこう聞きます。 「うまくいったらどうなるの?」 誰かがライブラリを書こうとすると、なにかの調査をしていると、新しい機能を増 やそうとすると、「うまくいったらどうなるの?」と聞きます。あなたが今日している ことがうまくいったら、製品やチームはどうなりますか? テスト駆動開発はとても人気のあるプラクティスです。今から書こうとするコードがうまくいったときの様子をまずテストケースで表現し、次にそのテストケースに適合するようにコードを実装します。やるべきことが明解になり、できあがったかどうかを確認するのも分かりやすく、実践する人の多いプログラミングのスタイルです。 テスト駆動開発をやってみると、これはプログラミングに限らずにさまざまな作業でも利用できるのではないかと感じます。どんな作業であれ、それが成功したかどう かを確認する方法を
スクラムガイドの目的 スクラムは複雑なプロダクトを開発、提供、保守する為のフレームワークである。このガイドではスクラムを定義している。定義には役割、イベント、作成物とそれらをまとめるルールが含まれている。フレームワークの各要素は特定の目的を有し、スクラムによって実現される価値と成果にとって不可欠な要素となる。スクラムの考え方や構造を変えたり、要素を省いたり、ルールを無視する事は問題を隠し、スクラムから得られる価値を限定したり、無意味な物にしてしまうのである。 Ken Schwaber と Jeff Sutherlandはスクラムのフレームワークを作る事に重要な役割を担った。 LeSS（大規模スクラム）は複数のチームでプロダクト開発をする際にスクラムを適応し、組織のシステムが変化した結果として形作られ、LeSSはLeSSルールにて定義をされている。LeSSルールは、各チームのレベルではスクラ
こんにちは。シニアスクラムマスターの天野 @ama_ch です。 サイボウズの開発組織において、今後の成長を加速させるためには、組織の基本単位をスクラムチームのような自律的な小さなチームにしてスケールさせることが非常に大切だと考えています。サイボウズは比較的スクラムが普及している組織ではありますが、組織内のすべてのチームがスクラムを採用しているわけではありません。 フレームワークとしてスクラムを採用するかどうかはチームの自由です。しかし、健全なチーム環境を整えることはすべてのチームにとって重要です。チームやチームワークに関する情報は巷に多く存在しますが、我々のようにすでにある程度の規模で活動しているプロダクト開発組織で、チーム環境を整えるために実践的に使える情報がないことが悩みでした。 そこで、これまでのチームに関する学びと実践を踏まえ、サイボウズの開発組織の文脈において、スクラムを実践し
みなさんこんにちは、@ryuzeeです。 今日はデイリースクラムについて、概要や注意点を紹介します。 なお、あくまで一般論であることに注意してください。スクラムの基本は「透明性・検査・適応」です。自分たちで随時やり方を検査して、もっとうまくできるように適応していかなければ効果はあがりません。 1. デイリースクラムの目的スクラムを利用するとき「フレームワークで決められているから」というだけの理解で進めてはいけません。これは全てのイベントに当てはまります。 スクラムのイベントはすべて、検査と適応が行われるように明確に設計されています。 デイリースクラムの最大の目的は、スプリントゴールの進捗を検査し、今後の作業計画を必要に応じて見直す（適応する）ことで、スプリントゴール達成の可能性を最適化することです。 毎日の検査と適応（高速なフィードバックループ）によって問題を早期に発見することでリスクを減
心理的安全性という概念がある。ここ十年ほどチームづくりの最重要ファクターであるともてはやされ、他方では粗雑な理解によって批判されてきた。急に人気の出たアイドルの宿命みたいなものを背負っている。 世間的なイメージがどのようなものか、少し羅列してみよう。 なんでも言える。否定されない。安心して働ける。不安がない。感情を大切にしてもらえる。あなたはあなたのままでいいと肯定される。 こうしたイメージを抱いている人もいるかもしれないが、残念ながらこれらは、心理的安全性の正しい姿からは遠くかけ離れている。ただ安心してほしいのは、こうした誤解をしている人は決して少なくないということだ。 手持ちのグーグルで「心理的安全性 誤解」と検索してみると、何ページにもわたって理解を正す記事が並んでいる。NewsPicksも、プレジデントも、朝日新聞も、Qiitaも、東洋経済も、あらゆるメディアが心理的安全性の誤解に
「ユニコーン企業のひみつ」という本を読んだ。 本旨は、成功したスタートアップ企業、所謂ユニコーンの開発手法や組織は、エンタープライズ系開発を主としている企業とは違うものですよ、という話である。 そしてそれらの企業が具体的にどういうやり方で彼らのプロダクトを開発しているのかを書いている。 ちなみにタイトルにユニコーン企業とあるけれど、別にユニコーン（評価額10億ドル以上の未上場企業）に限った話ではなく小さなスタートアップからGoogleのような既に上場して随分経っている巨大企業まで共通した話だと思う。著者もとくに区別しているわけではなく単にSpotifyで働いた経験から書いたからそのようなタイトルにしたというだけみたいだ（Spotifyもすでに上場しているので厳密にはユニコーンではない）。まあスタートアップは立ち上げのタイミングでは組織も何もないので、タイトルにあるユニコーンというのは、一応
テスターのくせに Janet Gregory さんと Lisa Crispin さんの書籍『Agile Testing』『More Agile Testing』を読まずに今日まできてしまったのですが、この二冊を凝縮（Condensed）した『Agile Testing Condensed』（日本語訳）くらいは目を通しておかないとね！ということで読みはじめました。 leanpub.com この記事は本書に書かれていたある問題を取り出し、それに対してわたしたちのチームが普段やっていることをわたしの目線で紹介したものです。ツイートするには長いのでこちらに書きました。 チームが「サイロ化」する問題 複数のチームがすべて同じプロダクトで作業している大規模な組織でよく見られる問題の1つは、チームが「サイロ化」する傾向があることです。依存関係を解決するために他のチームと話すことを忘れています。（第3章：
アジャイル開発に取り組むチーム向けのコーチングや、技術顧問、認定スクラムマスター研修などの各種トレーニングを提供しています。ぜひお気軽にご相談ください（初回相談無料） みなさんこんにちは。@ryuzeeです。 以前書いたスクラムマスターを雇う時に聞いてみるとよい38個の質問という記事に対して、自分も答えてみましたので、以下で紹介します。 なお、既に38個答えた勇者がいるのでこちらも併せて読んでみるとよいと思います。 「スクラムマスターを雇う時に聞いてみるとよい38個の質問」に答えた@katzchang/回答-スクラムマスターを雇う時に聞いてみるとよい38個の質問それでは、行ってみましょう。 スクラムマスターの役割についてアジャイルマニフェストでは「プロセスやツールよりも個人と対話を」といっている。プロセスを守らせるスクラムマスターは、それとは反対のことをしているのではないか？スクラムマスタ
本記事は、FOLIOアドベントカレンダーの11日目の記事になります。 はじめに 自己紹介 CS 1.6とは？ 本題 メンバーを適したポジションに配置する 報告はできる限りシンプルかつ明確に 報告に感情は不要 怒らない あえて失敗させる 讃え合う ルールはシンプルに最小に 自分たちで考えさせる 全体的に見渡すレベルを目指す 信頼する、言い過ぎない 時間を決めて練習する 最後に はじめに ゲーマー時代に培ったマネージメントやチームワークは仕事にも当てはまることが多いと感じます。 私は様々なプレイヤーを指導したりリーダとして率いることが多かったので、ゲーマー時代に自分がどう行動してたか + それを仕事に照らし合わせて雑多に書いてみたいと思います。 自己紹介 私はCS1.6 (Counter Strike 1.6)の2012年アジアチャンピオンになった者です。 このゲームは私が高２のときくらいから
今年もMercari Advent Calendar 2018 が始まりました。初日は @stanaka がお送りします。 メルカリでは創業以来開発してきたPHPのアプリケーションから(主に)Goで実装されたマイクロサービスアーキテクチャへの移行を進めています。これまでにMercari Tech Conferenceやその他のカンファレンスでMicroservice化の意義、移行の方法、基盤となるMicroservice Platformの概要などについて様々な発表をしてきました。 現在、来年からの本格的なマイクロサービスアーキテクチャでの開発に向けて、これまでのサービスの施策ドリブンのチーム編成から、マイクロサービスを軸としたチーム編成に移行しようとしています。 しかし、マイクロサービスアーキテクチャを成功させるためには、各種プラットフォームの機能を揃え、それらを利用したマイクロサービス
俺は開発中プロジェクトの進行具合を見ればその後の成功失敗をわりと当てることができる。（偉そうに出たが、開発者の何割かは息を吸うようにこれをやる） 数日一緒に仕事をすれば確度はもっと高くなる。 美味しんぼにおける、「天ぷらを揚げる前に、上手い天ぷらをあげる職人が分かるか？」という奴だ。これのチーム版。 なぜそれが解る人と解らない人が居るかを説明する。 犬は嗅覚の世界で生きていて、鳥は視覚の世界で生きている。お互いの世界は理解することができない。 ゲームの開発現場には、犬、鳥、トカゲ、深海魚、ナマケモノと各種種族が入り混じっているので、ある属性の人には別の属性の人の重要な事象がまるで見えていない事がある。犬の世界は鳥には分からないのだから。 例えば日本人は、昔、青色と緑色は同じと扱っていた。どうでもよかったのだろう。 砂漠の民はラクダを表す言葉が年齢性別によって細かく区別されているという。重要
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
