優れたプロセスの解剖学：SIPOCフレームワーク

プロセスを設計することは、業務卓越性に向けた最初の本格的なステップです。これはビジネスプロセスマネジメント（BPM）において構造が生まれる段階であり、一貫した結果を達成するために、業務がどのように流れるべきかを意図的に定義する段階です。まだ図表やツールの話ではなく、論理・役割・成果・ルールを整理する段階です。

設計フェーズ：その目的とは？

プロセス設計の目的は、インプットを価値あるアウトプットに変換するための、一貫性のある論理的な構造を作ることです。関係するステップ・役割・判断基準、そして「良い状態」とは何かを定義します。

このフェーズを終えると、モデル化・文書化・実行が可能な、明確に定義されたプロセスが得られます。パフォーマンスを意識した設計が理想です。このフェーズでは以下の問いに答えます：

• このプロセスの起点は何か？
• 目指すべき結果は何か？
• 誰がいつ関与するか？
• フローを支配するルールは何か？

適切に設計されたプロセスは、曖昧さを減らし、不必要な作業を最小化し、Onboarding・委任・改善をスムーズに行えるようにします。

プロセスを再設計すべきサイン

多くの企業、特に小規模・成長段階の企業では、プロセスが習慣によって形成されます。うまくいく方法を続ける——それが機能しなくなるまで。以下は、プロセスが複雑化し、意図的に見直す必要があるサインです：

• 結果にばらつきがある——うまくいくこともあれば失敗することもある。
• 手順が共有されず、特定の人の頭の中にしかない。
• 新入社員がWorkflowを習得するのに常に誰かに頼らなければならない。
• 社員が常に手動で「修正」しているか、回避策を使っている。
• 全体のフローを誰も把握しておらず、各自が自分の範囲だけをこなしている。
• あるステップの意義を問うと「ずっとこのやり方でやってきた」という答えが返ってくる。

これらの症状が現れた場合、それは単なる文書化の問題ではありません。設計の問題です。プロセスが明確に定義されていないか、時間をかけて複雑化・肥大化してしまっています。

（注：これらのサインは、最後の「最適化フェーズ」でも、より体系的な形で再度取り上げます。そこではプロセスの再設計がテーマです。）

設計すべきプロセスの見つけ方

すべてのプロセスを一度に改修することは現実的ではありません。価値を生み出すフローから始め、最も重要なものに集中することが鍵です。

バリューストリームから始める

大局的な視点を持ちましょう。「自社のビジネスにおける価値の流れは何か？」と問いかけてください。顧客との最初のTouchpointから最終的な成果物の提供まで、大きな段階は何でしょうか？

この問いに答えることで、コアプロセス（バリューストリームの根幹）が見えてきます。バリューストリームの例：

• 小売業：仕入れ → 在庫管理 → 販売 → 配送 → 入金
• サービス業：マーケティング → リード獲得 → 顧客Onboarding → サービス提供 → フィードバック
• 製造業：受注 → 生産計画 → 組立 → 品質検査 → 出荷

これらの大きな段階にはそれぞれ、独立して設計・改善できる小さなプロセスが含まれています。

バリューストリームマップを使ってこれらのフローを端から端まで整理すると、業務の全体像が見え、弱点を発見しやすくなります。

小さなプロセスへの分解

主要な段階が見えたら、それぞれを独立した管理可能なプロセスに分解します。各プロセスは独自のインプットを持ち、明確なアウトプットを生み出すものである必要があります。

例えば「営業」フェーズには、以下のプロセスが含まれます：

• リードの選別（Lead qualification）
• 提案書の作成
• 契約交渉
• 業務チームへの引き継ぎ（Handover）

これらが設計の対象となります。

Impact-Effort Matrixで優先順位を付ける

プロセスを洗い出したら、どれを先に対処するかを決める必要があります。すべてのプロセスが同じように急を要するわけではありません。中には摩擦が多く目立つものもあれば、非効率ながらも影響が限られるものもあります。

この判断を明確にするために、Impact-Effort Matrixを活用しましょう。プロセスを再設計した場合の効果と、そのために必要な労力を比較するシンプルなツールです。

対象プロセスをリストアップし、次の2つの問いを立てます：

効果（Impact）： このプロセスを再設計すると、顧客体験の改善・コスト削減・業務の円滑化にどれほど貢献するか？

労力（Effort）： この再設計にはどれだけの時間・リソース・変更管理が必要か？

各プロセスを以下のグリッドにプロットします。

まずは「クイックウィン（即効性の高い改善）」を探しましょう。効果が高く、修正しやすいプロセスです。これにより勢いと自信が生まれ、課題を素早く解消できます。

一方、効果・労力ともに高いプロセスは、後から取り組む大型イニシアチブとして位置付けることができます。

ただし、最も問題を抱えているプロセスが最も目立つとは限りません。 発見するための方法：

