2年目にして大きなチャレンジをすることになったスクラムフェス大阪とその参加者のために、今だからこそ伝えたいことがあります。

スプリントを回すことに心血を注いでいませんか？ 小さな改善を積み上げることに追われていませんか？
しみったれて硬直したプロセスやツールの話ばかりしていませんか？

このキーノートは、スクラム実践者がアジャイリストであり続けるために必要な態度について思いを巡らせる時間にしましょう。

プロダクトの使いやすさ、操作性の検証、いわゆるユーザビリティ評価を簡単に体験してみましょう、というセッションです。

ユーザビリティ評価とは

ユーザビリティ評価にはざっくり2つのアプローチがあります。

a) 本物のユーザに試してもらうユーザテスト

• ユーザさんにプロダクトまたはプロトタイプを操作してもらう
• あらかじめ設定した操作内容（タスク）を行ってもらう場合が多い
• 定量評価：達成度や達成時間を測定する（想定時間内に終わるか、前バージョンや競合と比較してどうか等）
• 定性評価：つまづいた点や発話（つぶやき）、事後コメントを記録、観察する
• 費用や時間がかかりがち、動くものがない段階で検証ができない、情報漏洩リスクなどが障壁

• プロの頭の中にある"仮想"一般ユーザを使って評価
• 仕様書レベルでもやろうと思えば評価できる（早い段階で問題点を発見できる）
• 初心者VMの脳内エミュレーション精度には心理学的限界がある（通常、開発者はそのプロダクトにもっとも詳しく、初心者からもっともかけ離れた存在である）
• エミュレーション精度を挙げるチェックシート的なフレームワークも存在する（ヒューリスティック評価法など）

どちらにも一長一短があり目的や開発フェーズに応じて使い分けるのが良いとされていますが、コロナ禍でテストルームに多くのユーザを招いて調査をすることが難しくなってきた昨今、せめて後者を頑張ろうといった動きが目立ってきたように感じます。

どちらも「なんかここがわかりづらそう」といった現象／箇所は発見できるのですが、その理由を説明づけるには専門的な知識が必要になります。特に後者は定量的なエビデンスが得られないので、蘊蓄勝負な色合いが強いです。専門用語や過去の類似例で武装することで説得力を生むことが必須になってきます。

本セッションの狙い

本セッションではユーザビリティ屋がよく使うキーワードを簡単に紹介し、実際に身の回りで感じた使いやすさ／使いにくさを例にとって、それらのキーワードで語ってみるトレーニングをしてみたいと思います。つまりユーザビリティを語るための語彙力を鍛えてみようという試みです。「使いやすさ」を説得力ある言葉で語ることは、チームでプロダクトを開発するのにとても重要です。現状にケチをつけるわけですから、しっかりした根拠が伴っているべきですし、その方が円滑にコミュニケーションできるでしょう。

ユーザビリティ専門家が使うボキャブラリーを学び、にわか専門家を気取ってバシバシっと使ってみませんか？（オトナのキッ〇ニア）

スクラム道関西は、ソフトウェア開発の現場をより良くしたいという想いから、アジャイルやスクラムに関する知識を相互に共有し、議論しながら切磋琢磨するために集まった、関西を拠点とするコミュニティです。
参加者が実際に経験した開発現場で困っていること、悩み事、問題を一緒に考え話し合うことで、参加者の現場が一歩でも前進し、改善が進めば、と考えています。

今回、スクラムフェス大阪の参加者が、スクラム道関西運営メンバーに、直接相談できる場を設けます。
スクラム道関西運営メンバーは、様々な業種、業界、職種の立場がいます。
ぜひ、ピッタリの相談相手を見つけ、現場を少しでも前に進めるきっかけを掴んでいただきたいと考えています。
また、特別ゲストコーチとして、福原美砂さんにもご参加いただきます。人間関係に関するプロのコーチですので、開発現場での人間関係について、お悩みをお持ちの方も、ぜひご参加ください。

相談できる場は、

• オープンスペース
• 1on1

の2種類あります。

オープンスペースは、参加者も含めて、現場の困りごとを一緒に解決する場です。
現場で困っていること、悩んでいることが、実は隣の現場でも同じように発生していたり、実はすでに解決した現場もあるかもしれません。
ぜひ、参加者同士で気づきを得て、前に進めれるように、活発に議論できればと思います！

他の参加者の方には話しづらいけど、相談したいことがある場合には、ぜひ1on1をご活用ください！
相談したい方を指名して、じっくりお話してください！
1on1の場合、お一人の相談時間は30分間とさせていただきます。

COVID１９が現れた後で、働き方法が速く変えました。アメリカの会社には、社員が時々Work From Home (WFH) (在宅勤務)出来る文化が多いけど、毎日の働き方法は事務所にいると同じです。

今は違います。皆んなの安全のためにたくさんの会社はWFHだけのモードに変化しました。だから新しいチャッレンジも現れました。

このプレゼンテーションでコーチとして私がWFHの普通な問題を直す方法を教えます。

例えば：

• コムニケーション
• 同僚と絆
• テクノロジー
• Burnout/Exhaustion

COVID19 has changed the way we work. While many American companies had cultures that supported occasional work from home for employees as needed, the culture of working remained the same as when those employees were located in offices.

Now, it's different - everyone is fully remote, all the time. And that leads to a lot of new challenges.

As a software engineering coach, my job is to help others learn new technologies as well as new ways of working...and this different reality has presented plenty of learning opportunities that I'm excited to share with you!

予告動画 : https://www.youtube.com/watch?v=ymZnqdUQ8DE&feature=youtu.be

数度目のアジャイル開発戦争が勃発。
内製開発企業と受託開発企業ではそれぞれのビジネスと命運をかけて防御壁を展開、エンジニア獲得の勢力図がうごいていた。

Scrumの加護をうけし組織となるために工作を展開する企業。
それに反発し自由と共同を求めてオープンなコミュニティをつくりあげるものたち。

終わりが見えない戦争に希望を見出すため、各組織では次世代の旗手をみつけ育成する作戦が遂行された。
そしてミレニアル世代が第一線に配属され、時代はひとつの転換を向かえようとしていた・・・

このワークショップは一言でエレベーターピッチの強力版です。

次のような悩みに効果的です。
・「良い商品なのに売れない、自社(自分)に強みがあるのにお客様に喜んでもらえない。」
・「日々、頑張っているものの報われないことも多く、意気消沈してしまう」

