『教育心理学概論』という書籍があるのはご存じかなと思います。この書籍を書いた三宅なほみ先生は1986年に発表した博士論文"Constructive interaction and the Iterative Process of Understanding" (通称「ボビンの論文」) で、ペア作業の観察を通じて、理解というものはなにか？複雑な問題をペア作業によってどのように進めていくのか？に迫りました。「建設的相互作用」を提案した論文として多くの影響を与えているそうです。

スクラムの源流が80年代の製造業のプロダクト開発を観察した1986年の論文 "The New New Product Development Game" にあることはもちろんご存じですよね。この論文については、スクフェス大阪で読みました。https://confengine.com/conferences/scrum-fest-osaka-2021/proposal/15403/the-new-new-product-development-game

２つの日本人による論文が同年に出ていることは全くの偶然ですが、異なるアプローチで人間の協調作業に迫っていることが興味深いです。

本セッションでは、「ボビンの論文」と「The new new product development」を機械翻訳をかけながら読んだ経験を振り返り、理解とは何か、組織にとって必要な小グループ活動、ペア作業の効果に関して議論していきたいと思います。また、普段モブプロをやられている方や、ファシリテーションに取り組まれている方にとって、人間の意識がどうなっているかがわからないのは悩みのタネであろうと思います。そうした方にも気づきがあるのではないかと思います。

Scrum Fest OSAKAの「mogiriちゃん」の記憶冷めやらぬ昨今。
モブプロでなんかいじりたいという邪な気持ちだけでプロポーザルを書いています。
世の中のモブプロの理解が全く間違っていると感じる昨今。
本当のモブプロをここでお伝えしたい！その気持ちだけでこのセッションを設計しています。
昨年、大好評を博したイキトメモブプロに続き、ついに第二弾をお届けします。

お待たせしました。いや、お待たせしすぎたかもしれません。
全裸監督2、いや全力でやります。
ちなみにメインスピーカーの村林は新婚のため参加できません。前代未聞。

XP祭り初のビブリオバトルで川鯉さんが優勝した『教育心理学概論』という書籍があるのはご存じかなと思います。この書籍を書いた三宅なほみ先生は1986年に発表した博士論文"Constructive interaction and the Iterative Process of Understanding" (通称「ボビンの論文」) で、ペア作業の観察を通じて、理解というものはなにか？複雑な問題をペア作業によってどのように進めていくのか？に迫りました。「建設的相互作用」を提案した論文として多くの影響を与えているそうです。

スクラムの源流が80年代の製造業のプロダクト開発を観察した1986年の論文 "The New New Product Development Game" にあることはもちろんご存じですよね。この論文については、スクフェス大阪で読みました。https://confengine.com/conferences/scrum-fest-osaka-2021/proposal/15403/the-new-new-product-development-game

２つの日本人による論文が同年に出ていることは全くの偶然ですが、異なるアプローチで人間の協調作業に迫っていることが興味深いです。

本セッションでは、「ボビンの論文」を機械翻訳をかけながら読むことを通じて、理解とは何か、ペア作業の効果に関する新しい視点を得ることを目標にしたいと思います。また、普段モブプロをやられている方や、ファシリテーションに取り組まれている方にとって、人間の意識がどうなっているかがわからないのは悩みのタネであろうと思います。そうした方にも気づきがあるのではないかと思います。

事前の準備は不要ですのでさらっと来ていただければと思います。

※本セッションはアギレルゴコンサルティング株式会社のスポンサーセッションとして提案するものです。

皆さんは、スクラムの源流が80年代の製造業のプロダクト開発を観察した論文 "The New New Product Development Game" にあることはもちろんご存じですよね。そこにどんなことが書いてあったか、知りたいと思いませんか？現在論文は無料で Harvard Business Review サイトで公開されているので、誰でも読めるのですが、英語なのでちょっとハードル高いですよね。一緒にみんなで機械翻訳かけながら読んでみませんか？

