ビジネスに合わせたスピード感でソフトウェアを開発する
このコラムで幾度となく言及したとおり、ビジネス価値のあるソフトウェアを開発することは非常に大切です。
加え、現代のソフトウェア開発では、「必要な時期に、必要とされる素早さで、ソフトウェアを利用可能にする」というスピード感が強く求められています。その背後には多くの要因がありますが、なかでも最も重要なファクターは、「ビジネスが開発スピードを要求している」という点です。
とりわけ、利用者が直接用いるアプリケーション・ソフトウェア（以下、単に「アプリケーション」と記す）をビジネス・スピードに合わせて提供できるかどうかは、ビジネスの成否を左右する重大事と言っても過言ではありません。
実際、例えば、一般消費者向けのサービスを提供している企業が、世間のトレンドを見定めて自社の課金体系を見直す決断を下したとしましょう。ビジネス決定に従った新たな課金アプリケーションが、決定から2週間後に利用可能になるのか、それとも6カ月後でなければ利用可能にならないかで、商機をつかめるかどうかの可能性はまったく異なってきます。言い換えれば、開発のスピードによって、アプリケーションのビジネス価値に雲泥の開きが出来るということです。
これまでも、ビジネスに合わせたスピード感でアプリケーションを提供するための開発方法がさまざまに提唱され、実践されてきました。開発の人的リソースを広く海外に求めるオフショア開発もそうですし、アジャイルのような柔軟な開発プロセスも開発スピードを増すための手法の1つです。また、クラウド・コンピューティングやSOAなど、すでに存在するリソースを有効活用するための技術も、アプリケーション開発のプロセスを迅速化するものと言えるでしょう。
新しい開発手法の持つ課題
もっとも、新しい開発手法は、ビジネス価値の高いアプリケーションの提供につながるものでなければ意味はありません。
ところが、例えば、地理的に分散した開発チームが馴染みの薄い技術を用いて、柔軟な対応が可能な開発プロセスの下でアプリケーション開発を行うとすればどうでしょうか。そのような場合、結果的に複雑さの上に複雑さを重ねるような状態に陥り、きわめて優秀な一部の組織を除いて、問題を解決することが困難になるはずです。
しかも、複雑性は爆発的に一挙に生じるものではなく、「この部分はアウトソーシングを試行し、こちらは新技術を試してみる」といった具合に、徐々に複雑さが増していくことになります。このような緩やかな複雑化の進行は、状況がかなり悪化してからでないと、なかなか気づきません。また、アプリケーション開発で従来から用いられてきた管理の仕組み（スプレッドシートや電子メール、電話など）についても、その見直しの必要性すら感じない場合も珍しくないのです。
開発の目標が最新のアプリケーションの実現に置かれているにもかかわらず、開発に使用する技術やプロセスは最新とはほど遠い状態にある――このような状況を看過していると、結果的に、開発の複雑さが増すばかりとなり、開発の効率性が一向に上がらないという危機的な状況へと開発プロジェクトが追い込まれることになります。
開発の新しい課題を解決するALM
上記のような課題を解決するためのアプローチとして、今日ではALMという管理手法が提唱されるようになりました。
ALMでは、以下のような相関する2つの原則をつないで実践することが重視されています。
- アプリケーション・ライフサイクルの本質的な理解：従来型のシステム開発ライフサイクル（SDLC）では、アプリケーション・ライフサイクルの一部しかカバーしていません。そのため、より広範で完全なアプリケーション・ライフサイクルを意識して開発を行うことが重要となります。
- マネジメントと自動化の強力な統合化：新しい開発手法を支えるのは「マネジメント」と「自動化」の統合から得られるスピーディな状況把握と作業連携です。
アプリケーション・ライフサイクルの本質的な理解
従来型のSDLCが重要であることは確かです。ここで失敗すると、アプリケーションが完成しないか、膨大なコストをかけた低品質のアプリケーションを使わざるをえなくなるかのいずれかの状況に陥ります。
しかし、SDLCをコントロールすればすべてがうまくいくわけではありません。SDLCでは、要件定義の前に行われる作業（ポートフォリオの計画策定から技術ポリシーとガバナンスの確立）と初期導入の後に発生する事柄（運用上の応答性の確保や調整、変更管理、アプリケーションの廃棄など）のすべてが見落とされています。
ところが、最新のガートナーの調査によれば、「アプリケーションのコストの92％は最初の開発後に発生すると推定される（「A Framework for the Lifetime Total Cost of Ownership of an Application」、Gartner Reserch,2010年3月30日）」としています。
したがって、開発の始動前と運用開始後を含めた完全なライフサイクルを無視して、ライフサイクルのコアの部分（つまり、開発のみ）のみに意識を集中させていると、組織はアプリケーションのTCO（所有総コスト）の大半を見過ごすことになるのです。
ALMは、アプリケーションの「揺りかごから墓場まで」――つまりは、「完全なライフサイクル」の中で事象をとらえ、一連のプロセスが効果的に実行されてこそ、そのアプリケーションはビジネスに役に立つものとなるという考え方に基づいています。
アプリケーション開発のコストは、開発後の長年にわたるTCOに比べれば小さいものと言えますが、最初の開発の中で行われた決定（資産の再利用、変更への対応、品質への投資）、もしくは開発前のIT投資の判断は、ビジネスの総コストに永続的に影響を与えることになるのです。
マネジメントと自動化の統合
効果的なアプリケーション・ライフサイクルを実現し、ビジネス上の価値を一貫して提供するためには、「マネジメント機能」と「自動化」とを強力に統合化する必要があります。
どこでどのようなアクションが必要になるかを示すマネジメント機能は、自動化された応答を支援し、応答の結果はシームレスに管理状況にフィードバックされます。
マネジメントと自動化を統合するという概念は、すでにさまざまな分野で実現されています。
例えば、自動車や飛行機には、その乗り物の状態と挙動を示すダッシュボードやコックピットが備わっています。これらは、自動化された関連システムを介して修正操作（燃料の補給、別方向への操舵など）を誘導します。そして、その動作の結果（加速、方向の修正）は瞬時にコックピットのコンソールに反映されます。
また、製造業の生産量を最適化するSCM（サプライ・チェーン・マネジメント）や、食品／雑貨業界での効率的な流通機構を実現するECR（エフィシエント・コンシューマー・レスポンス）なども、マネジメント機能と自動化との統合化によって、その概念を具体化させています。
そして、ソフトウェア・エンジニアリングにおいても、マネジメント機能と自動化の統合のよりALMという概念が実現可能になります。
ALMを実現するための3大要素は、トレーサビリティとプロセス間連携の自動化、レポーティング（あるいは、分析）とされています。言い換えれば、これらのやり方を見直すことが、アプリケーション・ライフサイクルを最適化し、新しい開発手法によるスピーディな価値提供を実現することが可能になるのです。
以上、今回は、ALMのアプローチがなぜ必要とされるのかを中心に話を進めてきました。次回も引き続きALMについて解説します。
※ これは2011年にCIOオンラインにて「【HP特別連載コラム】探求！ビジネス成長とIT革新
シリーズ3：ビジネス成果をもたらすソフトウェアを開発するために（7）」として連載したものを転載したものです。