こんにちは。
クエステトラの木村です。
さて早速ですが、ワークフロー（ここでの意味は業務フロー・業務の流れと繋がりと置き換えてください）を構築していくにつれて、いつの間にか巨大なものを作ってしまうことがあります。
もっとも、ワークフローが大きくなること自体は悪いことではありませんが、今回は他分野からの「考え方」を拝借して、改めてワークフローの「大きさ・範囲・単位」を考えてみたいと思います。
モノリシックなシステムとマイクロサービス
皆様はモノリシックなシステムという言葉で、何か思い浮かぶものがありますでしょうか。
想起できる方は、インターネットを介したシステムの「インフラ」部分に明るい方だと思います。
さて、皆が日常的にアクセスするインターネット上のサービスは「サーバー」と言う、大きな受け答えシステムに接続しています。
このシステムはとても上手く構成されており、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で使用している言語と異なる言語など運用が可能なため、これらに付随する開発ツールやインターフェイスがバラバラになる可能性がある
さて、上記でマイクロサービスがどの様なものであるか、少し理解が進んだでしょうか。
では早速ワークフローでのマイクロサービスを考えていきましょう。
考え方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
クエステトラ：テンプレート
https://questetra.com/ja/workflow-template/
いかがでしたでしょうか。
まあ今回も強引に「マイクロサービス」の良いところを「ワークフローアプリ」を作成する上で拝借し記事を書いてみましたが、実際の現場では全てマイクロサービス的な考え方が適するとは言えません。
その現場にいる人達が、間違いなく・ストレス無く業務を行えるための「適切なワークフローの大きさ」は、ケースバイケースだからです。
しかしながら、マイクロサービス的ワークフロー構築。
難しい場所は開発チームに任せて、簡単に作れそうな部分は部署内でガシガシ作る、みたいな事が実際にできますので、考え方を検討してみるのも「業務改善」に一役買います。
それではまた。
今回はこの辺で失礼します。
マイクロサービス的ワークフローアプリの構築を無料で試したい方はこちら↓
