ブログ

こんにちは！矢作です！

ワークフローシステムや簡易データベースシステムの様に、自分たちでデータの入力画面を作れるクラウドサービスが多く存在します。そのようなシステムでは、データ入力の手段に「選択入力機能」が用意されています。選択入力機能は、用意された選択肢の中から適切なものを選ぶと、データ入力が完了する、というとても便利な機能です。

選択入力機能は、入力の手間を減らすだけでなく、誤入力も防止できるというメリットがあります。しかし、選択入力機能が役に立つのは “選択肢” が適切にメンテナンスされていることが前提です。

複数の業務で利用される選択入力機能の場合には、ひとつの選択肢マスターデータが利用される仕組みを活用すると、メンテナンスの手間が削減されます。

本記事では、マスターデータの更新頻度が高い場合の課題を解決する、更新作業の自動化について紹介します。

選択肢マスターデータの自動更新が必要な理由

選択肢のメンテナンスコストに関する図をご覧ください。

選択肢のメンテナンスコスト – 更新頻度と業務の数との関係

この図では、

• 選択肢更新の頻度
• その選択肢を必要とする業務の数

に応じて、選択肢のメンテナンスコストがどうなるのかを示しています。選択肢マスターデータを用意することで解決できるのは、「その選択肢を必要とする業務の数」が多いときのみです。選択肢の更新作業を、1日に1度、数時間置きに1度、というようなペースで行わなければならない場合、選択肢マスターデータを用意するだけでは十分に対応できません。選択肢マスターデータの更新は、次の2つの作業で行われます。

• 新しい選択肢マスターデータを用意する
• 用意した選択肢マスターデータをシステムにセットする（アップロードする）

これらを1日置き、数時間置きに行うには、大きな手間が発生します。また、ミスが発生する可能性も高くなります。
このような課題を解決するために、選択肢マスターデータの更新作業を “自動化” することが求められます。

選択肢マスターデータ自動更新の仕組み

実際に、選択肢マスターデータが自動更新される仕組みは、そのシステムにより様々です。ここでは、クラウド型ワークフロー「Questetra BPM Suite」に備わっている仕組みを紹介します。前節で、選択肢マスターデータの更新は次の2つの作業で行われると紹介しました。

• 新しい選択肢マスターデータを用意する
• 用意した選択肢マスターデータをシステムにセットする（アップロードする）

Questetra BPM Suite では、この流れをワークフロー図に描いて設定することで、選択肢マスターデータの更新を自動化することができます。
例えば、次のワークフロー図では、クラウド型簡易データベース kintone アプリに登録されているデータから、選択肢マスターデータが更新されます。

選択肢マスター自動更新ワークフロー

このワークフローでは、次の作業が毎日5:00に自動的に処理されるようになっています。

• kintone アプリに格納されたデータをダウンロード
• ダウンロードされたデータを、選択肢マスターデータとして登録

この例では、kintone アプリのデータをダウンロードしていますが、他にも Google スプレッドシートに登録されたデータも対象とすることが可能です。また、独自にスクリプトを組むことで、他のクラウドサービス(Salesforce など)に登録されたデータをダウンロードすることもできます。

Questetra BPM Suite では、ワークフロー図に選択肢マスターを登録するまでの流れを描き、簡単な設定を行うだけで、選択肢マスターファイルが自動更新される仕組みを構築できます。

まとめ

データ入力画面における選択入力機能は大変便利な機能ですが、その選択肢のメンテナンスコストが大きくなることがあります。

更新頻度が高い場合には、その更新作業が自動化されるようにすることで、手間が小さくなったり、ミスが防止されたりします。クラウド型ワークフロー「Questetra BPM Suite」では、選択肢を更新するための手続きをワークフロー図に描き、簡単な設定をするだけで、選択肢マスターファイルが自動更新される仕組みを構築できます。

Questetra BPM Sute にご興味を持たれた人は、60日間無料でご利用いただけるトライアルがございますので、是非お申し込みください。

今回はここまで！

1. BPMの定義

「ワークフロー」と「BPM」。2つの言葉を比較するには、それぞれの「定義」が必要です。ここではまず、“Business Process Management” (BPM) の定義について考察したいと思います。

1-1. ビジネスプロセスを「最適化」に近づける活動

IT業界において絶大な影響力がある米ガートナー社による定義は、押さえておく必要があると言えます。〔Gartner, Inc: ITアドバイザリ会社, Wikipedia En Ja〕

ガートナー用語集 “Business Process Management (BPM)”

【筆者意訳】 ビジネスプロセス管理（BPM）は、『普遍的な行動規範』 （Discipline） のひとつです。すなわち、様々な手段を用いてビジネスプロセスを「発見」し「モデル化」し「分析」し「測定」し「改善」し、そして「最適化」します。そもそも「ビジネスプロセス」は、ビジネス戦略に沿う成果をあげるため、人・システム・情報・モノの挙動を制御します。しかし「手順が明確で何度でも繰り返すことができるプロセス」だけでなく、「変化し続けるプロセス」も存在していることには注意が必要です。なお、この管理活動においては（必ずしも必須とは言えませんが）多くの場合、コンピュータ（Technologies）が活用されます。従ってビジネスプロセスの管理活動は、「情報通信への投資」（IT投資）や「機械制御への投資」（OT投資）を方向づけることにもなります。

【引用原文】 Business process management (BPM) is a discipline that uses various methods to discover, model, analyze, measure, improve and optimize business processes. A business process coordinates the behavior of people, systems, information and things to produce business outcomes in support of a business strategy. Processes can be structured and repeatable, or unstructured and variable. Though not required, technologies are often used with BPM. BPM is key to align IT/OT investments to business strategy.

押さえておくべきこと（大切なこと）は、

『ビジネスプロセス管理（BPM）』は、
基本的には「ITツールを指す言葉」ではない

という点です。

【筆者ぼやき】 “BPM is a discipline.” この “discipline” を翻訳するのは難しいです。本稿では敢えて『行動規範』と訳しています。辞書には「集団の規律」「組織内の統制」「キリスト教の法規」「学問分野」といった訳語もありますが、どれもシックリきません。ちなみに「BPMは学問分野である」と翻訳されているケースをよく目にします。が、その日本語訳は「シックリこない」を通り越して「誤訳だ」と感じています。原義的・哲学的〔e.g. Mフーコーの「ディシプリン」, Wikipedia En〕に言えば、「権威からの教え」といった強いニュアンスなハズです。つまり「教義」「行動指針」「行動規範」などの方が適訳だと思っています。

1-2. ビジネスプロセスを「定義」することから始まる活動

“BPM” が「行動規範」であり、部署内や全社での “取り組み” を指す言葉ということは分かりました。しかし、その “取り組み” はどのように実践されているのでしょうか？

企業における “取り組み” では多くの場合、指標やゴールが設定されます。ビジネスプロセスの管理活動においても『組織の成熟度』が参照されることが少なくありません。実践する会社によって、あるいは支援するコンサル会社によって異なりますが、基本的には「１段階から５段階」の5つのステージを参照します。（”管理対象が存在しない状態” を想定して「０段階目」が用意されている場合もあります。）

筆者自身は「0:混沌」「1:定義」「2:統制」「3:統治」「4:制御」「5:順応」くらいの表現が、日本語として適当だと思っています。

1-3. BPM活動の歴史

ところで、『ビジネスプロセス管理活動』（BPM活動）は、いつごろから実践されるようになったのでしょうか？

IT業界やコンサル業界では、BPMの理論基盤は、Fテイラーの『科学的管理法』（1910年頃）を源流とするという考え方が広く支持されています。つまり、テイラーは “労働者管理の方法論” の中で「工具手順の標準化」や「標準的作業時間の設定」などを提唱しました。100年以上経った今日に至ってもなお『組織内のワークフローを分析し調和させるマネージメント理論』として広く知られています〔科学的管理法: Wikipedia En Ja〕。そして、その「プロセスを管理する」という考え方が、1960年代の「カイゼン活動」（品質管理の方法論）、1980年代の「CMMI」（ソフトウェア開発の方法論）、1990年代の「COBIT」（ITガバナンスの方法論）などに引き継がれている、と言われています。

ここで大切なことは、

『ビジネスプロセス管理（BPM）』は、
この10年・20年に湧いて出てきた新しい考え方ではない

という点です。

よく考えれば「プロセスを管理したい」という表現自体、極めて普通のフレーズです。長い歴史の上に存在し続けている『普遍的な行動規範』なのだと思います。そして、この『ビジネスプロセス管理（BPM）』という言葉自体は、2000年代に入って注目されるようになります。それは、Gartner 社自身が『Business Process Management Suite』（BPMS）という造語を発表したことがキッカケとなります。

【筆者ぼやき】 常々思っている事ですが、「ビジネスプロセスを管理する」という行為は、社会性が高い人類にとって “極めて自然な欲求” です。極端な話、「”ビジネスプロセス管理の歴史” なんて “人類の歴史” と同じなんでわ？」などと思ってしまいます。たとえば豊臣秀吉が全国の農耕地の測量を命じた時、プロセスの概念はあったように思います。「測量手順」「役割分担」「報告書式」くらいは定義されていた（管理されていた）ような気がします。〔知らんけど〕 〔太閤検地, Wikipedia Ja〕

