ビジネスプロセスの改善に終わりは来ない。「改善」の先には、また新たな「課題」が見つかる。

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 スイートは、こうした設計・実行・監視・改善のサイクルを一体として支え、改善を日常業務の中で回し続けるための基盤となる。継続的な業務改善を実現するためには、「気づいたら改善する」のではなく、「改善が回り続ける仕組みを維持する」ことが重要だ。

ワークフローアプリ間の連携

Questetra BPM Suite では、

　「ワークフローアプリX」（親アプリ）の途中で、
　「ワークフローアプリY」（子アプリ）を呼び出す

という形で、ワークフローアプリ同士を連携させることができる。

• Step1. 子アプリに［メッセージ開始イベント（HTTP）］を配置し、アプリを予め稼働（リリース）させておく。

• Step2. 親アプリに［サービスタスク（子プロセス開始）］を配置、呼び出す子アプリを指定し、アプリを稼働（リリース）させる。

利用するモデリング要素

※［メッセージ送信中間イベント（HTTP）］を用いる方法もあるが、本記事では触れない。

連携させる理由

「ワークフローアプリ同士を連携させる理由」（ワークフローアプリを分割する理由）は様々だ。主な理由は次の6つ。

1. フローの可視性

大きなフローを小さな単位に分けることで、個々のフロー図がシンプルになり、関係者が理解しやすくなる。

2. データの共通化

親プロセスの業務データが子プロセスへ自動転記されるため、入力ミスのリスクを削減できる。

3. フローの再利用性

よく使う手順（例：法務審査、翻訳、検品）を子アプリ化しておくことで、複数の親アプリから利用できるようになる。

4. スケーラビリティ

親アプリ内のループ構造から子プロセスが複数起動される設定にすれば、「1対多」の親子関係を容易に実現できる。

5. 責任範囲の明確化

親アプリ「請求フロー」を営業部に担当させ、子アプリ「入金確認フロー」を経理部に担当させる等、データ閲覧権限やプロセス改善責任を切り分けられる。

6. トラブル隔離とリトライの簡素化

子プロセスがエラーになった場合でも、子プロセスだけ再実行できるようになる。障害対応負荷を下げることができる。

具体的な利用例

このように、ワークフローアプリを適切に分割して連携させることで、可視性・再利用性・運用性の高いプロセス設計が可能になる。 Business Process Management バンザイ！