「業務設計」と「運用設計」の違いは？ それぞれの基本知識から設計時のポイント、進め方などを解説

企業内での様々な業務の効率化・および課題洗い出しなどの際に、よく施策として挙がる内容には「業務設計」や「運用設計」があります。

それぞれの設計は観点が異なるものであり、違いを理解しておくと明確な方針を決定しやすいでしょう。

本記事では「業務設計」と「運用設計」の基本知識から、進め方や留意すべきポイントなどを解説しています。

運用設計書のサンプルもご用意しております。よろしければご活用ください。

まずは「業務設計」と「運用設計」について、あらためて基本知識をご紹介します。

業務設計では、社内全体、あるいは部署内などにおいて、つながりのある業務全般を見渡し、それぞれの業務フローにて作成・整理・修正などを行いながら、社内あるいは部署内などの業務全体を最適化します。

業務設計においては、ひとつひとつの業務を単体の作業として注目するのではなく、すべて全体フローの一部として捉え、業務全体を可視化・最適化していきます。
可視化・最適化の過程においては、もともと行われていた業務内容をいったん細かく分け、その業務だけでなく全体的なつながり・影響も考慮しながら、企業そのもののパフォーマンスを向上させるという視点で業務手順や業務内容を再設計します。

業務設計で目指すべき結果、得られる成果としては、それぞれの業務のつながりがスムーズになり全体的な作業効率が上がる他、トラブルが起きた際の影響を最小限にできるといった点が挙げられます。

運用設計では、システムやソフトウェアを開発し正式にサービスリリースした後のことを想定して、安定運用を行うための各種設計を行います。
主に運用手順や監視手順、保守手順などを可視化し、障害発生時の対応、機能維持、可用性などの観点で運用の設計をしておきます。

運用設計の成果物として、一般的に運用設計書ができあがります。

以上のように、「業務設計」と「運用設計」はそれぞれ同レベルの比較対象というよりは、目的や意義、対象規模が異なる別レベルの概念です。
そのため、例えば全体的な業務設計の一環として、サービス運用担当の部署において運用設計の作成や見直しに着手することもありえます。

業務設計と運用設計の大まかな違いがわかったところで、それぞれの目的についても詳しく見てみましょう。

業務設計では個々の業務を一度細分化し、業務全体への関連性を考慮しながら業務全体にとって最適なプロセスを再構築していきます。

このようなことを行う業務設計の主な目的としては、個々の業務プロセスにおいて属人化している部分の発見・可視化、および改善などが挙げられます。また、これらの目的は最終的にビジネスの利益の増大や、競合優位性の確立にもつながります。

個々の業務におけるフローが、例えばそれぞれの部署や担当者に任せきりで全体にとっての最適化ができていない場合には「3M」と呼ばれる現象が起こりがちです。

• 「3M」とは
  ムリ：リソースに対する作業量の超過・短納期や過剰な品質 など
  ムダ：本来不要な作業・過剰な人員投下、既存の設備やツールをまったく活用できていない など
  ムラ：作業可能量の不安定さや、アサインされるメンバーが固定でないことによる成果の不安定さ など

この「3M」に付随する業務の属人化や、業務間コミュニケーションコストの増大、対応品質のばらつきといった業務課題も見据えて業務設計を行っていく必要があります。

運用設計では、主にシステムやソフトウェアを開発後、サービス運用を開始した段階においての、「効率的で円滑なシステムの運用、運用範囲の明確化」を目的とします。

システムやソフトウェアは開発が終わってローンチした後、サービスの提供が続くかぎり、ずっと長期的に運用を行っていくこととなります。
従って、長期的な視点で安定運用を果たせるような設計を行うのです。

細かい視野ではシステム障害の発生を防止する、および万が一の障害発生時にもシステムの可用性や機能維持を担保する、といった目的を意識しつつ、システム運用や保守における属人化した業務プロセスの発見・可視化・改善を行っていきます。

業務設計と運用設計それぞれを理解するために、実際の導入時の大まかな流れを見ておきましょう。

業務設計は大まかに以下のような流れで進めていきます。

• 現場への状況ヒアリング・現状分析
  個々の業務について、その業務を行っている部署や担当者、およびその業務に関連する他部署にも現状をヒアリングし、「誰がどのような作業を行っているのか」「どのような手順で行っているのか」を確認します。
  確認を進める際には、前述の「3M（ムリ・ムダ・ムラ）」の可能性があるか、その他の業務全体の視野においてちょっとした問題点まで含めすべて洗い出せるように、極力細部までありのままを確認しておきます。