昨年の Scrum Fest Osaka 2020 @ Online から、カンファレンスの参加者の交流やさまざまな連絡にDiscordを使うようになりました。それからいくつかのカンファレンスで使ってきたのですが、スタッフ側でちょっと頭の痛い作業が「受付」です。

もちろんリアルのカンファレンスでも結構大変で、長年頭を悩ませてきたのですが、Eventbriteのアプリの出来がいいのが救いでした。しかし、Discordの受付にはそれが使えず、しぶしぶGoogle Spreadsheetを使いながら、スタッフがポチポチ確認作業をするということをしてきました。

それから約一年たちまして、さすがに運用も安定してきましたし、DiscordのボットとEventbriteのAPIを使って、自動化をやってみようかなということで、やってみました。プログラムとしては大したことはないですし、うれしいのもほとんどスタッフだけですし、これといった感動する苦労話もないのですが、こんな話を聞いてもらえるのもスクフェス大阪くらいかなと思い、プロポーザルを書いてみます。

mogiri
https://github.com/kawaguti/mogiri

この小さなアプリを、どのように維持したり、育てて行ったらいいか、皆さんをご意見やご示唆をいただければ幸いです。

本セッションでは、ゲーム制作会社で１メンバーとして新しい取り組みをしていくために重要なソフトスキルについて学びます。

まずは、第一歩として、個人からできるコミュニケーションの改善について学んでみましょう。

1. 修羅の国でのコミュニケーション入門 - 自分は悪くない、から脱却しよう
2. 過激な反応で関係を壊してしまう前に - Emotional Science
3. リモートワークは効果も問題も拡張する
4. 責任に目を向ける - 責任逃れの構図
5. チームの４つの毒
6. アジャイル戦略論 - 何かを始めるときの6つのステップ

DevOpsDays Tokyo もあと2セッションを残すのみとなりました。
先進的な事例から、これからやっていきたいことまで、幅広くご共有いただきました。

どんな組織にもそれぞれ独自の環境があり、皆さん考えながら一歩ずつ取り組みを進められているのが印象的でした。
また、技術プラクティスからテストや品質、さらには組織変革まで、DevOpsが含む領域の幅広さを感じました。

本セッションでは、いくつかのセッションでも語られた、リーンコーヒー形式での雑談を実際にやってみたいと思います。

付箋に話したいトピックを書いていただき、5分ずつ、あるトークテーマで話していきます。
会場とオンラインとどちらからでも話していただきたいと考えています。

※本セッションはアギレルゴコンサルティング株式会社のスポンサーセッションとして提案しています。

皆さんにとってDevOpsってなんですか？デプロイの自動化ですか？インフラストラクチャー・アズ・コード(IaC)ですか？運用部門と開発部門が共通言語をもって協力し合うことですか？SlackでChatOpsですか？テスト自動化ですか？全社でフィードバックを短期化することですか？

DevOpsは、写真共有サイトのFlickr社の人たちが発表したスライドが一つの源流です。
https://www.slideshare.net/jallspaw/10-deploys-per-day-dev-and-ops-cooperation-at-flickr

これにインスパイアされた Patric Debois さんたちが、DevOpsDaysを始めたそうです。もともと考えていたアイデアはシステム管理者のためのカンファレンスだったとか。(詳しくは基調講演で)

これに影響を及ぼしているのが、当時ThoughtWorks(当時)の Jez Humble さんの「Continuous Delivery 継続的デリバリー」です。

また、概念を会社全体のビジネスに広げ、いまでいうDXをうたっているのが Gene Kim さんの「Phoenix Project」でした。

Microsoft(当時) の Sam Guckenheimer さんはAgile 2014 の基調講演で、「Microsoft's Journey to Cloud Cadence 」で、同社が行ったシステム開発全体の近代化の中で、多くのDevOps/技術プラクティスを取り上げ、アジャイルに取り組む企業が進む先としての一つの像を整理し、現在の「Azure DevOps」や「Github Actions」プロファクトにつながっています。

