無料を好んで人件費がかかりすぎ!? 過剰なベンダーロックイン恐怖症から脱却を！
冒頭から「こんなタイトルで人が集まるとは（笑）」と、ハイテンションで登場した牛尾氏。そんな牛尾氏による本セッションのテーマは「Be Lazy（楽をして）でDevOpsの自動化の第一歩を踏み出そう！」だ。
セッションは牛尾氏が最近疑問に感じている話題からスタート。みんな「0円＝タダ」が大好き。お金をかけることは誰も好まない。牛尾氏自身も元々は商業ツールを好まず、できるだけオープンソースを活用することを考えてきた。しかし「最近、意識が変わってきた」という。
そもそも、なぜベンダーロックインが好ましくないのか。恐らく「高い汎用機やシステムを購入し、それを使い続けるしかなかった」思い出を持つ人が多いからだろう。つらい記憶があるからこそ、ベンダーロックインを避けてきたのではないだろうか。
「しかし、それが過度になり、逆に損しているのでは？」と、牛尾氏は問いかける。
近年、有料の製品といえばソフトウェアやサービスを指すことが多く、以前主流だった汎用機や大型システムと比べると安価なものが中心だ。解約や移行も簡単にできることが多い。それなのに、なぜ今も「ベンダーロックインを避けること」にこだわり続けるのか。
むしろ、今の時点で最も高価になっているのは人件費であり、無償の製品を使用するために人を雇うのであれば本末転倒だ。牛尾氏は「車輪の再発明よりも、（既に存在する良い製品に）お金を払おう」と語る。ベンダー提供のツールやソフトウェアを賢く使うことが、本セッションのテーマである「Be LazyでDevOpsの自動化の第一歩を踏み出そう！」につながっていくのだ。
DevOpsでは自動化の技術的な話がクローズアップされがちだが、それだけではなく、重要なポイントが3つ存在する。
まず、「人」の考え方やマインドセット、組織の在り方について考えること。次いで開発の手法や進め方といった「プロセス」の改善。その上で最適な技術や「プロダクト」の活用が求められる。「人」「プロセス」「プロダクト」を集合体として考え、エンドユーザーに対して継続的に最高の価値を提供することがDevOps本来の意味だ。DevOpsが実現すれば「1日に10回ものデプロイが可能となる」といわれているが、「現代の技術を活用すれば簡単にできることだ」と、牛尾氏。
DevOpsの目的は次の3つだ。まず1つ目は、アイディアを思いついてからデプロイするまでの時間の短縮、つまり「リードタイムの短縮」である。そして2つ目は「本番環境やユーザーから開発側へ、速やかなフィードバックを届ける」ことだ。以前は「本番環境に出す前に、できるだけ精度を上げるべき」という考え方が一般的だった。しかし現在では、「できるだけ早く本番環境に反映させ、フィードバックを得つつ改善していくことが望ましい」。なぜなら本番環境に置いて初めて判明する問題もあるからだ。こうしたデプロイとフィードバックを繰り返す「継続的な実験と学び」が3つ目に挙げられる。
実際、DevOpsを実現することで得られるメリットは非常に大きい。コードのデプロイ速度は30倍にもなり、リードタイムは1/2555に短縮され、障害復旧は24倍の速さで実現、変更の失敗率は1/3にまで削減可能、とされている。必然的に導入の有無で大きな差が生まれることになり、その影響は将来にわたって続く可能性が高い。
DevOpsな開発環境を実現するため、初心者にオススメの「バリューストリームマッピング」とは？
DevOpsで重要となる自動化の導入ステップについて、牛尾氏はまず「DevOpsプラクティスを理解する」こと、つまり考え方を理解することが重要だと語る。Infrastructure as Code（IaC）や継続的インテグレーション、自動テスト、継続的デプロイなど、主要なプラクティスを理解することで、適切なツールを選定することができる。ちなみに牛尾氏は、DevOpsのスタータキットを公開しており、DevOpsの概要やプラクティスの詳細をデモ付きで説明している。
DevOps最初のステップとして、牛尾氏は「バリューストリームマッピング」を勧める。アイディアを実装してデプロイするまでの過程を“見える化”して、リードタイムや実行時間を明確にする手法だ。
バリューストリームマッピングを実行する場合、開発者（Dev）や運用者（Ops）だけでなく、決定権を持つ上層部やビジネスサイドのメンバーなど、あらゆる人を巻き込むことが重要だ。「効率的な開発を妨害するプロセス」や「自動化のため有用な技術」についてディスカッションを行い、情報を共有する。そこから、自動化・効率化について「人・プロセス・ツール」の三位一体で考えていくきっかけが生まれる。
次のステップでは、CI/CD（継続的インテグレーションと継続的デリバリー）の基本チェックリストを用いる。リストの内容を確認し、アプリケーション開発の流れである“パイプライン”を実際に見ながらディスカッションする。ここでは牛尾氏の経験則から想定されるチェックリストが紹介された。内容は基本的なものであるが、これらを意識するだけでも大きな効果が得られるという。