• 課題整理・改善案検討
  行ったヒアリングにより確認できたそれぞれの課題について、対応の優先順位づけや、改善案の検討を行います。
  優先順位づけについては、あくまで社内の業務全体の視点で優先順位を検討する他、まずは「簡単に取り組めて、すぐに成果が見えやすい部分」から着手するというのもひとつの方法です。
  そうすることにより、業務設計におけるひとつの成果をまず出しておけるため、次の課題解決にも取りかかりやすくなったり、継続して全体的な業務設計を進めていきやすくなったりというメリットがあります。
• 業務設計の計画策定
  まとめられた改善案に対して、ひとつひとつ実行計画を策定していきます。
  改善策を具体的にどのような手順で進めていくのか、スケジュールに落としこみながら計画する必要があるため、どの部署の誰が実施するのか、事前準備の内容やトラブル想定など含め細部を検討します。
  また、ひとつひとつの実行計画を終えた際に行う成果の評価について、評価方法などもこの段階で決定しておきます。
• 計画実行
  策定した計画に基づいて、改善を実行します。
• フィードバック、効果検証
  計画実行後、実際にどのような変化が起きたかを確認・検証するために、計画策定の段階で決めておいた方法に基づいて成果を評価します。併せて、それぞれの業務の現場や関係各所からのフィードバックを集めておきます。
  何か問題が起きてしまっていた場合には、必要に応じて再び「課題整理・改善案検討」を行います。

運用設計は大まかに以下のような流れで進めていきます。

• 提案・計画
  運用設計のための計画、および提案を行います。
  運用設計はシステムやソフトウェアをリリースした後の運用に関する設計を行うため、実際に利用する顧客・クライアントの合意もこの段階で得ておきます。
  運用設計はシステムの仕様や機能の細部を踏まえて設計していく必要があるため、場合によってはシステムの開発設計段階から並行して開始することもあります。
• 要件定義
  システム運用担当者の業務内容、監視オペレーターの業務内容、保守担当者の業務内容といったように担当ごとの細かな状況を整理。さらに、運用設計を「業務運用設計」「基盤運用設計」「運用管理設計」の3つに分けて、それぞれ要件を定義していきます。
• 運用テスト
  サービスリリース後の環境になるべく近い実行環境を用意した上で、作成した運用設計を実際にテストします。運用の実用性を確認し、フィードバックを取得した上で必要に応じて運用設計の見直しを行います。
  運用設計の進め方については、下記記事でさらに詳しく解説していますので併せてご覧ください。
  ▼システム開発後の「運用設計」とは？ 重要性や進め方を解説

業務設計を行う際に、留意しておくべきポイントを解説します。

業務設計ではまず業務ごとの現場の状況確認・課題の洗い出しを行いますが、その際には以下に挙げるようなフレームワークを活用すると効率的、かつ網羅的に洗い出しを行えるため便利です。
それぞれ概要を解説します。

• ECRS（イクルス）
  「Eliminate（排除）」「Combine（結合）」「Rearrange（並べ替え）」「Simplify（簡素化）」の観点による、効果的な業務改善を目的としたフレームワークです。
  一般的に、“イクルス”の順番どおり「E→C→R→S」の順番で取りかかると業務改善の効果が高いといわれているフレームワークであるため、洗い出し後に優先順位を決定するひとつの基準としても有効です。
• PDCAサイクル
  「Plan（計画）」「Do（実行）」「Check（評価）」「Action（改善）」を継続的に繰り返し、業務改善を目指していくフレームワークです。
  業務設計の契約や、実施後の見直しに活用できます。
• ロジックツリー / デシジョンツリー（決定木分析）
  業務設計で洗い出された様々な課題をツリー状に枝分かれさせ、枝分かれの先のひとつひとつを分解して考えるフレームワークです。
  ツリー状の枝分かれを検討する際には、漠然と枝分かれさせるのではなく、漏れなくダブりも生じないように意識しながら的確に設定していくことが重要です。業務設計において、個々の業務上の課題を網羅的に把握し、原因を分析する際に活用します。
