現場コーチとしてScrumでサービス開発しているチームの支援をしていると、よくディスカッションする話題の1つが「プロダクトバックログアイテム(PBI)の価値や成果をどう考えて、どのように扱うか？」というものです。

このような話題の時、OutputとOutcomeの話をします。

• Outputとは、リリースした機能の数や質のことをここではいいます。
• Outcomeとは、利用者がどう変わったのか？利用者の課題が解決したのか？と利用者視点での効果のようなことをいいます。
  
  • ※Outcomeはビジネス視点からのOutcomeと、利用者視点からのOutcomeの2つに分類されます。上記は利用者視点からのOutcomeのことを書いています。
    
    

たくさんのPBIをつくって頻繁にリリースしてOutputが増えたとしても、自分達にとっての価値、もしくは利用者にとっての価値(利便さや嬉しさ)といったOutcomeが増えていないとそのプロダクトやサービスを続けていくことはできません。

1つずつのPBIの情報に"売上の増える額"や"ユーザー数の増加”を加えているチームもあります。
また別の現場ではストーリーポイントと同じようなやり方で、仮想の単位を決めて相対的な値をチームで話し合って、どれからやるか？の参考にしています。

このセッションでは、"プロダクトバックログアイテムにおける価値の取り扱いのやり方”のいくつかの現場の事例を紹介しつつ、Outcomeについて考えをお話します。
みなさんのPBIのOutcomeがよりわかりやすく、より高くなるヒントになればと思います。

アジャイル、XP、Scrumは10年くらい前からイベントに出たり、本を読んだり勉強しても、どうにも身につかず。

2017年に会社を作って、2019年に自社サービスをリリースして、やっとアジャイルが腹落ちしてきた気がします。

このセッションでは、なぜ今までアジャイルが実践できなくて、なぜ今になってアジャイルがわかりかけてきたのか、ということをお伝えできればと思います。

世の中でアジャイル開発が一般的になるにつれて、アジャイル開発を支援する「アジャイルコーチ」という職種や肩書を見かけることが多くなってきました。
アジャイルコーチとは組織がアジャイルなやり方で成果を出せるようにするために、組織的な観点、技術的な観点、プロダクトの観点などさまざまな観点から支援する役目です。
アジャイル開発に慣れていないチームには、アジャイルコーチは必要な存在だと言ってよいでしょう。

一方で、アジャイルコーチといえば、「めんどくさい」「マサカリ投げる」「上がった感」「単価が高い」「実際の効果がよくわからない」といったイメージがあります。
これらはコンサルティングを始めとした支援系の仕事に対する共通のイメージでもありますが、銀の弾丸思考の表れでもあります（アジャイルコーチがあなたの問題をすべて指摘し、魔法のように解決してくれるわけではなく、あくまで主体はスクラムチームです）。

本セッションでは、アジャイルコーチとは何なのか、実際にアジャイルコーチをどう活用すれば良いのかを、日本で唯一のScrum Alliance Certified Team Coach(CTC)で実際にアジャイルコーチングを有償サービスとして提供している現役アジャイルコーチが解説します。

ふくおかフィナンシャルグループ（FFG）では、2018年4月、DevOps・アジャイル開発を実践していくための組織が立ち上がりました。
昨今厳しいと言われる銀行業界でイノベーションを起こしていくための組織です。

2018年5月にゲーム会社から銀行へと異色の転職で入社以降、このアジャイル開発チームに携わってきました。

古くからある大きな企業でのアジャイル開発を進めていくには、技術的な面・組織的な面で非常に多くの問題が存在していました。
そもそも外注開発しかしたことのない組織が内製開発に取り組むということで、その問題の大きさは想像に難くないでしょう。
実際、前職とはかけ離れた環境やフローが存在し、多くのカルチャーショックにぶちあたってきました。

このセッションでは、そんな組織の中で、ゼロからアジャイル開発を進めてきた1年半の歴史を余すことなく紹介していきたいと思います。
取り組んできたこと、失敗したこと、成功したこと、たくさんあります。
地銀という古い体制の組織・規制の厳しい金融業界、そんな世界で経験してきた内容が、少しでもみなさんの今後に役立つことができれば幸いです。

• アジャイル組織の変遷
• 現行ルールのしがらみとの闘い
• アジャイル開発を少しずつ組織に浸透させていく方法
• 組織を拡大していくための対内・対外的な取り組み
• 拡大していく組織で発生した問題
• 成果を出し続けていくための組織やチームの意識改革

我々LINEのSETチームは、テスト自動化の実現・推進だけではなく、プロダクト開発チームのプロセス改善・DevOpsの推進・技術戦略の策定・実施といった活動を、全社的に行っています。

チームの再定義 -フラクタルスプリントとフラクタルチーム-

