IT運用で「シフトレフト」を掲げると、専門チームが受けていた問い合わせや作業をサービスデスクへ移し、さらに利用者のセルフサービスへ移す施策が進みます。 適切に設計すれば、利用者に近い場所で早く解決でき、専門家は改善や高度な判断へ時間を使えます。 しかし、受付先だけを変え、判断基準、知識、権限、例外時の支援を移さなければ、差戻しや誤操作が増え、結果として解決までの時間が長くなります。

ITIL 4では、サービスデスクを利用者とサービス提供者の接点として扱い、Knowledge ManagementやContinual Improvementなど複数のプラクティスを横断して価値を生み出す考え方を取ります。 PeopleCertの公式資料も、プラクティスを単独の手順ではなく、関係者、責任、技術、知識、コミュニケーション、バリューストリームを含む能力として整理しています。 つまり、シフトレフトはチケットの行き先を変える施策ではなく、解決能力そのものを需要に近い場所へ移す取り組みです。

本記事では、繰り返し発生する一つの需要から始め、標準化、知識移転、段階的な移管、安全な自動化、継続的改善へつなぐ5ステップを整理します。 自社の体制、サービスの重要性、権限、契約、適用法令、リスク許容度に応じて調整することが前提です。

具体的な課題：左へ動かしたのに、解決が遅くなる

シフトレフトが失敗する典型は、一次窓口へ件数だけを移し、専門家が暗黙に行っていた確認や例外判断を残すことです。 一次窓口は手順書どおりに処理できない案件を抱え、専門チームは説明不足のエスカレーションを受け、利用者は同じ内容を何度も伝えることになります。

  • 対象を件数だけで選ぶ：頻度は高いが影響も大きい作業を、リスクを評価せず移管する。
  • 手順だけを渡す：開始条件、完了条件、判断根拠、禁止事項、例外時の経路が共有されない。
  • 権限が仕事と合わない：必要な情報へアクセスできない、または過大な権限を恒常的に付与する。
  • 自動化を近道にする：不安定な手作業をそのまま自動化し、誤りを高速に拡大する。
  • 成果を処理件数で測る：再問い合わせ、再発、利用者の待ち時間、専門家の負荷、品質を見ない。
シフトレフトの成果は「誰が処理したか」ではなく、利用者に近い場所で、安全に解決できる能力が増えたかで判断します。

考え方：標準化・知識移転・自動化を順番に積み上げる

仕事を左へ移す前に、まず反復可能な形へ整えます。入力、開始条件、判断、作業、確認、記録、完了条件を標準化し、そのうえで判断に必要な知識と例外時の支援経路を移します。 能力を確認できた範囲から自動化し、監視、停止、手動復旧を含めて運用します。

  1. 標準化：同じ条件なら、誰が実施しても同じ品質になる仕事の形を作る。
  2. 知識移転：操作方法だけでなく、判断理由、例外、リスク、相談先を共有する。
  3. 自動化：十分に理解した反復作業を、検証可能で停止できる仕組みに変える。

Google SREは、トイルを反復的で予測可能なサービス維持作業として捉え、まず把握・定量化し、リスクと投資対効果を見ながら反復的に削減する考え方を示しています。 自動化は有力な手段ですが万能ではなく、強い権限を持つ自動化ほど防御的な設計が重要です。 この考え方は、ITIL 4の継続的改善と組み合わせることで、単発の効率化ではなく、サービス品質を守りながら能力を移す運用になります。

実践手順1：移す需要を一つ選び、現在地を測る

まず、問い合わせや作業を「件名」ではなく需要の原因で分類します。パスワード再設定、アクセス申請、端末設定、定型データ抽出など、一定期間に繰り返される一つの需要を選びます。 件数だけでなく、解決時間、待ち時間、差戻し、再問い合わせ、専門家へのエスカレーション、誤処理時の影響を確認します。

最初の対象は、条件を明確にでき、影響が限定され、結果を確認しやすいものが適しています。 頻度が高くても、不可逆な変更、広い特権、重大な個人情報、例外が多い作業は、いきなり移管せず、標準化や設計改善を先に行います。 現在地を測っておくことで、移管後に本当に利用者体験と運用負荷が改善したかを比較できます。

実践手順2：判断を標準化し、完了条件まで一枚にする

選んだ需要について、必要な入力、前提条件、実施可否の判断、作業、確認、記録、完了条件を一枚にまとめます。 「通常どおり対応する」のような曖昧な表現を避け、どの情報を確認し、どの状態なら成功とみなすかを具体化します。

