『業務設計の教科書』要約【属人化を排除して仕事を仕組み化する】

「DXを進めたのに、現場が楽にならない」。

この違和感は珍しくありません。
システム導入やAI活用そのものが目的化し、肝心の業務プロセスが整理されないまま進むと、ツールは増えても仕事は複雑化します。

『業務設計の教科書』は、この失敗パターンを正面から扱った実務書です。
テクノロジー導入の前に、業務を「見える化」し、再現可能な仕組みに変える手順を体系化しています。

この記事では、本書をGolden Ratio（要約50%・分析30%・実践20%）で整理します。
読み終える頃には、現場で止まりがちな改善プロジェクトを前に進める具体手順が見えるはずです。

書籍情報

• 書名: 業務設計の教科書
• 著者: 武内俊介
• 出版社: 技術評論社
• 発売日: 2025年12月25日
• ページ数: 304ページ
• ASIN: 4297153726（紙版）

要約（50%）: 本書の核心は「システムより先に業務を設計する」こと

1. 第1章: DX失敗の原因は、導入順序の逆転にある

本書は冒頭で、RPAやSaaS導入が失敗する典型を示します。
それは「何を改善したいか」を定義する前に、「何を入れるか」を決めてしまうことです。

• ツール選定が先
• 業務理解が後
• 現場の混乱が増える

この順序だと、既存のムダをそのままデジタル化するだけになります。
本書が強調するのは、まず業務の目的・流れ・責任分界を明確にし、その後で技術を当てる順番です。

2. 第2章: 業務の地図を作り、暗黙知を形式知に変える

業務改善が止まる最大要因は、全体像が共有されていないことです。
本書は「業務の地図」を作ることで、個人依存の仕事をチーム資産に変える重要性を説きます。

ここで示される観点は次の通りです。

• 誰が何を起点に動くか
• どの情報がどこへ流れるか
• どこで待ち時間・手戻りが発生するか

この可視化がないまま改善案を出すと、対症療法になりやすい。
本書は、現場の経験知を「設計可能な情報」に変換する工程を丁寧に示しています。

3. 第3章: 現状分析は「感覚」ではなく「手順」で行う

第3章では、業務定義シートや業務地図を使い、現状把握を標準化します。
ポイントは、問題を人の能力に帰属させず、業務構造として捉えることです。

• 仕事の前提条件は何か
• 入力情報の品質は安定しているか
• 出力物の定義は揃っているか

この確認をせずに「担当者が頑張る」で回すと、属人化が深まります。
本書は、個人の努力に依存しない運用への転換を、実務フォーマットで支えています。

4. 第4章: 業務の本質に迫り、ムダを撤廃する

本書の中核は第4章です。
「仕事」と「作業」を切り分け、価値を生まない工程を特定して減らすことが主題になっています。

特に有効なのは、ECRS的な発想です。

• Eliminate: そもそも不要ならやめる
• Combine: 分割されすぎた工程は統合する
• Rearrange: 順序を入れ替えて待ちを減らす
• Simplify: 手順そのものを簡素化する

ここで重要なのは、自動化をゴールにしないことです。
本書は「自動化の前に整理がすべて」と明言し、改善の優先順位を誤らない設計を促します。

5. 第5章: すべてをシステム化しない勇気を持つ

第5章では、デジタル化の適用範囲を見極めます。
「全業務を機械化すべき」という極端な発想を避け、人とシステムの最適分担を設計する章です。

• 判断の文脈が多い業務は人が担う
• 反復処理はシステムに寄せる
• 境界領域は段階的に移行する

この視点がないと、現場の運用負荷が跳ね上がります。
本書は、技術志向と現場実装のバランスを取る現実的な姿勢を貫いています。

6. 第6章: 業務設計は一度で終わらない

本書の後半は、継続改善の運用設計に焦点を当てます。
業務は常に変化するため、設計も更新し続ける前提が必要だと述べます。

• 小さな変更が積み重なってムダになる
• 属人化は放置すると再発する
• ブラックボックス化は静かに進行する