こうしてDevOpsは、インフラの自動化、コーディングプラクティスの普及、フィードバックサイクルの短縮化、それらにともなうビジネスや組織体制の変革、を取り込みながら広がってきました。

本セッションでは、そうしたDevOpsの背景と広がりを整理します。

さらに、任天堂「ゼルダの伝説 Breath of the Wild」、東宝「シン・ゴジラ」、ポリゴンピクチュアズのアニメ制作過程など、コンテンツ業界での制作過程の変化なども織り交ぜながら、私たちにできそうなことはなにか、探っていきたいと考えています。

主催者として、どうして、アジャイルテスティング研修、アジャイルリーダーシップ研修、情熱プロダクトリーダーシップ研修を企画しているかについても紹介できればと考えています。

※本セッションはアギレルゴコンサルティング株式会社のスポンサーセッションです。

コロナ禍で、私たちも研修をオンライン開催する必要に迫られました。
時差、同時通訳、Zoomの扱いなど、様々な技術要素を学んできましたので、本セッションではそのお話をしたいと思います。
アギレルゴコンサルティングのオンライン研修、スクラムフェス大阪、スクラムフェス三河、スクラムフェス札幌、
品川アジャイルでの活動を経て、RSGTのハイブリッド開催は行われています。

技術的な背景と、プロダクトとしての考え方を話してみたいと思います。

『The Great ScrumMaster』を翻訳したチームが発足したのは2019年4月のことです。住む地域も異なる9人が、Facebookをきっかけに翻訳するために集まり、コロケーションでのモブがなかなかうまくいかないところから、実験を繰り返しながら、徐々に持続性の高いモブ作業をリモートで確立するに至りました。もしかしたらこれは自分たちがそう考えているだけで大したことがない話なのかもしれませんが、そのあとで世界を襲ったCOVID-19の中でも、この知見と身に着けた感覚は有効だったと考えています。今後も同様の形式の翻訳を進めていきたいと考えておりますので、どの辺がよかったのか、みなさんに聴いていただいて、フィードバックをいただければと思います。

おかげさまで書籍の方も「読みやすい」というご意見を多くいただきまして、リリース版での誤りの訂正も今のところ一箇所のみです。品質も高められたかなと思います。

このセッションは、フルタイムでもなければ地域も近くない私たちが、普通のリモートモブに達した軌跡を共有し、普通のリモートモブの姿を提言します。これが唯一の正解でもないですし、私たちも発展途上なので、ぜひ様々なフィードバックがいただければ幸いです。

SCRUMMASTER THE BOOKの中には、たくさんのエクササイズが載っています。

書籍に載っているエクササイズってなかなか一人ではできなかったりしますよね？

でも実際に、現場でエクササイズを導入する前には、試しておきたいですよね。

そんな、あなたにSCRUMMASTER THE BOOKの訳者陣と一緒にエクササイズを試してみませんか？

ケーススタディとしても書かれた、米国バージニア州のFederal National Mortgage Corporation（米国連邦住宅抵当公庫、通称Fannie Mae）でのSAFe導入。その立ち上げにほぼ最初から携わった「プロジェクト開始から初めて一か月以上もった」シニアスクラムマスター・アジャイルコーチが語る裏話。　

5か月という短期間で、8スクラムチームをコアとした合計130人以上からなるAgile Release Train (ART) ローンチの実用化に貢献するという貴重な経験を得た反面、新しいスクラムチームの立ち上げ、それに伴う新スクラムマスターのオンボーディング、チームのコーチング等と次から次へと湧いて出てくるタスクを黙々とこなす怒涛の毎日。　三河の話題も含めながら、川口さんと対話式で「今なら笑って話せる」苦労話をお届けします。

Disclaimer

このトークで示した見解はすべて演者個人の見解であり、 演者の所属する組織及びFannie Maeとしての見解を示すものではありません。

「ボトムアップでのアジャイルチームづくりは、どうしたらよいか？」
「アジャイルチームを作ったものの、なかなかその先に進まない」
「顧客要望やトップダウン指示で、アジャイルチームを早急に作り成果を求められているが何から始めたらよいか、わからない」
こうしたご質問を数多くいただくようになりました。日本企業の経営層から開発エンジニアまで、みんな悩んでいるみたいです。

