DevOpsDays Tokyo 2020 Day 1

Thu, Apr 9
10:30
11:30

    Lunch Break - 90 mins

01:00
  • Added to My Schedule
    keyboard_arrow_down
    Ikuo Suyama

    Ikuo Suyama - Effective Mob Programming

    schedule  01:00 - 01:20 PM place Hall A

    モブプログラミングとは...

    「同じことを、同じ場所で、同じ時間に、同じコンピューターで」

    私たちはモブプログラミング(以下モブプロ)を「デフォルトの働き方」として採用し、一年間ほとんどすべてのタスクをモブプロで実施してきました。
    これら自分たちのチームのモブの実践と、様々なチーム、ときには海外でモブプロを経験し、その行動を観察するうち、モブプロを実践するときに共通して見られるいくつかの行動を発見しました。

    なぜモブプロなのか

    書籍「Effective DevOps」によると、DevOpsは4本の柱からなる文化であるとされます。
    4本の柱とはすなわち、

    - コミュニケーション
    - アフィニティ
    - ツール
    - スケーリング

    「同じことを、同じ場所で」全員で実施するモブプロは、開発チームのコミュニケーションを促進し、そして開発チームを超えてビジネスや運用チームとのアフィニティを高め、信頼を醸成する最良の手段の一つであると言えます。

    実際に僕たちのチームでは、モブプロをきっかけにチームのコミュニケーションが改善され、いまでは自己組織化された機能横断的なチームを実現しています。

    '効果的な' モブプログラミング

    モブプログラミングは「全員で1つのことをやる」という性質から、
    「効率的に働く」つまりリソース効率の最大化、単位時間あたりのアウトプット総量の最大化をめざすのではなく、
    「効果的に働く」つまりフロー効率を最適化し、単位期間あたりの仕事の成果(Outcome)を最大化するための手段であると言えます。

    自分たちのモブを観察するうち、成果を出せているときとそうでないときそれぞれに特定の共通した行動が見られることに気が付きました。

    これらの行動のうち、良い影響を与えるものを増長し、悪い影響を与えるものを最小化するため、意図的にチーム内でのモブにおける役割を定義しました。
    このロールの組み合わせによって、モブにおける「フォーメーション」あるいは「カタ」として名前をつけ、いくつかのカタログを作成しています。

    本セッションでは僕たちのチームで発見したモブプロの「カタ」を紹介し、カタを通して効果的にモブプロを行う方法について議論します。

01:25
02:00
  • Added to My Schedule
    keyboard_arrow_down
    Kaori Tokiwa

    Kaori Tokiwa - あなたのチームは「終わりのない改善」に疲れていませんか?

    schedule  02:00 - 02:20 PM place Hall A

    【問題 vs 私たち】で考えることが大事!というのは、DevOpsを進めているようなチームであれば当り前のことでしょう。
    日々、立ち向かう【問題】を「どう解決するか?」ということに頭を悩ませ、チームでよりよい解決策を考えて改善活動を継続的に行っているかもしれません。

    ところで、

    立ち向かっている【問題】が、本当に今あなたのチームが立ち向かうべき【問題】か?
    その【問題】が解決できた時にチームが辿り着けるゴールはなにか?

    と考えたことはありますか?

    • 【問題】に対して効果的なTry/Actionが出せない
    • 【問題】に立ち向かい続ける改善のサイクルは回しているが終わりがみえない
    • 立ち向かう【問題】が見当たらなくなってしまった

    と悩んだことはありませんか?

    様々なチームの支援を行っていると、次のような光景に出会うことがあります。

    • 目についた【問題】と次々に戦い続けていて、チームがレベルアップした実感が持てずに改善疲れをしている
    • まだチームで【問題】に立ち向かうプロセスが出来上がっていない段階でラスボスのような巨大な【問題】と戦って疲弊している
    • 次に立ち向かうべき【問題】が見つけられず、改善活動やチームの成長が停滞している

    こんな時は【問題】を「どう解決するか?」を考える前に、チームが立ち向かうべき【問題】が「なにか?」を見極めることが大切です。

    DevOpsを進めるチームによくある【問題】を例に、【問題】を捉えなおすことによっておきる嬉しい変化についてお話します。

    また、チームで【問題】に立ち向かうプロセスをどのように構築していくか?についても言及します。

    あなたのチームが【問題】に立ち向かいながらレベルアップし、楽しく改善を進めていくヒントを持ち帰っていただければ嬉しいです。

    改善疲れから抜け出し、チームが自信をもってレベルアップした!と実感できる活動にシフトしていきませんか?

