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.

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

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

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

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

自動車に代表される日本のハードウェアは高品質だ、と何となく思っている方は多いと思います。そうした製造業の企業は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?"

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

例えば、テストマニフェストでは、「ずっとテストし続ける」「品質に対してはチームが責任を持つ」と示しています。つまり、テストとは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のテストについてご紹介します。

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マインドセットを実践し、顧客との会話で得たビッグピクチャー（全体像）とユースケースの重要性を理解して、徐々に品質を改善したストーリーを話します。

Site Reliability Engineering (SRE) is rising quickly as the most innovative approach to IT Service Management (ITSM) since the early days of ITIL. This session will explore SRE from an ITSM perspective, including how SRE approaches common processes such as Service Level Management, Change Management, Incident Management, Capacity Management, and more.

In this webinar, you’ll learn:

• The history and definition of Site Reliability Engineering
• SRE Guiding Principles
• The importance of meeting Service Level Objectives
• SRE guidance for ITSM processes
• Why toil reduction and an engineering approach is important
• About the role of the Site Reliability Engineer
• Details of the SRE Foundation certification

Visual Studio has now integrated machine learning into your coding experience. Learn how to take advantage of the best in class tools to edit, test, navigate, cleanup, and debug your .NET code. In this demo packed session we’ll cover what’s new in Visual Studio including IntelliCode, code cleanup, new C# features, debugger, the test explorer, and the latest code fixes and refactorings.

"How would you move Mount Fuji?"  

Great question, but does an engineer need to know the answer in order to write great code?  No?  I don't think so either.

The technical interview is one of the most controversial, challenging, and stressful parts of an engineer's career. The more senior the engineering position, the  less relevant the brain teasers, algorithm quizzes, and puzzles that make up these interviews are to the evaluation of a potential candidate. And although this interview style first became famous at large tech corporations like Microsoft and Google, it has propagated across the industry to the point that courses are springing up in college campuses and bootcamps showing candidates exactly how to "crack" these interviews.

In the past, I’ve worked at a number of companies as a lead developer and in that role I spent a lot of time interviewing folks for technical positions. We weren’t allowed to choose our own process and had to follow the company’s rules. In that time I learned a lot about what works, and what doesn't work, for judging technical aptitude in an interview setting.

In this presentation I will talk about the difficulties of technical interviewing from both the interviewee and interviewer's point of view, and provide several helpful tools using the acronym RESPECT to improve the interviewing experience across the board.

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

---- English below ---

数年前からクライアントと一緒に見逃し配信サービスを提供するプロダクトに取り組んできました。

アジャイル、スクラム、そしていくつかのDevOpsのプラクティスに沿って、私たちはスキルがあり、新しい挑戦への意欲を持ち、スムーズに協力し合えるクロスファンクショナルなチームを構築することができました。

「顧客が要求したものを一貫して継続的に提供できるか」と問われれば、自信を持って「はい」と答えることができます。幸いなことに、サービスの利用はコロナの影響もあり、増え続けていました。一見すると、素晴らしい成功のように見えませんか？

しかし、ある日同僚から「どの機能がこの成功に一番貢献しているのか」と聞かれたとき、私たちは答えられず、疑問を感じました。クライアントのロードマップにあるものを提供することだけで成功なのだろうか？私たちは、よく揶揄される「機能工場」と呼ばれるものになってしまったのではないだろうか？

どうして機能工場になってしまったのか？

プロダクトビジョンの設定、UXリサーチやメトリクスへの取り組み、プロダクトマネジメントにおけるプラクティスに沿ってやってきたはずなのに、何かが足りない。

私たちは、ガブリエル・ベネフィールド氏が開発したMobius Loopフレームワークにインスピレーションを受け、機能のアイデアから開発を経て実際の収益に至るまで、チームとステークホルダーの両方が一枚の同じ絵を見て話すことができる、プロダクト開発フローの探求を開始しました。

このセッションでは、継続的に行ってきた実験と直面した課題を共有します。

------

We have been working for a few years with our client to build a video catch-up service.

Following Agile, Scrum and some DevOps practices, we were able to build a motivated cross-functional team with good skills, collaborating smoothly. We could confidently answer YES if asked “are you able to deliver what the customer requested consistently and continuously?”. Cherry on the top, the service usage was growing. 

Sounds like a success, doesn’t it?

But one day a colleague asked us “which feature contributed the most to this success?”, we could only answer “good question…” and started doubting: how does what our team builds really contribute to the service’s success? Is only delivering what’s on the client’s roadmap right? Didn’t we become what is often referred to as a “feature factory”, be it a well functioning one?

How could that happen? We followed the “good product manager” practices (having a product vision, doing UX research, having metrics etc …) but something was still missing.

We found a first source of inspiration in the Mobius Loop framework developed by Gabrielle Benefield and from there, started the quest of a product development flow where both the team and stakeholders can see the same picture, from feature ideas to development and delivery all the way to actual revenue.

In this talk we will share our experiments and the challenges we faced in this ongoing journey.

開発チームの生産性は、コードを書く周辺の様々な作業に大きく依存しています。この発表では、direnvやBazelを活用し、スクリプトなどの共有を一段と推し進めることで、小さな生産性の向上をチーム内で共有できるような環境を作った事例を紹介します。