Currently in our environment of 27 developers we have no manual tests for the software to deploy to production. We practice continuous integration, and continuous delivery. All infrastructure is written as code. Bugs and defects are top priority with no bugs most of the time. Team members treat each other with psychological safety. We have a 2-hour value stream for our cloud based IOT product. This means a customer can receive changes to the software within 2 hours of the start of the feature.

How did we get to this point? By working collaboratively and practicing Mob DevOps and Mob Programming! In this session we will review the status of the team and how you can iterate toward a similar environment.

私は、Jenkinsプロジェクトの創始者、CloudBeesの創業者の一人として欧米の様々なソフトウェア開発の現場を見てきました。この経験から、雇用形態、ソフトウェア開発組織の作られ方、CI/CDなどの技法、cloud nativeなどのテクノロジの勃興の間に、密接な繋がりがある事がわかってきました。この発表では、これらの知見をまとめてアメリカ式のソフトウェア開発プロセスがどのように構築されているかを紹介します。

また、僕はここ数年日本のソフトウェア開発を世界水準へと思い色々な活動をしていますが、アメリカ式をただ輸入すればいいと思っているわけではありません。まずは、日本式のソフトウェア開発がどのような合理性に基づいてどのように行われているのか、日本式のソフトウェア開発のプロである皆さんから学びたいと思っています。その上で、皆さんと日本のソフトウェア開発プロセスはどのように進化していくべきなのか、一緒に考えを深めたいと思っています。

皆さん「文化的負債」という言葉をご存知でしょうか？

当社の主力ソフトウェア・プロダクトは誕生してから20年・25年といった歴史を経て今もなおバージョンアップ繰り返し、進化し続けています。この長い歴史あるプロダクトを開発してきた組織も、市場の要求と時代の変化に対応しながら成長を重ねて来ました。

ところで「技術的負債」とは我々エンジニアにとって常に付きまとう身近なリスクです。これを放っておくとプロダクトの品質や競争力が破綻することは良く知られた事実です。当社のプロダクトも歴史が長い分、この「技術的負債」との戦いの歴史と言っても過言では有りません。しかし、今回これと同等以上に着目したいのは、組織の健全性の指針とも言える「文化的負債」の方です。

書籍「Effective DevOps ―4本柱による持続可能な組織文化の育て方」では次のように表現されています。

【技術的負債とは、システム設計、ソフトウェアアーキテクチャー、ソフトウェア開発、技術の選択などの技術的な決定が最終的に生み出すもののことだ。一方で、文化的負債は、採用や解雇の決定、コミュニティの基準の制定や施行、組織の階層構造、価値観といった文化的な決定が最終的に生み出しているもののことである。 文化的負債にも技術的負債と同じことが当てはまる。つまり、いつか返済しなければいけないし、負債の原因となっている問題を長期に渡って手付かずにしていればいるほど、利息が蓄積して、将来負債から抜け出すことが難しくなる。(p314)】

私たちが今の組織でこの「文化的負債」に着目し、「アジャイルに行こう！」と叫んでからの8年間で実際に経験した、組織文化の変革のコツやメソッド、苦労したことや人相手の難しさ、それらの対処方法などについて発表したい。

ITの活用を前提に、あらゆる事項をより良い方向に変えていくDXを追い風として、ソフトウェアの開発･保守に要する時間短縮と品質の維持･向上を両立させるDevOpsの導入が多くの企業で進められています。

一方でDevOpsの導入から効果的な運用までに求められる技術は、昨今のクラウド技術の急激な進展に伴い、非常に広範囲かつ個々に深い理解が求められるようになっており、関連技術の習得は益々その難易度が増している事も事実です。

Cloud Nativeの実践には"手を動かしながら全体像をつかんでいく事"が肝要ですが、書籍やオンラインの情報は個別ツールの説明に終始するものが多く、全体像がイメージできないとお悩みの方も多いのではないでしょうか。

本セッションではDevOpsの事例やデモをご覧いただきながら、DevOpsを現場で実現するために学ぶべき技術要素とその学習方法をお話します。

DevOps Tools エンジニアを社内に増やしたいと考えているみなさま、必聴です。

機械学習を本番システムで活用するためには機械学習とソフトウェア両方の開発と運用が必要になります。その方法論や文化をMLOpsを呼びます。機械学習（ML）を組み込んだDevOpsという造語です。

