はじまり
今回は、現在のお仕事で使っている「OutSystems」というツールに関して、記事を書いてみようと思います。
OutSystemsってなに？
「OutSystems」というのは、最近巷で流行っているローコードツールです。
公式サイトはこれです。
歴史としては、OutSystems社が2001年に設立されたそうです。
そして、日本国内で言うと、「株式会社BluMeme」というところが2012年に国内初導入を行ったそうです。それから、BlueMemeが国内でのOutSystemsのベンダー最大手としての地位を確立しています。
OutSystemsのサポートデスクのサービスも、BlueMemeは提供しています。
OutSystems導入のメリット
まず、OutSystemsの導入のメリットを挙げていきます。
その1：UIパーツが既に出来ているので、目標物に近いものをすぐに試作できる。
OutSystemsで開発すると、既にあるOutSystems標準パーツを使えば、あまり工数を掛けずに目標のUIデザインに近いモックアップを作ることが出来ます。
なので、要件定義や基本設計とかの段階からUI、UXの協議を深いレベルで行うことが出来ます。
そうすることで、以下のメリットが生まれます。
- 要件定義、設計に掛かる工数の削減
- パーツ作りの工数の削減
- 納期までの期間の短縮
その2：試作品を作って確認をするプロセスを、アジャイル形式で開発できる。
先程、UIパーツが既に出来合いのものがあると述べました。
そのため、一発勝負のウォーターフォール開発ではなく、プログラムを作っては確認、また作っては確認、をするアジャイル開発が容易になります。
そのため、以下のメリットが生まれます。
- 要件定義漏れのキャッチアップが早い段階で可能
- 要件変更のプログラムへの反映が早くなる
- 一気にプログラムをリリースするわけではなくなるため、バグのスコープが狭まり、バグの特定が容易になる
OutSystemsの惜しいところ
では、実際に惜しいところを挙げていきます。
その1：テストコードが書けない
OutSystemsでは、先程挙げた標準モジュールやForgeと呼ばれる部品を使って、開発を行っていきますが、そのパーツ間ではもちろん変数などのやり取りが発生します。
そのため、OutSystemsで完成したシステムはもちろんプログラムというものが出来るわけです。
そして、プログラムを作ったからには・・・、もちろんテストを行わなければなりません。画面にちゃんと意図した処理が実装されているか、UIが崩れていないかなど・・・。
しかし、OutSystemsで実装した処理のテストは自動化出来ません。
と言うと、些か語弊はあるのですが、Seleniumなどを使ったE2Eテストは別途組めば出来るのですが、クライアントで値を表示するまでの内部処理のテストを自動化出来ないのです。
なので、OutSystems内では画面の描画以外の処理（DBからSelectしたり、値を加工したり、）はあまり実装しないほうが良いのかと思います。これは、アーキテクトの設計の仕方にも依ると思います。
その2：diffツールが過敏である
OutSystemsでは、修正する際にモジュールからcloneして修正でき、その修正したところとclone直後のdiffが出来ます。
出来る点は素晴らしいのですが、修正した際に編集するUIで少しでもアクションなどを動かしてしまうと、動かした部分でdiffが発生してしまいます。
実際に、僕が体験した話としては、diffした際にあまりにもdiff部分が多すぎて、diffしそびれている箇所が分からなくなり、cloneからマージされていなかったことがありました。
その3：あまりに大量のデータはエンティティに入らない
これはOutSystemsの問題なのかSQL Serverの問題なのか微妙なところではありますが・・・。
この「エンティティ」というのは、OutSystemsで作った画面が裏で持っているデータベース的なモジュールなのですが、このデータベースに利用されているのが、Microsoft SQL Serverです。
このMicrosoft SQL Serverなのですが、実は1つのレコードあたり、8060byte以上のデータを保持することが出来ないのです。（カラムの定義上のbyte数ではなく実質のbyte数ですが。）
システムとして既に150byteは占有されているそうなので、実質使用できるbyte数は7910byteになります。
なので、大量の項目を保持するのが目的であるシステムを作るのであれば、この7910byte制限に抵触しそうかどうかを確認する必要があります。
byteの数え方としては、どうやら、全角が2byte、半角が1byteで計算するようです。以下の記事で詳しく掲載されていました。（DATALENGTHに関してはこちら）
まあ、全角で20文字打てる項目を400個弱利用できるので、基幹システムとかじゃなければ、それで不十分になることはあまり無いと思いますが・・・。
その4：簡単ではあるが、それ故に未熟なコードが出来る可能性が上がる
世間一般的に、ノーコード/ローコードツールは、「プログラミングのスキル/知識がなくても開発できる！」が謳い文句のようです・・・。
この記事にも載っているのですが、このNTTデータ研究所という最大手のITベンダーがそう言っているので、その考え方が共通見解となっていますね・・・。
出典：NTTデータ経営研究所
しかしながら、ノーコード/ローコードツールは、あくまでプログラム開発を「補助」するツールであるものです。決して、プログラミングのスキル/知識がなくても開発ができるという代物ではありません。
開発生産性は確かに上がるかもしれませんが、プログラミングのスキル/知識は必要です。
僕が実際に体験した具体例があります。
まず前提として、このOutSystemsでは、クライアントアクションとサーバアクションと、クライアント側で行うアクションとサーバ側で行うアクションをそれぞれ定義できます。
そして、話に入りますと、とある画面のレスポンス速度が妙に遅いので、それを実際に見てみました。
すると、クライアントアクションとサーバーアクションを何回も何回も行ったり来たりしていて、その通信の時間分、遅くなっていたことが判明したのです。
もう一つあります。
とある画面で表示している項目をすべてCSV出力する処理があったのですが、その処理がメモリ不足で落ちてしまったのです。
その原因の一つが、クライアントアクションで不要な変数を大量に作っていたことでした。
結果的には、変数の量は半分に減らせて（確か、その問題の部分だけで500→250個くらいに減ったような。）、メモリ不足現象も解消しました。
以上、２つ挙げた具体例でも分かるように、製造するにあたってどのようにプログラミングすると、どういう不具合が起きてしまうのかが分かっていない方がプログラムを組んでしまうと、バグが大量に発生する危険性があるわけですね。
なので、先程の「ノーコード/ローコードツールは、プログラミングのスキル/知識がなくても開発できる！」の認識は、あまりにも的外れであり、開発者はプログラミングのスキル/知識を蓄えるべきなのです。
この認識の元、日本国内に性能が低いプログラムが以前より大量製造されるとなると、鳥肌モノですね・・・。
プログラムは、ツールが作るのではなく、人が作るもの・・・ということですね。
おしまい
以上が、今回の記事になります。
ローコードとプロコードは一長一短ということですね。（なんかプロコードっていう呼び方も引っ掛かるな・・・）
以上になります！
コメント