ブログ

企業において、コーポレートサイトや、製品（商品／サービス）サイトを自社で制作／更新する際、WordPressを利用するケースは多いでしょう。
今回は、WordPressの「投稿（post）」や「ページ（page）」の投稿作業の一部を自動化し、作業を省力化する方法をご紹介したいと思います。

WordPressへの投稿を自動化する方法

準備するツール（クラウドサービス）

使用するツールは、「WordPress」と「Questetra BPM Suite」です。Questetra BPM Suiteとは、ノーコードで業務システムを構築できる業務システムプラットフォームです。Questetra BPM Suiteでは、システムの設計図となる「ワークフロー図」を作成します。これにより、ワークフロー図上に設置した工程が、設置した順に処理されていきます。

下書きが自動作成される仕組み

Questetra BPM Suiteに、記事を投稿したいサイトの情報やタイトル、投稿内容などを設定（入力）します。設定情報をもとに、WordPressに下書き記事（草案）が自動的に作成されるようQuestetra BPM Suiteからシグナルが送信されます。WordPressに下書き記事が自動的に作成され、下書き記事のURLなどの情報がQuestetra BPM Suiteに送信されます。

WordPressに投稿されるまでの流れ

下の図は、WordPressに投稿されるまでの流れを描いたワークフロー図です。WordPressに下書きが自動投稿される自動処理アイテムを使用します。

＜WordPress記事投稿ワークフロー図＞

具体的には、以下の順でWordPressへの投稿が完了します。

1. 人が処理する工程：タイトル／記事本文／抜粋／投稿タイプ（post／page）などを設定（入力）する。
2. システムが処理する工程（自動処理アイテム）：1で設定された情報をもとに、WordPressに下書きが自動的に作成される。
3. 人が処理する工程：WordPress の編集画面で確認し、下書きを「公開」にする（作業後に［投稿］ボタンを押す）。

この業務プロセスを採用することで、投稿者の作業は、下図のような入力フォームにある必要項目を入力し、出来上がった下書きを確認／投稿ボタンを押下するだけです。そのため、投稿作業が単純化され省力化されます。

※入力フォームの項目は、工程毎に作成／設定できます。

業務プロセスで活用する方法

Questetra BPM Suiteは、複数人／複数部署が関わる組織で使用できる点が大きな特徴です。サイト制作や更新において、特にコーポレートサイトや製品ページなどでは、正確な情報を掲載する必要があります。そのため、複数の部署／担当者が、内容に間違いがないかを確認する必要があります。Questetra BPM Suiteは、この様な社内における部門横断的な業務プロセスを実現するために役立ちます。

また、Questetra BPM Suiteでは、複数人／複数部署が関わる業務プロセス内に、自動化アイテムを使用できます。作成するワークフロー図内には、人が処理する工程（投稿文作成や内容確認など）とシステムが処理する工程（記事下書き自動作成アイテムなど）の双方を設置できます。そのため、組織が関わる業務においても、効率化／作業の省力化が可能です。以下のワークフロー図は、WordPressに記事の草案が自動的に追加されるアイテム（自動処理工程）を組織における業務プロセスに使用した例です。

具体的な工程処理の流れは以下の通りです。

1. 人が処理する工程：タイトル／記事本文／抜粋／投稿タイプ（post／page）などを設定（入力）する。
2. 人が処理する工程：1で設定された内容をチェックする。要修正の場合は、修正するよう差し戻す。
3. システムが処理する工程（WordPress記事草案自動追加アイテム）：1で設定された情報をもとに、WordPressに下書きが自動的に作成（追加）される。
4. 人が処理する工程：WordPress の編集画面で確認し、下書きを「公開」にする（作業後に［投稿］ボタンを押す）。
5. 人が処理する工程：投稿された内容をチェックする。要修正の場合は、修正するよう差し戻す。

この様に、Questetra BPM Suiteを使えば、WordPressに下書きが自動的に作成（追加）されるため、作業時間の短縮による業務の効率化や省力化が可能です。また、ワークフロー図通りに仕事を進めていけるため、業務のムラを防止できます。これ以外にも、業務プロセスにチェック担当／工程を入れることで、ミスの軽減による業務品質の向上を実現することも可能です。ご興味のある方は、是非お試しください

サイトに集客する際、どのページのアクセス数が伸びているかを定点観測し、次に繋げたいものです。
今回は、Google Analyticsでサイトの「アクセス数／アクセスランキング」を確認する作業をノーコードで自動化する方法をご紹介します。

アクセス数を自動取得する方法

準備するツール（クラウドサービス）

ノーコードでサイトのアクセス数やアクセスランキングを自動取得するのに必要なツールは、以下の2つです。

• Questetra BPM Suite
• Google Analytics

クラウド型ワークフロー「Questetra BPM Suite」では、アクセス数を自動取得するアイテムを使うことで、ページビュー数やセッション数など様々な情報(※1)が取得される仕組みを構築できます。また、その結果がレポートされる方法を複数の方法(※2)の中から選べます。アクセス解析サービス「Google Analytics」は、Questetra BPM Suiteからのリクエスト（設定条件に合致するアクセスデータの取得要求）に応答し、アクセスデータを渡します。（サイト計測の設定は既に実施されているものとします）

※1. 取得できる主な情報は以下の通りです。（指定したサイト／ホスト／ページと、指定した期間の）

• ページビューランキング
• ページビュー数
• ユニークページビュー数
• セッション数
• 閲覧開始数

…など

※2. 指定できる主な方法は以下の通りです。

• 指定アドレスへのメール自動送信
• Slackへの自動投稿
• Googleスプレッドシートへの自動入力
• Googleドキュメントへの自動入力
• Googleドライブへの自動保存

…など

自動取得する仕組み

Questetra BPM Suiteで、アクセスデータを取得したいサイトの情報や計測条件などを設定（入力）します。その情報をもとに、Google Analyticsから該当するアクセスデータを自動取得します。取得された情報はQuestetra BPM Suiteに取りこまれ、予め設定した方法で報告されます。

アクセスランキング取得までの流れ

Questetra BPM Suiteにおいて、下図「アクセスランキングを自動取得するワークフロー図イメージ」の様に設定（ワークフロー図を作成）した場合、アクセスランキング取得までの流れは以下のようになります。

1. 自動処理工程（タイマー起動アイテム）：毎週月曜日の8時にプロセス（ワークフロー図上のタスクが開始から終了まで遷移する一連の流れ）が自動的に開始されます。
   
   
2. 自動処理工程（Google Analytics アクセス数自動取得アイテム）：API連携されたGoogle Analyticsから、設定条件にあったアクセスデータが取得されます。
   
   
3. 自動処理工程（メール自動送信アイテム）：設定した送信先／内容に自動送信されます。設定により2で取得したアクセスデータをメール内容に差し込まれます。（データ成型も可能）

＜アクセスランキングを自動取得するワークフロー図イメージ＞

業務プロセスにおける活用方法

Questetra BPM Suiteの特徴の一つとして、複数担当者／部署の業務を連結できる点が挙げられます。そのため、複数人（複数部署）が関わる業務プロセス（業務フロー図）の中に、アクセス数が自動取得されるフローを組み込むことが可能です。以下のワークフロー図は、人事部、マーケティング部、カスタマーサービス部の担当者が、制作担当者に部門サイトのページ制作／更新を依頼する業務プロセスです。

＜サイト制作／確認プロセス例＞

具体的な流れは以下の通りです。

1. 人が処理する工程：各部門がページ制作を依頼する。
2. 人が処理する工程：制作担当者が依頼を受ける。（ページ制作／更新する）
3. 人が処理する工程：各部門が成果物を確認する。
4. 自動処理工程（条件分岐アイテム）：修正依頼箇所があれば「修正」工程へ遷移し（制作担当者に修正依頼され）、修正がなければプロセスが終了する。

この業務プロセスに、先ほどの「自動処理工程（Google Analytics アクセス数自動取得アイテム）」を加えます。

＜アクセス数が自動取得されるサイト制作／確認プロセス＞

