スクフェス大阪のオンサイトの端っこを借りて、現地からずっと配信し続けます。
こんな感じで・・・は出来ないかもだけど、iPad駆使して配信したいと思います。

品川アジャイルの人が雑談してたり、
オンサイトやオンラインにいる各地域のスクフェスオーガナイザーの人と雑談してたり、
近々行われたスクラムフェスや、これから行われるスクフェスの裏話や苦労話を聞いていたり、
セッションを見ながら雑談してたりできるといいなぁと思っています。

あとはDiscordとかのコメントを拾ったりできるといいなぁ。

NINNOの一室を借りて、現地からずっと配信し続けます。こんな感じで

品川アジャイルの人が雑談してたり、
オンサイトにいる参加者登壇者の人が雑談してたり、
セッションを見ながら雑談してたり、
登壇者が意気込みを語ったり、
登壇を終えた人が感想を語ったりなどができるといいなぁと思っています。

あとはDiscordとかのコメントを拾ったりできるといいなぁ。

アジャイルでモダンな組織を作っていくうえで、テストに関する考え方は極めて重要になると思います。もし、要件定義、開発、テスト(品質保証)をそれぞれ別のチームで行っている場合は、根本的な体制の組み直しが必要になると思います。

その際に、突きつけられ、迷子になりがちなのが「我々はなぜテストをするのか？」という問いです。独立していたQA担当をチーム内に入れるべきなのか？開発者自身がテストをするべきなのか？POやPdMがテスト項目を記述すべきなのか？組織的にはさまざまな問いがあるだろうと思いますが、おそらく自分たちの文脈において「我々はなぜテストをするのか？」を考えられないと、ただ組織を組み替えて、足りない部分を誰かに押し付けて終わってしまうのではないかと思います。

最近、３つの講演に出会いました。KANOメソッドで有名な狩野紀昭先生による、日科技連の歴史を振り返る講演、Jonathan Rasmusson氏による Spotify などのユニコーン企業でのテストについての講演、それから BDDの提唱者である Dan North 氏による BDD is not Testing です。このセッションでは、この三つの講演から、「我々はなぜテストするのか？」について、考え直してみたいと思います。

なにぶんテスト専門家でもありませんので、みなさんに十分な知見をお届けできるかわからないのですが、議論のきっかけになれば幸いですし、間違っているところがあればご指摘いただければ幸いです。

一応、私の実務者としてのバックグラウンドはこんな感じです。もうだいぶ時間たってしまったので、あんま意味ないかもしれませんが。

• 社会人になって、私が最初に配属された部門は「情報部門」というところでした。データを作る部門、という感じですが、主な仕事は、アナログな情報のデータ化でした。ファックスや印刷物、メールなどで飛び交う情報の特定部分を抽出して、ちゃんと整理してデータベースに入れる仕事です。ここで行われるテストは、入力した情報が間違っていないかどうかの、２～３重の確認でした。これを間違えると、重要な経済指標の算出が間違ってしまい、しかもそれ以降の計算も間違っていくので、とても重要な仕事でした。間違いが許されない。
• その次に携わったのは、そうしたデータを入力するシステムの開発です。人々が間違った情報を入力してしまわないように、見比ベることを容易にしたり、振り返って直せるようにするための仕組みです。ユーザビリティを高める必要がありました。
• そして、数年後には、もっと複雑な仕組みに携わるようになりました。リアルタイムデータ。取引情報をリアルタイムに表示する仕組みで、これをどうやって間違わないように行うのか？パターン無限にあるやん。また、さまざまなクライアントでそれをきちんと再現するにはどうしたらいいのか？さらに問題が起きたときに情報を収集する仕組みを作る必要がありました。
• 最後にやったのが、サーバインフラに、間違わずに環境を届ける仕事です。システムそのものの正規の状態を作り上げ、それを間違わずにデプロイによって複製する仕組みです。しかも、そのあとは動いているシステム同士が間違っていないことを確認し続ける必要があり、問題がある場合は、問題が起こる前のサーバー状態と入れ替えて再生する必要があります。

昨年の DevOpsDays 創始者 Patrick Debois さんのトークでも触れられた、DevOpsという言葉ができるきっかけになった2009年の講演「10+ Deploys per Day」をとりあげます。その講演で何が語られたのか？について、短い時間でお伝えすることはしてきたのですが、今回は時間をちゃんと使って、話してみたいと思います。