本発表では機械学習を本番システムに導入する際に頻繁に発生する技術的、組織的な課題を説明し、課題を乗り越えるための方法や仕組み、チーム体制を実例を用いて解説します。具体的にはMLOpsを導入するタイミングや、導入時に必要なワークフローとシステム、役割分担等になります。本発表によって、聴講者が機械学習を本番システムで使い、ビジネス価値を生むための礎になることを目指します。

少数精鋭のチームの中、どんどん個人に依存していくタスクたち。
そんな中、キーマンの突然の離脱により課題の解決が誰もできなくなるプロジェクト。
知見も経験も無い大きな壁を前に、ただただ上を見上げるしかない担当者。
藁にもすがる思いで、頼った先には今まで見たことのない新しい文化があった。

一人ひとりがその道のパイオニア、分からないことがあれば分かる人に聞く、そんな仕事のやり方が常識だと思って過ごしてきた中でモブプロ・モブワークを通してわかった「チームとして働くこと」の大切さ。

その新しい文化に刺激を受け、個人としてもチームとしても成長した軌跡をお話します。
モブの「モ」の字も知らなかった人が、モブで働くことが当たり前のメンバーの中に飛び込むとどうなるのか？そして、それを受け入れる側はどう感じていたのか？

会社をまたぎ、一度も顔を合わせずフルリモートで問題解決を行っていくために僕たちがどんな風に仕事を進め、工夫をしたかをお話します。

会社をまたいだコラボレーションの結果が生んだ大きな成果、必聴です。

欧州のIndustry4.0などに影響を受け、2016年1月の新聞掲載を皮切りに始まったFactory-IoTプロジェクト。
世界130工場　2500もの製造ライン、数万あるといわれる設備をつないで、30％もの生産性の向上を図るというミッションを命じられた。

デンソーでは、ハードを用いたKAIZEN文化は進んでいた。しかし、ソフトになると、、、結局ベンダーパッケージを用いたIoTシステムを構築した。結果、目まぐるしい生産システムの変化の速さに追従できなかったのであった。

その後の2018年、クラウドやOSSの技術に優れたパートナーと協調し、「技術を手の内化」というスローガンのもと、内製のIoTシステムの開発に着手し、無事に2019年10月にカットオーバーに至った。そして、生産システムの変化や現場の困りごとにスピーディに対応できるようになったのであった。

喜びもつかの間、予測できない接続設備の増加、9000TPSを超えるmessage数、急なネットワークトラブルによるデータ欠損、データ増による性能遅延、ユーザからの止まらない問合せや、各種申請、、、開発どころではなくなり、連日連夜、障害対策会議が開催されるのであった。

そこでは、IoTシステムでどんな問題が発生しているかの見える化（可観測性）、それから、如何に自動化を図りながらインシデントを解決し、サービスレベル（SLA／SLO）を向上させていくのか、落とし穴にはまりながら、埋めていった、その軌跡を自戒の念を込めて、発表させていただきます。

Since 2018, we started to implement Cyber Security into DevOps process by running a DevSecOps program, which aims to shift left the Cyber security mindset to the development teams through promoting DevSecOps tools combined with the relevant training.

In this presentation, we will share our DevSecOps implementation experience and the DevSecOps model we established to promote DevSecOps across development teams. The first step is to introduce the DevSecOps tools, such as SAST, DAST, IAST and FOSS. Different DevSecOps tools (such as Checkmarx, Contrast and Sonatype IQ ) need to be integrated into development CICD pipeline to automatically discover vulnerability and produce reports.

In addition, we will demonstrate three different ways to provide cyber security training to help development teams gradually grow their knowledge to be able to fix the vulnerability discovered by DevSecOps tools.

Finally, we build up a DevSecOps maturity model to measure the level of development teams’ DevSecOps ability. Based on the maturity level, the cyber security assessment will be simplified to benefit the development team (speed up the delivery)

This presentation is for the people who have interest in DevOps transformation and how to integrate/left shift cyber security during DevOps process.

Jeff Sutherland氏、Martin Fowler氏、Taichi Ohno氏。世界の業務プロセスに変革を導いた彼らは共通的に「カイゼン」について強調しました。

彼らの本を読みエンジニアとしての道を歩んできた私たちにとって、「カイゼン」は第一の価値として認識されていると思います。

皆さんは、今日より良い明日のために何に力を入れてますか？毎日が忙しすぎて、何かを改善するどころかストレスだけ溜まってたりはしてないでしょうか。