これにより、以下の様に制作したページのアクセス数を自動取得する（自動報告を受ける）ことが可能となります。（つまり、ページ制作後の効果測定をセットにした業務プロセスとすることができます）

1. 自動処理工程（タイマーアイテム）：（予め設定した期間である）7日間待機した後、次の工程に自動的に遷移します。
2. 自動処理工程（データ更新アイテム）：制作されたサイト／ページ情報が自動的にセットされます。
3. 自動処理工程（Google Analytics アクセス数自動取得アイテム）：2でセットされたサイト／ページ情報をもとに、Google Analyticsのデータが自動取得されます。
4. 自動処理工程（メール自動送信アイテム）：（3で取得したアクセスデータの差込など）予め設定した内容で、予め設定した送信先にメールが送信されます。

この様に、Questetra BPM Suiteを使えば、ノーコードでサイトのアクセス解析を自動化できます。ワークフロー図を作成することで、業務システム（ワークフローアプリ）を構築できます。

アクセス数の取得を自動化することで、本来人が時間をかけるべき「データを見て戦略を練ること」に注力できるようになります。ご興味のある方は、是非ご自身の手でお試しください。

こんにちは。クエステトラの木村です。
突然ですが、皆さんは「行動経済学」「社会心理学」といった言葉をご存知でしょうか。ここ近年、特にビジネスの分野でも目にすることが多くなってきた様に思いますが、個人的にはビッグデータが流行り出した後に、「データから人の行動を理解する」という文脈でも多く使われてきた気がしています。

行動経済学 Wikipedia
社会心理学 Wikipedia

さて、今回なぜ上記の言葉に触れたかというと「自分自身の行動」を変えたかった時があったからです。
まあ「仕事のある場面で出てくる癖を直したい」でも良いですし、「ある特定の技術に習熟したい」でもなんでもいいんですが、こういった「朧げな目標」に対して、先送りにしてしまう自分がいるわけです。

「今はAの方が優先度・緊急度が高いので、◯◯は次にしよう」
「◯◯を行うにはアレとコレが準備されていないといけないので、次にしよう」

と。さて、行動経済学から発展して、これらの概念を個人に対して適用することを試みた人がいます。
B.J.Fogg PhD さんです。

行動デザイン

彼（B.J.Fogg PhD）は25年以上スタンフォード大学と連携しており、さまざまなクラスで教鞭をとりました。
現在も副教授として健康と人間のパフォーマンス部門（HHP）の副教授に任命されています。さてそんな彼が世界に打ち出したものが「行動デザイン」です。「意志の力（モチベーション）」に頼らずに目標を達成するため、「行動」をデザインするというやり方です。と聞くと、なんだか物々しい感じもありますが至ってシンプルな考え方です。

B=MAP

上の図は彼が「行動デザイン」を提唱するにあたり、前提となる考えを示しています。それは B=MAP、「行動」は「モチベーション」&「能力」&「きっかけ」が一定の条件を満たした時に起こる、というものです。具体例を示します。

行動デザインの例

私が住む町の隣の駅前には、BIG ISSUEという有料フリーペーパーを販売している方がいらっしゃいます。
（有料だけどフリーペーパーと呼ばれているのは無視してください）

※BIG ISSUE=雑誌（有料フリーペーパー）をつくりホームレスの人の独占販売事業とすることで、ホームレス問題の解決をはかる試み。
ホームレスの人の救済（チャリティ）ではなく、仕事を提供し自立を応援する事業。ロンドン発祥。

私はこの駅を訪れた際、販売者がその場にいる時には必ずこの雑誌を購入しています。

では何故、この「行動（毎回購入する）」が起こるのでしょうか。
以下に簡単に説明します。

• モチベーション：頑張っている人を応援したい。
• 能力：450円なら払える。またそもそも外出時なので、手元にお金を持っている。
• きっかけ：駅前に販売者がいなかったら、購入していない。

上記の様に、モチベーションと能力、そしてきっかけが「バチ」っとはまり、私は行動を起こしたわけです。
多分、上記のうちの何か一つがかけていた場合には、行動を起こさなかったであろうと思います。

以下の図は、今回の行動がどの様な見方ができるのかを示した図です。モチベーションと能力が高い場合には、行動を起こす分岐点となる「行動曲線」を容易く越えます。そして「きっかけ」さえあれば、行動は起きるということですね。

きっかけ＝トリガー

行動デザインでは「AをしたらBをする」という風に、ある行動をトリガーとして捉え、次の行動を促します。実はこのトリガーが先ほどの公式（B=MAP）にあったP（Prompt。きっかけ）なのです。例えばですが、朝起きたらカーテンをあけます。しかしこの行動は、誰かに頼まれて実行していることでも、目標をたてているわけでもありません。「起きる」という行為自体が、トリガーとして無意識のうちに次の行動を促しているのです。

きっかけを考える

さて、それでは次にトリガーの例を考えてみます。ここでは「読書」を取り上げてみます。仮に、私は読書家になりたいと思いつつ、なんら読書ができていない状況だとします。あれやこれや計画を立てるも上手くいかない。そんな際の失敗するパターンは以下の通りです。

• 頻繁に読書する（予定を立てる！またはそう心に誓う）
  → 予定を立てるだけでは、その他の行動となんら結びついていないため、意志の力（モチベーション）を必要とする
  
• 読書をする時間をカレンダーに入れておく
  →予定通りに行かない際に立ち消える。
  また、カレンダーのリマインダーなどで「行動」を促すことはできるが、その他の事項との優先順位に負けてしまう事が多々ある（いつでもできると考えるため）

要は「AをしたらBをする」という、意志の力を使わずとも関連づけられるトリガー（きっかけ）が設計されていないわけですね。
では、具体的にどの様な「行動デザイン」をもち、読書が可能となるのでしょうか。答えの一例が以下となります。

• 目標：読書をしたい
• 課題：本を読む時間がない
• 行動デザイン：朝起きたら、枕の上に本を置いて部屋を出る。寝る前に1ページだけ読むことにする。

上記はAをトリガーとしてBをする（またはBをするための補助をAでする）という行動デザインです。私もこの方法を取り入れた結果、毎日少しずつ本を読むことが習慣となりました。（読書家に成れた気がします）「ほんとかな？」と疑いたくなりますが、1日の仕事を終え寝床に着く際に枕の上に本が置いてあるとめくってみたくなるものですよ。お勧めします。

業務プロセス・ワークフローと行動デザイン

とまあ、「行動デザイン」って面白いなーと感じる私は、日中は弊社でマーケティングを担当しています。無論、弊社の業務は Questetra BPM Suite であらゆる業務がアプリ化（ワークフロー化）されています。この様な環境で自社のワークフロー図を見ていると「あ、これは使える（意識の力を必要とせずに、業務を動かす）」と感じるものがありましたので、2部に分けてブログ記事にしてみる事にしました。さて、前編となる今回はAをしたらBをする（もしくはBをするためのトリガーがたちあがる）です。

意志の力（モチベーション）を使わずとも仕事をすすめるコツ

業務の中で毎日行わなければいけない事は、探すと結構出てきます。例えばですが、日報、朝会、夕礼、数値計測、進捗確認、制作作業などなどです。ここでもう結論から述べてしまいますが、例えば朝出社すると「今日のあなたの仕事はこれです」とタスクが明示されていたら、めちゃくちゃ楽だと思います。おまけに、そのタスク全てに順番（優先順位）が割り振られている場合、もっと楽になりますね。なぜなら意志の力を使わずとも順序よくこなせば1日の仕事が終わるからです。

「そんな簡単にいくかいな」という異論は受け付けます（笑）もちろん、発生ベースで自分のタスク以外に費やす時間はどうしても出てきます。それでもですよ。毎日自動で自分のタスクが明示される環境は「自身が処理すべき”核”の部分のタスクはこれである」と認識する事ができるため、相対的に他のタスクに割り当てられる時間を柔軟に割り当てる事ができるためです。と、説明というか論説で説得する様な文章になってきたので、具体的な項目を説明していきますね。

行動デザインパターン

