業務改善で失敗しないためのフレームワーク思考

ãä»äºãã®ç»åæ¤ç´¢çµæ

こんにちは、Taikiです。

業務を改善するときに思いつくのが、ITサービスの活用です。そして、そのITサービスマネジメントのベストプラクティスが、ITILとよばれる世界共通のフレームワークです。

ITILはITサービスマネジメントを実現するため、ITサービスの品質向上、中長期的なコストの削減などを目的として実在する企業、サプライヤ、コンサルタントなどからITサービスに関する実際の運営方式やノウハウを収集し、書籍化したもの。

出典：Wikipedia

このITILを実践し効果を発揮すれば、例えば、こんないい事があります。

課題が体系化されているため、漏れを防げる
実行プロセスの段階が分かるため、手戻りを防げる
責任や役割を明確にできるため、後々のトラブルを防げる
サービスの結果を測定し継続的に改善できるため、ニーズの変化に対応しやすい

しかし、この優れたベストプラクティスにも難点があります。それは分かりにくさです。

実例で説明されていないため、言いたい事が分からない
似たような表現が多いため分かりにくい（変更管理、変更提案、変更要求など）
オリジナルは英国のため、翻訳に限界がある

この分かりにくさを我慢して勉強すると、ロジックではなく記憶に頼った学習になるため、現場で応用が利きません。本来フレームワークとは、異なる場面でもそのノウハウを再利用できるものです。良い部品を再利用すれば短い時間で品質の良いモノが仕上がります。同じように、このITILのノウハウを効果的に応用できるよう、実用性重視で解説することが本記事の狙いです。

しかし、労力の関係上、ここでは上流プロセスであるサービスストラテジーとサービスデザインのみを取り上げ、その上位概念の意図を汲み取ることに留めます。残りの3プロセスと具体的なハウツーについては、ITILの参考書をお読みください。

サービスストラテジー
サービスデザイン
まとめ

業務改善するときには幾つかステップがあります。ITILはこちらの5つを基本プロセスとしています。

f:id:vtaiki:20190821012243p:plain

各プロセスの狙いは何でしょうか。

サービスストラテジー

業務を改善するときに、最も大事な点は何でしょうか。

それは投資以上の成果を出すことです。そのために戦略を策定します。それがサービスストラテジーの狙いです。そのサービスストラテジーを成功させる要因は、大きく4つあります。

事業関係管理
需要管理
サービスポートフォリオ管理
財務管理

上の言葉を聞いて、戦略にどう結び付くか、連想できますか。。これがITILの分かりにくさです。しかし、これに質問を付与すると少しわかりやすくなります。

事業関係管理　⇒　顧客のニーズは何か？
需要管理　⇒　どのくらいの需要があるか？
サービスポートフォリオ管理　 ⇒ 　どのくらいのリソースが必要か？
財務管理　⇒　予算はいくら必要か？

顧客のニーズは何か？（事業関係管理）

絶えず変わり続ける顧客のニーズを的確に捉え、サービスを提供することは困難です。

この変わり続ける顧客ニーズの変化に応えるコツが、顧客と良好な関係を構築することです。そのためにどうするか、それは顧客の数だけ答えがあります。リスポンスの速さを見るところもあれば、対応の丁寧さを見るところもあるでしょう。

例えば、営業担当者を変えてみると顧客から違うリクエストが出てくる事もあります。聞き手の視点が変わると話し手のアウトプットも変化し、思ってもいなかったニーズが見えてくることがあります。人対人は定性的な要素が多分にあるため、顧客との関係作りは人の相性も大きく関係します。

どのくらいの需要があるか？（需要管理）

顧客のニーズを掴んだ後は、そのサービスの需要がどれ程あるかを測定します。それが需要管理です。需要を測定する狙いは、投入するリソース（ヒト・モノ・カネ）の量を見極めるためです。その需要を測定するコツは、顧客の事業パターンを把握することにあります。例えば、夏場にビールやアイスが売れ、冬にケーキが売れるようなものです。

どのくらいのリソースが必要か？（サービスポートフォリオ管理）

需要を測定できたら、必要なリソースの投入量を決めます。但し、特定のサービスに人員や設備を過度に使うと、別のサービスレベルが低下します。そうならないために、サービスの棚卸を行う段階がサービスポートフォリオ管理です。リソースは有限です。優先度やサービスの特性に応じて投入するリソースの量を決めます。

