シフト・レフト?いいえ、サービス・サポートの成功のために「シフト・ダウン」してください。

シフト・レフトの開発手法を、カスタマーサービスやサポート組織にどのように適用すればよいのか。

この10年間で、開発、開発ツール、方法論の状況は大きく変化しました。多くの企業が、エンタープライズ・アプリケーションの開発とサポートにおいて、「ウォーターフォール」からアジャイル開発フレームワークやDevOpsの原則へと移行しています。その目的は、リリースサイクルを短縮し、品質を向上させ、システムやアプリケーションのユーザーであるお客様に全体的に優れた体験を提供することです。

特に、テストサイクルを開発作業に近づけることでアプリケーションの品質を向上させる新たな方法として、「シフト・レフト」と呼ばれる哲学が登場しました。これにより、本番環境で発見される不具合の数が減り、導入した組織では数万ドルのコスト削減に成功しました。

このホワイトペーパーでは、「シフト・レフト」開発フレームワークへの移行を加速させるコンセプトを、サービスおよびサポート組織にどのように適用できるかを検討します。これを「シフトダウン」と呼んでいますが、これは、より多くの責任を組織の「下」に置くこと、あるいはフロントエンドに置くことを意味しています。つまり、ティア1の従業員にできるだけ権限を与え、必要に応じてセルフサービスの自動化も行うことを意味しています。そして、なぜそうしないと収益に悪影響を及ぼすのかを説明します。

シフト・レフト・テスト:入門編

まず、ソフトウェア・テストにおける「シフト・レフト」という考え方について説明します。シフト・レフトとは、ソフトウェア開発の早い段階でテストを開始することです。これは、開発プロセスの最後にテストを専門のQAチームに任せるという従来のアプローチとは対照的なものです。理由は簡単です。開発プロセスの早い段階でバグや不具合を発見できれば、開発者へのフィードバックも早くなり、より生産的な作業が可能になります。現在、開発組織の10社中4社以上が、シフト・レフトを正式に採用しています。

現在、多くの組織では、ソフトウェア開発で用いられる、要求定義、設計、コーディング、テストをほぼ連続的に行う「ウォーターフォール・モデル」に大きく依存しています。 (図1参照)。

図1:ソフトウェア開発のライフサイクル

ウォーターフォール・モデルの最大の課題は、メジャー、マイナーを問わず、開発が完了してからバグや欠陥が発見されることです。軽微な不具合であれば、開発者はすぐに修正することができ、納期を遅らせたりコストをかけたりすることはありませんが、重大なバグとなると話は別です。

このようなケースでは、お客様への製品リリースが遅れたり、問題解決のために多くの人が参加してコストが増大したりします。ソフトウェア開発のライフサイクルの最後にテスト・フェーズを設けることが理想的なのは、製品にバグがない場合だけですが、製品開発の最初にそうなることを期待するのは夢のようです。

アジャイル開発など、より柔軟なソフトウェア開発モデルが登場するにつれ、企業は、テストを孤立したQAチームに単発的に任せることが、実際には非常にリスクが高いことに気付き始めました。その段階で発見された欠陥は、リリース遅延やコスト超過の第一の理由となっていました。

開発の各段階でテストを行う「シフト・レフト」の誕生
(図2参照)。

図2:シフト・レフトのテスト・モデル

シフト・レフトとは、基本的には、テストを可能な限り早い段階(ライフサイクル軸上で左)にシフトし、継続的に実施することです。シフト・レフトの実践には、テストをソフトウェア開発プロセスに統合し、修正が容易でコストのかからない早期にバグを発見することが含まれます。

シフト・レフトの概念は1990年代後半に登場しましたが、正式に命名されたのはLarry Smithが Dr. Dobbs Journal 2001年の記事で、QAを下層部に配置した統合開発により、テスト・プログラムを拡大しつつ、人員や設備を削減できることを説明しました。シフト・レフトでは、テスト、フィードバック、修正が日常的に行われています。これにより敏捷性が促進され、プロジェクト・チームは生産性を高めるために努力を重ねることができます。
(図3参照)。

図3:シフト・レフトと従来のQAモデルの比較。

