【2026年8月版】
実装しない技術（第2回）― 業務の把握と、システム化の判断
公開日: 2026/08/11
読了時間: 約 27分
第1回では、依頼に混入する三つの歪み、デジタル化しても業務が変わらない五類型、そして ECRS による業務整理の手順を扱った。ECRS を適用するには、対象の業務が正確に把握されている必要がある。
第2回では、把握を誤らせる要因を整理したうえで、業務整理の結果をシステム化の判断へ繋ぐ。
1. 作業一覧では見えない業務の全体像
個別の担当者へどんな作業をしているかと尋ねると、担当者単位の作業一覧が得られる。その一覧をそのままシステム化すると、部門の境界や既存の役割分担まで固定される。経費精算を例に取ると、担当者へ尋ねて得られるのは社内作業の並びだが、業務の実際の始点と終点は別の場所にある。
| 視点 | 範囲 |
|---|---|
| 作業一覧 | 申請画面へ入力する → 上司が承認する → 経理が確認する → 振込データを作る |
| 業務の全体 | 従業員が業務上の費用を支払う → 正しい金額が速やかに返金される → 会社の会計記録へ反映される |
全体の範囲で捉え直すと、別の解決策が出てくる。法人カードを使い、交通系ICや予約システムから明細を取得すれば、入力そのものが減る。少額経費を定額支給にし、領収書の提出が不要な範囲を設ければ、扱う件数が減る。会計処理と申請を一体化し、例外だけを人間が確認する形も取れる。どの案でも、効率化の対象だったはずの申請という手続きそのものが減っていく。
2. 現場の要求と、その背後にある問題
現場は日々の業務にある摩擦を最もよく知っている一方で、その摩擦がなぜ存在し、業務全体でどのような役割を果たしているかまでは把握できないことがある。要求は解決策の形で届くため、背後の問題を確認する必要がある。
「この画面にも顧客住所を表示してほしい」という要求を例に取ると、背後には複数の異なる問題があり得る。別画面を開くのが面倒なのかもしれないし、顧客を取り違えた事故があったのかもしれない。印刷物へ住所を書く必要がある、問い合わせ時に本人確認する、他システムの住所が信用できない、という事情も考えられる。表示項目を追加する前に、どの問題を解決しようとしているのかを確認する。
GOV.UK の利用者調査のガイドは、利用者のニーズを満たすサービスを提供するには、利用者が誰で、何をしようとしていて、現在どのようにしているかを理解する必要があるとしている。現場から集める対象も、機能の注文だけではない。
| 質問の対象 | 具体的な問い |
|---|---|
| 時間 | 何に時間がかかり、どこで待っているか |
| 誤り | どこで間違えるか |
| 懸念 | 何を恐れ、何を確認しているか |
| 例外 | どんな例外に対応しているか |
| 依存 | 誰へ問い合わせているか、どの情報を信用していないか |
| 目的 | 本当はどの結果を得たいのか |
これらは利用部門を問い詰めるための質問ではなく、組織が無意識に抱えている前提を共同で見つけるための質問になる。
3. 「法令で決まっている」の検証
業務を廃止しようとすると、法律で決まっている、監査上必要である、セキュリティ上必要である、内部統制上なくせない、コンプライアンス上必要である、という言葉が返ってくる。本当に必要な統制もあるため、確かめる対象は具体的な根拠と要求内容になる。要求されているのが結果なのか現在の手順なのか、その根拠が今も有効なのかで、取れる選択肢は変わる。
| 根拠 | 確認する内容 |
|---|---|
| 法令 | どの法令のどの条文か。保存対象、保存期間、原本か電子記録か、誰の確認が必要か、全案件が対象か |
| 監査 | 監査目的と検証するリスク。全件確認が必要か、証跡として必要な情報は何か、承認操作でなければならないか、自動記録で代替できないか |
| セキュリティ | 人手の承認以外の手段。入力制約、職務分離、利用上限、異常検知、改ざん防止ログ、定期レビュー |
統制の目的と現在の運用を分離すれば、別の実現方法を選べるようになる。必要だから残すという扱いをやめ、何を満たせば必要条件を満たしたと言えるのかを定義する形になる。
4. 業務整理で残す記録
業務整理の目的は、巨大な業務要件書を作ることではない。なぜ現在の業務が存在し、何を変え、どこまでをシステムへ渡すのかという判断を、後から追跡できる状態にすることである。
残すのは次の四つになる。文書の数は現場の規模に応じて増減するが、この四つの区分に収まっていれば足りる。
| # | 成果物 | 含めるもの |
|---|---|---|
| 1 | 問題・目的 | 解決する問題、実現すべき結果、利用者、関係者、制約と根拠 |
| 2 | 現状 | 実際の業務と情報の流れ、担当部門、システム、基準値、各工程の価値と必要性 |
| 3 | 将来像・代替案 | 廃止・統合・縮小・標準化した将来像、非システム施策、リスクと前提と依存関係、成功指標 |
| 4 | システムの担当範囲 | 人間が担う範囲、既存サービスへ任せる範囲、新規開発が担う範囲、対象外、続行と中止の判断 |
この四つは順に繋がる。問題・目的から現状を経て将来像を作り、システムの担当範囲を決めてからシステム化要求へ渡す。
4.1 問題・目的
誰のどの問題を解き、どの状態を実現するのかを記録する。IPA のユーザのための要件定義ガイドは、ビジネス要求定義を現状把握、問題と課題の抽出、ゴール抽出、手段抽出という順序で整理している。ゴールを先に決め、手段はその後に来る。
目的は結果で書く。「月次報告書を作る」ではなく「経営者が前月の異常を翌営業日までに把握できる」と書けば、報告書という手段の存続が前提から外れる。
関係者には、利用者、受益者、業務担当者、意思決定者、統制責任者が入る。依頼者と利用者と受益者が一致するとは限らない。GOV.UK も利用者とそのニーズの理解を最初の基準に置き、サービスとの接点だけでなく、利用者が何を達成しようとしているのかを全体の文脈から捉えるよう求めている。
具体的な文書としては次のものになる。
- 問題定義書（解決する問題、実現する結果、成功と判定する状態）
- ステークホルダー一覧（役割、関心事、影響の受け方、承認権限）
- 制約一覧（法令、契約、規程、予算、期限、既存システムとの関係）
4.2 現状
現在の業務と情報の流れを、実態に基づいて可視化する。マニュアル上の手順ではなく、実際に行われている処理を取る。Lean Enterprise Institute の実践記事でも、マップに必要な要素として処理ステップ、サイクルタイム、完全かつ正確な割合、情報の流れ、待ち時間が挙げられている。
同時に基準値を取る。件数、所要時間、待ち時間、担当人数、エラー率、差し戻し率、問い合わせ件数、維持費が対象になる。GOV.UK の性能指標のガイドは、改善の前に全チャネルを含む基準値を確立し、変更後の性能をそれと比較するよう求めている。効果測定のガイドも、どこから始めたかを知らなければプロジェクトの終わりに改善したかどうかは分からないとしている。
各工程については、価値と必要性を分類する。利用者価値を生む、法令や統制上必要、後工程に必要、現在は必要だが将来不要、根拠不明、という区分になる。その際に根拠と出典も併記する。
| 工程 | 必要とされる理由 | 根拠 | 根拠の主体 |
|---|---|---|---|
| 上長承認 | 不正防止 | 社内規程第X条 | 経理部 |
| 7年保存 | 法定保存 | 法令X条 | 法務 |
| 毎月集計 | 経営会議 | 慣習のみ | 経営企画 |
この形にすると、法令によるものと慣習によるものが同じ表の中で区別できる。「昔から」は根拠の欄に書けない。
具体的な文書としては次のものになる。
- 現行業務フロー図（開始条件から完了条件まで、部門とシステムを横断した実際の流れ）
- 業務量・所要時間の実測表（件数、処理時間、待ち時間、差し戻し率、エラー率）
- 帳票・データ項目一覧（発生源、利用先、参照実績のない項目の印）
- 工程別の価値・根拠表（上の例のように、必要とされる理由と根拠と主体を並べたもの）
4.3 将来像・代替案
現状をそのまま電子化せず、不要な工程、重複、再入力、承認を廃止・統合・簡素化した将来像を作る。Lean Enterprise Institute の行政業務の事例でも、現状から再作業や重複を洗い出し、工程の統合と削除を検討している。
規程変更、組織変更、契約変更、教育、権限委譲、既存サービスの利用といった、システムを作らない案も同じ候補集合に入れる。GOV.UK の DDaT Playbook も、提供方式を決める前に利用可能な選択肢を評価するよう求めている。
各案にはリスク、前提、依存関係、期待効果を付ける。リスクは発生確率と影響と代替統制で扱い、この工程は怖いから残すという判断を避ける。
具体的な文書としては次のものになる。
- 将来業務フロー図（廃止・統合・簡素化を適用した後の流れ）
- 工程別の処置一覧（廃止、頻度削減、対象限定、統合、標準化、順序変更、現状維持のいずれかと、その理由）
- 代替案の比較表（システムを作る案、規程や組織で解く案、何もしない案を同じ列で並べたもの）
- リスク登録簿（廃止や変更ごとに、発生確率、影響、代替統制、受容の可否）
4.4 システムの担当範囲
将来像のうち、何を人間が行い、何を既存サービスへ任せ、何を新しいシステムが担うのかを決める。対象外も明示する。ここで初めてシステム化要求の候補ができる。
IPA の DX SQUARE も、システム化要求は先にまとめたビジネス要求をもとに導き出すものとしている。
具体的な文書としては次のものになる。
- 担当範囲の定義書（人間が行う範囲、既存サービスへ任せる範囲、新規開発の範囲、対象外）
- システム化要求の候補一覧（優先度と、それぞれが解決する問題への対応付け）
- 判定記録（続行と中止のどちらを選んだか、その根拠と、再評価する時期）
この節で重要なのは、現状からシステム化要求へ直接繋がない点になる。間に将来像と非システム施策の比較が入る。ここが通常の要件整理と、作らないための業務整理を分ける境界である。
5. 開発着手前の判断表
業務ごとに、次の順序で判断していく。
| # | 判断 | 主な問い | 結果 |
|---|---|---|---|
| 1 | 目的 | 何の結果を生む業務か | 目的不明なら廃止候補 |
| 2 | 必要性 | 法令・契約・価値・リスク上、本当に必要か | 根拠がなければ廃止 |
| 3 | 重複 | 他の業務やデータで代替できないか | 統合または共通化 |
| 4 | 範囲 | 全件・全項目・毎回必要か | 対象や頻度を縮小 |
| 5 | 手順 | 分岐・承認・受け渡しを減らせないか | 単純化 |
| 6 | 標準化 | 部門別・担当者別の例外をなくせないか | 標準化 |
| 7 | 既存手段 | 制度変更、運用変更、既存製品で解決できないか | 新規開発しない |
| 8 | 投資効果 | 開発・運用・移行費に見合うか | 手作業維持も選択肢 |
| 9 | 技術適合 | 安定し反復可能な処理か | 適する部分だけ自動化 |
| 10 | 終了条件 | いつ廃止・再評価するか | 永久運用を避ける |
この並びは、システム化の可否を最初に聞かない順序になっている。自動化できるかどうかは最後の問いに置かれる。
5.1 システム化する価値があるか
判断表を通した後に残る問いは二種類あり、性質が違う。一方はそのシステムへ投資する価値があるかで、もう一方はその処理を自動化できるかである。順序としては前者が先になる。毎日千回繰り返される規則的な作業でも、その作業自体を廃止できるなら自動化しない方がよい。
投資の側で確認するのは次の六点になる。
- 解決する問題と実現する結果が明確である
- 十分な処理量、リスク、または価値がある
- 期待する利用者・業務上の成果を測定できる
- 必要なデータと利用目的が定義され、品質を管理できる
- サービス、業務、データの責任者が存在する
- ライフサイクルコストを上回る価値が期待できる
最初の三点は、GOV.UK の Discovery が次工程へ進む前に確かめるものとほぼ重なる。問題と利用者を理解し、解決の価値と現在のコストを把握したうえで、追求するだけの効果があるかを判断する。
件数の多さは、この判断を構成する一変数にすぎない。年に一度しか発生しなくても、一件の失敗が重大事故になる、人手では扱えないデータ量がある、法令上の証跡が要る、という業務はシステム化の対象になる。
四点目のデータについては、集めたいという理由だけでは足りない。英国政府はデータの所有者に、意味、内容、品質、管理の責任を負わせ、そのデータが目的に適合していることを保証させる。Data Quality Framework も、良質なデータがより良い結果の前提になるとしている。品質と管理責任を引き受けられないデータは、システムを作る理由にならない。
五点目の責任者も同じ性質を持つ。GOV.UK の Service owner は、品質、性能、便益、成果について責任を負う役割として定義されている。作る人はいるが、運用開始後に価値と品質とデータと廃止を誰が判断するのか決まっていない状態で着手すると、この責任が空席のまま残る。
六点目のコストには、開発と運用に加えて、セキュリティ対応、データ管理、変更、移行、最終的な廃止までが入る。この点は次節で扱う。
5.2 どこまで自動化できるか
投資の価値が認められた後に、処理ごとの自動化適性を見る。Microsoft の自動化に関するガイダンスは、反復的で手続き的、単純で明確、かつ長期間変わりにくい処理を優先し、複雑な変動や人間の判断を含む部分を無理に自動化しないよう勧めている。
- 処理が反復可能である
- 開始条件、入力、結果が定義できる
- 自動化する判断をルールまたは判定境界として定義できる
- 手順が一定期間安定すると期待できる
- 標準処理と、人間判断を必要とする例外を分離できる
一点目と二点目は繋がっている。繰り返せる処理であっても、どの条件で始まり、何を受け取り、何を返すのかが決まっていなければ実装できない。Lean の Standardized Work も、現時点で最も効率的な作業方法を定義し、それを改善の基準に置く考え方を取る。安定して繰り返せない業務は、自動化より先に標準化の対象になる。
五点目が実務では効いてくる。例外まで完全に自動化できなければシステム化できない、ということではない。同ガイダンスは自動化を全か無かの選択ではないとし、人間の判断が必要な工程を含む流れでも、その前後を自動化できるとしている。正常系100件と例外5件があるなら、例外を人間へ回す境界を設ければよい。
5.3 先に業務へ戻すべき状態
次の条件に当てはまる業務は、システム化の前に業務側の整理が要る。
| 状態 | 戻す先 |
|---|---|
| 目的や利用者が曖昧である | 問題定義へ戻す |
| 成功状態や改善効果を観測できない | 問題定義と測定設計へ戻す |
| 判断基準が共有されず、担当者ごとに違う理由も分かっていない | 業務の標準化へ戻す |
| 標準処理より例外や変動が支配的である | 業務モデルの見直しへ戻す |
| 手順がまだ安定していない | 標準化できる段階まで待つ |
| 必要なデータの品質、意味、所有責任を保証できない | データ側の整理へ戻す |
| サービスやデータの責任者が不明である | 責任の割り当てへ戻す |
| 低頻度で、自動化による期待価値も小さい | 手作業のまま維持する |
| 現在の業務をそのまま再現することが前提化されている | 改善可能性の検討へ戻す |
これらを残したままシステム化すると、曖昧さや対立をコードとして固定することになる。手作業のままでも許容できないか、既存製品で足りないかを先に確認する必要がある。
ここまでで、業務を把握し、記録し、システム化の可否を判断する手順が揃った。ただしこの手順を知っていても、組織は開発へ進むことがある。第3回では、そちらへ傾ける予算と契約の構造を扱い、そのうえで第1回からの内容を開発着手の条件として整理する。
参考リンク
- GOV.UK Service Manual — How user research improves service design
- GOV.UK Service Manual — How the discovery phase works
- GOV.UK Service Standard — 1. Understand users and their needs
- GOV.UK — Data ownership model
- GOV.UK — The Government Data Quality Framework
- GOV.UK DDaT Capability Framework — Service owner
- Microsoft — Recommendations for implementing automation
- Lean Enterprise Institute — Standardized Work
- Lean Enterprise Institute — Using Lean Thinking to Reinvent City Government
- IPA — ユーザのための要件定義ガイド 第2版
- GOV.UK Service Manual — How to set performance metrics for your service
- GOV.UK — The Digital, Data and Technology Playbook
- Lean Enterprise Institute — Your Value Stream Map Looks a Little Different…
- GOV.UK Service Manual — Measuring the benefits of your service
- IPA DX SQUARE — 要件定義とは？