楽天のランキングサービスグループは開発と運用、いわばDevOpsを実践していますが、そのプロセスに対しいくつか問題を抱えていました。開発の段階で発生するボトルネック、効率的だとは言えない運用環境。

何よりも問題だったのは、こういったボトルネックにおいて改善の文化が定着しにくいということでした。せっかく良いアイデアを思いついても、そのボトルネックから発生するコストの問題で後回しにするしかなく、そうなればなるほどチームの改善力はどんどん下がっていきました。

私たちランキングチームは２つの解決策を決め、それを同時に進め相乗効果を発生させることでこの状況を乗り越えようとしました。

ランキングチームが挑戦したトライアルそしてテクニカルな変更によるチームカルチャーの変化。またその後１年間の運用ストーリーまで！

より安全で良いサービスの提供のために、日々工夫を重ねているあなたのために、私たちのお話を特別に公開します。

コンポーネントが複雑化しその挙動を予測するのが難しいKubernetesの運用監視におけるオブザーバビリティ（Observability, 可観測性）について、その概要とSplunkを使ったアプローチについてお話しします。セキュリティやITインフラ運用のログ管理プラットフォームとして知られているSplunkですが、クラウド環境のオブザーバビリティへの取り組みを、デモを交えて解説します。

この10年は多くの変化がありました。

ソフトウェア開発プロセスにおいては、アジャイル開発の普及が進み、さまざまな現場でスクラムが活用されるようになりました。

技術面では、コンテナ技術やその管理の自動化が進み、システムはどんどん複雑になりつつあります。

一方で、テストや品質保証はどのように変わってきたでしょうか？

私はアジャイルコーチとして10年活動してきましたが、 最近話題の「DX（デジタルトランスフォーメーション）」の影響か、 開発に速さがより求められるようになってきたように感じています。

そして、その影響もあってか「テストがボトルネックになりがち」や 「マニュアルテストのチームがコストセンターになってしまった」という相談をよく受けるようになりました。

このセッションでは、アジャイル・DevOps時代におけるテストと品質について、

• 現在
• 戦略と戦術
• 組織未来

のお話させていただきます。

そして特に、「テスト・品質保証」について、現状と課題や求められる要件を整理し、未来のあるべき姿を、議論したいと思います。

我々の所属するソフトバンクの IT 本部は、主にキャリア事業を支える IT システムの開発、保守、運用を担っています。キャリア事業はユーザーの生活を支える重要なインフラであるため、堅実なキャリア品質のシステム構築として、自社のデータセンターのオンプレミスな環境で稼働するシステムを数多く開発してきました。一方で、近年ではビジネス環境の変化に伴い、Agile や CloudNative な開発にも積極的に取り組んでいます。

現在、全国のソフトバンクショップではスマホアドバイザーというスマホに関するあらゆる相談に対応するスタッフが在籍しており、スマホ教室などの様々なサービスを提供しています。スマホアドバイザーの業務を支援するシステムにおいて、自動化機能を可能な限り活用して、運用担当者の負荷の軽減を目的として、クラウド、Kubernetes を採用して、システム開発、および運用を行ってまいりました。当初は DevOps を目的としていたわけではありませんが、クラウド、Kubernetes によって、それまでの運用作業の質が変化し、結果として、開発と運用の組織の垣根を越え、運用の在り方、開発と運用の協業等、我々なりの DevOps を考えるきっかけとなりました。

このセッションでは、我々のスマホアドバイザーのシステム開発において、クラウド/Kubernetes を導入して、1 年程度運用してきて、得た知見、たどり着いた我々なりの DevOps、およびこれからについて共有できればと思います。

昨今のコロナ禍を受けて私たちは2020年2月以降、全面的な在宅勤務を余儀なくされました。リモートワーク環境下で変化を迫られたのが開発現場でのコミュニケーションです。もっぱら付箋とホワイトボードに頼っていた私たちは、新たな意思疎通の手段を用意する必要がありました。試行錯誤を繰り返してたどり着いたのは、ドキュメンテーションの軽量化やツールの徹底活用でした。アジャイル開発では「プロセスやツールよりも個人と対話」が重要なのは言うまでもありませんが、プロセスやツールで生産性や品質が大きく変わることも事実です。本セッションではフルリモート環境におけるスクラム開発のコツを実体験をもとに紹介します。

TBD

