フローを次へ進める前に、何を引き渡すのか？

営業が顧客の要望を見積担当者に渡し、タスクも「完了」にした。ところが見積担当者が資料を開くと、数量、納期、使用条件がまだ確認されておらず、改めて関係者に問い合わせることになる。前の担当者は確かに仕事をした。それでも、次の担当者は着手できない。

同じことは、企画からデザイン、デザインから制作、開発からテストへの引き継ぎでも起こる。企業と仕入先、販売パートナー、顧客の間でも起こる。

私が気になるのは、前の工程で生まれた成果が、次の工程で本当に使える出発点になっているか、ということだ。

ここを明確にして初めて、フロー図の矢印に実際の意味が生まれる。

1. まず二つを分ける。引き渡しが合格なら、次も始められるのか？

一つの業務フローは、互いに関係する複数のプロセスから成る。それぞれに目的があり、業務全体に何らかの結果をもたらす。その結果は製品、企画書、データかもしれないし、確認済みの要件や一つの決定かもしれない。

ISOのプロセスアプローチの解説では、プロセスを、インプットを使って意図した結果を生み出す相互に関連した活動の集まりとして捉え、プロセス間のインプット、アウトプット、相互依存を重視している。本稿もこの基本的な考え方に立ち、日常の引き継ぎに使う実務モデルを提案する。プロセスアプローチの解説（英語）

共通目標から出発し、次の順序で考える。前のプロセスが成果を生み出す → 次のプロセスの必要条件と照合する → 受入れ判断を明確にする → 開始条件を確認する → 次のプロセスに進む。

ここでは二つのことを分けて見る必要がある。

一つ目は、渡された成果が取り決めを満たしているか。要件は確認済みか、図面は現行版か、データに出典はあるか、成果物は取り決めた範囲に収まっているか。「この引き渡しを、仕事に使えるか」を判断する。

二つ目は、次のプロセスを始める条件が整っているか。担当者は引き受けられるか、必要な材料や資源は揃っているか、関連する決定は確認済みか。「今、始められるか」を判断する。

図面に問題がなくても、材料が届いていなければ制作には入れない。その場合は「引き渡しは受入れ済み、制作は開始待ち」と記録し、材料の問題を処理する。待ち時間をすべて設計担当者に差し戻しても解決しないし、図面を受け入れたからといって制作まで開始済みにしてはいけない。

横にスクロールするか、図を大きく開いて確認できます。

図を大きく開く ↗編集可能な SVG をダウンロード ↓

2. 何を渡すかは、次の工程での使い道から書く

「要望の整理は完了」「企画書は提出済み」。これだけでは、受け取り方が分かれやすい。

次に見積もりをするなら、少なくとも何を、いくつ、いつ納めるのか、どの条件が確認済みで、どこがまだ見込みなのかを知る必要がある。次に行うのが初期案の作成だけなら、一部の情報は未確定でもよいかもしれない。ただし仮定を明記し、まだ判断できないことを示しておく。

同じ資料でも、使う工程が変われば適用する基準も変わりうる。だから引き継ぎの要件は、着手前に関係者で確認する。業務の途中で本当に条件が変わった場合は、取り決めに沿って調整する。受け入れる側が引き渡しの直前になって、合意していなかった要件を次々に追加してよいわけではない。

まずは、次の六つを明確にするとよい。既存のタスク票、文書の説明欄、システムの項目に書けばよく、分厚い書式を新しく作る必要はない。

成果と根拠も分けておく。やり取りの記録から、ある条件を話し合ったことは確認できる。しかし、その条件が確定したとは限らない。AIが作った企画書が一見完成していても、そこに書かれた価格、仕様、納期の正確さや有効性まで証明されるわけではない。

受け取った人が、これを根拠に何ができるか、何をまだ確かめる必要があるか、どこまで使うと再確認が必要になるかを読み取れることが大切だ。

3. 誰が確認するのか。「検収をお願いします」だけでは足りない

提出する側は、まず取り決めに沿って自分で確認する。受け入れる側は、自分の仕事に必要なインプットを確認する。専門的な判断、対外的な約束、当初の権限を超える事項は、相応の権限を持つ人に確認してもらう。

小さなチームでは、一人が複数の役割を兼ねてもよい。それでも、判断の根拠と責任は明確にする。重要な事項に明らかな利益相反がある場合は、適切な再確認を別途手配する。通常の、低コストで修正しやすい引き継ぎには、簡単な確認や抜き取り確認で対応できる。リスクや修正コストが高い工程には、その分の確認を加える。どの工程にも何段階もの承認を要求し、元の問題以上に協力のコストを増やすべきではない。

