VSM(ValueStreamMapping)によって実現できたリリースまでに268.5hかかっていた時間を54.5hに短縮できた秘訣
大きな組織の中で、プロダクトをリリースするまでに必ず発生する開発プロセスの「ムダ」
プロダクトを効果的に早くリリースする上で「ムダ」を排除しリードタイム短縮につなげたいとの想いから、VSM(ValueStreamMapping)を活用して開発プロセスにある「ムダ」を可視化し改善し続けた結果、リードタイムを268.5h→54.5hに短縮した事例と手法についてお話します。
DMM.comにおける40以上あるサービスのプラットフォーム基盤の開発に遵守する中で、どうやってサービス開発者側にスピード感をもって良いプロダクトを提供できるかを考え、DX(DeveloperExperience)の向上へと向かったのか。
VSM(ValueStreamMapping)を使った「プロセス」と「プロダクト」の品質改善の話を中心に
SlackによるDeploy/Releaseで高速デリバリー、Deploymentpipelineの整備などの様々な改善事例を織り交ぜながらお話したいと思っています。
Outline/Structure of the Case Study
- DMM.comについて
- DMM.comのサービス開発体制について
- 組織における開発プロセスの「ムダ」について
- VSM(ValueStreamMapping)の書き方について
- VSM(ValueStreamMapping)を使った分析メソッドの紹介
- VSM(ValueStreamMapping)を使った改善メソッドの紹介
- 改善事例(Case study)
- まとめ
Learning Outcome
- DMM.comのサービス開発体制について
- VSM(ValueStreamMapping)を使った分析/改善プロセスについて
Target Audience
開発プロセスに「ムダ」があると感じている方。プロセス改善に興味がある方。
schedule Submitted 5 years ago
People who liked this proposal, also liked:
-
keyboard_arrow_down
Atsushi Fukui - フルマネージドなAWSサービスで実現するコンテナへの継続的デリバリー
Atsushi FukuiDevOps Specialist Solutions ArchitectAmazon Web Service Japan K.K.schedule 5 years ago
45 Mins
Demonstration
Intermediate
AWSのCodeシリーズを利用してサーバーの管理を不要にしたフルマネージドな環境で、DockerコンテナのフルマネージドなオーケストレーションであるAWS Fargateへの継続的デリバリーをどのように実現するかをデモを交えながら解説します。
-
keyboard_arrow_down
Shingo Kitayama - GitLabによるComplete DevOpsの実現 -これからのDevOps Toolchainのあり方-
45 Mins
Demonstration
Intermediate
DevOps ToolchainとしてのGitLabが目指す、これからのDevOpsツールのあるべき姿を紹介します。
GitLabは近年進化を遂げ、バージョン管理システムの機能だけに留まらず、Chatツールを代表とした開発ワークフローから、継続的インテグレーション(CI)、継続的デプロイメント(CD)、フィードバックまでの継続的デリバリを実装できる機能を提供しています。これは、数多く存在するDevOps Toolchainの選定コストを排除し、アプリケーション開発に集中できるプラットフォームを提供するための最善策とも言えます。
本セッションでは、実際にGitLabのCI/CD機能を使ったアプリケーションデプロイメントパイプラインのデモを交えて紹介します。さらに、最新版で強化されたDevSecOpsのセキュリティ機能やKubernetes上で展開するアプリの実装について、GitLabの魅力を最大限お伝えいたします。 -
keyboard_arrow_down
Yasunobu Kawaguchi / SATO Naoki (Neo) / Takuma Ishibashi / Tsuyoshi Ushio - パネル : 昨年のシアトル DevOps 視察ツアーから今までを振り返る
Yasunobu KawaguchiAgile CoachAgilergo ConsultingSATO Naoki (Neo)Azure TechnologistMicrosoftTakuma Ishibashiテクニカルエンジニア野村総合研究所Tsuyoshi UshioSenior Software EngineerMicrosoft Corporationschedule 5 years ago
45 Mins
Panel
Advanced
過去2回のDevOpsDays Tokyoは、2017年1月末のシアトル訪問から始まりました。
Microsoftを訪問し、いくつかの多様性のある開発現場を見せていただき、英語での闊達な議論もしてきました。今年のキーノートの Chap Alex さんもそこで出会った一人です。
彼はもともとテストの自動化の役職にいたわけではありません。
スカンクワークスで数年、チームになって3年くらい、今は30人のチームになったといっていました。別のチームの人は、TFSというプロダクトを作っていましたが、
「ほら社内でこんなに使われるようになったんだよ」
と言っていました。計画経済のようにトップを説得して全体に使わせるなんてことはやっていませんでした。さらに、そのチームは部屋を工夫し、チーム全員が一部屋に集まり、それでいてほかのチームとは共有しない部屋を作っていました。徐々にほかのプロダクトに広がっていると言っていました。
日本人エンジニアの河野通宗さんが言っていました。
「上司もエンジニアなので意思決定が速いです」
意思決定が速いと何がうれしいのですか?
「クラウドは常にどこかが壊れている。なのですぐに検知して直さなきゃいけない」世の中がガラリと変わってしまう音が聞こえました。
もう開発者もデザイナーもマネジメントも経営陣も関係なく、リアルタイムに動き続ける世界を相手にして動かないといけない。途中の誰かがわからないから通訳してくれといえば、そこでリアルタイムから弾き出される。
テスト自動化だけ、チームビルディングだけ、上手なデリバリーだけ、得意ななにかをひたすら追いかけて、エンジニアのキャリアパスだけ考えて、残りはほかの人のせいにしておけばよい時代は終わってしまった。全体としていい仕組みを作った企業が生き残る。誰も安住できないグローバル競争をしたたかに生き残って時価総額を伸ばし続けるエンタープライズがシアトルに一つありました。競争している企業もいくつもあります。
私たちの DevOpsDays Tokyo そこから始まりました。
それから一年ちょっとがたちました。
世の中の何が変わったのか、そして、心境はどう変わったのか、ここからどうなっていくのか。
話し合ってみたいと思います。 -
keyboard_arrow_down
Takashi Takebayashi - To be or to do that is the question.
45 Mins
Experience Report
Beginner
上長に「お前は技術もマネジメントもビジネスも何も分からないクズ」と言われ、本当に自分が「技術もマネジメントもビジネスも何も分からないクズ」なのかどうかを確認しようと思い立った。
確認する方法としてテスト駆動開発(TDD)でお馴染みの三角測量(その人にはたまたまそう見えたということが起こらないように2つ以上の値を使用してテストをする)で確認することに思い至り、ちょうどタイミングよく運転資金が枯渇し閉店を余儀なくされた馴染みの飲食店とパン屋があったので、そこに自己資金を運転資金として投入し、自分の技術と知識と能力を使って閉店を免れられるのかどうかを確認した結果を紹介する。 -
keyboard_arrow_down
Ippei Suzuki - Kubernetesエコシステム、そしてそれを支えるCNCFの最新の動き
45 Mins
Case Study
Executive
Kubernetesはクラウドネーティブの世界における、事実上の標準としての地位を確立している、と言えます。Dockerを代表とするコンテナ技術をベースに、マイクロサービス型のアプリケーションを運用管理するフレームワークとして、Kubernetesは急激に利用者が増えています。
"Linux of the Cloud"とも呼ばれ、今後特定のクラウドに依存しないアプリケーションの開発/運用のOSSプラットホームとして成長していくことが期待されています。
発表者はCNCFのメンバーとして、当団体の様々な活動に参画しており、最近の動き、そして将来的にどのようなクラウドネーティブ技術が登場するのか、導入事例なども含め、報告します。 -
keyboard_arrow_down
Seiji Kawakami - DevOpsが失敗する理由
45 Mins
Experience Report
Intermediate
アジャイル開発センター発足から1年以上、DevOpsをもっと浸透させるための箱はできました。
実情としては、上手くいっているプロジェクトもあれば、改善が必要なプロジェクトも多々あります。
業務部門、事業部門と兼務した経験から見えてきた、「リリースサイクルを短くするためのDevOps」が浸透しない理由、
そして現在挑戦している対策等を共有したいと思います。
-
keyboard_arrow_down
山崎泰宏 - 運用(Ops)の自動化を目指すも何故か進まない、現場あるある打開策
45 Mins
Talk
Intermediate
運用の自動化は誰もが目指す理想郷である。しかし現場を見てみると、意外にもその思惑とは裏腹に、導入は進んでいない。特に複雑な運用ほど自動化すれば効果が高いのに、実施されていない。
そこには、ひとえに運用におけるソフトウェア・エンジニアリングの考え方が不足しているのが理由に挙げられる。私達はソフトウェアを作り上げるように、運用を構成しなければならない。これはDevOpsに限らず、近年のSite Reliability Engineering (SRE)の骨子でも同様である。
本セッションでは、運用の自動化を進めるに当たって考慮すべき事項と、その実現手段についてはMicrosoft Azureを用いた一般的なものから、物理ネットワーク運用への適用など特殊なものまで、実例をいくつか交えて解説をする。