ここでは、アプリケーションマネジメントについて、次の観点で説明します。
アプリケーションマネジメントとは何か
ここでは、アプリケーションマネジメントを次のように定義します。
- 企業全体のアプリケーションの品質、セキュリティ、経済性を維持、向上するために（Why）
- アプリケーションマネジメント組織が（Who）
- アプリケーションマネジメントプロセスに従って（How）
- アプリケーションのライフサイクルを管理すること（What）
企業全体のアプリケーションを対象にしているということは、アプリケーションの機能、品質、セキュリティの全体最適化を通して、経済性を最大化する（アプリケーションの開発、維持管理コストをできるだけ抑えて、それによってもたらされる経済価値を最大にする）ということです。
アプリケーションの開発、維持管理コストをできるだけ抑えるためには、アプリケーションの生産性や保守性を高める必要がありますが、生産性や保守性を高めるための重要な考え方や方法に
があります。
マイクロサービスとは、協調して動作する小規模で自律的なソフトウェア部品のことで、マイクロサービスアーキテクチャは、アプリケーションをマイクロサービス化することで、アプリケーション開発の生産性と保守性を上げようとする考え方です。
また、DevOpsとは、開発 (Development) と運用 (Operations) を組み合わせることで、ソフトウェアを迅速に高い頻度で開発することを可能にする手法のことです。
アプリケーションマネジメントは、DevOpsやマイクロサービスアーキテクチャを適用することで、次のような課題を解決し、ビジネスの変化に合わせて、俊敏（アジャイル）に、品質の高いアプリケーションを導入できるようになることを狙いとします。
- 小規模で自律的なアプリケーションおよび組織による生産性と保守性の向上
- 作業のムリ、ムダ、ムラをなくすことによるリードタイムの短縮化
- フィードバックによる問題の早期発見と解決
- 継続的な学習と実験によるプロセス品質の改善
マイクロサービスアーキテクチ
とは、協調して動作する小規模で自律的なソフトウェア部品のことです。
マイクロサービスについては、書籍
が参考になります。
既存の基幹システムをマイクロサービスとしてモジュール化することによって、アプリケーション開発の生産性と保守性を上げることができます。
この例では、画面まわりを処理するフロントエンドアプリケーションが、ビジネスロジックとデータアクセスを制御するマイクロサービスを使う構造になっています。
これによって、新しいフロントエンドアプリケーションを開発するとき、すでに在るマイクロサービスを部品として再利用することができるので、開発の生産性が上がり、企業を変化に強い構造にすることができます。
また、データ構造が変わった場合、関連するマイクロサービスは影響を受けますが、そのマイクロサービスを利用するフロントエンドアプリケーションは一切影響受けないので、高い保守性を実現することができ、企業を変化に強い構造にすることができます。
マイクロサービスという技術を活用して企業全体のアプリケーションをモジュール化（部品化）し一元管理することで、システムの保守性、安全性など品質を向上させ、企業を「変化に強い構造」にすることができます。
DevOps
DevOpsとは、開発 (Development) と運用 (Operations) を組み合わせることで、ソフトウェアを迅速に高い頻度で開発することを可能にする手法のことです。
「The DevOps ハンドブック 理論・原則・実践のすべて」という書籍には、DevOpsを支える次の３つの実践原則について言及しています。
- フローの原則
開発→運用→顧客の左から右へのワークフローを高速にすること。
書籍では、これを実現するため必要な方法として次のことを上げています。- 作業を可視化すること
- WIP（仕掛り）を制限すること
- バッチサイズを縮小すること
- プロセスを自動化して受け渡しの数を削減すること
- 絶えず制約条件（ボトルネック）を見つけ出すこと
- バリューストリームからムダを取り除くこと
これを見ると、作業のムリ、ムダ、ムラをなくすといいうリーン生産方式、および、アジャイル開発の考え方が反映されていることがわかります。
バリューストリームとは、ビジネス上の仮説を立案してから、顧客に価値を送り届ける技術サービスを生み出すまでの間に必要なプロセスのことです。
バリューチェーンで言えば、主要活動の流れということになります。
また、上記プロセスの自動化には、テストからデプロイまでを自動化する継続的デリバリの考え方が反映されていますし、マイクロサービスアーキテクチャを適用することで、バッチサイズを縮小することができます。 - フィードバックの原則
バリューストリームのあらゆるステージで、すばやくてコンスタントな右から左へのフィードバックフローを実現すること。
書籍では、これを実現するため必要な方法として次のことを上げています。- 発生と同時に問題を知ること
- 新しい知識を作り上げるために組織が一丸となって問題解決に当たること
- 上流での（早めの）品質確保を追求すること
- 下流の（次の）ワークセンターのために最適な出力をすること
これを見ると、フィードバックによって問題の早期発見と解決を図ることで、問題を先延ばしすることなく、安全で回復力（レジリエンス）のある作業システムを構築することができることがわかります。
- 継続的な学習と実験の原則
ダイナミックで統制がとれた科学的なアプローチに基づく実験とリスクテイクを支持し、成功と失敗の両方から組織として学習し教訓を得ていく生産的な高信頼マネジメントの企業文化を生み出すこと。
書籍では、これを実現するため必要な方法として次のことを上げています。- 日常業務の改善を制度化すること
- ローカルな発見をグローバルな改善に転化すること
- 日常業務に回復力を鍛えるパターンを注入すること
- リーダーが学習する文化を奨励すること
これを見ると、継続的な学習と実験によってプロセスを改善する文化をつくりだすことが重要だということがわかります。
アプリケーションマネジメントはなぜ必要なのか
変化が激しく、不透明で先行きが予測できない昨今の経営環境を、
- Volatility（変動性）
- Uncertainty（不確実性）
- Complexity（複雑性）
- Ambiguity（不透明性）
の頭文字をとってVUCA（ブーカ）という言葉で表すことがあります。
それは、SNSやモバイル技術によって人と人がつながる時間や距離が短くなったことで、
個人の欲望や考えが、複雑なネットワークを介してすぐに世界中に広がり、
いつどこで、どんな需要が生まれるか読みづらく、欲求の新陳代謝も激しくなっているからではないでしょうか。
このような時代、環境の変化にアジャイルに対応しながらビジネスを展開していく必要がありますが、複雑化、ブラックボックス化した既存の業務やシステムが足かせとなってスムーズに適応できない会社が多々あるようです。
多くの会社が、
ビジネスの変化が加速し、ビジネスとITが密接化する中、全体の設計図もなく、必要に応じてシステムを導入してきた結果、
- 大規模で複雑なシステムがサイロのように乱立している
- 重複して整合していないデータが散在している
- 個別の業務やシステムは詳しいが全体を理解できる人や資料がない
というカオスで雁字搦めな状況に陥っています。
経済産業省が2018年に出したDXレポート ～ITシステム「2025年の崖」の克服とDXの本格的な展開～ではでは、企業がDXに対応できない現状を、
- 既存システムが、事業部門ごとに構築されて、全社横断的なデータ活用ができなかったり、過剰なカスタマイズがなされているなどにより、複雑化・ブラックボックス化している
- 経営者がDXを望んでも、データ活用のために上記のような既存システムの問題を解決し、そのためには業務自体の見直しも求められる中(=経営改革そのもの)、現場サイドの抵抗も大きく、いかにこれを実行するかが課題となっている
と分析した上で、このような状況を改善できない場合、
- データを活用しきれず、DXを実現できないため、市場の変化に対応して、ビジネス・モデルを柔軟・迅速に変更することができずデジタル競争の敗者になる
- 多くの技術的負債を抱え、業務基盤その ものの維持・継承が困難になる
- 保守運用の担い手不在で、サイバーセキュリティや事故・災害によるシステムトラブルやデータ滅失等のリスクの高まる
という状況に陥り、DXが実現できないのみでなく、2025年以降、全体で最大12兆円/年(現在の約3倍)の経済損失が生じる可能性(2025年の崖）と予想しています。
技術的負債(Technical debt)とは、短期的な観点でシステムを開発し、結果として、長期的に保守費や運用費が高騰している状態（要は金食い虫）のことです。
次の図は、技術的負債が発生するメカニズム、つまり、システムが収益を生まない金食い虫になるメカニズムを示したものです。
これを見ると、様々な原因が重なって、機能追加・変更に対応できるコストの低下を招いていることがわかります。
つまり、「機能追加・変更に対応できるコストの低下」が技術的負債を発生させる根源になります。
そこで、これを解消するために「低コストで品質を確保し迅速に機能追加・変更できる仕組の導入」という新しい原因を追加します。
すると、次の図のように、これまで問題となっていた事象を防いで、結果的に障害対応コストの増加を抑えるとともにIT人材を確保することができるようになります。
アプリケーションマネジメントは、低コストで品質を確保し迅速に機能追加・変更できる仕組で、これを導入することで、技術的負債の増加を防ぎ、IT投資の効果を最大化することができるようになります。
アプリケーションマネジメントを会社に導入するにはどうすればよいか
それでは、アプリケーションマネジメントはどのように導入すればよいのでしょうか。
最後に、アプリケーションマネジメントの導入プロセスについて見ていきましょう。
次の図は、アプリケーションマネジメント成熟度モデルを、各分野別に詳細化したものです。
アプリケーションマネジメントは、次の図のように一つの戦略サイクルで導入されます。
※アプリケーションマネジメントが導入された後も、新しく戦略サイクルが開始する都度、このアプリケーションマネジメントプロセスが実行されます。
AM成熟度でいうと、設計フェーズで、アプリケーションマネジメントモデルを設計した段階で、レベル３，定義された状態になり、
AM戦略を策定し、それにもとづいてAMシステムを構築し、１回以上運用することでレベル４、管理された状態になります。
アプリケーションマネジメント導入プロセスの概要は次のようになります。
- アプリケーションマネジメントモデルの設計
アプリケーションマネジメントの目的、体制、方法など本質となる型を設計します。
その際、あるべき（To-Be)アプリケーションアーキテクチャ、アプリケーションマネジメント組織、アプリケーションマネジメントプロセスを概念レベルで設計します。 - アプリケーションマネジメント戦略の策定
アプリケーションマネジメントモデルを具体的にどう実現するのか戦略を策定します。
その際、アプリケーションマネジメントのビジョン、および、あるべき（To-Be)アプリケーションアーキテクチャ、アプリケーションマネジメント組織を論理レベルで設計します。
その上で、現行（As-Is)のアプリケーションアーキテクチャ、アプリケーションマネジメント組織とのギャップを明確にします。
その結果を踏まえて、アプリケーションマネジメントシステムの構築計画と運用系各区を策定します。 - アプリケーションマネジメントシステムの構築
戦略フェーズで策定したアプリケーションマネジメントシステムの構築計画に従ってアプリケーションマネジメントシステム（アプリケーション基盤およびアプリケーションマネジメント組織）を構築します。 - アプリケーションマネジメントシステムの運用
設計フェーズで設計したアプリケーションマネジメントプロセスに基づいてアプリケーションマネジメントシステムを運用します。
アプリケーションマネジメント導入のアプローチは次のようになります。
- 概念レベルのモデルの設計（①）
まず、概念レベルのあるべき将来モデルを設計します。 - 論理レベルのモデルの設計（②）
次に、論理レベルのあるべき将来モデルを設計します。 - 論理レベルのモデルのギャップ分析（③）
次に、論理レベルのあるべき将来モデルと現行のモデルのギャップを分析します。 - システムの構築と運用
論理レベルのモデルのギャップ分析の結果を踏まえて、システムを構築、運用します。
システムを構築する場合、次の２つの方法があります。- 既存のシステムをベースに構築する場合（④-a）と、
- 新規にシステムを構築する場合（④-b）があります。
ポイントは、まず、概念レベルのモデルを、全社レベルで広く粗く明確にし、それから粒度を細かくしていくトップダウンアプローチをとることで、漏れなくダブりなく、企業全体で最適なシステムを構築することができます。
粒度の細かい現行の物理レベルのモデルから現行の論理レベルのモデルを抽出するというボトムアップアプローチをとると、経験則上、そこで疲弊してしまい先に進めなくなります。
なので、最初に現行の論理レベルのモデルを網羅するのではなく、論理レベルの将来モデルをベースに、それと比較できる現行モデルの部分だけ可視化するようにします。
それから、アプリケーションマネジメントはDXの一環として導入される場合もあり、DXのプロセスの中で考えると次の図のようになります。
[…] 記事アプリケーションマネジメントのアプリケーションマネジメント& […]