NoCodeを採用しない方が良い3つの理由

NoCodeを用いるとコードを書かずにサービスを構築することができます。筆者はNoCodeを用いた大規模なシステムの拡張開発を行なった経験があるので、所感をここに残しておきます。

 

本記事では、NoCodeを採用しシステム構築する前に考慮すべきポイントと、NoCodeを採用しない方が良い理由について解説します。

 

TL;DR

今は2023年です。CopilotやCode Whisperなどがあるのでコード書ける人はコード書きましょう。ビジネスサイドの方が突貫で間に合わせて、後々replaceする前提で使うのはアリだと思います。大きい問題点は本番環境しか作られない場合が多いという点です。

 

本番環境のみになりがち

NoCodeでシステム構築を行うというのは、全てSaaS上で開発を行うという事です。これは個人のlocal環境は存在しないという事です。で、ギリギリ作ることが可能なのはstaging環境なのですが、実はNoCodeである程度のシステムを作るとお金がかかります。productionと同じ環境を維持するのは単純に二倍の費用がかかるため、production一本でサービスを動かすことが多いと思われます。(50万->100万だとstaging要る?って気になりませんか?)

 

また、stagingを作ったとしても、うまく行ったのでデプロイ...ではなく同じ作業をブラウザ上でポチポチもう一度する必要があります。二つの環境の差異を無くすのは至難の技でしょう。

 

よって、私の関わったシステムは本番環境しかありませんでした。これで何が起こるかというと、新機能を追加するためにIntegromatを触ると、AirTableのデータが壊れて徹夜でデータ復旧、みたいな事になります。本番で動いている、昨日も今日も明日も莫大なお金を作るシステムの追加開発は本番環境のみであるのはリスクであることは明白ではないでしょうか。

 

(また似た問題として、コードを書く際もawsのlambdaやAppSync, DynamoDB等もlocalで動かさずに進める事もあると思いますが、Bad Patternだと思っています。LocalStackなどの開発への導入を検討しましょう)

 

複数人での開発が非常にしづらい

上記の問題点より、複数の(完全に同じ)環境を持つことは非常に困難です。

この際にシステムの近い部分の編集を行う際にはどうすれば良いのでしょうか?gitならコンフリクトを自動で差分を見て管理してくれます。これを人力でやる必要があります。

実際には一人である程度の範囲を完全に任せる方針になるでしょう。

 

乱雑にいらないものが残る

AWSでもよくありますよね。いらないものが残ったままになる現象。あれなんで残ったままになりやすいのか本当に不思議です。NoCodeではもう少し酷い感じになります。

なぜなら開発をするたびにproductionのAirTableの別のcolumnに列を追加して、そこにformulaを書いて、integromatに流して...のように既存のものに影響しないように作業を行います。そしてそれが何に影響しているのか、知るのはただ一人です。このfoo2というcolumnを消して良いのか、productionを壊して今日一日の業務オペレーションを止めないか、わかりません。localで動かして、とかできたらまだマシなんですけどね。

 

他にももっと

- AirTableデータ量が多すぎるとそもそも閲覧がかなり重い

- コードで言うコメントのような機能があったりなかったりしてドキュメント整備されないがち

- dirty hackを行う場面が非常に多い。(全然自由じゃないので)

- サ終されたら普通に業務が止まる(やりたいことの実現のための選択肢が個人的にやってる小さいサービスしかない場合も多い。例えば何かをpdfにしたりとか)

- ブラウザをポチポチするのが苦痛。vimが使えないエディタですら不自由なのにマウス一つで全てを操作するのは自分には無理だった(エンジニアが離れるかも)

- チームから動かなくなったと報告されると大体実行単位使い切ってたりする(これはGitHub Actionsとかもそうだけど)

 

等々ありますが、この辺で。

 

まとめ(それでも採用して良い時)

今は2023年でgithub Copilotという素晴らしすぎるツールがあります。範囲選択してFix bug buttonを押すとバグが治る時代に、わざわざNoCodeを使うメリットはほぼ皆無だと思います。

所感として、NoCodeを触っていると、IaCの逆を行くような気持ちになります。コード化されてないものをコード化しましょうという取り組みの逆です。色々なコード支援が失われるのはエンジニアとしても非常に辛いものでしょう。

TL;DRにも書きましたが、ビジネスサイドの方が突貫で使うようなサービスに今後はなっていくと考えています。