Wagby と kintone、salesforce の違い

さった4月20日に、第4回目となる超高速開発コミュニティの記念講演会&総会が終了しました。今回の記念講演は「超高速開発」という言葉を初めて世に出した、現ITPro/日経コンピュータ 副編集長の井上 英明 様に「超高速開発のこれまでとこれから」という演題で、示唆に富むお話をいただきました。改めて私たちがこのIT業界の中で関わっていくべき課題は「人月、ウォーターフォール、多重下請け構造」であり、さらに「IT人材不足と、市場縮小」という二つの時流を味方につけることができるか、が問われていると確認することができました。ご講演ありがとうございました。

f:id:ynie:20170424082330j:plain

その講演の中で、井上様から「超高速開発と呼ばれるツールがますます増える一方で、kintone のようなクラウドベースの高速開発ツールも登場している。」というご指摘をいただきました。そのとき私は「超高速開発ツールが目指す市場は基幹系であり、kintone などのクラウド開発環境ではすべてをカバーできない。」というコメントをしました。懇親会でこの点についていくつか質問を受けたので、改めて私の考えを整理して書きます。

以下、ご注意ください:

今回はクラウドベースの開発ツールとして kintone と salesforce を取り上げましたが、他にも多くのツールがあります。ここで記述したことはすべての製品に当てはまることではありません。

同様に、超高速開発コミュニティに参加しているツールも、多種多様です。ここは私のブログなので Wagby と比較していますが、ツールによって主張が異なりますので、こちらもお含みおきください。

基幹系で重要な「主キー設計」と「トランザクション処理」の比較

一つ目は「主キーは、複合キーをサポートすること」です。サロゲートキー(もしくはID)を導入して単一主キーのみのテーブル定義で統一することは、基幹系をサポートできない、というのが私の立場です。主キー設計はデータモデリングの一丁目一番地であり、業務要件から主キーを複合キーとして表現することは当然ありえます。さらに既存システム連携を考慮すると、複合キーをサポートしない基盤では、そのギャップを埋めるだけの余分な工数は、のちのちの保守を困難にします。いわば設計の負債として、その後の「お金と時間」を余分に使うことになります。

なお、サロゲートキーがダメなのではなく、サロゲートキーしか使えない基盤ではダメ、ということです。両方使えないと基幹系の基盤としては不十分と考えています。その判断は開発者に委ねられるべきです。基幹系では、開発者は実装容易性ではなく、あくまでも業務要件を優先して設計することでしょう。

そしてもう一つは、トランザクション処理です。クラウドを前提とした運用環境では、トランザクションにさまざまな制約が課されます。システム全体を利用者で共有しているため、特定の負荷をかけないように配慮してほしいという運営側の気持ちはわかります。とはいえユーザがこれらの制約を許容できるかどうかは別問題です。

加えて、トランザクションにかかわる排他制御をとりあげてみます。kintoneもsalesforceも、排他制御は楽観ロックを利用するとなっていますが、Wagbyは悲観ロックと楽観ロックを選択できます。開発者は(実装の容易性から)楽観ロック派が多いようですが、業務運用の観点からは悲観ロックの方が利用者にとっては望ましい場合が多い、というのが私の意見です。ここでもどちらがよい、という議論ではなく、両方使える、ということが基幹系の基盤としては大切である、と考えています。

トランザクション処理コードの開発生産性にも触れておきます。例えばkintoneでのトランザクション管理は、REST API 呼び出しからバッチ処理更新までを開発者が(ブラウザで動作する)JavaScript で実装することとなっていますが、ちょっとした処理でも長大なコードを書く必要があります。基幹系では多くのテーブルが対象となり、かつ、テーブルの項目も非常に多いという特徴がありますので、大変です。同じことを Wagby では(サーバで動作する)JavaScript で実装することができ、そのコードは数行で済みます。大規模システムになるほどその差は累積され、全体の開発生産性に大きく影響します。

今回はこの二点に注目して比較してみましたが、いずれも基幹系の場合は「開発者の自由度を高められるように、選択の幅を広くしておくことが開発・運用環境では重要」という意見を述べました。単一主キーのみ、かつ、楽観ロックのみ、という環境で基幹系をサポートすることは無理があるというのが私の立ち位置です。

超高速開発とクラウドは、ごっちゃにしてはいけない

今回、クラウドとして著名な kintone や salesforce をとりあげましたが、これは PaaS というカテゴリに属する製品です。クラウドというのはもっと幅が広い言葉です。例えば、開発環境はローカルでも、完成したアプリケーションはクラウド環境で動作するというものもあります。この場合は主キー設計やトランザクション処理コードはほぼ、従来通りの設計思想が利用できます。Wagbyのアプローチはこちらになります。さらに Pivotal が提供する CloudFoundry のような PaaS 環境は、Wagby のアプローチを支援できる基盤を理想的な形で提供します。一口に PaaS といっても、このような違いもあります。

現場で営業していると、少なくない方が「クラウドでつくる時代において、超高速開発ツールは存在理由がない。」と誤解していることに驚きます。クラウドと超高速開発ツールはそもそも同列で比較するものではなく、組み合わせて利用するものです。クラウド、イコール、万能な環境ではありません。どのような環境(プラットフォーム)にも設計思想があり、それを支えるアーキテクチャが存在します。すべての要求を満たすアーキテクチャというのが存在しない以上、目的によって選択は異なるのが当然です。

なお、このような PaaS を基幹系以外で活用する場面はたくさんあります。CRMやSFA、グループウェアなどの利用であれば、先の主張はあまり重要ではないかも知れません。しかし基幹系は違います。これをごっちゃにして「クラウドであれば何でもOKで、クラウドでなければすべてNG」という営業トークで語られてしまうと、結果としてユーザにも開発者にも不利益をもたらすと懸念しています。

5年目に入る超高速開発コミュニティですが、改めて初心を忘れず、私たちが目指す市場へ、説得力のあるプレゼンテーションを行う必要があると考えています。

ありがたいことに、きたる5月12日に「ソフトウェア&アプリ開発展 特別講演」で登壇する機会を頂戴しましたので、このあたりも含め、丁寧にお話したいと思います。