棚卸を行う1つ目の狙いはリソース投入の優先順位を決めることですが、2つ目の狙いは、新しいサービスを既存の資源で賄えるかを見極める事です。これができるとコスパが飛躍的に向上します。

3つ目の狙いは、業務プロセスの棚卸を行うことです。データを移行するときは、データを整理します。例えば、クラウドにデータを移行する前も、整理してスリム化できればそれだけ運用コストを削減できます。業務を自動化したいときもプロセスを簡素化することで、より短いソースコードで実装することができます。

予算はいくら必要か？（予算管理）

投入するリソースの量がきまると、その予算を見積もることができます。戦略策定の目的は、投資以上の成果を出すことです。それを考慮し予算の編成を行います。

サービスデザイン

戦略を策定した後は、その戦略通りに業務を改善できるよう業務設計します。そのためには限られた予算で業務を改善するためにサービスとコストのバランスを決めます。そのバランスを調整するプロセスがサービスデザインです。そのサービスデザインの成功要因は大きく8つあります。

サービスレベル管理　⇒　サービスの手厚さと責任分界点は？
可用性管理　⇒　サービスの利用時間帯は？
キャパシティ管理　⇒　どの程度のキャパが必要か？
サービス継続性管理　⇒　有事の際の復旧リミットは？
情報セキュリティ管理　⇒　機密情報や秘匿情報の取り扱いルールは？
サプイライヤ管理　⇒　どこにどの業務を任せるか？
サービスカタログ管理　⇒　サービスの存在を知ってもらえているか？
デザインコーディネーション　⇒　誰が全体の責任をもつか？

サービスの品質と責任分界点は？（サービスレベル管理）

サービスレベル管理は、顧客とサービスの手厚さを決める段階です。取り扱うサービスの種類、サービスを受ける対象者、対応時間などを決めます。ここまでをサービス提供者が行い、ここからは顧客が行うなどと責任分界点を決めますが、こういった取り決めをSLAと言います。

サービス水準合意 (Service Level Agreement, SLA) とは、サービスの提供者とその利用者の間で結ばれるサービス水準に関する合意である。サービスレベル契約と言われることもある。通信サービスやコンピュータ・アプリケーション・サービスなどで、サービスの定義、内容、範囲、品質、達成目標、稼働率などを記述する。具体的な数値として平均故障間隔(MTBF)、平均修復時間(MTTR)などを利用する。

出典：Wikipedia

SLAを設定する理由は２つあります。予算を越えない事と後で揉めないためです。

SLAを決めずにサービスを提供すると、顧客から「これもやってくれない？」とリクエストを追加されます。SLAがないからと何でも安請負してしまうと、金額は変わらないのに作業時間ばかりが増え、予算を圧迫します。

逆にSLAを決めていないからと、リクエストを突っぱねると顧客の不満は増幅し、次の契約更改で仕事がなくなる可能性もあります。

こういった事態を避けるために業務を設計するときはSLAを決めます。

サービスの利用時間帯は？（可用性管理）

先で決めたSLAを達成するために、まずサービスの提供時間を決めます。

可用性管理の説明はこちらです。

可用性（Availability）とは、システムを障害（機器やパーツの故障・災害・アクシデントなど）で停止させることなく稼働し続けること、またはその指標のことをいいます。
長い時間、システムを稼働し続けられることを高可用性（High Availability）ともいいます。

サービスの提供時間を決める理由は、高いコスパでサービスレベルを達成するためです。24時間365日、システムを無停止で維持することは不可能です。そうでなくても、高可用性を維持するにはコストがかかります。

ビジネスの活動時間を把握し、サービスの提供時間を必要最小限に絞ることができれば、それだけ可用性を維持しやすくなります。逆に壊れた時のビジネスインパクトが大きいポイントにホットスタンバイを設けるなどのコストを惜しんではいけません。

どの程度のキャパが必要か？（キャパシティ管理）

ここでは可用性を維持するためのキャパシティを決めます。キャパシティとは、作業員やデバイスの数、ネットワークの帯域やストレージ容量を指します。

キャパシティ管理の狙いは、安定性とコストのバランスを保つ事です。安定稼働を考えるあまり、過剰投資でオーパースペックでになったり、コストを意識し過ぎてスペック不足になることを避けます。

キャパシティ管理の精度を上げるためには、需要管理もさることながら、拡張性や柔軟性を持たせることです。例えば、オンプレにサーバーを購入する場合、スペックの変更に限界があるため、、需要変化に十分に対応できません。しかし、レンタルサーバーにしたりクラウドにすると需要に応じてサーバーの増強や縮小も柔軟にできます。