• AをしたらBをする
• 出社したら、タスクAを処理する。（自分のタスクリストにタスクAを割り当てる）

これはもうめちゃくちゃ簡単です。下の図の様に「タイマー」で平日の定時にタスクを起動させる事がもっともシンプルで楽です。

タイマーで自動起動されたタスクは、以下の図の様に「マイタスク」に表示されます。
後は処理するだけです。

「なんだ、これだけか。こんな内容は聞かずともわかるわい！」と考える方がいらっしゃると思います。はい。その意見は正しいです。しかし、「わかる」事と「実施できる（習慣化）」できることは別です。また今回の例は、「行動デザイン」を説明するために極端に簡素化された例です。まずは素直に「意志を使わないきっかけ」というものに頼れることを理解していただけると幸いです。

なぜなら、これまで単純に「タイマーで起動すればいいじゃん」と考えていた対象が「意志を使わないきっかけ(トリガー)」と捉え直せるからです。この話は、いわゆる「自動化」という概念とも関連してくるのですが、「意志を使わずに何か行動を起こす」という視点を持つと、「自動化」されたもののアウトプットに対する意識を変えることも可能です。

※数字を見るだけの状態から、週一で数字の内訳の仮説を立てるためのタスクを自動起動する、などより密度の濃い仕事を促す事もできる。

さて今回はここまで。次回、後編では発展系を紹介したいと思います。
もうこの段階でタイマー起動を試してみたくなった方は、弊社の無料トライアルをお試しください。

人が製品（商品やサービスを含む）を知ってから購入に至るまで、様々な段階を経ます。製品を提供する側からすれば、より購入してくれそうな顧客を探し出し、より早く購入してもらえるように働きかけたいものです。そのため、自社の製品に興味を持つ潜在顧客（リード）の意識／状態を行動に基づき、レベル分けしたものがMQLやSQL、PQLです。これらはこの十数年、マーケティングで主に使われていた概念です。今回は、用語の意味とそれら（リードレベルの判別や管理）を自動化する方法を考察します。

4つのQLとは？

QL（Qualified Lead）とは、ある基準を満たした潜在顧客のことです。QLは、購入／有料化の確度が高まるほど、IQLからMQL、SQL／PQLとレベルアップしていきます。

※このうちIQLとPQLは既に定義が概ね決まっているのに対して、MQLやSQLは企業により定義が異なります。そのため、それぞれの相対的なレベルや位置づけは企業により異なります。特にPQLは別のレイヤーで考えたほうが良いでしょう。

IQLとは？

リードのうち「コンタクト情報が判明している潜在顧客」のことをIQL（Information Qualified Lead）と呼びます。具体的には、メールアドレスなどの情報を提供する代わりに、お役立ち資料やホワイトペーパーなどの情報を得たリードです。この時点では、リードは自社（自分）の課題を認識しているものの、（リード／製品提供側双方において）製品によりその課題が解決されるかどうかを把握できていません。

そのため、マーケティングチームがIQLに対して実施する取組みとして、「（アンケートやヒアリング等による）リードが持つ課題の把握」や「（動画コンテンツやウェビナー等による）製品で解決できる課題例の案内」などが挙げられます。この様な取組みを通して、リードが持つ課題と製品がマッチしていることを認識してもらい、リードの購入意欲を高める必要があります。

MQLとは？

MQL（Marketing Qualified Lead）とは、「マーケティングに注力すべき見込客（有望見込客）」のことです。Warm Lead（そのうち顧客）とも呼ばれます。リードのうち、（自社で決めた）基準を満たしたリードをMQLと定義します。これにより、製品を購入する可能性が低い「不適切なリード」を排除し、不要なマーケティングコストや機会損失（＝有望見込客を逃すリスク）を軽減できます。基準の具体例として、以下が挙げられます。

• 特定ページ（機能／価格／導入事例など）に繰り返し訪問していること
• 製品資料をダウンロードしていること
• 企業名（B to Bの場合）／担当者名／電話番号を把握していること
• ウェビナーへ参加していること
• 製品で解決できる課題を有した顧客であること（アンケート回答者など）

つまり、課題解決できる製品を探しているリードや、購入の可能性があるリード、コンタクトが具体的に取れるリードなどです。マーケティングやインサイドセールスは、このMQLを対象に無料トライアルや無料相談を案内するなどのマーケティング活動を実施します。

この様にリードを定義することで効果的なマーケティング活動が実施できる一方で、MQLを判断／管理する際、以下のような課題も存在します。サイトへの訪問状況を把握するには、アクセス解析ツールを参照しリードの行動を追跡／記録する必要があります。また、複数の基準を設けている場合は、他の基準の到達具合も把握しなければならないため、情報の取得方法や記録方法も整理／工夫する必要があります。これらを手動で行うには多くの時間を要します。

SQLとは？

SQL（Sales Qualified Lead）とは、「営業に注力すべき見込顧客（有望見込客）」のことです。Hot Lead（今すぐ顧客）とも呼ばれています。SQLを判断する基準の具体例として、以下が挙げられます。

• 無料トライアルや無料サンプルに申し込み、製品を実際に試用していること
• 無料相談を申し込んでいること
• 見積を請求していること
• デモを申し込んでいること
• 予算が製品価格と合致していること
• 企業規模が（自社で決めた）基準以上であること
• 営業が連絡することを許可していること

SQLは、製品を使うことで自身の課題が解決できるかもしれない、と考えています。また、ある程度購入意欲（購入能力）があるリードとも言えます。SQLに対して、営業は直接連絡を取り、リードが持つ課題を解決する方法を提案します。また、SaaSビジネスの場合、無料トライアルなどを活用し、製品の使用方法についての支援も行います。このような取組みを実施することで、購入／契約に結びつけます。

PQLとは？

では、PQLとは何でしょうか？PQL（Product Qualified Lead）とは、無料トライアルや無料エディションに申し込んだ「製品を試用している見込客（有望見込客）」です。

PQLは、製品を使用しようという意思を持つため、購入の可能性があります。そのため、見込客のレベルとしては、SQLに最も近いリードです。（ただし、間違って申し込んだケースや、インセンティブ目的のリードも含まれている可能性があるため、試用頻度やヒアリングなどから本当のPQLかどうかを見極める必要があります）PQLへの活動内容は、SQLと同様に、リードが持つ課題を解決するための提案や、製品の使用方法についての支援などがメインの取組みとなるでしょう。

MQL、PQLの判別／管理を自動化する方法

これらQLの判断基準となる情報を取得する作業や適合判定を手動で実施することは大変です。特にリードの行動を複数の基準により追跡／記録する作業には、多くの時間がかかり、ミスやモレが発生する可能性があります。クラウド型のノーコード開発プラットフォームQuestetra BPM Suiteを使うと、MQLやPQLの判別／管理を自動化できます。

Questetra BPM Suiteでは、ワークフロー図が業務システムの設計図になっています。そのため、ワークフロー図を描くことで、業務システムを構築できます。また、作成したワークフロー図をそのまま業務システムとして運用することが可能です。MQLやPQLの自動判別／管理システム（ワークフローアプリ）を作成したい場合、判断基準や基準となる情報の取得先、MQL／PQLの管理方法などを整理します。整理した内容をもとに、誰が何をどの順番で処理するかを表すワークフロー図を作成します。

ワークフロー図上の工程には、「人が処理する工程」と「システムが処理する自動処理工程」があります。人が処理する工程では、入力／選択項目を設定すれば、自動的に入力フォーム（処理画面）が作成されます。また、システムが処理する自動処理工程では、どの様に自動処理するかを設定できます。

※具体的にどの様なワークフロー図となるかは、以下のサポートページをご覧ください。

▼ MQLのワークフローアプリサンプル
Leadトラッキング, MQL

▼ PQLのワークフローアプリサンプル
Leadトラッキング, PQL

Questetra BPM Suiteでは、この様なワークフローアプリ（業務システム）がノーコードで構築できます。また、上記のようなサンプル（テンプレート）はダウンロードしてすぐにお使いいただけます。ご興味がある方は是非、お試しください。