2007年にDevOpsが登場したとき、シフト・レフトはそれに不可欠な要素でした。DevOpsとは、ソフトウェア開発とITオペレーションを組み合わせて、プロセス、製品ライフサイクル、カスタマー・エクスペリエンスのエンド・ツー・エンドのオーナーシップを高めることです。ソフトウェア開発のライフサイクルを短縮し、高品質なコードを継続的に提供するというDevOpsの目標は、シフト・レフトの哲学を核としています。

シフト・レフトで得られる現実的なメリット

シフト・レフトの利点は、多くの研究によって明らかにされています。 ITコンサルタント James Martin によると、ソフトウェアの欠陥の56%は要求段階で、27%は設計段階で、そしてわずか7%が開発段階で発見されると述べています。インド工科大学のS.A.Kelkarは、 「Structured Systems Analysis and Design」の中で この数字を検証し、 さらにSTBCは「The Economics of Testing」の中でこの数字を確認しています。 (図4参照)。

図4:ソフトウェアの不具合が発生するとき
出典はこちら。 ライス・コンサルティング

IBM System Science Instituteの調査によると、開発の初期段階で問題が発見された場合、その修正には約$80のコストがかかります。しかし、同じ問題を生産中に発見した場合、修正には100倍の$8,000のコストがかかります。 (図5参照)。

図5:ソフトウェア開発ライフサイクルの各フェーズにおける不具合検出のコスト
出典はこちら。 IBMシステム科学研究所

シフト・レフトを顧客サービス支援組織に適用する

シフト・レフトの概念を理解した後は、その原則をITカスタマー・サービスやサポート組織に適用し、その恩恵を受けることができます。

今日、ITサポートチームのサービスは 優先順位付け 改訂 ITIL®(IT Infrastructure Library)やCOBIT(Control Objectives for Information and Related Technology)などの新旧のITマネジメント・フレームワークをベースにした新しいプロセスで、従来の顧客サポートの枠組みを変えています。ITカスタマー・サポートを優先させる最大の理由は?それは、クラウド化が進むプラットフォームやソフトウェア・アプリケーションの可用性やパフォーマンスが、ベンダーの完全な管理下にあることに、お客様の関心が集まっているからです。

サポート組織が直面している課題は、増加するインシデントのために継続的な消火活動が必要になることです。サポート・リクエストの数を減らすためには、傾向分析、予防措置、重大な問題の事後検証などのプロアクティブな方法が有効です。しかし、残念ながら、IT部門は、明らかなメリットがあるにもかかわらず、リソースのほとんどをリアクティブな活動に集中させ、プロアクティブなアプローチを無視することがよくあります。その結果、インシデントが繰り返され、お客様の不満や不必要なダウンタイムを招くことになります。

サービス・サポートとソフトウェア開発には多くの類似点がある

シフト・レフトが採用されたのは、コーディングの問題は発見が遅れるほど修正コストが高くなるからですが、サービス・オペレーションも同じような状況にあります。例えば、Tier1の技術者が最初に作業した後、Tier2に引き上げられ、しばらくしてTier3のSME(Subject Matter Expert)による電話会議を経て解決に至ったケースを想定してみましょう。その結果、n+1リソースを追加するごとに、5桁、6桁のコストが簡単に加算されていきます。

重大なインシデントが発生するのを待つのではなく、プロセスの前段階で問題を診断して解決するというこの考え方は、ソフトウェア開発におけるシフト・レフト革命をもたらした調査結果を真似たものです。実際、コストに関するPonemonの調査をサービス・オペレーションに適用すれば、プロセスの早い段階で解決することで、その100倍ものコストを削減することができます。

これを "シフト・ダウン "と呼んでいます。

なぜダウンなのか?それは、事実上、組織構造の下の方に責任を移しているからです。そうすることで、Tier 1とTier 2のサポート担当者は、より多くの知識、能力、責任を持ち、お客様のために行動する権限を与えられます。

現在のサービスのサポート方法

お客様(または社員、その他のユーザー)がサポートに電話すると、最低限のスキルと知識しか持っていないTier1エンジニアが対応します。「販売システムへのアクセスに問題がある」というような少し複雑な問題の場合、多くのTier1サポート組織は基本的な情報を把握し、優先度を評価してTier2にエスカレーションするだけです。Tier2のエンジニアは、2回目の電話で、より技術的な質問(多くの場合、製品中心)をし、(うまくいけば)問題を解決することができます。そうでなければ、真の製品専門家がいるTier 3へと再びエスカレーションされます。

