We'll talk about Team Topologies and related topics.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

昨年の 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

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

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

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

Value Stream Mapping を体験するワークショップです。 みんなで一緒にValue Stream Mappingを使ったプロセスの見える化・カイゼン案の検討を実際に体験してみましょう。

Value Stream Mapping = ソフトウェア開発工程の流れ(価値の流れ)を見える化するために作成するプロセス図です。アイデアが生まれてから顧客に対して価値が届くまでの全行程を見える化することによって、ムダな作業や非効率なフローをチーム内で共有することができるようになるため、カイゼンに役立てることができます。

４、５人でグループを作ってグループワークを行います。Value Stream Mapping が描けるようになるだけではなく、チームで作った時の効果も感じられると思います。

今回はOnlineということでDiscord＋zoom＋muralを使って実施しようと思っています。オンラインでワークショップってどんな感じなんだろう？と興味がある方も是非参加してみてくださーい！

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

具体的には

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

についてお話しします。