「自動化のススメ – Box活用の資料請求対応（その1）」では、資料請求フォームで氏名とメールアドレスが入力されると、資料の閲覧用 URL が差し込まれたメールが自動送信される仕組みを構築しました。

本記事では、資料ファイルが添付されたメールが送信される仕組みを、ノーコードで構築する方法を紹介します。

ノーコード開発クラウド Questetra BPM Suite

「業務の自動化」には、ノーコード開発クラウド「Questetra BPM Suite」を利用します。クエステトラ社が提供するクラウドサービスで、システムの内製化に活用されています。

Questetra BPM Suite では、システム開発が Web ブラウザだけで行われます。業務の流れ図（ワークフロー図）の作成を通じて、業務システムが構築されます。構築されたシステムでは、業務データが電子化されるだけではありません。

人と人との業務情報の受け渡しが自動化されるとともに、数値計算、データの解析や整形、メール送信などの処理も自動化されます。更に、他のクラウドサービスとのデータ連携も自動化されます。

自動化は、ワークフロー図において自動化したいタイミング（例えば、品質管理部長が検査報告書を承認したら）に、自動処理が行われるアイテム（検査報告書ファイルが Box にアップロードされる）を配置することで実現されます。

Questetra BPM Suite に用意されている様々な自動化アイテムを利用すると、簡単に「業務を自動化」できるようになります。

クラウドストレージ Box ファイルダウンロード

Box は企業向けのクラウドストレージサービスです。Box 導入事例ページには、「顧客企業数100,000以上、67%がフォーチュン500企業」と書かれており（2022-02-28確認）、大変多くの企業で利用されています。

前節で紹介した「Questetra BPM Suite (v13.3.0)」に用意されている自動化アイテムには、Box に関するものが用意されています。

• Box: ファイルアップロード
• Box: ファイルコピー
• Box: ファイル移動
• Box: ファイル共有リンク作成
• Box: ファイル共有リンク削除
• Box: ファイル削除
• Box: ファイルダウンロード
• Box: フォルダ作成
• Box: フォルダ検索
• Box: フォルダ共有リンク作成
• Box: フォルダ共有リンク削除
• Box: フォルダ削除
• Box: コラボレーション追加
• Box: コラボレーション削除

次節で作る仕組みでは「Box: ファイルダウンロード」（太字）が使用されます。

資料請求対応でのファイルのメール添付を自動化

次のような処理が行われるシステムを構築します。

• 資料を求める人（資料請求者）が、資料請求フォームに氏名とメールアドレスを入力する。
• Box に用意された資料（ファイル）が Questetra BPM Suite にダウンロードされる。
• 資料請求者に、資料（ファイル）が添付されたメールが送信される。

最初に、資料請求者が氏名とメールアドレスを入力する以外は、全て自動で処理されます（太字）。

まずは、この業務の流れ図（ワークフロー図）を作成します。（以下、Questetra BPM Suiteで構築）

このワークフローにおいて、人が処理するのは一番左の赤丸のアイテム「1.資料請求フォーム」のみです。ここで、氏名とメールアドレスが入力されると、後ろに連なる工程が順番に処理されます。

• 「2.資料ダウンロード」では、予め Box に保存された資料ファイルが Questetra BPM Suite にダウンロードされます。
• 「3.請求者へメール」では、ダウンロードされたファイルがメールに添付され、資料請求者に送信されます。

予め Box に保存された資料ファイルのファイル ID を、「2.資料ダウンロード」の”C2: ダウンロードするファイルの ID” に設定します。資料ファイルのファイルIDは、そのファイルのURLの一部（次の青い部分）です。

https://example.app.box.com/file/xxxxxxxxxxxx

資料請求が行われると、資料請求者は届いたメールに添付された資料（ファイル）を確認できます。

まとめ

「自動化のススメ – Box活用の資料請求対応（その1）」と同様に、資料請求フォームに氏名とメールアドレスが入力されると、その後は人が関与することなく完全自動化された仕組みを構築する方法を紹介しました。

その1 との違いは、資料ファイルがメールに添付されるという点です。

資料ファイルが大きい場合はその1のほうが良いかもしれません。しかし、今回の仕組みのほうがワークフロー図で使用されているアイテムの数が少なく、設定の手間が小さくて済みます。

更に、メール受信ソフトによっては、受信したメールを開くとすぐに添付ファイルの内容を確認できます。メール受信者の手間も小さくて済みます。

完全自動化されているため、人が対応する場合に比べてファイル添付の手間が削減されます。さらに、請求への対応忘れや遅れ、誤ったファイルを添付してしまう、メールの宛先を誤る、というようなミスも防止されます。

ノーコード開発プラットフォーム「Questetra BPM Suite」に用意されている自動化アイテムを利用すると、Box の API (Application Programming Interface) に関する知識・経験がなくても、ファイルダウンロードが自動処理される仕組みを構築できます。

「Questetra BPM Suite」には60日間無料でご利用いただけるトライアルが用意されています。ご興味のある方は、是非、以下よりお申し込みください。

他にも様々な自動化が可能です。

今回はここまで！

ノーコード開発ツールとは

通常、システム開発には、コードを使ったプログラミングが必要となります。ノーコード開発ツールとは、コーディング／プログラミングなしで、システム／モバイルアプリ開発が可能なプラットフォームです。

具体的には、ノーコード開発ツールを使うことで、パーツ（UIやワークフローのアイテムなど）のドラッグアンドドロップやパーツ名の入力、挙動の選択／入力などにより、アプリケーションが作成できます。

ノーコードで開発できるプラットフォーム「ノーコード開発ツール」は、利用用途毎に様々なサービスが存在しています。

ノーコード開発ツールの種類

ノーコード開発ツールの具体的な利用用途と主なサービスは、以下の通りです。

• Webサイト構築
  Webflow、STUDIO、Wix、Wordpress
  
  
• ECサイト構築
  SpreadSimple、Shopify
  
  
• モバイルアプリ開発
  Yappli、Appy Pie、Adalo、Glide
  
  
• データベース開発
  kintone、Honeycode、Airtable
  
  
• 業務システム開発
  Questetra BPM Suite

これらは、提供されている分野やその主なサービスの一部です。日本国内で使えるサービスは、現状海外サービスが多くを占めています。

ノーコード開発ツールを使うメリット

ノーコード開発ツールを使うことで得られるメリットとして、システム開発コストの削減や開発期間の短縮、エンジニア不足の課題解決などが挙げられます。ノーコード開発ツールを使ったシステム開発は、プログラマーやエンジニアに頼る必要がありません。そのため、社内のあらゆる部署において、必要なアプリケーションを開発できます。これにより、システム開発関連費用の圧縮や、アプリケーション完成までの期間短縮が可能となります。また、アプリケーション開発後のメンテナンスにおいて、エンジニア以外の人材でも対応できる点もノーコード開発のメリットといえるでしょう。

開発期間の短縮というメリットを享受できるのは、エンジニア以外の人材に留まりません。エンジニアにおいても、ノーコード開発ツールを使うことで工期の短縮が可能な点も大きなメリットでしょう。

ノーコード開発ツールの市場概況

カナダの調査会社Emergen Research社によれば、全世界におけるノーコード開発プラットフォームの市場規模は2020年には、約1兆4,000億円に達したとされています。（1USD=115円で計算）

また、2028年には約7兆8,000億円に達すると予測されています。予測期間中の年平均成長率は24.2%となっており、今後も堅調に拡大するとされています。

出所：Emergen Research社

ノーコード開発ツールの重要性

この市況より、今後もノーコード開発ツールが普及、拡大していくことが予測されます。つまり、ノーコード開発ツールを使い、開発コストや工期の圧縮を図る企業は、今後益々増えていくと考えられます。

もちろん、全ての開発をノーコード開発ツールに頼ることはできません。自社の企業規模や用途、状況に応じた開発手法を選ぶことは重要です。しかし、ノーコード開発ツールを上手く活用することは、自社の競争優位性を向上させるための重要な取組みとなることには変わりがないでしょう。

まずは社内業務をシステム化