小さな変化でも、このプロセスをより効率的にすることができます。たとえ製品の専門家でなくても、症状や影響、実際のパフォーマンスの偏りに関して重要な診断質問をするようにTier1の従業員を訓練することで、より多くの問題を最初のタッチポイントで解決することができます。また、少なくとも、より良い情報をTier2に提供することで、より迅速な解決、「カスタマー・サポートのピンポン」の減少、そして最終的にはエスカレーションの減少につながります。

パスワードやルーターのリセットなど、より高度な問題を実際に解決し、基本的なトリアージ機能を提供できるようにTier1担当者を訓練することは、大きな利益をもたらします。

シフト・ダウンの考え方

シフト・ダウンの目的は、技術的に経験の浅いリソースが、ライフサイクルの早い段階でより多くの問題を解決できるようにし、権限を与えることです。また、再発防止のための積極的なトラブル・マネジメントを行い、一般的にお客様の近くに交流ポイントを移動させることで、エスカレーションを減らし、初回修正率を向上させ、サービス・コストを削減し、全体的なカスタマー・エクスペリエンスを向上させます。

シフト・ダウンの例としては、自己啓発ポータルに診断用のコアな質問を組み込んだことが挙げられます。あるお客様では、このアプローチにより、Tier1はより多くの情報を得て、実際のトラブルシューティングを早期に開始することができるようになりました。

シフト・ダウンに着手する際には、ワークフロー、役割、責任を適切に調整するとともに、これらのエンジニアがどのようにサポートされ、報酬を得ているのか、評価基準を含めたパフォーマンス・システムを確認する必要があります。

ITサービスマネジメントの新時代

ITサービス・マネジメント(ITSM)機能は、まさに変革の真っ只中にあります。

Forbes InsightとBMCによる調査 は、ほとんどのITサービス組織が、単にITを中心としたサービスを提供するだけの組織から進化していることを明らかにしました。今やITサービス組織は、新しいデジタル時代にふさわしいカスタマー・エクスペリエンスを実現するために最前線で活躍するミッション・クリティカルなチームとみなされています。

本調査で得られたその他の重要な知見を紹介します。

- 56%は、ITの変化や変革のペースが "かなり "加速していると回答しました。
- わずか13%が、ITSMが従来の組織的な階層を維持すると考えていました。
- 36%は、優れたカスタマー・サポートを実現する障害として、適切なITスキルがないことを第一に挙げ、次いで予算の制約を挙げています。
- 37%は、IT予算全体の大半を継続的な保守・管理に費やしていると報告しています。

結論: 75%のITエグゼクティブは、ITサービス・サポートを含む継続的なITの維持・管理に費やす時間、費用、リソースの量が、企業の全体的な競争力に影響を与えていると考えています。

そのため、ITサポートの質とコスト効率の両方を向上させることは、クラウド、ビッグデータ、モビリティと並ぶ戦略的なITイニシアチブとなっています。実際、過半数の経営者(56%)が、企業のクラウド・コンピューティングやビッグデータへの取り組みにおいて、ITサービス・マネジメントが「非常に重要である」と回答しています。また、54%の企業が、モバイル・コンピューティングの取り組みをサポートする上で、ITサービス・マネジメントが「非常に重要である」と回答しています。

シフト・ダウンの7つのベスト・プラクティス

シフト・ダウンに挑戦したい方のために、私たちがITサービス企業での経験からまとめた7つのベスト・プラクティスをご紹介します。

1.データの収集

そのためには、まずベース・ラインを確立することが重要です。誰がフロント・ラインに連絡しているのか?どのような問題を報告しているのか?どのような質問をしているのか?コールタイプ(インシデント、問題、質問、リクエスト、フォローアップ)、最も頻繁にエスカレーションされるコール・タイプとアセット・カテゴリー、これらのコールに対応するためのコスト(人件費と時間を除く)、そして最後に、各コールに対応する技術者のスキル・レベルなど、着信コールに関するデータを収集する必要があります。

