ALM Essentials（1）
ALMとDevOpsとリーンスタートアップは何が違うのか？
そもそもALMって何？ ALMが現れた背景や、「DevOps」や「リーンスタートアップ」との違いを説明する。
ALMとは何か？
まず最初に「そもそもALMって何？」と思われている方に向けて、ALMについてご説明しよう。
アプリケーション・ライフサイクル・マネジメント（ALM）とは、ソフトウェア開発・保守を各アプリケーションのライフサイクルにわたって継続的にプロセス管理をする考え方である。ALMは、業務管理とソフトウェア開発の融合により、要件管理、設計、実装、検証、バグトラッキング、リリース管理を、ツールを使用してそれらの促進と統一化を実現することである。
上記のように、ALMとはApplication Lifecycle Managementの略で、その名の通り、アプリケーションの一生をマネジメントするものである。ALM ＝ Toolと誤解している人もいるが、ALM ≠ Toolであり、ALMとは継続的にビジネス価値を提供するためのものである。
ALMが現れた背景とは何か？
そもそも、この概念が出てきた背景をご説明しよう。それは現在のアプリケーションが以前と比べて、ビジネスのキーを握っているためである。次の図は、その状況の変化をまとめたものだ。
※この図は、次のリンク先ページの画像を参考に、新たに書き起こしたものです。
- ●【参考元】「ソフトウェア開発環境の最新動向 | Microsoft Visual Studio」の「ビジネス価値を提供し続ける」 © Microsoft
以前（図1.1で示す1990年代）のアプリケーションは、既存の確立したビジネスモデルのIT化が主な役目であった。
- A ビジネスモデルが確立しやすい
- B 大きく固定化した全体計画をし、その後は計画した通りに全体の機能を全て完成させてからリリースする
- C 上記の理由により、開発手法としてはウォーターフォールが適している
それが昨今（2010年代）では、ジャストインタイム（Just in Time）にリリースする必要があり、ビジネスをする上でITが不可欠なものになっている。
- A ビジネスモデルが変動しやすい
- B 小さく、しかも直近の予定は細かく未来の予定は流動的に計画し、その後は機能が出来上がるたびに随時リリースする
- C 上記の理由により、開発手法としてはアジャイルやリーンスタートアップの手法が適している
このような環境において、いかに素早くビジネスアイデアを動くアプリケーションにするのか、いかに高品質のアプリケーションを開発するのか、いかにビジネス価値のあるアプリケーションを提供するのかが非常に重要になってきた。そのため、“アプリケーションの一生をマネジメントする”というALMの概念が現れたのである。
“アプリケーションの一生をマネジメントする”とは、“今までのように「アプリケーションは作って終わり」ではなく、リリース後にユーザーから得られたフィードバックを基に常に改善していく”というものである。分かりやすい例としては、1年ごとにOSが更新されるアップルのMac OS XやiOS、稼働させながら日々少しずつ改善されているTwitterやFacebook、Flickrなどが挙げられる。このように、短期間で目まぐるしくアプリケーションが変化する時代になっており、ALMは目新しい概念ではなく、すでに多くの企業で実践されているものなのである。
DevOpsとの違いは何か？
ここまでの説明を読んで、「DevOpsとの違いって何？」と思われている方もいるだろう。そこでDevOpsの概念について説明しよう。
ただし2013年現時点では厳密な定義は存在しておらず、抽象的な概念に留まっている。
……中略……
DevOpsという単語は2009年のオライリー主催のイベント「Velocity 2009」において、Flickrのエンジニアにより始めて公の場で用いられた。このプレゼンテーションでは「開発と運用が協力することで、1日に10回以上のペースでリリースが可能になる」という発表とともにDevOpsという単語が用いられた。
Wikipediaに上記のように記述されている通り、本原稿執筆時点においては、DevOpsの厳密な定義は存在しない。本連載ではDevOpsの概念を、以下の図1.2 DevOpsに示すように、“それぞれの役割の違いから衝突することが多いDevelopment（＝開発、Dev）とOperations（＝運用、Ops）の双方が同じゴールを目指して協調する”こととする。
※この図は、次のリンク先のPDF内にある画像を参考に、新たに書き起こしたものです。
- ●【参考元】「Enterprise DevOps」の「DevOps のワークフロー」 © Microsoft
DevとOpsの衝突
先ほど“衝突することが多いDevelopmentとOperations”と記載したが、DevとOpsが衝突する理由をまずは説明しよう。
DevとOpsの衝突は主にその役割（ミッション）の違いに起因している。Dev、つまり開発の役割は“より良いものをリリースする”ことである。前述の通り、昨今は“小さく、しかも直近の予定は細かく未来の予定は流動的に計画し、その後は機能が出来上がるたびに随時リリースする”ようになってきている。そうなると最初から要望に完璧に合致したものを作り出すのは不可能である。リリースした後にユーザーからのフィードバックを基に新規機能の追加や既存機能の変更を継続的に行う必要がある。
一方でOps、つまり運用の役割は“システムを安定稼働させる”ことである。運用の世界では“動いているものには触らない”という言葉があり、すでに安定稼働しているシステムに対して、新規機能の追加や既存機能の変更を行わなければ今まで同様に動き続けるため、基本的に安定稼働しているシステムに手を入れることを嫌う傾向がある。
このようにDevとOpsでは一見すると相反する役割を持っているように見えるため、衝突してしまうのである。しかし、お互いの役割を見比べると一目瞭然だが、Devの役割は“システムを安定稼働させない（＝システムを不安定にさせる）”ことではなく、Opsの役割も“より良いものをリリースさせない”ことではない。
Devが“システムを安定稼働させる”のに協力するのであれば、“より良いものをリリースする”のをOpsが妨害することもなく、Opsが“より良いものをリリースする”のに協力するのであれば、“システムを安定稼働させる”のをDevが妨害することもない。ただ、今まで衝突が起きていたのは、システムに変更を加えると、システムが不安定になっていたために、“システムを安定稼働させる”ためにはシステムに変更を加えないことが唯一絶対の正解のように思われていただけである。
DevOpsとALMの違い
もし、“DevとOpsが互いに相手と協調しない”のであれば、“リリース後にユーザーから得られたフィードバックを基に常に改善していく”のがおぼつかない状況になるのは自明の理だろう。つまり、DevとOpsの双方が同じゴールを目指して協調するというDevOpsを、ALMは包括しており、ALMの一部がDevOpsとも言える。
リーンスタートアップ（Lean Startup）との違いは何か？
リーンスタートアップの定義についても、Wikipediaから引用しよう（括弧内は参考訳）（※編集部注： ちなみに「リーンスタートアップ入門 ― 日本の実例に学ぼう」という記事もあるのでこちらも参照していだくとより深く理解できるだろう）。
Lean startup is a method for developing businesses and products first proposed in 2011 by Eric Ries.（リーンスタートアップは、ビジネスと製品を開発するためのメソッドで、2011年にEric Ries氏により最初に提案された。）
……省略……
Definitions（定義）
Based on The Lean Startup（『リーン・スタートアップ』に基づくと……）
In his blog and book, Ries uses specific terminology relating to the core lean startup principles.（Ries氏のブログと本では、コアなリーンスタートアップの原則に関連する特別な用語を使っている。）
……省略……
Minimum viable product（実用最小限の製品）
……省略……
Continuous deployment（継続的デプロイメント）
……省略……
Actionable metrics（行動につながる評価基準）
……省略……
Pivot（ピボット）
……省略……
Build-Measure-Learn（構築―計測―学習）
……省略……
次の図はリーンスタートアップの原則の中の「構築―計測―学習」のフィードバックループの概念をまとめたものだ。
アイデアから製品を「構築」し、製品からデータを「計測」し、データからアイデアを「学習」する。再び「構築」からの流れを繰り返す。
※この図は、次のリンク先ページの画像を参考に、新たに書き起こしたものです。
リーンスタートアップ（Lean Startup）とALMの違い
リーンスタートアップを提案したEric Ries氏は著書『リーン・スタートアップ』の中に以下のように記載している。
「構築―計測―学習」のフィードバックループ
リーンスタートアップは具体的には、「構築―計測―学習」のフィードバックループを通して、まず要となる仮説に基づいて実用最小限の製品（MVP）をすぐに作って、実際に顧客に使ってもらった実験結果から、成長につながる価値を学ぶ（検証による学び）という工程をくり返します。その中で、仮説に対して結果が違ったら、そのまま進むか、あるいは方向転換（＝ピボット）するかを選びます。その判断基準も、いっときの成果ではなく、事業として継続できるかどうかを見る、著者ならではの鋭い指摘が示されています。
- 引用元： エリック・リース 著、井口 耕二 訳、伊藤 穣一(MITメディアラボ所長) 解説（2012） 『リーン・スタートアップ』 （日経BP）
リーンスタートアップにおいて「構築―計測―学習のフィードバックループ」を高速に回していくことが重要だと記載されている。では、どうやって構築―計測―学習のフィードバックループを高速に回せばよいか？ その答えがALMである。
ALMは、業務管理とソフトウェア開発の融合により、要件管理、設計、実装、検証、バグトラッキング、リリース管理を、ツールを使用してそれらの促進と統一化を実現することである。
Wikipediaに記載されている通り、ALMはリーンスタートアップが提唱するところの「構築―計測―学習のフィードバックループ」を高速に回すために、構築、計測、学習に必要な作業を統一化や支援する概念なのである。また、実用最小限の製品や継続的デプロイメント、行動につながる評価基準、ピボット、構築―計測―学習は、“今までのように「アプリケーションは作って終わり」ではなく、リリース後にユーザーから得られたフィードバックを基に常に改善していく”に強く関連した内容でもある。リーンスタートアップへの別の切り口でのアプローチがALMとも言えるのである。
■
次回はALMを実践するための基礎知識として、ALMの3つの構成要素について説明する。
1. 【現在、表示中】≫ ALMとDevOpsとリーンスタートアップは何が違うのか？
そもそもALMって何？ ALMが現れた背景や、「DevOps」や「リーンスタートアップ」との違いを説明する。
2. いまさら聞けない「ALM」。3つの構成要素とは？
ALMを実践するための基礎知識として、ALMの3つの構成要素「Business（ビジネス）」「Development（開発）」「Operations（運用）」について説明する。
3. Visual Studio Team Servicesの機能概要と環境構築パターン
効率的にアプリを開発・運用するには、開発ライフサイクルの流れをスムーズにするツールの活用が欠かせない。その環境の一例として、マイクロソフトが提供するSaaS型のALMツール群の全体像を解説する。
4. Team Foundation Serverの機能概要と環境構築パターン
自社イントラネット内などのオンプレミス環境で、アプリ開発のライフサイクルを全体的に管理できるALMツールとして、マイクロソフトのTFS環境を導入した場合の、ALM環境の全体像について解説する。
5. JIRA Software／Bitbucket／Bamboo／HipChat／Confluenceの機能概要と環境構築パターン
オープンソース・ソフトウェアも便利だけど、アプリ開発のライフサイクルを一貫して効率よく管理するには、アトラシアンが提供するツール群がもっと便利。SaaS型／オンプレミス型の両環境の全体像を解説する。