クエステトラ社では、Questetra BPM Suiteを使い、ノーコードで業務システム（アプリ）を各部署の担当者が作成しています。これにより業務のルール化や自動化（業務の受渡しの自動化やタスクの自動処理など）、可視化（タスクの処理実績や進捗の見える化）などが可能となっています。身の回りの業務をノーコード開発ツールでシステム化していくことはそれほどハードルが高くないため、この様な社内業務のシステム化を先ずはお勧めします。

Questetra BPM Suiteは、業務システムをノーコードで開発できるプラットフォームです。クラウド型のため、ブラウザ上での業務システムの構築や、出来上がったシステム（アプリケーション）の処理が可能ですので、これらの実施場所を選びません。システム構築は、業務プロセスを表す「ワークフロー図（業務の流れ図）」を作成するだけです。ワークフロー図を作成するには、予め対象業務において「誰が」「何を」「どの順番」で処理するかを整理します。整理した情報をもとに、モデリングエリア（ワークフロー図を作成するキャンバス）上にアイテム（担当者のレーンや、人が処理する工程、システムが処理する自動処理工程）を設置していきます。

次に、（ワークフロー図上の）アイテムの設定をします。具体的には、工程で処理する項目（項目名や処理内容）を設定します。人が処理する工程については、この項目に基づき処理画面（入力フォーム）が自動作成されます。この様に、Questetra BPM Suiteを使うと、簡単に社内業務をデジタル化し自動化できます。ノーコード開発プラットフォームを体験してみたい方は是非お試しください。

0. 事前の準備

業務プロセスを設計（定義）する際、事前にどんな準備が必要なのでしょうか？

• 業務プロセスの目的
• 業務プロセスのオーナー
• 業務プロセスの関与者
• 業務プロセスをシステム化する目的
• 業務システムに是非とも欲しい機能
• 業務システムの稼働スケジュール
• などなど……

たしかに世の中、どんな Plan（企画）も「事前の準備」は大切です。

しかし、、、 “業務プロセス” を設計する際、事前にアレコレ深く考える、、、はオススメしません。たとえば “例外ケース” や “エラーケース” といった枝葉末節を列挙しはじめるとキリがないのです。気が付けば「誰も読まない分厚いマニュアル」を作ってしまいかねません。何より “メインフローを検討する時間” が減ってしまいます。

筆者自身は「むしろ深く考えないほうがイイ」、「”インプット” と “アウトプット” だけを決めて、さっさとモデリングを始めるべきだ」と考えています。

• 業務プロセスのインプット（≒トリガー）
• 業務プロセスのアウトプット（≒成果物）

なお、この2つ、”インプット” と “アウトプット” については、何時間でも、何日でも、「確信が持てる」まで、深く深く考察すべきだと考えています。（←散歩しながら考えるのが好きです。）　言い換えれば、、、もし「確信が持てない」ようであれば “業務プロセス定義” に着手すべきではない、、、と考えています。”インプット” と “アウトプット” の想定なく、業務プロセスの設計を始めると「ロクな結果」にならないのです。（ただの経験則ですが…）

と、偉そうなことを書いていますが…、 業務プロセス設計の途中で “インプット” と “アウトプット” を変更してしまいたくなる事は、マレにあります。特に、寝て起きて、リフレッシュした頭で「設計途中の業務プロセス」を見返したときに、「うっ…コレ…チガウ…」と思ってしまうのです。まぁ、カンペキだと思っていた業務プロセス定義も「諸行無常」（←この世のものはたえまなく変化し続けてしまう）なのでしょう。あるいは「スキー場の恋愛」（←ゲレンデで見かけた異性は3割増しでステキに見えてしまう）みたいなものなのかも知れません。なので、日々のレクチャー活動や大学での講義では、「最初の10本は駄作しかできないと覚悟しておいてください」とクギを指すようにしています。

1. 業務プロセスの命名

“ワークフローアプリ” を［新規作成］し、業務プロセス定義に着手します。そして “アプリ名” を付けます。

業務プロセスの名前（”ワークフローアプリ” の名前）としては、『アウトプット』（≒成果物）を印象付けるネーミングがオススメです。

たとえばこの設計動画では、『社内報メール送信プロセス』と命名されています。こういった業務プロセス定義名にしておけば、他部署メンバが見ても、新入社員が見ても、誰が見ても、業務プロセスの目的（ゴール）をイメージできます。（社内報がメールで送信される業務プロセスだ！）

ネーミングは、とても大切です。何より業務プロセス定義の “長大化” を防ぎます。絵画や建築で言えば “ラフ・スケッチ”（下絵）みたいなものだと思っています。プログラミングで言えば “関数名と引数と戻り値” みたいなものでしょう。いずれにせよ、とても大切です。”業務スコープ” や “プロジェクト・スコープ” を表しているといっても過言ではありません。

2. 処理者の検討

続いて、業務プロセスの “登場人物” について考察します。（”スイムレーン” と呼ばれるハコを配置します）

この設計動画のようにシンプルなワークフローの場合は悩むことなく設定できるでしょう。基本的には『申請者』や『申請者の上司』のように “相対的に設定” するのがオススメです。ポイントは「業務上のロール名」で設定している点です。

しかし、この “相対的に設定” がアダになって混乱を招いてしまうケースがあります。たとえば、「メンバの申請」と「課長の申請」で経路が異なる業務プロセスでは「『申請者の上司』って誰だ？」といった無駄な停滞を招く場合があります。そのようなケースでは、『メンバ』や『課長』や『部長』といった「組織上のロール名」で “絶対的に設定” するのがオススメです。

ちなみに、組織を横断するワークフロー（組織横断型の業務プロセス）などでは、単に『管理部』や『マーケティング部』といった「組織名」を指定すれば足りる場合もあります。

ごく稀に「どんな人が処理するのか？」（≒「どんなヒューマン工程があるのか？」）が完璧に列挙できないケースがあります。そのような場合は、”主要な登場人物” だけを設定すれば良いと思います。なお、”相対的に設定” と “絶対的に設定” を、あえて両方使うことによってエレガントにまとめられる業務プロセスもあります。たとえば、「複数の入力フローに対しての差戻工程を一元化する」といったケースが該当します。が、”最初の10本” では、そのような機会に遭遇しません。

3. 先頭工程の設定

業務プロセスの “先頭工程” を配置します。

この設計動画で言えば『1.申請する』です。非常にシンプルなヒューマン工程です。「業務プロセスのインプット（≒トリガー）」となります。コレは、あらかじめ “0.事前の準備” で考えていたことになります。

先頭工程が『1.申請する』となるワークフローは多く存在します。ワークフローシステムによっては『申請』『承認』『決裁』『確認』の流れが固定化されます。しかし現実世界の業務プロセスは『（見積書の）草稿を作成する』や『（アクセス集計の）CSVをアップロードする』など様々です。あるいは『Webオーダー』や『異常検知メール』といった外部トリガーも少なくありません。

4. 途中工程の検討

業務プロセスに必要な工程を配置します。

この設計動画で言えば『2.承認する』や『1x.修正して再申請する』です。いずれもシンプルなヒューマン工程です。

オススメは工程名に数字を付けることです。つまり、上流工程から順に “若い番号” を付けておくことで、ワークフロー図の可読性が高まります。

ちなみに、「途中で経路を分岐させる必要がある業務プロセス」は少なくありません。

• A. ゲートウェイ分岐：
  • ワークフローエンジンに案件内データを参照させて、経路を選択させる
• B. 処理者による分岐：
  • 処理者に『取り下げる』『再申請する』といった “経路ボタン” を選択させる
  • （デフォルトの『処理完了』ボタンは表示されない）

そもそも “フロー分岐” （複数経路から一つを選択）には大きく2つの考え方がありますが、基本的には「B.処理者による分岐」がオススメです。理由は簡単で、処理者が業務プロセスの「流れ」を意識するようになるからです。

しかし、中には「処理者が “業務プロセス全体” を俯瞰することに意味がない工程」もあります。たとえば、「ヒタスラに『翻訳する』の工程を処理するヒト」を想像してください。その場合、翻訳者に “複数経路” を意識させる意味がありません。そのようなケースでは「A.ゲートウェイ分岐」がオススメです。

