海外企業と協業し、海外と日本のチームが企業間混合チームへ進化していく変遷
ガートナージャパン(株)によると、オフショアへの期待値は年々上昇(※1)しており、また今後はコスト削減ではなく人材確保を目的としたオフショアが進んでいく(※2)そうです。
※1 日本におけるテクノロジのハイプ・サイクル(2015、2016、2017)より
※2 2017年以降のIT人材に関する展望より
2016年頃、私が所属するチームでは製品に求められている価値の進化に追いつくため、開発力の増強が必要と判断しました。
オフショア経験などなかった会社なのに、人財の積極的採用ではなくインドの企業と協業し開発チームを設立する道を選択しました。
インド企業のScrumチームと協力した話と日印混合Scrumチームへ進化した話を紹介し、オフショアや国際チームの設立を成功させるための有効な方法を共有できたらいいなと考えています。
Outline/Structure of the 1st Step Case Study
- インドの企業を選択した理由
- 苦労せず海外とやりとりをする方法
- 日本とインドそれぞれのScrumチームが1つのプロダクトを育てる際に立ちはだかった大きな壁
- 壁を破壊することに繋がった一手
- 現在、日印混合チームがどのようにScrumを実践しているのか
Learning Outcome
- オフショアの外部チームと協力していく際に注意したほうがいいこととしてご活用ください
- 国内外混合チームによるScrumの実践を成功させる手段の一つとしてご活用ください
Target Audience
海外と混合チームを作りたい、または海外へオフショアしたいと考えている方
schedule Submitted 4 years ago
People who liked this proposal, also liked:
-
keyboard_arrow_down
Yoh Nakamura - ファシリテーションの難しさと楽しさ
20 Mins
Thought & Practice
Beginner
ScrumでもXPでもアジャイルなやり方でプロダクト開発をしていく上で”会話”は大事になってきます。
そのような会話は1対1に限らず、チーム全員、チームとステークホルダーのような複数人である会話することもあります。
そのような場には様々なコンテキスト、利害関係を持った人々が集まることもあり、何もしないで良い結果を得るのが難しい場合もあります。その場の質を高めるスキルの1つがこのセッションのテーマである”ファシリテーション”です。
ファシリテーションとは、会議、ミーティング等の場で、発言や参加を促したり、話の流れを整理したり、参加者の認識の一致を確認したりする行為で介入し、合意形成や相互理解をサポートすることにより、組織や参加者の活性化、協働を促進させるリーダーの持つ能力の1つ。日常での組織コミュニケーション全般において、ファシリテーション技術は活用される。 (Wikipediaより抜粋)
このセッションでは、スクラムマスターにとって必要なスキルの1つでもあるファシリテーションの難しさや楽しさを、現場コーチとして20以上の現場を支援してきた知見を交えてお話します。
-
keyboard_arrow_down
Narichika Kajihara - エンジニア採用もカンバン使ってみたら、「透明性」によって採用が活動が変わったこと / Agile Recruiting
20 Mins
Advanced Case Study
Advanced
「スクラム」のフレームワークは、もともとソフトウェア開発に用いられてきました。しかし「スクラム」の経験主義の原則は、短いイテレーションの中で、検査と適用を繰り返すことでプロセスのカイゼンを加速させる事ができます。また透明性の原則によって、ステークホルダーへの説明責任、今何が問題になっているのかを見える化させることができます。
その「アジャイル」フレームワークを「エンジニア採用活動」に適用してみた内容について、発表させていただきたいと考えています。
トラディッショナルな採用活動は秘密主義に根ざしており、独自な文化が根強く残っています。その中で透明性をもったプロジェクト運営をすることで、「採用活動の変化」「ステークホルダーの意識の変化」、検査と適用を繰り返すことでプロセスのカイゼン速度が向上した。開発部門以外にも適用した事例について、お話させていただきたいと思います。
-
keyboard_arrow_down
Shigeki Morizane - 全部SCRUM!~SIerで大切だったもの、サービサーで大切だったもの~
20 Mins
1st Step Case Study
Beginner
2018年、15年勤めた富士通、NRIというSIerを辞め、Leveragesというベンチャーのサービサーに移籍しました。
これまで、SIerやそのお客様先でSCRUMの導入を支援してきましたが、実際のWeb系のサービサーでのSCRUMはまったく毛色の違ったものでした。
でも、どちらもSCRUM!全部SCRUM!
規模や価値観やビジネスモデルによるSCRUMの取り入れ方の差を身体で感じ取った話しをします。
-
keyboard_arrow_down
kyon _mm - 超Scrum入門〜未完成フラクタルと15minSprint〜
45 Mins
Thought & Practice
Advanced
https://www.youtube.com/watch?v=7xhxIYYMmTc
チームがうまくいっていることはスクラムチームの大きな目標です。
いくつかのスクラムチームに関わってきた立場から、良いチームになるための1つの大きなアプローチを見つけました。私が関わってきたチームでは、最初から1DaySprintをやりつづけています。また、1 Hourのタイムボックスを持つチームもあります。またそれらはたった数日で成されます。
良いチーム、美しいチームとはスクラムという視点だけにはとどまりません。あるチームでは、15minSprint、1hourSprint、1DaySprint、1WeekSprint、1MonthSprintを構成したフラクタルなスクラムを実践しています。
数万年に渡る生物の美しさ、クリストファー・アレグザンダーが発見してきた美しさ、といった視点からスクラムやチーム、そして理想像を整理します。
-
keyboard_arrow_down
Ryosuke Nakamura - 自律的で協調的なチームの作り方 ~複数拠点、多言語、職能型組織で始めるScrum~
20 Mins
1st Step Case Study
Beginner
職能型組織からメンバーが集められてプロダクトチームを作るような場合、それぞれの役割の間にあるグレーゾーンのタスクを誰が拾うのか、お互いのロールが何やっているのか見えづらい、などの問題が発生しがちかと思います。
私たちのチームでも大きく以下の役割ごとの組織から集められたチームでした。- プランナー(プロダクトデザイン、企画、グロースを担う役割)
- デザイナー
- フロントエンドエンジニア
- サーバーサイドエンジニア
- QA(Quality Assurance)
また、プランナーとデザイナーは東京、エンジニアとQAは福岡と物理的にも離れた中作られているチームです。
もちろんそれぞれがいいプロダクトを作りたいという思いを持ってやっていたのですが、
プランナー側には以下のような不満があり、- エンジニア側の見積もりが適切かわからない(必要以上にバッファー積んでないだろうか?)
- エンジニア側が十分に効率よく働けているかわからない(人を余らせているのではないだろうか?)
- エンジニアの売り上げに対するコミットメントが低いように感じる(締め切り守る気あるのだろうか?, オーバーエンジニアリングしてないだろうか?)
- 変更を柔軟に取り入れてデッドラインも守るようにしてほしい(差し込み開発入れたいこともあるけど、走ってる大きな機能追加のデッドラインはずらしたくない)
エンジニア側には以下のような不満がありました。
- 見積もり前にビジネス側で開発のスコープとデッドラインが決めないでほしい
- 開発する機能に関して背景や目的があまり納得できない
- 開発する機能の優先順位がわからない
- プランナー側が作成する要求や仕様が不正確だったり、不十分だったりするせいで、開発期間が延びていると感じているのに理解されていない気がする
そんな中、社内アジャイルコーチによるエンジニアチームでの振り返りワークショップをきっかけに、エンジニアが週1の改善 MTG を開始し、不満をためることをやめ、プランナー側へ歩み寄るという行動を始めました。
仕様が期待するものでないのは、エンジニア側からどんなものが欲しいのか伝えられてないからだということで、要求仕様の書き方の模範例を一緒に作る取り組みを始めたり、リモートランチなど直接的に仕事とは関係ないコミュニケーションの量を増やしたりしてお互いの理解を進めていく一方で、KanbanやScrumの社内研修をプランナーとエンジニアで一緒に受けてAgileな開発に関する共通認識を一緒に作っていきました。そして、Scrumからいいところを学ぼう、チーム改善のヒントを得ようとして開催された社内Scrum研修を受けた後、あれScrum導入してもいいんじゃない?とプランナー側、エンジニア側どちらともなく思ってScrumでの開発が始まりました。
以下のような制約がある中の導入でしたが、それらを受け入れながら、チームの自律的、協調的な動きはScrum導入後加速したように思います。- プランナー組織構造の都合上、1人のPOは選出しにくい
- QAを担当する独立した組織があり、社内にQAの責任者入るものの、実際の手動テストは外部委託
- 開発チームに共通の言語がない(チームメンバーは中国人、台湾人、日本人、アフガニスタン人で構成され、日本語を話せない外国人、英語を話せない日本人がいる)
私達は理想的なScrumを実践できている訳ではないかもしれませんが、継続的な改善とお互いの歩み寄りを積み上げ、またScrumのフレームワークの力を借りることで、確実に、よりアジャイルになっていると感じています。
この事例紹介を通して、組織間の不和に悩んでいる人、チームメンバーにもっとお互いを助け合って欲しいと思っているリーダーのような人に改善のヒントを共有できるといいと思っています。 -
keyboard_arrow_down
Kazuki Mori - Effective Retrospective / とにかく楽しいふりかえり
45 Mins
Thought & Practice
Beginner
みなさんは楽しくふりかえりをできていますか?
スクラムでは「レトロスペクティブ」というイベントとして、チームの活動の一環として定義されている「ふりかえり」。色々なチームの話を聞いていくなかで、ふりかえりがなかなかうまくいかない、というチームが多いという現状が見えてきました。
マンネリ化してしまったり、ふりかえりがスキップされてしまったり、アイデアがなかなか出てこなかったり。そんな状態から脱却するためには、まずは「場」を作ることが大事だと考えています。
場とは、心理的・物理的なさまざまな側面からなる流動的に変わっていく生き物のようなものです。この場を参加者全員の力でよい方向に形成することで、チームがより高く成長するためのアイデアが出やすくなります。
場とは何か。そして、場を作るためにどんなことをすればよいのか。また、ふりかえりを楽しくするためのやり方にもフォーカスを当てて、「ふりかえり」全般についてお話できたらいいな、と考えています。
以下のことを中心にお話いたします。
- ふりかえりの3つの目的と3ステップ
- ふりかえりにおける「場」とは
- 物理的・心理的に場を作るための方法
- ふりかえりをより楽しくするための方法
- ふりかえりのさまざまな手法
-
keyboard_arrow_down
Takahiro Futagawa - スクラムチームを辞めて20人でカンバン運用してきた半年間の軌跡
20 Mins
Advanced Case Study
Intermediate
Pairsを運用する株式会社エウレカでは2018年4月から、それまでの目的別スクラムチーム組織を変更し事業部全体でリアルカンバンを用いたプロダクトバックログの優先順位を忠実に消化できるチーム体制へ変更しました。
このセッションでは4月から今までのリアルカンバン運用の軌跡についてお話しながら、つらみやうまく行ったこと、今後の展望などをご紹介したいと思います。
-
keyboard_arrow_down
Yosuke Ota - スクラム1年生のチームが全員でRSGT2018に参加してわかったチーム開発、はじめの一歩
20 Mins
1st Step Case Study
Beginner
どのようにするとより良いチーム開発ができるのでしょうか。
いま、私たちのチームは自信を持ってチーム開発をしています。1週間スプリント中の1日スプリント、当たり前に行われるペア・モブプログラミング、チームの活動に合わせた工夫のあるタスクかんばん、多くのプラクティスを実践することで安定してチームの成果を出しています。
しかし、スクラム導入からしばらく、自信を持ってチーム開発をしているとは言えない状態でした。
メンバーの状態に左右されるベロシティ、レビューで発覚する未完了、再計画されないデイリースクラム、さまざまな課題がそこには存在していました。スクラムのことを良く分かっておらず、言われたことをやっているだけの状態だったため、改善のサイクルをうまく回せないことが続きました。チーム開発に対する不安が大きい時期です。
このような状態から大きく変わる転換点となってくれたのが、チーム全員で参加したRSGT2018でした。
本セッションでは私たちのチームがわかったRSGTの素晴らしさと、チーム開発のはじめの一歩を紹介します。
-
keyboard_arrow_down
Tsutomu Yasui - 心理的安全性ゲーム
45 Mins
Thought & Practice
Beginner
チームの中で、なにか事件が起きたとき、誰がどういう反応をするかでチームの底力が垣間見えます。「心理的安全性ゲーム」では、マズい状況に対する様々な反応を体験して、チームにおける心理的安全性の意味と作り方の理解を深めます。
「心理的安全性ゲーム」はカードゲームですが、勝敗はありません。マズい状況を発見して報告してくれた「平和を破壊する役」に対して、各メンバーは手札から「発言」を選んで反応します。10分ていどで遊べる簡単なゲームになります。
このゲームは文字通り、心理的な効果を体験できます。たとえゲームと分かっていても、「教えてほしい」と頼んでいるのに「舌打ちをして」「自分でやれ」と言われるとちょっと傷つきます。言ったほうも、あとで心苦しくなったりします(あるいは、スカッとするかもしれません)。そうしたやりとりを目の当たりにしたチームと一緒に、よいコミュニケーションについて話をするきっかけを作るゲームです。
4-5人のグループでゲームをやり、そこでの気づきやよりよいコミュニケーションの在り方について議論をしたり、共有したりします。さらにどんな改善が見られるか、再度ゲームをやって試してみましょう。
-
keyboard_arrow_down
Yoshihiro Yunomae - 運用中のモバイルゲーム開発チームに、並行バージョン開発を導入してみた
20 Mins
Advanced Case Study
Intermediate
モバイルゲームの運用では、プレイヤーを飽きさせないために、週2~3回のコンテンツのアップデートと、月1回の機能アップデートを実施します。このため、開発チームは継続的に価値を出し続ける工夫が必要となります。アカツキのある大規模開発チームにおいて、人数の割に開発の進みが思わしくなく、作業が属人化されていました。結果的にプレイヤーに継続的に価値を届けるのが困難となっていました。これは、以下の2つが根本的な原因でした。・チームの開発スタイルが確立する前にチームが肥大化したことにより、コミュニケーションフローが整備されていなかった・開発業務中に運用業務の差し込みが入り、度々開発が中断していたこれらの根本課題に対処するため、以下を実施しました。1. 開発チームを分割し、コミュニケーションパスを設計2. Scrumをベースに、複数のチームが並行バージョン開発出来るように開発フローを設計3. 次々バージョン開発チームが運用業務を行うようにし、次バージョン開発チームの業務中断を抑止本セッションでは、並行バージョン開発を取り入れた経緯と、取り入れた並行バージョン開発の手法を詳細に紹介します。 -
keyboard_arrow_down
Takahiro Kaihara / Misa Fukuhara - 「自分を立てなおす対話」をやってみよう! ♥ 智慧の車座ワークショップ
Takahiro KaiharaJesterTao of Scrum KansaiMisa Fukuhara組織と関係性のためのシステムコーチ(ORSCC)オフィス福原 C&D HR Lab.schedule 4 years ago
120 Mins
Workshop
Beginner
みなさん、仕事上で理不尽な思いをしたり、仕事でなんだか不完全燃焼していませんか?
自分ではなくても前は仕事をバリバリと精力的に活動していたのに、今は元気がないなぁって人がまわりにいませんか?
社会人生活や人生において、ロジカルには解決できない問題がたくさんあります。
そのような問題を解決・解消するひとつの方法として、皆さんに「対話」を紹介し、少しでも健やかに日々を過ごしていただきたいというのが、このプロポーザルを出した理由です。
本セッションでは、プロコーチ、組織コンサルタント加藤 雅則さんの著作『自分を立てなおす対話』で紹介されている『智慧の車座』をやってみたいと思います。
https://www.amazon.co.jp/dp/453231707X
智慧の車座は、問題を抱えたテーマオーナー(相談者)と、複数の支援者の対話を通して、「問題をほぐし」「智慧を出し合い」解決方法を模索する対話法です。
このワークショップ参加後に、以下のような状態になればよいなあと考えています。
- 「自分を立てなおす対話」とは何かを知る
- 「自分を立て直す対話」を(なんとなく)できるようになる
人生に迷っているあなた、このワークショップに参加して、暗闇の荒野に進むべき道を切り開いてみませんか?
興味を持たれた方はぜひ、投票をお願いいたします。
「対話こそ、金より輝かしく光よりいのちあるもの」(ゲーテ)
-
keyboard_arrow_down
Rie Chonan / Tadataka Ebihara - プロダクトオーナーは突然に 〜メカ屋出身プランナーと奇妙な冒険〜
Rie ChonanScrum MasterLINE CorporationTadataka EbiharaProduct OwnerLINE Corporationschedule 4 years ago
20 Mins
1st Step Case Study
Beginner
プロダクトオーナーの育成、支援はスクラムマスターの役割であり、難しさである、という事は巷でよく聞く課題です。
確かに、私も過去に現場でそのような状況に直面することがあり、プロダクトオーナーの立ち位置やチームとの関わり方、支援の方法について悩むことがありました。
一方で、私たちClova関連チームのプロダクトオーナーは、POという役割も、スクラム開発も初めてという状態での抜擢。
未経験による悩みだけでなく、ソフトウェア開発とのギャップを感じていました。
このような状況で、私たちはプロダクトオーナーが抱える悩みや問題は、開発チームの課題として一緒に解消する事にしました。
本セッションでは、Clova関連チームのプロダクトオーナーと共に登壇します。
複数の立場から、開発チームとの関わり方やプロダクトオーナーが躓きやすいポイントを紐解きながら紹介できたら幸いです。
-
keyboard_arrow_down
Mitsuyuki Shiiba - ちゃんとやってるのになんかうまくいかないスクラムからの脱出
20 Mins
Advanced Case Study
Intermediate
こんにちは。椎葉です。
僕は楽天でWebアプリケーションエンジニアとして働いています。数年前に「エンジニアとして色んなチームを内側からサポートしたい!」と考えて「改善グループ」というグループを立ち上げました。そして、様々なチームの中に入っていって、一緒にコードを書いたり、テストを書いたりして楽しんでいます。
そんな風にエンジニアとして動くことを中心にしてはいるのですが、実は毎回最初にやるのはチームの開発プロセスを一緒に改善することなんです。というのも、エンジニアとして動くための土台としての開発プロセスが、とても重要だからです。
僕の所属しているECインキュベーション開発部では、どのチームもスクラムで開発をしているのですが、この活動の中でよく聞いたのは「スクラムをやってはいるのだけど、何かうまくいかない」ということです。
このセッションでは「スクラムが何かうまくいかない」と感じているチームに実際にどのような課題があったのか、その原因は何だったのか、そしてそれをどのように改善したのか、を失敗談も交えながらお伝えしたいなと思います。
同じような課題を感じている方が一歩踏み出すきっかけになるといいなと思います。そして、セッションの後にはみなさんと「うちもこういうことがあるよー・あったよー」みたいな話をできたら嬉しいです!
-
keyboard_arrow_down
Ken Takayanagi / Manabu Shibahashi / Yumiko Yoshida - 喧嘩できるチームを作るワークショップ
Ken Takayanagidialogue facilitatorClassmethod.IncManabu ShibahashiPresidentTAMA Support ServiceYumiko Yoshida代表取締役、コラボレーションコン サルタント株式会社Hyper-collaborationschedule 4 years ago
100 Mins
Workshop
Advanced
「チームのメンバーで喧嘩できてますか?」
自分が言いたいことが相手の意見と対立しそうで、伝えなかった…。
言ってもわかってもらえないと思ったので言わなかった…。
このチームでは余計なことをすると指摘されそうで面倒臭いのでやらなかった…。
そんな体験はないでしょうか?
自分の伝えたい考えをきちんと伝える。相手が伝えたい考えときちんと向き合う。
これはチーム内での会話の仕方でもありますが、チームの空気感というか文化からも影響を受けると考えます。
「喧嘩できる」というのは対立構造ということではなく「喧嘩ができる」チームの空気感があるというある意味「健全なコミュニケーション」が行える状態についてお伝えしたいと思います。その改善として、このワークでは組織や文化の理論もお話ししながら、学びと体験をお届けします。
2018/10/19
同ワークショップを企業で実施した時の記事が公開されました。
http://bit.ly/2OCzYA9 -
keyboard_arrow_down
Takuo Doi - 行動分析学に基づくScrumの導入
45 Mins
Thought & Practice
Intermediate
Scrum / Agileは非常に人間的なアプローチです。
そして、それが大きな魅力である一方で、これまで、プロセスで縛ることにより開発を実践してきた人にとっては、理解できない、導入できない原因ともなっています。
アジャイルの実践者に現場の課題を相談した際に、よく返ってくる返事の一つが、「It depends(状況による)」です。
この言葉はまさしくそうなのですが、アジャイルコーチが入っているような現場ではなく、あまり経験のない人にとっては、自分たちの状況を見てもどうしたらよいか分からなく、手当たり次第に思いつきを実施してみたり、原理主義のようにプラクティスを遵守しようとしたりしてしまう原因となっています。
本セッションでは、心理学の一分野である行動分析学に基づき、Scrumの課題を見付け、その課題を解決する方法を見つける科学的な方法を提案したいと思います。
本セッションの内容により、改善を促したいプロジェクト/チームをどのようにScrumがうまく機能する体制にし、文化として根付かせるかの汎用的な手法を知ることができます。
-
keyboard_arrow_down
Takao Oyobe / Haruna Iizuka / Masahiko Morita / Megumi Tsuchihashi / Ryota Nagatomo / Saki Ota / Saki Tanaka / Takuya Uchida / Tsubasa Kanemura / Yuki Misumi - 学習する/Unlearnするチームへ ー 新卒研修とスクラムとモブプログラミング ー
Takao OyobeアジャイルモンスターHoloLab Inc.Haruna IizukaTraineeRakuten, Inc.Masahiko MoritaAccountingRakuten, IncMegumi Tsuchihashiad traderRakuten, IncRyota Nagatomo新卒エンジニアRakuten, IncSaki OtaVisual DesignerRakuten. IncSaki TanakaEmployeeRakuten, Inc.Takuya UchidaSoftware EngineerRakuten, Inc.Tsubasa KanemuraSalesRakutenYuki MisumiSoftware EngineerFreelanceschedule 4 years ago
45 Mins
Thought & Practice
Intermediate
チームがうまくなるために、「学習」と向き合うことはとても大切です。
私がこれまで関わってきたチームでも、アジャイル開発を通してチームがうまくなることに取り組み続けてきました。ところが、最近新卒向けの研修に携わった際に衝撃を受けました。
ビジネス採用として入社したためプログラミング未経験だった新卒の彼らは、当初は黒い画面(ターミナル)すら怖がっていましたが、数カ月後にはメンター陣からのインプットを頼りに、
- 1 day timebox
- 1 hour timebox
- モブプログラミング
- プロトタイピング
- ユーザーインタビュー
などをまわしながら、3週間でプロダクトを作れるようになっていました。
その道のプロフェッショナル達がエクストリームだと思うこと/どうはじめたらいいのか悩んでいることを平気で突破してしまったのです。もちろん彼らはプロダクトを本番リリースしたわけではありません。
もちろん彼らは運用しながらお金を稼いでいるわけではありません。
でも彼らはプロダクトづくりの経験をもっていませんでした。
でも彼らはプログラミング経験ももっていませんでした。私達は、
- 学習し続けていく中で固定観念に囚われてしまうことがあること
- 学習をしていないことが圧倒的成長スピードを生むことがあること
という事実に向き合う必要があります。
学習を積み重ねていくことで成長スピードが落ちてしまうのではなく、学習を積み重ねていっても成長スピードを落とさないチームをどうつくるか。そのためにはUnlearn(学びをリセット)がキーになります。
このセッションでは、そろそろ言い訳するのはやめてもっとうまくなるためにはどうすればいいのかを真剣に考えます。もっとうまくなるための学習する/Unlearnするチームについて一緒に考える時間にしましょう。
-
keyboard_arrow_down
Tatsuya Kinugawa / Rochelle Kopp - そのときサーバントリーダーはどう振る舞うか
Tatsuya KinugawaGeneral ManagerRakutenRochelle KoppManaging PrincipalJapan Intercultural Consultingschedule 4 years ago
45 Mins
1st Step Case Study
Beginner
サーバントリーダーシップを実践するにあたって様々な場面で振る舞いを考えさせられることがあります。
上司への向き合い方、配下リーダー陣への向き合い方、はたまた彼らのメンバーに向けてもこれまでとは違う振る舞いをすることが多いです。
本セッションではRochelle Koppさんと一緒に具体的なシチュエーションを題材にしながら旧来のマネジメントとサーバントリーダーシップの振る舞いの違いについて実例を挙げながらお話したいと思います。
これによりこのマネジメント手法がより身近なものに感じて頂ければ嬉しいです。
-
20 Mins
Thought & Practice
Beginner
[email protected] Guide を読んでみましょう(RSGT2019までには日本語版が出ているはず)。
-
keyboard_arrow_down
Toshiyuki Ohtomo / Yusuke Amano - プロセスを良くするだけではチームはゴミを大量に作り続ける 〜より良いプロダクトに欠かせないPO支援〜
Toshiyuki OhtomoScrum MasterCybozu, Inc. and Cafigla LLC.Yusuke AmanoScrumMasterCybozuschedule 4 years ago
20 Mins
Thought & Practice
Beginner
スクラムマスターはプロセスにリーダーシップを発揮します。
では、プロダクトのリーダーシップは誰が発揮するべきでしょうか?
プロダクトオーナーです。
皆さんの現場で、開発チームとプロダクトオーナーの間に距離を感じることはないでしょうか。より良いプロダクトを作るには、開発チームとプロダクトオーナーの相互の対話が欠かせません。
サイボウズの社内で複数のスクラムチームを支援する中で、開発チームだけでなくプロダクトオーナーを支援する必要があるということを学びました。
ここでは、スクラムマスターとしてスクラムのセレモニーをプロダクトオーナーにとっても欠かせない場にしていった経験を共有したいと思います。- プロダクトオーナーの抱える問題
- プロダクトバックログアイテムの分割
- セレモニーの時間が取れない
- 開発の見通しが立たない
- プロダクトオーナーを支援する取り組み
- プロダクトバックログリファインメントの質を高める
- スパイクの活用
- スプリントゴールの設定
- スプリントレビューで未来を語る
- スプリントレトロスペクティブでメトリクスを活用する
- プロダクトオーナーの抱える問題
-
keyboard_arrow_down
Stefan Nüsperling / Ikuo Suyama - Fail fast, learn fast - Celebration Grid:組織を変えるプラクティス [Management 3.0体験ワークショップ]
Stefan NüsperlingManagement 3.0 ファシリテーター、Founder & CEONüWorksIkuo SuyamaEngineerCyberAgentschedule 4 years ago
45 Mins
Thought & Practice
Intermediate
Celebration Grid
失敗から学ぶことは、ビジネスにおいて重要なテーマであることは疑いようがありません。
企業、組織、およびチームは、すばやく失敗し、失敗から学ぶことで、複雑な環境に適応しなければなりません。あなたの組織では、失敗を祝福していますか?成功したことのみを祝い、多くのことを学べる失敗をないがしろにしてはいませんか?それでは、すべての失敗を祝う必要があるのでしょうか?あるいは、両方を祝うのでしょうか?"セレブレーション・グリッド" によって、成功や失敗ではなく、 "学習したこと" を祝福しましょう。このセッションでは、"セレブレーション・グリッド" を実際に作成していただき、失敗を祝う方法や、学びを得るための実験をマネジメントする方法をお伝えします。Management 3.0
Management 3.0 は、オランダ出身のヨーガン・アペロ(Jurgen Appelo)が作ったアジャイルリーダーシップ概念です。「人ではなく、システムをマネージするべき」というアイディアに基づいています。Celebration Grid は、Management3.0の中でもAppelo氏が「最も重要なもの」と位置づけるプラクティスです。CyberAgent AdTech Studioでの事例紹介
CyberAgent ではこれまで2度ステファン氏によるManagement3.0社内研修を実施しており、20名以上の参加者が1年以上にわたり Management3.0 の取り組みを続けています。今回はその中でも「セレブレーショングリッド」のプラクティスを社内でどのように運用し、どのような成果が得られたのかを、成功と失敗の事例を交えてお話します。