Software engineering may be difficult, but fostering a working environment that enables skilled engineers to perform their best can sometimes seem downright impossible. Every day, many engineering teams are battling a messy whirlwind of forces like unmovable deadlines, imposter syndrome, psychological safety issues, personnel/leadership conflicts, fierce technological preferences, and more. With teams more distributed all over the world than ever before, cultural differences can exacerbate many of these difficulties.

In this presentation, I’ll discuss tips, tricks, and techniques that technical leaders and managers alike can utilize to better coach engineering teams, including concepts like the definition of empathy (and, more importantly, what doesn’t count), the trust-influence relationship model, introducing new technologies in a meaningful and consumable way, and a 5-step process to provide teams confidence to own their new solutions moving forward.

** 日本語版もあります。

ここ最近、私の周りでは、テスト活動の範囲が広がっている事例が出てきているように感じます。

例えば、テストマニフェストでは、「ずっとテストし続ける」「品質に対してはチームが責任を持つ」と示しています。つまり、テストとはQAやテスターだけの取り扱いではなく、チーム全体でテストを常に考え続けることを表しています。

また、Dan AshbyのDevOpsにおける継続的テストの図では、実装前であるPlanの部分から本番環境適用後のMonitorまで、あらゆるところでテストができることを表現しています。

この継続的テストの図のうち、画像の左半分、特にPlanやBranchといった部分や更に前段階のIdeaの部分にテスト活動を持っていくことをShift leftのテストと呼んでいます。一方、画像の右半分の部分にテスト活動を持っていくことをShift rightのテストと呼んでいます。

私は今まで、RSGTやScrum Fest Osakaでの発表を通じて、Shift leftの事例を紹介していきました。また、書籍『Agile Testing Condensed』にもShift leftのテストを行う方法が多く紹介されています。

一方で、Shift rightのテストはどうでしょうか？実は開発者やSREチームではFeature Flagといった手法を用いることによってShift rightのテストを行う準備ができているかもしれません。ですが、Feature Flag部分に対するテストをどうすれば良いかまで考えている人は少ないかもしれません。また、Feature Flag以外にどのような手法があるのか知らない人も多いかもしれません。

そこで本発表では、書籍『Agile Testing Condensed』と書籍『Testing in DevOps』を参考にして、Shift leftおよびShift rightのテストについてご紹介します。

あなたのチームは「こんなテストでいいのかな？」と不安を持ったことがありませんか？
あなたの組織は「これが我々の品質保証だ！」と自信を持って進められていますか？

• スクラムチームのテストが上手くいっていない感じがするが、打つ手が見つからなくなってきた
• 所属している組織の品質を上げたいが頭打ち感がある
• テストや品質保証で外の力を借りようとしたが、イマイチだった（上手くいかなかった）

この発表では、ソフトウェアテストや品質保証に漠然とした悩みや不安を抱えている方に向けて、自信を持ってテスト活動を進めていくスタートラインをいくつかの例を使ってお伝えします。

この発表で扱う予定の例：

• テストケースを行き当たりばったりで作り続けてきたが、増やしても増やしても不安が消えないチーム
• あるチームで行ったテスト自動化を組織に横展開してみたが、メンテナンスコストが増える一方で品質が上がっている気がしない
• プロダクトの開発規模拡大のために外部のテスト専門会社にテストを依頼したが、期待したようなテストをやってもらえなかった

この発表で特にお伝えしたい点：

• テスト・品質保証のスキルは大きく4つに分類できる
  • Domain Knowledge：ドメイン知識…プロダクトに関わる固有知識・技術
  • IT Skills：ITスキル…開発そのものの技術（テスト自動化の環境構築なども含む）
  • Test Skills：テストスキル…モデリングやロジカルシンキング、パターン化能力、質問力などの技術（※ひたすら入力・打鍵・実行する作業スキルではない）
  • Soft Skills：ソフトスキル…コミュニケーションやファシリテーションなど他のスキルの下支えとなる技術
• どのスキルを使っているか？重視するか？を分析することで漠然とした不安から抜け出せる
• 足りないスキルを埋めるために何ができるか
• ソフトウェアテストは広大だ！

あなたが抱えるソフトウェアテスト・品質保証の漠然とした不安や頭打ち感を、この発表を通して一緒に紐解いてみませんか？
自信を持ってテスト活動を進めるためのスタートラインに一緒に立ちましょう！

