オペレーション構築の考え方：優れた業務フローはいちばん真似されにくい強みになる

Transcript

1. 00. 優れた業務フローは、いちばん真似されにくい強みになる **Subtitle:** 商品や機能より、利益を生む仕事の回し方は外から見えにくい。 **Visible layer** 機能 デザイン 価格 比べられやすい 真似されやすい **Invisible layer** 判断基準 例外対応 システム連携 改善の積み重ね 簡単には真似できない **Takeaway:** 商品だけでなく、仕事の回し方そのものを強みにする。 01
2. 01. バックヤードは、会社に残る利益をつくる **Subtitle:** 売上を直接つくらなくても、ムダやミスを減らせば、会社に残る利益は増やせる。 **Common condition** 同じ商品 同じ売上 **Heavy workflow** 手作業が多い 確認・引き継ぎが多い ミス・やり直しが多い 会社に残る利益が少ない **Lean workflow** 自動で流れる 判断基準がそろっている ミス・手戻りが少ない 会社に残る利益が多い **Key distinction** 会計上はコスト でも、役割は利益を増やすこと **Takeaway:** 「依頼をこなす部門」ではなく、「利益を増やす部門」として考える。 02
3. 02. 商品と業務フローは、最初から一緒につくる **Subtitle:** 「できた商品を回して」ではなく、残したい利益から商品と運営を一緒に決める。 **Design order** 1. いくら利益を残す？ 2. 運営に使えるお金はいくら？ 3. 商品と業務を一緒に設計する 4. この条件で回る？ **Formula** 売上 − 目標利益 − その他のコスト ＝ 運営に使えるお金 **Design together** 商品：価格・仕様・提供範囲 業務：人・自動化・例外対応 **Decision** 回る → 進める 回らない → 価格・仕様・業務を見直す **Takeaway:** 業務フローは後工程ではない。利益から逆算して、事業の一部として設計する。 03
4. 03. 100万円のコスト削減は、100万円の売上より利益に効く **Subtitle:** 売上は一部しか利益に残らない。実コストの削減は、原則そのまま利益に残る。 **Example condition** 限界利益率30％の例 **Sales** 売上 ＋100万円 原価など −70万円 利益 ＋30万円 **Actual cost reduction** 実コスト −100万円 利益 ＋100万円 **Three effects** そのまま利益に残る 毎月積み上がる 事業が伸びるほど効く **Condition:** 品質や成長を損なわず、改善費用を差し引いて、実際にPLへ反映される実コスト削減を指す。 **Takeaway:** 一度きりの節約で終わらせず、毎月効く仕組みに変える。 **Connection:** 毎月効かせるには、個人の頑張りではなく、誰がやっても再現できる仕組みにする。 04
5. 04. 人の頑張りではなく、仕組みで利益を出す **Subtitle:** 担当者が変わっても、件数が増えても、同じ品質で回る状態をつくる。 **People-dependent work** その人しか分からない その場で判断する 担当者で品質が変わる 量が増えると、人も増える **System-driven work** 判断基準をそろえる できるところは自動で処理する 例外だけ人が見る 同じ人数で、より多く回す **Result** 誰でも再現できる 事業を大きくできる 利益が残る **Takeaway:** 組織をつくるとは、成果を再現できる仕組みをつくること。 **Connection:** では、利益を生む仕組みは、どのような考え方でつくればよいのか。 05
6. 04.5. 利益を生む仕組みの5つの原則 1. 標準から始める 2. やらないことを決める 3. 例外の行き先を決める 4. 学びから更新し、理由を残す 5. 工数と結果を測る 06
7. 03.1. As-Isを正解にせず、標準のTo-Beと比べる **Subtitle:** 業務要件ごとに、今のプロセスと業界標準のプロセスを並べ、Gapの理由を確かめる。 **Example:** 申込業務 ¦ 業務要件 ¦ As-Is｜現在のプロセス ¦ To-Be｜業界標準を起点にしたプロセス ¦ ¦ --- ¦ --- ¦ --- ¦ ¦ 申込を受け付ける ¦ 紙の申込書を受け取る ¦ デジタルフォームで受け付ける ¦ ¦ 入力内容を確認する ¦ 担当者が目視でチェック。不備は電話・メールで確認 ¦ 入力時に自動チェック。不備はその場で修正 ¦ ¦ 顧客情報を登録する ¦ CRMへ手入力 ¦ CRMへ自動登録 ¦ **Question:** Gap：なぜ、紙と人のチェックが残っているのか？ **Classify the Gap** 理由がない → To-Beへ合わせる 意図して外す → その理由を説明できるか **Reasons to retain** 法規制 契約 会計 顧客価値 採算 **Rule:** システム機能を比較するのではない。同じ業務要件を満たすプロセスとして、As-IsとTo-Beを比較する。 **Takeaway:** 理由のないGapはTo-Beへ合わせる。外すなら、その理由を説明できるかを問う。 **Connection:** 次のページで、標準を理解した上で意図して外すことが、どう差別化につながるかを考える。 07
8. 03.5. 標準を知らずに、差別化はできない **Subtitle:** 標準を出発点に、どこを合わせ、どこをあえて外すかを意図して決める。 **Three levels** 1. 標準を知らない 競争優位を語る以前の状態 2. 標準を理解し、合わせる 競争のスタートライン 3. 標準を理解した上で、意図して外す 採算と理由のある差別化 **Design boundary** 競争力を生む領域：理由と採算を持って独自化する 変えてはいけない領域：法規制・契約・会計上の要件を守る 差別化しない領域：標準化する **Connection:** 仕組み化の第一歩は、価値と採算に合わない特別対応を「やらない」と決めることである。 **Takeaway:** 優れた業務プロセスは、何を仕組み化するかだけでなく、何をやらないかによって作られる。 08
9. 03.2. 5社の例外を、995社が払い続ける固定費にしない **Subtitle:** 少数の要望を、会社全体が払い続ける複雑さに変えない。 **Ratio** 995社：標準で対応 5社：特別対応 **Problem** 5社の条件を標準へ追加 1,000社が複雑さを払い続ける **Decision** 5社が生む利益・戦略価値 開発・運用・更新・リスク 上回る → 条件を決めて提供 上回らない → 条件を見直すか、やめる **Rule:** 顧客数だけで判断しない。「重要顧客だから」という言葉だけで例外を恒久化しない。 **Takeaway:** 顧客数ではなく、得られる価値と、会社全体が負う総コストで判断する。 09
10. 06. イレギュラーを、曖昧な別フローとして残さない **Subtitle:** 未知の例外を安全に受け止め、四つの行き先のどこかへ送る。 **First response** 1. いったん止める 2. 影響を限定する 3. 判断と結果を記録する **Four destinations** なくす ̶ 価値がない 標準へ吸収 ̶ 繰り返し起きる 入口で正規化 ̶ 形式だけが違う 個別サービス化 ̶ 対価が取れる **Do not:** 人の頑張りだけで回す別フロー。 **When retained** 判断基準 期限 責任者 **Takeaway:** 例外を残すなら、行き先と、判断基準・期限・責任者まで決める。 10
11. 03.4. 標準は、常に変わり続ける **Subtitle:** 標準は、画面に人が合わせる運用から、AIが仕事の場でシステムを使う運用へ変わっている。 **Example:** SalesforceのAIスタンダード **これまで** 1. Salesforceの画面を開く 2. 人がレコードを探す 3. 人が入力・更新する 4. Slackへ戻る **これから** 1. SlackでAgentforceへ依頼する 2. AIがSalesforceのデータを参照する 3. AIが更新やアクションを実行する 4. 人はSlackの中で業務を進める **Source of truth:** 顧客データ・権限・業務ロジックは、裏側のSalesforceに残す。 **Evidence** Salesforceの2026年リリースでは、営業・管理業務の大半をSlackから離れずに進められるとしている。 Salesforce社内では、86％の従業員がSlackでAgentforceを利用し、年間50万時間超の削減を見込んでいる。 **Takeaway:** システムを入れ替えなくても、仕事の入口は変えられる。新しい標準を学び、業務を更新する。 **Source:** Salesforce Help「Agentforce Pipeline Management and Agentforce Account Management in Slack」（2026）、Salesforce Newsroom「Deploying Agentforce in Slack」（2025） 11
12. 05. ミスが起きたら、人ではなく仕組みを直す **Subtitle:** 「もっと気をつける」で終わらせず、同じミスが起きにくい流れに変える。 **Bad loop** 1. ミスが起きる 2. 本人に注意する 3. しばらく気をつける 4. また起きる **Better flow** 1. ミスが起きる 2. どこで防げた？ 3. 入力で防ぐ 4. 途中で見つける 5. 安全に止める 6. 判断と結果を残す 7. 次回の扱いを決める **Responsibility** 作業者：異常を報告する 設計者：仕事の流れを直す 責任者：改善を終わらせる **Takeaway:** 人を責めない。だからこそ、仕組みを直す責任は曖昧にしない。 12
13. 07. やり方も理由も、人の頭の中に置かない **Subtitle:** 手順と理由を残し、何を正とするかを一つ決める。 **Move outside the person** 人の記憶 口頭の引き継ぎ 個人だけのファイル **Keep together** どうやるか：手順・コード・システム設定 なぜやるか：判断の理由・過去の失敗・契約・法令・会計 **Source of truth** 情報の種類ごとに「正」を一つ決める 同じ情報を複製しない 人もAIも同じ入口からたどる **Takeaway:** 「どうやるか」「なぜやるか」「何が正か」を、セットで残す。 13
14. 07.7. 数字は、誰かが正しさに責任を持って初めて保たれる **Subtitle:** 毎月作られるだけで誰も使わないレポートは、計算が壊れても誤りに気づけない。 **Actual episode** 1. 前月のExcelをコピーし、今月の売上データを貼り付ける 2. 集計式の参照範囲は、前月の行数のまま残っている 3. 新しい商品や行が増えても、売上合計に含まれない 4. 誰もレポートを使わないため、誤った売上合計を数か月作り続ける **Missing question:** システムの売上合計と一致しているか？ **Root cause:** レポートを作る人はいても、その数字を使い、正しさに責任を持って見る人がいなかった。 **Required** 元データと集計方法を理解する 数字を使い、責任を持って見る人を決める システムの合計と照合し、差があれば止めて確かめる **Takeaway:** 数字の正しさは、責任を持って見る人がいて初めて保たれる。 **Connection:** 数字の正しさを守るには、まず何を正常とするかを決める必要がある。 14
15. 07.8. 正常を決めなければ、異常は見つからない **Subtitle:** 正常な範囲を先に決め、外れたときの動きまで仕組みにする。 **Define normal** 定義 データソース 計算方法 正常な範囲 変更履歴 **Detect** 正常な範囲 異常を検知 **Respond** 止める 直す 責任者へ上げる **Takeaway:** 正常・異常・異常時の責任者を、問題が起きる前に決める。 **Connection:** 正常を定義したら、改善の前後を同じ工数と結果の指標で比べる。 15
16. 07.5. 工数と結果を、改善の前後で測る **Subtitle:** 減らした作業だけでなく、何が良くなったかまで、同じ指標で比べる。 **Before** 工数：時間・件数・コスト 結果：品質・経営指標・実際に使われたか **Change** 業務を変える **After** 同じ工数指標 同じ結果指標 **Calculation** 差分 ＝ 改善効果 **Takeaway:** 改善前に指標を決め、変更後に同じ指標でもう一度測る。 **Connection:** ただし、計測そのものが新しい業務になってはいけない。 16
17. 07.6. 測るための作業で、現場を遅くしない **Subtitle:** 完全な正確さより、改善の優先順位と効果を判断できる精度を目指す。 **Do not** 全件を人が入力 計測そのものが、新しい業務になる **Automatic** タイムスタンプ 処理件数 **Selective** サンプリング 定期観測 **Result** 判断に足りる精度 改善の優先順位 改善の効果 **Takeaway:** 取れるデータは自動で取り、足りない部分だけを人が測る。 **Connection:** そして、測って減った時間が、そのまま会社のコスト削減になるとは限らない。 17
18. 09. 時間が減っても、お金が減るとは限らない **Subtitle:** 時間短縮は大切。でも、会社から出ていくお金が減るまでは「コスト削減」ではない。 **Starting point** 時間が減った その結果、何が変わった？ **Actual cost reduction** 外注費を減らした 残業代を減らした 実コスト削減 PLに反映 **Capacity only** 時間だけが空いた まだ「余力」ができた段階 将来の採用を避ける 人を別の仕事へ動かす **Four categories** 実コスト削減 将来コストの回避 余力の創出 品質・リスク改善 **Rule:** 「削減時間 × 時間単価」は、利益ではなく参考値。 **Takeaway:** 時間×単価で終わらせず、実際に減ったお金か、生まれた価値まで確かめる。 18
19. 09.5. 空いた時間は、放っておくと別の仕事で埋まる **Subtitle:** 効率化だけでは人は自然に動かない。空いた人と時間の行き先を、先に決める。 **DeNA example** AIで業務を大幅に効率化 空いた時間で「やりたかった仕事」を始める 新規事業への人材シフトは想定ほど進まない 結論：人を先に動かす **Management actions** 外注を減らす 採用を止める 欠員を補充しない 人を別の仕事へ移す 移動先の成果を測る **Rule:** 一人月分の時間を減らすだけでは、まだ利益は増えない。 **Takeaway:** 空いた時間を利益や新しい価値へ変えるところまで、先に決める。 **Source:** DeNA公式「DeNA南場智子『先に動かし、事業を広げる』スピーチ全文書き起こし」 https://fullswing.dena.com/archives/100189/ 19
20. 10. 強い組織は、仕事を回すたびに賢くなる **Subtitle:** 社内の問題も、変わり続ける標準も、次の仕組みに戻していく。 **Two inputs** 社内からの学び：例外・ムダ・失敗 外からの変化：標準・技術・法規制 **Loop** 1. 業務の結果と標準の変化を観測する 2. 例外・ムダ・ズレを見つける 3. 残す、変える、やめるを判断して記録する 4. ルール・システム・ドキュメントを更新する 5. 次の実行結果を確かめる **Result** 速くなる 安くなる 正確になる 事業を大きくしやすくなる **End state** 真似されにくい強みになる **Takeaway:** 社内の学びと標準の変化を次の仕組みに変える。その積み重ねが、いちばん真似されにくい強みになる。 20