1つのチームが複数のプロジェクトに分裂したとき、そのチームはどうひきつがれるのでしょうか。おなじものにはならないし、それなりの成熟をするには時間がかかる。だから、チームはできるだけ解散してはならない。果たして本当にそうでしょうか?

私達のチームメンバーは複数のプロジェクトにわかれ、PBLもPOもまったく異なるようになりました。それでも1つのチームとして存在する方法を模索しました。その過程で、複数チーム、複数プロジェクトにおける15minスプリントを基盤とするフラクタルスプリント、組織横断な知識交換、プロジェクトに依存しないチームとしての存在意義を見出してきました。私達のチームは解散したようにみえましたが、実際には解散していなかったのです。フラクタルスプリントによってフラクタルチームは成されました。

異なるミッションをもっていても、組織としては軍隊アリやバッファローのような超個体をめざす1つのチームとして機能をするようにまでなりました。プロジェクトのためだけにチームがあるのではありません。わたしたちがいるからチームなのであるという視点をつきつめていき、それは個人や組織の成長にもつながっていく姿をお話します。

そしてこれらを支える理論として進化心理学、ダーウィンの進化論などの学術的な視座からアジャイル開発を話します。なぜ人間はチームをつくるのか。

大企業で新規事業を始めるために必要なものはなんだと思いますか？予算ですか？社内政治ですか？そう！違う！そう！

プロダクトオーナーやリーンスタートアップの本を読んでも、なかなか教えてもらえないのが「日本企業におけるカネと政治」。エンジニア出身の方も、マーケティング出身の方も、プロダクトデザインやUXの方も、等しく苦労するポイントであろうと思います。

プロダクト開発はうまくできても、それ以外のところで泥沼にハマってしまいがちな大企業の皆様に、うまくサヴァイヴして人生をときめくためのヒントをお伝えできればと考えております。そのために、実際に大企業で新規ビジネス開発の仕組みづくりに携わるみなさんから、戦略やヒントやマサカリをいただきます。もしかしたらちょっと心に棘が刺さるかもしれませんので、しっかりと心のご準備をお願いいたします。

発表者は、絹川達也さん(楽天)、太田敦士さん(NTT西日本)、そして楽天技術研究所や楽天テクノロジーカンファレンスを設立から育ててこられた森正弥さん。いずれもご本人が新規サービス/事業を手掛けるだけでなく、仕組みづくりや組織づくり、メンタリングなども携わられてきたみなさまです。

　アジャイルでの大物でありScrumを考案して世界に広げた人物。ジェフ・サザーランド氏は実は、米国陸軍士官学校を卒業した元パイロットです。

軍隊は一番入れ替わりが激しい組織です。今日入隊する人がいて、その反面退役する人もいます。退役の方が入隊より多く、総員の数がマイナスになることもあります。入れ替わる時の階級もバラバラで、一般兵士が入隊してきても、例えばベテラン士官が退役する場合もあります。

　しかし、こういう状況の中でも、全てのメンバーを即戦力に作る極限のアジリティーを発揮し、最高のパフォーマンスを保つのが軍隊の最大課題であり、存在理由でもあります。私はそこで元陸軍将校として４年間勤め、300名の部下を纏めながら、毎日戦闘力の向上のために資源管理・訓練の計画・実施などに力を入れていました。

　チーム（ないしは会社）そしてアジャイルプロセスは、軍隊と特に違いはありません。入れ替わりは激しく、生産性のために中途はもちろん新卒に対しても即戦力になれる人材を求めています。チームなど組織に対しても、一定のパフォーマンスを出すことが求められています。

制限された状況の中でも、どうしたら常に最大のパフォーマンスが発揮できるか。

軍隊ではどういう風にしていて、それをどうやって今のチーム・組織に活かせるか。私の経験を持ってご提案させていただきます。

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.

あなたのチームはいつ死にますか？

スクラムはチームワークのためのフレームワークです。スクラムでは、安定したチームが成功するための前提条件として紹介されることが多いです。実際に「STABLE TEAM（安定したチーム）」はScrum Patternsの1つになっています。

安定したチームは本当によいチームなのでしょうか？

私たちのチームは、スクラムやモブプログラミングを通して自己組織的なチームになりました。Unlearnを自分たちの活動に組み込んで、学習するチームになりました。スタートアップしたプロダクトも成長軌道に乗せることが出来ました。そしてそのチームは、プロダクトの終焉を乗り越え、さらには会社をも越えました。

• チーム転職できました #チームFA宣言 #完結編 #アフターストーリー

私たちのチームは、Project-BasedでもProduct-Basedでもなく、Team-Based TEAMだったのです。私たちのチームにとってはプロダクトの終焉も転職もチームの死にはつながりませんでした。私たちの考える「STABLE TEAM（安定したチーム）」はSAME TEAM（同じチーム）ではなく、生物のように変化し続けることができるチームです。私たちは会社を越えた後も、変化と向き合い生物的チームを目指して活動を続けています。

