10.定型業務とは？非定型業務やプロジェクトとの違いと、効率化のポイント

改善の話になるたびに、「この業務は例外が多いから整理できない」「全部プロジェクト扱いで考えた方が早い」といった声が出て、手が止まる会社は少なくありません。AIや自動化の話題が出ても、そもそも何が繰り返し業務で、どこから人の判断が必要で、どの仕事を期限付きで管理すべきかが分からないからです。

前回の記事 マネジメントサイクル（PDCA・OODA）とは では、改善を回し続けるための考え方を整理しました。この記事 で扱うのは、その改善サイクルをどの業務に、どの粒度で当てるかを決めるための分類です。

業務を定型・非定型・プロジェクトに分けると、標準化しやすい仕事、自動化候補、人が例外判断を担う仕事が見えてきます。担当と改善の順番を決める際にも役立つ整理です。

本記事では、3種類の業務の違い、分類するときの見方、標準化や自動化へつなげる考え方、よくある失敗、改善サイクルとどうつなぐかを整理します。

シリーズ全体と関連する記事は、業務プロセス最適化ガイドで確認できます。

「請求処理は毎月あるのに、担当者ごとにやり方が違う」 「問い合わせ対応は全部イレギュラーだと言われて、整理が進まない」 「新しい施策も日々の処理も同じ会議で扱っていて、結局どれも前に進まない」

現場では、こうした混線がよく起きます。業務分類の役割は、仕事の価値を上下で分けることではなく、扱い方を整理して改善の順番を決めることにあります。

業務を3種類に分ける理由

業務を 定型 / 非定型 / プロジェクト に分ける目的は、言葉をきれいに定義することではありません。どこまで標準化できるか、何を自動化候補にするか、どこに人の判断を残すかを決めやすくすることにあります。

分類が曖昧なままだと、毎月同じように発生する仕事まで都度対応になり、逆に本来は個別判断が必要な仕事を無理に画一化して失敗しやすくなります。改善や自動化が止まる原因は、ツール不足より先に、この混線にあることが少なくありません。

同じ業務の中にも扱い方の違う仕事がある。問い合わせの受付、個別判断、FAQを整える取り組みを分けて考える。

定型業務・非定型業務・プロジェクト業務の違い

まず、継続する通常業務か、開始・終了と成果物を持つプロジェクトかを確認します。そのうえで、中の作業を、手順や判断条件をそろえられる定型部分と、個別判断が必要な非定型部分に分けます。プロジェクトの中にも定型作業はあります。この二つの見方を使って、管理するまとまりと、標準化する作業を整理します。

一つの業務を、扱い方の違う仕事へ分ける

「顧客問い合わせ対応は非定型」と一括りにすると、受付や履歴登録まで毎回考え直すことになります。記入例として、問い合わせ対応を次のように分けてみます。

プロジェクトは「期限と成果物で区切る」見方で、定型・非定型は「作業の繰り返しと判断」で分ける見方です。FAQ整備の中にも、記事の登録という定型作業と、掲載内容を選ぶ非定型の判断があります。3種類を完全に排他的な箱に押し込めず、管理したいまとまりと、その中の作業を分けると迷いにくくなります。

業務名や粒度がそろっていない場合は、先に業務一覧表の作り方で開始・完了と担当を整理します。「例外が多い」の中身が分からない場合は、現場ヒアリングの進め方で具体的な対応履歴や条件を確認してから分類します。

定型業務

定型業務とは、繰り返し、または所定の条件で発生し、標準の手順・判断条件を定められる業務です。請求書発行、勤怠締め、定例レポート集計などが例になります。年1回の更新や棚卸しにも、定型化できる作業はあります。発生頻度は分類の必要条件とせず、自動化の優先度を決める段階で、件数、作業時間、例外率、運用負荷を別に確認します。

定型業務を「単純で価値が低い」と見なすと、日々の運営を支える仕事を軽視してしまいます。手順や判断条件をそろえ、再現性を高める価値が大きい領域です。

非定型業務