1-4. ところで “BPMS” というコトバは必要だったの？

『Business Process Management Suite』（BPMS）という言葉についても、米ガートナー社による定義を確認しておきましょう。

ガートナー用語集 “Business Process Management Suites (BPMSs)”

【筆者意訳】 ビジネスプロセス管理スイート（BPMS）は、BPMプロジェクトやBPM戦略を推進するためアプリケーション基盤です。すなわち、プロセス改善のライフサイクル全体をサポートします。具体的には、プロセス発見・プロセス定義・プロセス設計だけでなく、実装・監視・分析・継続的な最適化に至る全ての改善活動を支援します。一般的なソリューション（情報システム等）と異なり、モデルドリブンな手法によるビジネス担当者とIT担当者のコラボレーションでビジネスプロセスを進化させ続けることができます。

【引用原文】 Business process management suites (BPMSs) are the leading application infrastructures to support BPM projects and programs. A BPMS supports the entire process improvement life cycle – from process discovery, definition and design to implementation, monitoring and analysis, and through ongoing optimization. Its model-driven approach enables business and IT professionals to work together more collaboratively throughout the life cycle than is possible with other approaches to solution delivery.

あらめて BPMS という言葉が必要だったのは、端的に言えば「新しい技術トレンド “モデルドリブンな手法” （Model-Driven Approach） を世間に広めたかったから」なのだと思います。詳細については次章以降で少しずつ解説できればと思いますが、ここでは、

『ビジネスプロセス管理スイート（BPMS）』は、
「ITツールを指す言葉」である

という点だけ押さえておいてください。

【筆者ぼやき】 “Suite” とは「一揃い」という意味です。ホテルの「スイート（ルーム）」には “色々な部屋” がそろっています。パッケージソフトの「オフィススイート」には Word や Power Point 等を “色々なソフト” がそろっていました。ちなみに “Suite” と “Sweet” （甘い）は同じ発音です。が、背広（Suit）や水着（Swimsuit）やガンダム（Mobile Suit）の “Suit(s)” は発音が違います。〔どうでもイイ〕

1-5. BPM定義アレコレ

Gartner 以外の組織では、ビジネスプロセス管理（BPM）をどの様に定義しているのでしょうか？ おおむね、Gartner社の「必ずしもITツールを指す言葉ではない」に近い定義（表現）になっています。

• 【引用元】 ［Salesforce］BPMとは？基本的な考え方とBPMシステムを使った実践方法
  • 【引用文】 BPM は 業務管理の手法のひとつです。
• 【引用元】 公益社団法人企業情報化協会　BPM推進プロジェクト
  • 【引用文】 業務プロセスのPDCAサイクルを回して業務の成果を上げるための新しいアプローチです
• 【引用元】 ［Red Hat 自動化］ビジネスプロセス管理とは
  • 【引用文】 BPMとは、戦略的な事業目標の達成支援を目的として、ビジネスプロセス全体をモデリング、分析、最適化するプロセスマネジメントの手法です。
• 【引用元】 ［NTT DATA INTRAMART］現場からはじめる業務改革
  • 【引用文】 BPMとは、業務プロセスの現状を把握し、変更や改善を行うことで、本来あるべきプロセスに継続的に近づけていくための業務管理手法です。

その一方で、”IT ツール” を指す定義も存在するので注意が必要です。（例：国際標準仕様『BPMN 2.0』の用語集）

Business Process Model and Notation (BPMN), Glossary informative

【筆者意訳】 ジネスプロセス管理： プロセス管理（プロセスの分析、定義、処理、監視、管理など）をサポートするサービスやツールです。人間やアプリケーションレベルのインタラクションのサポートを含みます。BPMツールは、手動プロセスを削減し、部署とアプリケーション間の依頼ルートを自動制御します。

【引用原文】 Business Process Management: The services and tools that support process management (for example, process analysis, definition, processing, monitoring and administration), including support for human and application-level interaction. BPM tools can eliminate manual processes and automate the routing of requests between departments and applications.

つまり、

『ビジネスプロセス管理（BPM）』は、
基本的には業務管理手法を指すが、
文脈によってはITツール群を指す場合もある

と理解しておけばよいと思います。

2. ワークフローの定義

この章では「BPM」と比較しながら「ワークフロー」という言葉にフォーカスします。

2-1. ビジネスプロセス管理はワークフロー管理の延長線上にある

ワークフロー研究で有名なアールスト教授（特に、2000年代の「ワークフローパターン研究」や2010年代の「プロセスマイニング研究」が有名） 〔Win van der Aalst, Wikipedia En〕は、論文『BPMその動向調査』(2003) の冒頭で次のように述べています。

BPMその動向調査 / “Business Process Management: A Survey” (2003) (cached PDF)

【筆者意訳】 ビジネスプロセス管理（BPM）は、伝統的なワークフロー管理（WFM）のシステムや取り組みの延長線上にあると考えられます。 （中略） 多くの人は、ビジネスプロセス管理（BPM）は1990年代のワークフローの波に続く「次のステップ」と考えています。（中略） BPMの定義には様々なものが存在しますが、ほとんどの場合、ワークフロー管理（WFM）が明確な形で内包されています。

It can be considered as an extension of classical Workflow Management (WFM) systems and approaches. … Many people consider Business Process Management (BPM) to be the “next step” after the workflow wave of the nineties… There exist many definitions of BPM but in most cases it clearly includes Workflow Management (WFM).

そして、その10年後の論文『BPMその広範囲な動向調査』(2013)においても、同様の説明をしています。

BPMその広範囲な動向調査 / “Business Process Management: A Comprehensive Survey” (2013) (cached PDF)

【筆者意訳】 BPMは、ワークフロー管理（WFM：Workflow Management）の延長線上にあると考えられます。WFMは主に、ビジネスプロセスの自動化に焦点を当てていますが、BPMはより広い範囲なスコープを持っています。すなわち、プロセス自動化とプロセス分析だけでなく、進捗管理や作業体制までカバーしています。（中略）。伝統的なワークフロー管理（WFM）は、ビジネスプロセスを機械的に自動化することを目的としていました。人間の関与があることや管理を支援することについては、あまり考慮されていなかったと言えます。

BPM can be seen as an extension of Workflow Management (WFM). WFM primarily focuses on the automation of business processes, whereas BPM has a broader scope: from process automation and process analysis to operations management and the organization of work… Traditional WFM technology aimed at the automation of business processes in a rather mechanistic manner without much attention for human factors and management support.

これらの考え方は、2020年代に至ってもなお、IT業界内における考え方の基本になっている思います。つまり、

『ワークフロー』は、BPM の一要素である
（ワークフローシステムは、BPMS に内包される）

という認識が根付いていると思います。

【筆者ぼやき】 教授の論文 “Business Process Management: A Survey” では、ワークフロー研究者（グラフ理論の応用研究や形式言語の応用研究など）ならではの視点で BPM 定義が書かれています。興味深いのは、”見えないプロセス” を否定している点です。『我々のBPM定義ではオペレーション可能な作業工程（operational processes）に限る。つまり戦略プロセスや明示できないプロセスは除外する。プロセスが認識されている状態でなければならない点に注意して欲しい。作業工程についての情報を持ち合わせず支援などできない。』〔←うん、気持ちは分かる〕

2-2. ワークフロー技術は BPMS の１要素

ガートナー社も、「BPMS製品の選定基準」（2009年）や「iBPMS製品の選定基準」（2011年）の中で

【筆者意訳】 BPMSには10の機能領域がありワークフロー技術は1つのコンポーネント（部品）に過ぎない

と述べています。

オフィシャルな文書ではありませんが、ブログ『ワークフローとBPMのチガイ、分かってる？』（2010年）の中で、ゼンゼン違う！と訴えたこともありました。（リサーチ部門の方）

Do You Understand the Difference Between Workflow and BPM?

【筆者意訳】 BPMS にはワークフローの “進化形” が搭載されています。もっと言えばワークフローは、BPMS の10技術のヒトツにすぎません

Thus, a BPMS includes a more advanced form of workflow. Furthermore, workflow is just 1 of 10 technologies found in a BPM Suite.

さすが調査会社だけのことはあって、とてもロジカルな主張です。そして彼らは、そのコンポーネント（部品）は『プロセス・オーケストレーション・エンジン』（Process Orchestration Engine）と呼んでいます。それまでにも『ワークフロー・エンジン』という表現があったのですが、呼称の上でも「ワークフロー」を “卒業” する必要があったのかも知れません。（CF: Workflow Reference Model）

【筆者ぼやき】 たとえば（スマホを知らない高齢者から）「ケータイとスマホの違いって何？」と聞かれたとき、貴方は何と答えますか？ 恐らく答えに窮するでしょう。「アプリが使える！」や「タッチパネル操作でボタンがない！」と説明しても、きっと伝わりません。「イロイロできる！」とだけ言って実演して見せるしかないような気もします。ただ最初に「スマホには（ほぼ）全てのケータイ機能が備わっていますよ」と伝えることは重要だと思います。そして、その “多機能” がもたらすメリットとデメリットをどのように感じてもらうかがポイントなのだと思います。

