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

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

 
 

Outline/Structure of the Talk

  • DevOps論文の読み解き方
  • DevOpsの論文傾向
  • 100本紹介

Learning Outcome

  • ソフトウェア工学としてのDevOpsに対する取り組み傾向

Target Audience

DevOps初心者

schedule Submitted 5 months ago

Public Feedback


    • 60 Mins
      Keynote
      Beginner

      We'll talk about Team Topologies and related topics.

    • Kenta Sasa
      keyboard_arrow_down

      Kenta Sasa / Hiroki Arai - Welcome to DevOpsDays 2022!

    • Satoshi Yokota
      keyboard_arrow_down

      Satoshi Yokota / Tadahiro Yasuda - 価値あるソフトウェアをすばやく届けるために僕らがやってきたこと 〜経営者による組織とカルチャー作り〜

      60 Mins
      Keynote
      Beginner

      クラスメソッド株式会社とクリエーションライン株式会社の社長二人が、お互いが経験してきた生々しい話を赤裸々にお話しします。

    • クリス Chris Lucian
      keyboard_arrow_down

      クリス Chris Lucian / Alex Papadimoulis - Chris Lucian: Interview with Q&A

    • Kenta Sasa
      keyboard_arrow_down

      Kenta Sasa / Alex Papadimoulis - Welcome to DevOpsDays 2022, Day Two!

    • Ryo Mitoma
      keyboard_arrow_down

      Ryo Mitoma - 作る人から作りながら運用する人になっていく

      Ryo Mitoma
      Ryo Mitoma
      開発者
      サイボウズ株式会社
      schedule 4 months ago
      Sold Out!
      45 Mins
      Sponsor Talk
      Intermediate

      サイボウズのクラウドサービスは開発と運用の人員が分離されており本部も分かれています。
      これにより部門間の連携した作業の高コスト化や、各部門のミッションが対立するなど典型的な課題が存在しました。

      本セッションでは海外向けのクラウドサービスを国内オンプレミスのデータセンターから AWS へ移行するにあたり、開発と運用両方に取り組むために結成されたチームが、チームの制約に合ったデプロイメントパイプラインを構築していく中で得られた知見を DevOps の考え方を踏まえてお話します。

    • hagevvashi dev
      keyboard_arrow_down

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

      20 Mins
      Talk
      Intermediate

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

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

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

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

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

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

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

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

    • Shohei Ishikawa
      keyboard_arrow_down

      Shohei Ishikawa - BIMから建設DXへ -DX に向かうために、何を伝えるべきか

      45 Mins
      Talk
      Beginner

      2010年代、多くのウェブサービスが登場するなどOSSをベースに情報化社会が一気に進みました。一方、建設業界ではBIM(Building Information Model)と呼ばれる業界独自のデジタル化が行われてきました。しかし2020年代、建設業でもDXの波が訪れ「BIMから建設DXへ」と大きな変化が起きています。
      本セッションでは、ソフトウェア企業がプラットフォームサービスへと変化するにあたりユーザーにこのDXへの潮流の意味をどのように伝えるべきかという問題への取り組みを、DXの資料を元に解説します。

    • kamo shinichiro
      keyboard_arrow_down

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

      45 Mins
      Talk
      Intermediate

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

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

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

    • Fujihara Dai
      keyboard_arrow_down

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

      45 Mins
      Talk
      Intermediate

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

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

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

    • 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チームがどのように対応できるのか、皆様と一緒に考える時間にしていきたいと思います。

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

    • aki matsuno
      keyboard_arrow_down

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

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

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

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

    • Kouta Ozaki
      keyboard_arrow_down

      Kouta Ozaki - 開発チームにオーナーシップを委譲するという手法

      Kouta Ozaki
      Kouta Ozaki
      SRE
      Chatwork Co., Ltd.
      schedule 4 months ago
      Sold Out!
      45 Mins
      Talk
      Intermediate

      皆さんのチームはシステムデリバリのアジリティを最大化できていますか?
      現代の開発ではコードの負債、複雑なコミュニケーションパス、ボトルネックの存在など、いろんな要素によって簡単にアジリティの低下を招いてしまいます。

      Chatworkでは現在、アジリティを最大化するために次世代開発基盤の開発を行なっており、組織とシステムを刷新しアジリティを最大化しようと取り組んでいます。
      この中の取り組みの一つとして、開発者にシステム開発のオーナーシップを委譲することでコミュニケーションパスの最適化、責任の所在の明確化を行います。

      しかし、一口にオーナーシップを渡すといっても障壁はいろいろとあります。
      特にセキュリティや監査、信頼性などの考慮は一定の規模に育ったChatworkでは必ず確保しなければなりません。
      この課題を解決するためにChatworkではDevOpsの手法を使った開発者へのオーナーシップの委譲を推し進めていくという選択をしました。


      本セッションではChatworkがなぜその選択をしたのか、どのように実現をしているのか、難しさや課題としてどういうものがあるのかという話をSREの視点からぶっちゃけトークをしていきます。(怒られたらマイルドな内容になります)

    • Yotaro Takahashi
      keyboard_arrow_down

      Yotaro Takahashi - 右手にThe DevOpsハンドブック、左手にクックブック

      45 Mins
      Talk
      Intermediate

      タイトルは「もしも食べ専エンジニアがThe DevOps ハンドブックを読んだら」など、ほか候補やより良いアイデアがありそうかなと思っていますのでぜひコメントでご意見ください!

       

      私は妻と小学生の男の子二人、トイプードルの娘の5人暮らしなのですが、我が家の料理隊長である妻がアメリカに1年間行くことになりさぁ大変! 食べ専エンジニアの私が残された4人分の3食を毎日なんとかすることになりました!

      食べ専から日々の料理を作ること、いやいや作ることと食べることだけではなく後片付けや調達、作ることとそれにまつわる運用、、、

      あれ?これってDevOpsの原則が参考になるんじゃない?

      というわけで手に取ったのが仕事で過去手に取った『The DevOps ハンドブック 理論・原則・実践のすべて』です。

      このセッションでは、The DevOpsハンドブックに記載されている3つの道、すなわち①フローの原則、②フィードバックの原則、③継続的な学習と実験の原則、を通して、料理のワークフローの中でどのようにDevOpsの原則を実践してきたかの体験談をお伝えします。

    • Ryusuke Kimura
      keyboard_arrow_down

      Ryusuke Kimura - レガシーなシステムをリプレースした後に起きた開発組織の変化について

      Ryusuke Kimura
      Ryusuke Kimura
      System Architect
      VisasQ
      schedule 5 months ago
      Sold Out!
      45 Mins
      Talk
      Advanced

      2020年2月私が入社した時、システムは現代のモダンなシステムとの剥離が出てきている狭間でした。

      一方、会社はその後、すぐに上場をして、一気に組織の人数が増加しました。

      システムも社会的責任を果たせるようにアップデートをしなくてはいけないのは自明で、「必要最低限のアップデートをする」という選択ではなく、「全てを作り直す」という選択をして、システムリプレースを行っています。

      新しいシステムはモノリシックからマイクロサービス化に変更しましたが、私はマイクロサービス化に伴う組織的な変化、いわゆるコンウェイの法則を期待してマイクロサービス化の採用をおこないました。

      本セッションでは、マイクロサービス化を行った後に起きた開発組織の変化について赤裸々にお話できたらと思っています。

       

    • Kohsuke Kawaguchi
      Kohsuke Kawaguchi
      Co-CEO
      Launchable, Inc.
      schedule 5 months ago
      Sold Out!
      45 Mins
      Talk
      Intermediate

      フレイキーなテストは、根絶できない疫病のように昔から開発者をずっと悩ませ続けてきました。皆さんの開発チームでも、目にはついていなくても、フレイキーなテストがイライラを引き起こしたり、プルリクエストを失敗させたり、ホットフィックスの開発にストレスを上乗せしたり、必ずしているはずです。

      この問題に世界中の技術者達がどのように立ち向かってきたのか、Jenkinsの開発者としても有名な川口が紹介します。GoogleやGitHubのようなユニコーン会社から、もっと身近な等身大の会社まで、どういった取り組みが効果を上げてきたのかを見ていきます。皆さんの会社での取り組みにもきっと役に立つはず!

    • Yasunobu Kawaguchi
      keyboard_arrow_down

      Yasunobu Kawaguchi - DevOps の源流 : Flickr 10+ Deploys per Day のトーク (2009年) を再訪する

      45 Mins
      Talk
      Beginner

      昨年の DevOpsDays 創始者 Patrick Debois さんのトークでも触れられた、DevOpsという言葉ができるきっかけになった2009年の講演「10+ Deploys per Day」をとりあげます。その講演で何が語られたのか?について、短い時間でお伝えすることはしてきたのですが、今回は時間をちゃんと使って、話してみたいと思います。

      このトークの周辺の事情については私の過去のトークで、私の整理をお伝えしてきましたが、今回はこのセッションそのものをお伝えしまーす。

      DevOpsの時代
      https://speakerdeck.com/kawaguti/age-of-devops

      アジャイルとDevOps
      https://www.slideshare.net/kawaguti/agile-and-devops

      10+ deploys per day (動画)
      https://www.youtube.com/watch?v=LdOe18KhtT4

      10+ deploys per day (スライド)
      https://www.slideshare.net/jallspaw/10-deploys-per-day-dev-and-ops-cooperation-at-flickr

       

    • Ayana Yokota
      keyboard_arrow_down

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

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

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

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

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

    • T. Alexander Lystad
      keyboard_arrow_down

      T. Alexander Lystad - [Remote] It doesn't take much to be above average: The critical shortcomings of small software companies

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

      Small software companies may have personal and sensitive data on millions of users and process millions of euros worth of transactions, but many have appaling application security. In this talk, I'll mention some of the common shortcomings we come across and what can be done to address them.

      Based on analysis of hundreds of acquisition targets, vendors, customers and partners, it is clear that most small software companies are underinvesting in security to the detriment their future and customers. Based on our analysis, the danger zone seems to be <40 FTEs, <5 MEUR revenue. The good news is that major improvements in security can be made without the need for huge investments.

    help