プロセスガバナンス：プロセス文書を最新に保つ

プロセスガバナンスでは、プロセスオーナーやモデルの変更権限、承認済みモデルの保管場所、レビューの時期を定めます。これにより、作成プロジェクトの終了後も、文書を実際の業務に即した状態に保てます。

これは一般的な定義であり、間違いではありません。このページで取り上げるのは、多くのガバナンスに関する記事で触れられていない点です。それぞれの決定事項が、実際にはどこで管理されるのか。ProcessMindでは、責任者、承認、公開済みバージョン、レビュー待ちの一覧は、ポリシー文書の条項ではなく、プラットフォームの機能です。

人、システム、責任範囲が変われば、業務も変わります。図が表すのはある時点の状態であり、知識は担当者の頭の中にとどまりがちです。責任者とレビューが明確でなければ、文書は徐々に実態と合わなくなります。

プロセスガバナンスの意味

プロセスガバナンスとは、プロセスを実際に運用する方法に文書を沿わせるための決定事項とロールの仕組みです。次の4つの実務的な問いに答えます。

• **責任者：**プロセスの責任を負う個人は誰ですか？
• **変更：**モデルを編集できるのは誰ですか？変更を承認するのは誰ですか？
• **公開：**承認済みバージョンはどこで管理しますか？
• **レビュー：**モデルが現在の業務を反映しているか、いつ確認しますか？

プロジェクトガバナンスは、合意した範囲の納品に重点を置きます。ITガバナンスは、テクノロジーのリスクに重点を置きます。プロセスガバナンスはプロセスそのものを対象とし、プロセスを導入したプロジェクトの終了後も続きます。

重要なプロセスについて、この4つの問いに答えられれば、運用の基盤が整っています。答えられない場合、チームは同じプロセスを何度も、毎回最初から文書化することになります。プロセスアーキテクチャを整えると、繰り返し行われる文書化を1か所にまとめられます。

プロセスガバナンスの枠組みで決めるべき4つの事項

最初のガバナンス会議の準備には、次の表をご利用ください。各プロセスについて、決定事項、担当者、決定が実施されていることを示す根拠を記録します。

ルールは必要な範囲にとどめてください。ProcessMindではプロセスオーナーが承認者を務めるため、長い承認手順ではなく、各変更の判断者と結果が明確になります。承認済みモデルを見つけやすい場所に置き、プロセスの変更頻度やリスクに応じてレビュー日程を設定してください。ガバナンスと公開の仕組みでは、ワークフローを順を追って説明しています。

4列目は、多くのガバナンスの枠組みで見落とされている点です。文書にしか記載されていない決定は単なる方針ですが、プラットフォームに組み込まれた決定は、実際の制約として機能します。責任者が項目として設定され、レビューが一覧に表示され、公開済みバージョンだけが閲覧者に見える仕組みなら、ルールを定めた担当者が異動した後も運用を続けられます。

プロセス文書が古くなる理由

文書と実態のずれは、妥当な例外対応から始まることがよくあります。承認の工程で滞留が起きたため、マネージャーが特定のケースではその工程を省略することに同意します。滞留は解消されますが、例外対応を正式に終了する人はいません。新しい進め方が定着しても、モデルには以前の承認工程が残ったままです。

文書が信頼されなくなると、確認されなくなります。次の変更にも気づきにくくなり、実態とのずれが広がります。実際には例外対応が記録されないことも多く、レビューではなく監査の際に初めてずれが見つかります。根本的な原因は、モデルが正式な記録として扱われず、業務が変わっても判断を促す仕組みがないことです。モデルをガバナンスの行き届いたプラットフォームに置けば、変更を記録する場所ができます。バージョン、承認によって正式な状態にする責任者、公開状態、レビュー日を管理できます。ガバナンスは単なるリマインダーではなく、ワークフローの一部になります。

プロセスガバナンスに必要なロールと責任

実務に役立つプロセスガバナンスモデルは、3つの役割から始まります。小規模な組織では、1人が複数の役割を担う場合もありますが、責任の範囲は明確にしておきましょう。

プロセスオーナーの責任は明確です。提案された変更が実際の業務を正しく反映しているかを判断し、その決定を確定させる権限を持ちます。この判断が正式な承認となります。オーナー自身がモデルを編集したり、文書化を維持したりする必要はありません。ProcessMindでは、変更の進行を追いかける必要もありません。プロセスに対してレビューが依頼されると、オーナーのレビュー待ち一覧に表示され、承認するとそのバージョンが公開されます。プロセスアーキテクトは、カタログ全体の一貫性を保ちます。コンプライアンス承認者を加えるのは、統制上、2人目の署名が必要な場合に限ります。通常は承認者を1人にできます。役割を区別して記録し、暗黙の了解に頼らないことが、プロセスオーナー制を機能させる条件です。

RACIマトリクスで責任を割り当てましょう。初めて設定する場合は、RACIテンプレートから始められます。同じ役割をチームごとに定義し直さず、モデル間で共通して使えるよう、ロールライブラリを一元管理しましょう。

役割とあわせて、レビューの頻度も決めましょう。関連する変更があったときにレビューし、アクティブなプロセスは定期的に見直します。

まず、どのプロセスをガバナンスの対象にすべきですか？

組織内のすべてのプロセスではなく、特に重要なものから始めましょう。収益を生み出すプロセス、規制当局の注目を受けるプロセス、多くの引き継ぎを伴うプロセス、過去1年間に頻繁に変更されたプロセスを優先します。

