Regional SCRUM GATHERING® Tokyo 2016

講演資料

これまで、SAFe、DADなどのアジャイルをスケールさせる方法論がありましたが、どれも非常に多くのことが定義されていて、スモールチームのアジャイル開発実践者にはかえってハードルが高かったと思います。

最近LeSS、Nexusと多くを定義するのではなく、スクラムのように見える化と改善のミニマムのフレームワークを定義するものが出てきました。

本セッションでは、Bas Voddeが提唱しているLeSS(Large Scale Scrum)と、スクラムの生みの親、Ken Schwaberの、まだ発表されて間もないNexus ガイドの２つをご紹介します。そこには１チームでの成功をスローダウンする事なく、連続的にスケールしていく方法のヒントがあります。

他のスケール手法との比較なども、参加者の方とディスカッションできればと考えています。スケールが必要なプロジェクトでもアジャイル開発を楽しんでいく方法を探しましょう。

Scrumについて知っている事を前提にします。

http://www.scrumguides.org/
https://www.scrum.org/Resources/The-Nexus-Guide
http://less.works/

『どうやって始めて』『どのような変化が起きたのか』　--　チームを影から支える人たちへ

本セッションでは、ちょっとお固い企業でスクラムをはじめたマネージャの視点で、
定期的に感じる失敗感・挫折感を乗り越えて、これからどのような手を打って行こうとしているのか、現在進行形のお話をしたいと思います。

具体的には、マネージャができるチームへの支援や、外部アジャイルコーチの有効性、現場の人たちの戸惑いや変化、グループ企業内で静かにゆっくりと波及しはじめている変化や、ちょっとした対立などを生々しくまとめたものを発表してみたいと思います。

これからスクラムを導入したいと思っているリーダーには前向きな気持を、
リーダーを支える経営層やマネージャーには、変革者やチームへの支援と寛容の気持を持ってもらえるようなセッションが出来たらいいなと思っています。 

 

• 僕たち、見積もり下手だと思ってたけど、意外とそうでもなかったね
• Tシャツだと精度が低いからポイントにしよう！
• スプリントを見比べるとお化けが出る
• 僕たちのヘルスチェック

概要

メトリクス、数値の取得や分析・評価というのは、開発の役に立たず時間を食われるばかりだと、開発チームから忌避されがちです。しかしスクラムチームがス クラムチーム自身のために取得するメトリクスは、チームの状況把握と問題発見に役立ちますし、チーム自身が見てセルフチェックできるものです。本セッショ ンでは、あるスクラムチームのメトリクスを紹介しつつ、なぜ測ることにしたか、測ってどうなったかお伝えします。

The improvement of productivity by Scrum for the "Vietnam engineers" + "non-IT Japan and South Korea human resources" in Vietnam.

●発表資料（SlideShare）
https://www.slideshare.net/secret/JLQCckwK4k8Kkp 

●想定する受講者像

・ベトナム・韓国・日本など、様々な国の方とチームとして働くことに課題・興味がある方

・非IT系ｘIT系の方が一緒に１チームとして働く場合の課題をお持ちの方、そのようなチーム構成に興味がある方

●どのようなものを得られるか

・様々なバックグラウンドや役割を持ったチームメンバーのモチベーションに対する「源泉」や「考え方」の違いを知ることができます。

・この差異を知ることで、異なるバックグラウンドを持ったチームメンバーと一緒に仕事をしていくためのTipsやヒントを得ることができます。

（チーム間の協力方法、バイアスやギャップの縮め方）

・役員や事業長など決済権や最終判断の権限を持つ方に、Scrumの効果を理解してもらった上で組織構造を変える方法（会社規模〜30人くらい）

・自社Serviceに対するScrumの導入方法（会社規模〜30人くらい）

●アジェンダ(進め方)

１，ベトナムって？

２，韓国って？

３，日本って？

４，最小規模案件でScrumを試した結果

５，中規模案件でScrumを試した結果

６，リーダ・チームメンバーへの課題と仕事の進め方のヒアリング

７，そのヒアリングから見えてきた共有課題と仮説

８，社長・事業長へのヒアリングと彼らの気づき

９，チームにScrumMasterとして、参加した結果「わかったこと」や「感じたこと」

１０，自社Serviceの全案件に対して、Scrumを続けることで起きたチームの変化

１１，その結果、改善されたコト

１２，まとめ

ゲームを楽しんでいますか？

ゲームが面白いのは、楽しむ仕組みをいろいろな場所で入れているからです。