02:25
  • Added to My Schedule
    keyboard_arrow_down
    Masato Ishigaki

    Masato Ishigaki - 「失敗できる」を作り出すと開発組織は加速する

    schedule  02:25 - 02:45 PM place Hall A

    事業の成長、開発組織の成長においても、イテレーティブさを担保することは非常です。事業という不確実性の高いものをグロースさせる作業に対して小さく失敗しながら、イテレーティブ(反復)に施策をユーザーに提供していきます。

    その施策を実行する組織として、どのように「小さく失敗するか」を考え、どうやって「失敗できる」環境を作り出せるかは、事業・組織双方の成長において欠かすことはできません。
    実現するためには、事業戦略・データドリブン・組織文化といった幅広い部分に適応する視野を持ちつつ、ビジネスサイド、エンジニアサイドともに連携して、事業を一緒に作っていかなければいけません。

    今回は、事業を作り出す開発組織においての「失敗」をどのように考え、実践しているのかを事例を交えながらお話していけたらと思います。

03:25
  • Added to My Schedule
    keyboard_arrow_down
    Taku Iwamura

    Taku Iwamura - 沖縄でリモート開発しながらモバイルアプリを毎日リリースする仕組み

    schedule  03:25 - 03:45 PM place Hall A

    私たちは、東京に本拠点がある企業向けの案件管理アプリ(iOS/Android)を沖縄のチームでリモート開発をしています。

    エンドユーザーとプロダクトオーナーは東京、開発チームは沖縄という体制ですが、遠隔地での開発であっても素早くユーザーからのフィードバックを得てアプリの価値を高めていくために、GitHubやBitriseを組み合わせてモバイルアプリを迅速かつ正確にリリースすることができる仕組みを構築しています。

    このセッションでは、東京と沖縄でのリモート開発においてどのようにコミュニケーション密度を上げているか、迅速かつ正確なリリースを行なうためにどのような仕組みを構築したか、またそれを実現することで得られる効果について紹介します。

04:00
  • Added to My Schedule
    keyboard_arrow_down
    Naomichi Shimazu

    Naomichi Shimazu - 500スプリントを支えるエンジニアリング基盤のつくり方

    schedule  04:00 - 04:20 PM place Hall A

    どうすればチームが自走し、安定して組織が拡大するのでしょうか?

    組織が大きくなっていくとチームの数も増えていくと思います。

    DevOpsを実現できるチーム作りでは、自動化やCI/CDなどの基盤となる仕組みを作っていくところから始まります。

    ではその仕組みは0から作るのでしょうか?それともうまく行っているチームを参考にするのでしょうか?


    もし、チームが増えるごとに0から仕組みを作っていては基盤作りだけで何日も、へたをすれば何週間も使ってしまうでしょう。

    もし、他のチームを参考にしたなら、自分たちのチームに使えそうな部分を探し出すのに膨大な時間を費やしてしまかもしれませんね。

    私が所属する組織でも同じようなことが起きました。

    いくつかのチームを調べた結果、原因となっていたのは各チームが作った「秘伝のタレ」でした。

    私たちは秘伝のタレの製造を防ぐために、共通のエンジニアリング基盤を作りました。

    この基盤によってチームは素早くプロダクトの開発に着手でき、自走できるようになりました。

    本セッションでは、私の組織で実現した、チームの自走を助け、安定して組織が拡大することを実現するエンジニアリング基盤について紹介します。

