# タスク: 一つの仕事を人とAIが協働するための資料にまとめる 必要な成果から、タスク、役割、引継ぎ条件、確認方法をつなぎます。 ## 準備するもの 繰り返し発生する実際の仕事を一つ選び、目標と成果要件、利用権限のある入力資料、現行手順、関係する役割、既知の例外を、出典・版・不足事項とともに用意します。 ## 作成する成果 成果を支える関係、完結するタスク、役割の責任、引継ぎ条件の草案を作成します。AIが支援する動作、検収方法、例外時の引継ぎも整理します。 ## 確認する方法 入力、出力、担当者、完了基準を確認します。資料が揃う場合、不足・矛盾・範囲外の場合を試行し、人の確認、手戻り、未解決事項を記録して業務成果まで検証します。 ## 適用条件 仕事の根拠と試行計画を整理する読書経路です。すべての役割に通用する方法を保証しません。一つの役割が複数の完結するタスクを担い、業務が部門をまたぐ場合もあります。タスク完了と経営成果は別々に確認します。 入力、条件、出典、版を確認し、不足資料は未提出として記録します。創作で埋めません。 目標、予算、権益、権限、最終判断のうち人の確認が必要な事項を示します。 ## 原文と版 - モデル: 四方向SOP：業績・業務・職能タスク・動作をどうつなぐか | R1 | https://yutengfei.com/ja/journal/four-way-sop/ Markdown: https://yutengfei.com/ja/journal/resources/four-way-sop.md 具体的な仕事が支える業務成果と経営成果を確認します。 - 方法: 四方向SOPの使い方：業績から業務、人材、毎日の仕事を整理する | R1 | https://yutengfei.com/ja/journal/four-way-sop-practical-guide/ Markdown: https://yutengfei.com/ja/journal/resources/four-way-sop-practical-guide.md 一つの業務を完結するタスクと具体的な動作に分解します。 - 方法: 職務・職責の分析から役割別業務マニュアルへ：協働する人が貢献の仕方を理解するために | R1 | https://yutengfei.com/ja/journal/co-builder-role-handbook/ Markdown: https://yutengfei.com/ja/journal/resources/co-builder-role-handbook.md 役割の責任を明確にし、複数のタスクを業務手順書にまとめます。 - モデル: フローを次へ進める前に、何を引き渡すのか？ | R1 | https://yutengfei.com/ja/journal/process-handover-and-entry-conditions/ Markdown: https://yutengfei.com/ja/journal/resources/process-handover-and-entry-conditions.md 引継ぐ成果物、次段階への条件、検収責任を確認します。 - 方法: SOP から Skill へ：AI が支援できる仕事と、その成果の確かめ方 | R1 | https://yutengfei.com/ja/journal/sop-to-ai-skill/ Markdown: https://yutengfei.com/ja/journal/resources/sop-to-ai-skill.md AIが支援する部分を選び、入力、検収、例外時の引継ぎを定めます。 - 方法: SOPは最後まで実行したのに、なぜ業績につながらないのか？ | R1 | https://yutengfei.com/ja/journal/sop-business-outcome-diagnosis/ Markdown: https://yutengfei.com/ja/journal/resources/sop-business-outcome-diagnosis.md 実際の成果から、動作、協働、経営仮説の問題を区別します。 ## 関連Skill この経路にインストール可能なSkillは付属しません。資料を読んだり取得したりしても、Skillの導入、AIツールの接続、実行の許可にはなりません。Skill化する場合は形式、ツール、権限を確認し、試行と検収を行います。 ## 結果とずれ、知識や手順の修正点を記録します。 バージョン: V1.0 · 2026-11-05 https://yutengfei.com/ja/journal/pathways/sop-human-ai/ --- 必要な資料と節を選び、全資料を無差別に投入しないでください。 出力資料も元のライセンスと第三者資料の表示に従います。取得により改変・商用利用・学習用の追加権限は付与されません。 --- # 四方向SOP：業績・業務・職能タスク・動作をどうつなぐか - 著者: Andrew David W.Y. - 出典: https://yutengfei.com/ja/journal/four-way-sop/ - 版: R1 - 公開: 2026-11-04 - 改訂: 2026-11-04 - 公開状態: 全文公開 - コンテンツの種類: モデル (models) - 研究テーマ: ステークホルダー資本ガバナンス (stakeholder-governance) - エコシステムの視点: 運営エコシステム (operations) · リソースエコシステム (resource) ## この資料の使い方 **用途**: 顧客への成果と経済的成果を起点に、主要な業務、完結するタスク、具体的な動作をつなぎます。四方向SOPは、下位の仕事へと展開し、上位の成果へと照合できる支援関係を示します。一つの仕事をなぜ行うのかを理解し、手順を終えた後に何を検証する必要があるかを組織で確認するためのモデルです。 **利用条件**: 対象、目的、制約が今回の課題に合うか確認し、本文に明記されていない条件は別途確認してください。 **モデル · 要素、関係、仮定** **根拠と検証の範囲**: 事例は四方向SOPの展開方法を示します。活用を評価する際は、後続工程で成果物を使えるか、顧客と経済面の成果に変化があるかを確認してください。 この記事には外部検証の結果を別途登録していません。公開だけで有効性が確認されたとはいえません。本文の根拠、仮定、限界を確認してください。 これは読解・引用用の知識資料で、インストール済みの Skill ではありません。AI で利用する際も出典と限界を残し、出力を確認してください。 ## 本文 見積もりは送ったのに、顧客からなかなか確認が返ってこない。営業は見積もりを済ませたと言い、購買は供給条件を伝えたと言う。見積担当者も表に沿って計算している。全員に完了記録はあるのに、案件は先へ進んでいません。 こうしたとき、私は、誰の仕事が終わっていないのかと急いで問う必要はないと思います。先に確認したいのは、顧客がどの問題を解決したいのか、この見積もりはその要望に応えているのか、約束した条件で履行できるのか、ということです。すでに終えた仕事は、結局どの成果を支えているのでしょうか。 四方向SOPで整理したいのは、具体的な仕事と経営成果の関係です。SOPを業績、業務、職能タスク、動作という四つの階層に分けます。設計時は成果から下位の仕事へと展開し、運用後は動作から上位の成果へと照合します。この関係をたどることで、なぜその仕事を行うのか、どこまで仕上げるのか、他の人の仕事とどうつなぐのかを、具体的に問い直せます。 ## 一、四つの階層で、四つの問いに答える SOPは一般に標準作業手順を意味します。ここで取り上げる四方向モデルは、範囲や細かさの異なる作業手順を分類する方法です。一つの仕事について必ず四つの文書を作るという意味でも、四階層の組織を設けるという意味でもありません。 | 階層 | 中心となる問い | 主に確認すること | 簡単な例 | | --- | --- | --- | --- | | 業績SOP | 顧客への価値は、企業の経済的成果にどうつながるか | 顧客との関わりが強い主要な段階と成果 | 要望の確認から履行、代金回収までの受注案件の流れ | | 業務プロセスSOP | 主要な段階を進めるために、どのようなプロセスを組むか | 複数のタスクが連携して生み出す業務成果 | 履行可能な見積もりを作成する | | 職能タスクSOP | 担当職や役割として、どの一つのタスクを完結させるか | 入力、処理、出力、完了基準を備えたタスク | 一件の見積金額を算定する | | 動作SOP | そのタスクを具体的にどう行うか | 準備、操作、点検、例外対応、引き継ぎの要件 | 数量と価格算定単位を照合する | **業績SOPは、顧客への成果と経済的成果を起点にします。** 受注業務なら、要望の確認、提案と見積もりの確認、契約条件の明確化、履行と検収、精算と代金回収といった主要な段階を整理できます。業務によって順序、分岐、並行関係は異なります。一つの模式的な流れを、あらゆる企業に共通する固定の経路にはできません。 業績を成約件数だけで見ることもできません。顧客が納品物やサービスを受け入れたか、企業が代金を回収したか、必要なコストを賄えているかによっても、成果の判断は変わります。まず対象とする業績チェーンの範囲、観察期間、成果の定義と集計基準を明確にし、それに合う記録を選ぶ必要があります。 **業務プロセスSOPは、一つの業務成果を生み出すために仕事を組みます。** 顧客に見積もりを確認してもらうには、要望の整理、供給条件の確認、見積金額の算定、権限を持つ担当者による確認が必要かもしれません。業務プロセスSOPは、これらの仕事をつなぎ、次の段階で使える成果を作ります。一つの部門が担当する場合も、部門や組織をまたいで協働する場合もあります。 **職能タスクSOPは、一つのタスクを完結させる手順に対応します。** ここでの「職能」は、見積金額の算定、請求書の発行、納期の確認など、担当職や役割が引き受ける一つの仕事を指します。「経理部」「購買部」といった職能部門でも、一つの職務の全責任でもありません。タスクが完結しているかは、どの条件で始まり、何を処理し、何を引き渡し、どう完了を確認するかで判断します。 **動作SOPは、タスクを実行できる説明に落とし込みます。** たとえば見積金額を算定するなら、まず確認済みの要望の版を読み、数量と価格算定単位を照合し、承認された価格算定ルールに従って計算します。その根拠と未決事項を記録し、最後に見積計算書を提出します。誤りが起きやすい箇所、引き継ぎが必要な箇所、明確なリスクがある箇所では、作業基準と例外対応を明記します。慣れている動作の一つ一つを、長い解説にする必要はありません。 横にスクロールするか、図を大きく開いて確認できます。 [![四方向SOPの階層ごとの支援関係。下位へ展開して必要な仕事を明確にし、上位へたどって成果の根拠を照合します。](https://yutengfei.com/journal/four-way-sop/materials/ja/01-four-layer-support.svg)](https://yutengfei.com/journal/four-way-sop/materials/ja/01-four-layer-support.svg) 図1：四つの階層は、仕事の範囲と支援関係を表します。矢印は説明と検証が必要な関係を示しており、下位の仕事が完了すれば上位の成果が必ず得られるという意味ではありません。 [図を大きく開く ↗](https://yutengfei.com/journal/four-way-sop/materials/ja/01-four-layer-support.svg)[編集可能な SVG をダウンロード ↓](https://yutengfei.com/journal/four-way-sop/materials/ja/01-four-layer-support.svg) ## 二、下位へ展開し、本当に必要なプロセスを見つける 整理は、実際の一つの業務から始められます。まず、顧客がどこで選択し、企業がどこで約束をし、納品やサービス提供と支払いをどう実現するのかを確認します。その中から主要な段階を一つ選び、どの成果が必要で、どのタスクが共同でその成果を生み出すのかを掘り下げます。 「提案と見積もりの確認」を例にします。顧客に見積もりが届いただけでは、この段階が成立したとはいえません。見積もりは確認済みの要望に応える必要があります。根拠となる供給条件、納品・提供条件、取引条件を照合できることも必要です。既存の承認範囲を超える条件については、適切な決定権者の判断が必要です。社内でどの仕事を組むかは、こうした条件をどう満たすかを考えて決めます。 さらに下位を見ると、「履行可能な見積もりを作成する」という業務プロセスには、要望の整理、供給条件の確認、見積金額の算定、権限を持つ担当者による確認といったタスクが含まれます。それぞれに出力があり、他のタスクとの接点があります。要望の整理は「話はした」というだけでは完了にできず、照合に使える要望の記述を引き渡す必要があります。供給条件の確認も「たぶん在庫がある」では足りません。何を確認し、どの範囲で有効なのかを示す必要があります。 次に、「見積金額を算定する」という一つの職能タスクを選びます。入力には、確認済みの要望、有効な供給条件、現在適用される価格算定ルールなどがあります。出力としては、計算が正しく、版と計算根拠を明示した見積計算書を作成し、その後の確認に使うことが考えられます。計算を進められなくする不足事項は、先に差し戻して確認します。計算を妨げない後続の確認事項は、計算書に併記できます。ただし顧客への約束に関わる未決条件は、約束をする前に解決しなければなりません。この階層まで整理してから、具体的な操作や動作をさらに説明します。 一段下へ展開するたびに、**追加する仕事は、上位で必要な成果を生み出すためにどう役立つのか**を答える必要があります。説明できなければ、そのタスクが不要なのかもしれません。上位の目標が曖昧なのかもしれませんし、両者の間に必要なプロセスが抜けているのかもしれません。文書番号を付けるだけでは、仕事同士をつなげられません。 横にスクロールするか、図を大きく開いて確認できます。 [![一件の見積もりで四階層のSOPをつなぐ例。受注案件の主要な段階を、業務プロセス、完結するタスク、作業要件へと展開します。](https://yutengfei.com/journal/four-way-sop/materials/ja/02-quotation-expansion.svg)](https://yutengfei.com/journal/four-way-sop/materials/ja/02-quotation-expansion.svg) 図2：架空の受注業務の例です。「提案と見積もりの確認」を支える関係の一部だけを展開しています。実線の矢印は模式的な流れ、破線は一部分の詳細への展開を示します。実際の業務では、並行処理、分岐、やり直しが生じることがあります。 [図を大きく開く ↗](https://yutengfei.com/journal/four-way-sop/materials/ja/02-quotation-expansion.svg)[編集可能な SVG をダウンロード ↓](https://yutengfei.com/journal/four-way-sop/materials/ja/02-quotation-expansion.svg) ## 三、上位へ照合する。動作の完了を業績の実現とみなさない 下位の仕事を明確に分けるだけでなく、上位へ照合できることも必要です。 価格算定単位の照合が終わっても、満たしたのは一つの作業要件にすぎません。見積金額の算定が終われば、タスクの要件を満たす計算書ができたことを意味します。要望、供給条件、権限などを合わせて確認して初めて、顧客に提示できる見積もりができる可能性が生まれます。顧客が受け入れるか、その後に履行と代金回収ができるかは、引き続き確認する必要があります。 そのため、四つの階層を単純な成果の等式で表すことはできません。適切に行われた複数の動作はタスクの完結に必要な条件を整え、複数のタスクは業務成果を支え、複数の業務プロセスは業績チェーンを前へ進めます。それでも、市場の変化、顧客の選択、製品の適合性、リソースの制約、経営判断は最終結果に影響します。 顧客が見積もりを受け入れなければ、まず顧客の反応と、その業績チェーンに関する記録を見ます。問題は対応時間、要望の理解、見積もりの誤りにあるかもしれません。一方で、製品が合わない、納期が条件を満たさない、価格に競争力がない、顧客の調達計画が変わった、といった可能性もあります。問題の所在を確認してから、業務上の連携、個別のタスク、操作要件を変えるのか、製品と市場について改めて判断するのかを決めます。対処が必要な階層だけを展開すればよく、毎回四階層をすべてたどる必要はありません。 四方向SOPは、こうした関係をたどって問いを深め、根拠をさかのぼって確認する助けになります。ただし、一枚の階層図だけで原因を証明することはできません。業績が想定に届かなかったことを、そのまま特定の人の実行不足に帰することもできません。 ## 四、組織と関係はあるが、組織図には収まらない 実際の仕事では、四つの階層が会社、部門、職務、個人に一対一で対応するとは限りません。一人が複数の職能タスクを担当することも、一つの業務で複数の役割が協働することもあります。同じ「納期確認」というタスクが、新規の見積もりや受注後の変更など、異なる業務に使われることもあります。 そのため、SOPを整理するときは、二つの関係を同時に残します。一つは、そのタスクがどの成果を支えるか。もう一つは、誰が必要な責任、権限、リソースを持つかです。前者は仕事の論理を示し、後者は誰が仕事を組み、実行するかを示します。両者は関係していますが、互いの代わりにはなりません。 共通して使うタスクでは、版と適用範囲も管理する必要があります。たとえば供給条件が更新されたとき、どの見積もりが引き続き有効で、どれを再確認する必要があるでしょうか。同じタスクを複数の文書に複製し、参照元を管理していないと、手順どおりに作業していても根拠が食い違うことがあります。 企業を、リソース、運営・ガバナンス、顧客、資本という四つの参加関係（四つのエコシステム）から見ると、参加者は自ら貢献を提案することも、具体的な需要に応えることもできます。少人数の運営・ガバナンスの中核が意思決定とルールの整備を担い、価値を生み出す活動、販売チャネル、顧客関係を調整します。価値を生み出す役割の担当者は、対応するタスクを通じて業務に参加し、役割別の業務マニュアルを手がかりにこれらの手順を使います。購入・利用のみを行う顧客や、投資のみを行う投資家は、それぞれに対応する手順に沿って参加します。その二つの立場だけを理由に、共同で価値を生み出す役割の業務マニュアルを用意する必要はありません。 ここで説明しているのは、仕事をどうつなぐかです。貢献をどう評価し、権利や利益をどう取り決めるかについては、実際の業務に合わせて別途ルールを定める必要があります。タスクの完了記録から自動的に導けるものではありません。 ## 五、まず一つの流れで検証し、その後に広げ方を決める このモデルを使うために、会社全体の文書整理から始める必要はありません。実在し、繰り返し発生し、成果を観察できる業務の流れを一つ選び、まず三つのことを行います。 第一に、その流れで顧客にどの成果をもたらし、どの経済的成果を得るのか、省けない条件は何かを明確にします。第二に、主要な段階を一つ選び、必要な業務プロセスと完結するタスクへと展開し、入力、出力、責任、検収の根拠をつなぎます。第三に、実際の業務の進行を追い、不足、待ち時間、やり直し、顧客の反応を記録して、どの操作をさらに標準化するかを判断します。 十分に習熟し、安定していて、引き継ぎも簡単な仕事なら、簡潔な手引きだけで足りるかもしれません。新規業務、要望が頻繁に変わる仕事、判断への依存が大きい仕事では、先に目標、判断条件、フィードバックの方法を明確にし、手順を少しずつ蓄積します。四階層をそろえるためだけに記入や承認を増やすと、かえって業務の妨げになりかねません。 研修や設備保全などの支援業務も、一件の成約に直接対応するとは限りません。複数の業績チェーンを支えたり、より長い期間の能力やリスクに影響したりします。その支援関係を説明するには、相応の記録と判断が必要です。個々の動作に無理に売上を割り当てることはできません。 プロセスアプローチには、すでに研究の蓄積があります。ISOによるISO 9001:2015のプロセスアプローチの技術資料も、プロセス間の入力、出力、接点、責任、点検を重視し、組織の状況とリスクに応じて必要な文書を定めることを勧めています。\[1\] 本稿の四方向モデルは、四つの観察階層を用いて、顧客への成果と経済的成果から具体的なタスクや動作まで問いを掘り下げるためのものです。実際の業務での適用性は、引き続き検証する必要があります。 一度の試行が役立ったかを判断するには、参加者が自分の引き渡す成果はどこを支えるのか説明できるか、次の段階でその成果を使えるか、問題が起きたときに対応する記録を見つけられるかを確認できます。引き継ぎの不足、やり直し、待ち時間が減ったかも観察する価値があります。ただし、業務量や要望の複雑さなどの変化も同時に記録する必要があります。結果が改善しても、一度の試行だけでモデルの効果だと断定することはできません。 四方向SOPの価値は、最終的には仕事と成果の関係を互いに説明できるかに表れます。下位へ展開するときには、何を組み立てる必要があるかを理解する。上位へ照合するときには、何を引き渡せたか、何がまだ成立していないかを理解する。この関係を実際の業務に戻して繰り返し検証することで、手順を継続して使える方法へと育てる余地が生まれます。 ## 出典と関連資料 このモデルは、著者から提供された初期研究資料『SOP梳理设计方法论』（SOP整理・設計方法論）、特に第2、4、5節に基づきます。版の記録には、2023年3月9日の研修に伴う調整と、2023年5月11日に杨婧が参加して行った基礎理論・モデルの構築が記載されています。本稿は四階層の関係を改めて説明し、図も本稿のために独自に再構成したものです。過去の図にあった評価・分配の仕組みは引き継いでいません。文中の見積業務は架空の例です。 \[1\] ISO/TC 176/SC 2, _The Process Approach in ISO 9001:2015_, N1289, 1、4–5ページ。[公式技術資料](https://www.iso.org/iso/iso9001_2015_process_approach.pdf)。ここではプロセスアプローチを参照しています。四方向の分類をISOの要求事項とするものでも、本稿のモデルが認証を受けているとするものでもありません。 関連資料：[繁・簡・易・図：ビジネスの論理を設計するための考え方 (中国語)](https://yutengfei.com/zh/journal/fan-jian-yi-tu/)；[企業計画の10ステップ：方向性、リソース、実行をつなぐ (中国語)](https://yutengfei.com/zh/journal/enterprise-planning-ten-steps/)。 ## 関連資料 - [四方向SOPの使い方：業績から業務、人材、毎日の仕事を整理する](https://yutengfei.com/ja/journal/four-way-sop-practical-guide/) - [SOPは最後まで実行したのに、なぜ業績につながらないのか？](https://yutengfei.com/ja/journal/sop-business-outcome-diagnosis/) [CC BY-NC-ND 4.0](https://creativecommons.org/licenses/by-nc-nd/4.0/) 別途明記された場合を除き原文の文章に適用し、第三者の素材は対象外です。ダウンロードや機械による読み取りは既存の許諾を拡張せず、派生物、商用利用、モデル学習を別途許可するものではありません。 [AI 利用ガイド](https://yutengfei.com/ja/journal/ai/) --- # 四方向SOPの使い方：業績から業務、人材、毎日の仕事を整理する - 著者: Andrew David W.Y. - 出典: https://yutengfei.com/ja/journal/four-way-sop-practical-guide/ - 版: R1 - 公開: 2026-11-04 - 改訂: 2026-11-04 - 公開状態: 全文公開 - コンテンツの種類: 方法 (methods) - 研究テーマ: ステークホルダー資本ガバナンス (stakeholder-governance) - エコシステムの視点: 運営エコシステム (operations) · リソースエコシステム (resource) · 顧客エコシステム (customer) ## この資料の使い方 **用途**: 一つの業績の流れを起点に、業務、リソースと協力先、職責、日々の動作を順に整理します。架空のブランドデザイン会社を例に、起業時の収益経路の検証、人材の確保と育成、人とAIの協働に使える仕事の方法を、四方向SOPでどう支えるかを説明します。 **利用条件**: 対象、目的、制約が今回の課題に合うか確認し、本文に明記されていない条件は別途確認してください。 **方法 · 手順、入力、完了条件** **根拠と検証の範囲**: 事例は四方向SOPの展開方法を示します。活用を評価する際は、後続工程で成果物を使えるか、顧客と経済面の成果に変化があるかを確認してください。 この記事には外部検証の結果を別途登録していません。公開だけで有効性が確認されたとはいえません。本文の根拠、仮定、限界を確認してください。 これは読解・引用用の知識資料で、インストール済みの Skill ではありません。AI で利用する際も出典と限界を残し、出力を確認してください。 ## 本文 企業は何によって業績を生み出すのか。どの業務が必要なのか。どのような人を探し、その人たちは毎日何をすればよいのか。 これらの問いは、一緒に考えられます。 私が初期に四方向SOPを研究したのも、これらをつなぐためでした。まず企業が業績を生み出す主要なプロセスを見つけ、その流れに沿って、業務、職能タスク、具体的な動作を一段ずつ整理します。すでに事業を営んでいる企業なら、現在の業務を点検するために使えます。起業したばかりなら、収益を得るいくつかの可能性を分析し、何から始めるかを決めるために使えます。 私はこの関係を、**業績SOP、業務プロセスSOP、職能タスクSOP、動作SOP**という四つの方向に分けています。 SOPは標準作業手順を意味します。ここでは四つの方向を使い、経営成果から具体的な仕事までの関係をつなぎます。 業績から下位の仕事へと見るときは、「この成果を得るために、どの仕事を組む必要があるか」に答えます。動作から上位へと見るときは、「この仕事は、最終的にどの成果を支えるのか」に答えます。 四つの全体構造を先に確認したい方は、[四方向SOPのモデル紹介](https://yutengfei.com/ja/journal/four-way-sop/)をお読みください。今回は、企業でどのように使うのかを、もう少し具体的に説明します。 図は本文の幅で表示されます。大きな図も開けます。 [![四方向SOPの実践経路。業績、業務、職能タスク、動作の順に、収益の経路、資源とパートナー、職責と人材、日々の仕事を明確にし、実践のフィードバックで上位へ確認する。](https://yutengfei.com/journal/four-way-sop-practical-guide/materials/ja/01-practice-map.svg)](https://yutengfei.com/journal/four-way-sop-practical-guide/materials/ja/01-practice-map.svg) 図1：一つの業績の経路から必要な仕事を各層に展開し、実践のフィードバックで上位へ確認する。四層は仕事の範囲であり、組織の四階層ではない。残した方法は人とAIの協働を支えるが、権限、設定、成果の検証が必要となる。 [大きな図を開く ↗](https://yutengfei.com/journal/four-way-sop-practical-guide/materials/ja/01-practice-map.svg)[編集可能なSVGをダウンロード ↓](https://yutengfei.com/journal/four-way-sop-practical-guide/materials/ja/01-practice-map.svg) ## 一、まず企業が業績を生み出す主要なプロセスを見つける SOPを整理するとき、私はまずこう問います。この企業の顧客は誰か。何を提供し、なぜ顧客は代金を払うのか。企業はどのように納品やサービス提供を完了し、収益を得るのか。 これらを明確にすると、業績SOPの主な流れが見えてきます。 初期の研究では、「顧客開拓、見積もり、契約締結、代金回収」という簡単な例を使いました。これらの段階を業績SOPに置いたのは、いずれも顧客との関わりが強く、一件の取引が成立するかどうかに関係するからです。実際に使うときは、業務に応じて要望の確認、納品・提供、検収など、必要な条件を加えます。 **業績SOPのプロセスは、業績を実現するうえで重要な要素によって構成する必要があります。** ここからは、架空のブランドデザイン会社を例に説明します。プロジェクト型の業務の一つは、まず次のように書けます。 要望のある顧客を見つける → 要望とサービス範囲を確認する → 提案と見積もりを出す → 協働と支払いの取り決めを確認する → デザインの納品と検収を完了する → 合意どおりに精算する。 これは事業運営の主な流れです。どの段階にも、明確に説明できる成果が必要です。「顧客を見つける」では、適切な顧客なのかをさらに確認します。「要望を確認する」では、双方が理解できる範囲を残します。「デザインを完成させる」では、納品物が取り決めを満たしているかを確認します。 主な流れを描くと、経営者はどこに目を向ければよいかを見つけやすくなります。顧客候補は多いのに成約しないなら、要望、提案、見積もりを見ます。契約したのに納められないなら、制作と納品を見ます。納品したのに入金されないなら、検収と精算の条件を見直します。 同時に、何を業績として観察するのかも明確にします。契約締結、売上、売上総利益、入金は、それぞれ定義や集計基準が異なり、混同できません。一つの企業が、製品、サービス、顧客の種類に応じて、複数の業績SOPを持つこともあります。 ## 二、起業時は収益を得るいくつかの可能性を描いてみる 安定した業務がまだない企業でも、この方法を使えます。 起業したばかりの時期には、いくつかの構想があるものです。同じブランドデザイン会社でも、プロジェクト単位のデザイン、継続的なコンテンツ制作、デザイン研修を考えているかもしれません。これらに必要な顧客、リソース、仕事の組み方は同じではありません。 まず、それぞれの業績SOPを簡単に描けます。 - プロジェクト型のデザイン：案件の顧客を見つけ、範囲と見積もりを明確にし、協働の取り決めを結び、デザインを納品し、検収と精算を行う。 - 継続サービス：継続的な要望のある顧客を見つけ、各期のサービス内容と料金の取り決めを明確にし、協働を取り決め、定期的に納品、検収・精算、フィードバックを行い、その後も継続するかを判断する。 - デザイン研修：受講者と学習上の要望を明確にし、講座を設計し、受講者の募集、申し込み、受講料の徴収を行い、研修を実施し、学習成果とその後の要望を確認する。 描いた後は比較できます。今あるリソースに最も近いのはどの経路か。まだ遂行する能力がないのはどの段階か。顧客は実際に代金を払う意思があるのか。最初に何を投入する必要があるのか。先に検証すべき条件は何か。 こうすると、「ほかにもいろいろできる」という話から、「まずどの業務を実現するか」という話に進めます。 まだ行ったことのない業務について、私は業績SOPを検証前の構想として扱います。まず試せる条件のある経路を一つ選び、実際の顧客と接し、小さな範囲で納品やサービス提供を行い、その反応から調整します。図を描くことで問題を早めに見つけられますが、判断を検証するのは実際の業務です。 ## 三、業績SOPが明確になると、業務とリソースを見つけやすくなる 業績SOPは、どの主要な成果を実現する必要があるかを示します。次に、その成果を得るためにどの業務を行うかを考えます。 たとえば「デザインの納品を完了する」は、業績SOPでは一つの段階に見えます。しかし、その背後には、要望の調査、創作とデザイン、コンテンツの整理、制作物の点検、顧客とのやり取りなどがあるかもしれません。これらのプロセスを組み、顧客が使える成果を生み出すことが、業務プロセスSOPの扱う内容です。 **業務プロセスSOPでは、どのように価値を生み出し、次の段階へ引き渡すかを考えます。** 要望の調査では、デザインに使える根拠を引き渡します。デザインでは、要件を満たす案を引き渡します。制作物の点検では、ファイルが実際に使えることを確かめます。各段階を終えたとき、次の段階が受け取って使えるものが必要です。 業務プロセスが明確になると、必要なリソースも具体的になります。 顧客調査には、インタビューと分析の能力が必要です。デザインには、デザイン能力、素材、ツールが必要です。撮影、印刷などの制作を伴うなら、それに合う設備、技術、供給能力も必要です。すでに持っているもの、補う必要のあるもの、協力先を探すとよいものを、業務に沿って一つずつ判断できます。 協力先を探すときの問いも明確になります。相手はどの部分の能力を提供できるか。何を成果として納めるか。どの基準で協働するか。今ある仕事とどうつなぐか。 一つの業務プロセスを社内チームで担うことも、外部の協力先と進めることもできます。必要な価値と協働の関係を先に説明し、それからどの組織が引き受けるかを決めると、本当に必要なリソースを見つけやすくなります。 ## 四、業務を明確にしてから、職能タスクと職責を整理する 業務プロセスSOPができたら、その中のタスクを整理し、職能タスクSOPに展開できます。 たとえばデザイン業務では、要望を確認する人、デザインする人、制作ファイルを点検する人、納品を取りまとめる人が必要です。それぞれのタスクが必要とする入力、負う責任、引き渡す成果を、さらに明確にできます。 ここでの「職能」は、担当職や役割が完了させる一つの仕事を指します。一つの職が複数の職能タスクを担うことも、一つの業務を複数の職で共同して進めることもあります。 これらのタスクをまとめると、職責を分析できます。その役割はなぜ必要なのか。普段何を担当し、誰と協働し、どのような能力を備える必要があるのか。 これは、人を探すとき、能力を判断するとき、育成するときのいずれにも役立ちます。 人を探すときは、実際のタスクから要件を定められます。たとえば必要なのは、顧客の要望をデザインの根拠として整理できる人なのか、特定の種類のデザインを完成させられる人なのか、それとも複数人で納品する仕事を取りまとめられる人なのか。要件が違えば、探す方向も違います。 能力を判断するときは、そのタスクに関係する作品を見たり、進め方を聞いたり、実際に課題に取り組んでもらったりして、問題の理解、リソースの使い方、成果の納め方を確認できます。職種名が同じでも、実際に担える仕事は大きく異なる場合があります。 育成するときも、具体的な不足を見つけられます。要望を十分に聞き取れていないのか。ツールに習熟していないのか。それとも納品前の点検が足りないのか。不足をタスクと動作に落とし込めば、それに合う練習を組み、その後の仕事で進歩を確かめられます。 人員配置も業務に応じて変えられます。起業時は、一人が複数の役割を兼ねても構いません。業務が増えたら、仕事量、専門性、協働上の必要に応じて分けます。四方向SOPは、まずどの仕事が必要かを説明し、それからどのような人と組織が必要かを判断するために役立ちます。 ## 五、職能タスクを展開すると、毎日の動作が明確になる 職能タスクSOPは何を完了させるかを明確にし、動作SOPはそれをどう行うかをさらに説明します。 たとえば「顧客の要望を整理する」は、インタビューの質問を準備する、顧客からの情報を記録する、未確定の内容を照合する、要望の記述をまとめる、確認を終える、デザイン工程へ引き渡す、と展開できます。 抜けや誤りが起きやすい箇所では、基準も明記します。どの情報が必須か。どの版の資料を使うか。何をもって引き継げると判断するか。不足があったら誰に補ってもらうか。 そして、これらを日々の仕事に戻して、四つの属性から見ます。 - **日常のタスク**：継続的に行う通常業務。たとえば顧客からの問い合わせの確認、案件記録の維持。 - **定期のタスク**：決められた間隔で行う仕事。たとえば毎週の案件進捗の整理、毎月のサービス状況の振り返り。 - **工程起点のタスク**：SOPが所定の段階に進み、その条件が満たされたときに発生する仕事。たとえば要望の確認後にデザインへ進む、案の承認後に納品を準備する。 - **依頼起点のタスク**：他の人からの依頼や割当を受けて入ってくる仕事。たとえば顧客からの変更依頼、協力先からの支援要請。 「依頼起点」は仕事の入り方を表しており、本人の主体性を評価するものではありません。複数の属性が重なる場合もあります。顧客からの変更依頼は、他の人から受け取る仕事であると同時に、変更処理のフローを開始するきっかけにもなります。 これらを明確にすると、その役割を担う人は、普段何を行うか、時期が来たら何を行うか、どの状況になったら何を行うか、他の人からの依頼を受けたらどう扱うかが分かります。 さらに、適用するSOP、ツール、納品基準、協働の関係を業務マニュアルにまとめれば、新しい人には学習の入口ができ、経験のある人には共通の根拠ができ、仕事も引き継ぎやすくなります。 ## 六、蓄積したSOPは、AIが企業の仕事を理解するための資料にもなる この整理は、人にもAIにも価値があります。 AIに「提案を作って」とだけ伝えても、業務の背景が多く抜けています。顧客は誰か。どの段階を進める提案なのか。必要な資料は何か。誰が成果を使うのか。どの条件は勝手に決めてはいけないのか。こうしたことが明確でないかもしれません。 四方向SOPは、その背景をつなげられます。業績SOPは仕事の目的、業務プロセスSOPは協働のプロセス、職能タスクSOPは具体的なタスク、動作SOPは作業方法と基準を示します。 要望の整理を例にすると、使用を許可された資料、適切な要望整理のひな形、点検要件をAIに渡し、情報の整理や不足事項の指摘を支援してもらい、責任者が確認するための初稿を作れます。顧客への確認が必要な内容や、対外的な約束に関わる判断も、フローの中に明確な位置を設けておきます。 実務で使ってきたSOPは、AIが参照・利用できる知識、タスクの説明、Skillとして、さらに整理できます。うまくいった方法に加え、実際に起きた例外、失敗の理由、調整の記録も残す価値があります。 私が重視するのは、もう少し先のことでもあります。AIの能力が今後も発展するにつれ、企業が今日蓄積している仕事の方法は、AIが実際の業務を理解し、参加するための重要な資料になると考えています。そこには、単なる操作手順だけでなく、企業が仕事を行う目的、関係、条件、経験が含まれています。 ファイルをAIに渡しただけで、AIが習得したことにはなりません。フローが自動的に動くわけでもありません。どの部分を担えるかは、ツールの能力、使用権限、成果の検証によって変わります。それでも、この基礎が明確であるほど、その後の人とAIの協働には根拠ができます。 ## まず、成果を確かめられる一つの業務から始める 実際に使うときは、一枚の紙に業績SOPを一つ書くところから始められます。 主要な段階を一つ選び、必要な業務プロセスを展開します。その業務からタスクと責任を取り出し、最後に繰り返し行う動作、基準、タスクの発生条件を明記します。 実際の業務を一度行い、振り返ります。主要な成果は実現したか。リソースは足りたか。誰の仕事がうまくつながらなかったか。どの動作を変える必要があるか。最初に考えた仕事のうち、実は不要だったものはあるか。 業績が想定に届かなかったときも、上位に戻って考え直せる余地を残します。顧客の要望、製品、価格、リソース、外部環境は変わり得ます。フローの記録は問題の所在を見つける助けになりますが、具体的な原因はさらに確かめる必要があります。 初期の『SOP整理・設計方法論』にも、試行、フィードバック、改善の反復を形成過程に組み込んでいました。今も、この段階は大切だと思います。フローを書いた後も、実際の仕事で役立つものへと変え続ける必要があります。 **企業が何によって業績を生み出すのか、業務がどう価値を生むのか、どのリソースと人材が必要か、一人ひとりが毎日どう仕事を進めるか。これらは、同じ関係をたどって一つずつ明確にできます。** 四方向SOPで企業を支援したいのは、こうしたことです。まず一つの業務から始め、内容を明確にし、有効だった方法を残していく。そのために使ってほしいと思います。 ## 研究の根拠と関連資料 本稿は、初期の研究資料『SOP整理・設計方法論』にある四方向モデル、職責、仕事の分類、試行と改善の反復に関する内容を基に、起業時の事業、リソースの協働、人材育成、AI活用についての現在の考えを加えて整理したものです。登場するブランドデザイン会社は、方法を説明するための架空の例であり、検証済みの経営成果を示すものではありません。初期資料の「作業SOP」などの呼び方は、本稿では「動作SOP」に統一しました。タスク属性には、現在の表現である「日常、定期、工程起点、依頼起点」を使っています。 - [四方向SOPのモデル紹介](https://yutengfei.com/ja/journal/four-way-sop/) - [職責の分析から役割ごとの業務マニュアルへ](https://yutengfei.com/ja/journal/co-builder-role-handbook/) - [役割ごとのタスクは、どのようにフローに入るのか](https://yutengfei.com/ja/journal/role-task-entry/) - [SOPからSkillへ](https://yutengfei.com/ja/journal/sop-to-ai-skill/) ## 関連資料 - [四方向SOP：業績・業務・職能タスク・動作をどうつなぐか](https://yutengfei.com/ja/journal/four-way-sop/) - [SOPは最後まで実行したのに、なぜ業績につながらないのか？](https://yutengfei.com/ja/journal/sop-business-outcome-diagnosis/) [CC BY-NC-ND 4.0](https://creativecommons.org/licenses/by-nc-nd/4.0/) 別途明記された場合を除き原文の文章に適用し、第三者の素材は対象外です。ダウンロードや機械による読み取りは既存の許諾を拡張せず、派生物、商用利用、モデル学習を別途許可するものではありません。 [AI 利用ガイド](https://yutengfei.com/ja/journal/ai/) --- # 職務・職責の分析から役割別業務マニュアルへ：協働する人が貢献の仕方を理解するために - 著者: Andrew David W.Y. - 出典: https://yutengfei.com/ja/journal/co-builder-role-handbook/ - 版: R1 - 公開: 2026-11-04 - 改訂: 2026-11-04 - 公開状態: 全文公開 - コンテンツの種類: 方法 (methods) - 研究テーマ: ステークホルダー資本ガバナンス (stakeholder-governance) - エコシステムの視点: 運営エコシステム (operations) · リソースエコシステム (resource) ## この資料の使い方 **用途**: 業務に必要な成果から考え、職責の分析を、価値を生み出す役割の業務マニュアルにつなげます。タスク、条件、権限、成果物、協力関係を明確にし、要件整理の協力者という仮の例を通じて、実際のタスクでの使い方と試行後の改訂を説明します。 **利用条件**: 対象、目的、制約が今回の課題に合うか確認し、本文に明記されていない条件は別途確認してください。 **方法 · 手順、入力、完了条件** **根拠と検証の範囲**: 実際の業務で手引きを試し、責任、作業の起点、成果物の条件を確認してから、試行の反応を踏まえて改訂します。 この記事には外部検証の結果を別途登録していません。公開だけで有効性が確認されたとはいえません。本文の根拠、仮定、限界を確認してください。 これは読解・引用用の知識資料で、インストール済みの Skill ではありません。AI で利用する際も出典と限界を残し、出力を確認してください。 ## 本文 ある事業に参加したいという人がいる。では、何から始めればよいのでしょうか。 「要件を整理してください」「コンテンツづくりを手伝ってください」と伝えるだけでは、相手はすぐに具体的な疑問に直面します。誰に話を聞くのか。どの資料を使えるのか。どこまで仕上げれば渡せるのか。意見が分かれたら、誰に判断してもらうのか。 社内でも同じことが起こります。職務や職責を書き、業務の流れを図にしていても、担当者が替わると、前の担当者が何度も説明しなければならないことがあります。 私は、役割別業務マニュアルには、責任を引き受けた後でどう仕事を進めるかを明確にする役割があると思っています。参加する人には、自分が何を貢献できるのか、どのような条件が必要なのか、ほかの人とどう仕事をつなぐのかが分かる必要があります。 ## 一、この仕事が支えるべき成果を先に考える マニュアルを書く前に、実際の業務を一つ選び、今どのような成果が必要なのかを確認します。 例えば、企業が事業紹介資料をつくろうとしているとします。まず必要なのは、原稿作成やデザインを始めるための、確認済みの要件書かもしれません。どの顧客に向けたものか、どの場面で使うのか、顧客に何を理解してもらう必要があるのかも明確にします。 「今、誰の手が空いているか」から分担を決めると、その場限りの割り振りが、長期的な職責として書き込まれやすくなります。既存の職名だけを起点に内容を埋めていくと、業務に本当に必要なのに、まだ誰も担っていない仕事を見落とすこともあります。 初期の研究資料『SOP梳理设计方法论』（標準作業手順〈SOP〉の整理・設計方法論）では、業務プロセス、職務、具体的な動作、基準、引き継ぎを結び付け、試行してから改善することを求めていました。この考え方を今につなげるなら、まず必要な成果を見定め、現在の仕事がそれをどう支えているかを確認できます。うまく機能している分担は残し、職責の重複、引き継ぎの抜け、実施条件の不足については、改めて話し合います。\[1\] ここでは、二つの段階の成果を分けて考えます。要件書の確認が済むことは、一つの納品・引き渡しの完了です。それによって資料が分かりやすくなったか、顧客の判断に役立ったかは、その後の業務で観察する必要があります。マニュアルが十分に書かれ、期限内にタスクを終えたとしても、それだけで経営成果が改善したとは言えません。 ## 二、役割、担当する人、今回のタスクをそれぞれ明確にする 職務分析は、仕事を理解する出発点になります。チームや組織をまたいで協力する場合は、その中で比較的独立して担える貢献を、役割として説明することも必要です。 ここでいう「価値貢献の役割」とは、どの種類の貢献と責任を引き受けるかについての合意です。例えば「要件整理の協力者」は、要件を集めて確認し、後の工程で使う要件確認書をまとめる役割を担えます。条件が合えば、社内の従業員も、社外の専門パートナーも、この役割を担えます。 | 区分 | 答えるべき問い | 要件整理の例 | | --- | --- | --- | | 役割 | 継続してどのような貢献を担うのか。その範囲はどこまでか。 | 事業紹介資料の制作要件を集め、確認し、整理する | | 人 | 必要な能力、時間、参加条件を備えているのは誰か。 | 今回は社内の同僚、または社外の協力者が担当する | | タスク | 今回は具体的に何を提出し、誰が引き受け、誰が受入確認をするのか。 | 合意した期限内に、あるプロジェクトの要件確認書を提出する | 一人が複数の役割を担うことも、同じ役割を複数人で担うこともできます。ただし、タスクごとに、引き受ける人、協力する人、受入確認をする人を明確にしなければなりません。「要件整理の役割が担当する」とだけ書いても不十分です。複数人で担う場合は、それぞれの範囲も示し、全員が「ほかの人が処理したはず」と思い込まないようにします。 資源、運営・管理、顧客、資本という四つのエコシステムは、参加関係を捉えるための視点です。役割の仕事を、四つのエコシステムごとに機械的に一組ずつ用意するわけではありません。どのような立場の参加者も、自ら貢献を提案でき、具体的な要望に応じることもできます。少人数で機能する運営・管理チームは、該当する意思決定とルール、価値の生産、販売チャネル、顧客関係の調整を担います。個々の事項を誰が決めるかは、実際の権限付与に基づいて明確にする必要があります。 業務マニュアルは、実際に引き受ける価値貢献の役割に対応させます。購入・利用のみを行う顧客は、購入、利用、フィードバック、アフターサービスなどの手順で参加します。投資のみを行う人は、該当する投資や情報共有の手順で参加します。この二つの立場であるという理由だけで、協働のための業務マニュアルを求めることはありません。別途、製品の共創、専門的な調査研究、その他の明確な貢献の役割を担う場合に、その役割のマニュアルを使います。\[2\] 横にスクロールするか、図を大きく開いて確認できます。 [![図一：業務に必要な成果を先に定め、貢献の役割を明確にし、マニュアルをつくり、一つのタスクに落とし込む。](https://yutengfei.com/journal/co-builder-role-handbook/materials/ja/01-result-role-handbook.svg)](https://yutengfei.com/journal/co-builder-role-handbook/materials/ja/01-result-role-handbook.svg) 図一：矢印は、本稿で提案する整理の順序を示しています。一人が複数の役割を担えますが、タスクごとに引き受け方を別途明確にします。この例は、効果が検証されたことを意味しません。 [図を大きく開く ↗](https://yutengfei.com/journal/co-builder-role-handbook/materials/ja/01-result-role-handbook.svg)[編集可能な SVG をダウンロード ↓](https://yutengfei.com/journal/co-builder-role-handbook/materials/ja/01-result-role-handbook.svg) ## 三、一冊のマニュアルで八つの問いに答えられるようにする 職責の説明では、まず「何を担うか」を明確にできます。業務マニュアルには、それに加えて、どう始め、どう対処し、どう終えるのかを利用者に伝える必要があります。 次の八つの問いを、初版をつくる際のチェックリストとして使えます。分量は仕事の複雑さに合わせます。目次を埋めるためだけに、内容を増やす必要はありません。 | 答えるべき問い | マニュアルに含める内容 | | --- | --- | | なぜこの役割が必要なのか。 | 誰のための仕事か、支える業務成果、役割の範囲 | | 自分が担う仕事は何か。 | 主な職責、タスクが入ってくる経路、ほかの役割との分担 | | 始めるには、どのような条件が必要か。 | 必要な資料、能力、時間、ツール、アクセス権限 | | 通常はどのように仕事を進めるのか。 | 重要な手順と、関連する適用可能なSOP、テンプレート、事例 | | 自分で何を決められるのか。 | 自分で確認・処理できる事項と、誰の判断を仰ぐべき事項 | | 何を引き渡し、何をもって合格とするのか。 | 成果物、品質要件、受入確認の方法、受け取る役割 | | 不足や変更があったら、どうするのか。 | 記録方法、連絡先、補充・調整・一時停止を判断するための窓口 | | このマニュアルを誰が維持・更新するのか。 | 管理担当者、版、適用範囲、発効日、変更方法 | 職責は、ほかの人が具体的な仕事をイメージできる程度まで書きます。「要件管理を担当する」では、まだ広すぎます。「制作目的、使用場面、内容の範囲を確認し、要件確認書をまとめ、情報源と未確認事項を明記する」とすれば、何をするかが分かります。 基準も、仕事に即したものである必要があります。事実確認が必要な仕事なら、どの情報に出典が必要で、どの不足が先に進む妨げになるのかを示します。「責任感を持つ」「迅速かつ効率的に行う」といった言葉だけで、要件を置き換えてはいけません。探索的な仕事では、方法を選ぶ余地を残し、答えるべき問い、必要な根拠、話し合う節目を明確にします。すべての手順を固定する必要はありません。 SOP（標準作業手順）と役割別業務マニュアルは、相互に参照できます。マニュアルは役割を起点に、どのような場合にどの手順を使うかを伝えます。SOPは一つの仕事を起点に、関係する役割、手順、基準を示します。共通の手順は、有効な版を一つだけ維持し、マニュアルから参照します。複数の場所へコピーした後、それぞれが別の内容に変わっていく問題を減らすためです。 ## 四、実際の仕事から内容を集め、ほかの人に試してもらう 初版は、すでに行ったタスク、またはこれから始めるタスクを一つ選ぶところから着手できます。 実際の担当者に、次のことを説明してもらいます。仕事はどこから来るのか。最初にどの資料を見るのか。どの判断に経験が必要なのか。通常は誰に確認するのか。最後に何を誰へ渡すのか。そのうえで、前工程と後工程の担当者にも確認してもらいます。担当者自身は完了したと思っていても、後工程が本当に受け取って使えるかは、ここで初めて分かることがあります。 整理する際は、内容を三つの状態に分けます。確認済みのやり方、試行を予定している取り決め、まだ決まっていない問題です。昔から続けているからといって、それが妥当な基準とは限りません。新しく提案されたよい方法も、実際に使ってみる必要があります。 次に、基本的な能力はあるものの、その仕事には不慣れな協力者を選び、マニュアルを使って、範囲を管理できるタスクを試してもらいます。初回は助言する人が付いてもかまいません。同時に、どこで手が止まったか、何の追加説明が必要だったか、どの入力資料がそもそも手に入らなかったかを記録します。 こうした問題が出たら、まずマニュアルと仕事を進める条件を確認します。説明が不明確なのか、タスクが能力を超えているのか。手順に抜けがあるのか、権限、資料、時間が用意されていないのか。原因を確かめてから、研修の追加、分担の変更、条件の調整、マニュアルの改訂を判断します。 仕事の不確実性がまだ高い場合は、簡潔な役割説明とタスク票で進め、実施しながら記録する方法もあります。無理に最初から固定手順へまとめると、利用者がすでに成り立たなくなった前提に従って仕事を続けてしまうことがあります。 ## 五、「要件整理の協力者」を例に、初版を埋めてみる 以下は、企業の事業紹介資料づくりを想定した仮の例です。方法の使い方を示すもので、特定のプロジェクトですでに得られた効果を示すものではありません。 **役割の目的**：原稿作成とデザインの担当者が、どう仕事を進めるかを判断できる程度まで制作要件を整理し、使用場面、内容の範囲、事業に関する事実を何度も推測する手間を減らします。 **開始条件**：プロジェクト責任者が、制作目的、伝える相手、おおよその範囲を明確にしていること。使用可能な既存資料を提供し、事業に関する事実を誰が確認するかを決めていること。今回のタスクでは、提出期限、投入できる時間、受入確認者を別途合意します。 **主な仕事**：まず、誰が資料を見るのか、どの場面で使うのか、相手に何を理解し、どのような行動を取ってもらいたいのかを確認します。次に、事業内容と表現上の要件を整理し、重要な記述の情報源を確認します。意見の相違や不足事項を一覧にし、権限を持つ人に確認を求めます。 **成果物**：要件確認書を一つ作成します。少なくとも、使用場面、対象者、内容の範囲、重要な事業上の事実と情報源、納品仕様、確認済み事項、未確認事項、それぞれの責任者を含めます。具体的な期限、確認状況、適用する版は、今回のタスクとともに記録します。 **権限と協力関係**：協力者は、質問し、資料を整理し、表現方法を提案できます。事業範囲、製品に関する約束、価格、公開時期などは、該当する権限を持つ人が確認します。整理担当者が文書に書いたというだけで、未決定事項を企業の約束に変えることはできません。 **受入確認と受け取り**：受入確認者は事実と範囲を確かめ、原稿作成とデザインの担当者は、仕事を始める条件が整っているかを確認します。不足が一部の内容にしか影響しない場合は、確認済みのうちどの部分を先に進めるかを明確にできます。全体の方向性に影響する不足なら、先に補うか、改めて判断します。「ファイルを提出した」という事実だけで、どこまで使えるかの判断を済ませてはいけません。 **例外への対応**：資料同士が矛盾する、使用場面が変わる、追加要望が当初の範囲を超えるといった場合は、問題とその影響を記録し、該当する責任者に、補充、調整、一時停止、中止のいずれにするかを判断してもらいます。新しい範囲と期限は、再確認が必要です。協力者が自ら改善を提案することもできますが、実際の行動には相応の権限と条件が必要です。 **完了と引き継ぎ**：最終確認書と必要な根拠を保存し、後工程の担当者に未決事項、制約、版を伝えます。担当者が替わる場合は、未完了のタスク、ファイルの保管場所、アクセスに関する取り決めを引き継ぎます。 こうすれば、参加者は「要件整理を手伝ってほしい」という一言だけを受け取るわけではなくなります。自分に引き受ける条件があるかを判断でき、始めた後でどう仕事を進めればよいかも分かります。 ## 六、タスクで使い始めた後も、調整できるようにする タスクの開始時には、双方で範囲、条件、期限、受入確認の段取りを確認します。実施中は、適用する版に従って進め、不足を見つけたら早めに伝えます。終了時には、引き渡しと後工程での受け取り状況を確認し、マニュアル自体の問題を管理担当者にフィードバックします。 受入確認に通らなかった事項は、何を補い、何をやり直すかを明示し、対応後に再確認します。意見が分かれた場合は、あらかじめ合意した責任者または再確認を担う人が対応します。一時停止した事項は未処理の状態を保ち、再開が必要になった時点で条件を再確認します。中止した事項は、後処理を終えてから終了します。小さなチームでは一人が複数の役割を兼ねられますが、重要な約束や利益相反のある事項については、実際のルールに沿って再確認を行う必要があります。 マニュアルの改訂にも根拠が必要です。一度限りの特別な対応は、まず例外として記録できます。同じ問題が繰り返される、または業務条件が変わった段階で、共通のやり方を変えるか判断します。新版には、変更内容、適用範囲、発効日を明記します。未完了のタスクをどう引き継ぐかも説明し、旧版は後で確認できるよう残します。 横にスクロールするか、図を大きく開いて確認できます。 [![図二：役割別業務マニュアルを、タスクの引き受け、実行、受入確認、フィードバックに使う。例外は権限を持つ人が判断し、必要に応じて改訂を検討する。](https://yutengfei.com/journal/co-builder-role-handbook/materials/ja/02-handbook-in-use.svg)](https://yutengfei.com/journal/co-builder-role-handbook/materials/ja/02-handbook-in-use.svg) 図二：提案する運用の仕組みです。例外対応後に仕事を続ける場合は、条件を再確認します。改訂版は、発効の確認が必要です。成果物が基準を満たすか、後工程で使えるか、業務成果が変わったかは、それぞれ分けて観察します。 [図を大きく開く ↗](https://yutengfei.com/journal/co-builder-role-handbook/materials/ja/02-handbook-in-use.svg)[編集可能な SVG をダウンロード ↓](https://yutengfei.com/journal/co-builder-role-handbook/materials/ja/02-handbook-in-use.svg) マニュアルが役立っているかは、具体的な問いで確かめられます。新しい参加者は、何から始めればよいか、以前より分かるようになったか。重要な問題を早く見つけられたか。説明ややり直しが減ったか。後工程が受け取りやすくなったか。試行の前後では、できるだけ似たタスクについて、範囲、複雑さ、担当者の経験を記録します。タスクが簡単になったことや、担当者が習熟したことも結果に影響します。改善をすべてマニュアルのおかげとすることはできません。 マニュアルには、引き渡しや貢献の記録として、どのような根拠を残すかを定められます。報酬、費用、権利・利益とその条件は、実際の業務に関する契約や制度に基づき、別途確認します。「マニュアルに沿ってタスクを終えた」ことから、自動的に導かれるものではありません。\[2\] AIは、適用できる内容の検索、既存資料の整理、確認書の下書きを手伝えます。マニュアルに沿って、記載漏れを指摘することもできます。ただし、誰が事実を確認し、どの事項を誰が決め、誰に結果を渡すかは、引き続き明確にしておく必要があります。再利用できる手順をSkillというAI向けの実行ガイドにまとめる場合も、適用範囲、入力と出力、人が判断する範囲を明確にする必要があります。 今、何度も説明が必要になっている役割を一つ選びます。実際のタスクを使い、目的、条件、仕事、権限、成果物を書き出します。次に担当する適切な人に使ってもらい、その人が直面した問題に合わせて修正する。そこから、マニュアルを実務で使い始められます。 ### 根拠と関連する読み物 \[1\] 初期研究資料『SOP梳理设计方法论』（SOPの整理・設計方法論）。主に、3〜4ページの職責と業務マニュアルの関係、6〜9ページの文書内容、職務調査、試行、改善を参照しました。資料末尾には、2023年の版と協働の記録が残されています。本稿におけるエコシステムで協働する役割、役割とタスクの区別、試行の提案は、それらの資料を基に今回発展させたものです。過去の職責・プロセス研究図二点は、元の関係を確認するためだけに使い、当時の評価や権利・利益の取り決めは引き継いでいません。 \[2\] [『四つのエコシステムのガバナンスモデル：貢献、権利・利益、協働の循環』](https://yutengfei.com/zh/journal/four-ecology-governance-model/)（中国語）では、参加関係、貢献と権利・利益、事項ごとの権限を論じています。本稿は、役割別業務マニュアルでどう仕事を組織するかをさらに考えるもので、共通の分配方式をあらかじめ定めるものではありません。 [『企業計画の十段階：方向、資源、実行をつなぐ』](https://yutengfei.com/zh/journal/enterprise-planning-ten-steps/)（中国語）は、業務目標と協力の条件を理解する際の参考になります。[『一度の取引の後、企業には何が残るのか』](https://yutengfei.com/zh/journal/after-transaction-business-accumulation/)（中国語）では、経験が次の仕事にどう生かされるかを、引き続き考えられます。 本稿は、実務での検証を待つ方法の提案です。異なる企業での効果を検証した結果は示していません。図と仮の例は、仕組みを説明するためのものです。 ## 関連資料 - [フローを次へ進める前に、何を引き渡すのか？](https://yutengfei.com/ja/journal/process-handover-and-entry-conditions/) - [日常・定期・工程起点・依頼起点：役割のタスクを業務フローにつなぐには](https://yutengfei.com/ja/journal/role-task-entry/) - [一つの業績チェーンから、企業エコシステムの再設計をどう始めるか](https://yutengfei.com/ja/journal/performance-chain-ecology-transformation/) - [SOPは最後まで実行したのに、なぜ業績につながらないのか？](https://yutengfei.com/ja/journal/sop-business-outcome-diagnosis/) [CC BY-NC-ND 4.0](https://creativecommons.org/licenses/by-nc-nd/4.0/) 別途明記された場合を除き原文の文章に適用し、第三者の素材は対象外です。ダウンロードや機械による読み取りは既存の許諾を拡張せず、派生物、商用利用、モデル学習を別途許可するものではありません。 [AI 利用ガイド](https://yutengfei.com/ja/journal/ai/) --- # フローを次へ進める前に、何を引き渡すのか？ - 著者: Andrew David W.Y. - 出典: https://yutengfei.com/ja/journal/process-handover-and-entry-conditions/ - 版: R1 - 公開: 2026-11-04 - 改訂: 2026-11-04 - 公開状態: 全文公開 - コンテンツの種類: モデル (models) - 研究テーマ: ステークホルダー資本ガバナンス (stakeholder-governance) - エコシステムの視点: 運営エコシステム (operations) · リソースエコシステム (resource) ## この資料の使い方 **用途**: 前のプロセスからの引き渡し、受入れ判断、次のプロセスの開始条件を分けて考える。引き継ぎで問題が起きたときの対応と、共通目標が個々の「完了」にどう関わるかを説明する。 **利用条件**: 対象、目的、制約が今回の課題に合うか確認し、本文に明記されていない条件は別途確認してください。 **モデル · 要素、関係、仮定** **根拠と検証の範囲**: 事例は分析と手順を示すためのものです。実務では例示の条件を実際の業務記録に置き換え、判断と結果を確認してください。 この記事には外部検証の結果を別途登録していません。公開だけで有効性が確認されたとはいえません。本文の根拠、仮定、限界を確認してください。 これは読解・引用用の知識資料で、インストール済みの Skill ではありません。AI で利用する際も出典と限界を残し、出力を確認してください。 ## 本文 営業が顧客の要望を見積担当者に渡し、タスクも「完了」にした。ところが見積担当者が資料を開くと、数量、納期、使用条件がまだ確認されておらず、改めて関係者に問い合わせることになる。前の担当者は確かに仕事をした。それでも、次の担当者は着手できない。 同じことは、企画からデザイン、デザインから制作、開発からテストへの引き継ぎでも起こる。企業と仕入先、販売パートナー、顧客の間でも起こる。 私が気になるのは、前の工程で生まれた成果が、次の工程で本当に使える出発点になっているか、ということだ。 ここを明確にして初めて、フロー図の矢印に実際の意味が生まれる。 ## 1\. まず二つを分ける。引き渡しが合格なら、次も始められるのか？ 一つの業務フローは、互いに関係する複数のプロセスから成る。それぞれに目的があり、業務全体に何らかの結果をもたらす。その結果は製品、企画書、データかもしれないし、確認済みの要件や一つの決定かもしれない。 ISOのプロセスアプローチの解説では、プロセスを、インプットを使って意図した結果を生み出す相互に関連した活動の集まりとして捉え、プロセス間のインプット、アウトプット、相互依存を重視している。本稿もこの基本的な考え方に立ち、日常の引き継ぎに使う実務モデルを提案する。[プロセスアプローチの解説（英語）](https://www.iso.org/iso/iso9001_2015_process_approach.pdf) 共通目標から出発し、次の順序で考える。**前のプロセスが成果を生み出す → 次のプロセスの必要条件と照合する → 受入れ判断を明確にする → 開始条件を確認する → 次のプロセスに進む。** ここでは二つのことを分けて見る必要がある。 一つ目は、渡された成果が取り決めを満たしているか。要件は確認済みか、図面は現行版か、データに出典はあるか、成果物は取り決めた範囲に収まっているか。「この引き渡しを、仕事に使えるか」を判断する。 二つ目は、次のプロセスを始める条件が整っているか。担当者は引き受けられるか、必要な材料や資源は揃っているか、関連する決定は確認済みか。「今、始められるか」を判断する。 図面に問題がなくても、材料が届いていなければ制作には入れない。その場合は「引き渡しは受入れ済み、制作は開始待ち」と記録し、材料の問題を処理する。待ち時間をすべて設計担当者に差し戻しても解決しないし、図面を受け入れたからといって制作まで開始済みにしてはいけない。 横にスクロールするか、図を大きく開いて確認できます。 [![図1：引き渡した成果を次のプロセスの出発点にする条件。引き渡し内容の確認と開始条件の確認は分けて行う。受入れは、自動的に開始を意味しない。](https://yutengfei.com/journal/process-handover-and-entry-conditions/materials/ja/01-handover-to-next-process.svg)](https://yutengfei.com/journal/process-handover-and-entry-conditions/materials/ja/01-handover-to-next-process.svg) 図1：共通目標と制約は、すべての工程に関わる。矢印は引き継ぎと判断の順序を示すものであり、顧客への履行や経済的な成果がすでに実現したことを示すものではない。 [図を大きく開く ↗](https://yutengfei.com/journal/process-handover-and-entry-conditions/materials/ja/01-handover-to-next-process.svg)[編集可能な SVG をダウンロード ↓](https://yutengfei.com/journal/process-handover-and-entry-conditions/materials/ja/01-handover-to-next-process.svg) ## 2\. 何を渡すかは、次の工程での使い道から書く 「要望の整理は完了」「企画書は提出済み」。これだけでは、受け取り方が分かれやすい。 次に見積もりをするなら、少なくとも何を、いくつ、いつ納めるのか、どの条件が確認済みで、どこがまだ見込みなのかを知る必要がある。次に行うのが初期案の作成だけなら、一部の情報は未確定でもよいかもしれない。ただし仮定を明記し、まだ判断できないことを示しておく。 同じ資料でも、使う工程が変われば適用する基準も変わりうる。だから引き継ぎの要件は、着手前に関係者で確認する。業務の途中で本当に条件が変わった場合は、取り決めに沿って調整する。受け入れる側が引き渡しの直前になって、合意していなかった要件を次々に追加してよいわけではない。 まずは、次の六つを明確にするとよい。既存のタスク票、文書の説明欄、システムの項目に書けばよく、分厚い書式を新しく作る必要はない。 | 明確にすること | 引き継ぎ時に答えられること | | --- | --- | | 用途と範囲 | どのプロセスで使い、どの判断に役立て、どこまでを対象にするか | | 成果とバージョン | 成果物はどこにあり、現行版はどれで、いつ作成されたか | | 確認の根拠 | 重要な事実を何によって確認したか。出典と必要な確認記録はどこにあるか | | 受入れ基準 | 何を満たせば受け入れられるか。どの版の基準を使うか | | 引き受ける人と期限 | 誰が提出し、誰が確認し、誰がその後を担当するか。いつまでに返答するか | | 未確定事項と対応 | 何が未確認で、何に影響し、誰がいつまでに補うか、または決めるか | 成果と根拠も分けておく。やり取りの記録から、ある条件を話し合ったことは確認できる。しかし、その条件が確定したとは限らない。AIが作った企画書が一見完成していても、そこに書かれた価格、仕様、納期の正確さや有効性まで証明されるわけではない。 受け取った人が、これを根拠に何ができるか、何をまだ確かめる必要があるか、どこまで使うと再確認が必要になるかを読み取れることが大切だ。 ## 3\. 誰が確認するのか。「検収をお願いします」だけでは足りない 提出する側は、まず取り決めに沿って自分で確認する。受け入れる側は、自分の仕事に必要なインプットを確認する。専門的な判断、対外的な約束、当初の権限を超える事項は、相応の権限を持つ人に確認してもらう。 小さなチームでは、一人が複数の役割を兼ねてもよい。それでも、判断の根拠と責任は明確にする。重要な事項に明らかな利益相反がある場合は、適切な再確認を別途手配する。通常の、低コストで修正しやすい引き継ぎには、簡単な確認や抜き取り確認で対応できる。リスクや修正コストが高い工程には、その分の確認を加える。どの工程にも何段階もの承認を要求し、元の問題以上に協力のコストを増やすべきではない。 受入れ判断は具体的に書く。例えば「要件表V2は見積入力基準との照合済み。仕様と数量は試算に使用できる。確定納期は供給側の確認待ちであり、これを根拠に顧客へ約束してはならない」。これなら「受け取りました」「問題ありません」より、その後の仕事を進めやすい。 「受領」は資料が届いたことを示す。「受入れ」は、指定された範囲の引き渡し内容が確認を通過したことを示す。「開始」は、次の工程の実際の条件も整ったことを示す。タスク管理システムで使うステータスは違ってもよいが、参加者がこの違いを見分けられるようにしたい。 返答期限も決めておく。期限を過ぎても返答がなければ、催促と調整に進む。無回答を合格扱いにはしない。受入れを断る場合も、満たしていない基準と具体的な不足を示す。理由のない待ち時間や繰り返しを減らす責任は、双方にある。 ## 4\. 次へつながらないときは、まず問題の種類を見る 引き継ぎに問題が起きると、「差し戻してやり直す」が選ばれやすい。しかし、渡された成果そのものに原因がなければ、やり直しても解決しない。 まず三つに分けて考えられる。 **成果に不足がある。** 取り決めた仕様が抜けている、重要なデータを確認できない、文書のバージョンが一致しない、といった場合だ。具体的な不足と影響を示し、担当者が補足または修正してから、有効な基準に照らして再検証する。すでに合格し、影響も受けていない部分まで、すべてやり直す必要はない。 **基準や権限について認識が分かれている。** 例えば「確認済み」の意味が双方で違う、または当初は権限のなかった納期を約束する必要がある場合だ。まず元の取り決めに戻る。必要なら権限を持つ役割が、適用する基準、範囲、責任を決める。受け入れる人が個人の考えで条件を追加してもいけないし、提出する人が進捗を急ぐために他人に代わって約束してもいけない。 **業務条件が変わっている。** 顧客の要望や供給能力が変わった、あるいは次の工程の資源が一時的に不足した場合などだ。まず影響範囲を見極め、関係する役割が、資源の追加、範囲や日程の調整、一時停止、関連業務の終了のいずれを選ぶか決める。成果自体は合格でも、当面使えなくなることはある。 横にスクロールするか、図を大きく開いて確認できます。 [![図2：引き継ぎの問題を三つに分けて対応する。対応後も継続する事項は再検証に戻す。一時停止した事項は、再開条件の確認が必要になる。](https://yutengfei.com/journal/process-handover-and-entry-conditions/materials/ja/02-exception-and-revalidation.svg)](https://yutengfei.com/journal/process-handover-and-entry-conditions/materials/ja/02-exception-and-revalidation.svg) 図2：問題を分類するのは、適切な対応先を見つけるためだ。成果の修正、基準の解釈、業務条件の調整には、それぞれ担当と責任がある。すべてを実行力不足にまとめてはいけない。 [図を大きく開く ↗](https://yutengfei.com/journal/process-handover-and-entry-conditions/materials/ja/02-exception-and-revalidation.svg)[編集可能な SVG をダウンロード ↓](https://yutengfei.com/journal/process-handover-and-entry-conditions/materials/ja/02-exception-and-revalidation.svg) 本当に必要であれば、明確な範囲に限って条件付きで受け入れることもできる。例えば内部試算を先に進めながら、不足する確認情報を補う場合だ。そのためには相応の権限が必要で、何をしてよいか、何をしてはいけないか、補完期限、条件を満たせなかった場合の停止や差し戻しの方法を明記する。これらが確認されても、限定的に行う作業のインプットと開始条件を、改めて確認する必要がある。 条件付き受入れでも、必須要件を飛ばすことはできない。決定権がない、結果を制御できない、または先に終えるべき必要な確認が残っている場合は、関連する行動を一時停止する。停止中も担当者を置き、どの条件が整えば再開するか、いつ再確認するかを示す。すでに負っている履行、費用、事後対応の責任は、引き続き取り決めに沿って処理する。ステータスを「一時停止」にしても消えない。 ## 5\. 見積もりの引き継ぎで、モデルの使い方を見る 以下は、モデルを説明するために作成した架空の場面であり、特定企業の実際の記録ではない。 顧客が、まとまった数量の特注設備を求めた。要件の調整担当者は、資料を見積責任者へ渡す。事前の取り決めでは、正式見積もりには確認済みの仕様、数量、納入先、希望納期が必要で、未解決事項も記載することになっている。 最初の提出では、仕様と数量は確認できていたが、納入先はまだ二つの候補があった。見積責任者は不足を指摘し、この状態では輸送費を確定できないと伝える。要件の調整担当者はその後、納入先を確認してV2を提出し、旧版と変更内容も残した。 V2を確認すると、見積もりに必要なインプットは取り決めを満たしていた。ただし、供給側はまだ生産能力を確認していない。ここも分けて考える。社内の原価試算は始められる。一方、確定納期を入れた正式見積もりを顧客に出す条件は、まだ整っていない。 権限を持つ責任者は、限定された範囲で内部試算を先に進めることを認めた。タスク記録には、生産能力の確認担当者、期限、顧客に納期を約束してはならないという制限を記載する。関連するインプットと資源を再確認した後、内部試算を開始する。 その後、供給側から希望納期を満たせないと連絡があれば、関係する役割が顧客と調整内容を確認する。顧客が仕様を変えた場合は、影響を受ける試算と資料を特定し、新版に基づいて改めて確認する。「V2は受入れ済み」という判断をそのまま使って、対外見積もりを続けてはいけない。 この例では、資料の不足、後工程が引き受けるための条件、対外的な決定を分け、一部の作業を先に進める余地を残している。しかし、最終的な成約を保証するものではない。一度の引き継ぎが順調だっただけで、フロー全体が業績を高めたと証明することもできない。 ## 6\. 共通目標は、個々の「完了」にも関わる 営業は早く進めたい。見積担当者は資料を揃えてほしい。供給側は条件を安定させたい。いずれにも実際の理由がある。共通目標は、同じ案件について関係者が取捨選択を話し合うためにある。顧客は何を解決したいのか。時間、コスト、品質、履行条件をどう両立させるか。どの約束はしてはいけないか。 全員の利害が同じである必要はない。また、共通目標を理由に、誰か一方へ際限なく仕事を追加してよいわけでもない。追加作業、待ち時間、やり直しにはコストがかかる。誰が負担し、元の取り決めを超えたときに誰が決めるかを明確にする。 このような引き継ぎは、資源、運営管理、顧客、資本という四つのエコシステムのいずれでも起こりうる。異なる役割は自ら貢献することも、要請に応じることもできる。具体的な事項は、業務上の関係と権限に沿って扱う。少数精鋭の運営管理チームは、関係する意思決定、ルール、調整を担い、価値の生産、販売チャネル、顧客関係をつなぐ。すべての専門的役割に代わって判断するわけではない。 このモデルが扱うのは、成果の引き渡しと、それを引き受けることだ。引き渡しの記録は後の評価に事実を提供するが、貢献のすべてを示すものではない。報酬、持分、配当、決定権が自動的に生じるものでもない。制度上の権利や利益は、実際の業務と相応の取り決めに基づき、別途扱う必要がある。 使い始めるときは、問題が繰り返される引き継ぎを一つ選べばよい。資料の不足、待つ理由、やり直し、確認コスト、顧客への履行への影響を記録する。試行後に、どの確認が役立ったか、どの基準が重すぎたか、問題の担当者を以前より早く見つけられたかを見る。比較対象や十分な記録がなければ、まず観察結果を残し、原因を急いで決めつけない。 案件が最終的に期待どおりにならなかった場合も、顧客のニーズ、製品と価格、履行、販売チャネル、入金など、業績につながる一連の流れから問題を探す。その後で、業務、職務機能、具体的な作業動作のどのレベルのSOPを調整するか決める。引き継ぎはその一部であり、すべての経営結果を説明できるものではない。 フローを次へ進める前に、引き渡しを通じて受け取る人に伝えたいのは、今これを根拠に何ができるか、まだ何をしてはいけないか、状況が変わったら誰に対応を求めるか、ということだ。これらの条件がつながって初めて、フローが実際にどこまで進んだか分かる。 * * * ### 出典と関連資料 - モデルの基礎：初期のチーム資料『SOP梳理设计方法论（SOPの整理・設計方法論）』。主に6〜9ページの前提タスク、次工程への移行、引き継ぎ、例外対応、試行、改善を参照した。初期の「職務責任、業務マニュアル、SOP、業績評価」の関係図2点から、「前工程の結果を検証する」という研究の手掛かりを得た。本稿の引き継ぎと例外対応の仕組みは再構成した実務モデルであり、その効果は具体的な業務での検証を要する。 - 概念の参考：[ISO: The process approach in ISO 9001:2015（英語）](https://www.iso.org/iso/iso9001_2015_process_approach.pdf)。プロセスのインプット、アウトプット、相互依存を説明するために参照した。本稿は規格条文の解説や認証ガイドではない。 - [企業計画の10ステップ：方向性、資源、実行をつなぐ（中国語）](https://yutengfei.com/zh/journal/enterprise-planning-ten-steps/)：目標と資源配分から、相互依存する協力の約束を理解する。 - [四つのエコシステムのガバナンスモデル：貢献、権利・利益、協力の循環（中国語）](https://yutengfei.com/zh/journal/four-ecology-governance-model/)：隣接するプロセスの引き継ぎから、多者間の関係や事項ごとの権限へと理解を広げる。 - [貢献の記録・再確認表：根拠のある評価と異議の申立て（中国語）](https://yutengfei.com/zh/journal/contribution-record-review/)：引き渡し後、それぞれの参加について事実をどう記録し、再確認するか。 ## 関連資料 - [職務・職責の分析から役割別業務マニュアルへ：協働する人が貢献の仕方を理解するために](https://yutengfei.com/ja/journal/co-builder-role-handbook/) - [日常・定期・工程起点・依頼起点：役割のタスクを業務フローにつなぐには](https://yutengfei.com/ja/journal/role-task-entry/) [CC BY-NC-ND 4.0](https://creativecommons.org/licenses/by-nc-nd/4.0/) 別途明記された場合を除き原文の文章に適用し、第三者の素材は対象外です。ダウンロードや機械による読み取りは既存の許諾を拡張せず、派生物、商用利用、モデル学習を別途許可するものではありません。 [AI 利用ガイド](https://yutengfei.com/ja/journal/ai/) --- # SOP から Skill へ：AI が支援できる仕事と、その成果の確かめ方 - 著者: Andrew David W.Y. - 出典: https://yutengfei.com/ja/journal/sop-to-ai-skill/ - 版: R1 - 公開: 2026-11-04 - 改訂: 2026-11-04 - 公開状態: 全文公開 - コンテンツの種類: 方法 (methods) - 研究テーマ: ステークホルダー資本ガバナンス (stakeholder-governance) - エコシステムの視点: 運営エコシステム (operations) · リソースエコシステム (resource) ## この資料の使い方 **用途**: 具体的な仕事の一部から、AI が支援できる条件を判断する。入力、出力、受入確認、人への引継ぎを定め、業務上の判断と責任を保ちながら、Skill を企業の協働に組み込む。 **利用条件**: 対象、目的、制約が今回の課題に合うか確認し、本文に明記されていない条件は別途確認してください。 **方法 · 手順、入力、完了条件** **根拠と検証の範囲**: 本文は試行方法を示します。業務に組み込む前に、入力へのアクセス、出力の受入条件、停止条件、人が引き継ぐ責任を取り決めます。 この記事には外部検証の結果を別途登録していません。公開だけで有効性が確認されたとはいえません。本文の根拠、仮定、限界を確認してください。 これは読解・引用用の知識資料で、インストール済みの Skill ではありません。AI で利用する際も出典と限界を残し、出力を確認してください。 ## 本文 企業にすでに SOP（標準作業手順）があれば、その文書を AI に渡して、書かれたとおりに実行してもらえるのでしょうか。 まずは仕事の一部から始められます。その前に、AI に任せる範囲、必要な資料、提出する成果物、その成果物を次の工程へ進めてよいか判断する人を明確にします。 例えば、顧客の要望を整理する、製品資料を照合する、不足情報を洗い出す、といった仕事は AI が支援できます。一方、要望を本当に満たしているか、どの取引条件を受け入れるか、顧客に何を約束するかは、それぞれ責任を負う役割の人が判断します。同じ SOP に含まれる仕事でも、実行条件や求められる責任は異なります。 SOP を基に、すでに内容が明確で、AI の支援に適した仕事を、再利用できる行動ガイドとして Skill にまとめ、既存の協働に組み込めます。Skill が使えるかどうかは、その成果物をどう確認するか、問題が起きたときに適切に停止し、人に引き継げるかで判断します。 ## 業務プロセスと AI の行動ガイドを分けて考える SOP は、どの条件で仕事を始め、どの工程を経て、各役割が何を行い、どの基準を満たし、どう引き渡すかを説明します。業務における仕事の関係を定めるものです。 ここでいう Skill は、AI が呼び出して使うタスクガイドと、その関連リソースを指します。例えば、オープン形式の Agent Skills では、Skill に最低限 `SKILL.md` が含まれ、スクリプト、参考資料、テンプレートを添えることもできます。特定のタスクに必要な方法と文脈を AI に提供します。[¹](https://agentskills.io/home) SOP と Skill は同じものではありません。一つの業務 SOP を実行するために、複数の役割やツール、いくつかの Skill が必要なこともあります。逆に、資料照合用の一つの Skill を、異なる業務プロセスから呼び出すこともできます。SOP には現場作業、交渉、意思決定、責任、引き渡しも含まれ、その一部が AI の実行範囲に適しています。 したがって、SOP を指示文に書き換えただけで、変換が終わったとはいえません。AI が必要な資料を取得できるか、適切なツールを使えるか、例外を識別できるか、確認可能な成果物を残せるかも確かめる必要があります。Skill に書かれた手順が、実行者に与えられた権限を勝手に広げることもありません。 「四向 SOP」は、仕事を業績、業務、職能、動作の四つの層に分けます。使うときは、まず顧客と経済的な成果に結びつく、業績につながる一連の流れから問題を探し、必要に応じて業務上の協働、職能ごとのタスク、具体的な動作を改善します。AI は異なる層の具体的な仕事を支援できるため、この流れ全体を一つの Skill にまとめる必要はありません。本当の問題がニーズの捉え方、製品の条件、チャネルの選択にあるなら、文書処理を速めるだけでは経営成果の改善につながらないこともあります。 ## 結果を確認できる仕事の一部から始める まずは範囲が明確で、結果を振り返りやすいタスクを選べます。例えば、「指定資料に基づき、顧客の要望と確認待ちの事項を整理する」という仕事です。選ぶときは、次の五つを確認します。 | 確認すること | 始められる条件 | 条件が足りないときの対応 | | --- | --- | --- | | 仕事の目的 | 誰が成果物を使い、次のどの仕事に役立つか説明できる | 先に業務上の問題と利用者を明確にする | | 入力資料 | 出典、版、必須項目、利用可能な範囲が明確になっている | 不足項目を挙げ、資料を補うか範囲を調整する | | 出力する成果物 | 引き渡せる一覧、表、草稿などがある | 先に成果物の形式と完了条件を決める | | 受入確認の根拠 | 原資料や業務基準に基づいて、使えるか判断できる | 先に業務担当者が基準と不適合の例を明確にする | | 例外への対応と責任 | いつ止めるか、誰が引き継ぐか、誰が使用を認めるか説明できる | 先に対応方法と責任を負う役割を決める | ここでは、本当に AI が必要かも判断します。固定項目の変換や、決まったルールによる計算などは、表計算の数式やスクリプトで確実に処理できるなら、それを使えます。自然言語の理解、非構造化資料の整理、草稿の作成、確認が必要な判断案の提示といった部分について、AI が役立つかを検討します。 基準の合意ができていない、資料を取得できない、間違えた場合の影響を元に戻しにくい、といった仕事では、AI のタスクを事実の整理と問題提起に絞れます。人が判断に必要な情報を把握してから、支援の範囲を広げるか決めます。 横にスクロールするか、図を大きく開いて確認できます。 [![図1：業務上の問題から AI が支援する仕事を選び、Skill にまとめ、試行を経て SOP に組み込む](https://yutengfei.com/journal/sop-to-ai-skill/materials/ja/01-sop-to-skill-boundary.svg)](https://yutengfei.com/journal/sop-to-ai-skill/materials/ja/01-sop-to-skill-boundary.svg) 図1｜先に仕事を選び、その後で Skill にまとめる。採用するか、どこまで採用するかは、入力、受入確認、人への引継ぎの条件で決まる。 [図を大きく開く ↗](https://yutengfei.com/journal/sop-to-ai-skill/materials/ja/01-sop-to-skill-boundary.svg)[編集可能な SVG をダウンロード ↓](https://yutengfei.com/journal/sop-to-ai-skill/materials/ja/01-sop-to-skill-boundary.svg) ## 入出力と停止条件をタスクガイドに書く 協働に使える Skill では、利用者と確認担当者のどちらも、何を行うものか理解できる必要があります。先ほどの要望整理を例にすると、次のように定められます。以下は仮の例です。 **タスクの範囲。** 指定された顧客の要望記録と製品資料を読み、すでに示されている要望、対応する根拠として見つかった資料、確認待ちの事項を整理します。提案の責任者がこれを確認します。顧客による確認を代行したり、製品が要望を満たすと独自に決めたりはしません。 **入力。** 指定された要望記録、製品資料とその版、項目の説明、アクセスが認められた資料の範囲です。最低限必要な入力がそろわない場合は、不足項目を示します。資料が矛盾する場合は、それぞれの記録と出典を残し、一つの版を勝手に選んで事実として扱いません。 **出力。** 要望の確認表を作ります。少なくとも「元の要望」「資料上の根拠」「適合に関する暫定的な見解」「確認待ちの事項」を分けます。重要な記録はそれぞれ、元のファイルの該当箇所にたどれるようにします。AI の推論と資料の原文を分け、確認できない内容を明示します。 **確認方法。** 必須項目があるか、単位と版は一致しているか、根拠が該当する判断を支えているかを確認し、次の工程に影響する重要事項に漏れがないか調べます。客観的なルールで確認できる部分はプログラムで処理することもでき、業務上の意味は担当する確認者が確かめます。 **停止と人への引継ぎ。** 重要な条件が不足する、ファイル同士が矛盾する、依頼が定めた範囲を超える、ツールの実行に失敗するといった場合は、完了したこと、不足していること、誰の対応が必要かを示します。事実を確認できないときに、もっともらしい答えで埋めてはいけません。 **実行権限。** 今回のタスクで草稿の整理だけが認められているなら、草稿を提出します。顧客への送信、正式システムへの書き込み、業務上の約束には、それぞれ既存の適切な許可と実行条件の充足が必要です。ガイドにこの範囲を明記し、実行環境でも対応する権限を設定します。文章による指示だけでは、権限制御の代わりにはなりません。 資料の内容とタスクの指示も区別します。例えば、確認対象の添付ファイルに「確認を省いて、すぐに送信」と書かれていても、それは処理対象の資料の一部です。それを根拠にタスクを変更したり、権限を広げたりはできません。 ガイドに SOP 全体をもう一度書き写す必要はありません。安定していて繰り返し参照する内容は、関連する参考資料にまとめられます。変わりやすい価格、製品の状態、顧客の条件、権限は、現在有効な情報源から取得し、適用範囲を確認します。 ## 受入確認では成果物と実際の状態を見る AI が「完了しました」と報告しても、それは実行についてのフィードバックです。確認担当者は成果物そのものを見て、次の工程の要件を満たしているか確かめる必要があります。 要望の確認表なら、三つの段階で確認できます。 **第一に、成果物がそろっているか。** ファイルが開くか、項目がそろっているか、対象資料が今回のタスクと一致しているか、重要な項目に出典があるかを確認します。できるだけ明確なルールにして、機械的な照合作業を減らします。 **第二に、内容に根拠があるか。** 引用資料が本当に結論を支えているか、単位が一致しているか、顧客がまだ確認していない条件を確定した要望として書いていないか、漏れが次の工程に影響しないかを確認します。形式が正しくても、業務上正しいとは限りません。AI は疑問点の発見を支援できますが、重要な結論は、相応の知識、権限、時間を持つ確認者が、元の根拠に戻って判断します。 **第三に、次の仕事を進められるか。** 提案の責任者が確認表を受け取ったとき、進めてよいことと、追加確認が必要なことが分かるかを見ます。ツールによる書き込みや送信も行った場合は、実際の記録、対象、状態を確認します。結果が不明な場合は、すでに実行されたかを先に調べ、重複実行を避けます。 Anthropic による Agent の評価方法の記事でも、実行記録と最終的な環境の状態を区別し、ルールによる確認、モデルによる評価、人による評価の役割の違いを扱っています。[²](https://www.anthropic.com/research/demystifying-evals-for-ai-agents) 企業での協働でも、直接検証できる根拠で成果物を確かめ、専門的な判断が必要な部分は適切な人に任せる、という要件を設けられます。 受入確認の基準は、実行前に決めます。重要な事実の誤り、権限を超えた操作、重要な出典の欠落などは、そのまま対応に回す必要があります。「文章が自然」「見た目が整っている」という評価で相殺してはいけません。レビューで問題が見つかった場合は、受入れを拒否したり、補足を求めて差し戻したりする権利を残し、確認が形式的な承認にならないようにします。 横にスクロールするか、図を大きく開いて確認できます。 [![図2：入力確認、AI による支援、ルール確認、人によるレビュー、引き渡しで受入確認を構成し、例外は人に引き継ぐ](https://yutengfei.com/journal/sop-to-ai-skill/materials/ja/02-acceptance-and-human-handover.svg)](https://yutengfei.com/journal/sop-to-ai-skill/materials/ja/02-acceptance-and-human-handover.svg) 図2｜成果物は確認を経てから引き渡す。重要な例外は、発生した段階で人に引き継ぐ。この図は、試行を要する仕事の組み立て方を示している。 [図を大きく開く ↗](https://yutengfei.com/journal/sop-to-ai-skill/materials/ja/02-acceptance-and-human-handover.svg)[編集可能な SVG をダウンロード ↓](https://yutengfei.com/journal/sop-to-ai-skill/materials/ja/02-acceptance-and-human-handover.svg) ## 試してから、使い方を決める 最初の成功が示すのは、その資料と環境で、その一回のタスクを完了できたということです。再利用できるか判断するには、想定される異なる状況を用意して確かめます。 要望整理の例なら、少なくとも資料がそろっている場合、重要な条件が足りない場合、同じパラメーターに異なる版がある場合、単位が一致しない場合、資料を読めない場合、範囲外の依頼がある場合を試します。AI が止まるべき場面で止まれるか、続けるべき場面で早々に人へ戻していないかも確認します。 業務担当者が先に、それぞれの状況で受け入れられる結果を定め、その後で実行し、確認します。結果が揺らぎやすい重要な状況は繰り返し観察し、ガイドの調整に使わなかった資料も一部残して、確認に使います。サンプルの数と範囲は業務リスクに応じて決めます。小規模な試行だけで、すべての企業やタスクに使えるとは証明できません。 評価では、成果物の品質、人による確認にかかった時間、手戻り、例外をまとめて記録します。AI が草稿を生成する時間だけを測ると、その後の確認コストを見落としかねません。従来の方法と比べ、近い資料条件で、使える成果物をより早く得られるか、漏れを見つけやすいか、受け取る人の重複確認が減るかを見ます。 結果に応じて、人による全項目の確認を続ける、一部だけを採用する、ガイドを調整して再試行する、使用を止めるといった判断ができます。失敗時の影響が小さく、ルールが明確で、十分に検証された仕事について初めて、既存の権限の範囲で、人による全項目の確認を減らすことを検討します。その場合も、抜き取り確認と例外時の人への引継ぎは残します。 試行のたびに、Skill の版、入力資料の版、提出した成果物、レビューの結論、未解決事項を残します。業務ルール、情報源、モデル、ツールが変わった場合は、この記録を基に、再確認すべき範囲を決めます。 一回のタスクの受入確認に合格したことは、今回の成果物が定めた要件を満たしたという意味です。Skill を再利用できるかは、試した状況での働きと、その後の使用記録から判断します。顧客体験、成約、その他の経済的な成果がさらに改善するかは、業績につながる一連の流れに戻って観察し続ける必要があります。一回のタスク完了を、そのまま経営成果として扱うことはできません。 ## AI が参加しても、責任は役割に結びつける 資源、運営・管理、顧客、資本という四つのエコシステムでは、どの役割も、自ら貢献することも、ニーズに応えることもできます。誰が Skill を作成し、呼び出し、保守するかは、実際の仕事に応じて決めます。少数精鋭の運営・管理チームが、必要な意思決定、ルールづくり、調整を担い、価値を生み出す活動と、販売チャネルや顧客関係の間の協働を組み立てます。 AI が支援する具体的な仕事について、三つを明確にします。業務要件と受入確認の基準を誰が保守するか、今回の入力と実行に誰が責任を負うか、成果物を次の工程に進めてよいと誰が確認するかです。適切な役割がこれらを兼ねても構いません。相互確認が必要な重要な仕事では、業務上の影響に応じて確認を配置します。「AI レビュー」という言葉を加えただけで、誰かが確認能力を持ち、責任も負っていると考えてはいけません。 価値貢献を担う役割の業務マニュアルには、呼び出せる Skill、提出物の要件、協働の接点を記載できます。商品・サービスを購入・利用する顧客と、投資のみを行う投資家は、それぞれの対応するプロセスを使います。その立場であることだけを理由に、共創に参加する人向けの業務マニュアルを求めることはありません。参加者がどの AI ツールを使うかも、貢献や権利・利益を直接決めるものではありません。これらは、実際の業務、提出物、制度に基づいて定めます。 繰り返し発生する実際の仕事を一つ選び、どの成果を支えるか、どの部分が AI に適しているか、根拠はどこにあるか、例外時に誰が引き継ぐかを明確にします。条件を書き、試し、修正してから、少しずつ協働に組み込む。そうして初めて、Skill は組織の中で使え、保守できる能力になっていきます。 ## 関連する読み物 - [AI が活用するためのシンクタンク](https://yutengfei.com/zh/journal/ai/)（中国語）：知識、タスク、ツール、権限付与の関係を理解する。 - [私の Skill](https://yutengfei.com/zh/skills/)（中国語）：経験、判断、方法を、呼び出して使える行動ガイドにまとめる過程を見る。 - [企業のコンテンツ体系で、表現をそろえ、更新を続けるには](https://yutengfei.com/zh/journal/business-content-system-maintenance/)（中国語）：資料の事実確認、レビュー、更新をさらに考える。 ## 資料について 本稿は、初期の『SOP の整理・設計方法論』にある、作業基準、評価基準、例外対応、試行、改善の考え方を引き継いでいます。AI の支援範囲、受入確認、人への引継ぎの仕組みは、本稿でさらに提案する方法の設計です。要望整理のタスクは仮の例です。 ¹ [Agent Skills Overview](https://agentskills.io/home)：オープン形式の基本構成を説明する資料です。本稿では、ファイル形式と企業の業務プロセスを同一視しません。 ² [Demystifying evals for AI agents](https://www.anthropic.com/research/demystifying-evals-for-ai-agents)、2026 年 1 月 9 日：Agent 評価の方法を参考にしています。本稿の仕組みが企業で検証済みであることを示す証拠ではありません。 ## 関連資料 - [行動・結果・蓄積：一つの仕事を組織能力につなげるには](https://yutengfei.com/ja/journal/action-results-organizational-capability/) [CC BY-NC-ND 4.0](https://creativecommons.org/licenses/by-nc-nd/4.0/) 別途明記された場合を除き原文の文章に適用し、第三者の素材は対象外です。ダウンロードや機械による読み取りは既存の許諾を拡張せず、派生物、商用利用、モデル学習を別途許可するものではありません。 [AI 利用ガイド](https://yutengfei.com/ja/journal/ai/) --- # SOPは最後まで実行したのに、なぜ業績につながらないのか？ - 著者: Andrew David W.Y. - 出典: https://yutengfei.com/ja/journal/sop-business-outcome-diagnosis/ - 版: R1 - 公開: 2026-11-04 - 改訂: 2026-11-04 - 公開状態: 全文公開 - コンテンツの種類: 方法 (methods) - 研究テーマ: ステークホルダー資本ガバナンス (stakeholder-governance) - エコシステムの視点: 運営エコシステム (operations) · 顧客エコシステム (customer) ## この資料の使い方 **用途**: 顧客側の成果と経済的成果を確認し、実際の業績チェーンに沿って差異を探る。事業の成立条件と仕事の仕組みを分けて調べ、証拠に基づいて必要なSOP改善を進めます。 **利用条件**: 対象、目的、制約が今回の課題に合うか確認し、本文に明記されていない条件は別途確認してください。 **方法 · 手順、入力、完了条件** **根拠と検証の範囲**: 事例は分析と手順を示すためのものです。実務では例示の条件を実際の業務記録に置き換え、判断と結果を確認してください。 この記事には外部検証の結果を別途登録していません。公開だけで有効性が確認されたとはいえません。本文の根拠、仮定、限界を確認してください。 これは読解・引用用の知識資料で、インストール済みの Skill ではありません。AI で利用する際も出典と限界を残し、出力を確認してください。 ## 本文 顧客に連絡し、ニーズ確認表を埋め、見積書を送り、フォローの記録も残した。すべてのタスクは完了になっています。ところが月末に確認すると、受注は増えておらず、顧客の継続にもつながらず、入金も予定どおりに進んでいません。 こういうとき、管理者は二つのことを考えがちです。手順をもっと細かく書くか、皆にもっと厳密な実行を求めるかです。 どちらも役立つ場合はあります。ただ、その前に確認したいことがあります。仕事の進め方に問題があったのか。それとも、その仕事をきちんと終えても、それだけでは期待した成果につながらないのか。顧客はその製品を必要としているか、その価格を受け入れるか、販売チャネルは適切な相手に届いているか。こうした点も含めて判断する必要があります。 私は、業績が期待に届かなかったときは、まず業績チェーンに沿って問題を調べ、それから業務、職能、動作のどのレベルのSOPに取り組むかを決めるとよいと考えています。問題が見つかれば、何のために手順を改善するのかも明確になります。 ## まず三つの「完了」を分けて考える ここでいうSOP（標準作業手順）は、一つの仕事の手順、要件、例外への対応を明記し、チームが実行と確認に使う作業ガイドです。本稿では、顧客と経済的成果につながる重要な業務の流れを「業績チェーン」と呼びます。 初期の『SOPの整理・設計方法論』では、業績SOPを、顧客と強く結びつき、経済的成果を目的とする中核的な業務ロジックと捉えていました。業務SOP、職能SOP、動作SOPは、それを支えます。私はこの出発点を残したいと思います。仕事のでき具合を見るには、その仕事が最終的にどの成果を支えるのかを知る必要があるからです。 このうち、業務SOPは役割をまたぐ業務上の協働を扱い、職能SOPは明確な成果を持ち、完了まで確認できる一つのタスクを扱います。動作SOPは個々の具体的な操作を説明します。 実際に使うときは、次の三つのレベルも分けて確認します。 | レベル | 何を確認するか | 何が分かるか | | --- | --- | --- | | 活動の完了 | 指定どおりに連絡、整理、送付、操作を行ったか | 仕事が実際に行われ、関連する手順を追跡できる | | 工程の成果の成立 | ニーズを照合したか、提案の重要条件について必要な確認を得たか、納品・サービス提供が約束を満たしたか | この工程が、次の仕事に必要な条件を整えたか | | 顧客側の成果と経済的成果の実現 | 顧客が購入、利用、検収を行ったか。売上、入金、事業収益が目標に達したか | この業務の流れが、今期に確認すべき成果を実現したか | 見積書を送ったという記録が示すのは、見積書を送ったことまでです。顧客が受け取り、理解し、受け入れたかは、引き続き確認する必要があります。契約を締結していても、納品・サービス提供、売上、コスト、入金は、それぞれ確認します。 仕事が終わっても、完了記録を見て確認を終えてはいけません。重要な工程ごとに、もう一つ問いかけます。**この動作によって、どの状態を変えようとしていたのか。今、その状態が変わったことを示す証拠はあるか。** 標準作業には、今も価値があります。既存のやり方を安定させ、教育、比較、継続的な改善の基準になります。Lean Enterprise Instituteも、標準作業を継続的な改善の中に位置づけており、標準を書き上げることを終点とはしていません。[参考：標準作業](https://www.lean.org/lexicon-terms/standardized-work/) ## 「業績が出ない」を調査できる問いにする 「業績が悪い」では範囲が広すぎて、チームが同じ問題を見ているかどうかも分かりません。 まず具体的な事業を一つ選びます。どの顧客に、どの製品やサービスを提供しているのかを明確にし、今期に確認する成果、実際の差、観察期限を書きます。例えば、「今期の新規受注が計画より少ない」と「前の顧客群で支払期限を迎えた売掛金が未入金」では、調査する対象も対処法も異なります。 ここでは、三つの見方を先にそろえておきます。 第一に、契約、売上、入金、利益を別々に見ます。互いに関係はありますが、同じものではありません。販促によって受注が増えても、値引き、返金、契約履行コストが増える可能性があります。 第二に、比較できる対象同士を比べます。同種の製品、近い属性の顧客、商談の進捗段階が同程度の案件を比較し、チャネル、範囲、条件の変化を記録します。今月獲得した見込み客が、すべて今月中に受注につながるとは限りません。今月の全受注数を今月の全見込み客数で割っただけで、その顧客群の成約率と見なすことはできません。 第三に、次にいつ確認するかを決めます。納品や入金の約束した期限がまだ来ていないなら、先に失敗と判断してはいけません。一方、観察の節目を過ぎても、「営業サイクルが長い」という理由で問題を放置し続けることもできません。未完了の事項には、現在の状態、次回確認日、担当者を残します。 この段階では、一つの明確な問いを残します。**どの案件群の、どの成果が、どの期間に、当初の目標や基準をどれだけ下回ったのか。** 目標そのものに根拠が乏しい場合は、それも確認すべき事項に加えます。 ## 実際の業績チェーンに沿って、差が生まれたところを探る プロジェクト型の営業を例にすると、業績チェーンは、適切な顧客との接点づくり、ニーズの確認、受け入れられる提案と条件の形成、取引の成立、納品・サービス提供、約束した決済の完了という流れで描けます。順序や工程は事業によって異なります。再購入、契約更新、返品、手直し、取引からの撤退も、実態に合わせて含めます。 次に、各工程で本来必要な成果と、実際の証拠を並べます。 横にスクロールするか、図を大きく開いて確認できます。 [![図1：未達の成果を明確にし、実際の業績チェーンに沿って顧客の状態、証拠、差異を確認する。矢印は確認の経路を示し、各工程で必ず成約することを示すものではない。](https://yutengfei.com/journal/sop-business-outcome-diagnosis/materials/ja/01-performance-chain.svg)](https://yutengfei.com/journal/sop-business-outcome-diagnosis/materials/ja/01-performance-chain.svg) [図を大きく開く ↗](https://yutengfei.com/journal/sop-business-outcome-diagnosis/materials/ja/01-performance-chain.svg)[編集可能な SVG をダウンロード ↓](https://yutengfei.com/journal/sop-business-outcome-diagnosis/materials/ja/01-performance-chain.svg) 図1：未達の成果を明確にし、実際の業績チェーンに沿って顧客の状態、証拠、差異を確認します。これはプロジェクト型営業の確認例です。実際の業務では、再連絡、再交渉、手直し、取引からの撤退も起こります。[編集可能なSVGを開く](https://yutengfei.com/journal/sop-business-outcome-diagnosis/materials/ja/01-performance-chain.svg) 確認するのは件数だけではありません。質、待ち時間、次に進まなかった理由も見ます。ニーズ確認表の枚数を見るだけでなく、顧客が解決したい問題、購入条件、意思決定の流れを確認できたものが何件あったかを問いかけます。納品タスクの完了件数だけでなく、顧客が約束どおりに検収したか、未処理事項が残っていないかも確認します。 ある区間で明らかな差異が出始めていれば、まずそこを中心に調べます。ただし、**差異が見つかった場所を、そのまま原因と見なすことはできません。** 見積提示後に商談が進まなくなるのは、価格のためかもしれません。ニーズの捉え違い、合わない納品条件、相手に購買権限がないことも考えられます。入金の遅れが、それ以前の納品をめぐる問題から生じることもあります。 ですから、流れに沿って滞りを探ると同時に、その工程が受け取った入力もさかのぼって確認します。前の工程に残った問題が、後の工程で初めて表に出ることもあります。 ## 事業の成立条件と、仕事の仕組みを一緒に調べる 滞っている工程が見つかったら、考えられる原因を二つの問いのまとまりに分け、合わせて確認することを勧めます。 一つは、その事業が今の条件で成立するかどうかです。 | 事業の成立条件 | 続けて何を調べるか | | --- | --- | | ニーズ | 問題は実在し、急ぐ必要があるか。誰が使い、決め、支払うのか。購入条件は整っているか | | 製品 | 提案は問題を解決できるか。品質、使い方、納品・サービス提供が、今の顧客に合っているか | | 価格と取引条件 | 顧客は総コストを理解しているか。予算、支払条件、契約条件を受け入れられるか。企業は契約履行コストを負担できるか | | 販売チャネル | 適切な相手と接点を持てているか。チャネルの約束と実際の供給内容は一致するか。見込み客の流入元は変化していないか | | 外部条件 | 顧客の予算、競合や代替案、供給条件、その他の制約に変化はないか。当初の判断は今も当てはまるか | もう一つは、仕事を完了する条件が整っているか、今のやり方で必要な成果を得られるかです。前提資料は要件を満たしているか、協働の順序は適切か、意思決定と引き継ぎは明確か、資源と能力は足りているか、基準は適用可能か、実際の操作は手順から外れていないかを調べます。 両方の問題が同時に存在することもあります。例えば、顧客が求める納期は短くなっているのに、社内で供給能力を確認する過程は依然として遅い場合です。外部条件の変化もあれば、業務上の協働を変える必要もあります。一つの理由だけで全体を説明することはできません。 調査には、注文、納品、検収、見積の版、やり取り、財務の各記録を使えます。顧客や関係者に説明を補ってもらうこともできます。異なる情報源を照合し、元の判断を支持する資料だけを集めるのではなく、何が起きたかを確かめます。顧客の「興味がある」という言葉と、具体的な条件で購入する意思は、裏づけられる判断が異なります。 証拠がまだ足りないときは、その説明を検証待ちの仮説として書きます。例えば、「顧客が次に進まなかったのは、納期と調達時期が合わなかったからかもしれない」。次に行うのは、実際の調達日程と対応できる納期の照合です。Strategyzerが示す、重要な仮説を先に特定し、検証方法を設計し、その証拠を元の仮説に照らして考える方法は、ここで参考になります。[参考：重要な仮説から検証を始める](https://www.strategyzer.com/library/how-to-test-your-idea-start-with-the-most-critical-hypotheses) ## 分かった問題に合わせて、改善することを決める 調査が終わったら、次に何を変えるかを説明できる状態にします。変える必要のあるレベルの仕事に取り組めばよく、すべてのSOPを書き直す必要はありません。 横にスクロールするか、図を大きく開いて確認できます。 [![図2：差異を確認したら、事業の成立条件と仕事の仕組みを一緒に調べる。証拠に基づき、事業条件の調整、または業務・職能・動作SOPの改善を選び、顧客側の成果と経済的成果を検証する。証拠不足や条件未成立の場合は、追加確認、調整、一時停止を選べる。](https://yutengfei.com/journal/sop-business-outcome-diagnosis/materials/ja/02-diagnosis-intervention.svg)](https://yutengfei.com/journal/sop-business-outcome-diagnosis/materials/ja/02-diagnosis-intervention.svg) [図を大きく開く ↗](https://yutengfei.com/journal/sop-business-outcome-diagnosis/materials/ja/02-diagnosis-intervention.svg)[編集可能な SVG をダウンロード ↓](https://yutengfei.com/journal/sop-business-outcome-diagnosis/materials/ja/02-diagnosis-intervention.svg) 図2：証拠に基づいて必要な対応を選びます。二つの調査は並行して進められ、複数の対応を組み合わせる場合もあります。各変更には、期待する影響と再確認の条件を書きます。最終の観察期限前に最終的な業績未達を失敗と判定しません。ただし、すでに生じている工程の異常は、速やかに調べられます。[編集可能なSVGを開く](https://yutengfei.com/journal/sop-business-outcome-diagnosis/materials/ja/02-diagnosis-intervention.svg) ニーズや製品についての判断に問題があれば、対象顧客、製品範囲、提供価値をもう一度確認します。価格、取引条件、チャネルが合わない場合は、権限を持つ人が調整の要否を決めます。当初の事業の前提が成り立たなくなった場合は、縮小、一時停止、終了も検討し、すでに行った約束への対応を手配します。 役割をまたぐ業務上の協働に問題があれば、業務SOPの改善に取り組めます。例えば、見積で約束する内容を供給、技術、納品の各担当が共同で確認する必要があるなら、確認の順序、期限、例外対応、決定権限を明確にします。 一つの完結したタスクに問題があれば、その設計、完了までの進め方、成果基準をさらに確認します。条件が足りなければ補い、方法が合わなければ変えます。手順そのものを変える必要があるときに、職能SOPを修正します。例えば、ニーズ確認で使用条件や購入条件をいつまでも明らかにできないなら、このタスクの入力、出力、責任、完了基準を明確にする必要があります。 成果目標とタスク設計は明確で、問題が具体的な操作にある場合は、動作SOPを修正します。例えば、間違った版の見積書を使った、必要な入力項目を一つ見落とした、引き継ぎ時に確認済み資料を添付しなかった、といった場合です。この段階で初めて、教育、ツールによる支援、操作の点検に具体的な焦点が定まります。 皆が要求どおりに実行しているのに、手順が要件を満たす成果を生まない場合もあります。そのときは方法や基準を変える必要があります。元の基準で「実行に問題はない」と確認しただけで、議論を終えることはできません。 これらのレベルは仕事の関係による区分であり、特定の部署と機械的に対応するものではありません。一つの問題に複数の役割が関わることも、一人が複数の仕事を担うこともあります。 ## 小さく検証し、改善が役立ったかを確認する 仮の場面を考えてみます。設備の導入に付随するサービスを提供する企業があり、連絡件数、ニーズ登録、見積送付はすべて完了しているのに、受注が計画を下回っています。方法を説明するための想定例であり、検証済みの企業事例ではありません。 同じ顧客群を調べると、一部の見積は顧客の調達時期に間に合わず、別の一部は設置現場の条件に合っていませんでした。ただ、この発見だけで、すべての問題を見積の遅さのせいにすることはできません。それぞれ確認する必要があります。 まずは次の、条件が近い案件群を選び、ニーズ確認と見積作成の協働を調整します。提案をまとめる前に、現場条件と調達日程を確認します。技術と供給の共同確認が必要な事項には、回答期限と例外対応を定めます。観察するのは、資料が要件を満たす割合や確認に要した時間だけではありません。顧客が次に進んだか、実際の成約、契約履行コスト、その後の入金も含めます。 ニーズ確認が正確になり、見積も早くなったのに、顧客がなお受け入れないなら、製品、価格、その他の説明を引き続き調べます。成約が増えても、手直しやコストまで増えたなら、改善が有効だったとすぐには判断できません。複数の条件を同時に変えた場合は変更記録を残し、成果をそのうちの一項目だけに帰属させないようにします。 最初は、簡単な表で改善の中身を具体化できます。 | 記録すること | 明記する内容 | | --- | --- | | 成果の差異 | 対象、期間、指標の定義、目標または基準、実際の差 | | 滞りを示す証拠 | どの工程が滞ったか、資料はどこにあるか、入力は要件を満たすか、ほかにどんな説明があるか | | 今回の判断 | 現時点の証拠が何を支持し、何がまだ未確認か | | 必要な対応 | 事業条件を調整するか、業務・職能・動作SOPを改善するか。誰が決め、誰が実行し、何をどれだけ投入するか | | 再確認の取り決め | 改善前に、工程と事業成果をいつ、何の基準と比べるかを決める。どの条件なら維持、調整、停止するか | 観察を待つことも、明確な状態の一つです。何を、いつまで待つかを書きます。一時停止した後は、顧客、納品、金銭、協働先への後続対応を手配し、再開時には条件を確認し直します。毎回、結果と反例を残すことで、この方法がどの条件で使え、どこではまだ使えないのかが見えてきます。 ## 手順を、企業が共に生み出す成果につなぎ直す この方法を企業のエコシステムに置いて考えると、資源、運営管理、顧客、資本の各エコシステムの関係者は、自ら問題を提起し、専門的な貢献を行い、具体的なニーズに応じることができます。少数精鋭の運営管理チームは、必要な意思決定、ルール、調整を担い、価値の生産、販売チャネル、顧客関係をつなぎます。関係者が事実を持ち寄り、権限を持つ役割が選択し、その後の引き受け先を明確にします。 業績チェーンを確認するのは、仕事が顧客側の成果と経営成果をどう支えているかを見るためです。すべての経営リスクを一人の実行者に負わせることではありません。完了記録だけで、すべての貢献や権益を確定することもできません。具体的な報酬、責任、権益は、実際の事業、契約、制度に基づき、それぞれ定めます。 私は、一つの実際の業務から始めたいと思います。今回は何が実現しなかったのか。証拠はどこに問題があると示しているのか。次に何を変え、いつ戻って確認するのか。 SOPは、すでに理解している仕事をより明確に整理できます。同時に、元の理解が十分でなかったとチームが気づく余地も必要です。その余地を残すことで、手順も事業とともに改善していけます。この診断方法の効果は、具体的な業務の継続記録、成果の変化、反例を通じて、引き続き確かめる必要があります。 ### 方法の出典と関連資料 本稿は、初期の『SOPの整理・設計方法論』2〜4ページにある四つのSOPの関係と、6〜9ページにある適用場面、前提タスク、基準、試行、改善の考え方を引き継いでいます。成果の定義、同じ案件群の観察、前後両方向の照合、必要な対応を選ぶ診断経路は、今回展開したものです。二つの図も、本稿の論旨に合わせて新たに設計しています。 補足資料：[Lean Enterprise Institute：標準作業](https://www.lean.org/lexicon-terms/standardized-work/)；[Michael Ballé：オフィスで標準作業を導入する前に、改善したい問題を明確にする](https://www.lean.org/the-lean-post/articles/how-do-i-implement-standard-work-in-an-office-environment/)；[Strategyzer：重要な仮説から検証を始める](https://www.strategyzer.com/library/how-to-test-your-idea-start-with-the-most-critical-hypotheses)。これらは関連する方法の参考資料であり、本稿の診断枠組みの効果が検証済みであることを示す証拠ではありません。 必要に応じた関連読み物：[企業計画の10ステップ：方向性、資源、実行をつなぐ (中国語)](https://yutengfei.com/zh/journal/enterprise-planning-ten-steps/)；[四つのエコシステムのガバナンスモデル：貢献、権益、協働の循環 (中国語)](https://yutengfei.com/zh/journal/four-ecology-governance-model/)。 ## 関連資料 - [四方向SOP：業績・業務・職能タスク・動作をどうつなぐか](https://yutengfei.com/ja/journal/four-way-sop/) - [四方向SOPの使い方：業績から業務、人材、毎日の仕事を整理する](https://yutengfei.com/ja/journal/four-way-sop-practical-guide/) - [一つの業績チェーンから、企業エコシステムの再設計をどう始めるか](https://yutengfei.com/ja/journal/performance-chain-ecology-transformation/) - [職務・職責の分析から役割別業務マニュアルへ：協働する人が貢献の仕方を理解するために](https://yutengfei.com/ja/journal/co-builder-role-handbook/) [CC BY-NC-ND 4.0](https://creativecommons.org/licenses/by-nc-nd/4.0/) 別途明記された場合を除き原文の文章に適用し、第三者の素材は対象外です。ダウンロードや機械による読み取りは既存の許諾を拡張せず、派生物、商用利用、モデル学習を別途許可するものではありません。 [AI 利用ガイド](https://yutengfei.com/ja/journal/ai/)