しっかりとした全体のストーリーを持ち、各所でのゲームメカニクス・レベルデザインがきちんと抑えられていないと、ゲームはすぐにつまらなくなります。

スクラムでは、自己組織化されたチームを望ましい姿として、メンバーの自由度を高めることを促します。

しかしながら、ゲームでは、単に自由度を高めるだけでは面白いゲームには仕上がりません。

あなたのチームは楽しんでいますか？

本セッションでは、18年間のゲーム業界の開発と、バンダイナムコやグリーでスクラムマスターなどとしてスクラムを導入してきた経験から、ゲーム設計を基にチームの成長を導く方法を検討し、スクラムのフレームワークからあえてはずされているマネージャーについて考えてみます。

教科書とおりのスクラムの勉強を卒業された方に新たな視点をお届けできればと思います。

[登壇資料] http://www.slideshare.net/imagire/ss-57180617 

とあるスマートフォンアプリの開発プロジェクトを通じて、私はCI/CD・TDD・BDDといった自動化の施策に、以下の３つの可能性があるという考えに至りました。

1. 業務の効率化
2. チームメンバーやステークホルダーらとの良好な関係の構築
3. チームの学習と成長

私はこの考え方を「Technology-Driven Development」と名付け、実務でも活用しています。現場での試行錯誤を通じて得たアジャイル・スクラムの実践知の１つを紹介させていただければと思います。

[参考]

1) Slideshare

http://www.slideshare.net/ssuser968fab/technology-drivendevelopment-forslideshare-38323907

2) 論文

http://www.agilealliance.org/files/5014/0509/9284/ExperienceReport.2014.Ito.pdf

Cisco is changing the way Cisco does business through Continuous Delivery and Scaled Scrum.  We would like to share how we have moved a $40B enterprise of 25,000 engineers across the globe from 100% waterfall based delivery to scrum delivery in a massive scale.

Today, a strong partnership with the business and increased collaboration is driving delivery of new business outcomes faster.  However, our journey started over 3 years back and was a gradual, and still on-going, evolution of mobilizing the agile transformation, strategically and tactically.  We started with a strong executive leadership's desire on the recognition of inevitable need for a change in the way we enabled business capabilities, from waterfall based 6 to 9 months delivery cycles to agile incremental weekly and monthly delivery capabilities.  We experienced our share of challenges, from just getting started to organically creating the critical core of passionate agile leaders throughout the enterprise.

Let us share how we organized and created the momentum, and also overcame various challenges along the way, from getting beyond the long standing cultural resistance to a practical matter of scaling scrum from ground zero via strategic planning and systematic execution across globally distributed organizations throughout Cisco.  

巨大企業Microsoftがなぜ、そしてどのようにScrumを導入していったのか？サービスリリース日に直面した失敗と学び、そしてその後のチーム学びと進化を、人・プロセス・技術の面から生々しくレポートしたいと思います。全世界にまたがったグローバルチーム開発、グローバル分散環境のデプロイメント戦略、プロダクションからの学び、テレメトリ戦略、DevOpsへの旅まで具体的にお話しいたします。 

近年突然インパクトある製品やサービスを生み出すことができるようになったMicrosoftは何故変わることが出来たのでしょうか？その秘密を公開いたします。  

本公演はAgile conference 2014でキーノートを務めたSam Guckenheimer氏が講演したプロジェクトの内容から更に進化した現在の姿を日本語で聞ける貴重な機会になっています。ぜひお楽しみください！

当日のプレゼンテーション https://docs.com/ushio-tsuyoshi/7001/microsoftscrum7devops 

Agile 2014のキーノート

Journey to Cloud Cadence - Sam Gukenheimer

http://agile2014.agilealliance.org/program/

Rakuten and Microsoft talk DevOps in Real world.

http://www.slideshare.net/TsuyoshiUshio/rakuten-and-microsoft-talk-devops-in-real-world

DevOps Enterprise 2015 Sam Guckenheimer - Visual Studio Online: The Inside Story from COTS to Cloud

https://www.youtube.com/watch?v=-3uSiHO22tc

【講演後アップデート】
当日の資料は下記です。
 ■Slide Share
http://www.slideshare.net/RyotaInaba/sgt2016agile

■前提

・キャリアとは不確実性に富み、不確実性を受け入れる間口を持つことが『機会』である
・キャリアは、ライフプランやステージの変化によりその形を変え、プランには多様性がある
・Agile/Scrum人材の姿勢は銃士の姿勢であり、壁を作らず状況に応じて適宜適切に対応すべき

 ■課題認識