あなたのチームはいつ死にますか？

このタフクエスチョンの答えはどの教科書にも載っていません。しかし、チームの死を考えることで、どう生きるかが定まり、どうチーミングすればよいのかが見えてきます。一緒にチームのライフサイクルについて考えてみましょう。

スクラムショーワークショップは、スクラムの説明をショー（寸劇）形式で行うワークショップです。
このワークショップを通じて、参加者はスクラムの基本を体験・学習できます。

スクラムショーワークショップは、yycr2019（アジャイルコーチとスクラムマスターの宴、通称：よなよなコーチングリトリート）で
生み出されたワークショップです。「短い時間でアジャイルを知るようにしてほしい」というニーズに応えるために、最大2時間でアジャイル・スクラムの理解を高められるワークショップをみんなで作りました。
会社の中で展開するために、できるだけ準備が少なく済ませたいという要望にも応えています。

皆さんも、スクラムショーワークショップを実施してみましょう！

紹介動画はこちらから！

詳細はこちらの記事をご参照ください。

UX屋さんは言います「ユーザーテスト（ユーザビリティテスト）は製品の利用品質を目覚ましく向上する」と。でも、専門家に頼むと結構な金額の請求書が届くかもしれませんし、社内でやると結構な手間がかかるかもしれません。結局、まだ「やったことがない」「見たことがない」という人が多いのかもしれません。

そこで、このセッションではスマホアプリを題材にしたユーザーテストを会場で実演します。「実演」と言っても大げさなものではありません。①その場にいる人で、②その場にある機材を使って、③約30分で完了する（ただしセッションは45分）ーーという「即席」スタイルです。

「UXとは？ユーザーテストとは？」という小難しいプレゼンテーションを聞いたり、その分野の本を読んだりするのも悪くありませんが、まずは自分の目で見て、自分で価値を判断してみてはいかがでしょうか。意外と気に入るかもしれませんよ。

はじめに

スクラムチームにテックリード？

「スクラムのロールには定義されていないけど、こういうのは誰がやるのが良いんだろう？」「そもそも、そんな状況ってことは、まだスクラムをやるための準備が整ってないってことなのかな？」って悩むことありませんか？僕はありました。

スクラムに取り組んだ最初のころは「あれー？ここどうしようかな？とりあえず・・・自分でやっとくかな」と思うことが結構ありました。「これでいいのかなぁ？」と不安に思いながらやってましたが、それも5,6年たった今では「あー、うちの組織だと、こういう役割が必要なんだわ。こそこそやらずに、自分の中でテックリードって名前つけて堂々とやっとく方が良さそうだな」って納得してやってます。

スクラムガイドの中には、テックリードというロールは定義されていません。でも僕は、今の組織の中で、このロールがとても大切な役割を果たしているなぁと感じています。大変だけど、やりがいがあって、とても面白いロールです。

こんにちは。椎葉です。楽天株式会社の大阪支社で自社ECサービスのアプリケーションアーキテクトとして仕事をしています。僕が所属している組織では、多くのチームがスクラムを採用しています。その中で、この数年間、僕は改善エンジニアとして「色々なチームに入っていって現場のみんなと一緒に内側から組織の改善をする」という活動をしてきました。その活動の中で学んだのが、テックリードというロールの大切さです。

僕の中のテックリードは、スクラムチームと組織のあいだに立って、技術的な視点に軸足を置きながら、開発やチームや組織を支える。そういう役割です。何かと何かの間におちてしまいそうなものに手をのばして拾い上げたりします：プロダクトオーナーと開発チームのあいだ、開発チームとスクラムマスターのあいだ、スクラムチームと組織のあいだ、そしてマネージャーとスクラムチームのあいだ。など。　

このセッションで伝えたいこと

「僕の組織では、スクラムからは少し外れるかもしれないけど、こういうことをやる必要があって、僕はテックリードとしてこういうことをやってるよ」ということをお伝えしたいと思います。

それによって、これからスクラムに取り組もうとしていたり、既にスクラムを実践しているけど悩んでたりする方々に対して「あぁ、自分も同じようなことで、もやっとしていたけど、そういう風にやってる人もいるんだな」って何かしら参考になるようなセッションにしたいなと思っています。

また、その中で学んだ「テックリードとして考えておくと良いこと」もお伝えします。

今、テックリードとして悩んでいる方や、これからテックリードとしてチームをリードしていく方々に勇気を伝えられるようなセッションにしたいと思います。

サイボウズの事業がオンプレミスからクラウドに移行する中、開発スタイルはウォーターフォールでの指揮統制・分業型からスクラムでの自己組織化・機能横断型に変わりつつあります。そんな状況の中、チームがユーザーにより価値を届けやすくするために職能別部署は解体されチーム主体の新組織になりました。