非定型業務とは、毎回まったく同じ条件では発生せず、相手の状況、背景、優先順位、過去経緯を踏まえた判断が必要な業務です。クレーム対応、提案内容の調整、例外的な取引条件の判断、採用面接などが当てはまります。

非定型業務だからといって、属人化したままでよいわけではありません。判断基準、よくある論点、確認観点、過去の対応履歴は標準化できます。完全自動化が難しくても、下調べやたたき台づくりを補助する余地はあります。

プロジェクト業務

プロジェクト業務とは、期限、ゴール、関係者があり、通常運用とは別に進行管理が必要な仕事です。新サービス立ち上げ、オフィス移転、基幹システム切替、展示会準備などが代表例です。

「重要な仕事だから全部プロジェクト扱い」にすると、管理の仕方が合わなくなります。毎月繰り返す運用までプロジェクト扱いにすると、改善サイクルも役割分担も定着しにくくなります。

分類を標準化・自動化へつなげる見方

分類したあとに見るべきなのは、どの業務をどこまで標準化できるかです。AIや自動化は、その後で検討した方が無理がありません。

業務分類表の全10件・8項目。横にスクロールして備考まで確認できます。日付は記入例です。更新した原本を開く

分類表には、業務名、業務区分、担当、頻度、必要スキル／ツール、改善の余地、備考を記入します。原本の「顧客問い合わせ対応」は全体を非定型としていますが、自社の表では「受付・履歴登録」と「個別判断」を別行にするか、備考で分けてください。社内イベントも、企画の検討と、開催日までの実行管理では扱い方が変わります。

「改善の余地」は候補です。「RPAを導入すれば自動化できる」と確定させず、入力のばらつき、承認条件、例外時の確認先を調べてから判断します。元データのNo欄は業務を識別する番号として使い、分類を変えたときも対応履歴が追えるようにします。

問い合わせ対応なら、最初は受付項目と顧客・注文の照合条件をそろえます。次に、頻出する不足情報を減らし、例外率と確認時間を測ってから、自動登録の対象を選びます。返金や契約条件の変更は権限者の判断へ残します。

FAQ整備は、対象、公開日、承認者、引継ぎ先を決めたプロジェクトとして扱えます。たとえば、次の六つの作業へ分けます。

このように、分類した後は、標準化、測定、必要な部分の自動化へ進みます。ツール名だけで改善欄を埋めず、先に何をそろえるかを一件の仕事で決めてください。

定型業務で見るべきこと

定型業務では、手順、入力項目、承認条件、例外分岐をそろえられるかが最重要です。ここが整理できると、RPA、SaaS連携、ワークフロー、自動通知の候補が見えやすくなります。

• 標準化対象：作業順序、入力ルール、承認ルート、締め時刻、差し戻し条件
• 自動化候補：転記、照合、集計、定型通知、定型承認、定例レポート作成
• 人が残すべき判断：新しい例外への対応、ルール変更の判断、異常値の最終確認

非定型業務で見るべきこと

非定型業務では、完全に同じ答えを出すことより、判断漏れを減らすことが重要です。よくある観点、確認項目、参考事例、初動手順を整えると、属人化を減らしやすくなります。

• 標準化対象：ヒアリング項目、確認観点、エスカレーション条件、対応履歴の残し方
• 自動化候補：情報収集、要約、文案の下書き、関連事例の検索
• 人が残すべき判断：相手との対話、優先順位調整、例外時の意思決定

プロジェクト業務で見るべきこと

プロジェクト業務では、作業そのものより、誰が何をいつまでにやるかを見える化できているかが重要です。WBS、会議体、レビュー基準がないまま走ると、通常業務と混ざって遅延しやすくなります。

WBSの全16行・10項目。備考に完了条件を追記しました。横にスクロールして依存先と完了条件を確認できます。表の日程は記入例です。更新した原本を開く