みなさんご存じの通り、アジャイルにおけるマネジメントの基礎は、チームにあります。チームがなければ、ベロシティも測れないし、見積もりもできないし、デリバリーできません。しかし、いまだに、作るものが決まって、予算が取れてから人をかき集めるプロジェクトが後を絶ちません。どうやって調達・開発するのかが決まっていないのに、なぜか金額や期間は決まってしまう。

まあ日本人、子供のころからチームチーム刷り込まれてますし、集まれば仲良くやることには長けてます。なんとかしますよ。大人ですし。

「うちの会社にいる人間はまじめな奴が多いから、
　チームというのは勝手に集まればできるもので、
　まあ、よいチームを作るためにワークショップでもして、親睦を深めたらいい」
....などと、簡単に思っているマネージャーも結構多いのではないかと思います。

ち・がーーーーーーう。

そんな風にしたって、簡単にはうまくいかないこと、みんな体験してますよね？
小学校の掃除の班でケンカが絶えない。遠足のグループ活動が楽しくない。
あいつの言うことが納得できない。一人でやった方が仕事が早い。
特定の人が仕事のほとんどを背負って周りは動けてない。
うまくできない人がいるけど十分に教える余裕がない。

私たちのチーム作りは失敗の連続。
でも仕方ない。人間関係って難しいから。
私一人が我慢すればよいのだ。
...いつもそうやって、うまくいかないことに蓋をして、めんどくさいことを先送りしようとします。

じゃあ、どうやってチームを作るのか？
本セッションでは、ここに答えていこうと思います。

大企業から中小企業まで経験を持つ、アジャイルコーチ三人衆が、それぞれの経験から話をしていきます。
チーム作りの各段階で、どんなことを考えながら作っていくのか、参考になる話もならない話もあると思いますが、
参考になるところだけ持って帰っていただければと思います。

チーム作りのプロセス

1. 一人目の仲間を作る
2. 話し合いながらアウトプットする
3. ものの置き場を確保する
4. 成果をアピールする
5. やったことをふりかえる
6. 技術的負債を解消する

7月に漫画最終回を迎えた「ハイキュー!! がアジャイル方面のコミュニティでもじわじわと盛り上がってきています。チームの成長の物語であり、個人がチームや自分の実力・振る舞いとどのように対峙するかを丁寧に描く作品に、多くの人が共感と学びを感じています。バレーボールのルールを知らなくても大丈夫。6人で強い方が強い。ハイキュー!! の物語を通じて、チームで業績を上げる方法について考えてみましょう。

田原の出身なのですが高校は豊橋に通ってまして、バレーボール部の部員でした。といっても、大した運動能力もなくずっと補欠で楽しくやっていたのですが、先輩方から様々なことを学ばせていただいた気がします。出場選手6人だけでない周りを含めたチームの動き方は、そこで学んだんじゃないかと思います。そのあと、企業ITの道に進んだり、スクラムに出会ったりする中で、Production IG制作であるところのアニメ「ハイキュー!!」、そして原作の漫画に出会うわけです。

早く行きたければ、ひとりで行け。
遠くまで行きたければ、みんなで行け。

プロダクトをちゃんと作り、育てていくために必要なものは何でしょうか？
ビジョンや現実的なロードマップ、MVPや顧客仮設の検証はもちろんとして、プロダクトチームを育てていく必要があるんじゃないかと思います。
近くに行きたいなら一人で行け、遠くまで行きたいなら、みんなで行け。

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

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

発表者は、黒田樹さん(リクルートテクノロジーズ)、絹川達也さん(楽天)、横道稔さん(LINE)。いずれもご本人が新規サービス/事業を手掛けるだけでなく、仕組みづくりや組織づくり、メンタリングなども携わられてきたみなさまです。

息が止まるほど、熱い "モブ・リファクタリング" します!!

