TBD

 
 

Outline/Structure of the Keynote

TBD

Learning Outcome

TBD

Target Audience

TBD

schedule Submitted 4 weeks ago

  • Hiroyuki Ito/伊藤 宏幸
    keyboard_arrow_down

    Hiroyuki Ito/伊藤 宏幸 - Testable Infra: Cloud-native技術をフル活用した、「テスト」の諸問題の刷新的解決案

    45 Mins
    Talk
    Advanced

    皆さんは、システムのテストをする際に、次のような問題を経験されたことはないでしょうか?

    • テスト環境の準備の工数がバカにならない
    • テストデータを複数人・チームで共有していて、気軽にテストできない
    • 外部サービスと接続できず、必要なテストができない

    これらの問題は、開発者・QAなどのシステム関係者にとって、テストに対する非常に大きな技術的・心理的障壁となります。加えて、十分なテストを行えないことによる本番障害の多発にもつながります。

     

    私たちのチームは、これらの問題を解決すべく、Cloud-native技術を駆使して、2020年に「Testable Infra」という社内インフラを構築し、運用を開始しました。加えて、これを複数のシステム開発プロジェクトに導入し、実際に上述のテストの諸問題の改善という成果が出始めています。

     

    このセッションでは、「Testable Infra」のコンセプト、設計と技術の詳細、およびこれを活用したシステム開発の未来像についてお話しします。

    なおこのセッションは、2020年12月に中国で開催された「TOP100 Summit 2020」で発表した『Make testing easier technically and psychologically with Kubernetes - Innovation of testing distributed systems with "Testable Infra" -』を大幅に加筆修正し、日本語で発表します。

  • Woohyeok Aaron Kim
    keyboard_arrow_down

    Woohyeok Aaron Kim - Roll your Product with Kaizen Culture(Let's 'Tech' the initiative (Renewed for 2021))

    45 Mins
    Talk
    Advanced

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

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

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

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

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

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

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

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

  • クリス Chris Lucian
    keyboard_arrow_down

    クリス Chris Lucian - Mob DevOps & Mob Programming

    45 Mins
    Talk
    Beginner

    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.

  • Kohsuke Kawaguchi
    keyboard_arrow_down

    Kohsuke Kawaguchi - 育児的ソフトウェア開発

    Kohsuke Kawaguchi
    Kohsuke Kawaguchi
    CTO
    CloudBees, Inc.
    schedule 5 days ago
    Sold Out!
    45 Mins
    Talk
    Beginner

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

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

  • Yuya Kazama
    keyboard_arrow_down

    Yuya Kazama - DevOpsの組織におけるテスト活動の在り方

    Yuya Kazama
    Yuya Kazama
    QA Engineer
    BizReach Inc.
    schedule 6 days ago
    Sold Out!
    45 Mins
    Talk
    Beginner

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

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

    20200418161646.png

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

    model-2.jpg?w=820

    この継続的テストの図のうち、画像の左半分、特に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部分に対するテストをどうすれば良いかまで考えている人は少ないかもしれません。

     

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

    また、我々の組織で行っているShift rightのテストの事例もご紹介できればと考えています。

  • Shigeru Tatsuta
    keyboard_arrow_down

    Shigeru Tatsuta - Kubernetes 導入から始める DevOps について

    Shigeru Tatsuta
    Shigeru Tatsuta
    Senior System Engineer
    SoftBank
    schedule 1 month ago
    Sold Out!
    20 Mins
    Talk
    Beginner

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

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

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

  • Jumpei Ito
    keyboard_arrow_down

    Jumpei Ito - 「お客さん怒ってるから謝ってきて」から始まったWhole-TeamアプローチとAgile Testingマインドセットの改善物語

    Jumpei Ito
    Jumpei Ito
    QA Engineer
    WingArc1st Inc.
    schedule 1 week ago
    Sold Out!
    45 Mins
    Talk
    Beginner

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

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

    お客様と会話し、開発現場のプロジェクトにどっぷりとハマり、
    見えたものは、お互いが主張するギャップでした。

    このトークでは、QAが開発現場に入って、
    チーム全体でデリバリーできるようなチームビルディングと、
    品質にフォーカスした開発を行うAgile Testingマインドセットを実践し、
    徐々に品質を改善したストーリーを話します。

  • Ryo Mukai
    keyboard_arrow_down

    Ryo Mukai / Naomichi Shimazu / Susumu Tomita - 「ログイン画面が開きません」から始まるチーム改革の軌跡

    45 Mins
    Talk
    Beginner

    知見も経験も無い大きな壁を前に、ただただ上を見上げるしかない担当者。
    藁にもすがる思いで、頼った先には今まで見たことのない新しい文化があった。

    その新しい文化に刺激を受け、個人としてもチームとしても成長した軌跡をお話します。
    会社をまたいだコラボレーションの結果が生んだ大きな成果、必聴です。

  • Kohsuke Kawaguchi
    keyboard_arrow_down

    Kohsuke Kawaguchi - 開発環境、共有のススメ

    Kohsuke Kawaguchi
    Kohsuke Kawaguchi
    CTO
    CloudBees, Inc.
    schedule 5 days ago
    Sold Out!
    5 Mins
    Lightning Talk
    Intermediate

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

  • Hiroyuki TAKAHASHI
    keyboard_arrow_down

    Hiroyuki TAKAHASHI / Yasuko NAITO - 文化的負債との戦い: 老舗ソフトウェア開発会社でアジャイル変革を仕掛けた7年間

    45 Mins
    Talk
    Advanced

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

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

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

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

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

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

help