このトークの周辺の事情については私の過去のトークで、私の整理をお伝えしてきましたが、今回はこのセッションそのものをお伝えしまーす。

DevOpsの時代
https://speakerdeck.com/kawaguti/age-of-devops

アジャイルとDevOps
https://www.slideshare.net/kawaguti/agile-and-devops

10+ deploys per day (動画)
https://www.youtube.com/watch?v=LdOe18KhtT4

10+ deploys per day (スライド)
https://www.slideshare.net/jallspaw/10-deploys-per-day-dev-and-ops-cooperation-at-flickr

2011年、スクラムの父、Jeff Sutherland 博士を日本に初めて招いて「イノベーションスプリント2011」を行いました。そこで行われた講演が "Roots of Scrum" でした。残念ながら撮影まで手が回らず、ビデオが残っていません。スクラムはどこから来たのか、日本から何位を学んだのか、多くの示唆のある講演だったと記憶しています。

スクラムは実践と学びを繰り返し、スクラムガイドが作られ、アップデートが繰り返されています。多くの実践者が書籍を出し、保管できなアイデアで貢献してきました。しかし、スクラムガイドでは語られない源流とストーリーがあります。

2005年に行われたカンファレンスで、 "Roots of Scrum" のビデオが公開されています。現在見ても、多くの示唆がありますし、もしかしたら多くの人はまだこれを見ていないのかもしれない、と思うところがあります。

そこで、この60分の講演ビデオの内容を、できるだけ多く、日本語で伝えなおしたいと思います。

オリジナルサイトより
https://www.infoq.com/presentations/The-Roots-of-Scrum/

スクラムの生みの親であるジェフ・サザーランド博士は、60分のJAOO2005講演で、スクラムの創始から、ケン・シュウェーバーとともにスクラムを産業界に展開することに参加し、Easel、Fuji-Xerox、Honda、WildCard、Lexus、Googleに影響を与えたことまで、スクラムの歴史を説明しています。スクラムのタイプA、B、そして「一気に」タイプCについて考察し、XPを開発する際にケント・ベックがスクラムのプラクティスを「盗んだ」というユーモラスな噂を確認している。

2011年1月に「10分でスクラム」という資料を出してから、10年が経ちました。
https://www.publickey1.jp/blog/11/10_5.html

それから10年が経ちました。アジャイルマニフェストからは20年です。
当時の私がどのようにスクラムと出会い、そして誰かにスクラムを伝えたくなったときに何をしたのか。
少し思い出しながら、話してみたいと思います。

同じような境遇になってしまった皆さんに、周りに自分なりのスクラムを伝えるきっかけができれば幸いです。
もちろん、スクラム全然知らない！という方にも、知っていただける機会になると思います。

最後に、2021年版の「10分でスクラム」を話してみたいと思います。

Agile 2012 のキーノートで、スタンフォード大学経営学部のボブ・サットン教授が基調講演をしました。当時出版されたばかりの本 “Scaling Up Excellence” を題材に、幅広い調査を元に、よい組織文化をスケールさせるには、どうしたらいいか、なにをやってはいけないか、について話してくれました。

その時に書いたブログがこれです。
Agile2012 Day2 : 基調講演: よい組織文化をスケールさせるには by ロバート・サットン

最近、私は新しい会社 (HoloLab, inc.)にジョインしました。このまだ小さな会社にジョインするにあたって、ふと、ボブの基調講演で学んだことを思い出しました。あわせて当時のインタビューをいくつか見直して、人が増える会社にとって覚えておくべき重要なことを学びました。彼らの研究手法はGTAという質的研究手法を使っているそうで、統計的に有効性が証明されたものではないのですが、うまくいっている企業に共通する要素をとりだしてまとめる、ということにおいて、説得力のある情報が多く含まれていると感じました。一個人の経験や気づきをまとめた自伝やジャーナリストが書いた本とは違い、一定の研究手法にしたがって行わたであろう点も信頼できます。

本セッションでは、そこでボブ・サットン教授がなにを教えてくれたのかを、自分なりにレビューしてみたいと思います。

『教育心理学概論』という書籍があるのはご存じかなと思います。この書籍を書いた三宅なほみ先生は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. 技術的負債を解消する