受入れ判断は具体的に書く。例えば「要件表V2は見積入力基準との照合済み。仕様と数量は試算に使用できる。確定納期は供給側の確認待ちであり、これを根拠に顧客へ約束してはならない」。これなら「受け取りました」「問題ありません」より、その後の仕事を進めやすい。

「受領」は資料が届いたことを示す。「受入れ」は、指定された範囲の引き渡し内容が確認を通過したことを示す。「開始」は、次の工程の実際の条件も整ったことを示す。タスク管理システムで使うステータスは違ってもよいが、参加者がこの違いを見分けられるようにしたい。

返答期限も決めておく。期限を過ぎても返答がなければ、催促と調整に進む。無回答を合格扱いにはしない。受入れを断る場合も、満たしていない基準と具体的な不足を示す。理由のない待ち時間や繰り返しを減らす責任は、双方にある。

4. 次へつながらないときは、まず問題の種類を見る

引き継ぎに問題が起きると、「差し戻してやり直す」が選ばれやすい。しかし、渡された成果そのものに原因がなければ、やり直しても解決しない。

まず三つに分けて考えられる。

成果に不足がある。 取り決めた仕様が抜けている、重要なデータを確認できない、文書のバージョンが一致しない、といった場合だ。具体的な不足と影響を示し、担当者が補足または修正してから、有効な基準に照らして再検証する。すでに合格し、影響も受けていない部分まで、すべてやり直す必要はない。

基準や権限について認識が分かれている。 例えば「確認済み」の意味が双方で違う、または当初は権限のなかった納期を約束する必要がある場合だ。まず元の取り決めに戻る。必要なら権限を持つ役割が、適用する基準、範囲、責任を決める。受け入れる人が個人の考えで条件を追加してもいけないし、提出する人が進捗を急ぐために他人に代わって約束してもいけない。

業務条件が変わっている。 顧客の要望や供給能力が変わった、あるいは次の工程の資源が一時的に不足した場合などだ。まず影響範囲を見極め、関係する役割が、資源の追加、範囲や日程の調整、一時停止、関連業務の終了のいずれを選ぶか決める。成果自体は合格でも、当面使えなくなることはある。

横にスクロールするか、図を大きく開いて確認できます。

図を大きく開く ↗編集可能な SVG をダウンロード ↓

本当に必要であれば、明確な範囲に限って条件付きで受け入れることもできる。例えば内部試算を先に進めながら、不足する確認情報を補う場合だ。そのためには相応の権限が必要で、何をしてよいか、何をしてはいけないか、補完期限、条件を満たせなかった場合の停止や差し戻しの方法を明記する。これらが確認されても、限定的に行う作業のインプットと開始条件を、改めて確認する必要がある。

条件付き受入れでも、必須要件を飛ばすことはできない。決定権がない、結果を制御できない、または先に終えるべき必要な確認が残っている場合は、関連する行動を一時停止する。停止中も担当者を置き、どの条件が整えば再開するか、いつ再確認するかを示す。すでに負っている履行、費用、事後対応の責任は、引き続き取り決めに沿って処理する。ステータスを「一時停止」にしても消えない。

5. 見積もりの引き継ぎで、モデルの使い方を見る

以下は、モデルを説明するために作成した架空の場面であり、特定企業の実際の記録ではない。

顧客が、まとまった数量の特注設備を求めた。要件の調整担当者は、資料を見積責任者へ渡す。事前の取り決めでは、正式見積もりには確認済みの仕様、数量、納入先、希望納期が必要で、未解決事項も記載することになっている。

最初の提出では、仕様と数量は確認できていたが、納入先はまだ二つの候補があった。見積責任者は不足を指摘し、この状態では輸送費を確定できないと伝える。要件の調整担当者はその後、納入先を確認してV2を提出し、旧版と変更内容も残した。

V2を確認すると、見積もりに必要なインプットは取り決めを満たしていた。ただし、供給側はまだ生産能力を確認していない。ここも分けて考える。社内の原価試算は始められる。一方、確定納期を入れた正式見積もりを顧客に出す条件は、まだ整っていない。

