ビヘイビアの河又です。今日は、ローコード時代のSaaS事業者側の責務は「徒労」を担う、担い続けることにあるという私の考えを述べてみます。

ローコードという概念の興隆

2018年以降でしょうか。ソフトウェアをプログラミングの専門知識ほとんどなしで現場ベースで構築できる「ローコード」あるいは「ノーコード」と言われるシステムが興隆してきています。

とは言え、私がその代表例である Microsoft Power Apps (& Power Automate) / Amazon Honeycomb / Google AppSheet (& GAS) 等を触って得た感覚としては「完全にコードを書かないわけではない」ので、ひとまず「ローコード」と呼称させて頂きます。

上記のようなガッツリ目のプラットフォームだけでなく、RPAやiPaaSも広義のローコードといえます。

最も現場に詳しい人が、現場用のシステムを作る。ローコードこそ理想形!

我々のようなSaaS事業者は、就労経験やヒアリング、読書で得た知識をもとに業務(ホリゾンタル)や業界(バーティカル)に寄り添ったシステムを構築し、サブスクリプション形式で販売します。

弊社のBehaviorHRであれば、企業の採用担当者様や人材サービス業者の方々に向けて構築しています。

しかし、最も現場に詳しいのは ー 「現場の人」だと思います。

究極的には、SaaS事業者は「部品」のみを提供し、それを組み立てるのは現場の人という体系こそが最高の生産性を発揮するものだと考えています。

これは、日本の産業用ロボット業界が自動車工場との連帯でうまくいったことにも通じます。

過去、うまくいかなかったのは何故か考えてみる

ローコードという言葉が生まれる前から、類型は存在していました。

当時は「RAD(Rapid Application Development)支援システム」や「XRM(X Relation Management)システム」「BPM(Business Process Management)システム」などと呼称されており、代表的な製品として「Lotus Notes」「Dynamics」「ServiceNow」等があります。

しかし、Lotus NotesはIBMが買収したのち非中核事業と判断され既にインド企業に売却済みであり、DynamicsもXRMという概念は当初の宣伝ほどに普及しなかったように思います。ServiceNowは企業として成功していますが、現場の一般社員が主導するのでなく専業のメンテナがいるケースが殆どです。何故でしょうか? ー 私は、徒労が多かったからだと考えています。

オンプレミス製品であれば、まずセットアップから大変です。サーバーを購入してWindows Serverを入れて… これを一般的な「現場の人」が担当するのは無理がありました。IDM(例えばAD)との統合性が低ければ、ID管理の考慮も必要です。自分のパスワードを忘れた社員への対応まであなたの仕事にしますか?面倒すぎますよね。

データベースのバックアップは?バージョン管理は?…矢継ぎ早に指摘され、やる気もなくしていく…

概して「現場の人」に自身の専門外の知識や継続的なメンテナンスを要求するため、導入が手詰まりになってしまう。あるいは情報システム部からカオスの根元として敵対視され「本格的なシステム(ローコードでないもの)」にリプレースされてしまう。これらの要因で、過去にはうまく成立しなかったと考えます。

今回、うまくいくとしたら何故か

新世代のローコードシステムはこれらの問題をある程度解決しています。

各社ともクラウドベースでオンプレミスサーバーの準備は基本不要ですし、それぞれのIDM(ID管理)とも統合されています。Azure AD / G Suite ID / Amazon SSO 等です。また、データベースバックアップ機構も概して内蔵されており、バージョン管理も自動的に行われることが多いです。

過去に比べれば、本格的システムを「現場の人」だけで作成・構築・メンテナンスできる環境が整ってきました。

それでも失敗するとしたら ーまだ残る徒労の担い手はSaaS事業者

システムが作って終わりになることは滅多になく、継続的なメンテナンスが必要です。

例えば弊社のBehaviorHRであれば、媒体横断での求人票一元管理を実現するために各媒体管理画面のスキーマ(画面構成)の詳細な理解とその変更に対する高速な追従が必須です。求人票の各種項目のバリデーション(文字数制限など)も完全に把握しなければ、整合性のあるデータベースが構築できません。

これらの作業を例えば現場の採用担当者様が継続的に行うなら、日常業務を大変に圧迫してしまいます。

人事の方、RPOコンサルタントの方の専門性は上記のようなスキーマ変更追従対応でしょうか。違いますよね。そのため我々はこのような「徒労」を担うことで、採用業務の効率化を支援しています。

(人材採用分野では滅多にないですが)連携先サービスにAPIがあれば、まだ楽です。とは言え、APIのバージョンも更新されていきます。更新対応を延々と続けなければ、いずれ動かなくなるのです。ZapierやPower AutomateなどのiPaaS各社は、その徒労を日々代行しているわけです。

より範囲を広げれば、例えばSmartHRはe-Govや各種申請書類の仕様変更追従という徒労を、MFクラウドやfreeeは銀行やクレカ事業者とのAPIやスクレイピングを駆使した連携という徒労を、それぞれ代行していると考えられます。

ローコード時代のSaaS事業者側の責務は、このような徒労を担う、担い続けることにあると私は考えます。

弊社はBehaviorHRで人材採用に関連するシステム上の徒労を担い続けて、より良い世界を作っていきます。