新組織の狙いは以下の4つです。

• 職能単位での部分最適化ではなく、チーム全体で最適化しやすく
• 従来の職能の枠にとらわれず、個人の多様なスキル・個性を活かしてプロダクトやチームに貢献できるように
• チームに必要なことはチームで意思決定できるように、権限と責任をチームに委譲
• 主体的にキャリアを作れるように異動をカジュアルに

組織変更の中で部長の役割は分割され再割当てされました。採用・予算などはチームに移り、異動は各メンバーに移り、給与評価はそれを受け持つ組織運営チームが新設されました。

組織変更をして8ヶ月、様々な変化が起きました。
どうやって意思決定するか議論するチーム。
どんな人を採用したいか、そもそも人を増やすべきなのかを議論するチーム。
上長がいなくなり色んな人と1on1し始めるメンバー。
活発になる他職能/他チームへのお試し異動。
チーム内でオープンに議論されるようになった問題。

このセッションでは部長がいなくなった組織で起こったことを紹介します。

こんにちは。楽天仙台支社の半谷(はんがい)と申します。
仙台・東京・大阪・福岡にそれぞれ仲間がいる開発組織で、25人くらいのグループのマネージャーをやっています。ベースは仙台ですが、月に2回くらいは東京に行っています。

私達は、楽天市場の開発を行っています。

2019年6月にリリースした新機能開発では、もともと縦割り組織だったビジネス・デザイン・開発のそれぞれのステークホルダをワンチームにまとめ、日々数万店舗様が使ってくれるような顧客満足度の高いものを作ることが出来ました。

この体制を作るのに参考にしたのが、Jeff Pattonさんが提唱している「Product Discovery Team」の考え方でした。このおかげで、ともすると敵対関係みたいになってしまいがちな三者が、顧客に価値を届けるぞ！良いもの作るぞ！と同じ方向を向きつつそれぞれが強みを発揮するようになりました。

もちろん最初からうまくいったわけではなく、色々な書籍や文献、先達の知恵に助けてもらいつつ、もがき苦しんだ結果たまたま発見したものです。なのでセッションの内容は、うまくいったぜ！という過程ではなく、苦労話が多くなると思います。

このセッションが、大企業の中で組織改善に悩むいろんな方々のヒントになったら良いなと思います。私自身もまだまだ悩み中なので、一緒に旨い酒が飲める仲間が出来たら嬉しいです。

現在，大学でプログラミング言語の授業を持っています．

その授業では，文法としてのプログラミングだけでなく，プログラミングの面白さを知ってもらえるもらえるように，モブプログラミングを導入して授業を行なっています．

ところが，企業でのモブプログラミングの導入とはまた違った課題がありました．そして，その解決策として，行動分析学を元にして，試行錯誤をしています．

本セッションでは，その試行錯誤の課程を共有したいと思っています．

----

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.

2018年の11月頃から始まり、開発手法としてScrumを採用したとあるプロジェクトは、2019年の6月に予定通りサービスのローンチを行うことができました。

このプロジェクトはお客さんとのユーザーストーリーマッピングでのMVP検討から始まり、まずはサービスの背骨にあたるMVPの実装を1ヶ月で完了。その後4ヶ月間はリリースできる状態をずっと維持し続けながら、毎スプリント着実に機能を追加していき、ローンチの1ヶ月以上前にはお客さんが希望する機能の追加を完了。ローンチ前にはいくつかのメディアに取り上げられたこともあり、多少注目されながらローンチ当日を迎えましたが、そこでも拍子抜けするほどなんのトラブルも起きず、お客さんからも開発チームからも、これほど安定したプロジェクトは今まで経験したことがないといったようなポジティブなフィードバックをもらうことができました。

その結果、お客さんからの期待値が想定以上に高まってしまい、同じやり方を他の複数プロジェクトにも早急に導入することが決定。開発者を含む関係者が一気に倍増したことで、チームは混乱状態に陥ってしまいました。

今現在も混乱中ですが、RSGT2020が開催される頃までには何とかなってると思うので、私達がこれからどのようにして再び練度の高いチームを作り上げていったかについてお話しできればと考えています。

ScrumPLoPとして2010年から活動してきたスクラムをパターンランゲージとして記述する活動も、2019/8/5現在、最終校正が完了し印刷待ちです無事9/3発売されました。RSGT 2020 には、出版された本を持っていける予定ですいきます。

540ページの大部になってしまったので、ちょっと気軽に手に取るには大きな本になってしまいました。

このセッションでは、A Scrum Book の読み始める方法を、ちょっとした出版までのエピソードなどを含めてお話しできればと思っています。

著者のJim Coplienを発表者に追加しました。