権限を持つ責任者は、限定された範囲で内部試算を先に進めることを認めた。タスク記録には、生産能力の確認担当者、期限、顧客に納期を約束してはならないという制限を記載する。関連するインプットと資源を再確認した後、内部試算を開始する。

その後、供給側から希望納期を満たせないと連絡があれば、関係する役割が顧客と調整内容を確認する。顧客が仕様を変えた場合は、影響を受ける試算と資料を特定し、新版に基づいて改めて確認する。「V2は受入れ済み」という判断をそのまま使って、対外見積もりを続けてはいけない。

この例では、資料の不足、後工程が引き受けるための条件、対外的な決定を分け、一部の作業を先に進める余地を残している。しかし、最終的な成約を保証するものではない。一度の引き継ぎが順調だっただけで、フロー全体が業績を高めたと証明することもできない。

6. 共通目標は、個々の「完了」にも関わる

営業は早く進めたい。見積担当者は資料を揃えてほしい。供給側は条件を安定させたい。いずれにも実際の理由がある。共通目標は、同じ案件について関係者が取捨選択を話し合うためにある。顧客は何を解決したいのか。時間、コスト、品質、履行条件をどう両立させるか。どの約束はしてはいけないか。

全員の利害が同じである必要はない。また、共通目標を理由に、誰か一方へ際限なく仕事を追加してよいわけでもない。追加作業、待ち時間、やり直しにはコストがかかる。誰が負担し、元の取り決めを超えたときに誰が決めるかを明確にする。

このような引き継ぎは、資源、運営管理、顧客、資本という四つのエコシステムのいずれでも起こりうる。異なる役割は自ら貢献することも、要請に応じることもできる。具体的な事項は、業務上の関係と権限に沿って扱う。少数精鋭の運営管理チームは、関係する意思決定、ルール、調整を担い、価値の生産、販売チャネル、顧客関係をつなぐ。すべての専門的役割に代わって判断するわけではない。

このモデルが扱うのは、成果の引き渡しと、それを引き受けることだ。引き渡しの記録は後の評価に事実を提供するが、貢献のすべてを示すものではない。報酬、持分、配当、決定権が自動的に生じるものでもない。制度上の権利や利益は、実際の業務と相応の取り決めに基づき、別途扱う必要がある。

使い始めるときは、問題が繰り返される引き継ぎを一つ選べばよい。資料の不足、待つ理由、やり直し、確認コスト、顧客への履行への影響を記録する。試行後に、どの確認が役立ったか、どの基準が重すぎたか、問題の担当者を以前より早く見つけられたかを見る。比較対象や十分な記録がなければ、まず観察結果を残し、原因を急いで決めつけない。

案件が最終的に期待どおりにならなかった場合も、顧客のニーズ、製品と価格、履行、販売チャネル、入金など、業績につながる一連の流れから問題を探す。その後で、業務、職務機能、具体的な作業動作のどのレベルのSOPを調整するか決める。引き継ぎはその一部であり、すべての経営結果を説明できるものではない。

フローを次へ進める前に、引き渡しを通じて受け取る人に伝えたいのは、今これを根拠に何ができるか、まだ何をしてはいけないか、状況が変わったら誰に対応を求めるか、ということだ。これらの条件がつながって初めて、フローが実際にどこまで進んだか分かる。

出典と関連資料

• モデルの基礎：初期のチーム資料『SOP梳理设计方法论（SOPの整理・設計方法論）』。主に6〜9ページの前提タスク、次工程への移行、引き継ぎ、例外対応、試行、改善を参照した。初期の「職務責任、業務マニュアル、SOP、業績評価」の関係図2点から、「前工程の結果を検証する」という研究の手掛かりを得た。本稿の引き継ぎと例外対応の仕組みは再構成した実務モデルであり、その効果は具体的な業務での検証を要する。
• 概念の参考：ISO: The process approach in ISO 9001:2015（英語）。プロセスのインプット、アウトプット、相互依存を説明するために参照した。本稿は規格条文の解説や認証ガイドではない。

• 企業計画の10ステップ：方向性、資源、実行をつなぐ（中国語）：目標と資源配分から、相互依存する協力の約束を理解する。

• 四つのエコシステムのガバナンスモデル：貢献、権利・利益、協力の循環（中国語）：隣接するプロセスの引き継ぎから、多者間の関係や事項ごとの権限へと理解を広げる。

• 貢献の記録・再確認表：根拠のある評価と異議の申立て（中国語）：引き渡し後、それぞれの参加について事実をどう記録し、再確認するか。