キーポイント
- Low-code platforms are the hottest enterprise software category right now. With the current level of investment, it is hard to imagine a future that doesn’t feature lots of bespoke business apps being built by non-IT staff for use by their teams.
- Low-code platforms can be grouped into three different categories: UI generation software, integration software, and transformation software
- Community developers are staff in your organization who use low-code platforms to create solutions for themselves and their teams because they are not able to use their enterprise systems to accomplish certain tasks. These users have always existed. Today, you can see them creating masterpieces in Excel.
- Community developers create two types of risks. First, integration risk, which involves exposing data that shouldn’t be exposed. And second, transformation risk, which involves bugs or miscalculations in the app that lead to bad business decisions.
- Visibility of low code solutions is the key to managing risk. To maximize the visibility inherent in having community developers building apps, it’ is recommended that you make available a single low code platform for your community developers. You must also provide training to your community developers on that platform.
ローコードプラットフォームは、現在最もホットなエンタープライズソフトウェアのジャンルです。数百というスタートアップに加えて、過去24か月間で、3大クラウドプロバイダがいずれも独自のローコードプラットフォームをローンチしています。これほどの投資が行われているからには、非ITスタッフが自分たちのために自らの手で開発した独自ビジネスアプリが世に溢れる、そのような未来を想像しない訳にはいきません。
このトレンドが皆さんのIT組織に与える影響を理解するための一助として、現在使用可能なローコードプラットフォームにはどのようなものがあるか、それらを欲しがるのは企業内のどのようなスタッフなのかを議論したいと思います。その上で、ローコードプラットフォームが皆さんのITアーキテクチャに適しているか確認し、最終的には、ローコードの世界でITをマネジメントするために最適な戦略について、私たちの見解を示していきます。
ローコードプラットフォームとは何か
ローコードプラットフォームとはExcelのようなものだ、と考えればよいでしょう。つまり、ユーザが使用可能で、さまざまなビジネスシナリオにおいて有益なソフトウェアツールです。このようなツールを使用することで、ソリューションも、新たな問題も生み出されます。
私たちはローコードプラットフォームを3つのカテゴリに分類しました。これらのカテゴリは、それぞれが企業内の異なるタイプのユーザに支持されることになります。
- UIジェネレーションソフトウェア
RetoolとBubbleはおそらく、この種のサードパーティアプリケーションとして最も知名度の高いものでしょう。プラットフォーム上のテーブル内に格納されたデータを操作するインターフェースを、ユーザが簡単に作ることができます。
3大クラウドプロバイダの提供する競合サービスは次のものです。 - インテグレーションソフトウェア
Zapierは、この種のローコードアプリケーションのプロトタイプ的な例です。ユーザはソフトウェアアプリケーション間の接続と、接続を通じてデータを移動させるトリガを作ります。 - トランスフォーメーションソフトウェア
これは、アプリケーション間をデータが移動することによって付加価値を生み出すことを主目的とする、広い意味でのソフトウェアです。AWS SagemakerのようなマシンラーニングツールやSyphtのようなデータ抽出ツール、UIPathのようなRPAソフトウェアがこのカテゴリに含まれます。
ローコードプラットフォームのソート可能なリストを見るには、ここをクリックしてください。
コミュニティ開発者とは何か
コミュニティ開発者(community developer)とは、ビジネス上の特定の問題を解決するソリューションを、ローコードプラットフォームを使って自分や自分たちのチームで開発する、企業内のスタッフのことです。
このようなユーザは以前から存在していました。今日では、彼らがExcelを使って傑作を作るのを見ることができます。その意味でExcelユーザは、ローコードプラットフォームで使用するものと同じカテゴリでグループ分けできるでしょう。
- UIクリエータ: Excelでテーブルを作り、読みやすいようにデータをフォーマットするユーザ。ローコードのユーザがローコードUIアプリケーションで関連テーブルを作るのと同じように、彼らはVLookup式のようなテクニックを駆使して、ワークシート間を越えてデータをリンクします。
- インテグレータ: Excelにインポートした大規模なデータセットを操作したり、データベースやAPIからExcelにリンクしたデータを使用するなど、より高度なExcelアプリケーションを開発するユーザ。
- トランスフォーマ: 広範なデータ変換を実行する、高度な演算式を作成するユーザ。VBAを使って、さらに高度な変換を行う関数を開発するユーザもいるでしょう。
コミュニティ開発者が企業内でローコードプラットフォームを使用する方法
コミュニティ開発者の多くは、3つのステージを経ることで、ローコードプラットフォームを使用する能力を高めます。大部分のコミュニティ開発者は第1ないし第2ステージに留まるのですが、一部は第3ステージまで達して、ビジネス全般で使用できるようなフル機能のアプリケーションを開発するようになります。
ステージ1 — UIジェネレーション: 彼らが最初に作るのは、キー入力されたデータを使って、優れたユーザインターフェースを提供するようなアプリケーションです。例えば、ミーティングの進捗に伴ってユーザがミーティング記録を書き加えられるような、ミーティング記録アプリケーションを作るかも知れません。これがUIジェネレーション(UI Generation)ステージです。
ステージ2 — インテグレーション: 経験を積んだユーザはステージ2に移行して、外部のシステムやデータソースからデータを引用するようになります。例えばミーティング記録アプリケーションを拡張して、Outlookからカレンダ情報を引き出したり、ミーティング後に記録のコピーを参加者にEメールしたりするようになります。これがインテグレーション(Integration)ステージです。
ステージ3 — トランスフォーメーション: そして、最終的に彼らは、ますます高度な変換を実行するアプリケーションを開発するようになります。例えば、マシンラーニングモデルを通じてミーティングノートを実行して、ミーティングコンテンツのタグ付けと保存を行うことで、トピックによる検索が可能にするのです。これがトランスフォーメーション(Transformation)ステージです。
コミュニティ開発者のモチベーションは何か
コミュニティ開発者がローコードアプリケーションを開発するのは、企業システムでは完遂できないタスクを彼らが抱えているからです。企業システムというのは、言うなればモザイクのようなものです。目標はそのアプリケーションスタックを、隣接するアプリケーション同士が直接的につながった、きれいに張り詰められた壁のようなものにすることです。
写真提供: Wengang Zhai (Unsplashより)
しかしながら、合併や買収、歴史的経緯による例外、ビジネス要件の変化などのために、スタックはオーバーラップしたり、他の領域とのギャップが生じたりするのが現実です。コミュニティ開発者がExcelスプレッドシートを作成したり、ローコードプラットフォームを使用したりするのは、このようなギャップを埋めるためなのです。ユーザはITスタックを、上の写真よりも、下の写真のようなイメージで見ているのかも知れません。
写真提供: Марьян Блан | @marjanblan (Unsplashより)
このようなユーザを支援するために、従来は、ギャップを埋めるための3つの選択肢がありました。
- 必要なタスクを達成できるように、企業システムを拡張する。例えば運用チームが、顧客が過去に購入した全製品を参照するために、財務システムやERP(Enterprise Resource Planning)システムなどのコアITシステムからのデータを必要としているならば、ITチームがコアシステムを拡張して、この情報をコアシステムの顧客レコードの一部として提示する方法が考えられます。
- ユーザの特別なニーズを解決するために、カスタムメイドのアプリケーションを開発する。例えば引受業務チームが、区分所有不動産(strata property)に関わるリスク評価を必要としているならば、この情報を提供するカスタムアプリケーションを開発するという方法があります。
- そのタスクを実行するサードパーティツールを購入する。例えばカスタマサポートチームが、自社に関するツイートをモニタする方法を必要としているならば、Twitterモニタリングサービスと契約することができます。
いずれの方法にもメリットとデメリットがあります。
最初の選択肢(コアシステムの拡張)では、新たなシステムやアプリをスタックに追加することなく、ユーザのニーズに対応したソリューションを提供できる一方で、ソリューションの構築やテストやデプロイに時間を要する、チームの保有するリソースによって制限を受ける、といったデメリットがあります。需要がカスタムソリューションを提供する能力を超えてしまうのに、それほど時間はかからないでしょう。
第2の選択肢(専用ソリューションの構築)は、ERPシステムを拡張するよりも容易なことが多いのですが、それでもソリューションの開発やテスト、デプロイ、サポートに要する労力は少なくありません。
第3の選択肢(サードパーティソリューションの利用)は、完成度の高いソリューションを実現できる可能性のある一方で、調達とインテグレーションに時間やリソースを必要とします。また、サードパーティソリューションは他の企業システムとオーバーラップする機能を含んでいることが多く、結果として同じタスクを実行する方法が複数存在することになります。
コミュニティ開発者は、このIT機能のギャップを埋める第4の選択肢を提供します。理屈の上では、痒い所に手の届くアプリケーションを開発するコミュニティ開発者の小部隊が存在すれば、企業のIT開発能力は飛躍的に向上することになります。
一方で、リスクも少なくはありません。ITチームが、魔法を使って王国を救う魔法使いの小集団だとしましょう。そこで突然、誰もが魔法を使えるようになったら、世の中はどうなるのか、想像してみてください。素晴らしいことが成し遂げられる可能性はありますが、間違いが起きることも避けられないでしょう。城の防衛計画が、誰かの不注意で近隣の王国に漏れてしまうかも知れません。
リスクはどこにあるのでしょう？
コミュニティ開発者には2つのリスクがあります。Excelの使用が問題を生じさせる例を使って、これらのリスクについて議論しましょう。
- インテグレーションのリスク: このリスクは、公開すべきでないデータの公開に関わるものです。Excelでは、これは非常にまれですが、最も厄介なリスクでもあります。コミュニティ開発者は、送信するつもりのないデータを含んだExcelスプレッドシートをEメールすることによって、通常は送るべきでない場所に誤ってデータを送ることがあるのです。例えば2017年、Boeingの社員がEメールで送信したExcelシートに、不注意から36,000名の社員の個人情報が含まれていたことがありました。API経由でデータを移動するローコードプラットフォームでは、このような問題の発生する機会が飛躍的に増加することになります。
- トランスフォーメーションのリスク: このリスクは、誤ったビジネス判断につながるような、アプリ内のバグや計算ミスに関するものです。これはExcelソリューションに関する最も一般的な問題です。ある研究によれば、Excelスプレッドシートの大部分には、少なくともひとつのエラーが含まれているというのです。この種のエラーの例として、英国で昨年、スプレッドシートのエラーが原因で新病院のオープンが遅れたことがありました。同じように、ローコードプラットフォームにもトランスフォーメーションエラーが含まれる可能性はありますが、現在のExcel以上にそれが蔓延するとは思われません。
Excelのリスクに関するその他の例は、こちらをクリックしてください。一通り目を通せば、コミュニティ開発者が企業に対して与えるリスクがどのようなものであるか、理解する上で役に立つでしょう。
ローコード利用の各ステージには、企業に対するさまざまなリスクプロファイルがあります。
ステージ1 (UIジェネレーション)では、コミュニティ開発者はローリスクです。先程のノートアプリケーションの例で述べたように、このステージで通常扱われるデータは、アプリケーションに手入力されたものです。ですから、Eメールやその他の通信で許容される使用方法を処理するのと同じように、これを管理する必要があります。
ステージ2 (インテグレーション)では、コミュニティ開発者のリスクはもっと高くなります。このステージでは、ローコードプラットフォームを使ってCRM(Customer Relationship Management)システムのデータを読み書きしたり、Clearbitによる見込み客の情報の補完やMailgunによるダイレクトメールの送信などの外部APIを使用したりします。このタイプのアプリケーションは、サポートシステムから取得したジョブデータを現場スタッフに提供したり、あるいはCRMから抽出した情報を営業スタッフに提供したり、といった機能を実行します。このようなアプリケーションは、ユーザ認証上のリスクやデータセキュリティの問題を発生させるのです。おそらくは、ユーザがどのシステムと統合して、そのデータで何を行うのか、適切なコントロールを配置したいと考えるでしょう。
ステージ3 (トランスフォーメーション)は、コミュニティ開発者のリスクが最も高いカテゴリです。社外のシステムから社内システムにデータの読み書きを行うだけでなく、データの変換も行うからです。これらのタイプのアプリケーションには、AWS Sagemakerのようなマシンラーニングソリューションを利用して独自のメリットを企業に提供するようなアプリも含まれます。例えば、見込み客のデータをCRMから取得してTwitterから抽出したデータと組み合わせ、AWS Sagemakerでトピックモデル分析を実行することで、ツイートしているトピックに基づいて見込み客をターゲットにする、というようなことも行われるようになるかも知れません。
インテグレーションフェーズに生じるリスクの他にも、これらのアプリはデータの不正確な変換というリスクも発生させます。例えば、コミュニティ開発者がカスタマサポート上の問題の重要度(つまり、どれを処理するかという優先度)を分類するマシンラーニングモデルを構築した場合、特定のグループを別のグループよりも不適切に優先させるような、性別や人種によるバイアスをそのモデルに持たせたくはないでしょう。
下の図は、ローコードプラットフォームにおけるリスクについての考え方を示すものです。
それぞれの図がステージを表現しています。各ステージのオレンジ色の部分は、IT組織が関与すべきではないアプリの割合、紫色と赤色の部分は、IT組織が関与すべきアプリの割合を示しています。赤色の部分は、機密データを扱うアプリの割合を示すもので、この部分にはインテグレーションリスクがあります。紫色の部分は、アプリが複雑であるため、ITチームによる関与が妥当であると考えられるアプリの割合を示しています。
最初の図が示すのはカテゴリ1のUIジェネレーションアプリです。これらのアプリは総じて低リスクであり、IT部門が関与する必要性は、アプリケーション内のデータがその管理下に置かれるべきものである場合に限られます。例えば、ミーティング記録のアプリにIT部門が関わる必要はありませんが、患者の記録を扱うアプリには関与する必要があります。アプリが複雑なためにIT部門の関与が必要になることは、このカテゴリではめったにありません。
次の図はカテゴリ2の、他システムと統合されたアプリを表しています。このカテゴリには、リスクのより高いアプリケーションが含まれる可能性があります。ステージ1のアプリケーションよりも紫色の部分が大きく、赤色とオレンジ色が小さいことが、IT部門の関与すべきアプリの割合の多いことを示しています。
最後の図は、重要なデータ変換機能に関わるカテゴリ3アプリを示すものです。このカテゴリには、最もリスクの高いアプリケーションが含まれています。紫色の割合が大きく、オレンジ色の小さいことが、ステージ2のアプリケーションよりも多くのアプリにIT部門が関与すべきであることを示しています。
まとめ: ローコードプラットフォームのリスク管理
好むと好まざるに関わらず、コミュニティ開発者はすでに企業内でExcelを使っていて、ローコードプラットフォームという新たなツールへのアクセスを求め始めています。このトレンドは止められませんが、それに抗うことはできますし、必然として受け入れることもできます。正しく行えば、コミュニティ開発者の小部隊を持つことで、企業のIT機能を飛躍的に向上させることが可能になります。
今日では多くの企業が、意思決定者がビジネス上の判断を行うために使用するスプレッドシートによって、重大なリスクにさらされています。ローコードプラットフォームがこれらスプレッドシートの一部を置き換えるようになれば、企業内にローコードプラットフォームが広がることによって、企業全体のリスクを低減することが可能になるのです。
ローコードプラットフォームソリューションの可視性を最大化することが、リスク管理の鍵となります。アプリを開発するコミュニティ開発者に固有の可視性を最大化するためには、コミュニティ開発者が単一のローコードプラットフォームを使用できるようにするとよいでしょう。
どのローコードプラットフォームを採用すべきか、というのはおそらく大きな問題ではありません。ローコードプラットフォームの機能セットには大差がなくなってきています — ローコードプラットフォームで実行できることは限られていますし、この分野に対する投資のレベルを見れば、どれを選択しても同じようなことが可能であると分かります。ですから、特にこれというローコードプラットフォームを決めていないのであれば、現在利用しているクラウドプロバイダの提供しているものを使うのがよいでしょう。Microsoft AzureのユーザならばPower Apps、AWSユーザならばHoneycodeを使うのです。GoogleユーザならばAppsheetがあります。
次には、コミュニティ開発者に対して、そのプラットフォームのトレーニングができるようにしましょう。特定のプラットフォームを快適に使えるようになれば、別のプラットフォームへのアクセスを要求される可能性はほとんどなくなります。ローコードの痒い所に手が届く手段を提供しておけば、ユーザは、やりたいことを自分自身で達成できるようになります。
そして最後に、既存のITスタックやクラウドプロバイダの提供するマシンラーニングやデータ変換サービスに関する専門的知識を、チーム内で養っておきましょう。コミュニティ開発者がマシンラーニングプラットフォームにアクセスする必要が生じた場合、すでに知見のあるプラットフォームを使用することで、データをより簡単にコントロールすることが可能になります。
著者について
Doug Hudgeon氏は、ビジネス上の現実的な問題をAWS SageMakerを使って解決する方法を記した、Manning(出版社)の書籍"Machine Learning for Business"の著者のひとりです。InfoQはこの書籍を、コード"hudgeonpc"を使って半額で入手することができます。氏はまた、実行可能なデータによるすべてのビジネスアプリケーションの相互接続をミッションとする企業である、Managed FunctionsのCEOでもあります。ビジネスプロセスがコミュニティ開発者にとって過度に複雑ないし高リスクなものになった時は、彼らにManaged Functionsを紹介するとよいでしょう。同社がローコードアプリケーションのリスクレベルを評価して、リスクが一定値を越えている場合には、アプリのインテグレーション/トランスフォーメーションコンポーネントの開発とメンテナンスを行います。同社がユニークなのは、そのコンポーネントをAWS、Azure、あるいはGoogleのクラウドネイティブな関数としてデプロイすることです。これにより、データを自身の環境に留め置くことが可能になります。