・多くの会社では未だに、期首に目標を立て期末に評価するような、不確実性や流動性を前提としない評価をしていないでしょうか？
・多くの会社では未だに、「プログラマ⇒設計者⇒コンサル⇒管理者」と、キャリアパスが1本になってはいないでしょうか？
・メンバの評価がプロジェクトの売り上げベースで左右され、能力と実績が混同されていないでしょうか？

 ■語りたいこと
・人事制度の多くは「うちは特別だから」「うちはこのやり方が適してるから」「今までこうだからこう決まっている」と言う論理的ではない考え方で硬直することが多いと思います。
・しかし、不適切・不整合・不当な、評価や処遇やキャリアパスは人材を殺し離れさせます。
・万全の目標管理に出会える可能性は万全のウォーターフォールに出会える可能性と近い。
・一本道しかないキャリアパスを是とすることは、一番はじめに引いたWBSを最後まで信じることに近い
・やってきたことが正当に報われ、これからやりたいことがパスとして存在する、そんな当たりまえのことが少しでも多くの人材の幸せに少しでもつながると思います。
・本セッションで、IT導入現場を知るキャリアコンサルタントとして、評価とキャリアに関しての考え方を提示し、今後の在り方に関して皆様と考えていけたらと思います。

 ■受講対象者
・IT企業の人事部様（人事制度・評価制度の企画、運用担当部門)
・評価者、部門で人材育成・配置を担う方（または予定者）
・その他、キャリアや評価に興味がある方ならどなたでも歓迎

 ■本セッションで得られること
・IT企業全般、特にAgile/Scrumを実践、または今後予定されている企業でよく用いられているが「ヨクナイ」評価制度とキャリアパスの考え方とその理由の気づきを得られる
・評価とは？キャリアとは？の考え方の肚落ち感を得ることで、自社での評価方法、キャリアパスの改善材料を肌感覚で得られる

■講演資料をアップロードしました
http://www.slideshare.net/aratafuji/ss-57219506

ーーーーー
フィリピンのスタートアップにスクラムを導入しようとしてみた事例を紹介します。

「スクラムの導入をサポートして欲しい」という依頼をうけて、2015年10月中旬から4週間フィリピンに行ってスクラムの導入にチャレンジしてきました。

英語をほとんど話せない私がフィリピン、インドネシア、韓国、日本の多国籍チームに対してどのようにアプローチし、何を行ない、その結果どうなったのか。
実施したことを時系列にそって、またアイデアを組織に広めるためのパターンである「Fearless Change パターン」の観点からも整理して、お話したいと思います。

■アジェンダ(仮)

・環境、ミッション
        ・場所 : フィリピン ボニファシオ・グローバル・シティ
        ・会社 : YOYO Holdings
        ・期間 : 4週間
        ・チーム：フィリピン、インドネシア、韓国、日本
        ・ミッション：「スクラムの導入をサポートして欲しい」
・各週で実施したこと
        ・渡航前〜4週目
・プロジェクトの現状
・現場からのフィードバック
        ・良かった点
        ・まだまだな点
・まとめ
        ・やったこと整理
                ・パターンで整理
                ・パターン以外の知見
        ・自己採点
        ・スクラムできた？
        ・所感

※参考までに、現地のリクルーティングイベントで発表したスライドはこちら。

http://www.slideshare.net/aratafuji/is-scrum-the-best-choice-for-you

【プレゼンテーション資料】
http://www.slideshare.net/MinoruYokomichi/ss-57211075

【概要】
あなたの開発チームには、だれもやりたがらない仕事を率先して引き受けてくれたり、落ちているボールを積極的に拾ってくれるような、「いい人」はいますか？
言われなければ気が付かないけど、誰かがやってくれているからチームがうまくいっている「雪かき」のような仕事が存在します。
そして、そういった仕事をやっている「いい人」が知らぬうちにすり減ってしまうケースが意外に多く存在するのかもしれません。

とある開発チームの事例と変革をベースに、以下をお話します

- 開発チームにおける「いい人」とは
- 「いい人」が陥りがちな問題
- 「いい人」がチームに生み出す負のスパイラル
- 「いい人」のかけがえない価値
- 「雪かき」を分類する
- チームにおける「雪かき」の平準化方法
- OKR を用いたチームマネジメント
- 「いい人」のひとつのキャリア