対象範囲を明確にしましょう。オーナー、承認者、レビュー日が設定された小規模なカタログのほうが、誰も信頼していないオーナー欄を含む大規模なカタログより役立ちます。ガバナンスの対象にする準備が整うまでは、ほかのモデルを参考資料として扱い、プロセスカタログで両者を区別できるようにしましょう。プロセス文書化のガバナンスは、どのプロセスを管理対象とし、どのプロセスを記述だけにとどめるか、その線引きから始まります。

ツールを選ぶ前に、オーナーを決めましょう。カタログでモデルを整理することはできますが、誰が責任を持つかまでは決められません。プロセス文書化では、モデル、オーナー、手順を1つの記録にまとめます。

AIが作成したモデルはどのように管理すべきですか？

AIが作成したモデルにも、ほかのモデルと同じオーナー設定、承認、公開、レビューのルールを適用します。ただし、より厳密な確認が必要です。AIによる下書きは、プロセスがどのように行われているかを示す妥当そうな説明にすぎず、組織内で実際にそのとおりに業務が行われている証拠ではありません。

担当するプロセスオーナーがレビューして承認するまで、作成されたモデルは下書きのままにします。下書きの作成元を記録し、オーナーが既存のモデルと比較できるようにしましょう。承認後は、ほかの文書化されたプロセスと同じ頻度でレビューします。

ここでは、ガバナンスの効果が2つあります。人が読むガバナンス対象の記録は、同じ権限設定のもとでAPIやMCPサーバーを通じてAIアシスタントも参照できます。公開・承認済みのモデルに基づいて回答するアシスタントは、プロンプトにコピーして貼り付けた内容ではなく、プロセスの情報を参照して回答します。MCPサーバーで公開できる情報をご覧ください。

ProcessMindは、AIによるモデリング支援とバージョン履歴に対応しています。AIが作成したモデルはレビューが完了するまで下書きとして扱い、公開は別途判断してください。バージョン管理の詳細は、ProcessMindのバージョン管理に関する文書をご覧ください。

プロセス文書が今も正確だと判断できる5つのサイン

ガバナンスが機能しているかどうかは、根拠を示せるかで判断できます。ここでは、私たちが確認に使う5つの項目を紹介します。いずれも理想論ではなく、ProcessMindで実現できることです。

**1. 重要なプロセスのオーナーをすぐに特定できます。**答えが部門名だったり、古いメールを探さないとわからなかったりする場合、責任者が記録されていません。ProcessMindでは、オーナーがプロセスに設定され、カタログにも表示されるため、検索すればすぐに確認できます。

**2. 変更内容と承認者を確認できます。**変更を覚えているだけでは記録になりません。すべてのモデルにバージョン履歴があり、権限に基づく承認操作によって、プロセスは下書き、レビュー中、承認済み、公開済みへと進みます。監査ログには、その履歴が残ります。

**3. 公開済みのバージョンが使われています。**同僚が個別にコピーを保管しているなら、共有モデルは信頼されていません。ProcessMindでは、プラットフォームとプロセスポータルの両方で、閲覧者に1つのバージョンを公開します。どのバージョンが最新か、迷う余地がありません。

**4. レビュー日が最新です。**誰にも把握されていない期限超過のレビューは、日付を設定しないよりも問題です。カタログの「自分のレビューが必要」一覧には、各オーナーの対応待ち項目が表示されます。これにより、レビューは単なる予定ではなく、担当者が明確なタスクになります。

**5. プロセスの記録をもとに監査の質問に答えられます。**複数のフォルダーに散在する証拠を集め直すには、何週間もかかることがあります。ProcessMindでは、オーナー、バージョン、承認、添付文書が1つの記録にまとまっており、エクスポートして提示できます。

これらの確認項目が意味を持つのは、実際の業務を反映している場合だけです。レビュー日が完了になっていても、誰かがモデルを読んだ証拠にはなりません。役割とレビュー待ち一覧があるのは、確認項目に担当者と実施時点を結び付けるためです。

すでにプロセスがプラットフォーム上で管理されているなら、5つの確認項目のために新しいツールを導入する必要はありません。モデリングプラットフォーム上でプロセスを管理する利点は、証拠が業務の一部として記録されることです。四半期末に誰かが報告書をまとめる必要はありません。

プロセスガバナンスを実務に取り入れる方法

すでに担当しているプロセスを1つ選び、方針を書く前に、そのモデルで4つの判断を実際に行いましょう。

1. オーナーを決める

   部門ではなく、個人をプロセスオーナーにします。2人で共同担当にすると、どちらにも責任が明確になりません。

2. 編集者と承認者を決める

   モデルを変更する人と、承認する人を分けます。ProcessMindでは、承認者はプロセスオーナーです。統制上必要な場合に限り、コンプライアンス承認者を追加します。

3. 1つのバージョンを公開する

   公開済みモデルを最新バージョンの唯一の基準とし、閲覧者にはコピーではなく、そのバージョンを共有します。

4. レビューを設定する

   レビュー日を設定し、レビュー待ち一覧を使いましょう。期限を過ぎた確認にも、意欲だけでなく担当者が必要です。

5. 5つの項目を再確認する

   1か月後に、上記の5項目をもう一度確認します。答えを見つけるのに検索が1回以上必要なら、次にその項目を改善しましょう。

ProcessMindでは、オーナー、承認、バージョン履歴、公開済みの記録を一元管理できます。そのため、ガバナンスは文書で求めるだけでなく、プラットフォーム上で徹底できます。オーナーの役割については、RACIの解説とRACIテンプレートで、役割の割り当て方を確認できます。成果に責任を持つ人がいない場合に何が起きるかについては、プロセスマイニングプロジェクトが停滞する理由をご覧ください。