DevOps Days Tokyo 2018 参加レポート

はじめに

深澤です。DevOps Days Tokyo 2018が2018年4月24日〜25日にかけて大崎ブライトコアホールで開催されました。初参加のレポートです。

どんなカンファレンスか

DevOpsというキーワードを元に、二日間に渡ってキーノートセッションや2トラックのセッション（いずれも英語/日本語 同時通訳付き）、またオープニング/クロージング/ネットワーキングパーティなどが行われました。参加者は200名〜300名（多分）、私服:4/スーツ:6（独自調査)でした。
漫談から始まる場作りや、いい感じにフランクな司会など、リラックスした雰囲気作り。また Mentimeter を使っての問い対して参加者が回答してビジュアライズされた集計結果が見れるのも、一体感の高まる楽しい仕掛けでした。

最後のクロージングセッションの様子。”Collaboration”や”文化”といった単語が多く寄せられていました。

DevOpsってなぁに

DevOps Days Tokyoを通した僕の今の理解としては‥
ビジネスの変化が加速し続け、各業界でイノベーションが起こっている。そんな背景の中で、いかに早く価値ある”と思われる”アイデアを形にして市場に投入し、フィードバックを得るか。そのフィードバックから得た情報を元に次のより良いものを投入し続けられるか。が価値を生み出し続ける鍵になっている。 それに適応するための考え方や活動に DevOps という名前をつけてる。と考えています。

セッション

参加して印象に残ったセッションを紹介します。

オープニングセッション

牛尾さんとアレックスさんの漫才から始りましたw

「より良く、より早く、より安く」
- エンジニア：ビジネス価値を伝えよう
- ビジネス：プロセスと技術を理解しよう

Transformation: How big can you dream? [Stas Zvinyatskovsky]

アジリティを高めるための足かせとして、企業/組織間コラボレーションが出来てない、デリバリのプロセスが遅い、などがある。 特定の顧客に対して価値を提供するの目標だが 価値は本番に適用しないと分からない、Backlogは仮説なんだよというメッセージがありました。また、それを達成するには（部分最適ではなく）全体的な変化が必要で、企業の仕組みを変える必要があり、それには数年かったり、痛みを伴う場合もある。なのでトレーニングを受けるのが必要、として終わりました。

DevOpsでデジタル変革　〜製造業デンソーの挑戦〜 [Seiichi Koizumi]

デンソーが目指すMaaS(Mobility-as-a-Service) にたどりつくために、愚直にシリコンバレーのやり方にならってデザイン思考やアジャイルな考えが方を取り入れている。また、プロジェクトルームを用意してScrumを実践している、などデンソーが本気で取り組んでる様子が伺えるお話でした。

フルマネージドなAWSサービスで実現するコンテナへの継続的デリバリー [Atsushi Fukui]

AWSが考えるDevOpsは、 ボトルネックを取り除き、フィードバックループを早く回す こと。それを構成するのは主にCulture/Practice/Toolの3つ。その中でもAWSが提供するToolに焦点を当てていました。
CodeCommit/CodeBuild/CodeDeploy/CodePipeline/CodeStar の Code n兄弟やオンラインエディタの Cloud9、またコンテナ向けサービスAWS Fargate / Amazon EKSなど、開発に集中できる環境を紹介。 最後に オーナーシップを持つ事が大事 という事で締めました。

Applying DevOps to an organization: a tough but successful journey [Jan de Vries]

DevOpsエバンジェリストとして企業を支援している。大きいのは組織的な部分の変化。マネジメントやエンジニアへのプレゼン、テスト自動化、組織の連携などを支援している。そして同じ会社全体の為に働いているのか？自分のサイロを最適化したいのか？ との問いかけ。DevOpsは半脆弱、ソフトウェアプロジェクトは脆弱だが、デプロイ頻度を上げると反脆弱になるという話し。最後にハンドルと逆に曲がる自転車に乗る映像を流し、複雑な事を変える時は、脳内を変化させなきゃならんのだよ。 という事で締めました。
途中、DevOps星取表 ぽいスライドがあり、数ヶ月後にどこまで成長したかが可視化してるのが印象に残りました。

For high-performing teams you need to nurture and grow your people [Gabor Devenyi]

