ビジネスホワイトペーパー アプリケーションの 時代における アジリティの 実現 アジャイルにはそのような利点があると考えられているにもかかわら ず、一部の企業はアジャイルの将来性は不確定であると報告していま す。その一方で、予想以上に変更を取り込むことができると認識してい る企業もあります。また、スピードを必要とするアジャイルは、安定性を 必要とする運用と衝突する場合が多いと捉えている企業もあります。 では、従来のやり方を変えることが難しい場合、企業はどのようにした ら真のアジリティを実現できるでしょうか。まずは、アジャイルを中途半 端に利用している部分を特定し、中途半端な利用をやめることです。そ の後は、アプリケーションライフサイクル全体を理解しているかどうか によって変わります。理解していれば、継続的な「アプリケーション供 給チェーン」の一環として、開発と運用を統合させます。 アジャイル手法の利用方法 アジャイルの成果に悪影響を及ぼすライフサ イクルのボトルネック。その中で最大のボトル ネックが開発と運用のギャップです。DevOps は、このギャップを埋め、本番運用までの最 終段階を加速させることを目的としていま す。 はじめに 現在は、ビジネスのアジリティ（俊敏性）がアプリケーションのアジリ ティによって決まる、アプリケーション中心の時代です。従来のシーケ ンシャル型アプリケーションデリバリよりもアジャイル手法が注目を浴 びていますが、これはアプリケーションモダナイゼーションへの移行理 由として過去10年間で最も説得力のあるものの1つとなっています。ア ジャイル手法を使用すれば、アプリケーションチームは高品質のソフト ウェアを迅速に提供できるようになることが約束されます。また、アプ リケーションチームとビジネスチーム間のコラボレーションも促進され るため、ビジネス要件に沿ったソフトウェアになる確率が高くなること も約束されます。 モダナイゼーションによって、予測可能性、品質、変更対応能力に関す る今日のIT目標をサポートできるようになります。アジャイルデリバリを 適切に適用すれば、開発サイクルの早い段階でコードの不具合を明らか にし、プロジェクト全体のリスクを軽減させ、変化しやすいビジネスの 優先順位にも迅速に対応できるようになります。 2 高リスクを招く開発手法の混在 アジャイル手法のメリットを追い求める中で、企業の多くはその部分的 な導入に苦しんでいます。これらのケースでは、開発者はアジャイル手 法で用いられるスプリントのような反復作業を積極的に採用しますが、 ビジネスチームとQAチームは、従来のシーケンシャル手法の場合とプロ ジェクト計画における位置付けが変わっていません。そういった企業は アジャイル開発に移行したと言われることもありますが、アジャイルデ リバリはまだ達成できていません。 結果として、アジャイルの主目標である「問題の早期発見」は実現され ません。開発部門でコード作成を迅速に完了させても、それ以外のデリ バリ担当部門（ビジネスアナリスト、QAエンジニア、プロジェクト管理 者）で従来のシーケンシャル型ウォーターフォール手法とスケジュール を利用し続けるのであれば、市場投入までの時間を短縮することも、品 質を向上させることも不可能です。 ウォーターフォール 手 法とアジャイル 手 法を 混 在させるやり方は、 「scr u m m er fa ll 」という造 語が できるほどよく見られます。冗 談で 「scrummerfallで開発するプロジェクトはウォーターフォール手法のみ を利用する場合よりも倍の速さで失敗する」と言われています。 アジャイル手法を利用する場合の心的状態 ここでアジャイル本来のやり方を確認しておきましょう。アジャイルで は、反復を繰り返しながら、段階的に開発してデリバリします。アプリ ケーション機能を細分化し、それらを1つずつ処理していくことで、非常 に短期間で実用的なコードを開発できます。アジャイルが意図どおりに 実装されれば、開発手法の「こだわり」がなくなります。検証作業によっ てシステムに関するフィードバックが継続的にチームに提供され、関係 者はシステムの方向性が間違っていないことを確認します。 適切に利用されているアジャイル 実際によくあるアジャイル 細分化：明確に区別できる短い期間にプロジェクトの範囲を分割し（2∼4週間のス 変更なし プリントなど）、チームで目標に優先順位を付け、各期間内で達成できるものにつ いて実際に即して考えるようにします。 関係者との交流：形式的で独立したウォーターフォール手法とは異なり、アジャイ 変更なし ル手法ではビジネス部門の担当者に接近して絶えず連絡を取ることを奨励してい ます。プロセス全体で関係者の承認を得ることは、期待を維持させ、不快な意外性 を最小限に抑えるのに役立ちます。 問題がわかりやすい設計：各スプリントには開発とテストが含まれるため、チーム には、機能からアーキテクチャーの選択に至るまで、統合されていることを確認で きる機会があります。従来のウォーターフォール手法では、このような段階でテス トが実施されることはありません。テストが実施されるのはプロジェクトのかなり 後半の段階であり、ここで問題が判明すると非常に高いコストがかかる可能性が あるときです。 システムテストの代わりにユニットテストが実施されます。本格的な全体検証はプロ ジェクトの後半になるまで実施されません。遅れが生じたプロジェクトは、ウォー ターフォール手法の場合と同じリスクにさらされることになります。つまり、 「予期し ない問題が発生し、それを解決する時間が少ない」というリスクです。 厳格な蓄積型テスト：開発チームが各スプリントを進める際には、それまでに開発 したすべての機能の回帰テストを実施します。これにより、最新の開発スプリント によってそれまでに開発された機能に影響が出ないかどうかがわかります。問題が 発生する場合は、プロジェクト全体ではなく、最新のスプリントに限定したトラブ ルシューティングが行われます。 部分が全体に間違えられます。過去のスプリントの作業を検証する回帰テストを実 施することなく、各スプリントは単独でテストされます。チームはプロジェクトの後半 になるまで、蓄積されたアプリケーション機能、パフォーマンス、セキュリティについ て把握しておらず、問題があっても対処する時間はほとんどありません。 変更を受け入れる設計：要件および設計作業のすべてを考慮して始めるのではなく チームは変更を柔軟に受け入れますが、受け入れる準備はできていません。欠点は、 （その多くは時間が経つにつれて変化します）、当初は高レベルの範囲や機能の 変更が生じたときに、その影響をほとんど理解することなく取り入れることです。 みが指定されます（ユーザーが判断します）。詳細は、アプリケーション自体の動 作が確認されたときに、それに応じてスプリントごとに決められていきます。 実際の進捗の測定：アジャイルでは、ソフトウェア開発について、作成される実行 テストが成功しなければ、開発が進んだとは言えません。 ファイルにこそ価値があると考えられています。進捗状況は、実施されたサインオ フミーティングの回数や、記述されたコードの行数、作成された技術文書ではな く、テスト済みの実用的なコードによって測定されます。 アジャイルと従来のIT：高度な融合を実現 企業がアジャイル手法を全面的に採用するのを遅らせている理由の1つ として、プラスよりもマイナス面が多いことを不安視していることが考 えられます。しかしながら、アジャイルの柔軟性や反応性といったメリッ トを享受しても、一貫性や完全性といった従来のITが目指していること を諦める必要はありません。 これらの目標は双方でサポートされます。従来のITが目標としている主 な分野を考えてみると、適切に実行されれば、アジャイルの目標を推進 するのに役立つ場合があります。 スピードと品質 アジャイルにおける測定値として最も有名なのがベロシティです。これ は機能を提供する速度のことです。この数値を高い状態で維持するた めに、チームによってはユニットテストを十分に行ったとして回帰テス トを犠牲にする場合があります。また、パフォーマンスやセキュリティ など、機能に関係しないものの検証を遅らせる場合もあります。このよ うなチームは結果として、遅い段階で問題が検出され、本番運用時の障 害が増加することになります。 これはスピードと品質が両立しないということではなく、QAチームが開 発と同じペースを保つことを望んでいるのであれば、可能な限り手動で の作業を回避することが重要になるということです。たとえば、手動テ ストであってもHP Sprinterを使用すれば迅速になります。HP Sprinterで は、自動データ入力や、1人のテスト担当者が複数のブラウザ環境に対 して重複作業を行う「ミラーテスト」が可能です。また、不具合のドキュ メント化と再現を容易にするためのテスト手順を自動的に記録する機 能も搭載されています。 コードベースがスプリント間で増大していくにつれ、スピードと品質を 維持するためにはテストを本格的に自動化することが必要となります。 HP Unified Functional Testingは、グラフィカルユーザーインターフェイス （GUI）のテストだけでなく、GUIをまったく備えていないサービスやコン ポーネントのテストも自動化する機能を提供します。また、HP Service Virtualizationを使用することで、開発担当者とテスト担当者はシミュ レーション環境または仮想環境において、高度に制限されたサービス や提供されていないサービスのテストも実行できます。 3 柔軟性と一貫性 迅速な反応と完全さ 情報が古くなることも多い煩雑なプロジェクト計画を使用する従来の 手法とは異なり、アジャイル手法は変更に対して柔軟で迅速な対応を 可能にします。ただし、アジャイル手法はその場しのぎのプロジェクト 管理になる場合があります。 アジャイルでは、変更に対して不安に思うのではなく、予想しておくよう 促します。どの企業でも、開発スピードを低下させるオーバーヘッドや 形式的な作業の負荷を負うことなく、迅速に適応する機能を求めていま す。しかしながら、これを達成するには、変更点とその理由を的確に捉 えることが必要となります。HP ALMに含まれているHP Application Lifecycle Intelligence（ALI）は、広範な統合開発環境、ソースコード、ビ ルドシステムに自動的に接続して、追跡機能をコードに至るまで拡大 し、ビルドおよびテストを含む要件からコードまでのすべての資産にア クセスできるようにします。開発担当者は、同僚や広範なデリバリ組織 にも自動的に接続しながら、自身で選択したツールを使用して作業でき ます。 HP Application Lifecycle Management（HP ALM）を、HP Agile Accelerator と組み合わせて使用することで、シーケンシャル型とアジャイル型の両 プロジェクトを効果的に管理できるようになります。これにより、アジャ イルチームは、効果的なユーザー主体の定義および管理、リリース/スプ リント/バックログの管理、バーンアップ/バーンダウン/スプリント間のベ ロシティチャート、自動タスクボードなど、適切な機能を利用できるよ うになります。また、アジャイルを利用しないチームも、従来の測定値 を同じソリューションから利用できるようになります。 独立精神とスケールメリット アジャイルは、小規模チームと強い自主性を奨励します。これらは優れ た目標ですが、チーム間のコラボレーションや知識共有が行われなくな る可能性があります。また、独立したチームは、再利用も困難にするた め、作業や機能の重複を招き、デリバリコストとサポートコストの両方 を増大させる可能性があります。 HP ALMを使用することで、再利用可能な資産の統合リポジトリが提供 されるため、どのチームも場所を問わずに、 「再利用可能なテストが実 施されているかどうか」、 「要件が引き出されているかどうか」、 「不具 合が挙げられているかどうか」といったことをすぐに確認できるように なります。 大規模な分散チームの場合も、HP Enterprise Collaborationなどのコラボ レ ー シ ョン ツ ー ル か ら メリット を 得 ら れ ま す。H P E n t e r p r i s e Collaborationは、コンテキストベースのコラボレーションおよび知識共 有ための統合されたソーシャルメディア型のモジュールです。 これはつまり、変更要求が新たに送られたときに、変更内容を考慮して 要件を選択できるということです。そして、エンドツーエンドの追跡機 能によって、迅速でありながらも詳細なインパクト評価を実行し、コー ドをアップデートして、必要な変更をすべて特定して加えたことを確信 して導入できるようになります。 scrummerfallの犠牲になったことはありますか アジャイルの取り組みによる効果を判断する ために組織で確認できる主な3つの項目： 1. アジャイルプロジェクトにおいて、従来のプロジェクトよりもラ イフサイクルの早い段階でコードの不具合が検出されている か。アジャイル手法を取り入れると、早い段階で問題が常に表 面化します。 2. アジャイルを取り入れたプロジェクトは、取り入れなかったプロ ジェクトと比 較して、最 終的な 製品の 不 具合が 少ないか。ア ジャイルを取り入れた場合は、修正にかかるコストを削減しな がら、ソフトウェアプロジェクトの品質を向上させることができ ます。 3. ビジネス部門の担当者は概して、アジャイルプロジェクトへの 満足度が高いか。アジャイルにより、ビジネス部門とIT部門が それぞれの期待を伝え合うことができるようになります。 4 重要な最終段階 アジャイルのデリバリチームは、駆け足でソフトウェアを開発します。し かしながら、常用しているリリースプロセスで時間がかかるようであれ ば、新機能を迅速に開発できても意味がありません。 この課題は、Forrester社のリリース管理に関する調査で明らかになって います。1行のコード変更のリリースにかかる時間（原則的にリリースプ ロセスの運用上のオーバーヘッドを計測）の調査では、回答者の80%以 上が1日以上、そして44%が1週間以上かかると答えています。 アジャイル開発によるメリットを活用し、ビジネスバリューへの転換を 向上させるために、アジャイルの原則を運用にも拡張させる時代になっ ています。 図1：リリースにかかる時間の調査 「御社のプロジェクトでコードを1行変更する場合、変更内容を 本番運用に反映させるには通常どれくらいの時間がかかります か？」 4時間未満： 7% 4時間以上、1日未満： 11% 1日以上、1週間未満： 39% 1週間以上、2週間未満： 11% 2週間以上、3カ月未満： 3カ月以上： 18% 4% 出典：Forrester Research Inc.、 「Five Ways To Streamline Release Management （リリース管理を簡素化する5つの方法）」2011年2月（ITプロフェッショナル101 人へのアンケート） DevOpsと継続的なデリバリ 新しいDevOpsは、開発とIT運用のギャップを埋めることを求めており、 まさにこの課題に対応しています。DevOpsはアジャイルの影響を受け て、原則と手法がセットになっており、2つのグループ間のコラボレー ションの向上に焦点を絞っています。DevOpsで実現される継続的なデ リバリは、最も重要な 「ユーザーが実際に利用できる機能になるまで のサイクルの短縮」に焦点を絞っています。また、コラボレーションの向 上だけでなく、ビルド、テスト、導入プロセスの包括的な自動化も重要 視されています。極端に言えば、一連の自動化されたテスト用クラウド を通過するすべてのコード変更が即座に導入されるようなレベルになる ことです。本番運用への自動的な導入は特定の状況でのみ可能なこと ですが、運用上の制約になってもビジネスニーズに合わせたリリースが 実現されるため、開発と運用の間でこのように高いレベルで統合される のは画期的なことです。 DevOpsと継続的なデリバリの導入を成 功させるための鍵となるもの は、品質、自動化、そしてコラボレーションです。これら基本的な要素が すべて揃うことで、従来のITサイロを一元化し、エンドツーエンドのアプ リケーションライフサイクル全体にわたってアジリティを実現できるよ うになります。 信頼性獲得につながる品質 効果的なDevOpsは、信頼することから始まります。つまり運用チーム が、アジャイル手法を活用して迅速に作業する開発チームは時間短縮の ために手抜きをすることはないと信頼することです。変更を迅速に適用 することに焦点を絞る開発チームと対照的に、運用チームの従来の考 え方は、変更は問題発生やシステム停止といったリスクにつながるとい うものです。運用チームが重点を置いているのは、実際には一般的に評 価される方法ですが、アプリケーションの可用性と安定性です。品質の 低いソフトウェアのリリースに伴う問題を回避するために、変更を最小 限に抑えようとする場合が多いのも理解できます。このような正反対の 2つの視点を融和させる鍵を握るのが品質です。品質が高くなければ、 DevOpsに必要な信頼関係はすぐに維持できなくなります。 リリースプロセス、つまりパイプラインはコードのチェックインから始ま ります。適切な手法は、このパイプラインを通して進められるので、変 更の品質を大幅に高めることができます。すでに継続的な統合を使用 して、1日に何回かビルドを行っている場合、自動化されたビルド検証や 回帰テストと組み合わせることで、効果がさらに高まります。テストラボ を ス ケ ジュー リン グ、プ ロビ ジョニ ン グ、導 入するた め の H P L a b Management Automationの機能によって、最初から高い品質でこの継続 的なテストを実施できるようになります。開発担当者は定期的にタイミ ングよくフィードバックを得られるため、機能に関するかどうかを問わず 問題が特定されて初期段階で修正されます。結果として、不具合が蓄積 されることなく、進捗を正確に捉えることができ、本番運用にリリース される前に不安定さが緩和されます。このため、開発チームは、運用 チーム側からすれば大きな懸念であるリスクを緩和させながら、さらに 機能を迅速に提供できるようになります。 自動化によりアジリティを実現 次に重要な要素が「自動化」です。リリースプロセスを考慮すると、手動 の手順が存在すると、それが手動でのハンドオフや承認、あるいはテス トなどの手動タスクであっても、リリースまでの時間に大きく影響しま す。大部分の企業のリリースプロセスは、多くの手動でのステップで構 成されており、複数の担当者が分厚いドキュメントとチェックリスト（こ れらも手動で編成されエラーが生じやすい）を使用して実行します。こ のアプローチは、アジャイルとはほど遠く、間違いの発生率が高い可能 性があります。 自動化によって、チームはこのような手動のハンドオフをなくし、エラー を減らし、さらにはリリースにかかる全体的な時間を短縮できるように なりま す。この 場 合 に 重 要 となる の が、H P C o n t i n u o u s D e l i v e r y Automationに搭載されている、アプリケーションの移植という機能で す。これによってチームはビルドしたアプリケーションを、どこでも容易 に導入できるようになります。移植機能は、開発、テスト、運用で共有さ れる環境に対応したアプリケーションモデルによって達成されます。誰 もが同じ資産と方法を使用して導入するため、開発、テスト、ステージ ング、本番運用におけるさまざまな環境において、結果に一貫性があ り、正確な導入環境が実現します。さらに、オンプレミスをベースとした 環境、異なるクラウドベンダーにまたがる環境、組み合わされたハイブ リッド環境をサポートする高い柔軟性をもっています。 5 サイロ同士をつなぐコラボレーション 図2：HP Executive Scorecard 効果の高いコラボレーションでは、従来の開発/運用の関係を表す「バ ケツリレー」や責任転嫁のようなことは行われません。非同期のレイテ ンシーは回避され、メールスレッド、電話、その他のレガシーメディアが 途切れることはなく、両チームが共通の目標にフォーカスできます。ま た、コラボレーションでは、いずれかの環境で得た教訓を別の環境でや り直す必要がないように、資産の共有た再利用を必要とします。 DevOpsのコラボレーション構築は、アジャイルチームがスプリントのプ ランニングセッションとスプリントの最後に実施されるデモに運用担当 者を加えるだけで、始めることができます。日々のアイデア共有や問題 解決関するチームのコミュニケーションは、前述したHP Enter prise Collaborationのようなソーシャルメディア型のコラボレーションツール を使えば効率的に行うことができます。 2つのグループ間でツールを統合することによっても、グループ間の障 壁を排除し、皆が共有の言葉で会話することできます。HPのポートフォ リオの統合機能には、次のようなものがあります。 • QAで使用されるパフォーマンステストのスクリプトは、自動的にパッ ケージ化され、運用に送信されるため、運用チームで再作成する必要 はありません。 • 本番運用での使用パターンは、直接HP Performance Centerにインポー トされ、より正確で実際に即したテストシナリオが作成されます。実 際のユーザーセッションは、自動的にパフォーマンステストのスクリ プトに変換できます。 • 開発と運用に共通のパフォーマンス診断ツールによって、データ共有 や問題の相互理解が可能になるため、分析や解決が迅速化します。 • 本番運用での問題解決のための双方向の情報交換：本番運用におい て問題が発生すると、自動的に開発の障害を記録し、その他のバック ログ項目に対してすぐに優先順位を付けることができます。開発で障 害が解消されたら、サービスデスクで自動的に更新されます。 大事なのは、HPのExecutive Scorecardにより、開発と運用にわたる情報 の「一元的なビュー」が提供され、これら両チームの協力状況について、 より明確に可視化できるようになることです。DevOpsの個々の測定基 準やKPIを設 定して連携させる機能によって、関係 者が同じ方向性を 持って作業できるようにする測定値と動因を調整できます。 6 あらゆる要素を一元化：包括的な アプリケーションライフサイクル アプリケーションの本当のライフサイクルは、要件定義から配備までよ りも広いものです。それは、アプリケーションを計画、デリバリ、運用す る継続的なサイクルであり、ビジネスアイデアで始まり、アプリケーショ ンの廃棄で終わります。これらの領域それぞれが影響を与え、基本的に 互いにリンクし合っています。アジャイルを取り入れようとする場合、プ ランニング用に1つ、デリバリ用に1つ、開発および管理用に1つなど、こ れら3つの領域を別々のライフサイクルとして扱う余裕はありません。 必要なのは、一元化されたシームレスなライフサイクルです。 Gartner社の調査では、15年間利用されるアプ リケーションの場合、総所有コストの8パーセ ントしか初期の開発にかかっていないと予測 しています。残りの92パーセントは、メンテナ ンス、機能拡張、運用に費やされています。こ れは、アプリケーションの開発と管 理には ライフサイクル全体を捉えた幅広い視点が 重要であることを明確に示しています。 図3：包括的なアプリケーションライフサイクル 運用 計画 最後に、ライフサイクルを完了させるステップがアプリケーションの廃 棄になります。アプリケーションは、効果的に利用されるべきで、本当 に有効である期間以上に維持すべきではありません。廃棄は、アプリ ケーションのコストがその価値を上回った時点を把握し、データのアー カイブ方法を提供し、アプリケーションをオフラインにしてそのリソー スの再プロビジョニングを行います。これにより、ポーフォリオの拡大に 潜む落とし穴や、増大の一途を辿るメンテナンスコストを回避して、IT の軽快さを維持できます。 アジャイル手法を活用する企業 廃棄 デリバリ 計画、デリバリ、運用、廃棄 アジャイル手法は開発担当者によって構築されるため、必然的にアプリ ケーションライフサイクルのデリバリ部分に重点が置かれます。DevOps や継続的デリバリといった考えは、アプリケーションのデリバリと運用 とのギャップを埋めることにより、包括的なライフサイクルの実現に向 けた大きな一歩を踏み出させます。一方で、計画と廃棄は取り残されま す。 粗悪なものを早くデリバリしてビジネスがうまくいくことはありませ ん。デリバリのサイクルを迅速化すれば、計画に関する課題は高まりま す。全体像を見落とすことなく、ペースの速い多数のプロジェクトに対 応する必要があるからです。要望はあらゆる方向から出されます。ビジ ネスチームからは機能強化や戦略的なニーズ、サービスデスクからは本 番運用の問題、開発および運用チームでは品質とメンテナンスに関す る改善点が特定されるなど、広範囲にわたります。 HP Project and Portfolio Management、HP Service Manager、HP ALMを統 合すれば、このような要望を満たす一元化されたビューが提供され、要 望に優先順位を付け、ビジネス目標に合わせることができるようになり ます。そしてそれは、リリースの計画や準備に必要なステップへとつな がっていきます。たとえば、利用できる予算の範囲内で対応可能な要望 を理解したり、プロジェクト間でリソースを割り当てて管理したりするこ とができます。プロジェクトが開始されると、計画は、要望を管理する とともに、一元化された作業の進捗状況、予算、人員配置を追跡するた めの継続的なプロセスとなります。プロジェクトおよびポートフォリオ の計画に対する確実なアプローチにより、IT幹部は信頼できるデータを 使用してすべての決定に対応し、混乱した環境に安定をもたらすことが できるようになります。 アジャイルの原則が企業全体で広まっていくにつれて、ビジネスへのプ ラスの影響も大きくなります。アジャイル開発からアジャイルデリバリ に移行するには、迅速に高品質のソフトウェアを開発するために、サイ ロを解体し、全作業者のチームとしての協力体制を強化させる必要が あります。これは、各スプリントで小規模なウォーターフォール手法を実 行することで陥るscrummerfallの落とし穴を回避し、貴重なリソースを 無駄にしないための重要なステップです。 次のステップとなる「継続的なデリバリ」は、アジャイル手法をベースと して、最終段階を進み、ユーザーの手元に迅速に届くことに価値を置く ことで、デリバリを改善します。これは、ビルド、テスト、導入プロセスを 自動化し、DevOpsの原則を通じてコラボレーションを強化することで 実現されます。 最終的に最も要望の高いステップが、究極的にはどの企業も探し求め ている「真のビジネスアジリティの実現」です。新機能をユーザーに迅 速に提供できるようになると、絶え間なく続くユーザーからのフィード バックを積極的に受け入れるようになります。ユーザーからこのような 反応を受けると、変わりやすいニーズをタイミングよく理解できるよう になり、より正確な軌道修正と情報に基づく意思決定を行えるようにな ります。本質的には、アジャイルの概念である「調査と順応（inspectand- adapt）」をビジネスレベルで適用しています。 結果としてビジネスがさらに加速されます。HPはより精度の高いフォー ドバックループを持つことにより、速いペースでユーザに価値を実現 し、ユーザに対する理解を深めることができます。 図4：アジャイルのビジネスインパクトの拡大 ネスアジリティ ビジ 継続 的なデリバリ イルデリバ リ ジャ ア アジャイル 開発 • ユーザーから継続的な フィードバックを得て、 方向性の決定に利用する • 短期間のサイクルで ユーザーに価値を提供 • DevOpsによって実現 • 包括的なアプリケーション ライフサイクルに対応 • 品質が効果的に融合 • 企業規模に拡大可能 • 開発にフォーカス • 小規模なチームと イニシアチブ 7 HP IT Performance Suite（ITPS） HP IT Performance Suiteは、企業が包括的なアプリケーションライフサ イクルを使いこなすことができるようサポートするものです。それは、 バックログおよびスプリントの管理、ユーザー環境および品質の管理、 開発者の環境との統合など、アジャイルの中心的なデリバリプロセスを 管理するための結合プラットフォームから始まります。 HPはまた、企業が包括的なライフサイクルを実現できるよう支援しま す。HPのデリバリソリューションは、広範なポートフォリオの中心に位置 付けられており、プロジェクトおよびポートフォリオの管理、アーキテク チャの管理、配備の自動化、サービス管理、さらにはコラボレーション のプラットフォームまで、ライフサイクルの他の要素を統合します。基本 的なすべての機能およびライフサイクルのすべての要素にわたってHP は、ビジネス目標に合致したIT、ハイブリッドIT環境の管理、セキュリ ティの脅威からの保護、リスクの低減を支援します。 HPが選ばれる理由 HPのようにアプリケーションの最初から最後までをサポートできる企業 は他にありません。HPが提供するものは、ゆるやかに結合したポイント ツールではなく、すべての関係者のニーズを満たすライフサイクル管理 と自動化を実現する統合プラットフォームです。テクノロジーの種類を 問わないソリューションを提供するというHPの取り組みは、すべての環 境をサポートします。HPでは、.NET、Java、SAP、Oracleを始めとして、70 以上の環境をサポートしています。従来の手法かアジャイル手法かに関 係なく、また10人のチームでも、何万人も抱える企業でも、HPのソリュー ションによって実績ある構成機能、スケーラビリティ、順応性が企業に 提供され、包括的なアプリケーションライフサイクル全体にわたって真 のアジリティを達成できるようになります。 HPサービス H Pサービスは、アジャイルやDev O psの課 題を解決しながら、H P I T Performance Suiteのメリットを実現できるよう企業を支援するもので す。コンサルティングに関する専門知識、知的財産、そして広範なポー トフォリオをご用意し、HPは以下のサービスを提供してお客様を支援 します。 戦略的なアドバイスサービス DevOpsなどの転換を成功させるには、戦略的なロードマップを策定で きる必要があります。ビジネス目標を満たす能力を段階的に提供でき るよう共通の視点を持ってサポートされ、複数のイニシアチブに基づい たロードマップにします。 ソリューションのコンサルティング これらサービスによって、人員、プロセス、ソフトウェアを組み合わせ て、戦略的な IT目標を実現できるようにします。HPソリューションは、 世界中で成功を収めた数百件もの導入実績によって構築および策定さ れてきたHP独自の知的財産を基盤としています。ソリューションのアー キテクチャーと設計、プロセスコンサルティング、変更管理、ソフトウェ アの統合および実装の各種サービスは、これらソリューションの一環と して提供されます。 HP IT Performance Suite実装サービス ソフトウェア実装パッケージの包括的なセット、およびアップグレード サービス、移行サービスを利用することで、HP ITPSソフトウェアの機能 を迅速かつ効果的に活用できるようになります。これには、ラボ管理、 テスト管理、機能テスト、パフォーマンステスト、セキュリティテスト、 コラボレーション、ITおよび運用の管理といった主なコンポーネントが 含まれます。 Get connected hp.com/go/getconnected テクノロジートレンド、サポート情報、 およびHPソリューションの詳細をご確認ください。 © Copyright 2012 Hewlett-Packard Development Company, L.P.本書の内容は、将来予告なく変更されることがあります。 HP製品およびサービスに対する保証については、当該製品およびサービスの保証規定書に記載されています。 本書のいかなる内容も、新たな保証を追加するものではありません。本書の内容につきましては万全を期しておりますが、 本書中の技術的あるいは校正上の誤り、脱落に対して、責任を負いかねますのでご了承ください。 JavaおよびOracleは、Oracleまたはその関連会社、またはその両方の登録商標です。 4AA4-1750JPN（2012年6月作成）
© Copyright 2024 ExpyDoc
