SIPOC（サイポック）は、Supplier（供給者）・Input（インプット）・Process（プロセス）・Output（アウトプット）・Customer（顧客）の5要素で、1つの業務の範囲を1枚の表にまとめる手法です。この記事では、5要素の意味と業務フロー図との違い、SIPOC図の作り方6手順、受注から請求までの業務で各列を埋めた書き方の例を順に説明します。後半では、SIPOCの各列を要件定義の連携先・入出力データ・利用者に読み替え、どこまでをシステム化するかを決める方法を整理します。
まとめ：SIPOCは業務の始点と終点を決め、誰が何を受け渡すかを先に合意する図
SIPOCで描くのは、業務の手順ではなく「範囲」と「受け渡し」です。どこから始まりどこで終わる業務か、何を誰から受け取り、何を誰に渡すかを、関係者が同じ1枚の表で確かめます。
作り方の要点は2つです。プロセス列は4〜5工程に抑えます。列を埋める順序は、プロセス、アウトプット、顧客、インプット、供給者です。受け取る側の要求から逆にたどると、要らないインプットを書かずに済みます。
システム開発では、SIPOCは要件定義の最初に置く道具になります。供給者の列は連携先のシステム、インプットとアウトプットの列は入出力のデータと帳票、顧客の列は利用者と権限の候補に読み替えられます。一方で、手順の改善や原因の分析には向きません。その用途には業務フロー図やECRS、なぜなぜ分析を使います。
SIPOCとは：供給者・インプット・プロセス・アウトプット・顧客で業務の範囲を1枚にする図
5要素の意味：誰から何を受け取り、どう処理して、誰に何を渡すかの5列
SIPOCの5要素は、左から右へ「受け取り→処理→引き渡し」の順に並びます。
| 列 | 英語 | 書く内容 | 受注業務での例 |
|---|---|---|---|
| 供給者 | Supplier | インプットを渡す人・部署・システム | 取引先、倉庫 |
| インプット | Input | 処理に必要な情報・帳票・物 | 注文書、在庫数 |
| プロセス | Process | インプットを成果に変える主な工程 | 受付、在庫確認、出荷指示 |
| アウトプット | Output | 工程から生まれる成果 | 受注データ、出荷指示書 |
| 顧客 | Customer | アウトプットを受け取って使う相手 | 倉庫、経理部 |
顧客には社外の取引先だけでなく、社内で次の工程を担う部署も入ります。倉庫が供給者と顧客の両方に出てくるように、同じ相手が両端に並ぶことも珍しくありません。英国の道路公社National HighwaysのSIPOCの手引き（Guide to SIPOC）は、顧客の列に「受け取る相手と、その相手が成果を何に使うか」まで書くよう説明しています。
業務フロー図との違い：SIPOCは範囲と受け渡し、フロー図は手順と分岐を描く
SIPOCと業務フロー図は、同じ業務を別の粒度で描きます。
業務フロー図は、担当者ごとのレーンに作業を並べ、条件分岐や差し戻しまで書き込む図です。工程は数十に及ぶこともあります。SIPOCは分岐を書きません。プロセス列に主な工程を数個並べ、両端に供給者と顧客を置くだけです。
描く順番は、SIPOCが先です。範囲が決まらないまま業務フロー図を描き始めると、前後の業務まで書き込んで図が膨らみ、どこまでが検討対象かがあいまいになります。SIPOCで始点と終点を決めてから、その内側だけを業務フロー図で細かく描くのが、手戻りを減らす描き方です。業務フロー図の描き方や粒度のそろえ方は業務可視化とは？4つの対象と方法・ツールの選び方で説明しています。
SIPOCが役立つ場面：関係者が多く、誰が何を渡すかが曖昧な業務の整理
SIPOCが効くのは、関係者の認識がずれていそうな業務です。米国医療研究品質庁（AHRQ）のSIPOCの解説ページは、使う場面として次の3つを挙げています。
- プロジェクトの初めに、主な構成要素を洗い出したいとき
- 供給者・インプット・アウトプット・利用者が複数あるとき
- それらが誰で何なのか、はっきりしていないとき
同じページは、利点としてプロジェクトの範囲を決めやすくなること、欠点としてすべてのプロセスに当てはまるわけではないことを挙げています。研修がほとんど要らない手法とも書かれており、付箋とホワイトボードがあれば始められるという説明です。部署をまたぐ受注処理や、外部委託先が絡む月次決算のように、受け渡しの相手が3者以上いる業務から使うと効果が見えます。
SIPOC図の作り方：工程を4〜5個に絞り、アウトプットと顧客から埋める6手順
6手順：始点と終点を決めてから、関係者の会議で5列を順に埋める流れ
National Highwaysの手引きとAHRQの解説ページの手順を突き合わせると、作り方は次の6手順にまとまります。
- 対象の業務を1つ選び、始点と終点を決める（例：注文書の受領から請求書の発行まで）
- 供給者・顧客・各工程の担当者から、会議に呼ぶ関係者を決める
- プロセス列に主な工程を4〜5個書き、関係者と合意する
- 工程ごとのアウトプットと、それを受け取る顧客を書く
- 工程ごとに必要なインプットと、それを渡す供給者を書く
- 漏れ・重複・不正確な記述がないかを見直し、成果物の責任者を決める
National Highwaysの手引きは、工程を「4 or 5 steps max」としています。会議の時間は2時間を超えない想定で、議事は上の手順に沿って進めればよいとしています。2時間で終わらないなら、対象の範囲が広すぎるサインです。始点と終点を狭めて、SIPOCを2枚に分けてください。
P→O→C→I→Sの順で埋める理由：受け取る側の要求から必要な入力を決める
5列は左から順に埋めるのではなく、プロセスを書いた後にアウトプットと顧客、最後にインプットと供給者を書きます。AHRQの手順も、National Highwaysの手引きも、この順です。
理由は、インプットの要否を判断する基準が顧客の側にあるからです。先にインプットから書くと、今使っている帳票やExcelをすべて並べてしまい、誰も使っていない情報まで「必要なもの」として残ります。顧客がアウトプットを何に使うかを先に確かめれば、それを作るのに要らないインプットは書かずに済みます。
National Highwaysの手引きは、アウトプットは顧客と、インプットは供給者と、それぞれ「何を・いつまでに」を決めるよう求めています。受け渡しの期限まで書いておけば、その期限が後で処理の締め時刻を決めるときの判断材料です。なお、顧客の側から書いた図をCOPIS（コーピス）と呼ぶこともあります。
よくある失敗：工程を細かく書く、顧客を「お客様」とまとめる、人をインプットにする
初めて作るSIPOCで多い失敗は、次の3つです。
- プロセス列に10工程以上を書き、業務フロー図と同じものになる
- 顧客を「お客様」「社内」とまとめて書き、誰が何に使うかが消える
- インプットに「営業担当」と人を書き、受け渡す情報が分からなくなる
工程が多くなったら、隣り合う工程を「在庫と与信を確かめる」のように1つの動詞句にまとめます。顧客とインプットは、部署名や帳票名まで具体的に書きます。人は供給者か顧客の列に置き、インプットとアウトプットの列には情報・帳票・物だけを書く、と決めておくと迷いません。
SIPOCの書き方の例：受注から請求までの業務で5列を埋めた記入例と読み取り方
記入例：卸売業の受注から請求書発行までを5工程で書いたSIPOC図
FAXとメールで注文を受け、自社倉庫から出荷し、月末に請求書を出す卸売業を例にします。始点は注文書の受領、終点は請求書の発行です。
| 供給者 | インプット | プロセス | アウトプット | 顧客 |
|---|---|---|---|---|
| 取引先 | 注文書（FAX・メール） | 1. 注文を受け付ける | 受注データ | 営業事務 |
| 倉庫、経理部 | 在庫数、与信限度額 | 2. 在庫と与信を確かめる | 受注確定の連絡 | 取引先 |
| 営業事務 | 受注データ | 3. 出荷を指示する | 出荷指示書 | 倉庫 |
| 倉庫 | 出荷実績 | 4. 出荷を確定する | 納品書、売上データ | 取引先、経理部 |
| 経理部 | 売上データ、単価表 | 5. 請求書を発行する | 請求書 | 取引先 |
表の内容は書き方を示すための例です。行ごとに工程を1つ置き、その工程の入出力を横に並べると、どの受け渡しがどの工程で起きているかを1行で読めます。
記入例から読み取る論点：二重入力の箇所、紙の受け渡し、期限の決まっていない入力
完成したSIPOCは、清書して終わりにせず、表から論点を拾います。上の例なら、次の3点が見えてきます。
1つ目は二重入力です。受注データ（工程1）と売上データ（工程4）に、同じ品目と数量が別々に入力されていないかを確かめます。2つ目は紙の受け渡しです。FAXの注文書と出荷指示書が紙なら、工程1と工程3で転記が発生しています。3つ目は期限です。与信限度額を経理部がいつ更新しているかが決まっていなければ、工程2の判断が古い数字に基づくことになります。
拾った論点のうち、なくせる作業やまとめられる作業は、業務改善の4原則で見直します。工程ごとに4つの問いを当てる進め方はECRSとは？業務改善の4原則の意味と順番で扱っています。
SIPOCを要件定義に使う方法：5列を連携先・入出力・利用者に読み替えて範囲を決める
要件定義でのSIPOCの位置：IPAガイドのビジネス要求定義の入口に置く
情報処理推進機構（IPA）の「ユーザのための要件定義ガイド 第2版」（2019年9月公開）は、要件定義をビジネス要求定義（BR）とシステム化要求定義（SR）に分け、それぞれの勘どころを章立てで整理しています。業務として何を実現したいかを決めるのがBR、それをシステムでどう実現するかを決めるのがSRです。
SIPOCは、BRの最初に置く道具です。対象業務の始点と終点、関係する部署と取引先、受け渡す情報が1枚にそろうので、業務要件を書き始める前の範囲合意に使えます。業務要件として何を文書にするかは業務要件定義とは？8つの記載項目と業務要件定義書の作り方で、要件定義全体の進め方は要件定義とは？目的・進め方・成果物で説明しています。
この順番を飛ばして画面や機能の話から入ると、要件定義の終盤で「この帳票は誰が受け取るのか」「この取引先のデータはどこから来るのか」が決まっていないことに気づき、範囲を決め直すことになります。
列ごとの読み替え表：供給者は連携先、インプットとアウトプットは入出力データ
SIPOCの5列は、そのまま要件定義の検討項目に対応します。
| SIPOCの列 | 要件定義での読み替え | 受注業務の例 |
|---|---|---|
| 供給者 | 連携先のシステム・外部の取引先 | 倉庫の在庫システム、取引先 |
| インプット | 入力データ・受け取る帳票 | 注文書、在庫数、与信限度額 |
| プロセス | 機能の候補・画面の単位 | 受注登録、在庫引当、出荷指示 |
| アウトプット | 出力データ・帳票・通知 | 出荷指示書、請求書、売上データ |
| 顧客 | 利用者・権限・受け取るシステム | 営業事務、倉庫、会計システム |
この表で拾えるのは、機能要件の候補とインターフェースの一覧までです。項目の桁数や処理件数、応答時間といった詳細はSRの段階で詰めます。顧客の列から利用者を拾っておくと、後でユースケース図や権限表を作るときの漏れが減ります。
システム化範囲の線引き：工程に「システム内・外」の印を付け、境界の入出力を連携にする
SIPOCの各工程に、新しいシステムで処理する工程なら「内」、手作業や既存システムに残す工程なら「外」の印を付けます。印を付けたら、内と外の境目を横切るインプットとアウトプットを数えます。
境目を横切る入出力が、そのままシステム間の連携やデータの受け渡し口になります。受注の例で工程1〜3を新システムの内側、工程4〜5を既存の会計システム側に残すなら、工程3から工程4へ渡る出荷指示と出荷実績、工程4から経理部へ渡る売上データが連携の対象です。境目を横切る入出力が5本を超えるなら、線の位置を見直す合図と考えてください。連携の数だけ、データの形式合わせとエラー時の運用を決める作業が増えるからです。
工程ごとの内外の判断基準は業務フローのシステム化とは？システム化業務フロー図の書き方と対象工程の選び方で詳しく扱っています。SIPOCで範囲を固め、システム化範囲と連携先を要件定義書に落とすところまでを外部と一緒に進めたい場合は、一創の要件定義・RFP作成・PMO支援でご相談を受け付けています。
SIPOCを使わない場面：手順の改善、原因の分析、1つの部署で完結する業務
SIPOCで答えが出ない問い：手順のムダ、ミスの原因、処理の実績
SIPOCは範囲と受け渡しを合意する道具です。次の問いには答えられないので、別の手法を使います。
- どの手順にムダがあるか：業務フロー図を描き、ECRSで工程を見直す
- なぜミスや遅れが起きるか：特性要因図となぜなぜ分析で原因を絞る
- 実際に何件、何時間かかっているか：システムの操作ログをプロセスマイニングで分析する
SIPOCを何度描き直しても、処理時間や差し戻しの回数は出てきません。実績の数字が必要なら、プロセスマイニングとは？仕組み・3つの分析と導入判断で説明しているように、システムに残る記録から取ります。
SIPOCを省いてよい場面：受け渡し先が1つの業務と、範囲がすでに決まっている改修
次の場合は、SIPOCを作らずに業務フロー図から始めて構いません。
1つは、1つの部署の中で完結し、受け渡し先が1か所しかない業務です。供給者と顧客の列がそれぞれ1行になり、表を作っても新しく分かることがありません。もう1つは、既存システムの画面に項目を1つ足すような、範囲が初めから決まっている改修です。
逆に、複数の部署や取引先にまたがる業務を新しくシステム化する場合は、SIPOCを省きません。範囲の合意がないまま要件定義を始め、終盤で連携先が1つ増えると、見積りと日程の両方を引き直すことになります。業務の流れそのものを作り直す規模なら、SIPOCで現状の範囲を描いた上で、BPRとは？意味と業務改善・DXとの違いの考え方で設計し直します。
SIPOCの読み方・COPISとの違い・テンプレートに関するよくある質問
SIPOCを業務整理や要件定義に取り入れるときによく出る質問に答えます。
SIPOCの読み方と、SIPOC分析・SIPOC図という呼び方の違いを教えてください。
SIPOCは「サイポック」と読むのが一般的です。SIPOC図、SIPOCダイアグラム、SIPOC分析と呼び方は分かれますが、指している手法は同じです。5列の表そのものを指すときは「図」や「ダイアグラム」、その表を使って業務の範囲や受け渡しを確かめる作業を指すときは「分析」と呼ぶ使い分けが多く見られます。社内で使うときは、どれか1つに呼び方をそろえておくと混乱しません。
SIPOCとCOPISは何が違い、どちらを使えばよいですか？
COPISは、SIPOCの5要素を顧客の側から並べ替えたもので、Customer・Output・Process・Input・Supplierの順に書きます。中身は同じです。顧客の要求から逆にたどる考え方を強調したいときにCOPISと呼びます。SIPOCの表でも、この記事で説明したようにアウトプットと顧客を先に埋めれば同じ効果が得られるので、呼び方にこだわる必要はありません。
SIPOCのプロセス列には、いくつの工程を書けばよいですか？
4〜5工程が目安です。英国の道路公社National Highwaysの手引きは、工程を最大4〜5個としています。7工程を超える場合は、隣り合う工程を1つの動詞句にまとめるか、対象の範囲を狭めて2枚のSIPOCに分けます。細かい手順や分岐を業務フロー図で描くのは、SIPOCで対象の範囲を決めた後です。工程数を抑えることで、関係者が短い会議で全体を確認できる大きさに収まります。
SIPOCのテンプレートはExcelで作れますか？
作れます。Excelの1行目に供給者・インプット・プロセス・アウトプット・顧客の5列を置き、2行目以降に工程を1行ずつ書く形で十分です。工程番号の列と、システム化範囲を検討する場合は「システム内・外」の列を足しておくと、要件定義で読み替えるときにそのまま使えます。関係者と一緒に作る会議では、付箋とホワイトボードで書いてから清書する方法も手早く進められます。
SIPOCはシックスシグマ以外の業務改善や、システム開発でも使えますか？
使えます。SIPOCは、シックスシグマの改善手順DMAICのうち、定義（Define）段階で範囲を決める道具として知られています。手法としては業務の範囲と受け渡しを整理するだけなので、事務の業務改善やシステム開発の要件定義にもそのまま適用できる手法です。AHRQは医療機関のワークフロー評価の道具として、National Highwaysは道路事業の成果物の合意の道具として紹介しており、業種を問わず使われています。
関連記事
- 業務可視化とは？4つの対象と方法・ツールの選び方、見える化を続ける仕組み：SIPOCで範囲を決めた後に描く業務フロー図と、可視化の方法の選び方です
- ECRSとは？業務改善の4原則の意味と順番、システム化・RPA化する工程の選び方：SIPOCで拾った論点を、工程ごとに見直すときに使います
- 業務要件定義とは？8つの記載項目と業務要件定義書の作り方・機能要件との階層を解説：SIPOCの次に、業務要件を文書にする段階の進め方です
- 要件定義と設計で作る図の一覧｜業務フロー図・画面遷移図とデザイナーの担当範囲：SIPOCの後に要件定義で作る図の全体像が分かります
- 業務フローのシステム化とは？システム化業務フロー図の書き方と対象工程の選び方：SIPOCで引いたシステム化範囲を、工程単位で確かめるときに