私は20代前半から新規事業に取り組み、自費でも数百万の借金をするなどして挑戦してきました。良い商品なんだけど売れない、強みがあるのに買ってもらえないとずっと悩み続け、どうしたらお客さんの喜びにつながるのだろうと考え続け、試行錯誤してきました。

そのうち徐々にうまくいくにつれて、お客さんから「弊社のこと、なんでそんなに知っているんですか? もしかして勤めていたことがあるんですか?」と驚かれたり、喜んで値引き無しに買ってもらえるようになりました。

その中で学んだ重要なポイントは開発だけでなく、顧客との付き合い方や売り方もアジャイルに適応してくことです。

今回は「顧客との付き合い方や、売り方もアジャイルに適応してく」ためのワークを行います。顧客と良い関係を結ぶためのヒントがえられるセッションにしたいと思います。

・商品/サービス/強みについて考える
・顧客を考える
・競合を考える
・セールス/プレゼンテーションを考える
・ロールプレイしてみよう/セールスマップでユーザーにも決裁者にも響くアプローチを整理してみよう

イノベーションを生み出し、生産性の高いチームを目指すのなら、マネージャーやスクラムマスターはどのように振る舞うかが鍵となります。そこで推薦したいのは「サーバント・リーダーシップ」です。

サーバント・リーダーシップを活かしている人は一方的に命令するのではなく、チームメンバーをどうやってサポートしてあげられるかに重点を置きます。チームメンバーをコントロールするのではなく、チームメンバーに仕えるという態度で接します。

このワークショップでは、サーバント・リーダーシップを効果的に実践するために必要な要素を紹介し、またそれを応用する方法もお教えしていきます。自分のリーダーシップを再考する絶好のチャンスになります。

※来場者へのアナウンス：このセッションは事前の参加チェックインが必要です。チェックイン方法は、参加者用 Discord の「品川タイムテーブル」チャンネルをご覧ください。

あなたのマネジャーはあなたより暇そうですか？
もし暇そうなら、ぜひ他のセッションに参加し、マネージャーに明日「いつも私にチャンスをくれてありがとう！」と伝えてあげてください :)

あなたのマネジャーはあなたより忙しそうですか？
もしそうだとしたら、そのマネージャーを助けたいと思いますか？
もし助けたいと思わないとしたら、あなたの成功の道も険しいかもしれません :/
あなたの成功の近道は、あなたのマネージャーを助ける事かもしれないのですから。

もし少しでも助けたいと思えているなら、この「お仕事解体ワークショップ」が使えるかもしれません。

世の中のマネージャーの中には、理由は様々あれどなかなかメンバーに仕事が渡せず、それが忙しさの悪循環を招き苦しんでいる人たちがいます。
そういったチームでは、マネージャーが休むと色々な事が回らなくなったり、マネージャーが仕事上のボトルネックとなることで仕事のリードタイムが長くなり、組織のパフォーマンスが制限されるでしょう。
それはマネージャーがマネージャーとして機能していないということかもしれませんが、メンバーからそれを助けることでチームとして一歩前にすすめることだってできます。

「お仕事解体ワークショップ」では、マネージャーとメンバーの対話を通して、マネージャーの仕事を解体、理解し、その仕事をチーム全体で担っていくための具体的なアクションを作ることができます。それは「マネジメント」という行為が、だれか特定の人に依存するのではなく、チームの中に溶けているようなチームを作る一手となるかもしれません。

忙しそうなマネージャーと働いている方、または周りにそういったマネージャーがいる方は、ぜひこのワークショップ体験にご参加ください。
実際にワークショップを組織に持ち帰って実施し、あなたのチームがよりよいチームになることを祈っています！ ;)

※「忙しい人」がマネージャーでなくてもこのワークショップは活用できます。（忙しい PO など）

仙台には、東日本震災後に立ち上がったコミュニティがあります。
その名は「レッツゴーデベロッパー」。
レッツゴーデベロッパーは、2011年の震災をきっかけに始まりました。
「共有と交流」をメインテーマに掲げ、日本各地から素晴らしいソフトウェアエンジニア集団が仙台に集結。講演やワークショップ等を開催してきました。

日本各地を巻き込むコミュニティは、どのようにして作られてきたのか？
そのコミュニティを下支えしてきた運営メンバーは、どんな想いで、どのように活動してきたのか？
さらに、コロナ時代前後の変化と、今後の日本各地を巻き込むストーリーを語り合う場としてパネルディスカッションを行います。

Value Stream Mapping を体験するワークショップです。 みんなで一緒にValue Stream Mappingを使ったプロセスの見える化・カイゼン案の検討を実際に体験してみましょう。

Value Stream Mapping = ソフトウェア開発工程の流れ(価値の流れ)を見える化するために作成するプロセス図です。アイデアが生まれてから顧客に対して価値が届くまでの全行程を見える化することによって、ムダな作業や非効率なフローをチーム内で共有することができるようになるため、カイゼンに役立てることができます。

４、５人でグループを作ってグループワークを行います。Value Stream Mapping が描けるようになるだけではなく、チームで作った時の効果も感じられると思います。

今回はOnlineということでDiscord＋zoom＋muralを使って実施しようと思っています。オンラインでワークショップってどんな感じなんだろう？と興味がある方も是非参加してみてくださーい！

星野リゾートでは、長年、ユニークな成長戦略を進めるため、独自に自社システムの開発を進めてきましたが、当初は開発に主体的でなかったため、システムの開発が企業成長のボトルネックになっていた状況でした。
そのような世界に、飛び込んだエンジニアが、Scrumという武器を片手に企業にどのような価値をもたらし、業界に大打撃を与えているコロナの事態をどのように戦っていくのか、お話したいと思います。

2012年から、ベトナムのアジャイルコミュニティに関わるようになりました。このセッションでは、ベトナムとスクラムの関わり、ベトナムのアジャイルコミュニティ、日本のコミュニティとの関係などについてお話したいとおもいます。

書籍『Agile Testing』の著者であるJanet Gregory と Lisa Crispinが明かす、本の出版後に何が起こり何を学んだかが、Agile Testing Days 2011のKeynoteで知ることができます。

XPチームに入り、テスターとしてどう関わったか
ジャネットとリサの出会い
チャレンジングな課題感のある5つのトピック
ジャネットのジグソーパズルからのユーザーストーリー話
現在の状況に見合ったリサのリモートワーク人間話
「失敗のお辞儀」「専門の一般化」
等々