When I refresh my memory and consider my whole testing life, I again realize that life is full of lessons. Whenever I think about this, I come up with a saying by John W. Gardner: “Life is the art of drawing without an eraser.” We are all making mistakes and it is not possible to manage each single piece of processes perfectly. Still; what we can remember is, with additional brush strokes, those mistakes can evolve into nice colors inside the big picture. Besides, in the next run, we may take precautions against possible mistakes.

In short, after the quick review of my career, I decided to collect the required soft skills for a tester. Being a tester requires lots of skills, but it is not holding all of them in an unnatural way. We are humans, no supermans.

組織の変革や新しいカルチャーを醸成するにあたって、何から始めるべきか？どのように進めるべきか？悩んでいるすべての方々にお届けしたいセッションです。

本セッションでは「次世代版 地域総合会社」を目指し、お客様のニーズに対応するために様々なデジタルトランスフォーメーション戦略、システム戦略に注力している株式会社北國銀行の現在進行形の取り組みを紹介します。

変革プロジェクトの中心となった岩間正樹氏をお招きし、どのように組織変革と新しいカルチャーの浸透を進めていったか、対談形式でお話をうかがいます。

北國銀行は保守的で多様性が足りず、年功序列や縦割りのカルチャーで、声が大きい人の意見がそのまま採用されたり、従来の仕様が踏襲されたり、お客様不在で仕様を決めたり、新しい発想が出てこない状況となっていました。

そのため、ステークホルダー全員がプロジェクトを推進するにあたり、今までとは違うマインドセットを持つ必要性を感じていました。

そこで、部署横断でチームを作り、業務をシンプル化しつつ統合して全体最適を図るために、ITプレナーズの「フェニックスプロジェクト DevOpsシミュレーション研修」を、6部署（銀行業務部門・マーケティング部門・IT部門）から合計36名が受講しました。

その結果、チームがどう変わったか、業務の進め方がどう変わったか、どのような成果が現れたかをお話しします。

=============================

※本セッションは株式会社ITプレナーズジャパン・アジアパシフィックのスポンサーセッションとして提案しています。

Agile Testingのチーム全体アプローチではチーム全員でテストや品質のことを考えていく必要があります。

チームメンバーは会話をしながら相互に理解を深めていくのですが、会話を促進するツールがいくつかあります。例えば、RSGT2021でJanetさんが提案していた品質スライダーや実例マッピング※などです。

今回はチームの会話を促進するツールの一つとしてテスト観点図※を紹介をします。
テスト観点図はチームメンバーが必要だと考えるテストの観点を集め、構造化したものです。

プログラマとテスターとプロダクトオーナーそして運用はそれぞれ製品に対して気にするところが違うのが普通です。
このテスト観点図をチームメンバー全員で早期に作成し、お互いの気になっていることを理解することでプログラマが設計、コーディングの前に必要な品質を意識することができ、バグの予防に役立ちます。

テスト観点図は価値のある成果物ですが、成果物そのものよりもそれを作り上げていくプロセスにこそさらなる価値があります。

※実例マッピング
実例マッピングについてはブロッコリーのブログに詳しく載っています。
https://nihonbuson.hatenadiary.jp/entry/ExampleMapping

※テスト観点図
テスト観点図はVSTePという手法の成果物の一つで、テスト観点を構造化した図です。
VSTePとは電通大の西康晴氏が提唱しているテスト開発の方法論です。
テスト対象についてチームでテスト観点を出し、構造化してテスト観点図を作ります。
そのテスト観点をベースにテストをどのように実施していくかを表した「テストコンテナ図」やテストケースのひな形になる「テストフレーム」を作り、チームとして納得感のあるテストを開発していきます。
http://www.jasst.jp/symposium/jasst16tohoku/pdf/S1.pdf

Preferred Networks（PFN）は深層学習などの最先端の技術を最短路で実用化することで、これまで解決が困難であった現実世界の課題解決を目指しています。コンピュータビジョン、自然言語処理、音声認識、ロボティクス、コンパイラ、分散処理、専用ハードウェア、バイオインフォマティクス、ケモインフォマティクスといった幅広い分野で研究開発を行っており、それを支えているのが Kubernetes を用いて構築しているオンプレミス/ベアメタルの GPU クラスタです。

