ファクトから始めるカイゼンアプローチ ~「LeanとDevOpsの科学」を実践して~

location_city Tokyo schedule Apr 21st 01:00 - 01:45 PM JST place Hall B people 21 Interested

カイゼンを進めてみたものの、よくなっている感触を得られずカイゼン活動が続かなかった経験はありませんか?
これはファクトを十分に集めずに進めてしまったことが要因の一つと言われています。

「LeanとDevOpsの科学」という書籍ではfour keysと呼ばれるパフォーマンス指標や、four keysの改善促進が高いとされるケイパビリティが紹介されており、現在私たちは、これらの指標を計測し、ファクトを元により良く、速く、安全にプロダクト開発を続けていくことを目指しています。

特にfour keysの計測方法を紹介した記事は一定あるものの、実際に計測できるのか?、計測結果をどう活かしているのか?
など疑問に感じている方もいるのではないでしょうか。
今回のセッションではLeanとDevOpsの科学を実践して収集したファクトからどのようにカイゼンを進めているか、事例や書籍では読み取れない実践する上での勘所をお話します。
ビズリーチではファクトを元にカイゼンをする文化をつくろうとしており、今回の話はその一つです。

 
 

Outline/Structure of the Talk

  1. 自己紹介

  2. なぜファクトから始めるのか

  3. 「LeanとDevOpsの科学」とは

  4. 実施してわかった計測の難しさ

  5. 計測後の活動

Learning Outcome

ファクトを元に改善する方法を知ることができます。

「LeanとDevOpsの科学」の活用方法がわかります。

Target Audience

チームや組織をより良くしたいと思っている人。特にエンジニア。

