ブログ

アプリケーション・ライフサイクル・マネジメント（ALM）はソフトウェアの初期の開発から最後のリリースまでのライフサイクルを管理することである。ALMはビジネス面と開発面の双方の側面からアプリケーションのライフサイクルを管理する手助けになるような全てのプラクティス、プロセス、ツールを包含している。 ALMの中心となる機能には、変更管理、ワークフロー、ソースコード管理、タスク管理、テスト、バグトラッキング、労務管理、レポートや分析といったことができる機能が含まれている。 またALMプラットフォームはALMプラットフォーム上の多くのプロセスや、場所やツールの種類をまたいだトレーサビリティやアカウンタビリティを確立するシステムとして、コードやタスクやロールや要求やその他さまざまな作成物をすべて管理する中央のレポジトリを持っているはずだ。

ソフトウェア開発における複雑で巨大な環境下においては、リスクを管理することは非常に重要になってきた。 全てのソフトウェア開発は先天的なリスクを含んでいる。それはソフトウェア開発が数学的もしくは物理的なところが中心にあるのではなく、むしろイノベーションや発見や芸術性が中心にあるからだ。 プロセスを自動化できる製造のシステムとは異なり、ソフトウェアの開発プロセスは万能な型にはまったシステムに落としこむことはできない 開発プロジェクトに影響を与えるなんらかもしくは全ての要素を予測することは不可能である。

かつて開発チームはALMの管理においては主にウォーターフォール型のアプローチに頼っていた。しかし工場の組立ラインのように、ウォーターフォール手法は、製品の要求を事前に集め、開発プロセスは予め定めた順序（コーディング→テスト→QA→リリース）にしたがっていくという線形的なアプローチである。 このような種類のアプローチにおけるリスクは、このアプローチ自体がプロジェクト失敗のリスクを増加させるという点にある。 最終的なプロダクトがリリースされるまでには、もはや当初考えていたようなマーケットには合わないものになってしまう可能性が高いということである。

プロジェクト失敗のリスクを減らすために、開発チームは継続的にソフトウェア開発のプロセスや技術を改善する方法を探していかなければならない。ソフトウェアは単純ではないものが多いので、線形の形式で最初から終わりまでの台本を書くことはできない。これこそが、マーケットにおいて「Agile ALM」に対しての変化が認められる理由であるのだ。 簡単にいえば、ALMもAgileなコミュニケーションも現在のソフトウェア開発の状況を改善することにフォーカスしている。 ALMが技術的な観点からそれに取り組んでいるのに対して、アジャイルはプロセスの改善にフォーカスしている。 ALMとアジャイルの共通のゴールと相乗効果故に、1〜3年後にはマーケットに複数のアジャイルALMベンダーがいることを期待している。

線形なウォーターフォール手法とは違い、アジャイルチームはALMへのアプローチとして要求の変更や複雑性やソフトウェアプロジェクトで起こり得るリスクファクターに対して「反復」や「検査と適応」を使って対応する。 アジャイルな手法のうちもっとも一般的であるScrumは、ここ数年規模の大小に関わらず急速に採用例が増えてきており、現在ではエンタープライズの分野にまで広がってきている。Scrumの成功は大部分は自己組織化されたチーム内の十分な協調と同じくらい「高いフィーチャー価値」を創りだすことを可能にすることにフォーカスしていることだ。 Scrumを利用しているチームはScrumをビジネスROIを早期に実現でき、作業のやり直しを減らし、製品のイノベーションを加速するという点について利点があると考えている。