本セッションでは、PFN が Kubernetes を用いてクラスタを運用するなかでどのような障害が起きるのかを紹介し、また障害対応をどのように自動化しているのかを具体的に使用/開発したソフトウェアを含めてご紹介します。また Kubernetes クラスタの管理、アップグレードの自動化にも取り組んでおり、それを実現する Cluster API についてもご紹介します。

自動車に代表される日本のハードウェアは高品質だ、と何となく思っている方は多いと思います。そうした製造業の企業はTQM（総合的品質管理）という品質管理の原則を確立し、ハードウェアの開発・生産をよりよくしてきました。しかし時代は変わり、彼らは今やソフトウェアが重要な役割を果たしたり、サービスと一体化し、アジャイル開発やDevOpsといったイマドキのスタイルを必要とする製品開発に、四苦八苦して品質管理の原則を適用しようとしています。

この発表では、発表者の経験から、高品質を生み出すTQMの考え方を以下の4つのマインドセットにまとめ、説明していきます。
- 品質という終わりなき旅
- 全員を愚直で賢くする
- 納得感の共感を高める
- 弱さに寄り添う

またこの発表では、品質を高め続けられる組織になるために、テスターはテストの技術や作業にのみ囚われてはいけない、というメッセージをお届けします。

この発表で特にお伝えしたい点：
- 品質を高め続けられる組織になるための4つのマインドセット
- TQMの考え方と、アジャイル開発やDevOpsといったイマドキのスタイルの類似性
- 知恵を生み出すために「矛盾ヲ抱擁セヨ」

この発表に興味を持って頂けそうな方々：
- 開発から疎まれているQAの方々
- ハードウェアとソフトウェアの両方を開発する組織のQAを再構築したいと思っている方々
- 「自分はテスターなのかQAなのか？」と悩んでいるテスターの方々

You have a vague impression that many Japanese hardware manufacturers develop high quality products such as automobile. They have established principles of quality management, called TQM, and optimized their process for large-scale hardware design and production. But as time flies, they are struggling to apply the principles to modern development such as agile and devops for software-intensive and service-oriented hardware products. Nishi will share his experiences in re-establishment of quality management in modern context for several large-scale manufacturers in Japan. He summarizes the concepts of TQM into four mindesets below:
- Journey into quality forever
- Make everyone perseveringly smarter
- Enhance co-confidence
- Nestle weakness
Nishi will also compare tester and QA, and suggest QA should be unchained from testing activities to establish a high quality organization.

The talk will focus on:
- Mindsets in high quality manufacturers in Japan
- Similarity between TQM and modern concepts, e.g. agile and devops
- To embrace conflicts and make insights for QA

Who will be interested:
- QA who has lost developer's trust 
- QA who will establish company-wide QA organization for both hardware and software 
- Test engineers who wonders "am I a tester or a QA?"

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

皆さんにとって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」、東宝「シン・ゴジラ」、ポリゴンピクチュアズのアニメ制作過程など、コンテンツ業界での制作過程の変化なども織り交ぜながら、私たちにできそうなことはなにか、探っていきたいと考えています。

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

Infrastructure as Code を導入してみたはいいけれど、デプロイしてみたらなぜか上手く動かない。そんな経験はありませんか？ 本セッションでは、実際の環境を構築する「前」に、IaC のコード自体に対してテストを行う手法について解説します。

ご存知の通り Infrastructure as Code (IaC) は、インフラをコードで定義することを通し、アプリケーション開発のベストプラクティスをインフラ領域にも輸入しようとする方法論です。IaC の考え方は近年急速に普及し、開発フローの一部として種々の IaC ツールを利用することは半ば常識のような状態にあります。

しかし同時に、IaC は銀の弾丸ではありません。特に組織的な導入を考えようとすると、得てして「なぜか上手くいかない」「余計に運用が辛くなってしまった」という声を聞くこともよくあります。

なぜこんな事態に陥ってしまうのでしょうか？ 本セッションの前半ではこの問題を言語化するために、「予測可能性」という考え方を導入します。IaC のデプロイ結果の予測しづらさがなぜ運用の辛さに繋がるのか、その構造を図解した上で、予測可能性を担保するための原理・原則を解説します。

では、具体的にその予測可能性を担保するにはどうしたらよいのでしょう？ セッションの後半では AWS を取り上げ、IaC の実践の中でいかにインフラの予測可能性を担保するのか、方法論や具体的なツールの適用について解説します。

IaC 特有の辛さに疲れてしまったあなたが、もう一度 IaC に光明を見い出すためのセッションです。

English follows:

