![見出し画像](https://assets.st-note.com/production/uploads/images/33823950/rectangle_large_type_2_d5c11066f84adbe2304de48afdede5a5.png?width=1200)
ノーコードツールのリスク管理
ノーコードツールはオンラインサービスであるが故にツールへの依存度が高く、それによる恩恵と同時に多大な「リスク」が存在します。
本記事ではノーコードで作成されたアプリケーションのリスク管理を行い、できるかぎり安定的な運営をするためにどうすれば良いのか2つの具体的な対策について紹介します
なぜこの記事を書こうと思ったのか
9/2 AM 1:20 ごろbubble.ioにて以下の症状が起きました
は????
— たかし@コードの書けないエンジニア (@NoCoderT) September 1, 2020
やばすぎ pic.twitter.com/5agTFLh84b
真っ白です。bubbleで長い時間をかけて作ってきたアプリケーションが全て水の泡になりました。
圧倒的、絶望感...
Bubble 現在インシデント発生中みたいですhttps://t.co/6zdju3CvX9
— tsubasa@NoCodeCamp DMM初のノーコードサロン運営中 Adalo好き (@tsubasatwi) September 1, 2020
tsubasaさんによるとbubbleからレポートが出されていたようで、原因はバグ。データベースのメモリを使い果たしてしまい、データベースがクラッシュしたとのことです。
アプリが全て消えた瞬間、NoCodeCampで毎日開催されている深夜のbubble会「よーこの深夜サロン」に乱入させて頂きみなさんに相談しました
#NoCodeCamp の #深夜のBubble会 もとい #よーこの深夜サロン 特設ページが出来ました😆🎉✨
— よーこふ (@yokof_88) August 14, 2020
👇👇👇https://t.co/IfHjP5WSqs#Bubble #Adalo #Glide などなどの #ノーコード ツールのお話はもちろん、マーケ・マネタイズ・人生相談まで、なんでもどうぞ🌛‼️@nocodejp @tsubasatwi も9割在廊😆🎊✨
bubbleを使っている方々(通称bubbler)のみなさん同様の症状になっていることを確認しました。サロンの管理人のtsubasaさんに聞いたところ「サーバーをツールに依存しているため現状何もできない。このような障害を予め考慮した上で設計する必要がある」とのこと。
最終的には20分後にサーバーが復帰して何も問題はありませんでした。
が、今回の事件から無限に作って楽しいだけのbubbleではない、といことが明らかになりました。またこれはbubbleに限らず全てのノーコードツールにおいて当てはまるものです。
では具体的にどのような対策があるのか考察していきます
1.データベースのリスク管理〜バックアップ〜
今回のようなバグがいつどのように発生するか、ツールを提供している会社がいつサービスを停止するか分かりません。サーバーの依存度が100%である以上、ノーコードツールの停止=作成したアプリの停止という状況になる可能性が高いです。
依存度100%という脆弱性から考えるとバックアップを取ることは必須なのではないかと考えます。「1つのデータベースがクラッシュする可能性」と「2つのデータベースが同時にクラッシュする可能性」を比べると、圧倒的に後者の可能性は低いです。メインのデータベースがクラッシュした際に予備のデータベースでカバーするという方針を取ることでアプリユーザーのデータを高確率で保持することができます。
具体的にbubble.ioで考えるとbubbleアプリにおいてデータを追加する際にAirtableにも同時に書き込むようなワークフローを挟むというものです。ただ、全てのデータのバックアップを取って冗長にするよりも、重要なデータのみバックアップを取るという方針が良いと考えます。
Airtableに限らずGoogleドライブなど様々なクラウドに保存して良いと思います。オフラインのHDなどに保存するのもありです。
2.ツール依存度のリスク管理 〜「β版運用」という方針〜
アプリが成長するに従ってツール依存度が100%という状況のリスクはどんどん高くなります。いずれノーコードツールから脱却するという方針は全然アリだと思います。
しかし個人が作成するような生まれたてのアプリケーションは普通すぐにはマネタイズできません。お金が回収できるのか分からないのにエンジニアを雇い、信頼性の高いサーバーを契約し、正式なアプリをローンチするのはまたそれも資金面において"リスク"です。
あくまでもノーコードツールで作成されたアプリはβ版とし、正式版アプリをローンチする余剰資金が生まれるまでの"繋ぎ"とする方針です。β版のアプリから生まれた収益を正式版に引き継ぐことによって、資金面でのリスクを最小限に抑えられます。同時にツール依存度の高さからサービス停止に陥るリスクも最小限に抑えられると考えます。
3.サービス停止のリスク管理〜買収〜
これはパンピー(一般人)には不可能ですがノーコードツール会社ごと買い取ってしまうことで、どれだけツール会社の収益が悪化しても自分のサービスは維持できるというものです。これができる資金力があるなら個別のアプリごとにイエスコードで正式版を維持すれば良い話なのであくまでも机上の空論ですね。
4.ユーザーへの連絡〜告知手段を持つ〜
追記です。ツイッターへ投稿したところリプライを下さいました。
この辺はAws/GCPなどにべったりなYesコードでも同じですね。一時的な障害はお祭りだと思って、アプリ外でのユーザへの告知手段とかを持っておくとかが良いと思います。
— tomoyuki@スマホ1つでノーコードで公式アプリ作成 (@sarukun99) September 2, 2020
確かにイエスコードでも障害やメンテは発生します。アプリ外に告知手段をもち、ユーザーに状況を報告できるようにする必要がありますね。今回bubbleもレポートを出しており、データベースのクラッシュが起きたということをbubbleユーザーに知らせることができました。
全体告知できるTwitterアカウントを持っておくとか、LPはStudioにして、アナウンスできるとかですかね
— tomoyuki@スマホ1つでノーコードで公式アプリ作成 (@sarukun99) September 2, 2020
手っ取り早いのは公式ツイッターを開設しておくことですかね
終わりに
何があるか分からないからとりあえずバックアップを取ろうねという1番目の事項は強調しておきます。まじで大事だと思いました。bubbleでアプリが消え去った時、自分は無力でした。結果的には何もなく無事にアプリが復帰しましたが、消えててもおかしくありませんでした。
ここまで読んで頂いてありがとうございました
Twitterやってるのでフォローお願いします