重要なのは例外です。本人確認に失敗した、対象が見つからない、結果が想定と違う、同じ申請が重複した、といった条件を列挙し、停止条件と相談先を決めます。 専門家の暗黙知は、操作手順よりも「いつ止めるか」「何を根拠に判断するか」に現れます。 標準化の段階で不要な承認、重複入力、分かりにくい画面を減らせば、移管する仕事そのものを小さくできます。

実践手順3：小さな範囲で知識と権限を移す

研修資料を配布して完了とせず、実案件を使って、説明、見本、共同実施、単独実施、振り返りの順で能力を確認します。 受け手が手順を再現できるだけでなく、例外を見分け、必要な情報を添えて支援を求められることを完了条件にします。

権限は対象作業に必要な最小範囲、期間、利用条件で付与し、操作記録を残します。 専門チームは仕事を手放して終わりではなく、初期の相談枠、エスカレーションの応答目標、知識更新の責任を持ちます。 一部の担当者や限定した利用者で試行し、誤処理、迷った箇所、差戻し理由を観察してから範囲を広げます。

実践手順4：安定した部分だけを安全に自動化する

自動化の前に、入力と出力が検証でき、失敗時に停止でき、手動へ戻せることを確認します。 申請フォームの入力検証、既知の問い合わせへの案内、定型的な照会、低リスクな変更など、判断境界が明確な部分から始めます。

自動化には、対象、実行者、権限、承認、監視、タイムアウト、再試行、重複防止、ログ、停止スイッチ、復旧手順を持たせます。 出力が不確実なAIを利用する場合は、許可された用途とデータ、根拠確認、人による承認、誤りを検知した際の停止・報告を別途設計します。 処理が速くなっても、誤りや問い合わせが増えるなら、対象条件か設計を見直します。

実践手順5：利用者成果と運用負荷を一緒に見直す

移管後は、左側で完結した割合だけを成功指標にしません。利用者の総解決時間、再問い合わせ、差戻し、誤処理、エスカレーションの質、専門家の割込み、手作業時間を確認します。 GOV.UKの利用者支援指針も、問い合わせをサービス改善の情報として扱い、支援担当、サービス構築担当、運用担当が協力して改善することを示しています。

月次の短いレビューで、不要になった需要、知識の欠落、画面や業務ルールの問題、自動化候補を整理し、担当者と期限のある改善へ変換します。 サービス、権限、組織、委託先、法令、利用者層が変わった場合は、移管済みの仕事も再評価します。 左へ移したまま固定するのではなく、需要そのものをなくす、製品へ吸収する、再び専門家へ戻す判断も含めて継続的に最適化します。

注意点：速さだけを成果にしない

  • 一律に移管しない：頻度、判断の複雑さ、誤処理時の影響、可逆性から対象を選ぶ。
  • 専門家を切り離さない：例外支援、知識更新、品質レビューの責任を明確に残す。
  • セルフサービスを強制しない：利用者の状況、アクセシビリティ、緊急性に応じて人の支援経路を用意する。
  • 自動化へ過大な権限を与えない：最小権限、入力検証、実行制限、監視、停止、復旧を設計する。
  • 平均値だけを見ない：一部の利用者、複雑な例外、重大な誤りが隠れていないか分布と事例を確認する。

まとめ：シフトレフトは、能力を需要へ近づける

シフトレフトを持続可能にするには、対象需要を選び、判断と完了条件を標準化し、知識と権限を小さく移し、安定した部分を安全に自動化し、利用者成果と運用負荷で見直す必要があります。 仕事を左へ押し出すのではなく、解決能力を利用者に近い場所へ育てることが目的です。

最初の一歩として、今月10回以上専門チームへ届いた反復作業を一つ選び、「通常ケースの開始条件」「完了を確認する証拠」「止めて相談する例外」を一枚に書いてください。 三つを合意できない作業は、まだ移管や自動化の準備ができていません。合意できた部分だけで短い試行を行い、結果を次の改善へ戻すことが安全な出発点です。

参考資料

本記事は公式・公的資料をもとに、一般的なITサービスマネジメントと運用改善の考え方を整理したものです。 個別組織の契約、法令適合性、セキュリティ、監査、労務その他の法律上・専門上の助言を行うものではありません。 公式資料は2026年10月6日時点で確認しています。実際の運用では、自社のサービス、利用者、組織、権限、委託契約、適用法令、リスク許容度を踏まえ、必要に応じて関係部門や専門家へ確認してください。

FW

WRITTEN BYFourthWall Consulting Teamテクノロジーと経営の両面から、企業変革を支援しています。

← 技術ブログ一覧へ戻る