「小さく始める」（と「継続的な改善」）はコンサルタント達が好んで使うフレーズです。しかし “小さい” という表現はクセモノです。つまり「小さいかどうか？」の判断は人によって大きく異なります。筆者に言わせれば、ヒューマン工程の数が “5” を下回るなら「小さい」と言えます。そして “10” を超えるようなら「大きい」です。そうなるとカイゼンが大変です。もし “20” や “30” を超えるような業務プロセス定義になりそうなら、”定義” する前に “分割” を検討してください。

5. イベントの検討

業務プロセスの途中に必要な “イベント” や “自動処理” を配置します。

業務プロセスにおける “イベント” とは「ワークフローエンジン自身に対処させる “アクション”」のことです。 “小さな工程” といっても良いかも知れません。具体的には『一定時間待機する／指定時刻まで待機する』（タイマーイベント）や『通知メールを送信する』（メールイベント）などがあります。

この設計動画では『タイマー中間イベント』と『メール送信イベント』が配置されています。もちろん、ヒューマン工程として『3.メールを送信する』を設計配置しても良いのですが、この例ではワークフローエンジン自身に『指定時刻にメールを送信する』を実現させる定義になっています。

“ヒューマン工程” を減らして “イベント” や “自動処理” で処理させることを、特に「処理の自動化」と呼びます。初期のワークフローエンジンは「経路に従って業務データを受け渡ししてくれる存在」（≒「受け渡しの自動化」を実現するソフト）だったのですが、近年では人間に変わって様々な処理を担ってくれる存在となっています。つまり、業務プロセス全体で見れば「ミスやヌケモレの撲滅」や「人間負担の軽減」が容易に実現できるようになっています。（サーバサイド処理）

6. 業務データの考察

業務プロセスに必要な “データ項目” を検討します。

もし「すでに紙で業務データを受け渡ししている」や「すでに決まったフォーマットのメールで業務データを受け渡ししている」という業務なら、それらを活用（参照）して定義すべきです。

すべての業務データを “文字型データ” として定義してしまっても構いません。しかし、様々な “自動化” を（将来に渡って）実現するためにも、”数値型データ”、”日付型データ”、”日時型データ”、”選択型データ” など、それぞれの業務データの特性に合わせて細かく定義することをオススメします。

なお、ファイルを添付したい業務には “ファイル型” というデータを用意します。『請求書PDF』『ラフデザイン』『工事現場の写真』など、様々な業務プロセスが想定されます。なお、あえて『ファイルサーバのURL』という “文字型データ” で受け渡しするケースもありますが、利便性を考えると基本的には “ファイル型データ” の方が有用です。もっとも、機微なファイルで「アクセス履歴を押さえたい」や「さらに細かく閲覧権限を制御したい」といったニーズがあれば、その限りではありません。

意外と大切なことは、業務上の「注意事項」や「ヒント」あるいは「入力例」をセットで考察しておくことです。それぞれの “データ項目” の枠外に記載したり、表示専用の “ガイドパネル” にまとめて記載したりします。

実はこの「注意事項」ですが、業務プロセス定義の作業において最も時間を要してしまいます。

もちろんワークフローシステム（ワークフローエンジン）の視点では「あっても無くても構わないモノ」なのですが、「人間による入力ミスを減らすため」にはどうしても不可欠です。もし、入力値に誤りがある案件が流されると、それ以降の下流工程にムダな作業を強いることになってしまうからです。

プロセスオーナーは「入力値にミスがある案件」の発生率に、常に注意をはらうべきです。いわゆる「手戻り」の発生は組織として大きな損失になります。加えて、処理者たちのモチベーション低下を招きます。もし発生率が5%を超えるようであれば「システム化する価値」すら疑問です。もちろん「”ゴミ案件” 流すな！」「”ドロ団子” 流すな！」のような啓蒙も有効ですが、基本的には、分かりやすい「注意事項」や「ヒント」あるいは「入力例」を記載しておくことが大切です。「業務プロセスを憎んでヒトを憎まず」の精神で（！？！）、業務プロセスを改善し続ける必要があると考えています。

7. パーミッションの考察

業務プロセスに流されるデータの “パーミッション” を検討します。

すなわち、それぞれの工程について

• どのデータを参照できるか？ （Read権限）
• どのデータを更新できるか？ （Read/Write権限）
• 閲覧できないデータは何か？ （その存在すら気づかない）

を検討します。

もちろん全ての工程の設定で、全てのデータを「更新できる」としても構いません。「ワークフローシステムとして運用できなくなくはない」と思います。しかし、業務案件をスムーズに流すためには「処理しやすいパーミッション設定」について検討する必要があります。

ここでは処理者視点での「読み書き権限」（Read/Write権限）について記載しています。別途、モニタリング視点での「参照権限」（Read権限）も検討する必要があると言えます。一般論的には、役員や管理職者だけでなく、他部署へも広く「参照権限」（Read権限）を付与しておくことで、部署間のコミュニケーションコストを下げることができます。

8. 処理者についての考察

ヒューマン工程の “処理者” を規定します。

ここで大切なコトは「ワークフローエンジンが理解できるように規定すること」です。つまり “2.処理者の検討” では、”登場人物” について名前を付けただけでしたが、ここではワークフロー基盤の『ユーザ』（や『組織』や『ロール』）をセットします。

“処理者” が1人だけ設定された場合（例：ユーザ “Suzuki”）、流れてきた仕事は、自動的に当該ユーザに［割り当て］られます。しかし複数人が設定されている場合（例：組織 “営業部” の所属者全員）は、そのユーザ達の誰かが引き受ける必要があります。ワークフローエンジンは彼らを “処理候補者” とみなして［引き受け］を促すことになります。

9. ワークフローシステムとして稼働

設計した業務プロセスを、ワークフローシステムとして稼働させます。

この動画にあるように『開発中のバージョン1のリリース』をクリックするだけで、ワークフローシステムとして稼働します。すなわち “先頭工程” から新しい案件を流せるようになります。

※この動画でモデリングされた業務プロセスをダウンロードしたい場合はこちらから。

10. そして改善サイクルへ

昨今「テレワークで停滞する業務を円滑化したい」という声をよく見聞きするようになりました。

このフレーズ自体はたしかに「バックリとしたニーズ」なのですが、つまるところ「あるべき業務の進め方」（To-Beプロセス）が大きく変化しているのだと思います。プロセスオーナーとしては、現状（As-Isプロセス）にとらわれず、勇気をもって、「積極的な改変」に挑戦していきたいものです。

みなさんも、是非、ワークフローシステムを改善し続けてください。No-Code で！！

こんにちは！矢作です！

本記事では、資料請求に対応する仕組みを Box を活用して構築する方法を紹介します。構築された仕組みでは、資料請求フォームで氏名とメールアドレスが入力されると、請求者に資料ファイルを閲覧できる URL が差し込まれたメールが送信されます。

請求受付後の処理はすべて自動化されるので、大幅な手間の削減とミスの防止を実現可能です。

ノーコード開発クラウド Questetra BPM Suite

「業務の自動化」には、ノーコード開発クラウド「Questetra BPM Suite」を利用します。

Questetra BPM Suite では業務の流れ図（ワークフロー図）の作成を通じて、業務システムが構築されます。構築されたシステムでは、業務データが電子化されるだけではありません。人への業務情報の受け渡しが自動化されるとともに、文字変換、数値計算、メール送信、なども自動化されます。更に、他のクラウドサービスへのデータ連携も自動化されます。

このような自動化は、ワークフロー図において自動化したいタイミング（例えば、営業課長が見積承認したら）に、何らかの自動処理が行われるアイテム（例えば、見積書ファイルが Box にアップロードされる）を配置することで実現されます。

Questetra BPM Suite に用意されている様々な自動化アイテムを利用すると、簡単に「業務を自動化」できるようになります。

クラウドストレージ Box ファイルコピー