05:00
  • Added to My Schedule
    keyboard_arrow_down
    Takao Oyobe

    Takao Oyobe / Ryutaro YOSHIBA (Ryuzee) - 帰ってきた朝まで生DevOps 〜結局DevOpsとはなんだったのか〜

    schedule  05:00 - 05:45 PM place Hall A people 1 Interested

    DevOpsという言葉の世界はますます拡がり、様々な○○Opsが生まれました。DevOpsDays Tokyoに集まったプロポーザルを見ても、たくさんのDevOpsがあることがわかります。定義を1つに統一する必要はないですが、自分の中のDevOpsを更新し続けることは大切だと思います。

    そこで今回の朝まで生DevOpsは「結局DevOpsとはなんだったのか」をテーマに、定義の話を超えてDevOpsから我々は何を学ぶべきなのかについて考えていきたいと思います。

    パネラーは随時追加していく予定です。
    また、このパネルディスカッションは飛び込み参加可能なオープンパネルディスカッションです。

06:00

    Networking Party - 90 mins

DevOpsDays Tokyo 2020 Day 2

Fri, Apr 10
10:30
11:30

    Lunch Break - 90 mins

01:00
01:25
  • Added to My Schedule
    keyboard_arrow_down
    Ryuki Mizutani

    Ryuki Mizutani - NTTデータにおけるDevOpsの取組み –DevOps Transformation-

    schedule  01:25 - 01:45 PM place Hall A

    ウォーターフォール開発がメインのNTTデータでDevOpsを推進するためにDevOps Transformationなる施策を立ち上げて、どのように活動してきたかを事例を交えてお話しします。

    また、エンタープライズにおいてDevOps実践に向いている/向いていないプロジェクトは何かについても考察していきます。

02:00
  • Added to My Schedule
    keyboard_arrow_down
    Shingo Kitayama

    Shingo Kitayama - 2020年Kubernetesが解体するDevとOpsのインターフェイス -次世代プロジェクトの主導権を獲得するアーキテクトの掟-

    schedule  02:00 - 02:45 PM place Hall A

     Kubernetesやコンテナ化を自社に推進したいと考えるエンジニアやアーキテクト、CTOの方も多いのではないでしょうか。
    ところが、その推進が停まる理由の一つに「チーム内の技術スキルの差」が挙げられます。必ずしもチームの技術スキルレベルが一定である必要はないものの、複雑なKubernetes環境を運用していくためには、そのチーム体制や運用プロセスの変化が求められます。
     Kubernetesが一般化されていく中、これからのプロジェクト推進者は何を考えなければならないのでしょうか。Kubernetesを導入する現場で直面する、DevとOpsの新たな関わり方についての考察を紹介します。個別のチームだけでなく、業界全体で考えなければいけないKubernetes推進という大きなプロジェクトに対して、ともに考え、ともにつくることを目指したいと思います。

03:00
  • Added to My Schedule
    keyboard_arrow_down
    Woohyeok Aaron Kim

    Woohyeok Aaron Kim - Roll your Product with Kaizen Culture : Let's 'Tech' the initiative

    schedule  03:00 - 03:45 PM place Hall A

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

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

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

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

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

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

    ランキングチームが挑戦したトライアルそしてテクニカルな変化によるチームカルチャーの変化。より安全で良いサービスの提供のために、日々工夫を重ねているあなたのために、私たちのお話を特別に公開します。

04:00
  • Added to My Schedule
    keyboard_arrow_down
    Takeshi Kondo

    Takeshi Kondo - How to Measure the Reliability

    schedule  04:00 - 04:45 PM place Hall A

    Site Reliability Engineering の中核となる考え方に SLO - Service Level Objectives があります。これは信頼性を SLI - Service Level Indicator として計測し、目標値(Objective)を定め、それを下回った時のポリシーを決めることで、サービス開発の信頼性と機能開発の優先順位をつけることに役立ちます。しかしこれらを実現するには、信頼性とは何を指すのか、何を計測すべきなのか、そしてどのようにプロセスとして組織で取り組むべきなのかを考える必要があります。本発表では信頼性を計測する理由、考え方、具体的な実現方法を説明します。また、このプロセスを組織で取り組むことによってプロダクト開発の信頼性と速度にどう影響するのか、その実践例も説明します。

05:00