面白い話が色々聞けます！

当日は日本語の字幕を付けて動画を放映しますのでお楽しみに！

会社の文化（カルチャー）変革の7年間の軌跡。

2013年ごろ、色々な問題が噴出し、会社としても個人（経営者）としてもどん底の状態でした。
そこから、色々な取り組みを行い、少しづつ会社の状態がよくなり素晴らしいメンバーにも恵まれ、会社の良い文化（カルチャー）が形成されるようになりました。

その過程のなかで2017年8月「Joy,Inc.」に出会いました。
「Joy,Inc」とは、Menlo InnovationsのCEOであるリチャード・シェリダンさんが執筆した本です。職場に喜びをもたらす知恵や経営手法だけでなく、顧客も巻き込んでより良い製品を作り、事業を継続させる手法などについて書かれた素晴らしい本です。
この本に共感しぼくらもこんな会社に成りたい！と決意。それまでの会社の文化を良くするための取り組みを更に推進していきました。

会社のカルチャーを変えることはとても困難です。それをどのような取り組みを行い実行してきたのか、そんなぼくらのジョイインクジャーニーの軌跡を共有したいと思います。そのジャーニーの中でやってきたこと、失敗したこと、いまも続けていることを含めて赤裸々にお話したいと思っています。このぼくたちの経験が、みなさんのジョイインクジャーニーに役立てていただけるのであれば大変嬉しく思います。

今回は、Developer Summit 2020 での講演（45分）のロングバージョンとしてもう少し詳しく、それぞれの取組みについてお話したいと思っています。（Developer Summit 2020ではベストスピーカー賞を受賞しました。https://codezine.jp/article/detail/12140 ）

https://confengine.com/regional-scrum-gathering-tokyo-2020/proposal/11835/joyinc3

アジャイル開発プロセスのひとつ、XP (eXtreme Programming)の入門セッションです。
XPの特徴は、技術と人（チーム）にフォーカスしていることです。

近年、プロダクトやサービスの企画・開発の難易度はますます上がり、テクノロジーの進化や市場の変化への対応が困難になってきています。Amazon, Apple, Google, Facebook, Netflix, Teslaなど、最新技術で市場をリードする企業の勢いが止まりません。はたして、かれらはどのようにして世界中の顧客が欲しがる製品を企画、開発、そして提供しているのでしょうか。 本セッションでは、シリコンバレーをはじめ日本でも採用されはじめている 「プロダクトマネジメント」を、エンタープライズ×スクラムでどう実現し、価値を高めるかについて、概説いたします。

「アタック25」をやります。

ただし、クイズで出題する問題はアジャイル/スクラムに関する問題に限定します。

クイズの問題自体もワークショップの中で参加者のみなさんに考えていただきます。

したがって、クイズ問題の作成者と回答者の両方の役割が体験できます。

しかも、クイズ問題作成〜回答のプロセスをスクラムでまわします。

スプリントを繰り返すほど出題されるクイズの問題の質が上がっていくことを体験できます。

アタックチャンスで運命を変えろ！

よりよいソフトウェア開発を追求するのが趣味の講演者が、趣味が高じて誰もが知っている世界的企業のクラウドの開発者の米国でのポジションをゲットしました。私が昔から知りたかった「アメリカのソフトウェア開発が何故そんなに進んでいるのか？、何が日本と違うのか？」という秘密を探ってきましたので、みなさんとシェアしたいと思っています。アジャイルやスクラムが生まれた背景や前提にはどういう市場、文化、マインドセットがあるのか？実際のアメリカの開発の現実はどんなのだろうか？もしくは、より良い開発を可能にしたい！と思っている方には喜んでいただけるセッションになると思うので、よかったら是非ご参加ください。時間が２０分しかありませんので、終了後、徹底Q&Aのディスカッションを直後に実施したいと思います。

アジャイルをカリフォルニア州で2014年から全社レベルで導入してから現在に至るまでの経緯と、今まさに起こっていること、そしてCOVID19がどう影響したのか、最後に今後の仕事のやりざまがどうなっていくのか（私の所見を）お話ししたいと思います。

伝えたいこと

スクラムの原理原則に背くとだいたい失敗するとよく言われます。「事情があってちょっとだけ自分たちのやり方に変えてみたいのですが、、」ともなれば、いずこかのスクラム有識者が「スクラムちゃうがな」と投げかけてくるかもしれません。しかし、それでもやってみてはどうでしょうか？

スクラムは3つの役割、3つの作成物、5つのイベントで構成される軽量で理解が容易なフレームワークです。ところがそれだけシンプルな仕組みであっても、実際に始めるとなるとそれほど容易ではありません。原則通りに始めようとすると、色々と疑問点がわいてきませんか？プロダクトオーナーやスクラムマスターは誰がやるのが良いでしょうか？プロダクトバックログはどうやって作るのでしょうか？スプリント計画はどうしますか？スプリントレビューは必要ですか？スクラムはいつ始められますか？

全ての条件を揃えてからスクラムを始めるのは容易ではありません。しかし、それでもやるしかないのです。なぜなら、正しいやり方を実践するだけの知識や実力や環境が私たちには無いからです。とりあえずやって、失敗して、少しでも原則どおりできるように変えていくのが現在の私たちのやり方です。

2019年4月に私がJOINしたチームはコテコテのウォーターフォールで開発していました。体制変更で突然大きく変化したチーム状態と過去に経験したことがない高難易度な開発テーマで課題が山積みの中、行き詰まりを感じてスクラムの原則を取り入れ始めました。とはいえ私たちはスクラムの経験が無いチームなので、プロダクトバックログも十分に作れない状態からとりあえずスプリントの開発サイクルに移行するなど、経験者から「それやったらアカンよ、たいてい失敗するから。」と言われるようなこともあえてやって、たいてい失敗しながら、従来の開発スタイルを少しずつ変えています。私たちの取り組みはまだスクラムをやっているとは言えないかもしれませんが、少しずつでもスクラムに近づこうと試行錯誤している方々にとっての1つの事例として、「こんなやり方でもできるよ」というストーリーをお話したいと思います。

スクラムと私