例えば、1ヵ月にかかってくる1,000件の電話のうち、500件はパスワードの再設定を求めており、250件はVPNアクセスの許可など、かなり複雑度の低いソリューションを求めており、最後の250件はデータベースがダウンした原因の究明など、複雑度の高いソリューションを求めていることがわかるかもしれません。これは、今後の戦略に影響を与えるでしょう。

2.価値の高いターゲットの選定

データの分析結果に基づいて、価値の高いターゲットを探し、シフト・ダウンしていきます。頻繁にエスカレーションされ、解決に時間がかかり、それに伴うコストが非常に高いシステムや設備は何か?エスカレーションされても、簡単に解決できるものは?顧客満足度やコストにほとんど影響を与えていないと思われるものは?

これらはすべてシフト・ダウンの候補です。

先ほどの例の、パスワード・リセット・コールについて考えてみましょう。とりわけ、サポート・コールの半分は自動化によって簡単に解決できるということになり、これは究極のシフト・ダウンの動きです。

さらに、もう少し掘り下げることもできるでしょう。例えば、高難易度の電話のほとんどがヨーロッパからかかってきていることがわかっている場合、ヨーロッパのお客様にTier2に直接つながるサポート番号を提供することができます。そうすれば、Tier1を呼ぶことで、自分やお客様の時間とお金を無駄にすることはありません。彼らは自分の得意分野に集中することができます。また、他の種類の電話について知れば知るほど、より正確に電話をつなげることができます。繰り返しになりますが、ここで重要なテーマは、お客様を理解し、通話パターンを理解することです。

3.現場への権限移譲

ケプナー・トリゴーは、社員や管理職が効果的な問題解決や意思決定を行うための基礎知識を身につけることができると考えています。私たちはこれをクリティカル・シンキング、すなわち「合理的プロセス」と呼んでいます。
ケプナー・トリゴーのクリティカル・シンキング・アプローチは、60年以上にわたり、企業経営に継続的な貢献をしてきました。

クリティカル・シンキングという言葉は、ケプナー・トリゴーにとって非常に特別な意味を持っています。クリティカル・シンキングとは、適切な結論を得るために情報を収集し、整理し、分析することを目的とした、一連の質問に基づいた論理的で反復的な思考パターンです。

ケプナー・トリゴーの信念として、優れたチームワークは、多くの人がすでに無意識に考えていることと同じように、意識的に活用できるように訓練することから生まれるということです。

そのためには、4つの基本的な質問に答える必要があります。

- どうしたのか?
- なぜこんなことになったのか?
- どのような行動をとるべきか?
- その先にあるものとは?

技術的なノウハウを組織の下層部に押し付けても、それなりの効果しか得られません。特に、技術的な知識の賞味期限がどんどん短くなっている今、それは単に拡張性のあるアプローチではありません。そのため、特に現場のエンジニアには、適切な質問の仕方、問題提起の基本、基本的なデータ収集、トラブルシューティング、クリティカル・シンキングなどを教育する必要があるのです。

経験豊富な技術者がするような質問の仕方を下のレベルの人に教えるだけでなく、そのような状況でどのように顧客を明確にし、確認し、対応するかを理解できるようにするのです。

4.スカレーション・トリガーの設定

シフト・ダウンする際にもエスカレーションは非常に重要です。収集・分析したデータに基づいて、顧客の問題をエスカレーションする必要がある場合の明確なトリガーを確立しておく必要があります。新しくトレーニングを受けたチームは、いつ手を放し、助けを求めるべきかを判断する方法を学ばなければなりません。

多くの場合、トリガーは時間パラメータに基づいています。Tier 1 の担当者が 1 時間かけても問題が解決しない場合、Tier 2 にエスカレーションする時期が来ている可能性があります。問題の解決を3回試みて、すべて失敗した場合は、エスカレーションする時期が来たと考えられます。エスカレーションは、お客様の態度に基づいて行うこともできます。お客様が怒っていて、おそらく強い言葉を使っている場合は、それがトリガーとなる可能性があります。

5.シフト・ダウン・プログラムのテスト