品川アジャイルでは、毎週水曜日に集まって勉強会をしています。
リモートモブでリファクタリング本の一章の写経を繰り返したり、
リファクタリングやテストツールをみんなで試したりしています。

今回は、その中で一番楽しい、リモートモブリファクタリングを
皆さんを交えて体験していきます。

TDDのワークショップと違い、機能の追加をせず、現状のコードを
「グリーンを維持したままで」手直ししていきます。
もしレッドになったら、息を止めてグリーンに戻します。
(「イキトメ」メソッド)

前半は、Codespaces を使ったモブプログラミング & リファクタリングの演舞。
後半は、飛び入り参加の方を交えて一緒に体験するワークショップとなります。

モブでやりますので、ドライバーは周りの指示を受けて入力するだけ。
プログラミングに自信がなくても、キーボードが打てればご参加可能です。
コードを継続的にメンテナンス可能にする、リファクタリングの世界へようこそ！

※VSCode と Live Share Extention Packコンポーネントを事前にインストールしておいていただけるとスムーズです。

コロナウィルス問題に伴う社会情勢により、残念ながら開催できなかったDevOpsDays Tokyo2020ですが、私たちは来年4月の開催に向けて既に動き始めています。
今回はこのスクラムフェス大阪の場を使って、2021年の開催に向けてのKick Offミーティングを公開でおこないます。

開催に向けてのスケジュール的なことから、キーノートスピーカーの選定、金銭面のことまで、包み隠さず公開で議論を致します。
カンファレンス運営の裏側が気になる方にとっては、またとない機会になることかと思います。

議論にぜひ参加したいという方も大歓迎です。
気軽な気持ちでぜひ覗いてみてください。
2021年に向けての最高のKick Offの瞬間を皆様と迎えられることを楽しみにしております！

DevOpsDays Tokyoとは…
DevOpsDays Tokyoは毎年4月に、日本語と海外スピーカーによる英語の2トラックで開催される、日本国内で参加ができる国際カンファレンスです。
DevOpsDaysは東京以外にも世界中の60以上の都市で自発的に開催されています。
ソフトウェア開発、ITインフラ運用、そしてその境界線上にあるトピックをカバーし、特にDevOpsを実現するための自動化、テスト、セキュリティ、組織文化にフォーカスします。​

IT技術を駆使して変化に強いビジネスインフラを実現するスキルを身に着けるために、国内外の最先端の事例とプラクティスを結集します。
海外から第一人者を直接招き、ここでしか手に入らない最新情報をリアルタイムで入手出来ます。​

最先端のテクノロジの活用法はもちろん、先進企業で必要とされてきた背景までも理解し、正しく組織内に展開するための洗練された知見を得られます。

このイベントが日本のみならず、世界のDevOpsプラクティスを共有できる、意義のあるイベントになれるよう、願っております。

ドイツのポツダムで毎年開催されるAgile Tesing Days 2019に参加してきましたので、フィードバック会として参加者たちのパネルディスカッションを行いたいです。

海外カンファレンスの「フェス感」が伝えられることを最大のゴールにしてます！

技術を学ぶ時、何をしますか？
本を読んだり講演を聞いたりしても読んだり聞いたりした話では実感が湧きません。

「チームの成長」とは簡単にはいかないもの。
でも、チーム内でちょっとしたスキル差から師匠と弟子として一緒に作業すればコトバ以上に伝わるものがあります。

今回、そのような学びの場を『リファクタリング第2版』を写経で得たエッセンスを、オンラインのモブプログラミングでリファクタリングで実演します。

新型コロナによるこのオンライン環境で、チームの活動方法に困っている方、モブプログラミングする方法を知りたい方、チーム力を上げたい方など、わたしたちのモブプログラミングからそのコツを学び取ってください。

実践概要

• Visual Studio Codespacesによるコードの共同編集
• モブプログラミング
• リファクタリング第2版を写経して学んだ技術の実践
• コードを破壊せず、テストがグリーンのまま行うコード改善方法

たのしいでっせ