ALM (application lifecycle management)
アプリケーションライフサイクル管理
アプリケーションソフトウェアを開発・運用するに当たり、そのライフサイクル全体を総合的に管理することでソフトウェアの品質や開発生産性、変化への対応力などを向上させようという考え方のこと。あるいはそのためのプラットフォームツールをいう。
企業が業務アプリケーションを導入するのは、自社のビジネスプロセスを強化・補強するためである。企業内の業務アプリケーションはビジネスプロセスを支援し、あるいはビジネスプロセスそのものとして稼働する存在だが、ビジネスプロセスは市場ニーズや経営環境の変化に応じて頻繁に変わるため、対応するアプリケーションソフトウェアも迅速・柔軟な変更を求められる。
一方、そうしたソフトウェアを開発する活動は、一般に「要求」「設計」「実装」「試験」「配備」などの開発プロセスからなるが、そのプロセス間での連携が弱いと多発する仕様変更に対応できず、品質低下・費用超過・納期遅延を起こす。
開発後の運用期間中もアプリケーションには機能追加や変更、修正などが行われるが、これはアプリケーションを最初に作った開発者とは別の技術者が担当することが少なくない。このとき仕様書や設計書などの文書が残っていなければ、コード解析などの各種調査を綿密に行わねばならず、コスト高となる。
また別の問題として、これらのソフトウェア業務は属人的・専門的に行われることも多いため、上位管理者や他部門からはしばしば“ブラックボックス”と見られてきた。
このような「プロセス」「情報」「専門性」の壁に分断されたソフトウェアプロセスを統合して、各プロセスの状況や実績を可視化・追跡できるようにするソリューションがALMである。
ソフトウェア開発のプロセスやツールを統合するという発想は古くからある。1980年代から1990年代に掛けて、APSE(Adaプログラミング支援環境)、IPSE(統合プロジェクト支援環境)、PCTE(可搬共通ツール環境)、統合CASE、AD/Cycleなどの試みがあった。ALMはそのコンセプトをPC系開発ツールで実現するものと考えることができるかもしれない。
ALMはもともと、ソフトウェア開発ツールベンダの米国ボーランドが2002年に提唱したもので、同社が提供する各種ツールを連携させるという製品戦略に基づいている。ALMコンセプトに基づく製品は現在では多くの会社からリリースされているが、いずれもソフトウェア開発にかかわる実務を行うツールの集合体であり、プロジェクト管理ソフトのように「管理のための管理ツール」ではない。
このようにALMの特徴の1つは、プログラマやテストエンジニアといった実務技術者にとっての作業環境だという点である。ツールの連携によって、プロセス上の各作業は最適化され、各エンジニアは成すべき仕事を知ることができる。プラットフォーム上で行った作業は自動的に記録されるので、連絡ミスなども防止できる。チーム開発のプラットフォームであるという側面がALMの原点である。
ALMプラットフォームが記録する情報は、原則として実績ベースのものである。コードやドキュメントのチェックインやチェックアウトの状況などから、いつ誰がどの作業を行ったのかを正確に把握できる。作業の遅れがあれば経緯を追跡して、原因を究明することも可能だ。作業中の仕事が終わらなければ、次の作業に進めないようにワークフローを設定できるものもある。これは開発チームに対して特定の開発プロセスを強制適用し、規律をもたらすものである。同時に“正確な報告”が自動的に多量に収集できることを意味する。
ALMの特徴のいま1つは、こうした正確な情報に基づいて管理活動が行えるという点にある。プロジェクト実施中の進捗管理はもちろんのこと、成果物のトレーサビリティを確保できるので、変更や間違いがどのプロセスで混入したのかを知ることが可能となる。バクの発生状況などから今後の進捗や最終的な品質を予測したり、事後的に開発プロセスの妥当性や作業の無駄を検証するという使い方もある。
ALMがカバーする領域は製品によってまちまちだ。基本は“開発”における各プロセスで、要求管理、構成管理、変更管理、リリース管理、バージョン管理、証跡管理、インシデント管理、成果物管理、 資産管理などの管理活動を支援する。アーキテクチャも各管理データベースが連携するもの、単一リポジトリに集約するもの、各情報源からデータをアグリゲートして統合表示するダッシュボード型のものとさまざまである。
ALMの対象領域に“運用”や“IT戦略”を含めるものもある。これはALMの大きなビジョンといえる。どのようなソフトウェアを作ろうとも、システム運用に移行せずユーザーへのサービス提供がなされなければ、価値はない。各社のALM製品は、開発工程と運用工程が密接に連携したソフトウェアライフサイクル・マネジメントの基盤として、進化を志向している。
開発から見て超上流に当たる“IT戦略”と連携させるビジョンもある。社内に複数のITシステム(計画中、開発中、運用中)があるとき、それらを比較して、どのプロジェクトを実施し、どのシステムを稼働停止とするかを決める手法としてポートフォリオマネジメントがあるが、これを行うには進捗やコストに関する正確な事実データが不可欠となる。ALMによって開発や運用の事実データが収集できれば、経営レベルの意思決定を行う際の情報提供が可能となる。
また、組み込みソフトウェア開発の世界ではPDM/PLMとともに、派生開発やプロダクトライン開発を行う基盤として期待されている。
参考文献
- 『Visual Studio Team Systemで実践するソフトウェアエンジニアリング――成功する開発プロジェクト運営のために』 サム・グッケンハイマー、ファン・J・ペレス=著/トップスタジオ=訳/マイクロソフト=監訳/日経BPソフトプレス/2007年2月(『Software Engineering with Microsoft Visual Studio Team System』の邦訳)
- 『実践! アジャイルプロジェクト管理――スクラムではじめる最強エンタープライズ開発』 テクノロジックアート=著/長瀬嘉秀、設楽秀輔=監修/技術評論社/2009年11月
関連記事
- 連載:Team Foundation Server 2010入門(1) − Team Foundation Server 2010を導入しよう(@IT Insider.NETフォーラム)
- ボーランド20周年を飾るのは.NET完全対応のDelphi 8(@IT News)
関連用語
- ソフトウェアエンジニアリング
- ソフトウェアプロセス
- ソフトウェア開発プロセス
- JIS X 0160
- 共通フレーム
- CASE(computer aided software engineering)
- リポジトリ
- ソフトウェア構成管理
- 変更管理 ソフトウェア資産管理
- トレーサビリティ
- ワークフロー
- ソフトウェアファクトリ
- 構成管理データベース
- ソフトウェア資産管理
- IRM(information resources management)
- ILM(information lifecycle management)
- ポートフォリオマネジメント
- プログラムマネジメント
- PSA(professional services automation)
- ソフトウェアプロダクトライン開発
- ソフトウェアプロダクトライン
- PDM(product data management)
- PLM(product lifecycle management)
- IDE(integrated development environment)
- CMMI(capability maturity model integration)
- COBIT(Control Objectives for Information and related Technology)
- PMBOK(the project management body of knowledge)
- ITIL(information technology infrastructure library)
- アジャイルソフトウェア開発
リンク
|
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
|
アイティメディアの提供サービス
ホワイトペーパー(TechTargetジャパン)
スキルアップ/キャリアアップ(JOB@IT)
スポンサーからのお知らせ
- - PR -