次のベスト・プラクティスは、カスタマー・サポートセンターでA/Bテストを行うことです。チームを2つのグループに分けます。一方のグループは、新しいシフト・ダウンのテクニックを使いますが、それはパスワードのリセットのような非常に特定の問題についてであり、もう一方は通常の業務を行います。どちらのグループが良い結果を出したでしょうか?

なぜこんなことをするのでしょうか?それは、経営の優れた実践方法だからです。あらゆる優れたビジネス・プログラム、あらゆる優れたイニシアチブ、その種類にかかわらず、シックスシグマ、あるいは同様の品質管理に従って、製薬会社が生産する医薬品を扱うようにプロジェクトを扱うべきです。新しいやり方を全社的に導入する前に、それをテストし、意図した通りの結果が得られることを証明する必要があります。

この場合、あなたが行っていることは、お客様に直接影響を与えることになります。本当の意味でお客様を第一に考えるためには、何かを変えることで本当にお客様のためになるかどうかを確認しなければなりません。

6.結果の数値化

そこで、どのような効果があったかを測定する必要があります。チームは、より多くの電話をより短時間で解決することができたのでしょうか?設備別、クライアント別、リクエスト・タイプ別のサービス・コストはどうだったでしょうか。この時点では、かかった費用に対して節約できた費用を定量化し、ROIを計算する必要があります。

この知識があれば、小さなサポート・チームで実験を行った下級管理職でさえ、上司に「カナダのチームでやったことを見てください」と言うことができます。これを北米で再現したらどうなるか、想像してみてください」。すると突然、会社全体がよりプロフェッショナルな方法でカスタマー・サービス・サポートを行うようになり、その下級管理職のキャリアを成功に導くことができるようになるのです。

今回の例では、1,000件のサポート・コールのうち500件がパスワード・リセットのためのものでしたが、このROI分析には、問題を解決するためにどれだけの投資ができるかを教えてくれるという特別な利点があります。パスワード・リセット・ツールに10万ドルを投資することで、1日に500件の電話がかかってくるのを防ぎ、200万ドルを節約できるのであれば、それは十分にお金を使ったことになります。

7.プログラムの規模

シフト・ダウンの最初の試みの結果に満足したら、データが示す他のシフト・ダウンの可能性や、プロセスを適用する場所を確認します。カスタマー・サービス・サポート業務の別の分野を改善するために、ベスト・プラクティス1または2からやり直してください。

サービス・サポートの指標として最適なもの お客様満足度

ITサポートは、デジタル時代とクラウドベースのアプリケーションにおいて、おそらく最も重要な企業の機能です。企業がテクノロジーへの依存度を高めるにつれ、必要なときに必要なだけ動作させることは、他のほとんどすべてのことに優先します。製造業、自動車、小売業、金融業など、あらゆる業種の企業にとって、ITサービス・マネジメントは極めて重要な役割を担っています。サービスの中断は、収益性、効率性、サービスの迅速性など、企業の生産性、そして最終的には企業の成功に直接影響します。過去 20 年間にソフトウェア開発分野で開発されたシフト・レフト技術は、IT サービス組織に適用すると大きな影響を与えることができます。

ケプナー・トリゴーは、Microsoftなどの世界で最も成功している大企業と提携し、サポートの迅速化、通話料の低減、カスタマー・エクスペリエンス・レベルの向上を実現してきました。

Shane Chagpar
プロジェクト・マネージメント・コンサルタント

Shane Chagparは、ケプナー・トリゴーや業界のベスト・プラクティス・ツールを用いて、クライアントのニーズに合ったソリューションをデザインしています。通常、複数のプロジェクトを監督し、チームのパフォーマンスと結果の両方に責任を負っています。また、ITサービス戦略、デジタル・トランスフォーメーション、インシデント・マネジメントなどの分野で、グローバルなリーダーシップを発揮しています。また、品質向上、ソフトウェア開発、製品管理の専門家でもあります。

カナダ在住のShane Chagpar (schagpar@kepner-tregoe.com)は、ケプナー・トリゴーのプロジェクトをグローバルに展開しています。

関連

システムによるサービス

Staying in Control - プレッシャー下での思考を改善するためのダッシュボードと指標のデザイン

私たちは以下の専門家です:

お問い合わせ

お問い合わせ、ご意見、詳細確認はこちらから