【想定する受講者層】
- チームやチームメンバーのコンディションをケアしているスクラムマスタ、マネージャ
- まだ熟達していない開発チームに関わるスクラムマスター
- 日頃「損を見ているかも・・・」と感じている「いい人」
- チームマネジメント、ピープルマネジメント、OKR などに 興味のある方

【何を得てほしいか】
- 「いい人」がスポイルされないチーム運営とマネジメント方法
- 皆で「いい人」を再評価しましょう！

「アジャイルってなんだか流行ってるけど、ソフトウェアの品質保証ってどうやるのか。品質保証部門はどうアジャイルに関われば良いのか。」アジャイル宣言にもその背後の１２の原則にも、「品質」という言葉は一切出てきません。アジャイルの時代において、品質保証部門はもはや用済みなのでしょうか。

アジャイル、DevOpsの時代における品質保証部門の存在意義とは何か、どんな取り組みをしていくべきなのか。DevOpsならぬ"DevSQA"の提案と共にお話しさせていただきます。

 http://www.slideshare.net/hiroakimats/devsqa

当社（ニッセイ情報テクノロジー株式会社）は、生命保険分野を中心として、様々な生保、銀行向けのシステムをウォーターフォールで開発してきました。

このような当社が、今回新規ソリューション開発において、初めてアジャイル開発にチャレンジしており、その中での具体的な取組み内容や、工夫したことをご紹介いたします。

通常のウォーターフォールプロジェクトでは、ＥＶＭによる進捗管理、メトリクスによる定量的な品質評価が当たり前の世界の中で、アジャイル開発ではどのように進捗の定量報告、品質担保、品質評価をしていったかなど、試行錯誤しながら取組んだ施策をご説明いたします。

【アジェンダ】

・導入／立上げプロセスとポイント

－ＷＦ前提の社内標準開発ルールからの逸脱の調整

－社内の管理部門との合意（リスク管理、品質生産管理部門）

－ファシリティ

－スクラムコーチの活用

・ＫＰＴによるプロセス、運営改善の具体的例と効果

－デイリーミーティングでの工夫

－ホワイトボードの活用方法

－チームメンバーの発信力の工夫

－楽しくわくわく進める工夫　　　　　など

・進捗管理

－プロジェクト全体の進捗定量管理

－スプリント内の進捗定量管理

・品質管理とテストツール

－品質評価方法

－品質を担保するためのテストツールの活用

・スクラムの効果と今後の展開

開発以外のチーム（営業・販売促進・受託事業）でスクラムを実践した中ででてきた、良かったことと難しかったこと、開発以外に適用させるための工夫を報告します。

当日使用した講演資料はこちらです。
http://www.slideshare.net/tomoyasuishii/ss-57247754 

【アジェンダ】

* 導入したプロジェクトの背景

* 実践したプラクティス

* 効果/メンバーからの反応

* 課題と改善案

【想定する受講者像】

* スクラム実践に興味がある非開発者

* 営業や企画等のチームにスクラムを導入してみたい方

【どのようなものを得られるか】

* 通常の開発おけるスクラム実践と異なるポイント

* 開発以外のチームでのスクラムの型としての実践例

* 非開発者（営業担当、マーケター等）のスクラムへの反応

Product owner, in order to determine the services or products that the customer is really necessary, and not the experience or intuition, ability to think logically is required. In, the services and products the customer is really necessary, to think logically, what do I?

The customer, when using the product or service, we have some hope (prior expectations). For this pre-expectations, and those of "performance evaluation" after products and services available is large, the customer will look like you are able to repeat and happy. Customer satisfaction, than the outcome of the service, determined by the goodness of the process.

In this session, the axis the concept of service science, the relationship between the customer and the service in the scrum, we will introduce how should be organized.

----

プロダクトオーナーは、顧客が本当に必要としているサービスやプロダクトを見極めるために、経験や勘ではなく、論理的に考える力が求められています。では、顧客が本当に必要としているサービスやプロダクトを、論理的に考えるには、どうすればいいのでしょうか。

顧客は、プロダクトやサービスを利用する際に、なんらかの期待（事前期待）を持っています。この事前期待に対して、プロダクトやサービス利用後の「実績評価」の方が大きいと、そのお客様は満足してリピートしていただけるようになります。顧客満足は、サービスの成果より、プロセスの良さで決まります。

本セッションでは、サービスサイエンスという考え方を軸に、スクラムにおける顧客とサービスの関係を、どのように整理すればよいか紹介します。