この現実を踏まえ、定期的な再設計サイクルを回す仕組みが推奨されます。
「完成品を作る」のではなく「改善し続ける土台を作る」。この発想転換が重要です。

7. 第7章: ストーリー形式で、現場の抵抗と突破を描く

第7章は、DXプロジェクト失敗から立て直しまでをストーリーで学ぶ構成です。
理論だけでは見えにくい現場の抵抗、部門間対立、認識ギャップが具体的に描かれます。

• 準備不足の要件定義
• 現場の協力が得られない局面
• ムダの可視化で対話が始まる転換点

この章の価値は、改善が一直線に進まない現実を扱っている点です。
業務設計は正論を示すだけでなく、利害調整を進める実務だと理解できます。

8. 本書の7章をどう読むと実装しやすいか

情報量が多い本なので、実務導入を前提に次の順で読むのがおすすめです。

1. 第1章で失敗パターンを把握する
2. 第3章・第4章で現状分析とムダ削減を学ぶ
3. 第5章でシステム適用範囲を決める
4. 第6章で改善サイクルを設計する
5. 第7章で現場実装の壁への対処を確認する

先に失敗構造を理解してから手法を読むと、打ち手の優先順位が明確になります。

分析（30%）: なぜ業務設計がDXの成否を決めるのか

1. DX失敗の本質は「プロセス負債」の放置

多くの組織は、古い業務手順の上に新システムを継ぎ足します。
この状態は、技術負債に近い「プロセス負債」を生みます。

• 同じ情報を複数回入力
• 責任境界が曖昧
• 例外対応が個人判断に依存

本書の有効性は、この負債を見える化し、返済順序を設計できる点にあります。
システム導入の前に業務を整えることで、後工程の手戻りコストを下げられます。

2. 業務設計は、属人化対策と学習速度向上を同時に実現する

属人化が問題なのは、担当者依存だからだけではありません。
改善知見が個人の頭の中に留まり、組織学習が進まない点が深刻です。

本書の手法は、暗黙知を形式知に変えることで、次の効果を生みます。

• 引き継ぎコストの低下
• 異動・退職時のリスク低減
• 新人の立ち上がり速度向上

これは採用難の時代に特に価値があります。
人の入れ替わりがあっても成果を維持できる組織は、業務設計力が高い組織です。

3. AI時代ほど「どこを人が判断するか」が重要になる

AI活用が進むほど、全自動化幻想が強まります。
しかし実務では、例外処理・倫理判断・顧客文脈の理解が残り続けます。

本書が示す「人とシステムの最適分担」は、AI時代にこそ重要です。

• 定型は機械へ
• 文脈判断は人へ
• 境界は定期見直し

この設計がないと、AI導入は現場の追加業務になります。
導入効果を出すには、業務設計が先です。

4. 本書の限界: 経営戦略レイヤーは別途補強が必要

本書は現場実装の教科書として非常に強い一方、経営戦略や組織政治の深掘りは限定的です。
たとえば、全社横断の予算配分、評価制度改定、事業ポートフォリオの再編などは射程外です。

• 現場改善には強い
• 全社変革の設計は別知見が必要

したがって本書は「現場で改善を回す中核テキスト」として使うのが最適です。
経営層向けの変革論と併読すると、実装精度がさらに上がります。

5. それでも読むべき理由

業務改善本は理想論に寄りがちですが、本書は現場の摩擦を前提にしている点が実用的です。
「正しい設計」だけでなく、「どう動かすか」まで視野に入っているため、実務での再現率が高い。

特に、DXプロジェクトに疲弊したチームほど、本書の恩恵が大きいと感じます。

6. 部門対立を減らす「共通フォーマット」の効用

本書の実務価値をさらに高めているのは、情報システム部門と業務部門の対立を、立場論ではなく設計論に変える点です。
実際の現場では、次のすれ違いが頻発します。

• 業務部門: 「現場を知らないITが机上論を言う」
• IT部門: 「要件が曖昧で開発できない」