• KPT
  「Keep（続けるべきこと）」「Problem（やめるべきこと）」「Try（新しく挑戦すべきこと）」の3つの観点・要素に分けて現状分析を行うフレームワークです。
  業務設計において、現状の課題分析や実施後の再設計などの際に活用します。
• バリューチェーン分析
  開発・製造からリリース、アフターサービスまで一連の業務をプロセスや機能ごとに分類した上で、それぞれの工程でどのような価値（バリュー）が生まれるのかを考え、課題や自社の強みを可視化するために用いられるフレームワークです。
  業務設計においては、個々の業務内の工程それぞれの価値を見直しながら、優先順位を決めていく際などに活用されます。

企業内、部署内などの業務設計を行う際に、個々の業務ごとに「インプット」と「アウトプット」があることを意識しておきます。
インプットとは、その業務の始まりの地点、つまり業務を行うための情報やモノなどのリソースが入ってくる地点です。
例えば製品を製作する業務であれば製品の材料が入ってくる段階、接客業務であれば顧客が来訪した段階、情報処理業務であれば情報が到着した段階がインプットとなります。

アウトプットは、その業務ごとの成果が出力される地点です。

前述の製品を製作する業務であれば製造完了、接客業務であれば顧客に満足してもらえるサービスを提供できた段階、情報処理業務であれば情報処理を完了し次の工程へ結果を渡せた段階がアウトプットとなります。

このような業務ごとの「インプット」と「アウトプット」を意識した上で、アウトプットと次のインプットなども考慮しつつ全体的な業務設計を行っていきます。

「QCD」とは、「Quality（品質）」「Cost（費用）」「Delivery（納期）」の観点で業務ごとの生産性の管理やマネジメントを行っていく方法、およびその指標です。

これらの3要素は互いにトレードオフの関係にあり、ひとつの要素を改善するためには他の要素を犠牲にしなければならない場合が多くなるため、それぞれの業務において、企業にとってはQCDのどれを現在優先すべきなのか、という点も考慮に入れながら業務設計を行っていく必要があります。

続いて、運用設計を行う際に留意しておくべきポイントを解説します。

サービスリリース後のシステム運用においては、システム自体の細かな仕様、機能の詳細や今後の拡張計画などに加え、システムを利用する顧客の個人情報なども取り扱うため、絶対に外部に漏らしてはならない機密情報が大きく関わってくることになります。
そのため、運用設計においては何より、「その運用方法にて、機密情報を守れるか」に着目して設計を行っていきます。

機密情報保護の観点で、例えばアカウント追加や変更の承認フローは最適であるか、各種リソースへのアクセス権設定方法は適切か、機器やOSのぜい弱性に関する情報を把握できる体制になっているか、ぜい弱性が発見された場合の適用手順や承認フローは最適であるか、といった確認を行います。

ローンチされたシステムやサービスの運用においては、セキュリティインシデントなどのトラブルを未然に防止することが重要となりますが、併せて万が一のトラブル発生時にもシステムに可用性があり、システムを利用している顧客も一定以上のレベルで業務を継続できることが大切となります。

運用設計においてはトラブル発生時の可用性の観点で、機器の冗長化や、物理的場所を分散した上でのバックアップセンターの設置、および迅速な復旧体制の確立を検討しておきます。

ここまで、「業務設計」と「運用設計」を様々な観点で比較しながら解説しましたが、冒頭の項で述べた通り、業務設計と運用設計は同レベルで比較できる二者択一の対象などではなく、それぞれ目的や意義、対象規模が異なる設計となります。

そのため、例えば社内での全体的な業務設計を行っていく上で、サービス運用担当部門における施策として運用設計の見直しに着手するといったケースもありえます。

テクバンでは、業務設計や運用設計において課題を感じているお客様へ向けて、各種サービスをご用意しております。
テクバンのエンジニアが対応するTechvan Remote Centerでは、新規環境の運用設計のサポートが可能です。「業務設計の必要性を感じているが何から着手すべきかわからない」「運用設計についてプロの意見を聞きたい」といった場合には、お気軽にご相談ください。

業務設計と運用設計は個別の概念ではなく、同時に行われることもある異なった観点の設計です。
本記事で解説した内容をぜひ、業務設計の見直し・運用計画など自社に必要な施策検討にお役立てください。

運用設計については、以下の記事でより詳しく解説しています。ぜひ、ご参考ください。
▼運用設計とは？ システムの安定稼働における重要性や行うべきタイミングを解説