DevOpsとは より良いコミュニケーションとコレボレーションを通して、より良い開発をしていくこと。
各チームに権限を与え、気持ちよく働き、協力して成果を出す。そのためにはテクニカルスキルはもちろん必要、そしてソフトスキルも必要。コミュニケーション、ファシリテーション、共感、謙虚、クリティカルシンキング、学ぶ、多様性。 問題解決で生産性が高いのは社会性/お互いのニーズが分かる/感性が高い/押しの強い人居ない/女性多い 。またGoogleのプロジェクト・アリストテレスの心理的安全性やHRT、信頼、仕事の意味やインパクトも大切。何故組織にいるのか考えてみよう、と。権限移譲と信頼に関しても言及し、例えばチームビルドを行うにしろ、チームで決めて行う のが大事。そして強みを活かそうという事で締めました。
今回一番共感出来たセッションかもしれません。

心・技・態　-LINEにおける改善の真実- [Hiroyuki Ito]

DevOpsの目的は 大企業病の回避 。分かりやすい。 大事な事は大きく3つ。心：組織文化、技：技術、態：ビジネス思考
失敗を許容するアジャイルなマインドセットを備える企業文化。リーンスタートアップの実践もしている。そんな環境でKPIを定め、それに向かってマネージャーの理解やエンジニアへヒントを出すなどの活動をしている。複雑化するテストに関してはコンテナを用いた安心して壊せる環境を用意。また、シンプル に皆が嬉しくなるために技術を使う。不安や埋もれた課題に対しては、深掘りして真の問題を探る事が大事。活動に関してはインパクトを与える事で、関心を持ってもう -> 協力してもらう。そして ゆとりを作る 忙しいと改善に消極的になるよね。
と、組織の中で、どう改善活動をしていくか、実践的なお話しが聞けました。

Pursuing Long-term Agility at Bing [Chap Alex]

Microsoft の Bing に関して。検索エンジン業界で価値を出すためには、やはりスループットを上げる活動が必要。昔、月イチのリリースでは変更箇所も多くテストも難しいものになってしまった。リリース頻度を上げる事で開発者の満足度が上がり、障害も減った。また問題がある変更を見つけやすくなった。 徐々にローカル環境でのテストがボトルネックになってきたので、クラウドで処理するようにした、そして並列化や、ブラウザ起動コストを減らすためのキャッシュを使う、Flakyなテストを適切に処理するなど、かなりCI/CDがチューニングされている印象。 また、助言として、待たずに飛び込め、マネージメントやエンジニアのサポートを得よ、そして計画しよう。全ての実験が成功するとは限らない、Failする事は問題ではない。 として締めました。
FAQではしばらく前に全てのテストが自動化されたこと、テスト環境にかなりの投資をしていることなど興味深い話しが聞けました。

Effective DevOps [Ryutaro YOSHIBA (Ryuzee)]

【資料公開】Effective DevOps

Effective DevOps ―4本柱による持続可能な組織文化の育て方

”DevOps” って何？を歴史から探る。最初に登場したのはTwitterのハッシュタグ #devops が2009年。Flickerの10 Deploy/Day はビジネスニーズへの対応の結果。開発と運用が協力した結果。そしてdevopsdays09が開催される。が、雑多なセッション。なので、DevOpsに明確な定義は無いこと。
また、4つのテーマとしてコレボレーション、アフィニティ、ツール、スケーリングの4本柱や、Googleのプロジェクト・アリストテレス、成長志向、フィードバック、非難の無い文化、スーパースターの弊害、コレボレーションについての話題で締めました。
DevOpsというワードについて、モヤっとしてたのが、実際にモヤっとしたものだと分かった のが、今回一番の収穫でした。

The Amazon Way - アマゾンのソフトウェア開発 - [Keisuke Nishitani]

Amazonのイノベーションの文化のお話し。有名なプレスリリースとFAQ駆動や、6Pagers、Two-Pizza Team、OLP 、全て自動化や、ハイヤリングでは自分より優れた人を採用しよう、またインタナーナルなトレーニングやランチでの技術共有する文化など、AWSと関係の深い弊社なので聞いた事があることも多かった内容で、改めてこの文化や取り組みがイノベーションを生む土台になっているんだと感じました。

VSM(ValueStreamMapping)によって実現できたリリースまでに268.5hかかっていた時間を54.5hに短縮できた秘訣 [Masato Ishigaki]

開発時間よりもリリースまでの時間に多大な時間を費やしていた現状を、一人でVSM(Value stream mapping) を使って可視化することから始め、周りを巻き込んでリードタイムを短縮していった経験と手法のお話し。
ベストセッションと呼べる、分かりやすく、勇気を貰える内容でした。

最後に

素晴らしいセッションを聞き、同士と集えたカンファレンスでした。 スポンサー及びスタッフやボランティア、また参加者の方がた、ありがとうございました。