schedule Submitted 3 months ago

  • Mesut Durukal
    keyboard_arrow_down

    Mesut Durukal - Common Pitfalls and Life-saving Solutions in Agile Testing

    90 Mins
    Keynote
    Beginner

    Motivation: I have experienced a lot of challenges in both technical and social manners and tried to develop solutions to cope with them throughout all the testing activities that I was involved in. Eventually, I have wrapped them up to make a list of common pitfalls which can be encountered by any tester and some golden rules to successfully get rid of them and manage a test project. 

    The most common problems are:

    • In continuous testing environments, due to time pressure, sometimes Quality focus may be shifted. How can we ensure to stick to the correct mindset even under stress?
    • While trying lots of approaches, how can we optimize the best way? How can we decide to go with it? How can we monitor the progress, trends and results of each single POC?
    • Test Reliability & Test Smells
    • Efficiency

    Some fundamental solutions are:

    • Being truly agile: Adapt new solutions quickly.
    • Manage the progress: Be aware of what is going on by setting KPIs to track & monitor with tools like CloudWatch, Grafana
    • Technical part: Automation principles for the sake of robustness. Solutions to reduce flaky tests & analysis effort & costs.
    • Holistic testing!

     

  • Yoshiyuki Ishikawa
    keyboard_arrow_down

    Yoshiyuki Ishikawa / Yosuke Kushida / Kei Tanahashi - カオナビのDevOps実践 ~ 運用自動化・テスト自動化の秘訣 ~

    45 Mins
    Sponsor Talk
    Beginner

    カオナビでは、自社システムの運用・保守を日々行っていく中で、定常業務を手動で対応してきました。
    しかし、開発規模・運用規模の拡大に比例して作業量も増加し、手動での運用に限界を感じるようになっていました。

    起きていた問題としては、主に
    ・「運用でカバー」する事による作業時間の圧迫
    ・自動テストの整備不足による手動テスト工数増加
    ・手作業によるヒューマンエラーリスク
    です。

    この問題の解決策を模索していく中で、DevOpsという単語をよく見るようになりました。
    開発部門の中でも2020年頃からDevOpsへの関心が高まり、積極的に自動化・見える化・効率化に取り組むようになりました。

    その中でも、特に注力したのが下記の3点です。
    ・業務自動化用サービスサイトの開発
    ・リリース自動化
    ・E2Eテスト開発

    本セッションでは、上記対応を進めていく中で、発生した課題とそれに対する有効な取り組み、取り組んだ結果得られたものについてお話します。

  • hagevvashi dev
    keyboard_arrow_down

    hagevvashi dev - 食べログのソフトウェアテスト自動化デザインパターン

    20 Mins
    Talk
    Intermediate

    食べログは誕生してから17年の歴史を持つプロダクトとなりました。
    そのプロダクト開発はすべて自社開発で、開発もQAもすべて自分たちで行ってきました。
    しかしながら、一般的なQA組織が食べログにできたことがなく、開発者が開発とQAどちらも行ってきました。

    そのため、食べログではテスト自動化前、手動テストにおいて

    • コード修正後のフィードバックが遅い
    • テストが再利用できない

    と言った課題があり、テストの負担が大きくなりがちでした。

    このテストの負担を減らすため、QA専門の組織を立ち上げ、テスト自動化の導入をすることにしました。
    テスト自動化を導入するにあたって、テストが不安定になるなどのいくつかの課題が生じましたが、戦略的にテスト自動化を導入し解決しました。

    本セッションでは、食べログにテスト自動化を導入する際に生じた課題と解決策を

    • アーキテクチャ設計
    • パイプライン設計
    • フレームワーク設計
    • テストケース自動化設計
    • インフラ設計

    などのテスト自動化導入パターンとしてまとめました。
    このパターンをもとに、テスト自動化導入を成功させる秘訣を紹介します。

  • Fujihara Dai
    keyboard_arrow_down

    Fujihara Dai - CI/CDパイプラインにE2Eテストを統合する

    45 Mins
    Talk
    Intermediate

    アジャイル開発やスクラムによって、チームごとに開発のリズムが整えられてきました。さらに、CI/CDの登場で、ビルドからデプロイまでのパイプラインプロセスも自動化されるようになってきています。

    このセッションでは、CI/CDパイプラインにブラウザレベルのE2Eテストを統合する方法を検討します。デモなどを通して、どこでどういうテストを自動実行するのがよいのか? を探求します。

    テスト自動化には様々なレベルがあります。広い意味ではユニットテスト、結合テスト、リグレッションテスト、パフォーマンステスト、セキュリティテストなどが自動化可能です。このセッションでのテスト自動化は「ブラウザレベルのE2Eテスト」を中心に話します。

  • Yuki Nishimura
    keyboard_arrow_down

    Yuki Nishimura - Airワークのサービス拡大に向けて課題を対応する中で見えたDevOpsの重要性と歩み

    45 Mins
    Talk
    Beginner

    昨年より「Airワーク 採用管理」のサービス拡大に伴いアーキテクトとしてシステム改善に関わりました。
    Airワークはクラウド(AWS)で構築されたサービスで参画当初以下のような問題がありました。

    • DB負荷が不定期に高騰する
    • アラート通知が月1000件以上発生
    • AWS障害発生 → 再発対策の流れがうまく回ってない
    • モニタリング基盤はあるものの何を見るべきかの更新がされていない
    • デプロイ、切り戻しに時間がかかる

    オンプレでの開発・運用経験を活かして、課題は一通り対応してシステムにはいっときの平穏が訪れました。
    しかし、この平穏はそう長くは続かないという予想もしていました。
    長期にわたる平穏のためには何が必要でしょうか。そんな時、対応していた時の気づきを思い出しました。

    「これらの問題、アプリの問題は開発チームで解決することができたはずだし、インフラチームは専任でいてインフラの問題も解決できたはずだ。解決できたはずの問題が未然に防げなかったのはなぜだろう」

    ここで、クラウドのような変化の激しい基盤では特にDevOpsが重要になると気づき、アプローチを始めていきました。

    このセッションではAirワークで実施した運用課題の改善事例とそこから得たシステム運用を安定化させるための実践トライ, 考え方についてお話ししようと思います。

  • Yukio Okajima
    keyboard_arrow_down

    Yukio Okajima / Yotaro Sato - コンプライアンス対応をチームの力に ~ 監査人が考える今後のDevOps

    45 Mins
    Talk
    Intermediate

    特にエンタープライズな領域で、DevOpsやアジャイルの適応範囲が広がるに従い、コンプライアンス要件への対応に苦労されているチームは増えているのではないでしょうか?
    例えば、次のようなお悩みです。

    • コンプライアンス要件では開発者と運用者の分離が求められているが、それでどうやってDevOpsするのか?
    • コンプライアンス要件では役職による承認を求めるが、それでどうやって自動化されたパイプラインを構築するのか?

    本来、コンプライアンス対応はビジネスの一部です。上手に対応することで、競合他社を一歩リードすることができます。しかし、このような状況が続いてしまうと、チームはスピードとモチベーションを失い、DevOpsで目指すビジネスの価値が損なわれてしまいます。

    そこで、DevOpsチームのコンプライアンスへの向き合い方について示唆を提供すべく、PwCの監査人と永和システムマネジメント Agile Studio のエンジニアが協力し、DevOpsとコンプライアンスを共存させるためのレポートと参照実装を公開させていただきます(※ 正式公開は3月頭の予定)。

    このセッションでは、実際にレポートをまとめたPwCの佐藤さんをお招きします。参加者からの、コンプライアンス対応における具体的な悩み事に直接お答えいただくことで、DevOpsチームがどのように対応できるのか、皆様と一緒に考える時間にしていきたいと思います。

  • 45 Mins
    Talk
    Beginner

    Do bugs speak?

    Yes, they do. People speak different languages like English, German, French, Chinese etc. But is communication to bugs possible? It is important to understand them, because they really tell us something. There is valuable information underlying the defects of a software, and information mining from defects promises for improvements in terms of quality, time, effort and cost.

    Problem Definition

    A comprehensive analysis on all created defects can provide precious insights about the product. For instance; if we notice that a bunch of defects heap together on a feature, we can conclude that the feature should be investigated and cured. Or we can make some observations about the severity or assignee of similar defects. Therefore, there are some potential patterns to be discovered under defects.

    Wrap-up

    Defect analysis is very important for QA people, and especially for QA managers. We utilize lots of aspects to get an idea about the product itself or our procedures. For instance while monitoring defect distribution across testing types, we will discuss how to get an idea about the quality of our testing approach. I.e whether we are applying all types in a balanced way. (functional, performance, documentation, etc.) Or over another graph, in which we track the gap between open defects and resolved defects, we will discuss what action items we can take when the gap widens. Finally, with ML assistance, we will see how we can reduce manual effort and cost.

    Results & Conclusion

    In this session, we discuss data mining from bugs and usage of ML in defect management. Objective of the study is:

    • To present in which ways defects can be analyzed
    • To present how ML can be used to make observations over defects
    • To provide empirical information supporting (b)

     

  • T. Alexander Lystad
    keyboard_arrow_down

    T. Alexander Lystad - [Video] Measuring Software Delivery and Operational Performance to improve commercial outcomes

    T. Alexander Lystad
    T. Alexander Lystad
    Chief Cloud Architect
    Visma
    schedule 6 months ago
    Sold Out!
    45 Mins
    Talk
    Beginner

    In this talk, I summarize the evidence that shows how engineering performance drives commercial performance, including Visma's own internal research. I'll show why and how we measure Software Delivery and Operational Performance across ~100 teams and how we use it to improve commercial results.

  • 45 Mins
    Talk
    Beginner

    DevOpsは論文が大量に出るまでに成長した概念になりました。書籍を読めどもまだまだ実践が不足している自分は論文を200本前後読んでみました。そこで今回はDevOps素人かもしれませんが、DevOpsについて言及されている論文を100本紹介します。

  • aki matsuno
    keyboard_arrow_down

    aki matsuno - 金融×Dev×Ops~5年間DevOpsを実践してきたチームの体験記~

    aki matsuno
    aki matsuno
    engineer
    -
    schedule 3 months ago
    Sold Out!
    20 Mins
    Talk
    Beginner

    ミッションクリティカルな性質を持った顧客業務に対応するために、DevOpsを実践したシステム開発を金融領域で5年間行ってきました。
    1秒の処理遅延が数億の損失に直結し得るシステムにおいてDevOpsを実践することで、多数の困難に直面することになりましたが、貴重な経験が多数得られ、DevOpsの意義も実感することができました。

    本セッションでは、実際にDevOpsを5年間実践しているチームの話や5年間実践してきて得られた経験をお話することで、金融領域においてDevOpsを実践することで得られる意義や、DevOpsを実践しているが故に発生した苦難をはじめとした日常業務のリアルをそのままお伝えします。
    また、セッション後半では、DevOpsを継続的に実践していくにあたって個人的に重要だと感じた点についてもお話できればと思っています。

  • Ayana Yokota
    keyboard_arrow_down

    Ayana Yokota - DevSecOpsを始めよう!セキュリティの新常識「SBOM」を活用した開発・運用

    Ayana Yokota
    Ayana Yokota
    Developer Advocate
    JFrog
    schedule 3 months ago
    Sold Out!
    45 Mins
    Talk
    Beginner

    開発と運用のコラボレーションを前提とした「DevOps」は広がりつつありますが、そこにセキュリティも加わった「DevSecOps」に馴染みはありますか?いや、この用語自体が大事なわけではないので言い換えます。セキュリティを加味した開発にどれほど積極的に取り組めていますか?セキュリティ部門の方と協業できていますか?

    このセッションでは、普段の開発フローになるべく効率よくセキュリティの考え方を組み込み、当たり前の取り組みとして脆弱性の管理や対策を行う手法を紹介します。特に、自前のコードに比べて関心が薄れがちな、OSSを始めとする外部から取得したライブラリを安全に使うことの大切さ、そのために活用できる「SBOM (Software Bill of Materials/ソフトウェア部品表)」についてお伝えします。

    セキュリティに苦手意識のあるアプリケーションエンジニア、対策したいけど何から始めていいか分からないマネージャーの方などにオススメです。「SBOM気になってたんだよね」という方も「正直セキュリティは分からん」という方も大歓迎です!

  • Gal Shelach
    keyboard_arrow_down

    Gal Shelach - SLA is for lawyers, SLO is where the money hides

    20 Mins
    Talk
    Beginner

    We have thousands of frontend servers in 7 data centers serving over 500k HTTP requests per second. They all expect to answer as quickly as possible to meet our SLA 

     

    Having said that, not breaking the SLA is one thing, but how to define the SLO is another. Let's say our SLA has a response time of p99 < 1000ms. This gives us a wide range where we can determine the SLO. This gives us a wide range where we can determine the SLO. 

     

    It may seem logical to set the SLO as low as possible. This way, we are less likely to break our SLA. What if I tell our customers that we have a magic feature that boosts revenue and only takes 400ms? Should we then define a different SLO? Maybe we should embrace the risk of breaking SLA from time to time but to have bigger revenue most of the time?

     

    My lecture will describe three systems we developed to utilize our system dynamically to gain an RPM-oriented SLO. Those are Java infrastructures we use internally to provide the most valuable responses to our customers within the limits of our Service Level Agreement.

  • Omar Galeano
    keyboard_arrow_down

    Omar Galeano - How to communicate the ROI of test automation to your business - テスト自動化のROIをビジネスサイドに伝える方法とは?

    Omar Galeano
    Omar Galeano
    Quality Engineering Principal
    Slalom
    schedule 3 months ago
    Sold Out!
    20 Mins
    Talk
    Intermediate

    In the era of modern software development, test automation has gone from a ‘nice to have’, to a critical component of delivering quality software at velocity.

    Business decision makers generally agree that test automation is a good idea, but may hesitate to commit appropriate resources, especially when budgets or deadlines are tight.

    We will interactively walk through scenarios that highlight the key factors that deliver test automation value. You will learn how to quantify the ROI of test automation and influence fiscally-minded decision makers with confidence!

    1*xhslp76-jPekWH_lYdfqqQ.png

    Note:Simultaneous interpretation will be provided in English and Japanese for this session, so please feel free to attend even if you are not comfortable with English!

     

    現代のソフトウェア開発において、テストの自動化は「あったらいいな」程度のものから、高品質なソフトウェアを迅速に提供するための重要な要素となっています。

    ビジネスの意思決定者は、テスト自動化が良いアイデアであることには同意しつつも、特に予算や納期が厳しい場合には、適切なリソースの投入決定にはためらうかもしれません。

    本セッションでは、テスト自動化の価値を高めるために、重要な鍵となる要素をシナリオを用いながら対話形式で紹介します。また、以下について学ぶことができます。

    ・テスト自動化のROIを定量化方法

    ・財政観点を重要視する意思決定者に対して自信を持って切り込む方法

    ※なお、本セッションは英語・日本語の同時通訳がつきますので、英語が苦手な方もお気軽にご参加ください!

     

  • Soichiro Seike
    keyboard_arrow_down

    Soichiro Seike - Enabling Team による Developer's Experience の向上への投資

    Soichiro Seike
    Soichiro Seike
    Professional
    Simplex
    schedule 4 months ago
    Sold Out!
    20 Mins
    Talk
    Beginner

    「トイルに悩まされて機能開発が思うようにできない」「Cognitive Loadの高い開発プロセスで少しの変更が難しい」と、疲弊しがちな開発組織の改善に取り組んでいる現状について話そうと思います。

    具体的には

    • 自社で初めてのSaasモデル型でのサービス提供を目指すチームが、どのような環境の変化に苦しめられたのか
    • TeamTopologiesの考え方を参考に、Enablingチームを組成し、どのような活動を続けてきたのか

    についてお話しします。

help