【筆者ぼやき】 ガートナー社は「BPM活動を支援する製品」（BPM製品）を、より細かく区分しています。具体的には、3つの区分（「BPM プラットフォーム」⇒「BPMS」⇒「インテリジェントなBPMS」）で調査しています。乱暴に言えば、”『未来を予想する機能』を重視する場合には「インテリジェントなBPMS」を使いこなしましょう” と主張されています。〔←スケールが大きな組織では重要です。〕

2-3. ところで “ワークフロー・オートメーション” って何？

では、2020年代に入って見聞きする機会が増えた「ワークフロー・オートメーション」（Workflow Automation）とは何でしょうか？　「ワークフローの自動化」といった “直訳” も見聞きしますが、日本語として意味が通じているとは思えません。

ちなみに、ガートナー社の用語集に「Workflow Automation」は存在していません。ガートナー社は、むしろ “iPaaS オシ” （Integration Platform as a Service）です。 〔そして「Workflow Automation」と「Robotic Process Automation」(RPA) の違いについては、またの機会に…。〕

そもそも日本においては、「ワークフロー製品」という言葉には “人間が関与するもの” の印象が強く、具体的には “申請承認フロー” や “経費精算フロー” を指す場合が多くなっていると言えます。〔いわば “Human-Centric Workflow” 〕

株式会社エイトレッド有価証券報告書

ワークフロー製品とは、企業の様々な業務にかかる稟議・申請から承認・決裁に至るまでの事務フローを電子化し、業務プロセスの効率化・自動化、内部統制の強化を図る等の製品の総称であります。

ただ、前節までの「定義の歴史」を振り返れば、なんとなく想像がつくと思いますが、「ワークフロー・オートメーション」で言う『ワークフロー』は「機械を相手にした（Integration-Centric な）ワークフロー」のニュアンスです。

すなわち、今日の “Workflow Automation” をあえて日本語に訳すならば、　一連処理の全自動化（一連作業の全自動化） くらいの意味に捉えるのが良い、と思います。そして、人間が関与することなく実行され、定型作業の生産性が大幅に改善されます。

（e.g. IFTTT、 Zapier、 kissflow、 Pipefy、 Box Relay、 WorkFusion、 K2 Software、 …）

なお、専門用語を逐一日本語に置き換える（ローカライズする）のは、結局回りまわって混乱を招くことになると考えます。基本的には、世界共通語のまま利用すべき（理解すべき）だと思っています。

3. BPMS の特徴である “モデル・ドリブン” とは何か？

「Workflow システム」が「BPMS」と呼ばれるために必要となる要素『モデル・ドリブン』とは何でしょうか？

3-1. そもそも “モデル” とは？

そもそも「モデル」という言葉には、大きく「模型」と「手本」の2つの意味があります。

• プラモデル: 模したモノ。本物ではない。
• 分子モデル: 模したモノ。本物ではない。
• ロール・モデル: 理想とする人。自分とは違う。
• ファッション～: 理想とする人。自分とは違う。

つまり、BPMS の特徴として使われる

"モデル・ドリブン" という表現の『モデル』は
対象を認識するために簡略化した図など
くらいの意味で捉えるべき

だと思います。（完全には描写しきれていないが）「特長的なポイントが規定されているもの」と言っても良いと思います。

3-2. プロセスモデルとは何か？

では「プロセスを “モデル化” する」という表現は、フロー図だけを指すのでしょうか。

今日において「プロセスモデル」は、概念的に、次の3要素で規定されます。

• 業務の流れ：各工程がどのような順序で接続されるか 〔フローモデリング〕
• 業務データ：どのようなデータが受け渡しされるか 〔データモデリング〕
• 引受ルール：だれ（個人・チームの誰か・機械など）が引き受けるか 〔リソースモデリング〕

すなわち、業務プロセスを模式化するには、業務の流れ図（フロー図）だけでなく、「住所・氏名・電話番号」といった業務データや、「鈴木さん・鈴木さんが所属する部門のリーダ」といた引き受けルールも規定する必要があります。

【筆者ぼやき】 言葉としての「フロー図」は、外にも様々な表現が使われます。プロセス図・業務の流れ図・ワークフロー図・フローダイアグラム・フローチャート・工程表・などなど。私見ながら、それらに大きな違いは無いと思っています。（さすがに、それらの「違い」を考察するのは不毛に…）。なお、具体的な表記法としては『BPMN』（Business Process Model and Notation）が国際標準化されています。

3-3. モデルドリブンとは何か？

「モデル・ドリブン」（Model-Driven）の日本語訳として「モデル駆動型」という表現をよく見聞きします。が、ピンときません。

そもそもの原因は「Drive/Driven」に対応する日本語が存在しないためです。”Drive” は原義的に「勢いづける」という意味です。テニスやサッカーで「ドライブをかける」などの表現もあります。従って、

『モデル・ドリブン』とは
まず何よりモデル化を最初に行う
というシステム開発スタイル

くらいに認識するのが良いと思います。

具体的には、前節に示したように「業務の流れ」「業務データ」「引受ルール」をモデリングします。そしてそのプロセスモデルを元に（によって）、システムが実装（自動的に構築）されます。

なお、伝統的には「モデリング」（「デザイン」とも言う）の後に、プログラマによる「インプリメント」（実装）を必要とする BPMS が主流でした。ただ、近年においては、 No-Code 開発（プログラミング不要のシステム開発／ソフトウェア開発）がトレンドになっています。

そして今日では、「プロセスモデル」（「ワークフローアプリ」とも言う）が完成すれば即運用できる BPMS を志向する組織も少なくありません。（← Questetra BPM Suite !!）（←”ポジショントーク”、すみません…）

【筆者ぼやき】 私見ではありますが『データドリブン経営』（データ分析を起点に判断がなされる経営）を「データ駆動型経営」とは言うべきではないと思っています。同様に『イベントドリブン』（Event-Driven／ユーザ操作を起点に処理が走り出すプログラム）や、『締切ドリブン開発』（締切が近づいてきたことをキッカケに活性化される開発スタイル）といったジョークも、そのまま “ドリブン” で良いと思っています。よく考えれば『USB Driver』は「USBドライバ」であって「USB活性ソフト」とは言いません。世界で同じ言葉を使う方が効率良いと思っています。Tsunami（津波）や Emoji（絵文字）と同じ理屈。そして “大空翼くん” の「ドライブシュート」は、”メチャメチャ活性化されたボール” なんだと思います。〔知らんけど〕

4. 結局 Workflow と BPM は何が違うか？

それぞれの製品には、それぞれの個性があります。したがって、カテゴリ「Workflow 製品」とカテゴリ「BPM 製品」の違いを述べるのは容易ではありません。以下の「違い」では、「大まかなこと」しか言えないことをご理解ください。

なお、歴史的な考察にもあったように、BPM製品（BPMS）は「人間と機械（コンピュータ）の両方をコントロールできる」ようになります。ただ、本質的な違いは「モデル化」の有無です。つまり、Workflow と BPM の違いは、「モデルが存在することによるメリット・デメリット」を考察することになります。

4-1. 業務の流れを設定する方法がチガウ

BPM製品（BPMS）の場合、モデリングの中核はワークフロー図（BPMN図）になります。

確かにこれは極めて大きなメリットです。しかし同時にデメリットでもあります。すなわち、「ありとあらゆる流れを記述できる」という側面は、その “習熟コスト” に直結してしまいます。〔BPMNは「読む」のは簡単ですが「描く」のはソコソコ大変です。〕

しかしながら、カイゼン活動に終わりはありません。

• 案件によって経路が変わる設定
• タイムアウトで次工程に進ませる設定
• 途中で複数工程に分流させる設定
• 既定のデータ編集を自動化する設定
• 子プロセスを自動的に呼び出す設定
• 他クラウド（外部API）と自動通信させる設定
• などなど

BPM製品（BPMS）であれば、様々な流れ（Control Pattern）と、様々な制御（API Orchestration）を実現できるようになります。

4-2. 引き受けルールを設定する方法がチガウ

BPM製品（BPMS）の場合、複雑な「引き受けルール」を設定する（広い意味で「モデリングする」）ことが可能です。

• 工程の処理担当者を1人指定する（案件到着時には割当済）
• 工程の処理担当者を複数人を指名する（誰かが引き受ける）
• 工程の処理担当者をロール名で指定する（複数人の場合は誰かが引き受ける）
• 順繰りで処理担当者になるように設定する（案件到着時には割当済）
• などなど

BPM製品（BPMS）であれば、様々な仕事の割り当て方を実現できるようになります。

4-3. 業務プロセスを共有する方法がチガウ

BPM製品（BPMS）の場合、全ての業務プロセスにグラフィカルな「ワークフロー図」（BPMN図）が作成されます。また、モデリング結果を「プロセスモデル」として保存することも可能です。（Questetra BPM Suite の場合 “.qar” ファイル）