WBS（作業を階層に分けた一覧）は、タスク名を並べるだけでは使いにくいものです。サンプルの「2 要件確認・WBS詳細化」は親行で、「2.1 ヒアリング実施」と「2.2 WBS作成」が子行です。「2.1完了後」という依存先を見て、ヒアリングで何が決まれば次へ進めるかまで確認します。

親行は子行をまとめるための行なので、親と子の期間を足して総工数にしません。並行できる作業もあるため、各タスクの期間の合計と、開始から終了までの経過期間は一致しないことがあります。まず一つの成果物について、担当・依存先・完了条件が追える粒度まで分けてください。

• 標準化対象：立ち上げ手順、WBSの粒度、会議体、報告フォーマット、完了条件
• 自動化候補：議事録要約、進捗整理、リスク一覧の更新、リマインド
• 人が残すべき判断：優先順位の決定、関係者調整、方針変更、最終意思決定

自動化候補を選んだら、対象件数、実作業時間、例外率、導入・運用の負荷を記録して小さく試します。投資判断へ進む際は、費用対効果の考え方で費用と効果の期間をそろえます。

よくある失敗と詰まりどころ

分類の議論が止まる会社には、いくつか共通パターンがあります。

改善サイクルとどうつなぐか

前回扱った改善サイクルは、どの業務にも同じように当てればよいわけではありません。分類すると、回すべき粒度が見えやすくなります。

• 定型業務：毎日、毎週、毎月の繰り返し処理に対して、処理時間、差し戻し件数、例外件数などを見ながらPDCAを回す
• 非定型業務：対応後に どこで迷ったか 次回に残すべき判断は何か を短く共有し、FAQや判断メモへ蓄積する
• プロジェクト業務：週次や隔週でWBSを見直し、依存関係、遅延、意思決定待ちを確認する

つまり、何を回すか と同時に どの粒度で回すか を決めることが重要です。毎月繰り返す仕事を大型プロジェクトのように扱っても重すぎますし、新規施策を日次の定型処理のように扱っても必要な調整が抜けやすくなります。

次回の記事 見える化のデメリットとは では、分類した業務を見える化するときに、どこまで公開し、どう扱うべきかという別の論点を整理します。分類と見える化をつなげて考えると、監視にならない運用を設計しやすくなります。

まとめ

定型 / 非定型 / プロジェクト の分類は、仕事の価値を決めるものではなく、標準化・自動化・役割設計の順番を決めるための整理です。定型業務は安定して回る手順を整え、非定型業務は判断の観点を共有し、プロジェクト業務は期限と依存関係を管理する。この分け方ができると、改善もAI活用も進めやすくなります。

大切なのは、きれいな定義を作ることではなく、自社の業務を同じ粒度で見て、どこまで標準化できるかを言葉にすることです。そこができると、改善サイクルも現場に当てやすくなります。

まず着手したいこと

最初から完璧に分類しようとしなくても構いません。大まかに分けてみるだけでも、改善の順番と必要な整理がかなり見えやすくなります。

自走しやすい会社と、相談した方が早い会社の違い

相談前に整理しておきたいこと

「どこまで定型化できるか分からない」「非定型業務の判断基準をどう残せばよいか迷う」と感じる場合は、この5点だけでも先に整理しておくと、相談時の論点がかなり明確になります。

本シリーズの全体像を見ながら進めたい場合は、業務プロセス最適化ガイド｜全15ステップで基礎から応用まで もあわせて確認してください。

補足コンテンツ

• PDFで見る：業務分類テンプレート
  編集用原本を開く 頻度、担当、業務区分、改善余地を一緒に整理できるたたき台です。
• PDFで見る：プロジェクト管理WBSサンプル
  編集用原本を開く プロジェクト業務をタスクへ分解し、担当と期限を整理する際の参考に使えます。

テンプレートのPDF内にGoogle Spreadsheetのリンクがあります。必要に応じてコピーして活用してください。

「自社の業務をどう分類すればよいか整理しきれない」「標準化、自動化、役割分担を一緒に設計したい」といった段階であれば、論点整理から進めるとその後の改善がぶれにくくなります。