株式会社ラクス は中小企業向けのクラウドサービスを提供し、19期連続増収で事業拡大中の会社です。私は2011年に入社し、BtoCサービスや北米向けサービスなどの新規事業の開発を経験した後、主力サービスである楽楽精算の大阪開発チームをリーダーとして立ち上げ、2018年からスクラム開発に取り組みました。スクラム開発に取り組んだことで、過去の開発経験も含めてチームが不確実性と向き合い敏捷性を高めていくことの重要性を改めて実感しました。2019年4月からは10年以上続くメール配信サービスの開発チームに異動し、マネージャとして従来型の開発プロセスを少しずつ改善してチームのアジリティを高めていくことにチャレンジしています。

生存者バイアスなんて、気にしない
長期稼働しているシステムの生き残った中で、どういうモデリングが良いのか、逆算で考えてみたいと思います。

私は、開発をスムーズに進めるために仕組みを整えたり自動化を推進するチームでスクラムマスター として働いています。

ジョインしたのは4ヶ月前。

チーム全員が疲弊し、諦めの色が濃くなっていました。

チームを取り巻く環境は過酷なものでした。レガシーコード、責任の押し付け合い、怒声、罵声...その他諸々。

どうやって生き生きと楽しく働ける環境にできるのか。

毎日たくさんの事件に遭遇しながらも、そこから学び成長しチームになっていった様子と、そのためにどのような取り組みを行ったかについて、お話しします。

何もないと思っていた所から、少しずつ採掘し道具を作りチームを構築していく様は、まるでマインクラフト のようです。

「マインスクラム ダンジョンズ - グループからチームへと変化するための戦い」

中の人は想像以上に大変ですが、外から話を聞くだけなら怖くないので気軽に聞きに来てください。

我々は誰に"価値"を届けるのでしょうか？

エンドユーザー？自動車メーカー？事業部長？？

大企業はPOからエンドユーザーまでが遠すぎます。

そして、POと開発チームの間にも距離感を感じている方もいるのではないでしょうか？

では、"価値"とはなんでしょうか？

ユーザーの求める価値＝ステークホルダーの求める価値でしょうか？

ステークホルダーの求める価値＝POの考える価値でしょうか？

そして、POの考える価値＝開発チームの考える価値でしょうか？？

また、"価値"とはどうやったら生まれるのでしょうか？？

失敗に成功した！

私のチームはとあるWebアプリ開発をスクラムで取り組みました。

結論を言うと、プロジェクトは予定通りリリースできました。が、その道のりは失敗の連続でした。

このセッションでは、とあるプロジェクトを通して私たちが経験した失敗談をお届けします。

しかし、結果的にこの失敗のおかげで私たちはアジャイルの原則に立ち返ることができ、開発チーム、PO、ステークホルダー、プロジェクトに関わった全員が大きく成長できました。そう、私たちは失敗に成功したのです！

皆さまには、プロジェクトの中で価値を生み出し続けるための明日から使える具体的な提案と、愛という"価値"をお届けするセッションになればと思います。

プロジェクトマネジメントの視点から、これからの新しい時代におけるアジャイルとプログラムマネジメントの連携の重要性について議論します。

モブプログラミングを導入したいと思っていても1人で出来るものでもないですし、良さそうだなと思ってもやったことないと自信を持ってお勧めできないというところはあると思います。

弊社では、継続的にモブプログラミングをしているチームはまだあまりないのですが、興味のある人はいそうです。また、ジュニアの育成に悩むマネジメント層からの興味もあり、モブプロ 体験会を実施することになりました。

すでに5回実施して参加者からは好評を受けているその中身を紹介したいと思います。

　私はスクラムチームのProduct Ownerとしての仕事に加え、2019年夏から人事、総務、経理、情シスなどを統べる「管理本部」を兼務しています。

そのミッションは"1300人に対し、働き方改革を推進すること"この抽象的かつ大きなテーマに立ち向かうことです。

　ミッションを受けてから数ヶ月、小さなチームで小さく始めることでリモートワークやコミュニケーション改革などたくさんのアウトプットと社内のメンバーへのアウトカムを追求してきました。

　そんな実践録をお話しします。

Extreme Fishbowlとは、ペアプロをみんなの前で公開してやることです。外野から声もかけられるのでやる側は緊張しますし、見る側も非常に勉強になると思います。
なんてドSなコンテンツなんでしょうか。これをオンラインでやってしまおうという試みです。
今回はFizzbuzzなどの簡単なネタを通じて、TDDとペアプログラミングを学びます。
運営側も初めての部分が多く、どうなるか正直わかりませんが、参加者のみなさんと一緒に盛り上がれたらうれしいです。

海外の模様
https://www.youtube.com/watch?v=HuKfBoF2BUU

イメージ画像(2015年のレッツゴーデベロッパーのグラレコ)
https://assets.st-note.com/production/uploads/images/11110821/picture_pc_30cad9ada2314e75b6696b9efbe8b732.jpg

開発環境は、ブラウザベースのツールを利用します。
https://repl.it/

Covid-19の影響で軒並勉強会がオンラインに移行しつつありますが、Agile459では2017年よりオンライン読書会を定期的に開催してきました。
その進め方はこれまで紆余曲折・試行錯誤してきましたが、オンライン勉強会を行う人が増えてきたため、これまでの経験を紹介することで、何かの役に立てばよいと考えました。

昨年2019年に海を渡る越境をしました。
越境(ちうごく転職)後の奮闘一年で得られた私の学び、私自分の変化についてお話します。

Mackerelというプロダクトはローンチから5年が経ちました。ぼくはそのほぼすべての期間、このチームに在籍していて、うち3年間はマネージャーとしてチームを運営しています。5年間運用されたチームではさまざまなことが起こりますが、いくつか事例をご紹介しながら、長く安定的に続くチームづくりについて考えていきたいと思います。

スタートアップ企業のソフトウェア・サービス開発や、大手企業の新規事業開発を支援するSun Asteriskが、いかにして海外を中心に4ヶ国・6都市で1500名体制を構築してきたのか。また、ベトナムをはじめとする、海外で培ってきた人材育成や教育の手法をご紹介します。

AgileやScrumにおいて、Agile Testingはあまり盛り上がっていない分野です。

• 「Testing？やってるよ。開発は全てテスト駆動開発（TDD）でね。」
• 「AgileやScrumでは全てチームで行うので、QAやTesterは必要ないよ。」
• 「チームの外で、QAがテストしてるみたいだね。詳しくは知らないけど。」

こんな風に思っている開発者も多いのではないでしょうか？

