完全ライフサイクルに対する配慮不足が開発をひっ迫させる
アプリケーションのコストの92％は最初の開発の後に発生する――これは前回も紹介したガートナーの推定です。この推定に基づけば、ライフサイクルのコアの部分（つまりは、開発のみ）に意識を集中させていると、組織はアプリケーションTCO（所有総コスト）の大半を見過ごすことになります。
本連載の中で、筆者はこれまで、ビジネスにとって価値のあるアプリケーションを開発するためには、利用者に向けて適切な情報を集約して提供したり、（ビジネスに合わせたスピード感でアプリケーションを開発するため）新しい開発手法や技術を取り入れたりすることが重要であると幾度となく論じてきました。
しかし、運用と保守にIT予算の多くを取られてしまっていては、開発コストがひっ迫し、ビジネス価値の高いアプリケーションの開発に十分な資金を投入できなくなります。つまり、アプリケーション・ライフサイクルのコア部分以外に対する配慮が足らないと、アプリケーションのビジネス価値を追求するための土台が瓦解しかねないわけです。
そこで重要になるのが、開発の前後も含めたアプリケーションの「完全ライフサイクル」をしっかりととらえ、それにかかるコストの適正化を図ることです。また、その実現に向けては以下の2点が重要なポイントとなります。
- 技術的負債の管理：コストや納期とのトレードオフで解決／処理を見送った開発時の課題や残作業――すなわち、技術的負債――の管理。これらの負債をそのままにしておくとさまざまな問題がのちに発生します。
- 適切なアプリケーション資産の管理：一般的にインフラ系の資産は適切に管理され、時代遅れになった機器の処分や刷新は必要に応じて行われています。ところが、耐用年数を超えたアプリケーション資産の処分は、ハードウェアのようにうまく行えていないというのが現状です。その管理のあり方を適正化しなければなりません。
管理不備によるアプリケーション機能の硬直化
上記の「技術的負債」とは、1992年にウォード･カンニガム氏によって紹介された概念です。コストや納期とのトレードオフで「本来はしておくべきこと」を見送ったために発生する開発の課題や残作業を、「負債」という言葉で表現しています。
この負債には、例えば、「見直しが必要な複雑なコード」や「静的解析ツールの警告に対する未対処」などがありますが、開発ノウハウの非共有やトレーサビリティの欠如なども技術的負債と言えるでしょう。
当然のことながら、これらの技術的負債は開発後に（つまり、リリース後に）返済しなければならず、「リファクタリング」や「情報整理」などへの出費が、その返済に該当します。
これらの負債を管理せず、長く放置していると「支払うべき利息」も膨大な額になります。例えば、技術的負債の長期間の放置によって、アプリケーションの機能が硬直化してしまう可能性があります。
この問題を解決するには、当然、プログラム・コードを改善しなければなりません。しかし、開発から長期間が経過し、開発時のノウハウも残されておらず、コード変更による影響も分からない中で、複雑でルールに準拠していないコードを改善するのは至難のワザと言えるでしょう。また、このような状況下で、現代のアプリケーションに求められる大量の仕様変更に対処していると、開発者は自ずと自分の理解と知識だけに頼った応急措置を繰り返すようになります。結果として、硬直化がさらに進行し、運用保守コストがますます膨れ上がっていくという悪循環に陥るのです。
とはいえ、技術的負債を一挙にゼロにするというのは現実的ではなく、必要とされるのは負債の適切な管理です。それがきちんと行えれば、柔軟性とスピードの実現に寄与することが可能になります。
また、開発時の苦肉の解決策として、本来の組織ポリシーに反する実装を行う場合があり、その決断がタイムリーなリリースを実現することがあります。そのようにして発生した技術的負債も以下のような管理を行っていれば問題はありません。
- アプリケーションの負債の量と、負債部分に関する記録が正式に保管され、いつでも閲覧可能な状態になっている
- 負債が壊滅的な割合までに膨らまないよう、累積負債を完済できるだけの時間を確保する
- 負債を「引き継ぐメンバーが引き受ける」という決定が下されている
特に最後の「引き受ける」という決定が重要です。技術的負債の引き継ぎは「開発チームから運用保守チームへ」といった具合に組織をまたがるからです。
本連載でも前述しましたが、「サイロ化現象」が起きている組織では、組織の垣根を取り払うところから始めなければなりません。その垣根が取り払われることで、その他の管理も有効になるのです。
アプリケーション資産の管理不備が保守対象を増加させる
運用保守にコストがかかるもう1つの要因として、運用保守の対象となるアプリケーションの増加があります。
米国におけるいくつかの推計によると、アプリケーションは4%~7%の年間成長率で増大しています。
企業は、新しいビジネス・ニーズが発生するたびに新しいアプリケーションの運用を始動させますが、それに伴い、新しいアプリケーションと既存のアプリケーションを連携させるためのアプリケーションも必要になり、新規アプリケーションの数はみるみる増えていくことになります。
新しいアプリケーションが本番環境に導入され続けるとしても、旧来のアプリケーションが同じスピードで本番環境から処分され、保守すべきアプリケーションの数が一定の範囲内で収まっているならばいいのですが、そうなっていないほうが一般的です。
アプリケーションの数を一定数に保つには、そのための特別な労力が必要であり、意識してそれに対処しなければアプリケーションの数は増える一方となります。
しかも、最新技術を適用したアプリケーションとレガシーなものが混在している場合、
すべてのアプリケーションを維持するために多岐にわたるスキルが必要になり、多くの保守要員が必要になります。また、アプリケーション間の連携では、セキュリティ面や性能面での課題が数多くあり、連携メカニズムも複雑になります。そうした要素が複合すると、アプリケーションの運用保守は一層難しいものとなるのです。
このように考えていくと、時代遅れのアプリケーションを廃棄することが、運用保守の手間とコストを削減する最も有効な手段という結論に行き着くはずです。ところが実際には、時代遅れのアプリケーションの多くが維持されています。
その理由の1つは、レガシーなアプリケーションに実装されている業務プロセスが複雑化しており、それを他のアプリケーションにどう置き換えればよいのかを調べるだけでも多大な労力が必要とされるからです。
「そのような労力をかけるくらいなら、レガシー・アプリケーションをだましだまし使い続けたほうがいい」―― そう考える企業が依然として少なくないということです。これは、前述した技術的負債に起因した問題とも言えるでしょう。
また、2つ目の理由が、データに関するポリシーです。企業が保持しているレガシー・アプリケーションの大半は、ビジネスに必要になるかもしれない過去のデータや、コンプライアンス上、保持が義務づけられているデータ、およびコンプライアンス目的で監査される可能性があるデータにアクセスするための手段として維持されています。したがって、データ保存に関する戦略性がない企業では、旧態依然としたアプリケーションがそのまま残されることになります。
ビジネスで使うデータのライフサイクルには、「トランザクティブ（ビジネスで利用中のデータ）」、「レポート（ビジネスで参照するデータ）」、「コンプライアンス（ビジネス目的ではなく、コンプライアンスや監査で必要となるデータ）」、「廃棄（保持する義務がなくなったデータ）」の4つの段階があります。
こうしたデータを1つのアプリケーションで管理するのではなく、ライフサイクルの段階に応じて管理方法を変えていく情報管理のプロセスを運用していくことが、レガシーなアプリケーションの廃棄を可能にするのです。
アプリケーションの開発投資に「現実」を反映させる
完全ライフサイクルを考えるうえで、もう1つ大切な活動があります。それは、アプリケーション開発前に、開発に対する投資判断を行うことです。
アプリケーション開発への投資は、ビジネス・サイドからの要求を評価し、ビジネス価値の高いものに対して優先順位をつけて行うのが通常です。
実際には、社内のさまざまなチームからの意見を聞き、その結果を集計して、共通見解に近いものに集約する作業を通じて、評価を行うことになります。
ただし、この評価プロセスやアウトプットが簡易的なもので行われていると、結果的に、政治的判断で投資先の優先順位や投資額が決められてしまいます。
要求には、「ビジネス・ゴール」だけでなく、「リソースの調達」や「リスク」、「受益者の相違」といった側面があるので、複数の軸で多面的に評価することが、定量的な価値判断を可能にするとされています。
また、その軸には、「現実」への対処も含めるべきです。ここで言う「現実」への対処とは、前述した「技術的負債への対処」、「既存アプリケーション資産を破棄するための情報管理プロセス」からのフィードバックを、開発投資の評価軸へ反映させるということです。
技術的負債やアプリケーション廃棄に対する対処を開発投資に反映させようとすると、これまで行ってこなかった管理作業が発生することがあります。その場合、余分な作業が増えているように見えるはずです。しかも、運用保守チームと企画立案チームとの間に垣根がある場合、それを取り払う作業も追加で発生します。
とはいえ、これらの管理が、長期的な運用保守コストの削減につながり、結果として、より多くのIT予算を戦略的な開発投資に振り向けることが可能となるのです。そして、このような長期的視点に立ち、最適な対処を行うことこそがALMの本質となります。
以上、今回は、ALMというアプローチの詳細の説明として、アプリケーション・ライフサイクルの本質的な理解を中心に説明しました。次回も引き続きALMについて解説します。次回は、ALMのもう1つの原則である「マネジメントと自動化の統合」について具体的に説明したいと考えます。
※ これは2011年にCIOオンラインにて「【HP特別連載コラム】探求！ビジネス成長とIT革新
シリーズ3：ビジネス成果をもたらすソフトウェアを開発するために（8）」として連載したものを転載したものです。