IT サポート ワークフローを改善する方法
ITSM システム アップグレードの増加による負担への対処法を求めて
製品所有者は従来の ITSM システム アップグレードの代替として何を学んだのでしょうか。
私はスクラム チームの製品所有者として、従来の ITSM システムを使用していくつかのサービス管理プラクティスの機能を開発していました。年度内の最後のスプリントが終わると、チームは新たな機能を学び、試すことのできるイノベーション スプリントに進みました。私はこのイノベーション スプリントで ITSM システムの新しいリリースを調べました。一見すると、新機能が多数あるように思われました。しかし、よく見ると、新しい機能は関係者の役には立たず、技術的負債が増える原因になりそうでした。
私たちのレガシー ITSM システムに本質的なサポートの問題があることが判明すると、選択肢は 2 つになりました。つまり、これを受け入れてその負担に耐え続けるか、より堅牢で柔軟なソリューションを探すかです。
しかし、これからプロセス オーナーやその他の関係者と何度も会議を重ねることは大きな負担になると想像できました。新しいリリースの内容、開発スケジュールの中断、そして最終的には、この作業からはそれほど大きな効果が得られないことを説明することを考えただけで、非常にストレスを感じました。アップグレードの増加では、利用できる機能の数に関係なく、常に一定して冗長プロセスや生産性の低下が生じるからです。
従来の ITSM システムのアップグレードによる負担
実際に経験したことがなければ、この説明が大げさに思われることもあるかもしれません。以下に、私のチームのアップグレード プロセスのスナップショットを紹介します。非常に多くのタスクがありますので、プレリリースからリリース、リリース後までの 3 つのフェーズにわたって、11 の大まかなステップにまとめてあります。
見ているだけで疲れるでしょう。それに、全体像を捉えることもできません。アップグレードを管理するチームは、組織の変更管理に関する懸念に対処するため、多大な時間と労力を費やしています。エンド ユーザーは、年に 2 回のサービス デプロイのための中断にはほとんど価値がないと見ており、不満を感じています。
以前は、アップグレードに関する問題はチーム独自のものだと感じていましたが、ユーザー グループ会議に出席し、ブログを読んでいるうちに、いたるところに面倒なアップグレード プロセスがあることに気づきました。顧客の一部からは、アップグレードに 8 週間以上もかかり、チームの生産性が低下したという不満も挙がっています。
組織によっては、簡単にアップグレードするためにレガシー ITSM システムを「再起動」するところまであります。たとえば、2022 年 3 月の ServiceNow の San Diego リリースに搭載された Next Experience UI の使い方をいまだに模索している顧客もいます。顧客企業の中には、ユーザーへの影響を見極められるまでは機能をオフにすると決定している企業もあります。
この問題の解決策を探していたところ、パートナーのサービスをアップグレードに活用する、システムの変更を控える、段階的な自動テスト機能を使用するなど、救急の対処法があることが判明しました。しかし、そのどれも十分に包括的ではなく、中には別の方向の仕事が増えそうなものもありました。
救いを求めて — ITSM システムへの、より優れたアプローチ
私には 2 つの選択肢しかないと思いました。ITSM システムに内在する課題を受け入れ、机の引き出しに胃薬と頭痛薬を常備しておくか、より堅牢で柔軟なソリューションを探すか、のどちらかです。イライラしながら Google で検索し、アナリスト レポートを読み、ITSM 分野に詳しい友人に相談した結果、アトラシアンの ITSM ソリューションである Jira Service Management にたどり着きました。
率直に言って、それでも私たちの課題を軽減できるかは懐疑的でした。私はかなり長い間、エンタープライズ ITSM システムを使用して仕事をしており、Jira Software も数年使用しています。ですから、Jira Service Management では私たちの課題に対処しきれないだろうと確信していました。
しばらくの間、Jira Service Management のアセット機能を調べましたが、データの設定と読み込みは簡単そうに思えました。その後、プロジェクトとサービス割り当てグループの作成を始めました。ほんの数時間の設定で (そしてドキュメントを一目見ただけで)、IT 資産と CI、および主要なインシデント機能を含む実用的なサービス カタログとサービス デスクを作成しました。
Jira Service Management は、「今いるところから始める」などのアジャイル手法の要素を取り入れ、すぐに使える ITIL プラクティスを提供しています。アトラシアンがツール中心のソリューションではなく、チーム中心のアプローチを採用していることは明らかでした。
Jira Service Management アップグレードに対するアトラシアンのアプローチ | システムのアップグレードに対するレガシー ITSM ベンダーのアプローチ |
|---|---|
| アジャイルとウォーターフォール型 | |
| アトラシアンは、柔軟性、コラボレーション、効率性を最適化する Jira Service Management のアップグレードにアジャイル手法を使用しています。 | システムのアップグレードに対するレガシー ITSM ベンダーのアプローチ レガシー ITSM ベンダーは、構造化された順次的なリリースに重点を置いたアップグレードにウォーターフォール アプローチを採用しています。 |
| 予定の変更と必要な年次アップデートの比較 | |
| Jira Service Management のお客様は、環境に適したリリース トラックを設定することで、変更率をコントロールできます。継続型製品では、変更や機能が利用可能になるとすぐに提供されます。バンドル製品は、毎月第 2 火曜日にまとめて変更を受け取ります。 | システムのアップグレードに対するレガシー ITSM ベンダーのアプローチ レガシー ITSM ベンダーは通常、年に 2 回、新機能を含むソフトウェア リリースを提供しています。 |
| 継続的な機能リリースと必要に応じたバグ修正の比較 | |
| アトラシアンのアプローチは、より短く予測可能なリリース サイクル、より小規模で高品質なコード セット、より透明で応答性の高い機能提供を通じて、お客様にビジネス価値の向上をもたらします。 | システムのアップグレードに対するレガシー ITSM ベンダーのアプローチ レガシー ITSM ベンダーは、必要に応じて/利用可能になったときにコード パッチとホットフィックスを提供しています。通常、これらのパッチとホットフィックスにバグ修正は含まれていますが、新機能は含まれていません。 |
| 疎結合アーキテクチャと密結合コード セットの比較 | |
| Jira Service Management は、個々のコンポーネントが互いに独立して構築される疎結合アーキテクチャに基づいています。疎結合アプリにより、チームは独立してデプロイおよび拡張する機能を開発できるため、より効率的なコード デリバリー/アップグレードが可能になります。 | システムのアップグレードに対するレガシー ITSM ベンダーのアプローチ レガシー ITSM のシステム アーキテクチャは密接に結合されているため、機能は柔軟性に欠け相互に依存しています。1 つのコンポーネントが変更されると、アプリ全体でより多くの変更が行われる「ドミノ」効果が生じ、全体的なコード変更が増え、リスクが高まります。 |
| 真のクラウド製品とサイロ化された SaaS サービスの比較 | |
| Jira Service Management はアトラシアンのクラウド・プラットフォーム向けに設計および作成されているため、組み込みセキュリティ、組み込みのコンプライアンス、製品あたり最大 150 個のマルチインスタンス、シンプルなユーザー単位のライセンスにより、カスタマーは自信を持って拡張できます。 | システムのアップグレードに対するレガシー ITSM ベンダーのアプローチ レガシー ITSM システムはオンプレミスで実行するように設計されていることが多く、ベンダーはアプリをリモートでホストするだけです。これらは真のクラウド ソリューションではなく、真のクラウド システムと同じメリット (スケーリング、アップグレード、価格、セキュリティ) を提供できません。 |
ITSM システムのアップグレードへのより健全なアプローチ
アップグレードの課題については、新しい機能が利用可能になったときにその機能性をプラットフォームと製品にシームレスに導入できるように、アトラシアンはテクノロジーの進化を計画しています。アトラシアンのクラウド ロードマップは公開されているため、お客様は常に今後の予定を確認できます。Jira Service Management のクラウドベースのシステムでは、お客様は機能を継続的に、または定期的に利用できるということです。お客様は次のことを行えます。
- 今後の変更に関する最新情報について、週次のリリース ノートを購読する
- 本番環境に展開する前に機能の変更を試すために、隔離された環境 (別名サンドボックス) を作成する
- (継続的およびバンドルされた) 本番環境のリリース トラックを設定して、変更率をコントロールする
- 継続的な改善をもたらす小規模で段階的なアップデートから得られるメリット
Jira Service Management は疎結合コード セットに基づいているため、コードの柔軟性/再利用性が向上し、アプリのアップグレードがより効率的になります。
私たちは皆、組織が「一生懸命働くのではなく賢く働く」ことができるように、デジタル トランスフォーメーションを加速させたいと思っています。Jira Service Management のアジャイルで段階的な変更と改善のアップグレード アプローチにより、より継続的に、より速く、中断することなく、リリースの検証とエンド ユーザーとの関わりを継続できることがわかりました。
デジタル変革のジャーニーに出発するなら、各アプリのコア アーキテクチャと実装アプローチ、および総所有コストを確認することをおすすめします。達成しようとしているビジネス イニシアチブを検討して、ニーズを満たし、かつ顧客とのあらゆるやり取りに付加価値をもたらすシステムを選択しましょう。
サービス管理に対するアトラシアンのアプローチの詳細は、アトラシアンの ITSM 完全ガイドをご覧ください。
Atlassian's guide to agile ways of working with ITIL 4
ITIL 4 is here—and it’s more agile than ever. Learn tips to bring agility and collaboration into ITSM with Atlassian.
ホワイトペーパーを読むサービス リクエスト管理とは - ガイド
サービス リクエスト管理により、IT チームは顧客のリクエストを迅速かつ容易に満たすことができます。プロセスとベスト プラクティスを確認しましょう。
記事を読む