今回の新潟トラックのkeynoteでも講演したJanetとLisaによる書籍『Agile Testing Condensed』は、このような開発者や経営者に対してAgile Testingのエッセンスを紹介しています。

本講演では、Agile Testingの「Condensed=濃縮された」内容が書かれている書籍『Agile Testing Condensed』の中で、現在の日本の開発者に特に伝えるべきだと感じた内容を、この書籍の翻訳者本人である発表者が紹介していきます。

紹介の際には、日本ならでは事情や書籍に載っていない補足なども加えてお伝えする予定です。

Regional Scrum Gathering Tokyo 2020 で「田舎で14年スクラム - チームを導く現場の「ゲームモデル」づくり」というプロポーザルを出したら落ちたのと、当該カンファレンスで2つもゲームモデルの話があったので、田舎の未開度合いと、そこで発見した奇跡について話したいです。

鳥取に比べたら、世界中スクラムパラダイスやで！

前回「田舎で11年スクラム」との違い

• 1年経過しました
• 計算間違ってません
• 田舎のスクラムチームを取り巻く状況はさらに深刻に
• 田舎では、会社の中でスクラムチーム運営してますわーいだけでは先がありません
• Long-Stable-Teamを求めて、ちんもは自分が働いている土地とそこに住む人々について改めて考えることになりました

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

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

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

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

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

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

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

毎年9月に開催しているXP祭りの運営スタッフが、運営の裏側を語ります。

外国人メンバや海外支社チームと５年以上働いてきた今だからこそ強く思うこと。
実体験を赤裸々に語りつつ、みなさんの疑問やご相談にざっくばらんにお応えします。

外国人だけが「異文化」というわけではありません。

既存文化の国内企業にアジャイル開発を提供・導入支援するなかでの苦労。
となりの部署・チーム・席の方と、ともに価値を紡ぐには。

広い意味で「異文化な人」との仕事に悩んでいる方、是非ご参加ください。

※本セッションでは、前半のプレゼンテーションに基づき、参加者の皆様から質問やコメントをいただきながら、ディスカッション形式で議論を進めていきます。

※全セッションDiscordで行います。Discordにログイン後、#agilejapan チャンネルへお越しください。尚、本セッションの録画はありません。ぜひリアルタイムでのご参加・議論をお待ちしております。また、視聴のみの参加も大歓迎です！

ゲストスピーカー：Japan Intercultural Consulting Managing Principal ロッシェル・カップ様
プレゼンター：アジャイルジャパン実行委員 CI&T Japan 川渕洋明
ファシリテーター：アジャイルジャパン実行委員 楽天株式会社 チャンドラー彩奈

「雑談」のワークショップです。

「雑談」と聞くと「え？なにそれ？意味あるの？」と思われるかもしれません。

しかし、「雑談」には組織/チームのカルチャー（文化）形成にとって良い効果があるのです。

このワークショップは、その「雑談」の効果を知り、「雑談」を体験してみるというワークショップです。

ーーーーーー

弊社（クリエーションライン）は、140名のエンジニアを中心にした会社です。

弊社では、2019年1月から毎週月曜日に30分を「雑談」の時間として使っています。

業務として「雑談」をしています。

私たちが「雑談」を行う目的は、「チームワークの7つの段階」でいう「新しい価値を共に生み出すチーム」になるためです。（参考：http://www.scholar.co.jp/workcollaboration/level/）

新しくできたチームがいきなり「新しい価値を共に生み出すチーム」になることはできません。そのようなチームになるためには、Level1からひとつひとつステップアップしていく必要があります。

「雑談」には、この7つの段階におけるLevel1~3に効果があると考えています。

Level1　Know each other (お互いを知る)

Level2　Share casual conversations（話をする）

Level3　Understand one another（理解する）

良いチームになるために、良いチームとなるカルチャー形成のために、僕たちは「雑談」を取り入れています。

実際に、この雑談を取り入れるようになり、定期的に調査しているエンゲージメントスコアは右肩上がりになっています。

僕たちがやっている「雑談」を体験していただき、是非あなたの組織、チームで「雑談」を取り入れてみてください。「雑談」だけで良いチームになるわけではありませんが、良いチームになるためのベースになるはずです。そのきっかけをこのワークショップで持ち帰ってもらえると嬉しいです。

巨大ウォーターフォールプロジェクトの一員であった業務SEは、8か月後、重要なアジャイルプロジェクト（※）を任されるエンジニアになっていました。

「なぜ？」「どうやって？」。このセッションでは、チャレンジした本人（橋本）とそれを支える組織（岡島）それぞれの目線から、次の切り口で明らかにしていきます。

1. 価値：変化を抱擁する世界へのチャレンジと、それを支援するアジャイル組織の在り方
2. 原則：本気で取り組むための「ビジネスと学びの両立」「段階的動機付け」「組織能力化」
3. プラクティス：プログラミング未経験の業務SEが成長するために日々考え実行したこと

※ https://jbpress.ismedia.jp/articles/-/57937

システムへの機能追加・変更を安全にするため、味方につけたい自動テストを伴うコーディング。

いざ実践しようと思ったが、既存システムのテスタビリティが低くて難しい。

そんな状況をサポートするテスティングテクニックをライブコーディングで実践していきます。
実際に現場である、テストを入れづらいコードに対してテストコードを追加していきます。

アイデア元 "書籍：レガシーコード改善ガイド"

イベントのオンライン開催は今回のコロナ渦によって一気に認知が広まり、今後もますます増えていくことが予想されます。

しかしまだまだオンライン開催自体のノウハウが少ない中、『場の温め方』は開催する側としても頭を悩ませる部分ではないでしょうか。

しかしオンラインにはオンラインのメリットがたくさんあります。

これをやっておけば間違いなし！
オンラインイベントのいろいろな場面で使えそうなアイスブレイクを集めてみました！
オンラインでなければ会うことがなかった人たちとの距離が、少しでも近づけられたら幸いです。

「自己調整学習」とは教育心理学などの文脈で使われる言葉で、学習が効果的になるように、学習者が自発的に行うプロセスのことです。

私がこの自己調整学習に興味を持ったのは、よりよい学習の理論を知って終わるのではなく、
実際によりよい学習を実践できるようになる理論であると感じたからです。

私は普段、認知科学や学習科学などの分野で、人の理解や学びについての理論を趣味で学んでいますが、
興味深い内容であると思う一方で、他の人に薦める難しさを感じています。
薦められた人は理論云々よりも、実際に役立つ知識が欲しいと考える人が多いと思うからです。

