良いアプリを作る為にスクラムを初めたら、巨大な組織(自動車会社)の風土が変わってきた話
日本の典型的な製造業で、スクラムで社内向けアプリ開発を始めて約1年。
ソフトウェア開発をしたことのない部門が、失敗を繰り返しながら動くをソフトを作り、ユーザーに価値を提供出来るようになってきました。
スクラムによって生まれたのは品質の高いアプリだけではありません。セクショナリズムが強い大企業の中で、部門を越えた関係者が一つのチームとして動くことによって仲間が増え、コラボレーションが生まれ、想定していなかった所でも新たな価値が生まれつつあります。
組織風土の変化の話に加えて、開発チームの具体的改善事例やインフラ構築の取り組み、メトリクスの推移なども共有します。
参考に7月にDASAで発表した際の資料をシェアします:
https://speakerdeck.com/yasuhiro_funato/minnagashou-huo-wode-rareru-aziyairukai-fa
Outline/Structure of the Talk
今回は、典型的な日本の製造業でスクラムを導入するにあたって大変だった点を中心に事例をお話します。
1人で始めて20人の開発チームになるまでの軌跡と、失敗とカイゼンの歴史、部門の壁を越える話など実例をそのまま共有します。大企業&製造業でも、ちゃんとスクラム開発できるんだ!と感じてもらい、挑戦するモチベーションと失敗する勇気を持ち帰っていただければうれしいです。
内容
- 日本の典型的製造業の風土
- 初めの一歩
- 1人からチームへ
- カイゼン事例
- 開発インフラの構築
- 組織風土の変化と得たもの
Learning Outcome
挑戦するモチベーションと失敗する勇気
Target Audience
ボトムアップでスクラムを初めたい方、イノベーションを起こす風土を作りたいマネージャーの方
Links
schedule Submitted 1 year ago
People who liked this proposal, also liked:
-
keyboard_arrow_down
Yoh Nakamura - みなさんのプロダクトバックログアイテムはOutcomeを生み出していますか?
20 Mins
Talk
Intermediate
現場コーチとしてScrumでサービス開発しているチームの支援をしていると、よくディスカッションする話題の1つが「プロダクトバックログアイテム(PBI)の価値や成果をどう考えて、どのように扱うか?」というものです。
このような話題の時、OutputとOutcomeの話をします。
- Outputとは、リリースした機能の数や質のことをここではいいます。
- Outcomeとは、利用者がどう変わったのか?利用者の課題が解決したのか?と利用者視点での効果のようなことをいいます。
- ※Outcomeはビジネス視点からのOutcomeと、利用者視点からのOutcomeの2つに分類されます。上記は利用者視点からのOutcomeのことを書いています。
- ※Outcomeはビジネス視点からのOutcomeと、利用者視点からのOutcomeの2つに分類されます。上記は利用者視点からのOutcomeのことを書いています。
たくさんのPBIをつくって頻繁にリリースしてOutputが増えたとしても、自分達にとっての価値、もしくは利用者にとっての価値(利便さや嬉しさ)といったOutcomeが増えていないとそのプロダクトやサービスを続けていくことはできません。
1つずつのPBIの情報に"売上の増える額"や"ユーザー数の増加”を加えているチームもあります。
また別の現場ではストーリーポイントと同じようなやり方で、仮想の単位を決めて相対的な値をチームで話し合って、どれからやるか?の参考にしています。
プロダクトバックログアイテムには、詳細・並び順・見積り・価値の属性がある。(ScrumGuide2017より)
このセッションでは、"プロダクトバックログアイテムにおける価値の取り扱いのやり方”のいくつかの現場の事例を紹介しつつ、Outcomeについて考えをお話します。
みなさんのPBIのOutcomeがよりわかりやすく、より高くなるヒントになればと思います。 -
keyboard_arrow_down
中村 薫(Kaoru Nakamura) - 10年たってやっとアジャイルがわかりかけてきた話
20 Mins
Talk
Beginner
アジャイル、XP、Scrumは10年くらい前からイベントに出たり、本を読んだり勉強しても、どうにも身につかず。
2017年に会社を作って、2019年に自社サービスをリリースして、やっとアジャイルが腹落ちしてきた気がします。
このセッションでは、なぜ今までアジャイルが実践できなくて、なぜ今になってアジャイルがわかりかけてきたのか、ということをお伝えできればと思います。
-
keyboard_arrow_down
Ryutaro YOSHIBA (Ryuzee) - アジャイルコーチ活用術
20 Mins
Talk
Beginner
世の中でアジャイル開発が一般的になるにつれて、アジャイル開発を支援する「アジャイルコーチ」という職種や肩書を見かけることが多くなってきました。
アジャイルコーチとは組織がアジャイルなやり方で成果を出せるようにするために、組織的な観点、技術的な観点、プロダクトの観点などさまざまな観点から支援する役目です。
アジャイル開発に慣れていないチームには、アジャイルコーチは必要な存在だと言ってよいでしょう。一方で、アジャイルコーチといえば、「めんどくさい」「マサカリ投げる」「上がった感」「単価が高い」「実際の効果がよくわからない」といったイメージがあります。
これらはコンサルティングを始めとした支援系の仕事に対する共通のイメージでもありますが、銀の弾丸思考の表れでもあります(アジャイルコーチがあなたの問題をすべて指摘し、魔法のように解決してくれるわけではなく、あくまで主体はスクラムチームです)。本セッションでは、アジャイルコーチとは何なのか、実際にアジャイルコーチをどう活用すれば良いのかを、日本で唯一のScrum Alliance Certified Team Coach(CTC)で実際にアジャイルコーチングを有償サービスとして提供している現役アジャイルコーチが解説します。
-
keyboard_arrow_down
Kazutaka Matsusaki / 河野 彰範 - アジャイルな組織を創っていくには?地銀で取り組むアジャイルな組織創り
45 Mins
Talk
Beginner
ふくおかフィナンシャルグループ(FFG)では、2018年4月、DevOps・アジャイル開発を実践していくための組織が立ち上がりました。
昨今厳しいと言われる銀行業界でイノベーションを起こしていくための組織です。2018年5月にゲーム会社から銀行へと異色の転職で入社以降、このアジャイル開発チームに携わってきました。
古くからある大きな企業でのアジャイル開発を進めていくには、技術的な面・組織的な面で非常に多くの問題が存在していました。
そもそも外注開発しかしたことのない組織が内製開発に取り組むということで、その問題の大きさは想像に難くないでしょう。
実際、前職とはかけ離れた環境やフローが存在し、多くのカルチャーショックにぶちあたってきました。このセッションでは、そんな組織の中で、ゼロからアジャイル開発を進めてきた1年半の歴史を余すことなく紹介していきたいと思います。
取り組んできたこと、失敗したこと、成功したこと、たくさんあります。
地銀という古い体制の組織・規制の厳しい金融業界、そんな世界で経験してきた内容が、少しでもみなさんの今後に役立つことができれば幸いです。- アジャイル組織の変遷
- 現行ルールのしがらみとの闘い
- アジャイル開発を少しずつ組織に浸透させていく方法
- 組織を拡大していくための対内・対外的な取り組み
- 拡大していく組織で発生した問題
- 成果を出し続けていくための組織やチームの意識改革
-
keyboard_arrow_down
Hiroyuki Ito/伊藤 宏幸 / 高橋 勲 - 特殊部隊SETチームの日常 - 技術と実験を融合した実践アジャイル術 -
Hiroyuki Ito/伊藤 宏幸Lead of SET (Software Engineer in Test) TaskforceLINE Corporation高橋 勲SETLINE Corporationschedule 1 year ago
45 Mins
Talk
Intermediate
我々LINEのSETチームは、テスト自動化の実現・推進だけではなく、プロダクト開発チームのプロセス改善・DevOpsの推進・技術戦略の策定・実施といった活動を、全社的に行っています。
一連の活動に際して我々は、様々な技術・ツールとアジャイルプラクティス・マインドセットとを組み合わせ、日々実験を繰り返しながら、ビジネス的成果へとつなげています。当セッションでは、特定の開発チームから組織横断活動までに活用できる、技術とアジャイルの組み合わせ方を、LINEでの実例をもとに、参加者の皆様が現場に持ち帰って試せる形でご紹介します。また当セッションは、SETチームをこれから作ろうとされている会社・担当者の皆さま向けの具体的なアプローチ集とすることも想定しています。 -
keyboard_arrow_down
kyon _mm - チームの再定義 -進化論とアジャイル-
45 Mins
Talk
Advanced
1つのチームが複数のプロジェクトに分裂したとき、そのチームはどうひきつがれるのでしょうか。おなじものにはならないし、それなりの成熟をするには時間がかかる。だから、チームはできるだけ解散してはならない。果たして本当にそうでしょうか?
私達のチームメンバーは複数のプロジェクトにわかれ、PBLもPOもまったく異なるようになりました。それでも1つのチームとして存在する方法を模索しました。その過程で、複数チーム、複数プロジェクトにおける15minスプリントを基盤とするフラクタルスプリント、組織横断な知識交換、プロジェクトに依存しないチームとしての存在意義を見出してきました。私達のチームは解散したようにみえましたが、実際には解散していなかったのです。フラクタルスプリントによってフラクタルチームは成されました。
異なるミッションをもっていても、組織としては軍隊アリやバッファローのような超個体をめざす1つのチームとして機能をするようにまでなりました。プロジェクトのためだけにチームがあるのではありません。わたしたちがいるからチームなのであるという視点をつきつめていき、それは個人や組織の成長にもつながっていく姿をお話します。
そしてこれらを支える理論として進化心理学、ダーウィンの進化論などの学術的な視座からアジャイル開発を話します。なぜ人間はチームをつくるのか。
-
keyboard_arrow_down
Yasunobu Kawaguchi / Mori Masaya / Atsushi Ohta / Tatsuya Kinugawa - プロダクト生存戦略 : 大企業で新規事業を始めて成功させるには
Yasunobu KawaguchiAgile CoachAgilergo ConsultingMori Masayaファウンダー楽天技術研究所Atsushi OhtaHyper media creatorNIPPON TELEGRAPH AND TELEPHONE WEST CORPORATIONTatsuya KinugawaGeneral ManagerRakutenschedule 1 year ago
45 Mins
Panel
Advanced
大企業で新規事業を始めるために必要なものはなんだと思いますか?予算ですか?社内政治ですか?そう!違う!そう!
プロダクトオーナーやリーンスタートアップの本を読んでも、なかなか教えてもらえないのが「日本企業におけるカネと政治」。エンジニア出身の方も、マーケティング出身の方も、プロダクトデザインやUXの方も、等しく苦労するポイントであろうと思います。
プロダクト開発はうまくできても、それ以外のところで泥沼にハマってしまいがちな大企業の皆様に、うまくサヴァイヴして人生をときめくためのヒントをお伝えできればと考えております。そのために、実際に大企業で新規ビジネス開発の仕組みづくりに携わるみなさんから、戦略やヒントやマサカリをいただきます。もしかしたらちょっと心に棘が刺さるかもしれませんので、しっかりと心のご準備をお願いいたします。
発表者は、絹川達也さん(楽天)、太田敦士さん(NTT西日本)、そして楽天技術研究所や楽天テクノロジーカンファレンスを設立から育ててこられた森正弥さん。いずれもご本人が新規サービス/事業を手掛けるだけでなく、仕組みづくりや組織づくり、メンタリングなども携わられてきたみなさまです。
-
keyboard_arrow_down
Woohyeok Aaron Kim - 【元士官が語る】軍隊組織からみる、これからのアジャイルのあり方
45 Mins
Talk
Intermediate
アジャイルでの大物でありScrumを考案して世界に広げた人物。ジェフ・サザーランド氏は実は、米国陸軍士官学校を卒業した元パイロットです。
軍隊は一番入れ替わりが激しい組織です。今日入隊する人がいて、その反面退役する人もいます。退役の方が入隊より多く、総員の数がマイナスになることもあります。入れ替わる時の階級もバラバラで、一般兵士が入隊してきても、例えばベテラン士官が退役する場合もあります。
しかし、こういう状況の中でも、全てのメンバーを即戦力に作る極限のアジリティーを発揮し、最高のパフォーマンスを保つのが軍隊の最大課題であり、存在理由でもあります。私はそこで元陸軍将校として4年間勤め、300名の部下を纏めながら、毎日戦闘力の向上のために資源管理・訓練の計画・実施などに力を入れていました。
チーム(ないしは会社)そしてアジャイルプロセスは、軍隊と特に違いはありません。入れ替わりは激しく、生産性のために中途はもちろん新卒に対しても即戦力になれる人材を求めています。チームなど組織に対しても、一定のパフォーマンスを出すことが求められています。
制限された状況の中でも、どうしたら常に最大のパフォーマンスが発揮できるか。
軍隊ではどういう風にしていて、それをどうやって今のチーム・組織に活かせるか。私の経験を持ってご提案させていただきます。
-
keyboard_arrow_down
Tomoharu Nagasawa - Going Agile with Tools - たまにはツールの話もしようぜ
20 Mins
Talk
Intermediate
English follows Japanese.
---
アジャイルな開発においては、アナログなツールもデジタルなツールも大切な活動のための友達です。
このセッションでは、アジャイルもテクノロジーも成熟してきたなかでうまれ、乱立されてきたデジタルなツールについて、基本に立ち返ってどんなツールが求められているか、どんなツールをあなたの現場で選べばいいのかを考察していきます。
せっかく使うツールならば自分たちのための、自分たちの創り出す価値のためのものを選びましょう。
ツールから学ぶバリューチェーンのような内容にするつもりです。
なお、本セッションでは特定のツールにフィーチャーすることはありません。
---
It is important to become friends with tools (both analog and digital) as Agile team. In this session, I will consider about digital tool(s) following points of view returning to the basics.
- What tool(s) are needed with Agile
- What tools(s) should you choose at your Agile team
I will share to learn "flow of value" from tool(s) with you in this session.
-
keyboard_arrow_down
Takao Oyobe - Team-Based TEAM - 会社を越えるチーム -
45 Mins
Talk
Advanced
あなたのチームはいつ死にますか?
スクラムはチームワークのためのフレームワークです。スクラムでは、安定したチームが成功するための前提条件として紹介されることが多いです。実際に「STABLE TEAM(安定したチーム)」はScrum Patternsの1つになっています。
安定したチームは本当によいチームなのでしょうか?
私たちのチームは、スクラムやモブプログラミングを通して自己組織的なチームになりました。Unlearnを自分たちの活動に組み込んで、学習するチームになりました。スタートアップしたプロダクトも成長軌道に乗せることが出来ました。そしてそのチームは、プロダクトの終焉を乗り越え、さらには会社をも越えました。
私たちのチームは、Project-BasedでもProduct-Basedでもなく、Team-Based TEAMだったのです。私たちのチームにとってはプロダクトの終焉も転職もチームの死にはつながりませんでした。私たちの考える「STABLE TEAM(安定したチーム)」はSAME TEAM(同じチーム)ではなく、生物のように変化し続けることができるチームです。私たちは会社を越えた後も、変化と向き合い生物的チームを目指して活動を続けています。
あなたのチームはいつ死にますか?
このタフクエスチョンの答えはどの教科書にも載っていません。しかし、チームの死を考えることで、どう生きるかが定まり、どうチーミングすればよいのかが見えてきます。一緒にチームのライフサイクルについて考えてみましょう。
-
keyboard_arrow_down
Kazuki Mori / Jean-Baptiste Vasseur / Kazunori Otani / Kenta Sasa - スクラムの理解を深めるスクラムショーワークショップ
Kazuki Moriチームファシリテーター野村総合研究所Jean-Baptiste VasseurAgile Coach株式会社yamanecoKazunori OtaniSenior Customer Success ManagerNew RelicKenta SasaAgile コーチクリエーションライン株式会社schedule 1 year ago
100 Mins
Workshop
Beginner
スクラムショーワークショップは、スクラムの説明をショー(寸劇)形式で行うワークショップです。
このワークショップを通じて、参加者はスクラムの基本を体験・学習できます。スクラムショーワークショップは、yycr2019(アジャイルコーチとスクラムマスターの宴、通称:よなよなコーチングリトリート)で
生み出されたワークショップです。「短い時間でアジャイルを知るようにしてほしい」というニーズに応えるために、最大2時間でアジャイル・スクラムの理解を高められるワークショップをみんなで作りました。
会社の中で展開するために、できるだけ準備が少なく済ませたいという要望にも応えています。皆さんも、スクラムショーワークショップを実施してみましょう!
-
keyboard_arrow_down
Tetsuya Tarumoto - アジャイルUXリサーチLive! ~ 「即席」ユーザーテスト見学会
45 Mins
Talk
Beginner
UX屋さんは言います「ユーザーテスト(ユーザビリティテスト)は製品の利用品質を目覚ましく向上する」と。でも、専門家に頼むと結構な金額の請求書が届くかもしれませんし、社内でやると結構な手間がかかるかもしれません。結局、まだ「やったことがない」「見たことがない」という人が多いのかもしれません。
そこで、このセッションではスマホアプリを題材にしたユーザーテストを会場で実演します。「実演」と言っても大げさなものではありません。①その場にいる人で、②その場にある機材を使って、③約30分で完了する(ただしセッションは45分)ーーという「即席」スタイルです。
「UXとは?ユーザーテストとは?」という小難しいプレゼンテーションを聞いたり、その分野の本を読んだりするのも悪くありませんが、まずは自分の目で見て、自分で価値を判断してみてはいかがでしょうか。意外と気に入るかもしれませんよ。
-
keyboard_arrow_down
Ikuo Suyama - 見積りしないスクラム / NoEstimates Scrum
20 Mins
Talk
Advanced
はじめに
本セッションは「見積りは不要なのでやめよう」と一律に提案するものでは ありません。
アジャイル開発における見積りについては「アジャイルな見積りと計画づくり」という素晴らしい書籍でその有用性や有効な実践方法が示されています。ここで、あえて問わせていただきます。
「あなたのチームの見積りは、どれくらい正確ですか?」
前回の RSGT 2019 Key Note において、 Chris Lucian@christophlucian 氏は #NoEstimates のコンセプトと、見積りのコストについて言及しました。
彼が述べたように、見積りには負の側面があることもまた認める必要があるのではないでしょうか。私達のチームでは、これら見積りの負の側面と見積りから得られるものを比較し、見積りすることをやめる判断をしました。
以来、半年以上をかけて実験を繰り返し、時には失敗もし、今のプロセスをすこしづつ作り上げてきました。この私達のプロセスでは、モブプログラミングが鍵となっています。
本セッションでは、私達がどのように見積りをせず開発をしているのか、見積りをやめたチームで何が起こるのか、という事例を紹介し、ソフトウェア開発、特にスクラムにおいての見積りのあり方の議論の一助となることを目的とします。
見積りの負の側面と価値 - なぜ見積りをやめたのか
少し見積りの負の側面について触れておきます。
私達が考える見積りの負の側面は、以下に集約されます。- 見積りのコスト
- 見積りを行うためにかかる時間
- 数値化したことによる、納期コミットの圧力
- 数値化したことによる、仕事量の最大化(パーキンソンの法則)
- 見積りの難しさ
- ソフトウェア開発はそれ自体が複雑で不確実性を含む
- 殆どの場合で経験したことがないことへの対応が必要になる
- このため、正確な見積りを行うことが困難
もちろん、見積りは負の側面ばかりではありません。
しかしながら、見積りの「価値」については、見積り自体に価値があるのではなく、見積りから得られる副次的な情報に価値があると考えられます。- 見積りの価値
- 見積りから得られる計画
- 共通理解の促進
- e.g. プランニングポーカー
見積りから副次的に得られる価値が見積りの労力とバーターしない場合、その価値を別の方法で得られるのであれば、見積り自体をやる必要はないと考えます。
スクラムと見積り
タイトルの通り、私達はスクラムを実践しています。
見積りを行わないプロセスでもスクラムは成立するのか、あるいはこれはスクラムと呼べるのか、という疑問が当然湧いてきます。
スクラムガイドには「見積り」という言葉が9回登場します。
それぞれを分類すると、スクラムにおける見積りは以下の意思決定を行うための情報であると考えられます。- 計画づくり
- PBIの優先順位付け
- ROIの ‘I’ の算出に必要
- スプリントのキャパシティを測る
- PBIの優先順位付け
- 追跡
- スプリントの進捗状況を把握する
見積り自体を行うことなくこれらの意思決定をするための情報が得られるのであれば、見積りをしなくてもスクラムとして成立するのではないか、というのが今回のアイディアです。
我々は、以下の方法でこの意思決定を行っています。
- PBIの優先順位付け(ROIの ‘I’)
- PBIのサイジング
- 直近2Sprint分のPBIはすべて1スプリント以下のサイズに調整
- CD3(Cost of Delay Divided by Duration) による優先順位付け
- PBIのサイジング
- スプリントキャパシティ&追跡
- モブプロによるWIP制限
- 安定性・予測可能性の向上
- 過去データからの ‘予測’
- タスクのサイクルタイムをヒストグラム化
- タスクカウントとスループット
- モブプロによるWIP制限
まとめ
Joshua Kerievsky はAgile2016 の基調講演「Modern Agile」において、アジャイルプラクティスは「補助輪」であると表現しました。
見積りは今、ソフトウェア開発の「補助輪」といえる段階に差し掛かっているのではないでしょうか。私達のプロセスは完成されたものではなく、日々実験と失敗を繰り返して進化しているものです。
AEPから10年、「見積りはソフトウェア開発において必須」という考え方もまた固定概念かもしれません。
我々の実践しているソフトウェア開発の形について紹介し、議論できればと思います。 - 見積りのコスト
-
keyboard_arrow_down
Mitsuyuki Shiiba - テックリードは未来の話をしよう (Tech Lead in Scrum)
45 Mins
Talk
Intermediate
スクラムチームにテックリード?
「スクラムのロールには定義されていないけど、こういうのは誰がやるのが良いんだろう?」「そもそも、そんな状況ってことは、まだスクラムをやるための準備が整ってないってことなのかな?」って悩むことありませんか?僕はありました。
スクラムに取り組んだ最初のころは「あれー?ここどうしようかな?とりあえず・・・自分でやっとくかな」と思うことが結構ありました。「これでいいのかなぁ?」と不安に思いながらやってましたが、それも5,6年たった今では「あー、うちの組織だと、こういう役割が必要なんだわ。こそこそやらずに、自分の中でテックリードって名前つけて堂々とやっとく方が良さそうだな」って納得してやってます。
スクラムガイドの中には、テックリードというロールは定義されていません。でも僕は、今の組織の中で、このロールがとても大切な役割を果たしているなぁと感じています。大変だけど、やりがいがあって、とても面白いロールです。
バックグラウンド
こんにちは。椎葉です。楽天株式会社の大阪支社で自社ECサービスのアプリケーションアーキテクトとして仕事をしています。僕が所属している組織では、多くのチームがスクラムを採用しています。その中で、この数年間、僕は改善エンジニアとして「色々なチームに入っていって現場のみんなと一緒に内側から組織の改善をする」という活動をしてきました。その活動の中で学んだのが、テックリードというロールの大切さです。
僕の中のテックリードは、スクラムチームと組織のあいだに立って、技術的な視点に軸足を置きながら、開発やチームや組織を支える。そういう役割です。何かと何かの間におちてしまいそうなものに手をのばして拾い上げたりします:プロダクトオーナーと開発チームのあいだ、開発チームとスクラムマスターのあいだ、スクラムチームと組織のあいだ、そしてマネージャーとスクラムチームのあいだ。など。
このセッションで伝えたいこと
「僕の組織では、スクラムからは少し外れるかもしれないけど、こういうことをやる必要があって、僕はテックリードとしてこういうことをやってるよ」ということをお伝えしたいと思います。
それによって、これからスクラムに取り組もうとしていたり、既にスクラムを実践しているけど悩んでたりする方々に対して「あぁ、自分も同じようなことで、もやっとしていたけど、そういう風にやってる人もいるんだな」って何かしら参考になるようなセッションにしたいなと思っています。
また、その中で学んだ「テックリードとして考えておくと良いこと」もお伝えします。
今、テックリードとして悩んでいる方や、これからテックリードとしてチームをリードしていく方々に勇気を伝えられるようなセッションにしたいと思います。
-
keyboard_arrow_down
Masaya Mito - 組織変更して部長がいなくなってから起きたこと
20 Mins
Talk
Beginner
サイボウズの事業がオンプレミスからクラウドに移行する中、開発スタイルはウォーターフォールでの指揮統制・分業型からスクラムでの自己組織化・機能横断型に変わりつつあります。そんな状況の中、チームがユーザーにより価値を届けやすくするために職能別部署は解体されチーム主体の新組織になりました。
新組織の狙いは以下の4つです。
- 職能単位での部分最適化ではなく、チーム全体で最適化しやすく
- 従来の職能の枠にとらわれず、個人の多様なスキル・個性を活かしてプロダクトやチームに貢献できるように
- チームに必要なことはチームで意思決定できるように、権限と責任をチームに委譲
- 主体的にキャリアを作れるように異動をカジュアルに
組織変更の中で部長の役割は分割され再割当てされました。採用・予算などはチームに移り、異動は各メンバーに移り、給与評価はそれを受け持つ組織運営チームが新設されました。
組織変更をして8ヶ月、様々な変化が起きました。
どうやって意思決定するか議論するチーム。
どんな人を採用したいか、そもそも人を増やすべきなのかを議論するチーム。
上長がいなくなり色んな人と1on1し始めるメンバー。
活発になる他職能/他チームへのお試し異動。
チーム内でオープンに議論されるようになった問題。このセッションでは部長がいなくなった組織で起こったことを紹介します。
-
keyboard_arrow_down
Mitsuo Hangai - 大企業の縦割り組織の中でProduct Discovery Teamを作ってサービスをリリース出来た話
20 Mins
Talk
Intermediate
こんにちは。楽天仙台支社の半谷(はんがい)と申します。
仙台・東京・大阪・福岡にそれぞれ仲間がいる開発組織で、25人くらいのグループのマネージャーをやっています。ベースは仙台ですが、月に2回くらいは東京に行っています。
私達は、楽天市場の開発を行っています。
2019年6月にリリースした新機能開発では、もともと縦割り組織だったビジネス・デザイン・開発のそれぞれのステークホルダをワンチームにまとめ、日々数万店舗様が使ってくれるような顧客満足度の高いものを作ることが出来ました。
この体制を作るのに参考にしたのが、Jeff Pattonさんが提唱している「Product Discovery Team」の考え方でした。このおかげで、ともすると敵対関係みたいになってしまいがちな三者が、顧客に価値を届けるぞ!良いもの作るぞ!と同じ方向を向きつつそれぞれが強みを発揮するようになりました。
もちろん最初からうまくいったわけではなく、色々な書籍や文献、先達の知恵に助けてもらいつつ、もがき苦しんだ結果たまたま発見したものです。なのでセッションの内容は、うまくいったぜ!という過程ではなく、苦労話が多くなると思います。
このセッションが、大企業の中で組織改善に悩むいろんな方々のヒントになったら良いなと思います。私自身もまだまだ悩み中なので、一緒に旨い酒が飲める仲間が出来たら嬉しいです。
-
keyboard_arrow_down
Stefan Nüsperling / Yasuyuki Kashima - リーン・チェンジマネジメント - チーム・組織に変化を起こす!オリジナルのチェンジ・フレームワークを構築する方法
Stefan NüsperlingManagement 3.0 ファシリテーター、Founder & CEONüWorksYasuyuki KashimaDirectorDigital Business Innovation Centerschedule 1 year ago
100 Mins
Workshop
Intermediate
- 組織にアジャイルを導入するこに関わっていますか?
- 変化(変革)をスタートするときに押さえておくべきポイントとは?
- 変化(変革)に対する「人」と「要因」の適切な対応と考え方
- 変化(変革)を「見える化」する
- 全員で同じ方向に向かっていくために必要なこと
あなたが組織の変化・変革に関わり、チェンジ・プログラムを開発、実行するためのより効果的な方法を探しているのであれば、リーン・チェンジエージェントになりましょう!リーン・チェンジエージェントとして、あなた自身のチェンジ・フレームワークを構築する方法や、変化の影響を受けるステークホルダーからどう支持してもらえるかを様々な視点から考え学びます。
このセッションでは前半にManagement 3.0の「Change Management(チェンジマネジメント・ゲーム)」を行う予定です。後半はグループでチェンジ・キャンバスを作成します。ディスカッションを通して変化(変革)への戦略を考えていきます。キャンバスから見えてくる変化(変革)への課題とどう向き合い実践していくかを学び、リーン・チェンジマネジメントを体験してください。
-
keyboard_arrow_down
Takuo Doi - モブプログラミング x 行動分析学 x 教育 / Mob Programing x Behavior Analysis x Education
20 Mins
Talk
Beginner
現在,大学でプログラミング言語の授業を持っています.
その授業では,文法としてのプログラミングだけでなく,プログラミングの面白さを知ってもらえるもらえるように,モブプログラミングを導入して授業を行なっています.
ところが,企業でのモブプログラミングの導入とはまた違った課題がありました.そして,その解決策として,行動分析学を元にして,試行錯誤をしています.
本セッションでは,その試行錯誤の課程を共有したいと思っています.
----
I have a C programing course at university.
I introduced Mob Programing technique to my class so that my student learn not only the grammar of the programing language but also the fun of programing.
I have an experience to introduce Mob Programing to the work in our company. However I faced different problems. And Now I am trying to solve the problem using Behavior Analysis.
I will share this experiences in my session.
-
keyboard_arrow_down
Arata Fujimura - 最高のScrumキメた後にスケールさせようとして混乱した(してる)話
20 Mins
Talk
Intermediate
2018年の11月頃から始まり、開発手法としてScrumを採用したとあるプロジェクトは、2019年の6月に予定通りサービスのローンチを行うことができました。
このプロジェクトはお客さんとのユーザーストーリーマッピングでのMVP検討から始まり、まずはサービスの背骨にあたるMVPの実装を1ヶ月で完了。その後4ヶ月間はリリースできる状態をずっと維持し続けながら、毎スプリント着実に機能を追加していき、ローンチの1ヶ月以上前にはお客さんが希望する機能の追加を完了。ローンチ前にはいくつかのメディアに取り上げられたこともあり、多少注目されながらローンチ当日を迎えましたが、そこでも拍子抜けするほどなんのトラブルも起きず、お客さんからも開発チームからも、これほど安定したプロジェクトは今まで経験したことがないといったようなポジティブなフィードバックをもらうことができました。
その結果、お客さんからの期待値が想定以上に高まってしまい、同じやり方を他の複数プロジェクトにも早急に導入することが決定。開発者を含む関係者が一気に倍増したことで、チームは混乱状態に陥ってしまいました。
今現在も混乱中ですが、RSGT2020が開催される頃までには何とかなってると思うので、私達がこれからどのようにして再び練度の高いチームを作り上げていったかについてお話しできればと考えています。
-
keyboard_arrow_down
Harada Kiro - A Scrum Bookの歩き方
45 Mins
Talk
Beginner
ScrumPLoPとして2010年から活動してきたスクラムをパターンランゲージとして記述する活動も、2019/8/5現在、最終校正が完了し印刷待ちです無事9/3発売されました。RSGT 2020 には、出版された本を持っていける予定ですいきます。
540ページの大部になってしまったので、ちょっと気軽に手に取るには大きな本になってしまいました。
このセッションでは、A Scrum Book の読み始める方法を、ちょっとした出版までのエピソードなどを含めてお話しできればと思っています。
著者のJim Coplienを発表者に追加しました。