有事の際の復旧リミットは？（サービス継続性管理）

通常の運用だけでなく不測の事態も考慮にいれた設計が必要です。すなわち災害など有事の際にいつまでにどのサービスをどの水準まで復旧させるかを決めることです。それがサービス継続性管理です。

なぜ滅多に起こらないことのために復旧時間や復旧レベルを緻密に決めないといけないのでしょうか。それはデータの消失や復旧時間の遅延がビジネスにとって致命傷になるからです。例えば、顧客があるベンダーにデータを預けた時に最も心配する事は、預けたデータの漏えいや紛失です。もしこれが発生すると社会的な信用が失墜し市場から退場することもありえます。それを担保する行為がSLAです。そして、そのSLAで合意した条件を満たすために、サービス継続性管理で復旧時間や復旧レベルを決めます。

よく考えると、サービス継続性管理は保険と似た性格をもっています。保険はリスクの頻度やインパクトに応じて保険料が高くなります。同じように重要なデータやシステムには相応の投資が必要です。しかし、全てにお金をかける必要はありません。例えば、プリンタが故障して業務が完全にストップすることは考えにくいでしょう。継続性管理の目的は、あくまで高い費用対効果でビジネスインパクトを最小限に留めることです。

機密情報や秘匿情報の取り扱いルールは？（情報セキュリティ管理）

機密性や秘匿性の高い情報には、誰にアクセス権を付与するか、誰がアクセス権を付与するか、など情報セキュリティ方針を確立する必要があります。この情報セキュリティ方針は、社会のデファクトスタンダードとなっておいます。今や情報サービスを取り扱う企業はISMSやプライベートマークなどを取得していないと後ろめたさを感じる時代です。

では情報セキュリティ管理の狙いは何でしょうか。情報の3原則とはCIA（完全性と機密性、可用性）です。すなわちセキュリティとコスト、使い勝手のバランスを取ることです。セキュリティをガチガチにし過ぎると生産性の足かせとなり、緩すぎると深刻な事故を招きます。そのバランス感覚が重要になります。

情報セキュリティは、JIS Q 27002（すなわちISO/IEC 27002）によって、情報の機密性、完全性、可用性を維持することと定義されている[1]。それら三つの性質の意味は次のとおりである[2]。

・機密性 (confidentiality): 情報へのアクセスを認められた者だけが、その情報にアクセスできる状態を確保すること
・完全性 (integrity): 情報が破壊、改ざん又は消去されていない状態を確保すること
・可用性 (availability): 情報へのアクセスを認められた者が、必要時に中断することなく、情報及び関連資産にアクセスできる状態を確保すること

出典：Wikipedia

どこにどの業務を任せるか（サプライヤ管理）

SLAや可用性、キャパシティに継続性、これまで取り上げた成功要因を実現するための選択肢が幾つかあります。外部にアウトソースするか、内製化か、またはその両方を取るかです。これを決める段階がサプライヤ管理です。費用対効果を考え、事業のニーズに応えるために、どう提供するかを決めます。思いつく両者の良し悪しを表にしてみましたので、ご参考ください。

f:id:vtaiki:20190827205713p:plain

サービスの存在を知ってもらえているか？（サービスカタログ管理）

どれだけサービスを充実させても、その存在が利用者に周知されていなければ意味がありません。提供中のサービスや今後導入するサービスを利用者に公開する段階がサービスカタログ管理です。

サービスカタログ管理の狙いは、そのサービスの存在を知ってもらう事に加え、SLAに基づいてサービスレベルを宣言する事です。例えば、サービスの対象者や提供時間、その担当が外注先の場合は問い合わせ先も明記しておくと、ユーザー全体に対して役割と責任の線引きができます。その結果、本来の業務範囲に労力や時間を集中しやすくなります。

誰が全体の責任をもつか？（デザインコーディネーション）

これまでの成功要因を実現するためには、部署間やサービス間で調整を行い、その成果に責任をもつプロセスが必要です。これがデザインコーディネーションです。

1つのサービスを変更することで複数のサービスに影響を与えたり、業務を1つ変えることで他部門の業務に支障を及ぼす事もあります。従って、デザインコーディネーションの責任者は、全体を俯瞰してプロセスやリソースを調整し、効果的に業務設計できる能力が求められます。そのため、その責任者として、調整能力の高い管理職を任命するケースが多いでしょう。