そんな中、自己調整学習の内容は、理論だけでなく、それをより実践しやすい形に落とした内容も扱っており、
これを紹介することで、学習のプロセスを見直すきっかけになるのではないかと考えました。

例えば、「初歩の自己調整学習者」と「上達した自己調整学習者」の比較がされています。
初歩の自己調整学習者は学習課題に興味をもっておらず、上達した自己調整学習者は強い内発的興味を持っています。
初歩の自己調整学習者は結果のセルフ・モニタリングをしますが、上達した自己調整学習者は過程のセルフ・モニタリングをします。
初歩の自己調整学習者はマイナスの評価を能力に帰属しますが、上達した自己調整学習者はマイナスの評価を方略の使用や不十分な練習に帰属します。
こうした具体的な比較は、現在の状態と比較して改善ポイントを考えるのに役立つと思います。

また、自己調整という言葉からは、自分だけの話のように感じるかもしれませんが、
自己調整学習の発達の話では、他者との相互作用の重要性にも触れられており、チームでの学習についても考えることができます。

このセッションでは、メタ認知や動機づけなど、自己調整学習の理論で重要になる考えについて簡単に触れながら、
上達した自己調整学習者を目指すという観点から、より実践的に学びのプロセスについて考えることができればと思います。

皆さんこんにちはヤフー株式会社の中村です

私たちのチームでアジャイルについての社員研修を担当する事になりました

しかし、研修を構築していた最中、オフラインからのオンラインへの変更となり…

今まで計画していた研修も設計から振り出しに戻りました

オンライン研修に変わった事で、経験した事がない事が多くなり

見通しが立てづらい状況になりました

そこで、少しずつ計画、実施、改修を繰り返し、状況を把握しながら、より良い研修を目指して作り上げていきました

私たちの体験した経験を通して、皆様が「より良い状態」を目指すヒントとなれば幸いです

ニューヨーク大学はコロナウイルスの影響を受けて、3月に授業を全てオンラインで行うという意思決定をしました。そして、その意思決定から一週間も経たないうちに、3万人以上の学生の全授業がオンラインへと移行されました。
学習環境に様々な変化が起こっていく中で、学生に高い質の学びを提供し続けるため、ニューヨーク大学はどのように対応をしてきたのでしょうか。学生として在籍していた視点からこの事例を分析した結果、この移行の成功にはスクラム組織への移行が大きく関わっていることに気付きました。このセッションでは、この移行期間の組織の動きをスクラムの観点から分析し、不確実性の高い社会において、どのような観点が組織に重要かを考えていきます。

実験場はどうして必要か？

企業の中で企業を変えようとしているスクラムマスターやアジャイルプラクティショナーの皆様。
コミュニティや本などで仕入れた新しいワークショップや、メトリクスがうまく働くかを会社で試してみたいと思いますよね。

でも、それ大丈夫ですか？
安全ですか？失敗しても大丈夫ですか？失敗しないようにがんばりますか？
でも、失敗ってしたほうがいいんですよね。

会社組織は良い実験場か？

そもそも会社組織の中で最初に実験するのってハイリスク・ハイリターンですよね？
失敗した場合ときには実験を止めたいと思いますが、下手に予算やOKRが決まってたりすると、とりあえず四半期ぐらいは引くに引けない状態になったりして、危険な状態になることがあります。

そうならないように、安全に実験できる場所を探しましょう！
そのためのサバイバルテクニックを考えましょう。

サバイバルテクニック

#1 趣味を増やそう！

単に趣味を増やすことに意味はありません。
社会性が得られる趣味であれば、それは立派に実験場として機能します。

#2 地域コミュニティに参加しよう！

PTAや自治会、地元神輿会など、地域コミュニティも立派な実験場です。

#3 家族を実験に

家族との信頼関係が利用できる場合は、実験目的を話して実験に協力してもらいましょう。
父親、母親、子息、伴侶それぞれ幅広い年齢層に対して実験できます。

アジャイル関係のコミュニティやイベントでいろいろなアジャイルコーチの方とお話しする機会も多くあると思います。

皆様の中には「いずれはアジャイルコーチとして独立して...」なんてことを考えられている方もいらっしゃると思います。

本セッションでは、社内のアジャイルコーチと独立系アジャイルコーチの違いや日々の苦悩をお話ししながら、皆様の将来に関する何らかのヒントを得てもらえることを期待しています。

本セッションではオンラインホワイトボードツールのMiroを使いながら、オンライン時代のスクラムチーム、スクラムマスターのふるまいを考えます。

オンラインのホワイトボードツールはMiroとMuralが有名ですが、今回はMiroを使っていきます。どんなことができるのか、どういう風に見える化できるのかを一緒に体感しましょう。

努力・根性・忍耐がとにかく嫌い。そのうえ弱虫。
余計な一言で周りをドン引きさせるくせに、
社会性を求められると、すぐにお腹がグルグル痛くなり出勤すらできない。
人生のほとんどをネガティブに過ごし時間を無駄にする。

そんなダメ人間の僕が10年に渡って開発チームを率いたら、
なぜか優秀で面白くてキャラが濃い人がいっぱい集まって
めちゃめちゃ優秀なチームが出来上がった！
しかも働き方改革もリモート勤務もダブルワークも可能なチーム。
そんな僕の体験から導き出した、アジャイルがもっと美味しくなる(かも知れない)話。

• ダメ人間は本当にダメなのか？
• なぜか上手く行く不思議な価値観
• バラバラのメンバーが実は一体となる秘訣
• チームの能力を最大限にする方法
• 個性的なチームを育てた(自ら勝手に育つ)チームビルディング
• 最弱のマネージャーが最高のチームを作るには

この説明を読んで、
『ふざけてんの？』こいつアジャイルやスクラム舐めてるよね？っていう人にも、
自分よりダメ人間を見つけたから少し安心できるかもって人にも、
なんとなく変わった話だなって思った人にも、
ダメ人間のダメダメ感を楽しみつつ、
優しくちゃかしてもらいながら進めれれば嬉しいです。

このセッションに参加すると

努力と根性と忍耐がとにかく嫌いな弱虫がなぜ

• 高いスキルを持った人達と共に歩めたか？
• 尖ったチームが育つ環境を作れたか？
• スキルの高くないメンバーも活躍できるチームを作れたか？
• 自分の思考のリミットを解除し続けれたのか？

