location_city Tokyo schedule Apr 15th 03:00 - 03:45 PM place Hall B people 12 Interested

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

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

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

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

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

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

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

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

 
 

Outline/Structure of the Talk

1. エンジニアにとっての「カイゼン」の価値

 

2. 楽天ランキングチームが抱えていた問題

- As Dev Team

テストにかかるコストが大きすぎることから、カイゼンをためらってしまう風土が作られる。

- As Ops Team

リリースオペレーションの能率が低い。またミスした時のリバートに時間がかかってしまうなどの問題が起こりうる。

BlueGreenデプロイの仕組みを用意していましたが、それでは十分ではなかった。

 

3. 僕らが診断したボトルネック

 

4. 解決策の考察そしてカイゼンへのチャレンジ

- CaaS : Rolling modified product
- Web Test Automation : Ensuring quality of new feature

 

5. 導入直後の時点でチームの姿

- Systemic Change
- Cultural Change ★★★★★

 

6. 1年間運用してみてさらにわかったところ 

- デプロイ戦略やアーキテクチャーのさらなる改善

- より安全なA/Bテストをするには?

- ウェブアプリケーション以外のところでのさらなる活用の可能性(e.g. バッチサーバのコンテナ化)

- チームにはどういう変化がさらにあったかなど

 

7. 意味のある2021年を過ごすための新しい提案

Learning Outcome

カイゼン活動によって、チームの文化がどう変わっていくかわかります。

BlueGreenデプロイからCaaSへの変更の姿がわかります。

CICDにおけるきちんとしたテストの必要性がわかります。

カイゼンのためのやる気が出ます。

Target Audience

クオリティを担保した上でのリリースペースの加速化、さらに「カイゼン」をチームに移植したい人

Prerequisites for Attendees

I'll Mainly treat about CaaS / k8s / docker, Test Automation as technical part.

But it's no need to understand it beforehand.

My main topic is not only introducing technical trial but only fostering Kaizen culture.

Slides


Video


schedule Submitted 4 months ago

Public Feedback

  • Yasunobu Kawaguchi
    By Yasunobu Kawaguchi  ~  3 months ago

    プロポーザルの投稿ありがとうございます。
    トピックのカテゴリーをよりわかりやすく再構成しました。
    本プロポーザルのトピックにも反映しております。
    Thank you for submitting proposals.
    We have reorganized the topic categories to make them easier to understand.
    This is also reflected in the topics of this proposal.


  • Patrick Debois
    keyboard_arrow_down

    Patrick Debois - TBD: DevOps Interview with Q&A

    Patrick Debois
    Patrick Debois
    Father of DevOps
    .
    schedule 3 months ago
    Sold Out!
    60 Mins
    Keynote
    Beginner

    TBD

  • Michael Migliacio
    keyboard_arrow_down

    Michael Migliacio - [Remote] Leading Engineers To Water: The Art, Science, and Culture of Technical Coaching

    45 Mins
    Talk
    Beginner

    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.

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

  • クリス 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.

  • 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" -』を大幅に加筆修正し、日本語で発表します。

  • Yasuharu Nishi
    keyboard_arrow_down

    Yasuharu Nishi - 製造業の品質管理の考え方をイマドキのスタイルで読み解いてみよう

    45 Mins
    Talk
    Intermediate

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

  • Yasunobu Kawaguchi
    keyboard_arrow_down

    Yasunobu Kawaguchi - [スポンサーセッション] DevOpsの時代 ~ 変化を体現する"統合"の先駆者たちから学ぶ

    45 Mins
    Talk
    Advanced

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

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

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

  • Kohsuke Kawaguchi
    keyboard_arrow_down

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

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

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

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

  • Kazuki Suda
    keyboard_arrow_down

    Kazuki Suda / Masao Sakata - PFN の ML/DL 基盤を支える Kubernetes における自動化

    45 Mins
    Talk
    Intermediate

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

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

  • Shigeru Tatsuta
    keyboard_arrow_down

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

    Shigeru Tatsuta
    Shigeru Tatsuta
    Senior System Engineer
    SoftBank
    schedule 4 months ago
    Sold Out!
    20 Mins
    Talk
    Beginner

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

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

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

  • Yuya Kazama
    keyboard_arrow_down

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

    Yuya Kazama
    Yuya Kazama
    QA Engineer
    BizReach Inc.
    schedule 2 months 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部分に対するテストをどうすれば良いかまで考えている人は少ないかもしれません。また、Feature Flag以外にどのような手法があるのか知らない人も多いかもしれません。

     

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

  • Dan Yakabe
    keyboard_arrow_down

    Dan Yakabe / Hidefumi Yoshida / Hiroo Sawada / Masaya Ohishi / Tatsuki Fujii / yuta kuroda - ハードリッチな製造業ではじまったFactory-IoT ソフトウェア技術の手の内化から、DevOpsまでの軌跡

    45 Mins
    Talk
    Beginner

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

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

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

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

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

  • Hiroyuki TAKAHASHI
    keyboard_arrow_down

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

    45 Mins
    Talk
    Advanced

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

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

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

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

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

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

  • Ryo Mukai
    keyboard_arrow_down

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

    45 Mins
    Talk
    Beginner

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

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

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

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

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

  • Masato Wakahara
    keyboard_arrow_down

    Masato Wakahara / Ryusuke Tanaka - 決済戦国時代において、早く安全なシステムを提供するために with Azure

    45 Mins
    Talk
    Beginner

    時は今、ペイメント戦国時代。様々なペイがシェアを争い凌ぎを削っていた。
    そんな中私たちにはシェアを奪うためにスピードが求められたが、金融システムには守るべきコンプライアンスが鎮座して私たちの動きを鈍らせていた。

    スピードとコンプライアンス遵守という相反する課題を解決するために、
    私たちが実践した取組や直面した課題、それを実際に乗り越えた経験を元にお話しいたします。

  • Jumpei Ito
    keyboard_arrow_down

    Jumpei Ito - 品質問題から始まったWhole-TeamアプローチとAgile Testingマインドセットの改善物語

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

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

  • Michael Migliacio
    keyboard_arrow_down

    Michael Migliacio - [Remote] Beyond the Brain Teaser: Technical Interviewing with RESPECT

    20 Mins
    Talk
    Beginner

    "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.

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

  • Laurent Chaply
    keyboard_arrow_down

    Laurent Chaply / Emi Kobayashi - これって成功?継続的デリバリーだけでは足りないと気づいたチームの軌跡 / Is it a success? When continuously delivering features is not enough

    45 Mins
    Talk
    Intermediate

    ---- 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.

     

  • Kohsuke Kawaguchi
    keyboard_arrow_down

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

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

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

help