「Scrum@Scale（S@S）を取り入れた100名ほどの開発組織で、スクラムに入らない独立したQAチームが活躍している」と聞いたら、もしかしたら奇異な感じを受けるかもしれない。スクラムではチームであらゆることが完結することを理想とするため、当然テスター（QAエンジニア・テストエンジニア ・などなど）もスクラムチームに入るべき、と考える方がスクラム実践者にとっては自然だからである。あえて、その自然に逆らって、私たちQAチームは独自のビジョンを掲げた「ビジョナリー・QA（Visionary QA）」として、独立した立場から品質向上という成果を上げようと奮闘している。このトークではそんな私たちQAチームの1年戦記をありのままに扱いたい。

開発プロセスの高速化が進み、多くの企業でアジャイル開発が取り入れられ、過去の当たり前が当たり前でなくなっている中で、QA界隈ではどうやって価値を提供するか頭を悩ませている。あくまでもテストにこだわる者もいれば、スクラムマスター・プロダクトオーナーの視野を得るべく資格を目指す者もいる。2009年に翻訳出版されたリサとジャネットによる『実践アジャイルテスト（Agile Testing）』（翔泳社）は国内のテスターに広く読まれているが、最近版元品切になっていることもあり、手に入りにくくなっている。

さて、テスターは異質な存在のひとつとして見なされている。ご存知の通り、スクラムガイドにはテストやQA活動をどのように行うべきか、言及されていない。3つのロールに「テスター」の文字は無い。よって、テスターのあり方はそれぞれの組織で模索するしかなく、特にテスターをスクラムチームに含めるべきか否かという議論は継続的に行われている。先にもあげたように、スクラム実践者にとってはテスターがスクラムチームに入ることは自然であると感じられ、実際そのようにしている組織が多いが、それぞれにメリット・デメリットがあることから、あらゆる組織で通じる答えは今のところ無さそうだ（テスターとして仕事をしてきたメンバーがスクラムチームの開発者の一員としてどれだけクロスファンクショナルに動けるか、という点が特にネックなように思える）。

このトークは、独立した立場で動くことを選んだQAチームの話だ。スクラムチームにテスターを迎え入れねばならないと思っている方にはそうでない可能性を示す一方で、やはりスクラムチームに開発者としてテスターを加えるべきだと結論づけるオーディエンスもいらっしゃるかもしれない。スクラムチームとテスターの一筋縄ではいかない関係を、1年間の実例をもとに、一緒に考えようではないか。

"In a 100-strong software development organization which runs Scrum@Scale, an independent QA team works well." ––it may sound strange to you. Ideally, in Scrum, everything should be done in one scrum team, so it is natural for Scrum practitioners that testers (QA engineers, test engineers, etc.) should join a scrum team. Daring to go an unnatural way, our QA team struggles to achieve quality improvement results from an independent standpoint as "Visionary QA" with its vision. I want to treat our QA team's year-long battle story as it is in this talk.

Development processes are getting faster and faster. Many companies are incorporating agile development. The commonplace of the past is no longer the norm. In this fast-changing age, the QA industry is struggling to figure out how to deliver value.  Some testers are more concerned with testing, while others aim for the certification to learn a Scrum Master/Product Owner's perspective. The excellent book, "Agile Testing" by Lisa Crispin and Janet Gregory (Addison-Wesley), which was translated in Japan in 2009 by the domestic publisher Shoeisha, has been widely read by testers in our country. Recently, however, it isn't easy to get due to out of print.

Testers tend to be seen as one of the heterogeneous entities. As you know, there is no mention in the Scrum Guide on how testing and QA activities should be done. There is no "Tester" in the three roles of Scrum. Therefore, each organization has no choice but to explore the nature of testers. In particular, there is an ongoing debate on whether or not testers should be included in Scrum. As mentioned earlier, it seems natural for Scrum practitioners to have testers join Scrum, and indeed many organizations are doing so. Still, since each has its advantages and disadvantages, it seems that we don't have an answer that works for all organizations at the moment. One of the problematic points appears to be how well testers can work cross-functionally as a "Developer" in Scrum.

With this session, which is about a QA team that chose to work independently, some attendees who feel testers should join a Scrum team may get a chance to notice the other possibility, and others may conclude that Scrum teams should still include testers. Let's take a look at the tricky relationship between Scrum and testers with the help of a year's worth of examples.

