保守・運用プロセス

YouTube動画

保守・運用プロセスとは

今回は、SLCPでの最終プロセス、保守・運用プロセスです。

システム開発プロセスが終わったら「作って終わり！」とならないのが、ビジネスとシステムが密接に関わる理由です。
システムは、リリース後に人に使われてから、ようやくその役割を発揮します💡

保守・運用プロセスで押さえるべきポイントは、

・リリース後に発生する、追加のシステム開発
・システムを利用するユーザーのサポート

この２つの観点で整理すると、理解が深まります◎

追加のシステム開発

まずは、システム開発リリース後の追加のシステム開発についてです。

バスタブ曲線

システム開発プロセスで、どれだけ徹底してテストをおこなっても、システムにバグ・故障はつきものです。

それを示すように、システム開発後のバグ発生件数はバスタブ曲線によって示されています。

システムリリース直後の初期故障期は、設計の不備などでバグが多く出る傾向にあり、
その後、バグの発生が落ち着く偶発故障期には、定期的な予防保守＝システムメンテナンスをおこなうことで発生件数は落ち着きを見せ、
磨耗故障期を迎えると、機械やシステムの長期間稼働により経年劣化が進んできます。

インシデント管理

システムのバグや故障は、１日や２日ですぐに直すことはできません。

一方で10年後にシステム復旧しても意味がいことから
開発スケジュールをマネジメントし、システムで起こった事象は優先度をつけて管理して、効率よく問題を潰していく必要があります。

こうしたバグやトラブル等、サービスに影響するできごとの事をインシデント（英語：incident）といい、
保守・運用の担当者がインシデントの解決に動くことをインシデント管理といいます。

保守・運用プロセスの２つの観点のうち、追加リリースで示すことは、これらリリース後のバグを修理することも重要な仕事の１つです。

また、機能の追加・仕様変更も、保守・運用プロセスにおいては正しい対応となるため、試験に向けて知っておきましょう！

ユーザーへのサポート

保守運用プロセスのもう１つの観点、顧客サポートを見ていきましょう！

システム開発・リリース後、作ったものを世の中に広げていくのがストラテジ系の経営分野でしたが、システムを顧客が利用し始めると

…などなど、様々なお問い合わせが発生します。

保守・運用プロセスでは、これらお問い合わせに対応することも重要な仕事となります。

SLA

企業の務めとして、顧客にシステムを利用し続けてもらうために、システム提供する企業と利用者の間で、一定条件で品質を保つことを、SLA（Service Level Agreement）といいます。

サポート手法

この顧客のシステム利用をサポートする手法として、４つの手法も試験に必ず！出ているので、知っておきましょう！

・サービスデスク

システムや、サービスを利用する中で、困ったことがあるときに利用したことがある方も多いと思います！

メリットは、電話やメールを利用して担当者に個別で困りごとを解決してもらえるので、ユーザーの迷いは的確に対応されることが多いです。

一方で、電話やメールを受けるサービスデスクの担当者にはキャパシティがあります。即座に問題解決されないことがデメリットになります。
（サポートデスクに電話を掛けたのに、担当者に繋がらない… といった経験、皆さんもありませんか🥲?）

・チャットボット

会話形式で問題を解決してくれます。
チャットボットの中には、AIを利用して問い合わせに回答するものもありますが、すべての問い合わせに完璧に回答できるものは世の中にはありません。

メリットは、サービスデスクのようなキャパがないため、単純な質問であれば早期解決に繋がることです。

デメリットとしては、
・導入コストがかかるため、すべての企業が導入できない
・複雑性の高い問い合わせには対応できず、結果的に有人のサービスデスクに誘導される
といったことが挙げられます。

・FAQ

システムの公式WEBサイト等で公開されている使い方の説明ページのことで、 FAQエフエーキュー（Frequently Asked Questions：よくある質問と回答）といいます。

FAQも、自分で問題解決できるものとしてメリットがありますが、サイトに掲載されていない複雑性の高いインシデントには、結果的に有人のサービスデスクで対応することになります。

・ナレッジコミュニティ

わかりやすい例として、Yahoo!知恵袋をイメージしてみてください！
ナレッジコミュニティサイトに、質問が下記込まれると詳しい人が教えてくれる解決ツールです。

企業はコストを掛けて、有人サポートデスクのオペレーターを雇用する必要がありません。
同じような疑問を持った顧客は、過去の質問を検索して、解決することができます。

Photoshop や Illustrator など、世の中にユーザーが溢れているサービスではナレッジコミュニティの制度を導入することが多いです。

チャットボット、FAQと同様、自力で解決できない場合は、結果的にサービスデスクに質問することになります。

エスカレーション

インシデント管理の対応のなかで、サービスデスクだけでは対応できず、エンジニア組織に協力を依頼することで解決するケースもあります。

例えば、
・〇〇の機能が使えなかったが、そもそもバグが有った
・（主にBtoBサービス等で）この機能がないと、導入できない　などです。

このような時に、サービスデスクの担当者が上位者に追加開発の判断を依頼し、
開発チームの協力を依頼することをエスカレーションといいます。

（下から上に、問題を受渡して、さらに高度な解決チームに流すという意味合いです。）

エスカレーション後は、インシデント管理の対象として保守運用の追加の開発対象となるため、今回扱ってきた２つの観点は、同じ保守・運用プロセスとして扱われます。

ITIL

最後に、すきまマーケット社の「おでかけグルメアプリ」ような“ITサービスの管理者“に向けて IT サービスの品質を効率的に管理するベストプラクティスを体系的にまとめたノウハウ集を

ITILアイティル（Information Technology Infrastructure Library）といいます。

試験では選択肢にもよく出る単語なので、意味とセットで、覚えましょう◎

今日も最後までブログを見てくださり、ありがとうございました！

次のITすきま教室でお会いしましょう👋

関連記事