ITSM - IT Service Management / article

問題管理から問題を取り除くための 4 つのヒント

本当にスキャンダラスなことから始めましょう。実際、ITSM、特に問題管理について今までに書かれたもので、おそらく最も物議をかもすものでしょう。これが引き起こす Twitter (ハッシュタグ #ITSMwtf を使用してください) での大騒ぎを想像すると、私は興奮でめまいがします。

子供を隠してください。ブラインドを閉じてください。確かに警告しましたからね。では、心の準備はいいですか。

問題管理は、問題を検出して修正するものではありません。

言っちゃいました。そしてこれを支持します。日常業務では、根本原因の分析にとにかく集中してしまい、もっと大きな全体像を見失いがちです。IT チームがアラームやサイレンが一斉に鳴り出すのを防止するために懸命に仕事をしているときに出くわす、最も一般的な障害のいくつかを見てみましょう。ここでは、問題のトラブルシューティングだけでなく、問題自体を完全に防止するための、いくつかのすばらしいヒントを得ることができます。

問題 1:後手の根本原因追及のワナに陥る

IT の最前線で受け取るチケットに一日中忙殺されていると、「検出して修正する」という自動操縦モードに陥るのはよくあることです。実際に、多くの標準的なサービスデスク指標では、エージェントが可能な限り多くの課題を解決することを奨励しており、これはもっともなことです。

それでは、根本原因の分析に関して何の問題があるのでしょうか? これが問題管理プロセスの真の責任 (およびビジネスに価値を還元する機会) のほんの一部でしかない点を除いては、何もありません。単に問題に反応しているのに反して、問題管理の真の目的は現在もこれからも、IT サービスを継続し問題が発生しないように、常にインシデントの再発を防止することです。

そのためには、組織内の問題管理の定義を拡大することをお勧めします。根本原因の分析は全体像の一部ですが、ここには問題管理の実践で責任を持つ必要がある全範囲を示しています。

公平に見て、上記は ITIL など多くのベストプラクティスのフレームワークと完全に一致しています。しかし、実際には、多量のチケットや限られたリソースのために、ナレッジベースの更新や、将来の停止が起きる可能性や深刻さをかなりの割合で軽減できる予測的な監視など、重要な機能を簡単に見落としがちになります。ワナに陥らないようにしてください! ワナに陥る余裕はありません。

問題 2:自分の問題を共有することを怠る

私は自己啓発本を読むように言ってるわけではありません (この記事のどの部分も、必要な臨床治療の代わりにはなりません)。代わりに、私は問題管理の実践でもう一つのよくある誤解について注意を喚起します。それは問題管理が単一の役割、またはサービスデスクチームのごく一部の責任だという考えです。

残念なことです。確かに問題管理マネージャーは役割です。ITIL の責任マトリックスでは、問題管理マネージャーは確かにプロセスに責任があり、すべてのステップでの業務の遂行にも責任があるように見えます。しかし問題の診断と解決フェーズを通してアプリケーションアナリストや技術アナリストが参入し、重い負荷を持ち上げてくれることに気付くでしょう。

当社のスタンスですか? チーム全員でやりますよ。IT チーム全員で単一の根本原因があるという考えを拒絶しています。通常、いくつかの別々の障害が問題を引き起こします。そのため当社では専門チーム (ネットワーク、インフラストラクチャ、仮想ホスティングなど) が複数の角度から課題に対応するように奨励しています。彼らはアジャイル問題対応チームとして協力して作業し、解決に向けたさまざまな理論や潜在的な方法を探索して発見します。

表面的には、ちょっとぜいたくでリソース集約的に見えます。しかし、何度となく、多くの個別の障害が累積したことが判明した複雑なインシデントを解決してきました。このような協力的なワークストリームがなければ、真の根本原因の背後にある複雑さを見つけるのに (何時間ではなく) 何日もかかっていたでしょう。

当社の推奨事項としては、第 1 に、診断と解決のフェーズで、アジャイルな対応チームを展開するために必要なリソースがない場合、手に入れられるまで主張する必要があります。信じてください。これらのリソースが欠落していることの影響 (サービスの中断や生産性の低下) は、リソースを調達するコストよりもはるかに高くなります。

第 2 に、人を囲い込まないでください。サービスデスクのエージェントが互いに支援、指導、および励まし合うオープンでインタラクティブな環境を促進してください。専門性の高いエキスパートを信頼しながら、最もジュニアなアナリストからも貢献や見解を求めてください。やるべき業務は問題を防ぐことです。問題をすべて防げない場合は、その影響を最小限に抑えます。チームが協力して働くことで、そうした環境をより迅速に実現できます。

また、業務に適切なツールを備える重要性を過小評価しないでください。アトラシアン製または他社製でも、チャット、知識の共有、プロセスの追跡、パフォーマンスの監査のために強力なコラボレーションツールが必要です。

問題 3:尋ねる質問が少なすぎる

私は先日車を診てもらった修理工に苦情があります。次のような次第です。私が症状を説明しているとき、修理工は聞いている風で頭をうなずいていました。その後、私の車を機械に接続すると何も問題は見つかりませんでした。私は「点検」に対して料金を支払いました。その 2 日後に、路上で立ち往生する羽目になりました。

ある時点で修理工はどのように考え、どう質問するか、最も重要な「なぜ」を尋ねることを忘れていたようです。

皮肉にも、問題の根本原因を決定する最高の手法の 1 つを開発したのは自動車業界でした。それは「5 つの Why」と呼ばれる手法で、豊田佐吉によって最初に提唱され、トヨタ自動車で幅広く使用されてきました。

「なぜ」を問うことは製造分野と同様に IT 分野でもうまく機能するシンプルで優れた手法です。例を使って「5 つの Why」を説明してみましょう。ウィキペディアから引用してきました。

まず、問題の状態:車が起動しないことを説明します。

なぜ? - バッテリーが切れています。(1 番目のなぜ)

なぜ? - オルタネーターが機能していません。(2 番目のなぜ)

なぜ? - オルタネーターベルトが壊れています。(3 番目のなぜ)

なぜ? - オルタネーターベルトが有効な耐用年数を優に過ぎており、交換されていません。(4 番目のなぜ)

なぜ? - 車両は推奨されるサービススケジュールに従ってメンテナンスされませんでした。(5 番目のなぜ、根本原因)

ケヴィン・ベーコンとの六次の隔たり」とは異なり、ステップの定数よりも多くのステップを踏んで回答を得て構いません。根本原因を特定するのに、7 つの「why」が必要ならば、7 を使用してください。5 は、マーケティング目的で聞こえのいい音で一般的に十分な数であるというだけです。重要な点は、トラブルシューティングをする人が自分の推測を脇に置いて、根本的問題に到着するまで考えられる原因を慎重に追跡することを奨励する、論理的で段階的なアプローチを取ることです。

実際、アジャイル問題対応チーム内の初期の演習として「5 つの Why」を使用して、問題にアプローチするのに使用できる角度を特定するのに役立てることを推奨します。多くの場合、それぞれの「why」への答えで、テストまたは探索する価値のある複数の仮説を明らかできます。

問題 4:知識を拡散しない

そして最後に、問題 4 です。これは「取引を成立させない」と呼ぶこともできます。それは「解決して逃げる」という問題管理チームの傾向を端的に示すものだからです。

自分自身の人生で、何か新しいことを学習したり、困難な問題を解決したら、結果を記憶の中にたたき込んで、再びそれを活用できるようにします。一般的に、これはあなたが予測の付かないティーンエイジャーでない限り、非常にうまく機能します。

しかし、チーム環境では、あなた自身の記憶の中は、学んだ知識を保持するのにあまり有益な場所とは言えません。少なくとも、唯一の場所であってはなりません。今こそナレッジベースの出番です。ナレッジベースは、問題解決プロセスを支援できる記事を格納および検索する一元的な場所です。

ナレッジセンターを活用したサポートを高く評価するトピックのみでブログ投稿も書くことができますが、幸運なことに Sarah Zorah がすでにブログを書いています。Sarah は、なぜナレッジマネジメントをサービスデスクの中核に据える必要があるか、ナレッジマネジメントを開始する方法を説明しています。

Sarah のブログで私が気に入った点は、ナレッジに基づくサポートは、問題解決の付随的なものではないということです。実際に課題を解決する方法なのです。したがって、ナレッジベースの記事を書いたり更新したりすることは、次の問題に取りかかるのを妨げる、面倒くさい余分なステップではありません。それは将来の問題を防止する (または影響を最小限に抑える) ための最も重要なステップです。

ナレッジベースの管理と更新が、御社のサービスデスクプロセスの中心的な業務にまだなっていない場合、またはそれを実行するための適切なソフトウェアが不足している場合は、何よりも優先して、この欠落を今すぐに埋めてください。何かを始めるのに遅すぎることはありません。しかし 1 日でも長く待つほど、貴重な知識 (およびビジネスへの活用度向上) を失うことになります。

実践

本日の私の結論は、残念ながら導入部ほどスキャンダラスではありません。問題管理は、ITSM のすべての分野と同様に実践を積むことです。つまり、本質的に最初から完璧にすることはできないものなのです。単に部分の集約として見たり、問題のトラブルシューティングをするだけではなく、問題の防止に目を向けることで、はるかに強力でより持続可能なサービスデスクが構築されます。これにより、顧客満足度とビジネスの収益性も向上できます。そして、私はそれに何の問題も見つけることはできません。

著者について

Nick Wright

サービスオペレーションマネージャー、アトラシアン

チーム、そして私は、アトラシアンのクラウドアプリケーションとインフラストラクチャが確実に最高の状態で機能するように努めています。急成長を続けながら、これを実現する方法をぜひ共有したいと思っています。ニュージーランド出身であるという言語的なハンデはありますが、フィッシュアンドチップスをきちんと発音できますよ。プライベートでは、サイクリング、ゲーム、妻と可愛い幼い娘と時間を過ごしています。 

さらに詳しく
Jira Service Desk logo

より多くの問題をさらに素早く解決

無料トライアル