Box は企業向けのクラウドストレージサービスです。2022-02-22時点に、Box 導入事例ページには、「顧客企業数100,000以上、67%がフォーチュン500企業」と書かれており、大変多くの企業で利用されています。

前節で紹介した「Questetra BPM Suite (v13.3.0)」に用意されている自動化アイテムには、Box に関するものが用意されています。

• Box: ファイルアップロード
• Box: ファイルコピー
• Box: ファイル移動
• Box: ファイル共有リンク作成
• Box: ファイル共有リンク削除
• Box: ファイル削除
• Box: ファイルダウンロード
• Box: フォルダ作成
• Box: フォルダ検索
• Box: フォルダ共有リンク作成
• Box: フォルダ共有リンク削除
• Box: フォルダ削除
• Box: コラボレーション追加
• Box: コラボレーション削除

次節で作る仕組みでは「Box: ファイルコピー」「Box: ファイル共有リンク作成」（太字）が使用されます。

資料請求対応でのファイル複製を自動化

今回は、次のような処理が行われるシステムを構築します。

• 資料を求める人（資料請求者）が、資料請求フォームに氏名とメールアドレスを入力する。
• Box に用意された資料（ファイル）がコピーされる。
• コピーされたファイルに共有リンクが作成される。
• 資料請求者に、共有リンクが差し込まれたメールが送信される。

最初に、資料請求者が氏名とメールアドレスを入力する以外の工程は、全て自動で処理されます（太字）。

まずは、この業務の流れ図（ワークフロー図）を作成します。（以下、Questetra BPM Suite で構築）

このワークフローにおいて、人が処理するのは一番左の赤丸のアイテム「1.資料請求フォーム」のみです。ここで、氏名とメールアドレスが入力されると、後ろに連なる工程が順番に処理されます。

• 「2.資料コピー」では、予め Box に保存された資料ファイル（コピー元ファイル）がコピー（複製）されます。
• 「3.共有リンク作成」では、複製されたファイルに共有リンクが作成されます。このとき、リンクの有効期限も設定されます。
• 「4.請求者へメール」では、作成された共有リンク（URL）が差し込まれたメールが、資料請求者に送信されます。

予め Box に保存された資料ファイル（コピー元ファイル）のファイル ID を、データ項目「資料ファイルID（コピー元）」の初期値に設定します。資料ファイル（コピー元ファイル）のファイルIDは、そのファイルのURLの一部（次の青い部分）です。

https://example.app.box.com/file/xxxxxxxxxxxx

また、複製されたファイルが保存されるフォルダを予め作成しておきます。「2.資料コピー」の “C3: 保存先フォルダのID” には、作成したフォルダの URL の一部（次の青い部分）を設定します。（ファイルIDと似ていますね）

https://example.app.box.com/folder/xxxxxxxxxxxx

「3.共有リンク作成」では、共有リンクの期限が設定されます。今回は、申し込みの1ヶ月後を期限とします。データ項目「共有リンク期限」の “初期値” で「プロセス開始日時の１ヶ月後」を選びます。

資料請求が行われると、資料請求者は届いたメールのURLをクリックして、資料を確認できます。

まとめ

今回は、資料請求フォームに氏名とメールアドレスが入力されると、その後は人が関与することなく完全自動化された仕組みを構築する方法を紹介しました。

請求フォームで請求情報が入力されると、資料請求者に資料閲覧のための URL がメール送信されます。しかも、その URL には有効期限が設定されているため、SNS 等でシェアされてしまっても、その影響が最小限に抑えられます。

完全自動化されているため、人が対応する場合と比べて、ファイルコピーや共有設定の手間が削減されます。さらに、請求への対応忘れや遅れ、誤ったファイルを案内してしまう、メールの宛先を誤る、というようなミスも防止されます。

ノーコード開発プラットフォーム「Questetra BPM Suite」に用意されている自動化アイテムを利用すると、Box の API (Application Programming Interface) に関する知識・経験がなくても、ファイルコピー、共有リンク作成が自動処理される仕組みを構築できます。

「Questetra BPM Suite」には60日間無料でご利用いただけるトライアルが用意されています。ご興味のある方は、是非、以下よりお申し込みください。

他にもたくさんの自動化が可能です。

今回はここまで！

こんにちは。クエステトラの木村です。
さて早速ですが、ワークフロー（ここでの意味は業務フロー・業務の流れと繋がりと置き換えてください）を構築していくにつれて、いつの間にか巨大なものを作ってしまうことがあります。

もっとも、ワークフローが大きくなること自体は悪いことではありませんが、今回は他分野からの「考え方」を拝借して、改めてワークフローの「大きさ・範囲・単位」を考えてみたいと思います。

モノリシックなシステムとマイクロサービス

皆様はモノリシックなシステムという言葉で、何か思い浮かぶものがありますでしょうか。
想起できる方は、インターネットを介したシステムの「インフラ」部分に明るい方だと思います。

さて、皆が日常的にアクセスするインターネット上のサービスは「サーバー」と言う、大きな受け答えシステムに接続しています。このシステムはとても上手く構成されており、1つのサーバーの中にOS（Linux）、HTTPのやりとりを行うミドルウェア（ApacheとかNginxとか）、データベース（MySQLやPostgreSQLとか）、サーバサイド言語（PHPとかJAVAとか）が同居可能です。

また、Webサービスを提供する上で必要な機能は一つのサーバー内に格納されている形が標準的なものでした。10年前ぐらいまでは、規模の大きなECサイトなどでもメインのサーバと、予備サーバーの2台で本番の運用が可能な状態でした。

さて、時代は変わり今や令和。10年前と異なり「クラウドサービス」がより一般化してきました。
例えば会計ソフトのfreee。国内の多くの銀行と連携可能ですので取引情報管理に費やす時間を抑えることが可能です。そしてまた、このfreee自体がAPIを公開していますので、自社で慣れ親しんだシステムと通信して使うことができます。上記からも「クラウドサービス」という、自社のサーバ内でサービスを運用する以外に、インターネットを介して「サービスのみ」を利用する時代が現在の主流になりつつあると言えるでしょう。

さて、マイクロサービスの考えは上記の「クラウドサービス」を使うことに少し似ていて、「一つのサーバーの中で、全ての機能を賄う」のではなく、「機能ごとに」サービスを別個で設置し通信することで全体のサービスを成り立たせる考えとなります。

上の図でわかるように、これまでは「モノリシック」な運用。
一つのサーバーの中で、各プログラムが同居してビジネスロジックを実現します。
一方で、マイクロサービスは各機能ごとにサーバーが分かれています（便宜上、この様に表現していますが、サーバーレスとも言えます）。あくまで、各個が「機能」を提供しており、それらは「通信」によりやりとりが行われる仕組みです。

マイクロサービス – Wikipedia
さて、マイクロサービスのメリットとデメリットは以下だと言われています。（大まかに）

メリット

• 独立性：Aチームは機能Aの改修、Bチームは機能Bの追加、など別個での開発が可能
• 保守性：他のサービスとの境界線が明確なため、機能追加時などの影響範囲が限定的
• 拡張性：機能C自体の処理能力を上げたい場合、単体でのマシンリソースの拡張などが容易
• 可用性：問題のあるサービスのみ切り離し、その他の機能だけ動かすことが可能
• 再利用性：特定の機能に該当する箇所のみ類似のサービスに変更可能

デメリット

• 通信：外部と通信を行うため、トランザクション処理などには注意が必要
• 「コンウェイの法則」に指摘されるように、組織の考え方が「独立」している必要がある
• 構造：機能Aではこの開発言語、機能BではAで使用している言語と異なる言語など運用が可能なため、これらに付随する開発ツールやインターフェイスがバラバラになる可能性がある

コンウェイの法則 – Wikipedia
さて、上記でマイクロサービスがどの様なものであるか、少し理解が進んだでしょうか。
では早速ワークフローでのマイクロサービスを考えていきましょう。

考え方1：機能毎にアプリを分けて作成する

上の図にある左側のワークフロー・業務プロセスを「フルフィルメントサービス」のワークフロー図として考えてみます。フルフィルメントサービスは、受注から発送、そして社内では会計までが一つの大きな業務と考えることが可能です。

