ビジネスプロセスの改善に終わりは来ない。「改善」の先には、また新たな「課題」が見つかる。
PDCA サイクルって何だっけ？
「継続的に改善し続ける」という考え方だ。たとえば、次のような違和感はすべて改善テーマになり得る。
- A. 顧客からクレームが来た
- B. セールスチームの成果が伸びない
- C. せっかく内定を出しても辞退されてしまう
- D. 毎朝「スマホ探し」の時間がかかってしまっている…
そして『課題』を感じた瞬間こそが、PDCA プロジェクトを立ち上げるチャンスとなる。（Plan ⇒ Do ⇒ Check ⇒ Act ⇒ Plan ⇒ …）
改善テーマA: 食品工場の衛生管理
- Stage.0 (課題設定): 顧客から「毛髪混入」のクレームがあった。食品加工工場としては信頼失墜の危機。再発防止が大目標。
- Stage.1 (Plan): 「Selfチェックは甘くなる」の仮説を立て、作業者同士がペアを組む「Buddyチェック制度」を設計した。毛髪はみ出しやローラーの掛け残しを互いに確認し合う。30日間の毛髪ゼロが目標。
- Stage.2 (Do): 一部の工場にて「Buddyチェック制度」を運用し、抜き取り検査を強化した。
- Stage.3 (Check): 1か月後、検査結果および顧客フィードバックを集計し、毛髪混入ゼロを確認した。なお、副次効果として、互いの身だしなみを確認する文化が生まれ、小さな異常やミスも指摘しやすい雰囲気が醸成された。
- Stage.4 (Act): 工場の「衛生管理標準」を公式に改訂し「Buddyチェック」を新入社員の教育カリキュラムとして完全に組み込んだ。毛髪以外の異物（作業服の繊維、手袋の破片など）についても管理を強化すべきではないかという議論が生まれ、新たな課題としてチームで認識された。
改善テーマB: セールス商談の競合負け
- Stage.0 (課題設定): 失注理由「価格面で競合に負けた」の割合が増加傾向にある。
- Stage.1 (Plan): 新人メンバが「強みを伝えきれていない」という仮説を立て、「費用対効果が明確化された提案書ひな型」を新たに開発した。「成約率20%→25%」を目標とした。
- Stage.2 (Do): 一部の営業チームに、新しい提案書ひな型を導入した。同時に、顧客ごとにコスト削減額・業務時間削減を数値で説明するよう徹底した。
- Stage.3 (Check): 1か月後、商談数・成約率・失注理由を分析した。「価格が高い」という理由での失注は減少しておりROI説明の効果は一定程度確認された。一方で、成約率自体は20%のままであり、価格以外の要因が成約に影響している可能性が示唆された。
- Stage.4 (Act): 新しい提案書と説明手法を全営業チームに展開し、営業マニュアルに組み込んだ。同時に「そもそも商談昇格の認識にバラツキがある」という新たな課題がチーム内で認識された。
改善テーマC: 新卒採用の内定辞退
- Stage.0 (課題設定): 近年、内定辞退率が高い。今年は、予定人数を確保できなかった。
- Stage.1 (Plan): 「内定後も会社を知ってもらう企画が必要では？」という意見をもとにフォロー施策を企画した。「内定辞退率30%→15%へ」を目標とした。
- Stage.2 (Do): 内定者に対し「職場見学＆社員交流会」というフォロー施策イベントを実施した。
- Stage.3 (Check): 内定辞退理由を分析した結果、内定辞退率30%→20%で目標には届かなかった。しかし「仕事内容への理解不足」を理由とする辞退は減少した。
- Stage.4 (Act): フォロー施策イベントを次年度の標準プロセスに組み込んだ。同時に「入社後のキャリアイメージが不明確」という声が一定数あることが分かった。
改善テーマD: 朝のドタバタ
- Stage.0 (課題設定): しばしばスマホが行方不明になる。特に朝。布団の中、ソファの隙間、まれに冷蔵庫の上。
- Stage.1 (Plan): ベッド脇に「スマホ専用トレー」を設置し、使用後は必ずそこに置くルールを設定した。「朝の探索3分→10秒」が目標。
- Stage.2 (Do): 「ここに置け」と書いたメモをトレーに貼り付けたうえでルールを運用した。
- Stage.3 (Check): 1か月経過後も、スマホ探索時間ゼロを維持した。朝の出発はスムーズになった。ただ、鍵の行方不明が顕在化した。
- Stage.4 (Act): トレーを「スマホ・鍵・財布トレー」に拡張し、生活標準プロセスとして正式採用した。しかし、寝る直前までスマホを触れてしまうことが、夜更かしを助長しているのではないか？ひいては朝のドタバタを助長しているのではないか？という新たな課題を感じるに至った。
もっとも重要な Stage は？
PDCA サイクルは「次の Plan に繋げる」のが難しい。
つまり、1回目の「Stage.1 (Plan)」には『課題』（← Stage.0）があった。しかし、2回目の「Stage.1 (Plan)」に『課題』が曖昧になってしまうのだ。 （※ Stage.0 ⇒ Stage.1 ⇒ Stage.2 ⇒ Stage.3 ⇒ Stage.4 ⇒ Stage.1 ⇒ …）
PDCA が回らなくなってしまう最大原因は『課題の消失』。n周目のStage.4（と Stage.3）は、(n+1)周目の Stage.0 を兼ねているということを自認し続けなければならない。
BPM サイクルとは？
「PDCA サイクル」が改善一般のフレームワークであるのに対し、「BPM サイクル」はビジネスプロセスの改善に焦点を当てた考え方だ。（※ Business Process Management）
「BPM サイクル」も、出発点はやはり『課題』の認識である。
改善テーマX: 問合対応プロセス
- Stage.0 (課題設定): 既存顧客から「対応が遅い」とのクレーム。たしかに緊急対応すべき問い合わせだった。
- Stage.1 (Plan): プロセスオーナーは「CS担当者によって緊急度の認識にバラツキがある」の仮説を立て、「AIによる緊急度自動判定工程」を追加した。AIが「最も緊急度が高い」と判定した問い合わせは「60分以内に一次回答」を目標とした。
- Stage.2 (Do): すべてのメール問い合わせが「緊急度」で自動分類されるようになった。
- Stage.3 (Check): 2週間の運用後、一次回答までの所要時間と顧客満足度を分析した。すべての緊急問い合わせが60分以内に回答されていた。所要時間の短縮と顧客満足度の改善を確認した。
- Stage.4 (Act): 回答担当者からのフィードバックを受け、AI判定の精度向上に取り組んだ。一方で、「緊急度だけでなく難易度も判定されるべき」との意見が上がった。
改善テーマY: 稟議決裁プロセス
- Stage.0 (課題設定): ヒューマン工程「課長承認」の滞留時間が長い。意思決定が遅い。
- Stage.1 (Plan): 「承認コメントや差戻コメントの作文に時間を要しているようだ」とプロセスオーナーは考えた。承認工程の前に「AIが承認・差戻コメントの両方を準備」を追加した。
- Stage.2 (Do): 「承認コメント案」と「差戻コメント案」がAIによって自動生成されるようになった。課長は、必要に応じて修正して、承認できるようになった。
- Stage.3 (Check): 2週間の運用後、承認までのリードタイムと滞留時間を分析した。その結果、コメント作成にかかる時間が削減され、特に軽微な案件において承認スピードが向上したことを確認した。
- Stage.4 (Act): 課長からは「判断の視野が広がった」といった肯定的なコメントが投稿されるようになった。申請者からは「不適切なコメントでは？」といった否定的なフィードバックも散見されるようになった。
改善テーマZ: Webコンテンツ更新プロセス
- Stage.0 (課題設定): コピペミスによって、ブログ原稿の「最終章」が無い状態で公開されてしまった。
- Stage.1 (Plan): プロセスオーナーは「人間コピペ」ではミスは避けられないと判断した。「下書き作成」（WordPress.com）を自動化した。コピペ漏れゼロを目標にした。
- Stage.2 (Do): ワークフローで承認された原稿（タイトル・本文・抜粋）が WordPress.com の下書き記事として自動登録されるようになった。公開担当者はレイアウトデザインに集中できるようになった。
- Stage.3 (Check): 1か月経過しても、コピペ漏れや章抜けといった単純ミスは発生しなかった。公開作業の所要時間も大幅に短縮されるようになった。
- Stage.4 (Act): ブログ原稿以外もこのワークフローが活用されるようになった。公開作業がスムーズになった一方で、文章表現の品質レビューに対する要望が増えた。AIレビューが必要では？という意見も出るようになった。
改善テーマW: 受注対応プロセス
- Stage.0 (課題設定): 注文書の内容を手作業で登録している。登録ミスが後を絶たない。
- Stage.1 (Plan): プロセスオーナーは、注文メール受信で自動的にワークフローが開始されるように変更した。また、AI工程「注文内容抽出」を追加し、注文内容がプリセットされるようにした。「受注登録ミス率10%→4%」を目標とした。
- Stage.2 (Do): 営業担当の作業は、「注文書の内容」を登録する作業から、「注文書の内容」と「プリセットされた注文内容」を見比べてチェックする作業に変わった。
- Stage.3 (Check): 商品コード・数量・納期の登録ミスは大きく減り、ミス率は1%に減少した。
- Stage.4 (Act): 営業担当のフィードバックによれば、「注文内容自体が誤っているケース」があることが分かった。見積内容との照合（差異チェック）を自動化すべきではないかという新たな課題がチーム内で認識された。
もっとも重要な Stage は？
「BPMサイクル」でも、『次の課題』を明確にし続けることが大切だ。
n周目のStage.4（と Stage.3）は、(n+1)周目の Stage.0 を兼ねているということを自認し続けなければならない。
BPM サイクルには BPM スイートが重要になる
こうした「BPM サイクル」を現実の業務で回し続けるには、設計・実行・監視・改善を支える基盤が必要になる。
たしかに「BPM サイクル」を人手だけで回すことは不可能ではない。しかし効率よく回すためには、PDCA の各ステージを支える機能を一式で提供する「BPM スイート」が便利だ。たとえば “Office Suite” は、ドキュメント・表計算・スライドアプリを一式まとめて提供している。
『Questetra BPM Suite』では、次のような機能を提供している。
Plan (Design):
- フロー設計機能: プロセスオーナーは、ビジネスプロセスやビジネスデータをモデリングする。結果、業務の流れやデータ項目が「見える化」される。
- 分岐設定、メール自動送信設定、メール待ち受け設定、フォーム待ち受け設定、PDF自動生成設定、子プロセス連携設定、ECMAScript処理設定、など
- 割り当てルール編集機能: プロセスオーナーは、各工程のタスク処理候補者（引き受けルール）を設定する。
- 業務データ編集機能: 文字列型、数値型、日付型、日時型、ファイル型、テーブル型、など。
- ※ IT業務統制機能、プロセスデザイン機能などとも呼ばれる。ワークフロー図の定義には国際標準記法 BPMN が活用されることが多い。
- ※ 単に、モデリング機能、Design-Time 機能、設計機能、開発機能と総称されることもある。
Do (Execute):
- リリース機能: プロセスオーナーは、モデル（ワークフローアプリ）を業務システムとして運用し、適宜バージョンアップする。
- タスク処理機能: 一般社員は、マイタスクを処理する。自分に割り当てられたタスクを、そのまま日常業務として処理できる。
- ※ 単に、ワークフロー機能、Runtime 機能、実行機能、運用機能と総称されることもある。
Check (Monitor):
- 進捗ステータス確認機能: 実行中プロセスの個別の進捗を監視する。今どの工程まで進捗しているのかを把握できる。
- ヒートマップ機能: 実行中プロセスの全体分布を監視する。今どの工程が渋滞しているのかを確認できる。
- 実績データ集計機能: 全工程完了プロセスの実績（ボトルネック等）を確認する。次の改善ポイントを見つけやすくなる。
- ※ 単に、モニタリング機能、ステータスモニタリング機能、パフォーマンスモニタリング機能と総称されることもある。
- ※ 主に Runtime に活用されるが、次の Design-Time に向けた見直しにも役立つ。
Act (Optimize):
- チームチャット機能: チーム内のメンバとチャットできる。要員配置や要員シフトについて議論しやすい。
- アプリチャット機能: ワークフローアプリと紐づけてチャットできる。改善の気づきを蓄積・共有しやすい。
- 案件チャット機能: プロセスと紐づけてチャットできる。案件固有の事情を共有しやすい。
- カスタムチャンネル機能: 特定の話題に絞って議論しやすい。
- ※ 単に、社内チャット機能と総称されることもある。
- ※ プロセスオーナーは、進捗状況や実績データをもとに、必要に応じて Runtime におけるリソース配分や担当人数を最適化する。
- ※ プロセスオーナーは、ワークフローアプリの課題を認識し、次の Design-Time のヒントとする。
なお、BPM の世界では、「Plan ⇒ Do ⇒ Check ⇒ Act」を「Design ⇒ Execute ⇒ Monitor ⇒ Optimize」と呼称することもある。しかし、それらの本質は変わらない。
まとめ
PDCA も BPM も、「課題に気づき、改善を繰り返す」という考え方だ。しかし実際には、その改善は人やチームの意識に依存しやすく、いつの間にか次の課題が曖昧になり、サイクルが止まってしまうことも少なくない。
とくに BPM の場合は、「ビジネスプロセスそのものを改善する」という、より難易度の高い取り組みになる。業務の流れや役割分担、データの扱いまで含めて見直す必要があり、属人的な運用のままでは継続的に回し続けることは難しい。
だからこそ、Check（監視）や Act（改善）のステージは、ITシステムによって支えられるべき領域である。プロセスの進捗や実績データを可視化し、ボトルネックや課題を継続的に把握できる環境があってこそ、次の改善につなげることができる。
BPM スイートは、こうした設計・実行・監視・改善のサイクルを一体として支え、改善を日常業務の中で回し続けるための基盤となる。継続的な業務改善を実現するためには、「気づいたら改善する」のではなく、「改善が回り続ける仕組みを維持する」ことが重要だ。
