記事の概要
- 先日、超高速開発ツールとOutsystems Platformに関する記事を書きました。
- →OutsystemsPlatform：超高速開発ツールを知ってみよう！
- 本日は別の「ローコード型 超高速開発ツール」として、キヤノン謹製の「WebPerformer」と比較しながら、それぞれの特徴と超高速開発ツールに関する知見を整理したいと思います。
- また、アジャイル開発との親和性という点でも整理していきたいと考えています。
おことわり
- 筆者は普段、Outsystems Platform（以下、OSP）を業務で利用していますが、Web Performer（以下、WP）は業務利用の経験がなく、ハンズオンや独学の内容が中心になります。
- 少し偏った内容になるかもしれませんが、可能な限りフラットに書きたいと思いますので、最後までお付き合いください。また、お気付きの点などございましたらコメントいただけると嬉しいです。
OSPの紹介
- 前回の記事をご参照ください m(_ _)m
- →OutsystemsPlatform：超高速開発ツールを知ってみよう！
WPの紹介
- キヤノンITソリューソンズ株式会社が提供する、純国産の「ローコード型 超高速開発ツール」です。(WPの公式サイト）
- 公式サイトには大きく次の3種がサービスとして紹介されています。
- Web Performer
- Web Performer WF
- Web Performer WF+
- 「Web Performer」が”ローコード開発ツール”としてコアとなるサービスです。今回はこれにフォーカスを当てて話を整理していきます。
- 「Web Performer」は次の3つのレイヤーでモデリングを実施します。
| レイヤー | 概要 |
|---|---|
| データモデル（DM） | データベースのスキーマやDAOを定義する。 |
| 入出力（IO） | 画面やボタンなどを定義する。ボタンが呼び出す、データ取得処理やビジネスプロセス（下記記載）を設定する。 |
| ビジネスプロセス（BP） | DAO・外部API・Webサービスなどを呼び出し、順序・条件を定義していくことで業務処理を実現する。 |
- よくあるパターンですね。ですが、それぞれが非常に密接になっているので、OSPほど自由度は高くない印象でした。
- 例：1つのIO（画面）に対して、親となるDMを明示的に紐づける必要がある
- 基本的に複数の独立したDMは1つのIO（画面）で表示できない
- 例外として、2世代（1：N）の親子関係にある子のDMなら何個でもOK。3世代（1：N：M）の孫のDMはダメ
- 裏技として、ダミーとなる親を作って、表示させたい独立したDBをそれぞれ子としてマッピングすれば何とかなるらしい
- 例：1つのIO（画面）に対して、親となるDMを明示的に紐づける必要がある
＜↓、WPのIOモデリングイメージ＞
-
なお、「Web Performer WF」と 「Web Performer WF+」は帳票作成やワークフロー（申請・承認など）に関する有償のプラグインになので、今回は深入りはしません。
- 少しだけ触れておくと、「伝統的な日本企業」の共通的なお悩みにフォーカスを当てています。
- したがって、基本的な業務要望はもちろん、そこそこレアな業務要望にもソリューションを提供してくれているという印象でした。お値段もそんなに高くない印象です。
簡単に言うと、OSPとWPの違いは？
- サービスの提供スコープが違います。具体的には次の通りです。
| 提供サービス | WP | OSP | 備考 |
|---|---|---|---|
| コード自動生成GUIツール （ローコード開発ツールとしてのメイン部分） | ◯ | ◯ | OSPのコンポーネント：Service Studio |
| アプリ管理 | × | ◯ | OSPのコンポーネント：Service Center |
| CI/CD | ×（注1） | ○（注2） | OSPのコンポーネント：Platform ServerおよびLife Time |
- WPはあくまでもコードを生成する所までが仕事です。
- WPはアプリログやアクセスをモニタリングしたり、継続的に他のモジュールとの依存関係をチェックしてマージ・デプロイするには、別途仕組み自体を構築する必要があります。
- 一方、OSPは「Service Center」と「Life Time」というコンポーネントによって、「アプリ管理」と「CI/CD」の仕組みが準備されているのがポイントになります。まさに、「プラットフォーム」という感じですね。
-
もちろん、両者の「コード自動生成GUIツール」としての中身も違いが大きいですが、大局的に見ると「サービスの提供スコープの違い」に起因する差異が大きいと分析しています。
＊注１ 公式情報によると、WPは”*Webアプリケーションの生成先を「AWS Elastic Beanstalk」に指定することで、「AWS Elastic Beanstalk」上の本番環境への自動デプロイが可能*”とのことです。 ”CI/CDの構築が容易だ”ということだと思いますが、結局仕組みの構築および品質担保は利用者に委ねられているので、OSPと比べると「×」と評価しています。 ＊注2 「Platform Server」では環境内での依存関係チェック、マージ、ビルドなどを担当します。「Life Time」は環境間でのバージョン管理とデプロイ実行がメインです。 「自動リグレッションテスト→自動デプロイ」などのリッチなパイプラインをデフォルトで提供しているのではなく、そのレベルを求めるなら、別ツールとの連携や仕組み構築が必要になってきます。
アジャイル開発との親和性は？
- 次のように相対的な親和性（ ≒ 優位性）を整理することが可能だと思います。 ＊どちらが「良い」「悪い」という話でないです
| # | 評価軸 | WP | OSP | 評価要素 |
|---|---|---|---|---|
| 1 | ライセンス | ○ | × | コスト、複雑性/柔軟性 |
| 2 | 開発準備アジリティ | × | ○ | 開発周辺系、PaaS環境 |
| 3 | 開発/検証アジリティ | ○ | ◎ | 開発〜検証サイクル、共通パーツ実装、開発ツールとしてのUI |
| 4 | 技術基盤/継続性 | △ | ○ | 普及性、新機能/新技術の導入 |
1. ライセンス
-
コスト
- 開発規模・構築方法にもよりますが、基本的にOSPの方が高くなると思われます。
- OSP：定額のライセンス料＋システム規模による年間追加コスト（エンドユーザ数、Application Objectsと呼ばれる開発リソースなど）
- WP（SI開発ライセンス）：開発アカウント数に対して年間コストが発生（システム規模による金額のスケールアップはなし）
- 一方、上述した通り、OSPはサービス提供が内容のスコープが広いので、コストが高いのも当然と言う見方もできると思います。
- 開発規模・構築方法にもよりますが、基本的にOSPの方が高くなると思われます。
-
複雑性/柔軟性
- ライセンス形態自体もかなり違っており、OSPの方が難解です。また、外国企業なので突然のライセンス変更リスクも考えなければいけないという意見もあります。
- OSP：1企業に対してMaster Subscriptionが有るので、複数関連会社にまたがった時の調整が大変です。受託側のライセンスで構築しようとすると、委託先ごとの住み分けも難しいです。「Application Objects」という概念の理解も少し大変で癖があります。
- WP：基本的に開発アカウントに対する料金で馴染みやすいです。また、委託側・受託側でそれぞれ別のライセンス形態が準備されています。
- ライセンス形態自体もかなり違っており、OSPの方が難解です。また、外国企業なので突然のライセンス変更リスクも考えなければいけないという意見もあります。
2. 開発準備アジリティ
- 開発周辺系
- 上述の通り、OSPにはCI/CDとアプリ管理のサービスが提供されているため、開発に取り掛かるまでの準備が大幅に短縮されます。
- PaaS環境
- OSPには、同額のライセンスコストで「On-Premises型」か「PaaS型」が選択できます。
- 「PaaS型」は「On-Premises型」に比べてサーバコスト・構築工数などが削減できると言えるので、アジリティという点では優位と言っても良いと思います。
- 注意点として、「PaaS型」は自由にOSのバージョンアップができない（PaaSとして当然かもですが）、SQLサーバも直接操作できないなどの制約があり、伝統的な日本企業のセキュリティ基準や開発柔軟性で基準を満たせない可能性が高いです。
- OSPには、同額のライセンスコストで「On-Premises型」か「PaaS型」が選択できます。
3. 開発/検証アジリティ
- 開発〜検証サイクル
- 両者とも、「誰でも」「一定の品質を」「スピーディーに実装できる」という点で、「ローコード型 超高速開発ツール」としての基準を満たしており、「開発→検証→FB反映・・・→リリース」というサイクルが重要なアジャイル開発に向いているという認識です。
- 共通パーツ実装
- WPはOSPに比べて処理やパーツを共有したり、依存関係をチェックする機能が弱いです。
- 例えば、異なるプロジェクト間ではWP上で作成したビジネスプロセスを共有する機能はないとのことです。（もちろん、最終的にはJavaのコードができて参照できれば良いので、何もやりようがないわけではないです）
- OSPは、独自に依存関係のチェックや共有の仕組みが備わっています。
- 開発ツールとしてのUI
- OSPは名前解決・型解決やAI（バージョン11以降）によるサジェスションが強力なので、操作していて非常に楽です。また、よりビジュアル性が高くシンプルです（ここは本当に主観です）。
- WPは、OSPに比べるサジェスション機能は弱いです。また、ツールの画面に設定項目・内容が細かく詰め込まれていて、慣れないと自分が何をしているのか迷子になることも多々ありました。。（色々な日本企業ユーザの要望を真摯に取り込んできた背景が伺えます）
4. 技術基盤/継続性
- 普及性
- OSPは世界のデファクトスタンダードを目指しているだけあって、世界中の大企業で導入実績があり、開発パートナーやコミュニティも充実しています。
- 導入国：52カ国、グローバルパートナー：245社以上、コミュニティメンバー：21万人
- また、トレーニングという点でも無料の個人用学習環境、動画、ドキュメントなどが充実しています。
- WPは日本市場における「伝統的な企業」をターゲットとしているため、OSPに比べると、世界的な普及度は劣後します。
- とはいってもキヤノンさんですから、すでに日本での実績は多く（2019.07時点で1,128社）、さらに付加価値を追求しています。
- また、開発パートナーを国外（フィリピンなど）に拡大するための取り組みも行なっているようです。
- 一方、有償の公式トレーニング以外の学習機会があまりないのが残念な所です。
- OSPは世界のデファクトスタンダードを目指しているだけあって、世界中の大企業で導入実績があり、開発パートナーやコミュニティも充実しています。
- 新機能/新技術の導入
- OSPは最新技術の導入に積極的で、定期的なメジャーバージョンアップをガンガン実施します。例えば最近だと次のような導入や取り組みが推進・検討されています。
- Reactを取り入れたUIフレームワークの刷新（「Reactive Web」）
- サジェスションを強化するためのAI導入
- ブランチングの強化（＊未導入・R＆D段階）
- WPは既存の日本企業の顧客からの上がってくる要望を拾い上げながら、不定期に順次改善するというスタンスです。ですので、OSPに比べると新しい仕組みの導入やUI刷新に積極的とは言えません。
- OSPは最新技術の導入に積極的で、定期的なメジャーバージョンアップをガンガン実施します。例えば最近だと次のような導入や取り組みが推進・検討されています。
最後に
- 繰り返しになりますが、WPとOSPのどちらが単純に「良い」「悪い」という話ではないと考えています。
- 両者とも「ローコード型 超高速開発ツール」という点では十分なサービスを提供しており、品質の良い製品だと認識しています。
- その上で、サービス内容やターゲットなどフォーカスしている点が違うので、違いをしっかり認識して選択・判断していかなければと考えます。