稟議とワークフローの違い。日本独自の三大要件の話
抽象的な「コンサルティングワーク」とか「論理的思考力」などの話ばかりを続けてしまったので、もう少し具体的な専門に近いITの話題について取り上げたいと思います。
ワークフローシステム、BPMS（ビジネスプロセスマネジメントシステム）などの、一見すると汎用的に「業務をデジタル化する」ことができそうなツールの取り扱いの難しさについて、考えて行きます。ワークフローというと、Webサイト構築だとか動画編集だとか具体的な業界固有のツールの連鎖も含めた意味を持つこともあるのですが、ここではより一般的な業務を対象とした仕組みを想定しています。フォームなどに入力されデータが、予め定義されたルートに沿って複数のユーザーの間を渡って行くシステムです。
なぜ使い勝手が良さそうなこの手のツールの扱いが難しいのか、という疑問に対する出来合いの（それなりに説得力がある）解答としては、第一に、デジタルツールの導入という前提条件の変化があるにも関わらず既存の業務の流れをそのまま電子化しようとしてしまうから、ということになりますが、ここではもう少し日本という環境の特殊性（？）を含めた背景を詳しく検討します。
そもそも、日本にはワークフローという横文字が大々的に輸入されるよりも前から「稟議」という言葉がありました……
稟議とは何か
辞書で調べると、
りん-ぎ【稟議】
〘名〙 （「稟議 ひんぎ」の慣用読み）
①上位の人にはかり申しあげること。
②官庁や会社などで、会議を開くほどではない新事項が生じたとき、主管者が決定案を作成し、関係者間に回して承認を求めること。
とあり、いわゆる稟議書にあたる用法が第二義であるということと共に、元々の読み方は「ひんぎ」であったということに驚かされます。また、「会議を開くほどではない」という定義も、少し違和感があります。ある程度以上の大きさの決済が稟議を前提としていたり、記録を残す意味で会議と組合せて利用されていたり、ということもあるので。（この定義では想定されている会議の格が高い、ということなのだとは思いますが）
エリン・メイヤーの『異文化理解力』（http://www.eijipress.co.jp/book/book.php?epcode=2208）でも、そのキーコンセプトであるカルチャーマップの8つの次元のうちの2つ「リード」と「決断」に関して（平等主義ではなく）階層主義であるにも関わらず（トップダウン指向ではなく）極端な合意指向であることを日本の国民文化の世界的にも希有な特徴である、とする説明の中でこの「稟議」という言葉に触れています。中間管理職によって起票され、各レイヤーの利害関係者全員の同意やフィードバックを受け付けてから順次上位のレイヤーへと進んでいき、最終決済者が承認をするまでにすべての関係者が意見表明の機会を与えられたという前提での合意が形成される、という決済までにかかる時間が非常に長いかわりに一度下された決定が強固で実行時にはスピーディ、な仕組みであるとされています。稟議は、世界でも稀に見る個性的なシステムという扱いです。
数十年前、初めてワークフローシステムという黒船を見た日本人は、多分それを稟議の仕組みだと受け止めたのではないかと思うのですが、実際には稟議のない国で作られたシステムだったわけです。
稟議でなければ何なのか
ワークフローは業界の用語辞典などでは例えば以下の様に説明されます。
Workflow
An orchestrated and repeatable pattern of business activity enabled by the systematic organization of resources into processes that transform materials, provide services, or process information. (Software AG)
ワークフロー
材料の変換、サービスの提供、あるいは情報の処理などのプロセスに資源をシステマチックに組み込むことで可能となる、組織化され再現可能なビジネス活動のパターン。
日本語文は筆者訳
直観的な説明とは言い難いのですが、稟議書の様に、あるいは回覧板の様に文書が回ってくる、というわけではなく、（ほぼ直訳になる）「仕事の流れ」という意味あいと考えて良さそうです。
しかし、前述の通り、日本には稟議という仕組みがあります。ワークフローという言葉に元来あった、「組織的に再現可能な仕事の流れ」というニュアンスやそれをシステム化することで効率化しようという話が、そのまま合意形成のためのコミュニケーションツール（＋決済記録）である稟議のイメージにすり替わる、ということが発生したのではないかと思われます。
実際、十数年前にBPMS（ビジネスプロセスマネジメントシステム、ここでは深入りしまんし若干の嘘もありますが、ワークフロー管理システムの高級なもの、と考えて下さい）のコンサルタントの方々にインタビューした際にも、「外部システムへ連携して処理を自動化するなど単なる人同士のコミュニケーションや記録に留まらないコンセプトを実装した時ぐらいしか、導入効果を実感できない」という悩みをよく聞きました。既存の稟議や承認プロセスを流れとしてはそのまま踏襲することもできなくはないのですが、ところどころ責任範囲の境界線や想定している情報へのアクセス権限などへの考え方の違いがありそれを埋めるためにカスタマイズしていたのではコスト面で釣り合わないケースがほとんどだったそうです。システム側は、仕事が具体的にその順番で展開していくということをサポートしようとして作られているのに対し、日本のユーザはおおよそそのような順番で利害関係者に情報が展開されていけばよい、程度のイメージしか描けてなかった、ということでもあるように思います。
BPM（ワークフロー）日本三大要件
私自身はBPM/ワークフローよりもその隣接ジャンルであるECM/文書管理を主な領域としてサービス提供をしてきたのですが、文書管理システムにもワークフロー機能はついていることが多く、同時期に検討されることも多々あるため言わば2つ目の専門としてBPMを扱ってきました。その20年くらいの経験の中で、海外で設計開発されたBPMSやワークフローシステムにはほとんど見られないが、日本企業からは必ずと言ってよい程要望される3つの機能がある、ということに気がつき、日本三大要件と呼ぶようになりました。
その3つとは、
一度提出（サブミット）した入力を自発的に取り下げる「引き戻し」
決済コースの人達に実際にワークフローが回る前に連絡をする「根回し」
組織情報を元に起票者の直上の上司を決済者として設定する「上長承認」
です。
ワークフローの下流で申請等を受け取った承認者が申請者に処理を戻す「差し戻し」の機能は大抵のシステムに標準装備されています。従って、何かミスがあっても承認者に連絡を入れるなどして差し戻してもらえれば修正は可能なのですが、誤字脱字や細かい修正点に提出直後になって気がつくというのはよくある話ですし、できれば恐らくは上長である承認者の手を煩わせることなく修正を実行したいという気持ちはよくわかります。しかし、欧米の発想でかっちりと仕事の区分が分かれ、アクセス権なども綺麗に設計されたパッケージシステムなどでは、提出して処理が先に進んだ時点でその情報の持ち主は承認者側に移っていることが普通です。アクセス権も同時に管理されているので、ステータス（今、承認者のところにあって承認待ちの状態であること）情報の書き込み（修正）も承認者にしかないのです。そのため、承認者による「差し戻し」が必要になります。もし、「引き戻し」を実装しようとするのであれば、フォームの中身については書き込み権限を承認者に移すがステータス情報だけは部分的に（申請前に戻すのは許可するが、承認済みへと進めることは許可できない）申請者側に残すという整理になります。実現できないことではないですし、そういう機能をもった国産のシステムも存在しますが、一気に複雑になりますしそのようなニーズが希薄な文化のベンダーにその必要性を理解してもらうのは大変困難です。
次に「根回し」ですが、実際の電子化前の稟議でも行われていた事前の相談をここでやりたい、という要望であることもありますし、本番の前にほぼ同様の予行の申請を流す機能が欲しい、と言われることもあります。基本的にはコミュニケーションですので、必ずしもワークフローと同じ仕組みでやる必要はないとも思われるのですが、せっかく業務フローを電子化するのであればなるべく一つで済ませたいし、今と同じ感覚で仕事を続けたい、という気持ちからか、よく要望されます。稟議が合意指向の「コミュニケーション」であることがよくわかります。同じシステム上に予行と本番が雑多に並ぶのは混乱の元ではないか、という批判もあり、これも実際に実装されることは稀な機能であると思います。
最後に「上長承認」です。これはカルチャーマップでいうところの「合意指向」ではなく「階層主義」に関するものかもしれません。海外製のワークフローシステムが想定しているワークフローは職務記述書などに記載される具体的な業務部門の具体的な仕事の流れであることが多いです。そのため、各仕事を受け持つことができる、あるいはその責任を持つ人というのは組織上の所属やロールで固定的に定義することが可能です。それに対して日本の稟議や承認のフローは起票者から組織の上に向かって流れていくケースがほとんどです（上にも一度書きましたが、「ワークフローの下流」という表現にちょっと居心地の悪さがあったりします。大抵は組織的には上流なので）。そのため起票者の所属を確認し、そのユーザにとっての上位者を見つけてきて承認者として設定する、という挙動を求められることが多くなってきます。また、各社員が自分の直上の上長をバイネームで把握していて、社内のルールも直上の上長に、であるとか、さらにその上長に、という形で間接的に記述されているようなケースも多々あります。しかし、それは「仕事の流れ」の在り方としてはあまり一般的なものであるとは見なされません。（有給の申請とか、経費精算などの事務的承認に限定すれば、それなりに一般的なものと言えそうですが、「ワークフロー」という語の含意はそれよりも広い世界をターゲットとしている、ということだと思われます）
最後に
以上のような（パッケージ）ソフトウェアの設計元と利用者で文化的な背景が異なっていることによる、ギャップが、日本のIT業界で繰り返し話題になる我が国のIT活用の未熟さの問題に繋がっているのではないか、と思います。DXの手前の議論として、他にも幾つかのITにまつわる文化的ギャップの話を記事かしていこうかと考えています。
2022.6.13 追記
三大要件についてですが、以前行ったプレゼンテーションなどでは、3つ目を「上長承認」ではなく「印影の表示」していたではないか、という指摘を頂きました。確かにその通りでした…… さすがにそういう表層的な要件は少なくなって来ているような気もしますが、国産のツールだと結構ありますね、印影表示機能。
この記事が気に入ったらサポートをしてみませんか？