この対立を解くには、どちらかが我慢するのではなく、同じフォーマットで会話する必要があります。
業務地図、定義シート、完了条件の明文化は、そのための共通言語になります。
本書はこの共通言語化を強く意識しているため、部門横断プロジェクトの摩擦を下げやすい構成です。

7. 「短期の非効率」を受け入れる設計思想が現実的

本書では、設計初期に発生する一時的な手間を否定しません。
可視化や定義づけには時間がかかるため、短期的にはむしろ非効率に見える局面があります。

• ヒアリング時間が増える
• 文書化の工数が増える
• 旧手順と新手順が一時並行する

しかしこのコストを払わないと、中長期の手戻りは減りません。
改善活動を「即効性」だけで評価しない姿勢は、現場運用において非常に重要です。
本書は、成果を急ぐ組織ほど必要なブレーキを提供してくれます。

実践（20%）: 属人化を減らす30日導入プラン

Day1-7: 業務の地図を作る

• 対象業務を1つに絞る（最初から全社でやらない）
• 関係者、入力、出力、判断ポイントを棚卸しする
• 手順を時系列で可視化する

最初の1週間は、改善案より現状把握を優先します。

Day8-14: ムダを特定し、優先順位を決める

• ECRS視点で工程を見直す
• 待ち時間、重複入力、手戻りを抽出する
• 影響度と実行難易度で改善順を決める

ここで「やめる仕事」を決めると、改善の初速が上がります。

Day15-21: 新プロセスを小さく実装する

• いきなり全体展開せず、1チームで試す
• 変更点を簡易マニュアル化する
• 例外処理ルールを明文化する

小規模実装で学習し、失敗コストを下げることがポイントです。

Day22-30: システム適用と改善サイクルを固定する

• 自動化対象と人判断対象を分ける
• 週次レビューで新しいムダを検出する
• 翌月の改善テーマを1つだけ決める

改善項目を増やしすぎると運用が崩れます。
毎月1改善の継続が、最終的に大きな差を作ります。

補足: 実装前チェックリスト

• 現状業務の責任者が明確か
• 出力物の完了条件が定義されているか
• 例外時のエスカレーション先が決まっているか
• 手順が特定個人の暗黙知に依存していないか

この4点を事前に確認するだけでも、改善プロジェクトの失敗率は下げられます。

補足2: 定着フェーズで見るべき3指標

改善施策は導入時だけでなく、定着段階で評価しないと元に戻ります。
本書の考え方を運用するなら、次の3指標を月次で追うのが有効です。

• 手戻り件数（再作業の発生数）
• 例外対応件数（標準手順から外れた回数）
• 引き継ぎ時間（新任者が独力稼働するまでの時間）

この3つが改善していれば、業務設計は機能しています。
逆に悪化している場合は、手順そのものか完了条件の定義を見直すべきです。

こんな人におすすめ

• DXやAI導入を進めても現場改善につながらない人
• 属人化を減らし、引き継ぎしやすい業務を作りたい人
• 業務改善を「根性」ではなく「設計」で進めたい人
• 部門間の対立を減らし、共通言語を作りたい人

逆に合わない人

• 最新ツールの比較だけを知りたい人
• 現場調査を省略して導入を急ぎたい人
• 一発で完成形を作りたい人

本書は、地道な設計と改善を積み上げる人に向いています。

まとめ

『業務設計の教科書』は、DX時代の「遠回りに見えて最短ルート」を示す本でした。

重要なのは、

• 先に業務を設計する
• その後で技術を当てる
• 最後に継続改善を仕組み化する

この順番を守ることです。

派手な施策より、再現可能な運用を作ること。
この基礎ができた組織だけが、AIやシステム導入の効果を本当に取り切れます。
「導入する力」ではなく「使いこなす力」を鍛える意味で、本書は実務担当者にとって極めて有効な一冊です。 属人化で悩む現場ほど、まずは1業務から地図化し、改善を小さく回すところから始めるのが最短です。 改善はセンスではなく設計で再現できる。その視点を実務へ移せる点が本書の強みです。 実務で効きます。