しかし、先に掲示したマイクロサービスの考え方に倣い「機能毎」にアプリ（ワークフローをシステム上で組み上げた状態のものとしてのアプリ）を分けて作成することで、一つのアプリと比べ「小さな」アプリを作成することが可能となります。改修や保守も楽になりそうですね。

さて、上の図では「大きなアプリ」で実運用を行っている中で、一部でエラーが発生した状況です。この場合、他の機能や部署と連動して進行すべきプロセスが一気に停止する恐れがあります。一方で、機能毎にアプリをわけて「通信」で運用していれば、考える上ではエラーを起こしているアプリのみが問題となるはずです。一部のアプリが停止していても、その他のアプリは稼働中（稼働可能）と考えられるため、エラーや障害発生時の影響範囲は小さくて済みそうです。

2. 外部のシステム（サービス）との連携

上の図では、各機能ごとに各社でサービスが提供されているものを想定して当て込んでみました。例えばですが、あくまで受注のインターフェイスはShopifyなどで実施し、受注が発生したタイミングでクエステトラのアプリを起動。データを取り込んで、次の外部サービスまでの工程をクエステトラのアプリ上で処理する、などの運用が考えられます。また受注だけではなく、決済や実際に人に作業してもらうBPOへのアサインなど、外部との連携も「各機能」アプリごとに連動を実施すれば、内製が難しい機能であっても比較的迅速に導入することが可能と考えられます。

クエステトラで小さなアプリを実現するための「アイテム（パーツ）」

先の章までで、マイクロサービス的考えをもち、ワークフロー・業務プロセス（アプリ）をどの様に分割できるか、一つの概念例を紹介しました。ここまで読んでいただいた方の中にも「まあ、考え方としてはわかるけど実際は結構難儀するのでは？」と思っている方も多いでしょう。しかしですね。クエステトラには、こうした「マイクロサービス的ワークフロー」を実現するためのアイテムが、実はふんだんに用意されています。

アイテム（パーツ）の一覧はこちら
https://questetra.zendesk.com/hc/ja/articles/360007459612

開始イベント群（標準で用意されているパーツ群）

• メッセージ開始イベント（HTTP / Webhook / メール受信 / フォームへの入力）
• その他の開始イベント（Gmail受信時 / Google カレンダー予定 / Kintoneレコードへのデータ追加時　など）

中間イベント群

• ワークフローの途中で、既存の別ワークフローを起動するパーツ（各社環境により個数・名称が変動）

外部とのOAuth2認証

などなど。

一般的な開発でAPIを触ったことがある方であれば、既存パーツと外部サービスのAPIを駆使して、小さなアプリを無尽に連携させることも可能です（そこまで多数の連携はしないと思いますが）

業務テンプレートの大活用

クエステトラでは、一般的に作成されるであろう業務システムに準じたワークフローアプリのテンプレートを多数準備しています。

これらのテンプレートは無料で利用することができますし、先のマイクロサービスの考え方に沿って既存テンプレートをいくつかのアプリに分割し、自社で運用しやすい粒度のアプリ群として使用していくことも可能です。

クエステトラ　サポートサイト：ワークフローアプリ（業務テンプレート）
https://questetra.zendesk.com/hc/ja/articles/360012492211

いかがでしたでしょうか。

まあ今回も強引に「マイクロサービス」の良いところを「ワークフローアプリ」を作成する上で拝借し記事を書いてみましたが、実際の現場では全てマイクロサービス的な考え方が適するとは言えません。その現場にいる人達が、間違いなく・ストレス無く業務を行えるための「適切なワークフローの大きさ」は、ケースバイケースだからです。しかしながら、マイクロサービス的ワークフロー構築。難しい場所は開発チームに任せて、簡単に作れそうな部分は部署内でガシガシ作る、みたいな事が実際にできますので、考え方を検討してみるのも「業務改善」に一役買います。

それではまた。
今回はこの辺で失礼します。

マイクロサービス的ワークフローアプリの構築を無料で試したい方はこちら

こんにちは！矢作です！

「自動化のススメ – Google カレンダー 予定追加」では、予定が追加される仕組みを構築しましたが、今回は追加された予定が自動削除される仕組みを構築します。

ノーコード開発プラットフォーム Questetra BPM Suite

「業務の自動化」には、ノーコード開発プラットフォーム「Questetra BPM Suite」を利用します。

Questetra BPM Suite では業務の流れ図（ワークフロー図）の作成を通じて業務システムが構築されます。構築されたシステムでは、人への業務案件の受け渡しが自動化されるだけではありません。文字変換、数値計算、メール送信、なども自動化されます。更に、他のクラウドサービスへのデータ連携も自動化されます。

このような自動化は、ワークフロー図において自動化したいタイミング（例えば、問い合わせ窓口担当者が回答を入力した後）に、何らかの自動処理が行われるアイテム（例えば、回答メールが自動送信される）を配置することで実現されます。

Questetra BPM Suite に用意されている様々な自動化アイテムを利用すると、簡単に「業務を自動化」できるようになります。

Google カレンダー(Calendar) 予定削除

Google カレンダーとは、チームでスケジュールを共有できる仕組みです。個人だけでなくグループのスケジュール、また会議室や備品の利用スケジュールも共有できます。Google ドライブや Google スプレッドシートなどと同様に、Google Workspace に含まれています。

前節で紹介した「Questetra BPM Suite」に用意されている自動化アイテムには、Google カレンダーに関するものが用意されています。（v13.3.0）

• Google カレンダー: 予定追加
• Google カレンダー: 予定のカレンダー移動
• Google カレンダー: 予定削除

次節で作る仕組みでは「Google カレンダー: 予定削除」（太字）が使用されます。

予約キャンセル処理後、予定がカレンダーから自動削除

記事「自動化のススメ – Google カレンダー 予定追加」では、製品デモの予約が受け付けられると、その予定が自動的にカレンダーに追加される仕組みを構築しました。

本記事では、申し込まれた予約がキャンセル処理されると、カレンダーに追加されていた予定が自動的に削除される仕組みを構築します。次のような流れで、カレンダーの予定が削除されます。

• 電話やメールなどで、製品デモのキャンセル依頼を受け付ける。
• キャンセル処理担当者は、製品デモに関する申込情報を検索し、該当するデータについてキャンセル処理を行う。
• デモ予約カレンダー、空き時間カレンダーに登録されていた予定が削除される。

「自動化のススメ – Google カレンダー 予定追加」で作成したワークフロー図に、削除に関するフローを追加します。（次図）

追加したワークフローでは、キャンセル担当者が青い四角アイテム「キャンセル処理」で削除する予定の予定IDを入力します。「キャンセル処理」に連なる2つのグレーの四角アイテムで、該当の予定が2つのカレンダーから削除されます。

実際に、キャンセル担当者は予定IDを手入力するのではなく、次の手順でキャンセル処理します。（簡単です！）

• 氏名やメールアドレスで、製品デモの予約情報を検索。
• 該当の情報が見つかったら、詳細画面の「このデータを再利用してプロセスを開始」をクリック。
• 表示された画面では、削除する予定の予定IDが入力された状態になるので、そのまま処理完了ボタンを押下。

この後、自動的に該当の予定が2つのカレンダーから削除されます。

まとめ

「自動化のススメ – Google カレンダー 予定追加」で、登録された予定が自動的に削除される方法を紹介しました。

削除の際には、Google カレンダーに登録された予定の “予定ID” が必要となりますが、”予定ID” は登録時に取得していると問題なく削除できます。

今回の自動化に使用した、ノーコード開発プラットフォーム「Questetra BPM Suite」に用意されている自動化アイテムを利用すると、Google カレンダーの API (Application Programming Interface) に関する知識や経験がなくても、Google カレンダーの予定が自動削除される仕組みを構築できます。

「Questetra BPM Suite」には60日間無料でご利用いただけるトライアルが用意されています。ご興味のある方は、是非、以下よりお申し込みください。

他にもたくさんの自動化が可能です。

今回はここまで！