• 現場スタッフに聞く：「毎週最も負担に感じる作業は何ですか？」
• 顧客クレームを確認：フルフィルメント・Onboarding・請求処理に関連しているか？
• 繰り返される回避策を観察：システムがあるべき場所でスプレッドシートが使われていないか？承認が常に遅延していないか？
• 接点を振り返る：顧客やベンダーに謝罪する頻度が高い場面はどこか？

これらのシグナルが、再設計すべきプロセスを示しています。

プロセスを設計するステップ：SIPOCフレームワーク

プロセスには多くの詳細が絡み合い、設計時に迷いがちです。しかし、SIPOCのようなシンプルなフレームワークを使えば、道筋が見えてきます。

もともとは品質管理やSix Sigma（シックスシグマ）の実践で使われていたSIPOCは、文書化や自動化に入る前にプロセスを定義・構造化するための高レベルのツールです。

SIPOCの各文字は以下を表します：

• S – Suppliers（供給者）
• I – Inputs（インプット）
• P – Process（プロセス）
• O – Outputs（アウトプット）
• C – Customers（顧客）

SIPOCを使うことで、複雑な図を描く前にプロセスの目的・範囲・ロジックを明確にできます。

ここでは「生産引き継ぎプロセス（Production Handoff Process）」の設計例を取り上げます。このプロセスは顧客の注文確定後に始まり、その注文が正式に生産チームへ引き渡されたところで終わります。

Customer（顧客）：このプロセスは誰のためのものか？

終わりを念頭に置いて始めましょう。このプロセスの恩恵を受ける顧客を特定します。

• 内部顧客（例：別部門）か、外部顧客（例：取引先）か？
• このプロセスから何を期待しているか？
• プロセスが成功したとどのように感じてもらえるか？

生産引き継ぎプロセスの場合：

• 顧客：社内の生産部門
• 期待：詳細が完備された、すぐに製造に着手できる注文書

Output（アウトプット）：プロセスは何を生み出すべきか？

次に、成果物を定義します。

• プロセスが成功した場合の結果はどのようなものか？
• 品質・完全性・納期においてどの基準を満たす必要があるか？
• アウトプットはどのように顧客に届けられるか？

生産引き継ぎプロセスの場合：

アウトプット：製造可能な作業指示書。以下を含む：

• 最終的な顧客仕様
• 承認済みの設計図
• 確定した部品表（BOM）
• 生産開始予定日

Process（プロセス）：目的を達成するための主要ステップは何か？

アウトプットを念頭に置き、それを実現するために必要な主要ステップを整理します。

• プロセスを開始するトリガーは何か？
• 始まりから終わりまでの主要な活動は何か？
• 必要な判断やチェックポイントは何か？

4〜7の高レベルステップで明確かつ論理的なフローを目指してください。例外処理は後回しにして、理想的で再現性のある流れに集中します。

生産引き継ぎプロセスのステップ：

• 注文要件の確認
• 顧客との設計・図面の確定
• BOMと調達可能性の承認
• 生産スロットの設定（キャパシティに基づく）
• 社内作業指示書の発行

Input（インプット）：何が揃っていれば開始できるか？

プロセスのステップを逆算します。

• 作業開始前に何が揃っている必要があるか？
• 関連する書類・ツール・システムはあるか？
• 開始時点での遅延やエラーの一般的な原因は何か？

生産引き継ぎプロセスのインプット：

• 顧客の署名済み注文書
• 初期設計仕様またはカスタマイズメモ
• 営業・技術チームからの暫定部品表（BOM）
• 目標納期

Supplier（供給者）：インプットはどこから来るか？

最後に、インプットの供給元を定義します。

• どのチーム・担当者・システムが供給の責任を持つか？
• 供給は安定しているか？安定していない場合、プロセスをどう設計してカバーするか？

生産引き継ぎプロセスの場合： 主に営業チーム（署名済み注文書と顧客メモの提供）が供給者となります。技術チーム（設計サポート）と計画チーム（BOMの実現可能性検討）も関与します。

SIPOCの先にあるもの

SIPOCを使ってプロセスの構造を設計したら、さらにもう一つ重要な決断があります：プロセスを誰が「所有」し、誰が「実行」するか？具体的な個人名ではなく、各ステップに責任を持つ機能やチームを定義すべきです。

プロセスオーナーの任命

すべてのプロセスには、以下の責任を負う役割が必要です：

• プロセス全体を端から端まで監督する
• 意図したアウトプットが確実に生み出されるよう管理する
• 継続的な改善を主導する

このオーナーは必ずしも実務を担当する必要はありませんが、プロセスが適切に機能することへの責任を持ちます。エスカレーション対応・パフォーマンスレビュー・変更時のアップデート調整を行います。