が、わかるだけでなく
次の日からすぐに実践できちゃうかも知れません。

誰にでも合うとは言いませんが

経験だけでなく社会心理学的な要素も取り入れた内容になっています。

背景

努力と根性と忍耐がとにかく嫌い(無理)。
協調性も薄く、コミュニケーションも苦手。
社会性やルールを押し付けられると、すぐストレスで死にそうになる。
(お腹ピーピーになったりして動けなくなる)
そんな僕は10年ほど前、リーマンショックの煽りを受けて失業していた。
理解されることもなく、何かを成し遂げることもなく、
お金もなく、虚しく人生を過ごす恐怖。
悩みに悩んでソフトウエア業界を離れる決心をした時、
ふとした縁で入った会社は当時社員が10人にも満たない零細SIerの
株式会社オンザロード。

アジャイルやスクラムを全く知らなかった僕が10年にわたって、
地道にチームビルディングとプロダクトマネジメントを続けた結果、
個性的なメンバーが自由に働ける環境が出来上がり、
洗練したスクラムのチームも生まれ、
お客様とも信頼関係を築くことができていました。

今回Home Automationという新たな夢に向かって退社したことをきっかけに、
株式会社オンザロードで起きた奇跡的なマネジメントを振り返り、
自分のバックグラウンドや大切にする一つの価値観に社会心理学的な根拠も付け足しながら、
皆さんに共有する事で、自分自身がさらなる覚悟を持って進んでいきたいと考えています。

「アジャイル開発の事例を聞いたけど、いざ自分ごとで考えるよく分からない…」
「このエピソードは、どこでも起きうる話なのだろうか？」
「自分の現場で起きている課題は、どのチームにも起こり得る課題なのだろうか？」

事例だけ聞いても分からない…一方で抽象化した理論だけ聞いてもよくわからない…みたいなこと、ありませんか？

レッドハットには、現場を支援しているアジャイルコーチが複数人います。このセッションでは、同じ会社だから話せる“場”のなかで、アジャイルコーチ同士で深く共有した事例を通し、チームの成長に伴い起きる課題について、実際に現場で起きた内容とどの現場でも共通でチームにみられる事象を紐づけて話せたらと思います。

今、現場で起きている課題の先に光があるのだろうか？そんなふうに心配している方々に進む勇気を持って頂ければという思いで話させて頂きます。

※本セッションは、「アジャイルチーム成長の過程ってどんな感じ？(20min)」と「アジャイル開発導入事例から分る組織・チーム・個人の課題(20min)」を１つにまとめて再構成するものになります。

さぁ、スクラムマスターやるぞ！で、まず何をすれば良いんだっけ…？
CSMの資格とったよ！とはいえ、実際現場でどうふるまえば良いのかちょっと不安…

教科書的な知識はいろいろなところで学べますが、実際の現場に立つのはいつも不安とワクワクで溢れてますよね。
私も同じです！

一方、ベテランスクラムマスターのみなさん！
「何から取り組めば良いですかね？」と新米スクラムマスター相談されました。
さぁ、なんと答えますか？

ということで、そんな新米スクラムマスターの不安を少しでも取り除いて、ワクワクを大きくしたい！
自分が相談されたときにきちんと答えられるようにしておきたい！
そんな気持ちから、
こんな取り組みしたな。こんな失敗したな。これは良かったな！
といったような、自身の経験を振り返ってみました。

振り返る中で、

• やっぱりこういったことは大事にしたいな。
• まずはこういったことを意識してやってみると良いかも。

といったようなものも整理してみたので、その超個人的な見解をみなさんに共有したいと思います。

お話しするキーワードはこんなものを想定しています（変わる可能性は高いです）
エピソードも含めて共有させていただきます。

• まずはチームから信頼を得よう
• チームに集中できる環境にしよう
• 焦らずじっくりやっていこう
• 必要は最高のモチベーション
• チームのカラーはそれぞれだよね
• 仲間をつくろう

などなど

現場によって状況は様々でしょうが、
「聞いてくれた人にとって、少しでも勇気を与えられ、励みになれば」
と思っています。

講演後に、ぜひいろいろお話ししましょう！！！

こんにちは！
私達はLED-Camp(※) で毎年スクラムを初心者向けに教えています。

ここでふりかえりを重点的に教えたのですが...LED-Camp が終わった後のアンケートに「ふりかえりは重要ではないと考えている」と答えた人がいました。
何故なのか？そもそもふりかえりは何故必要なのか、どういったときに必要なのか？
必要ってことは分かっている。分かっているんだけども...本当に必要なの！？

この疑問をなんとかして自分の納得する形にしたい！と思い、実践やイベントで様々な意見を交わしていきました。
その際に得た情報や、自分なりに出したふりかえりについてお話します。

この話を通じて、「ふりかえり」について、ふりかえるきっかけになってもらえたらと思います。

※ LED-Campは、組込みシステム開発の初学者や未経験者、また、興味のある方を対象とした合宿形式の勉強会です。若手の社会人や学生が一堂に会し、組込みソフトウェア開発の基礎を学びます。実習を通して、モデル駆動開発とスクラムを学び、チームで解決することを体験します。
詳しくはリンクを見てください！

「Scrum Patterns: The Spirit of the Game」 の公開情報を題材に、スクラムガイドについて掘り下げる会を開催します。

1. Product Organization Pattern Language
2. Value Stream Pattern Language

英語で書かれた書籍を、 じっくり読み進めるAgile459の読書会パターンで進めます。

みなさんと深掘りしたいテーマは、当日公開。

参加者全員で翻訳しながら、議論をするので、 事前に読んでおく必要はありません。

ぜひ、一緒にスクラムパターンにこんなこと書かれていたんだーという 発見をしましょー。

社内向けのソフトウェア開発をしています。２年前、委託型のウォーターフォール開発から内製アジャイルに切り替えたばかりの頃、企画時に決めたスコープを変えずに、実装していました。

スプリントを繰り返すたびに、レビューから得られる情報は日々増えていき、チームのドメイン知識の増加します。ユーザーやチームの成長など、何もかもが少しづつ変化していきます。あらゆる状況が変わっていくなかで、開発スタート前に作ったバックログを更新しない手はありません。

目まぐるしく変化する課題に対して、バックログをどの様に変えていったのか
そして、企画当時とリリース時の完成イメージにはどんな差が合ったのか