楽天のフリマアプリ「ラクマ」では年々、システム及び、組織の規模も拡大しており、インフラに関する設定の追加や変更依頼が日々増えてきてます。

また、品質を担保するために、ISMSやJ-SOX等監査を定期的に行っており、インフラに関する管理も監査の対象に含まれ、変更管理等に関しては、JIRAによるチケットの内容を証跡集めとして管理しておりました。

まだまだ成長フェーズにある段階なので、いかにシステムでオペレーションを軽減させるかが、日々の課題になっています。

その課題を解決するために、GitHub Actionsを使ってGitOpsを導入することにより、プルリクエストベースで安全なリリースが行えることに成功しました。

今回のセッションでは、以下の内容を共有できればと思います。

• GitHub Actionsを使ったTerraformの実行環境の仕組み
• Kubernetesのリソース管理をどのようなGitHub Actionsを組み合わせてGitOps化したか
• IaCを行う上でのブランチ戦略の考慮ポイント

As team grows together with services, multiple challenges appear during team's daily operation, ranging from the number of critical and blocker issue reported by QA to adaptation of (and to) agile processes.

Here we will share about Quality control, QA-automation, CI-CD activities done in our team.

Problems :

As a part of global team, Have you faced issues like below?

- Not able to complete stories in sprint?

- Members are not taking part actively in story planning, grooming?

- Complexity to manage tasks / time in global team?

- Regression testing takes man hour and time?

- Afraid to do operations on production?

- So many manual work, having mistakes frequently?

- Facing infrastructure / server issues?

Strategies :

We have implemented some activities inside Rakuten group to overcome these issues.

Here, You may learn

- Develop, test, deploy planned stories to staging within sprint scope.

- Planning with separate ticket for each single tasks

- Grooming with poker game

- Changing strategy of retrospective and action plan

- FDD and QA automation with non-stop releases of Micro-services

- Automations for repetitive / manual work

- CI pipelines with Jenkins Shared Libraries, containers & deployment on K8s etc.

Please join this session If you are interested in automations and improving agile processes.

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

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

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

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

QAに携わる人は一度は品質問題でお客様から怒られた経験はありませんか？
私は最近経験しました。

突然、マネージャーや経営陣に呼ばれて、
「お客さん怒ってるから、品質が語れるQAとしてお客さん先に行ってきて」
と言われました。
もちろん今まで自分が担当したことのない製品でした。

お客様と会話し、開発現場のプロジェクトにどっぷりとハマり、見えたものは、
お客様とチームとのギャップ、またチーム内のメンバー同士が主張するギャップでした。

書籍『Agile Testing Condensed』では「Whole-Team」の定義を「whoever you need to deliver the product」と提唱しています。
また、「Whole-Team Approach」は「all team members are responsible for the quality of thier product」と提唱しています。
つまりプロダクトをデリバリーする際に関連するメンバー全員が「Whole-Team」であり、Whole-Teamのメンバーは全員がプロダクトに対する品質の責任があります。

このトークでは、QAが品質問題を抱えている開発現場に入って、プロダクトマネージャーやチームメンバーとの信頼関係を構築して、徐々にWhole-Team（チーム全体）としてプロダクトをデリバリーできるようなチームになった話をします。

また、品質にフォーカスした開発を行うAgile Testingマインドセットを実践し、顧客との会話で得たビッグピクチャー（全体像）とユースケースの重要性を理解して、徐々に品質を改善したストーリーを話します。

ソフトウェア開発におけるオープンソースの採用は過去10年間で飛躍的に増加しましたが、その一方で、ハッカーが新たに公開されたオープンソースの脆弱性を悪用するのに必要とする時間は93.5%も短縮されています。開発チームが新たなイノベーションを提供する一方で、攻撃者もまたレベルを上げています。これは、Dependency Confusion（依存性の混乱）のような、最近注目を集めている破壊的なサイバー攻撃でも見られる事実です。攻撃者は、ソフトウェアのサプライチェーンにおけるセキュリティの脆弱性を悪用する意図と能力を兼ね備えており、場合によっては彼ら自身で脆弱性を植え付けることもあります。彼らは、自動化により規模を拡大しているほか、正確な標的化を通じて侵入の成功率を高めています。もし私たちがこれと同じことをして対抗しなければ（つまりDevOpsパイプラインにおいて直接セキュリティを自動化しなければ）、私たちは常にハッカーたちのなすがままになってしまうでしょう。

TBD