プロセスオーナーは、自部署の業務プロセスについて説明しやすくなります。また、経営層や関連部署などは、現状の業務プロセスをいつでも確認できるようになります。

4-4. 流れてきた案件の上流履歴を確認できる

BPM製品（BPMS）の場合、案件の「現在地」だけでなく、それまでの「経由地」をワークフロー図（BPMN図）上で確認できます。各工程の処理担当者は必要に応じ、上流工程の処理者を確認できるようになります。

4-5. いま流れている全案件をモニタリングできる

BPM製品（BPMS）の場合、全ての処理中案件の「現在地」を、ワークフロー図（BPMN図）上で確認できます。たとえば、滞留しがちな工程をあぶりだし、「人員増員や自動化といったアクションをとる」や「業務の流れを変更する」といったカイゼンにつなげられるようになります。〔ステータス・モニタリング〕

4-6. 過去に処理された全案件を集計できる

BPM製品（BPMS）の場合、案件担当者ごとや案件経路ごとの実績値を集計できます。たとえば、担当者ごとの実績レポートを自動化できるようになります。〔パフォーマンス・モニタリング〕

4-7. 蓄積データを細かいレベルで制御できる

BPM製品（BPMS）の場合、業務データの閲覧パーミッションを細かく設定できます。案件処理者は、「同僚や関連部署への相談」や「同僚や関連部署からの助言フィードバック」を得やすくなります。

5. おわりに

BPM活動は「カイゼンし続けること」（←”継続的なカイゼン”）にこそ、意味があります。”ちょっとした事務手続き” の中にも沢山の「課題」が隠れています。

各現場のプロセスオーナーのみなさん。『見えている業務プロセス』（モデル化されている業務プロセス）くんだけでなく、『まだ見えていない業務プロセス』（まだモデル化されていない業務プロセス）ちゃんとも、ちゃんと向き合っていきましょう。そして、小さなカイゼンを少しずつ積み上げていきましょう。お互い。。。

PS： よくある誤解

• 『ワークフローシステムが申請業務の流れに特化したシステムであるのに対し、BPMツールは受注システム・製造システムといったより大きな業務の流れが対象』
  • ⇒　それは誤解です。業務の大きさは関係ありません。“申請業務” をBPMツールで改善し続ける会社さんも沢山おられます。BPMツールは、より詳細に定義し、より詳細に管理し、そのプロセスを改善します。”申請業務” も改善対象です。
• 『ワークフローは申請や承認の業務を迅速かつスムーズに進めるためのツールであり、BPMは業務全体を分析し、問題点を解析、業務の組み換えなどを行って効率化を推進するツールです。』
  • ⇒　BPMS はワークフロー機能を内包します。つまり、BPMS も「申請や商人をスムーズに進めるためのツール」です。”包含関係にあること” が表現できていないと思います。
• 『ワークフローシステムが人の手によってフローが進められるのに対し、BPMツールは人の手による処理に加え、業務アプリケーションによる処理も行われます』
  • ⇒　これは混乱の原因になる可能性があります。”BPMツール” （BPMS）が「人による処理」と「機械による処理」の両方に対応するについては問題ありません。ただ、前半の表現は「人間作業をコントロールするワークフロー製品」（Human-Centricな製品）が多く存在していることを前提にしています。とくにグローバル視点では、むしろ「機械作業をコントロールするワークフロー製品」（Integration-Centricな製品）の文脈が多くなるので注意が必要です。
• 『紙ベース運用を改善したいという場合はワークフローシステムがおすすめ。BPMシステムは機能が豊富ですが少々オーバースペック…』
  • ⇒　そうかも知れません。。。多機能は習熟コストを要します。が、基本的には「改善し続けたいかどうか？」に依存する話だと思います。

ウチの課長は、なぜ業務フロー図を書かないのか？

こんにちは！矢作です！

先日、「ワークフローと相性抜群！？APIとは？」というタイトルの記事を書きましたが、今回も API（Application Programming Interface）に関することです。

APIがどのようなものなのか分かったら、次に取り組みたくなるのは、実際に使ってみることですよね。

今回は、API を手軽に体験・検証するための方法を紹介します。APIとは何なのかについて理解したい人は、こちらの記事を先にご覧ください。

1 API体験に必要なものは？

今回紹介するAPI体験では、Web API というものを体験していただきます。Web API は Google Workspace や Salesforce などのクラウドサービスが公開している API で、Webブラウザでホームページを見るときと同じ HTTP （と呼ばれる通信規約）を使ってアクセスします。また、Web API にアクセスする方式には REST という方式を利用します。（RESTが何なのか？はあまり気にしなくて大丈夫です）

Web API を利用するには、インターネットに繋がるパソコンがあればそれでOKです。Windows で言うところのコマンドプロンプトや、Macで言うところの「ターミナル」を利用しますが、これがない場合には、Web ブラウザで利用する方法も紹介するので、ご安心ください。

ということで、インターネットに繋がる新鮮なパソコンをご用意ください！

2 経済産業省・内閣官房 の API を使おう！

今回利用する API は、RESAS（地域経済分析システム）という、地方創生の様々な取り組みを情報面から支援するために、経済産業省と内閣官房（まち・ひと・しごと創生本部事務局）が提供するシステムのAPIです。

→ RESAS 概要

RESAS の API は、申し込み手続きをするだけで無料で利用できること、REST 方式の Web API であること、アクセスするとそれなりに面白いデータが返ってくること、から、最初に体験するには丁度いいと考えました。

ということで、まずは RESAS の API を利用するために手続きから始めます。それほどややこしくなくて、以下の手順で手続きを進めます。

• RESAS-API にアクセスする。
• 画面右上の「RESAS−API利用登録・ログイン」をクリック。
• 表示された画面のログインボタンの下にある「RESAS-API 利用新規登録」をクリック。
• 次の画面でメールアドレスや氏名などを入力し、「入力内容確認」をクリック。
• 次の画面で内容を確認して「上記内容で仮登録する」をクリック。

この後、「【本登録を完了させてください】利用登録仮完了のご案内」という件名のメールが届きます。そのメールに記載されたURLをクリックすると次のような画面が表示されて本登録が完了します。

この図に書かれている API キーがとても重要ですので、すぐに画面を閉じてしまわずに、コピーしてどこかに保存しておいてください。（exampleEXAMPLEexample…の部分）

API はインターネット上に公開されているので、そのアクセス方法さえ知っていれば、誰でもアクセスできます。良いユーザだけでなく、悪意を持ったユーザが大きなデータを取得するリクエストを大量に送りつけてくる、というようなことも簡単にできてしまいます。そのため、事前にメールアドレスや氏名の登録と引き換えに、APIキーを持っている人からのアクセスだけ許す、というような仕組みが構築されています。

これで RESAS-API の利用準備は完了です。

ちなみに、RESAS-API にアクセスすると、RESAS(地域経済分析システム)に掲載されているデータを取得できます。都道府県一覧、市町村一覧などの比較的簡単なデータから、将来人口の推計や海外への企業進出動向など、様々なデータを取得可能です。

どのようなデータを取得できるのか？また、どのような方法で取得できるのか？については、RESAS-API仕様書をご覧ください。

3 API 仕様書を見てみよう

RESAS-API仕様書の左メニューにある RESAS-API一覧を見ると、様々なデータを取得できそうなことが分かると思います。

一番上の、都道府県一覧をクリックしましょう。

すると、都道府県一覧を取得するための方法が詳しく書かれています。一番上にある、GET api/v1/prefectures という部分は、GET メソッドで api/v1/prefectures というポイントにアクセスすると、都道府県一覧を取得できるよ、ということを伝えてくれています。

今回、次の parameters は不要なため説明を省略します。

続いて responses です。API は、こちらからリクエストを送信すると、レスポンスと呼ばれるデータを返してくれます。そのデータの構成を示すものが、responses の表です。

この表は、/result/prefCode は都道府県コードを、/result/prefName は都道府県名を表すことを示しています。

最後の sample は、実際に API のエンドポイントにアクセスすると、どうなるのか？が示されています。sample の部分を見ると、

GET https://opendata.resas-portal.go.jp/api/v1/prefectures

の後に、次のような、なんだかムズカシそうな文字がつらつらと書かれています。