実際の事例を題材に共有したいと思います。

2019年2月に開設したマネーフォワード 京都開発拠点にて拠点の立ち上げとスクラムマスターをやっているumisoraと申します。

同時に出しているプロポーザルもぜひ御覧ください。

「マネーフォワード京都のスクラムセレモニーを完全かつ詳細にご紹介します」

私は新卒3年目くらいから金融系SI会社の中でスクラムに出会っています。出会ってから早8年は経ったでしょうか。スクラムに出会ってからというもの、その魅力は全ての課題を解決するのではないかと夢を抱くほどにパワフルで、合理的で、魅力的だと感じてきました。

そんなスクラム信者とも呼べる私ですが、過去３回自分自身がオーナーシップを持ってチームにスクラム導入のチャレンジしていました。しかし結果は惨憺たるもので、スクラム本の様にはチームは自走しないし、ベロシティは測れないし、ただ形だけのスクラムを行う事しか出来ませんでした。

「これは欲していた形ではない」

と同時に

「スクラムとはこんなにも難しいものか…」

と感じてきたのでした。

このセッションでは、

まるで本に書かれているかの様な成果によってチームの輝く姿を得るに至った、４度目のチャレンジであるマネーフォワード京都開発拠点でのサクセスストーリーをお話します。

2019年2月にオープンしたマネーフォワード京都開発拠点は2名からはじまり、10ヶ月で16名となりました。そのうち10名程度がWebサービス開発に直接的に関わって開発を行っています。

2019年後期から(自社としては)大きめの案件の開発が始まり、東京も含めて同時に10名~15名程度が稼働するプロジェクトとなりました。

毎月の様にドメイン知識もないメンバーが増える中で数カ月間ハレーションもなく、活躍できない人もない状況を作り上げました。新メンバーが増えても2週目からは以前からいる人達と同じパフォーマンスを上げ始めるチームです。

今回はオフショア開発に限ったお話ではありません。

・チームメンバーと普段離れて仕事して状況が把握できない。

・ステークホルダーを巻き込みたい。

・組織にアジャイル開発を浸透させたい。

上記にお悩みの方にも参考になります。

私はアジャイルコーチとして約１年前からベトナムにある子会社(Techbase VietNam Company Limited)のアジャイル開発の導入支援をしています。

「チームは全員同じ場所で作業するのが良い！」アジャイル界隈に限らずよく耳にします。また、チームが頻繁にコミュニケーションし連動、連携するアジャイル開発はオフショアに不向きと言う声も聞こえてきます。

一方で日本でも新型コロナウイルス感染症の拡大がきっかけでテレワークが進み、やむをえず分散作業するスクラムチームを見ます。その結果、オフショアと似た課題を抱えているチームも少なくありません。

コロナで働き方が急激に変化しましたがベトナムのスクラムチームは変化に適応し持続可能なペースで活動できました。

なぜできたのか？

文化も言葉も違うベトナムと日本、両国のチームが目指した国境を超えたアジャイル開発、その裏にあるメンバーの思いや組織的な取り組みも含めてお話しいたします。

モブプログラミングは、いますごく話題になっています。モブはいいという話が多くされてはいますが、具体的にどういうことがいいのでしょうか。そして、モブプログラミングでは何が起こっているのでしょうか。モブで、チームメンバーはお互いにどんなやりとりをしているでしょうか。それがそれぞれにどのように働きかけているでしょうか、その結果、どんな効果が生まれているでしょうか。

サイボウズでは、日本の開発は全てモブでやっています。そこから戻ることはありません。何が彼らをひきつけているのでしょうか

私は、そのモブに接した時、衝撃を受けました。そしてその魅力に取り憑かれました。何が起こっているのか、もっと調べたくなりました。そこで、モブのやりとりのログを徹底的に取っていきました。

そうすると、うまくいっているモブの状態や行動に、あるパターンが見えてきました。しかもそのパターンは、チームで不確実な問題を解決していくうえでのメンタリティーを援けているばかりでなく、高い品質をはじめから埋め込んでいく仕組みを裏付けていました。これを言語として表現して、その言葉で議論していけば、さらなるモブの改善や、モブ文化の伝達に寄与することが期待されます。

これはあくまでも、サイボウズのケースですが、モブの推進の参考になればと思います。

４年前、スピーカーを含むJAXA宇宙科学研究所で一緒に学んだ仲間たち数名が集まって「株式会社レヴィ」を創業しました。いわゆる、大学発ベンチャーという形の起業です。レヴィは、宇宙開発やソフトウェア工学などの分野で発展してきたシステムズエンジニアリングの手法群を出発点としながら、より一般的で幅広いレベル／分野のシステムに適用可能なシステムデザインの方法について考えています。そして、そのような方法を効果的に実行できるフレームワークやツールを構築し、研修・コンサル・WEBサービスなどの形で企業や個人に提供しています。今回の発表では、レヴィが構築したシステムデザインのためのフレームワーク「システミング」について、そのコンセプトと具体的なメソッドの一部を紹介します。

　Kubernetesやコンテナ化を自社に推進したいと考えるエンジニアやアーキテクト、CTOの方も多いのではないでしょうか。
ところが、その推進が停まる理由の一つに「チーム内の技術スキルの差」が挙げられます。必ずしもチームの技術スキルレベルが一定である必要はないものの、複雑なKubernetes環境を運用していくためには、そのチーム体制や運用プロセスの変化が求められます。
　Kubernetesが一般化されていく中、これからのプロジェクト推進者は何を考えなければならないのでしょうか。Kubernetesを導入する現場で直面する、DevとOpsの新たな関わり方についての考察を紹介します。個別のチームだけでなく、業界全体で考えなければいけないKubernetes推進という大きなプロジェクトに対して、ともに考え、ともにつくることを目指したいと思います。

アジャイル開発における品質保証は、特定の段階で特定の人々のみが取り組むというよりも、専門家を交えつつロードマップ策定から日々のモニタリングに至るあらゆる段階でチーム全体となって取り組む活動となります。本講演では、伝統的な品質保証（Quality Assurance）の考え方から、アジャイル品質（Agile Quality）へとチームや組織が変わっていくために必要なパターン集 Quality Assurance to Agile Quality (QA2AQ) の紹介を通じて、アジャイル品質の考え方と推奨される活動を紹介します。CodeZineにおいて有志によりQA2AQの各パターンを翻訳連載中です。https://codezine.jp/article/detail/12092