例： 生産引き継ぎプロセスでは、OperationsまたはPlanningマネージャーがプロセスオーナーとなり、全ての承認を揃えた上での生産への適時引き継ぎを担保します。

ステージオーナーとステージワーカーの特定

プロセスオーナーと同様に、ステージオーナーは特定のステージ内での監督責任を持ちます。彼らと緊密に連携するステージワーカーが実際の実行者です。

以下の観点で整理しましょう：

• インプットを供給するのは誰か？
• 各ステップを完了するのは誰か？
• 承認・レビューするのは誰か？
• アウトプットを受け取るのは誰か？

例：

プロセス設計セッションの進め方

プロセス設計は一人でできる仕事ではありません。プロセスはチームや部門をまたいだコラボレーションと連携が本質であるため、適切なメンバーを集めて生産的な設計セッションを開催することが、良いプロセスを設計するための唯一の方法です。

適切なメンバーを集める

プロセスオーナー・ステージオーナー・ステージワーカーを含む部門横断的なグループを招集しましょう。可能であれば、プロセスに影響を与える他のチームメンバーも加えてください。

階層への配慮も重要です。誰かの存在が他のメンバーの発言を妨げる場合は、開放的な雰囲気を醸成するためにその人物を除外することも検討しましょう。目標は、「実際にはこうやっています……」と率直に言い合える、安心できる環境を作ることです。

明確な目的を設定する

セッション開始前に、なぜこのプロセスを設計するのかをチームで合意しておきます。目的は以下のどれか？

• 改善の機会を発見するために現状プロセスをマッピングする
• トレーニング目的で文書化する
• 特定の問題（例：エラーが増加した原因）を理解する

目的を最初に明示することで、チームは関連する詳細に集中できます。例えば、ターンアラウンドタイムの改善が目的であれば、マッピング中に遅延や待ち時間に特に注目することになります。

ゲンバ（現場）ウォークを行う

Lean（リーン）の実践では、「ゲンバウォーク」とは実際に作業が行われている場所に行き、自分の目で確認することを意味します。マッピングセッションの前や最中に、実際の業務を現場——製造フロア・システム上・画面共有——で観察してみてください。それが難しければ、誰かに直近の事例をステップごとに説明してもらいましょう。

多くの場合、文書化された手順と日常的に実際に行われていることの間には乖離があることがわかります。

誰でも参加できるシンプルなツールを使う

物理的であれデジタルであれ、参加を促すツールを選びましょう。大きな紙・付箋・共有ホワイトボードツールが最適です。ステップはどんな順序で出ても構いません——後で並べ替えることができます。見た目よりも「真実」を記録することに集中してください。見栄えのいい嘘より、雑然とした正直なマップの方が価値があります。

答えを出すのではなく、問いを立てる

問いかけのアプローチは、誰かにプレッシャーをかけずに真実を引き出すのに役立ちます。ファシリテーターとして、好奇心を持って導きましょう：

• 「このステップの後に何が起きますか？」
• 「その情報はどこから取得しますか？」
• 「ここでの責任者は誰ですか？」
• 「遅延や手戻りの原因は何ですか？」

あるステップのやり方について2人が意見の相違を示した場合は、どちらか一方を否定せず、両方のバージョンを記録するか、「要確認事項」としてマークしてください。その不一致こそが、プロセスがまだ標準化されていないことを示すヒントです。

ペインポイントと気づきをマークする

マップが出来上がっていく中で、「このとき失敗することがある……」「よく待たされる……」「Xが起きたらこうする……」といった発言に注目してください。これらはプロセス改善の手がかりです。別の色の付箋やシンボル（例：問題には稲妻マーク、遅延には雲マーク）でマップ上に印をつけましょう。また、言及されたメトリクスも記録してください（例：「このステップには通常2日かかる」「この時点では週に5件のクレームがある」など）。

ペインポイントがなぜ発生するのか、チームで議論することを促してください。実際に業務をこなしている人たちは、ボトルネックやエラーの原因を知っていることが多く、解決策のアイデアも持っていることがあります。

合意と次のステップで締めくくる

現状をある程度全員が納得できるようにマッピングし終えたら（完璧でなくても代表的であれば十分）、一歩引いてグループで全体を見渡しましょう。「このプロセスを誰かに説明するとして、このマップは明確ですか？」「これが今のフローの実態であることに全員が同意しますか？」と問いかけてみてください。

このような設計セッションはプロセスを明確にするだけでなく、オーナーシップとエンゲージメントを育てます。問題の診断に携わった人は、解決策を受け入れやすくなります。そうして、スケッチが実際により良い働き方へと変わっていくのです。

設計の後は？

設計はゴールではありません。プロセスが明確に定義されたら、次はそれを伝達し、モデル化する必要があります。次の記事では、構造化されたアイデアをチーム全体が使えるビジュアルな参照資料に変えるための、フローチャートとSwimlane（スイムレーン）について解説します。