改善の話になるたびに、「この業務は例外が多いから整理できない」「全部プロジェクト扱いで考えた方が早い」といった声が出て、手が止まる会社は少なくありません。AIや自動化の話題が出ても、そもそも何が繰り返し業務で、どこから人の判断が必要で、どの仕事を期限付きで管理すべきかが分からないからです。
前回の記事 マネジメントサイクル(PDCA・OODA)とは では、改善を回し続けるための考え方を整理しました。bp010 で扱うのは、その改善サイクルをどの業務に、どの粒度で当てるかを決めるための分類です。
2026年の中小企業にとって、定型 / 非定型 / プロジェクト の整理は、言葉の定義をそろえるためではありません。標準化しやすい仕事、自動化候補になる仕事、人が例外判断を担う仕事を見分け、役割と改善の順番を決めるための土台です。
本記事では、3種類の業務の違い、分類するときの見方、標準化や自動化へつなげる考え方、よくある失敗、bp009 の改善サイクルとどうつなぐかを整理します。
(このサイトでは、中小企業が業務プロセスの最適化を実践し、持続的な成長を実現するための総合的な情報を提供しています。全体像や関連する記事は「業務プロセス最適化ガイド|全15ステップで基礎から応用まで」でご覧いただけます。)
「請求処理は毎月あるのに、担当者ごとにやり方が違う」 「問い合わせ対応は全部イレギュラーだと言われて、整理が進まない」 「新しい施策も日々の処理も同じ会議で扱っていて、結局どれも前に進まない」
現場では、こうした混線がよく起きます。業務分類の役割は、仕事の価値を上下で分けることではなく、扱い方を整理して改善の順番を決めることにあります。
目次
業務を3種類に分ける理由
業務を 定型 / 非定型 / プロジェクト に分ける目的は、言葉をきれいに定義することではありません。どこまで標準化できるか、何を自動化候補にするか、どこに人の判断を残すかを決めやすくすることにあります。
押さえたい視点
分類は価値の高低を決めるものではありません。定型業務は土台として重要で、非定型業務は判断の質が重要で、プロジェクト業務は期限と合意形成の設計が重要です。違うのは価値ではなく、管理の仕方です。
分類が曖昧なままだと、毎月同じように発生する仕事まで都度対応になり、逆に本来は個別判断が必要な仕事を無理に画一化して失敗しやすくなります。改善や自動化が止まる原因は、ツール不足より先に、この混線にあることが少なくありません。
定型業務・非定型業務・プロジェクト業務の違い
3種類の違いは、発生頻度、再現性、期限、判断の重さを見ると整理しやすくなります。
分類で見る観点
- 同じ流れが繰り返し発生するか
- 手順と判断条件を言語化しやすいか
- 例外が出たときの分岐を事前に決められるか
- 期限とゴールが明確な一回限りの取り組みか
- 人が担うべき判断が、感情対応、利害調整、優先順位決定のどれに近いか
| 種類 | 特徴 | 標準化対象 | 自動化候補 | 人が担う判断 |
|---|---|---|---|---|
| 定型業務 | 頻度が高く、流れが繰り返し発生する | 手順、入力ルール、承認条件、例外分岐 | 入力、照合、通知、集計、定型承認 | ルール更新、例外の最終判断 |
| 非定型業務 | 都度状況が変わり、相手や文脈の読み取りが必要 | ヒアリング観点、確認漏れ防止、ナレッジ共有 | 下調べ、要約、たたき台作成 | 優先順位、対話、提案、例外対応 |
| プロジェクト業務 | 期限と成果物があり、関係者調整が必要 | 進め方、会議体、WBS、レビュー基準 | 進捗整理、議事録、リスク可視化 | 目標設定、意思決定、合意形成 |
定型業務
定型業務とは、毎月、毎週、毎日など一定の頻度で発生し、誰が担当しても同じ品質で進めたい業務です。請求書発行、勤怠締め、定例レポート集計、定型的なデータ更新などがこれに当たります。
重要なのは、定型業務が 単純で価値が低い という意味ではないことです。むしろ会社を安定運営する土台なので、手順や判断条件をそろえ、再現性を高める価値が大きい領域です。
非定型業務
非定型業務とは、毎回まったく同じ条件では発生せず、相手の状況、背景、優先順位、過去経緯を踏まえた判断が必要な業務です。クレーム対応、提案内容の調整、例外的な取引条件の判断、採用面接などが当てはまります。
非定型業務だからといって、属人化したままでよいわけではありません。判断基準、よくある論点、確認観点、過去の対応履歴は標準化できます。完全自動化が難しくても、下調べやたたき台づくりを補助する余地はあります。
プロジェクト業務
プロジェクト業務とは、期限、ゴール、関係者があり、通常運用とは別に進行管理が必要な仕事です。新サービス立ち上げ、オフィス移転、基幹システム切替、展示会準備などが代表例です。
ここで重要なのは、重要な仕事だから全部プロジェクト扱い にしないことです。毎月繰り返す運用までプロジェクト扱いにすると、改善サイクルも役割分担も定着しにくくなります。
分類を標準化・自動化へつなげる見方
分類したあとに見るべきなのは、どの業務をどこまで標準化できるかです。AIや自動化は、その後で検討した方が無理がありません。
定型業務で見るべきこと
定型業務では、手順、入力項目、承認条件、例外分岐をそろえられるかが最重要です。ここが整理できると、RPA、SaaS連携、ワークフロー、自動通知の候補が見えやすくなります。
- 標準化対象: 作業順序、入力ルール、承認ルート、締め時刻、差し戻し条件
- 自動化候補: 転記、照合、集計、定型通知、定型承認、定例レポート作成
- 人が残すべき判断: 新しい例外への対応、ルール変更の判断、異常値の最終確認
非定型業務で見るべきこと
非定型業務では、完全に同じ答えを出すことより、判断漏れを減らすことが重要です。よくある観点、確認項目、参考事例、初動手順を整えると、属人化を減らしやすくなります。
- 標準化対象: ヒアリング項目、確認観点、エスカレーション条件、対応履歴の残し方
- 自動化候補: 情報収集、要約、文案の下書き、関連事例の検索
- 人が残すべき判断: 相手との対話、優先順位調整、例外時の意思決定
プロジェクト業務で見るべきこと
プロジェクト業務では、作業そのものより、誰が何をいつまでにやるかを見える化できているかが重要です。WBS、会議体、レビュー基準がないまま走ると、通常業務と混ざって遅延しやすくなります。
- 標準化対象: 立ち上げ手順、WBSの粒度、会議体、報告フォーマット、完了条件
- 自動化候補: 議事録要約、進捗整理、リスク一覧の更新、リマインド
- 人が残すべき判断: 優先順位の決定、関係者調整、方針変更、最終意思決定
AI活用の位置づけ
AIは、定型業務では処理補助、非定型業務では下調べ補助、プロジェクト業務では管理支援として使うと現実的です。まず業務分類と運用整理を済ませてから使う方が、現場に無理なく定着しやすくなります。
よくある失敗と詰まりどころ
分類の議論が止まる会社には、いくつか共通パターンがあります。
よくある失敗例
例外が多いことを理由に整理をやめる
例外があるからこそ、通常処理と例外処理を分けて整理する必要があります。全部を例外扱いにすると、改善も引き継ぎも進みません。
定型業務を軽視する
`毎月やっているだけの仕事` と見なして後回しにすると、負荷とミスが積み上がり、非定型やプロジェクトへ使う時間が削られます。定型業務は会社の土台です。
全部プロジェクト扱いにする
通常運用までプロジェクト会議で管理すると、毎回の繰り返し改善が定着しません。プロジェクトとして扱うべきか、定型運用として改善すべきかを分ける必要があります。
ツール選定から始める
AIやRPAの導入可否より先に、何を標準化し、どこに人の判断を残すかを整理しないと、導入後に例外処理だけが増えやすくなります。
改善サイクルとどうつなぐか
前回扱った改善サイクルは、どの業務にも同じように当てればよいわけではありません。分類すると、回すべき粒度が見えやすくなります。
改善サイクルのつなぎ方
定型業務は PDCA で手順と例外を磨き、非定型業務は事例共有と短い振り返りで判断精度を上げ、プロジェクト業務は WBS と週次レビューで進行を管理する。分類は、どの改善サイクルをどこに当てるかを決めるための入口です。
- 定型業務: 毎日、毎週、毎月の繰り返し処理に対して、処理時間、差し戻し件数、例外件数などを見ながら PDCA を回す
- 非定型業務: 対応後に
どこで迷ったか次回に残すべき判断は何かを短く共有し、FAQや判断メモへ蓄積する - プロジェクト業務: 週次や隔週で WBS を見直し、依存関係、遅延、意思決定待ちを確認する
つまり、何を回すか と同時に どの粒度で回すか を決めることが重要です。毎月繰り返す仕事を大型プロジェクトのように扱っても重すぎますし、新規施策を日次の定型処理のように扱っても必要な調整が抜けやすくなります。
次回の記事 見える化のデメリットとは では、分類した業務を見える化するときに、どこまで公開し、どう扱うべきかという別の論点を整理します。分類と見える化をつなげて考えると、監視にならない運用を設計しやすくなります。
まとめ
定型 / 非定型 / プロジェクト の分類は、仕事の価値を決めるものではなく、標準化・自動化・役割設計の順番を決めるための整理です。定型業務は土台として整え、非定型業務は判断の観点を共有し、プロジェクト業務は期限と依存関係を管理する。この分け方ができると、改善もAI活用も進めやすくなります。
大切なのは、きれいな定義を作ることではなく、自社の業務を同じ粒度で見て、どこまで標準化できるかを言葉にすることです。そこができると、bp009 の改善サイクルも現場に当てやすくなります。
まず着手したいこと
最初の一歩
- 主要業務を10件から20件ほど書き出す
- 各業務について、頻度、担当、期限、判断の重さを書き添える
- `定型 / 非定型 / プロジェクト` のどれに近いかを仮置きする
- 定型業務は標準化候補、非定型業務は判断メモ候補、プロジェクト業務は進行管理候補として分ける
- まず一つだけ、分類結果を改善アクションにつなげる
最初から完璧に分類しようとしなくても構いません。大まかに分けてみるだけでも、改善の順番と必要な整理がかなり見えやすくなります。
自走しやすい会社と、相談した方が早い会社の違い
判断の目安
まずは自走で進めやすい状態
- 主要業務の頻度と担当がある程度見えている
- 定型業務の手順差や例外の多さを社内で把握できている
- プロジェクトとして扱う仕事と通常運用を分けて考えられる
伴走を入れた方が早い状態
- 部署ごとに業務の呼び方や粒度がばらばらで比較できない
- `例外が多いから整理できない` で議論が止まりやすい
- ツール導入の話だけ先に進み、標準化の順番が決まらない
- 通常業務とプロジェクトが混在し、責任分担が曖昧になっている
相談前に整理しておきたいこと
相談前に整理したいこと
- 毎月や毎週繰り返しているのに、担当者ごとにやり方が違う業務は何か
- 例外が多いと言われているが、実際にどんな例外が発生しているか
- 通常運用なのにプロジェクトのように扱っている仕事がないか
- AIや自動化を検討したい業務で、人が残すべき判断は何か
- 改善サイクルを回す単位が、日次、週次、月次のどれに近いか
「どこまで定型化できるか分からない」「非定型業務の判断基準をどう残せばよいか迷う」と感じる場合は、この5点だけでも先に整理しておくと、相談時の論点がかなり明確になります。
本シリーズの全体像を見ながら進めたい場合は、業務プロセス最適化ガイド|全15ステップで基礎から応用まで もあわせて確認してください。
補足コンテンツ
- 業務分類テンプレート 頻度、担当、業務区分、改善余地を一緒に整理できるたたき台です。
- プロジェクト管理WBSサンプル プロジェクト業務をタスクへ分解し、担当と期限を整理する際の参考に使えます。
テンプレートのPDF内にGoogle Spreadsheetのリンクがあります。必要に応じてコピーして活用してください。
「自社の業務をどう分類すればよいか整理しきれない」「標準化、自動化、役割分担を一緒に設計したい」といった段階であれば、論点整理から進めるとその後の改善がぶれにくくなります。