{
    "message": null,
    "result": [{
        "prefCode": 1,
        "prefName": "北海道"
    }, {
        "prefCode": 2,
        "prefName": "青森県"
    }, {
        "prefCode": 3,
…
…

ここは、API にアクセスする具体的な方法と、アクセス後に返されるレスポンスが書かれています。

GET https://opendata.resas-portal.go.jp/api/v1/prefectures

は、GET という方法で https://opendata.resas-portal.go.jp/api/v1/prefectures にアクセスすると、{ “message”: null, …というレスポンスが返ってくる、ことが示されています。

4 APIをつっつく（APIにアクセスする）

それでは、早速APIをつついてみましょう。何が出てくるか楽しみですね。

APIをつっつく（APIにアクセス）する方法として、本記事ではコマンドラインを利用するものと、ワークフローを利用する方法を紹介します。

API をつっつくには、RESAS-API の利用登録を完了した時に入手した API キーが必要です。

4-1 コマンドラインでAPIをつっつく

まずは Windows のコマンドプロンプトや、Mac のターミナルを使って、API にアクセスしてみましょう。

コマンドラインを入力することができる、Windows なら “コマンドプロンプト” 、Mac なら “ターミナル” を立ち上げてください。

立ち上がったら、次の文字を入力してください。

curl -H "X-API-KEY: (APIキー)" https://opendata.resas-portal.go.jp/api/v1/prefectures

その後、Enter キーを押すことで、API に都道府県一覧データのリクエストを送ることになります。

では、Enter キーを押してみましょう。すると、次のような結果が返ってきます。

{"message":null,"result":[{"prefCode":1,"prefName":"北海道"},{"prefCode":2,"prefName":"青森県"},{"prefCode":3,"prefName":"岩手県"},{"prefCode":4,"prefName":"宮城県"},{"prefCode":5,"prefName":"秋田県"},{"prefCode":6,"prefName":"山形県"},{"prefCode":7,"prefName":"福島県"},{"prefCode":8,"prefName":"茨城県"},{"prefCode":9,"prefName":"栃木県"},{"prefCode":10,"prefName":"群馬県"},{"prefCode":11,"prefName":"埼玉県"},{"prefCode":12,"prefName":"千葉県"},{"prefCode":13,"prefName":"東京都"},{"prefCode":14,"prefName":"神奈川県"},{"prefCode":15,"prefName":"新潟県"},{"prefCode":16,"prefName":"富山県"},{"prefCode":17,"prefName":"石川県"},{"prefCode":18,"prefName":"福井県"},{"prefCode":19,"prefName":"山梨県"},{"prefCode":20,"prefName":"長野県"},{"prefCode":21,"prefName":"岐阜県"},{"prefCode":22,"prefName":"静岡県"},{"prefCode":23,"prefName":"愛知県"},{"prefCode":24,"prefName":"三重県"},{"prefCode":25,"prefName":"滋賀県"},{"prefCode":26,"prefName":"京都府"},{"prefCode":27,"prefName":"大阪府"},{"prefCode":28,"prefName":"兵庫県"},{"prefCode":29,"prefName":"奈良県"},{"prefCode":30,"prefName":"和歌山県"},{"prefCode":31,"prefName":"鳥取県"},{"prefCode":32,"prefName":"島根県"},{"prefCode":33,"prefName":"岡山県"},{"prefCode":34,"prefName":"広島県"},{"prefCode":35,"prefName":"山口県"},{"prefCode":36,"prefName":"徳島県"},{"prefCode":37,"prefName":"香川県"},{"prefCode":38,"prefName":"愛媛県"},{"prefCode":39,"prefName":"高知県"},{"prefCode":40,"prefName":"福岡県"},{"prefCode":41,"prefName":"佐賀県"},{"prefCode":42,"prefName":"長崎県"},{"prefCode":43,"prefName":"熊本県"},{"prefCode":44,"prefName":"大分県"},{"prefCode":45,"prefName":"宮崎県"},{"prefCode":46,"prefName":"鹿児島県"},{"prefCode":47,"prefName":"沖縄県"}]}

ちょっとびっくりするかも知れませんが、これが都道府県一覧データです。よーく見てみると、"{prefCode":1,"prefName":"北海道"}となっているところがありますね。この場合、都道府県コード=1、都道府県名=北海道、を表します。このような組み合わせが47都道府県分含まれています。

47都道府県について、都道府県コードと都道府県名の組み合わせ（都道府県一覧）を得ることができました。

4-2 ワークフローからAPIをつっつく

次に、ワークフロー（システム）からAPIにアクセスする方法を紹介します。

60日間無料でご利用いただける「Questetra BPM Suite」というクラウド型ワークフローを利用します。紹介する方法で、APIへのアクセスを試してみたい方は、次のページから是非お申し込みください。

ワークフローから API にアクセスするとはどういうことなのでしょうか？ワークフローシステムは、ワークフロー図通りに仕事を進めていくための仕組みです。

• サポートチームが製品に関する問い合わせを受け付けて、メンバが回答案を作成する
• サポートチームのリーダが回答案をレビューしOKを出す
• メンバが回答を送信する

というように、誰が、何をするのか、が定められたものをワークフローと呼びます。ワークフローシステムを利用することで、ペーパーレス化が実現されるのはもちろんですが、業務の標準化・見える化が推進され、その結果、業務の品質及び効率が向上することが期待されます。

今回、APIへのアクセスは次のようなワークフローで実現されます。

1. 人がGOサインを出す
2. ワークフローシステムから、API にリクエストが送信される。
3. ワークフローシステムはレスポンスを受信する

この簡単なフローをワークフロー図に描き、ワークフローシステムで稼働させます。

クラウド型ワークフロー「Questetra BPM Suite」にログインし、次のようなワークフロー図を作成しましょう。次に、APIからのレスポンスが格納されるデータ項目を用意します。ここではデータ項目の名称を「response」とします。

HTTPという文字が書かれた丸いアイテムがあります。これが、API にリクエストを送信、レスポンスを受け取る部分です。このアイテムの中で、API仕様書に書かれている通りの設定を行います。

設定画面の「アクセスURL」に https://opendata.resas-portal.go.jp/api/v1/prefectures を入力します。同じ画面上の「レスポンスを保存するデータ項目」というところで、先ほど追加したデータ項目「response」を選びます。

続けて、この設定画面の中ほどにある「ヘッダ」をクリックします。ここでは API キーを設定します。ヘッダ名に「X-API-KEY」を、ヘッダの値に API キーを入力します。

ここまでできれば準備は完了です。デバッグモードを利用して、動作を確認しましょう。

• 人がGOサインを出す
• ワークフローシステムから、API にリクエストが送信される。
• ワークフローシステムはレスポンスを受信する

この流れで処理が進みますが、GOサインを出すところでは、ボタンを押すだけです。

このフローの詳細を確認する画面で response というデータ項目の箇所を見ると、コマンドプロンプトで試したときとおなじように、​​{"message":null,"result":[{"prefCode":1,"prefName":"北海道"},{... というデータが表示されています。

このように、ワークフローの HTTP 通信を行う機能を活用することで、簡単に API へのリクエストを実現することができます。

また、ワークフローではAPIから受け取ったレスポンスを業務データに使うこともできます。

例えば、問い合わせ対応のワークフローを考えます。問い合わせが入ってくると同時に、Google スプレッドシートの API にリクエストを送信し、問い合わせ履歴シートからデータを取得する、というような事を実現できます。今回の問い合わせ者が、過去にどのような問い合わせをしたことがあるのかを確認しつつ、回答案を検討することができるようになりますね。

まとめ

APIがどのようなものであるのかを知っている人でも、実際にAPIを体験したことがある人は少ないのではないでしょうか？

実際にAPIを体験してみることで、今後の業務改善やビジネス展開のアイデアが出てくるかも知れません。コマンドプロンプトを利用する方法でも、クラウドワークフローを利用する方法でもどちらでも良いので、是非、これをキッカケに API を体験してみてください。

今回はここまで！

こんにちは！矢作です。

ここ数年の間に、ビジネスの多くの現場で Google Workspace や Salesforce のようなクラウドサービスが利用されるようになりました。API (Application Programming Interface)は、このようなクラウドサービスのデータ活用等に必須のものです。

業務において、グループウェアは Google Workspace で…クラウドストレージは Box で…というように複数のクラウドサービスを使っていて、これらがうまく連動すればいいのにな〜と感じている人は、API についてよく知っておくといいことがあるかもしれません。

APIのことは知っている！APIをすぐに試したい！という人は「APIを体験してみよう」へ！

1 APIとは

APIは冒頭にもちらっと書いたように、Application Programming Interface の略です。と略を説明されてもピンときませんよね。

Interface = インターフェースとは、辞書を引くと次のように書かれています。

interface
1（異なるものの）接触面，界面
1a《コンピュ》インターフェース（◇二者間で情報のやり取りを仲介するもの；ハードウェア［ソフトウェア，ユーザ］インターフェース）；《物理学》界面（◇２つの相が接する面）
2（研究分野などの間の）共通事項

1aの 二者間で情報のやり取りを仲介するもの と書かれているように、API も二者間での情報のやり取りを仲介するものです。仲介する二者は、ソフトウェアとソフトウェアです。

APIとはソフトウェアとソフトウェアをつなぐために用意されたものと、まずはざっくりと理解しておいてください。

2 API っておいしいの？

様々なクラウドが利用されるビジネスの現場には、「格納されたデータを活用したい」という要求があります。

例えば、

• kintone (データベース) の顧客マスタを抽出し、SendGrid (メール配信) で利用できるようにしたい。
• Zendesk (問い合わせ管理) に登録された問い合わせ対応履歴が、Salesforce で利用できるようにしたい。
• Salesforce (SFA) の取引先情報を毎日抽出し、Questetra BPM Suite (ワークフロー) で利用できるようにしたい。

など、様々な要求があります。（他にもっともっとたくさんあります）

このような要求をクリアするために、それぞれのサービスでは API が作られ、その情報が公開されています。

• kintone – kintone API
• SendGrid – API リファレンス概要
• Zendesk – API Reference
• Salesforce – REST API 開発者ガイド
• Questetra BPM Suite – Workflow API

APIが公開されているおかげで、

• 格納されたデータを抽出
• データを追加
• 特定の処理を実行（メール配信など）

というようなことを実現するソフトウェアを作れるようになります。他にも、スマートフォンアプリの開発などにもAPIは利用されます。

APIが公開されていない場合、このようなソフトウェアを作れません。

• kintone (データベース) の顧客マスタを抽出し、SendGrid (メール配信) で利用できるようにしたい。

という要求を考えた場合、

• kintone の顧客マスタを手動でダウンロードし、SendGrid に手動でアップロードする
• 自動化したいなら、SendGrid は利用せずに自前で kintone と連携できるメール配信システムを構築する

というような対応が必要になり、大きな手間やコストが発生してしまいます。

それぞれのクラウドサービスが API を公開してくれることで、ソフトウェアの開発が容易になります。

ということで、APIとはおいしいものです（笑）。

3 API ってどんなもの？

クラウドサービスにおける API の形式は、Web API と呼ばれ、その中でも REST という方式がよく利用されます。基本的に、ホームページを見るときと同じ通信規約の HTTP 通信が利用されますが、REST が何なのか？については現時点では気にする必要はありません。

• API 利用側：HTTP リクエストを送信する
• API 提供側：HTTP レスポンスを返す

API利用側は、例えば、Salesforce の商談データを抽出したい場合は、抽出用のリクエストを送信します。API提供側は、そのリクエストを受け、リクエストに含まれる抽出条件を見て、抽出結果をレスポンスに含めて返します。

このような形が基本で、どのようなリクエストを送らなければならないのか？については、それぞれのクラウドサービスのAPIマニュアルに書かれています。

他にも、安全に通信を行うために、認証・認可の話などもありますが、どんどん複雑になるので、現時点ではその話は割愛します。

4 APIとワークフロー

私たちクエステトラ社はクラウド型ワークフロー「Questetra BPM Suite」を提供していますが、ワークフローとAPIの相性はかなり良いです。理由は、利用シーンがとても多いから。

• 受注承認されたら、受注情報が salesforce に格納される。
• セミナー申込を受け付けたら、受付情報が kintone に格納される。
• 見積書が承認されたら、見積書PDFが Box にアップロードされる。

などなど、様々なシーンで他のクラウドサービスとの連携が発生します。それぞれのクラウドサービスがAPIを提供しているおかげで、ワークフローからの連携がカンタンに実現されます。

次のワークフロー図は、「ノーコードでkintoneに顧客情報を自動追加」するワークフローのものですが、「kintone にレコードを追加するアイテム」がフローの最後に配置されています。

このアイテムの内部では、kintone の API にリクエストが送信され、レコードが追加されています。このような処理が、パッケージ化され、アイテムを利用する人は、kintone の API に関する詳しい知識や、レスポンスを処理する知識を持たなくても利用できるようになっています。

Questetra BPM Suite には、kintone の他、

• Google ドライブ
• Google スプレッドシート
• Google カレンダー
• Gmail
• Google BigQuery
• Microsoft OneDrive for Business
• Microsoft Excel
• Box
• Slack

の API にアクセスするアイテムが標準装備されています。

5 まとめ

APIとはおいしいものである（笑）。

クラウドサービスが多くの組織で利用されるようになった今、それぞれのサービスの機能や、格納されているデータを活用するために、APIは必須のものです。

今回の記事では、APIとはこんなものだよ、という超概要について説明しましたが、今後の記事では「APIを体験する」をテーマとした記事も書きたいと思います。→ 書きました！「APIを体験してみよう」をご覧ください。（2021-12-29加筆）

今回はここまで！

様々なクラウドサービスとAPI連携できるノーコード開発プラットフォームを試したい人は以下より無料トライアルをお申し込みください。

こんにちは！矢作です！

ビジネスの現場では、今日もいろんな会話（今はチャット？）が飛び交います。

• わたしの有給休暇申請が承認されました。来月2週間ほど、お休みをいただきます♡
• 2ヶ月かけて準備した感謝祭企画が、事業部長に承認されました。あとは社長の決裁だけですね！
• ◯◯工場の製造ラインに1億円の設備投資を行う決裁を、本日の取締役会に仰ぎます

これらの会話に含まれる「承認」と「決裁」は、同じ意味のようにも見えますし、そうでないようにも見えます。本当は明確に意味が異なりますが、どのように違うのでしょうか！？

「決裁」は組織の意思決定

「承認」と「決裁」。辞書ではどのように説明されているのでしょうか？

しょう‐にん【承認】
［名］(スル)
１ そのことが正当または事実であると認めること。「相手の所有権を―する」
２ よしとして、認め許すこと。聞き入れること。「知事の―を得て認可される」
３ 国家・政府・交戦団体などの国際法上の地位を認めること。「国連に―された国」

ビジネスの現場では、１or２の意味で使われることが多そうですね。

契約書の承認においては、法務部長が法的な視点で承認する（１の意味）場合や、営業部長の判断で値引きを承認する（２の意味）、というようなことが考えられます。

けっ‐さい【決裁】
［名］(スル)権限を持っている上位者が、部下の提出した案の可否を決めること。「―を仰ぐ」「書類を―する」

この説明を見るとまさに「決める」という意味ですね。（字の雰囲気からもそれはまざまざと感じますが）

ものすごく砕けた言い方をすると、「承認」という行為は、起案された内容について「Ｙｏｕ、それタダシイよ！やっちゃいなよ！」と言っているだけに過ぎません。しかし「決裁」は、それを実行するのかしないのかを 組織の意思として決定する ことを意味しています。

「承認」されても組織としての意思決定はされていません。「決裁」されて組織の意思決定がされたことになります。

いや「承認」で意思決定してるしー

でも、「決裁」という言葉は使われない組織もあると思います。最初の例にある、

• わたしの有給休暇申請が承認されました。来月2週間ほど、お休みをいただきます♡

では、承認の時点で意思決定がされています。この場合、「承認」という言葉は使われていますが、決裁権者である上長がヨシとしたのであれば、それは「決裁」されていることになります。

有給休暇の取得、残業、見積書の提出など、比較的軽い事項については、「承認」という言葉で「決裁」されていることが多いように感じます。

「承認」に意味はないの？

決裁権を持つ人が「決裁」する際、「承認」が重要になることがあります。

「決裁」する立場の人は、毎日、多くの意思決定を行っています。その中で、全ての起案内容について十分に理解する時間があるか？また、起案内容の良し悪しについて判断できるだけの知識や経験があるか？というと、必ずしもそうではありません。

その際に頼りになるのが、起案内容が自分に届くまでの間にされた「承認」です。

迅速かつ的確に「決裁」するために、

• 誰が承認したのか？
• 承認の際にどのようなコメントが書かれているのか？

は有効に働く場合があります。

「承認」という行為に意味があるかないか、それは承認者がどれだけ決裁者から信頼されているか？承認時に助言となるコメントを書けるか？にかかっているのかもしれません。

決裁ルール

組織においては、稟議規程、職務分掌規程というような規程で、検討すべき事項ごとに、起案、承認、決裁の権限を誰が持つのか、が定められています。このようにして定められたルールは、「決裁ルール」と呼ばれます。

決裁ルール：検討事項ごとに、起案、承認、決裁の権限者が定められたもの

例えば、京都大学の「会計職務権限規程」の職務権限一覧表で決裁ルールが定められています。次の図はその一部です。

例えば、「予算に関すること」を見てみると、「予算の要求又は申請に関することで重要なこと」という事項については、

• 起案者：掛長
• 承認者：課長補佐、課長、部長、財務担当理事
• 決裁者：総長

となっていることが分かります。また、「予算の要求又は申請に関することで軽易なこと」という事項については、

• 起案者：掛長
• 承認者：課長補佐、課長
• 決裁者：部長

とされています。

重要なことは総長が決裁し、軽易なことは部長が決裁する、という決裁ルールが定められていることが分かると思います。

決裁ルールとワークフローシステム

京都大学の「会計職務権限規程」の職務権限一覧表をご覧いただければ分かっていただけると思いますが、規程に定められているルールは大変複雑です。検討事項ごとに、適切にこのルールを適用し、承認、決裁が確実に行われるように運用することは、大変な労力が発生します。

そこで利用されるのがワークフローシステムです。ワークフローシステムを利用すると、決裁ルールに関する設定を行っておけば、自動的に適切な権限者に承認や決裁が依頼されるようになります。

私たちクエステトラ社が提供するクラウド型ワークフロー「Questetra BPM Suite」では、決裁ルールをワークフロー図に描くことで、権限者に承認や決裁が自動的に依頼されるようになります。

上図では、左の職務権限一覧表のうち「予算の要求又は申請に関すること」の決裁ルールを、ワークフロー図に描きました。

左の一覧表を見ると、「重要なこと」と「軽易なこと」で決裁者が異なることが分かります。「重要なこと」は総長が、「軽易なこと」は部長が決裁者になっています。このような違いを吸収し、ひとつの図に表現できるのがワークフロー図の良いところの一つです。

このワークフロー図は、クラウド型ワークフロー「Questetra BPM Suite」を使って描きました。このようなワークフロー図を描いてみたいという人は、無料トライアルにお申し込みください。

「Questetra BPM Suite」で描いたワークフロー図は、単なる図には終わりません。更に少し設定が必要ですが、起案画面、承認画面、起案画面を作ることができ、その画面で起案すれば、ワークフロー図に描かれた通りの流れで、権限を持つ人に承認や決裁の依頼がされるようになります。

また、重要な意思決定においては、職務権限一覧表のとおりに承認・決裁がされている記録が求められます。そのような記録も自動的に保存されるので、業務監査等への対応にかかる手間も大きく削減されます。

まとめ

「承認」と「決裁」の違いについて説明してきました。権限を持つ人が「決裁」するにあたり、「承認」されていることは重要な判断材料になることがあります。

また、「決裁ルール」は表で整理されていることが多いですが、ワークフロー図に仕上げるとより分かりやすくなります。

是非、皆さんの業務についてもワークフロー図を描いてみてはいかがでしょうか？

今回はここまで！

こんにちは！矢作です！

ビジネスの現場でよくある「決済」と「決裁」。このふたつの「けっさい」、意味は全く異なりますが、ビジネスの現場ではそれなりに登場しますよね。

本記事では、「決済」と「決裁」の違いを整理するとともに、2つの「けっさい」が関連する業務にどのような課題があるのか見ていきたいと思います。

決済とは

「決済」を辞書で調べると、次のように説明されています。

［名］(スル)代金や証券・商品、または売買差金の受け渡しによって、売買取引を終了すること。

goo国語辞典 デジタル大辞泉

“売買取引を終了すること” とあるように、取引を済ませることを決済と言います。決済されると、取引を通じて発生した、買い手・売り手の債権・債務が解消されるということになります。

例えば、自動販売機で飲み物を購入するとき、お金と飲み物の交換はその場で終わり、発生した債権・債務はすぐに解消されます（そもそも債権・債務が生じる隙きがないかも…）。この場合、”決済” は一瞬で済んでしまうことになります。

しかし、企業間での取引では、お金とモノの交換が同時でないことがよくあります。買い手はモノを受け取った後に届く請求書に基づいて、翌月の末日（例）までにその代金を売り手の銀行口座に振り込むというような手続きを行います。

この場合は、買い手はモノを受け取ってから代金を支払うまでの間は “債務” を、売り手は “債権” を持ちます。まだ債権・債務が残った状態なので、この状態では取引が済んでいない = “決済” されていない 、ということになります。

買い手が売り手の銀行口座に振り込んで、”決済” されたということになります。この場合は、決済までそれなりに時間がかかるということになりますね。

決裁とは

「決済」はお金の話でしたが「決裁」はどのような意味でしょうか。こちらは、お金が関係する場合と関係しない場合がありますね。

「決裁」を辞書で調べると、次のように説明されています。

［名］(スル)権限を持っている上位者が、部下の提出した案の可否を決めること。「―を仰ぐ」「書類を―する」

goo国語辞典 デジタル大辞泉

この説明で十分わかりやすいですね。強調するなら “案の可否を決める” のは、権限を持っている上位者である、ということでしょうか。

企業においては、様々な企画が起案され決裁されます。このとき、よくあるのは投資金額の大小に応じて、その企画を決裁できる人が変わるということです。

• 100万円未満（例：セミナー開催） → 部長決裁
• 1000万円未満（例：展示会出展） → 担当取締役決裁
• 1000万円以上（例：テレビCM企画） → 社長決裁

というように、投資金額が大きな案になるほど、上位の人が決裁権限を持ちます。多くの企業等では、このような「決裁ルール」が職務分掌規程や稟議規程などの各種規程類に定められています。

お金が関係しない「決裁」があると先に述べました。例えば、

• 従業員の休暇取得
• 人事異動
• 規程類の改訂

などが挙げられます。

「決済」業務の課題

取引に関連する「決済」については、売り手の手間が大変大きなものになっています。

モノとお金が同時に交換されるのであれば、決済はすぐに終わりますが、実際には、売り手が買い手にモノを提供してから、お金が売り手に支払われるまでに時間が生じます。売り手としては、確実に支払われるまで管理する必要があります。この管理の手間が大変大きなものになっています。

売り手は、この手間を最小限にするために、入金確認業務の自動化、督促業務の自動化などの工夫をする場合もあります。他に、クレジットカード決済サービスのように、決済に関する業務を楽にしてくれるサービスを利用する場合もあります。

「決裁」業務の課題

決裁業務は通常、起案の後、複数の承認がされた後、権限者による決裁が行われます。ややこしいのは、「決裁」の説明でも述べたように、決裁ルールが存在することです。

休暇取得の決裁は、従業員が申請し、その上長が決裁する、とシンプルです。

しかし、予算が1000万円の企画というレベルになると、規程によっては、多くの人への回覧、承認を経て、取締役会で決裁される、というような場合もあります。このような複雑なルールについては、各種規程に定められていますが、そのルール通りにマチガイなく運用する、ということが大変難しいという問題があります。

そのため、多くの企業ではワークフローシステムが利用されています。ワークフローシステムを利用すると、起案内容に応じて権限者に承認や決裁が自動的に依頼されるようになります。

以下は、決裁ルールをワークフロー図に表現したものです（クリックして大きな画像でじっくりとご覧ください）。ワークフローシステムの中には、このようなワークフロー図を作成しながら設定を行うものもあります。

このワークフローでは次のような流れで承認・決裁が行われます。

1. 申請者による稟議の提出（企画の申請）
2. チームリーダによる承認
3. 100万円以下の場合、副部長による決裁
4. 100万円より大きい場合、部長による決裁（500万円以下なら副部長による代理決裁も可能）

この決裁ワークフローはひとつの例ですが、「自社の稟議ルールをワークフロー図に描いてみたいなぁ」と思った人は、クラウド型ワークフロー「Questetra BPM Suite」の “無料お試し” にお申し込みください。60日間、無料でご利用いただけます。

決裁ルールは、どの企業でも同じではなく、企業により大きく異なります。ですので、自社の決裁ルールを反映しやすいワークフローシステムを選ぶことが重要です。

まとめ

取引を済ませることを意味する「決済」、組織における重要な意思決定を表す「決裁」。「決済」と「決裁」は、それぞれビジネスには重要なキーワードですが、まったく意味が異なりますね。

今後の記事では、「決済」業務、「決裁」業務について更に詳しく書いていきたいと思います。

今回はここまで！

「コロナ」で「テレワーク」で「リモートワーク」な時代。”請求書の保存方法” が大きく変わろうとしている。そもそも “電帳法” とは何か？ “インボイス制度” との関係は？ そして “ペポル規格” とはナンダ？ ワークフロー会社自身の実録。「新しい電子帳簿保存法」と「あるべきワークフロー」の関係を分かりやすく解説。

1. 電帳法とは何か？

デンチョウホウとは『電子帳簿保存法』のことだ。「↓デン↑チョー↓ホー」と関西弁風に発音すると、ちょっとカッコイイ？ 〔←伝わらなぁーい〕 ＼(^o^)／そして正式名称は、例によって、、、非常に長い。（37文字）

• 電子計算機を使用して作成する国税関係帳簿書類の保存方法等の特例に関する法律
• 電子計算機を使用して作成する国税関係帳簿書類の保存方法等の特例に関する法律施行令
• 電子計算機を使用して作成する国税関係帳簿書類の保存方法等の特例に関する法律施行規則

むしろ英語の方がワカリヤスイかもしれない。。。
Act on Special Provisions (←特例) concerning Preservation Methods (←保存方法) for Books (←帳簿) and Documents (←書類) Related to National Tax Prepared by Means of Computers (←コンピュータ利用で)

2. 何が書かれているの？

電子帳簿保存法には、「請求書データはソノママ保存してネ。”紙保存” はボチボチ止めてネ。」と書かれている。 〔ドッキリ〕ただ、つい最近まで、「自信ないヤツは、”紙” に印刷して7年間ほど書庫で暖めとけよ！」と書かれていた。。。 〔バックリ〕

ちなみに、”紙” で届いた請求書は “紙” のまま保存しても構わない。そこで、取引先に「請求書は “紙” で送ってクダサイ」とお願いする会社が出現しているヨウダ。。。（←「デジタル保存ワークフロー」なんて考えられない会社／考えたくない会社）。しかし、コレは、ナンボなんでも、無茶苦茶だ。国には（国税庁には）、多少のクレームは覚悟の上で、デジタル化を推進してもらいたい。「飛脚を廃止して郵便制度を創り上げるんだ！」くらいの気概をもって（←140年ほど前）。。。、

▼追記：2021-12-06） 日経新聞2021年12月6日によると「電子保存義務化２年猶予」が確定したヨウダ。

…電子保存するよう企業に義務付けるのを伸ばす…７割超が「知らない」…デジタル化が滞る日本の実情を映す。

▲追記ここまで

3. そもそも「帳簿」ってナニ？

この法律は「国税関係帳簿書類の保存方法」について規定している。なので、「帳簿」と省略されているが、「国税関係帳簿書類」（8文字）を理解する必要がある。法律文（第2条:定義）には、『国税関係帳簿書類』は　「国税関係帳簿又は国税関係書類をいう」　と書かれているのだが、見づらい＆読みづらい。 〔←いちお日本語〕　(-_-;)
目を凝らしてヨク見れば、以下の集合関係が読み取れる。（？）
　「帳簿書類」 ＝ 「国税関係 “帳簿”」（Books） + 「国税関係 “書類”」（Documents）

4. じゃ “帳簿” と “書類” はナンヤネン！(怒)

国税庁の説明資料が分かりやすい。

賢明な方はお気づきだろう。ポイントは『書類』は「発行(控)」と「受領」に大別されているところだ。つまり『書類』は企業間（や株主向け）で受け渡しされる書類を指す。たとえば「請求書」は『書類』だ。「郵送した請求書」は「発行書類(控)」だ。「受け取った請求書」は「受領書類」だ。ちなみに、、、『帳簿』の訳語は “Books” で、『書類』の訳語は “Documents” となっている。 〔分かる人には分かる〕

説明資料

• 電子帳簿保存法Q&A（トップページ）
• https://www.nta.go.jp/law/joho-zeikaishaku/sonota/jirei/4-1.htm
• 電子帳簿保存法一問一答（PDF）
• https://www.nta.go.jp/law/joho-zeikaishaku/sonota/jirei/pdf/0021006-031_03.pdf

5. で、”電帳法2022″ で何が変わった？ (呆)

“変化” については、国税庁の説明資料を、以前のバージョンと比較するとワカリヤスイ（？） 〔ウォーリーを探せ！〕

説明資料

• 電子帳簿保存法一問一答（PDF） 〔令和2年 (2020年) 6月〕
• https://www.nta.go.jp/law/joho-zeikaishaku/sonota/jirei/pdf/0020006-168_03.pdf
• 電子帳簿保存法一問一答（PDF） 〔令和3年 (2021年) 7月〕
• https://www.nta.go.jp/law/joho-zeikaishaku/sonota/jirei/pdf/0021006-031_03.pdf

「7つの間違い探しクイズ」が好きな方なら、瞬時に、以下のような変化が読み取れるだろう。。。

• 2022年から、受け取った「紙」を電子データ保存するに税務署長の承認が要らない。
• 2022年から、受け取った「電子データ」を紙に印刷してはならない。

（たしかに、折角の「電子署名」や「電子タイムスタンプ」も、、、紙に印刷しちゃったら無意味だ。〔←逐次プリントアウトする業務プロセス〕）

6. ホンデ、、、どうしたらイイん？ (疲)

特に『書類』については “ペーパーレスで一元管理” を実現したい。 〔バックリ〕「コロナ」で「テレワーク」で「リモートワーク」な、この御時世に、紙で保存するなんてアリエナイ。。。つまり、紙で受け取った請求書や領収書はスキャンして Cloud サーバに保存すればイイ。メールで届いた請求書PDFも Cloud サーバに保存すればイイ。そういう業務プロセスにしなければならない。ただ、、、その Cloud サーバ（保存環境）を使いこなせるかどうか？は、各社のITリテラシーに大きく依存する。

• 「請求書PDFが添付されたメールを “受け取っただけ”」では保存にならない。
• 「税務調査時の “ダウンロード要求”」に応じられる必要がある。

などの “保存要件” もある。すべての会社、すべてのヒトが、使いやすい「保存環境」は、、、ナイ。自社内のITリテラシーを考慮して、各社それぞれで「保存方法」（デジタル保存が自然とムリなく実現できる業務プロセス）を決めるしかない、のだ。。。 〔←答えになってない（深く陳謝）〕　

また加えて、顧問税理士や監査法人/会計監査人の了解を得ながら進める必要もある。（もっとも、日本中の税理士・会計士が、みんな「暗中模索状態」なのだが…）

※国税庁：電子帳簿保存法上の電子データの保存要件
https://www.nta.go.jp/law/joho-zeikaishaku/sonota/jirei/05.htm

7. インボイス制度との関係は？

で、実は、、、この話は「電帳法2022」だけで終わらない。

スグに「インボイス制度2023」が来る。 〔ドッキリ〕　（ていうか密接に関連している）

いわゆる “インボイス制度” の開始とは、「適格請求書等保存方式」のルール変更　を指す。この『適格請求書』は「消費税法」の管轄だ。そして「軽減税率あるけど、キッチリ納税してネ」と言っている。大切なことは、「電帳法2022」も「インボイス制度2023」も、どちらも『保存方式』を規定している点だ。

であるならば、、、誰が、どう考えても、『”どちらの制度にも対応する保存方式” で保存できる環境』（業務プロセス）を整備したい、と考える。そしてソコに全ての『書類』（請求書・領収書）を保存したい。

• スキャン（orスマホ撮影）した請求書ファイル　※紙の請求書（Paper Invoice）
• PDF等の電子インボイス（Unstructured E-Invoice／構造化されていない電子インボイス）
• XML等の電子インボイス（Structured E-Invoice／構造化された電子インボイス）
• （請求書/領収書の無い支出）

★消費税法（2023-10-01） 第五十七条の四
適格請求書発行事業者は、国内において課税資産の譲渡等を行つた場合において、当該課税資産の譲渡等を受ける他の事業者から次に掲げる事項を記載した請求書、納品書その他これらに類する書類（以下この条から第五十七条の六までにおいて「適格請求書」という。）の交付を求められたときは、当該課税資産の譲渡等に係る適格請求書を当該他の事業者に交付しなければならない。ただし…
https://elaws.e-gov.go.jp/document?lawid=363AC0000000108_20231001_428AC0000000015

★国税庁：インボイス制度公表サイト
https://www.nta.go.jp/taxes/shiraberu/zeimokubetsu/shohi/keigenzeiritsu/invoice.htm

8. じゃ、どーすれば？？ (涙)

我がクエステトラ社は、ワークフロー会社なので（！）、、、当然ながら（？）、、、自社製品『Questetra BPM Suite』上で「適格請求書の保存プロセス」を運用する。 〔バックリ〕

今回改めて、以下のような業務プロセス（ワークフロー図）を描いた。

稼働させるとスグに業務システムとして全社員が利用できるようになる。そして、その使い方は、、、（さまざまな申請方法〔開始方法〕があるのだが）、、、たとえば「メールで請求書（PDF）を受領した」の場合（←あるあるユースケース）は、

• 請求書受領者は einvoice.xxxx@questetra.com にメールを転送する（するとワークフロー基盤に請求書PDFが保存される）
• 転送者（請求書受領者）に「1b. 日付金額等入力」のシゴトが割り当てられる ※画面参照
• 転送者（請求書受領者）の上司に「2. 上司承認」のシゴトが割り当てられる（ふつう承認をクリックする）
• 経理担当に「3. 経理承認」のシゴトが割り当てられる（ふつうOKをクリックする）
• ワークフロー基盤によって、自動的に Google Drive の特定フォルダに保存される
• ワークフロー基盤によって、”削除不可域” にタイトルが保存される

といった流れになる。（文字で説明するより、フロー図をジックリ見ていただいた方が早い…）

工程「1b.日付金額等入力の処理画面」

コレは、Questetra のサポートサイトで公開されているワークフローアプリ『請求書保存プロセス』をベースにしている。今後も、この業務プロセスを改善し続ける予定だ。（もし「イイ感じの特化型 SaaS 製品」が出てくれば、連携したり、乗り換えたりするかもしれない）

★サンプルワークフロー『請求書保存プロセス, 適格請求書』（無料ダウンロード）
https://support.questetra.com/ja/templates/e-invoice-storage-20211020/

請求書保存

SaaS型ワークフロー製品『Questetra BPM Suite』は、「自社の業務フロー」を描くことができるヒトなら（！）、ノーコードで業務システムを構築できるツールだ。こういった複雑な業務プロセスであっても、「自社の業務フロー」を描くことができるヒトなら（!!）、一日もあればシステム化できる。「GoogleDrive自動保存」などの自動工程も200種類以上用意されており、一般的な SaaS ワークフローとはかなりチガウ機能構成になっている。興味のある方は、是非、試してみてほしい。（無料トライアルは60日間だけど、何度でもトライできるｗ！）

9. ペポルって何？

（えーっと、日本版Peppol、、、また今度、、、「続き」書きます、、、ゼッタイ。〔情報不足ナウ〕。　
もしココまでの内容で疑問質問あれば、下の『コメントを残す』に書き込んでください。）