効率化する前に、その工程を疑う——ナヴァル・ラヴィカントの「最も単純に動く仕組み」
業務を効率化しようとすると、多くの会社は新しいツール、AI、テンプレート、承認システムの導入から考えます。しかし、不要な工程を残したまま処理速度だけを上げると、無駄が速く回るだけです。入力項目、会議、確認、転記、報告が増え、かえって全体像が見えにくくなることもあります。
ナヴァル・ラヴィカント（Naval Ravikant）は、2025年10月1日公開の公式Podcast「Find the Simplest Thing That Works」で、機能する複雑な仕組みは、最初から複雑に設計されるのではなく、単純な仕組みを繰り返し改善した結果として生まれると説明しています。
今回のテーマは、単に手順を減らすことではありません。要件の持ち主を確認し、不要な要件と工程を外し、本当に必要な部分だけを改善・自動化する順番です。日本の中小企業や専門サービス会社が、業務改善を小さく始める方法として整理します。
なぜ「効率化」が業務を複雑にするのか
現場の業務には、過去の事情から残った手順が少なくありません。以前の責任者が求めた報告、もう使われていない帳票、システム移行前の転記、誰が読むか分からない月次資料などです。発生した当時には理由があっても、その理由が消えた後まで工程だけが残ります。
そこでツールを入れると、古い流れがそのままデジタル化されます。紙の申請がオンライン申請になり、手入力が自動入力になっても、そもそも申請や入力が必要なのかは問われません。結果として、不要な作業を維持するための設定、権限管理、エラー対応まで増えることがあります。
業務プロセス改善の最初の問いは、「どう速くするか」ではなく、「この工程は何の結果を守るためにあるのか」です。目的を説明できない工程を最適化しても、会社全体の成果にはつながりません。
ナヴァルの主張——動く仕組みは、単純な核から育つ
ナヴァルは、複雑なシステムを最初から設計して大きくしようとすると、要素同士の関係が増えすぎて壊れやすくなると指摘します。一方、小さく動く仕組みを作り、実際の反応を見ながら改善すると、必要な複雑さだけが残ります。
ここでいう「単純」は、品質や安全を軽視することではありません。顧客との約束、法令、情報セキュリティ、品質確認など、守るべき条件は残します。そのうえで、各工程に「なぜ必要か」を説明できる状態を作ります。
以前の記事では、ナヴァルの小さなチームと直接連携の考え方を扱いました。今回は組織構造ではなく、製品や業務プロセスに入り込んだ不要な要件をどう見つけ、外すかに焦点を移します。
改善の順番は「要件→工程→最適化」
原典で紹介される順番を、日本企業の業務改善に置き換えると、次の3段階になります。
1．要件を、決めた個人までたどる
「経理が必要と言っている」「昔からこの形式だ」「本社ルールだから」と部署名や慣習で終わらせず、誰が、何の判断に使うために求めたのかを確認します。要件の持ち主が分かれば、現在も必要か、頻度や形式を変えられるかを話し合えます。
確認したいのは、出力を誰が使うか、どの判断に使うか、なくした場合に何が起きるか、法令・契約・顧客要求に基づくかの4点です。根拠が規制や契約なら、担当者の記憶だけで削らず、原文や契約条項まで確認します。
2．不要な工程を削る
要件が不要だと分かったら、そのための入力、転記、承認、保管も候補になります。ただし、いきなり恒久廃止する必要はありません。低リスクの業務なら、2週間だけ停止する、対象を限定する、報告頻度を毎週から毎月へ下げるなど、小さな実験にします。
削った後に問題が起きなければ、その工程は価値を生んでいなかった可能性があります。問題が起きた場合も、何を守る工程だったのかが具体化されるため、以前より簡潔な代替策を設計できます。
3．残った工程を、初めて速くする
必要な工程だけが残ってから、標準化、テンプレート化、担当変更、システム連携、AI活用を検討します。入力形式、完了条件、例外、責任者が明確になっていれば、自動化の失敗原因も特定しやすくなります。
AIを使う場合も同じです。ダン・マーテルのAIエージェント導入法で扱ったように、最初は候補提示や下書きに限定し、承認を経て権限を広げます。不要な工程をAIへ渡すのではなく、必要性を確認した工程だけを自動化します。
日本企業で見直しやすい3つの業務
大規模な基幹システムから始める必要はありません。まず、毎週繰り返し、関係者が少なく、止めても影響を限定できる業務を一つ選びます。
承認ルート
すべての申請を同じ人数で承認している場合、金額、個人情報、対外公開、契約変更など、失敗時の影響で分けます。低額の定型購入まで5人が確認しているなら、基準内は担当者と直属上司、高リスク案件だけ専門部署へ回す設計が考えられます。
定例報告
週報や月報の各項目について、誰が読み、どの判断に使ったかを確認します。数字を転記するだけで会議でも使われない項目は、削除または自動集計の候補です。文章報告は「事実・差異・次の判断」に絞ると、作成側と読む側の時間を減らせます。
二重入力
問い合わせ、案件管理、請求、顧客管理で同じ情報を複数回入力している場合、最初に正本となる場所を決めます。連携ツールを導入する前に、重複項目を削り、更新責任者を一人にします。入力先を整理しないまま連携すると、誤った情報まで速く広がります。
1枚でできる「工程の存在理由」棚卸し
対象業務を横に流れる図で書き、各工程について次の4項目を記録します。専用ソフトは不要で、付箋や表計算でも十分です。
成果：この業務が最後に生み出す結果は何か
工程：誰が、何を受け取り、何を出すか
理由：この工程が守っている品質・安全・判断は何か
実験：削除、頻度変更、対象限定のどれを試せるか
理由を一文で書けない工程には印を付けます。ただし、「理由が分からない」と「不要である」は同じではありません。顧客対応、会計、個人情報、安全に関わるものは、関係者や一次資料を確認してから変更します。
30日で進める業務プロセス改善
改善案を一度に全社展開せず、1業務・1指標・30日で試します。
第1週：一つの業務を可視化する
毎週1時間以上かかる定型業務を一つ選び、開始から完了までを書き出します。待ち時間、差し戻し、転記、承認も工程として含めます。改善前の所要時間と手戻り件数を記録します。
第2週：要件の持ち主を確認する
各工程について、誰が決めたか、何に使うか、今も必要かを関係者へ確認します。部署名で終わらず、判断できる個人へたどります。法令や契約が理由なら原文を確認します。
第3週：一つだけ削る
影響の小さい工程を一つ選び、対象限定または期限付きで停止します。問題が起きたときの戻し方を決め、顧客影響、品質、処理時間、問い合わせ数を観察します。
第4週：残った工程を改善する
必要性が確認できた工程だけを標準化・自動化します。導入前後の時間、ミス、手戻りを比較し、効果がなければツールや設定を増やす前に設計へ戻ります。
削ってはいけないものを、先に決める
簡素化は、統制を弱めることではありません。法令遵守、契約上の証跡、顧客への説明責任、個人情報保護、安全、品質保証などは、削除判断の対象外または専門家確認の対象として明記します。
また、一人の判断だけで削ると、別部署が使っている情報を失うことがあります。工程の持ち主だけでなく、入力する人、受け取る人、最終責任者をそろえ、小さな範囲で検証します。
これは、レイラ・ホルモジの「計画を増やす前に削る」考え方とも共通します。ただし今回は、優先目標ではなく、業務の要件と部品を一つずつ検証する点が中心です。
まとめ——速くする前に、存在理由を聞く
業務プロセス改善では、新しいツールを入れることが成果に見えやすい一方、最も大きな改善が「やめること」である場合があります。単純に動く核を見つけ、実際の結果を見ながら必要な複雑さだけを加える方が、仕組みは理解しやすく、修正しやすくなります。
まず今週、一つの定例業務について「この工程を決めたのは誰か」「何の結果を守るのか」「2週間だけ止めるなら何を測るか」を書いてみてください。答えが曖昧な工程が、最初の改善候補です。
原典
ナヴァル・ラヴィカント公式Podcast「Find the Simplest Thing That Works」（2025年10月1日公開）
原典では、単純な仕組みを反復して育てること、要件を疑ってから部品を減らし、最後に最適化する順番が説明されています。イーロン・マスク（Elon Musk）の製造工程の事例も、不要な要件が部署間の思い込みで残る危険を示すものとして紹介されています。
海外の業務改善事例を、自社の判断材料へ
海外企業の業務設計、AI活用、組織運営の事例を、自社の課題に合わせて調べたい方は、アシーマの海外情報リサーチをご覧ください。一次資料を確認し、導入判断に使える形へ整理します。
コメント