私はローコードに懐疑的です

• ローコード（low-code）に対して懐疑的な立場である
• ソフトウェアコンサルティングをする中で、ローコードの迅速な開発時間と低い保守コストを約束する広告に引かれたクライアントによく出会う
• クライアントが満足できない理由はいくつか存在する

カスタム機能の限界

• ローコードソリューションは企業要件の約80%を満たすが、残り20%は基本機能では解決できない
• ローコードツールのマーケターは残りの20%も簡単に解決できると主張するが、実際にはかなりのカスタマイズが必要で、ときには不可能な場合もある
• 企業は、ツールの基本機能が十分近いかどうか、あるいはツールをハックして正確なユースケースに合わせようとするかを選ばなければならない

開発者プールの制約

• 企業はときにローコードツールをハックして要件を100%満たそうと試みる
• その結果、特定ツールや独自言語で大量のカスタムコードを書くことになり、それを理解できる開発者はごく少ない
• その会社は、広く使われているオープンソース言語の開発者プールから採用する代わりに、このツールに高度に特化した保守担当者を探さなければならなくなる

プラットフォームアップグレードの問題

• ソフトウェアをアップグレードする際に、連携しているものを壊さないようにするのは難しい
• ローコードツールは、本来想定されていないユースケースのために任意のコードを処理しなければならない
• 厳格なAPI契約によってそれを実現できるはずだが、実際にはカスタムコードが内部でさまざまないたずらをしているのをよく目にする

データベース構造の混乱

• 精密な分析が不可欠なプロセスにローコードツールを使っている企業を見かける
• しかし基盤となるデータモデルを見てみると、何が何だか分からない状態である: user_attribute_47 は何を意味するのか？ アプリケーションの1ページ目から2ページ目へフィールドを移動すると、データは別のフィールドに入っているのか？

GN⁺の見解

• ローコードは開発速度を高め、保守コストを下げられる有望なツールだが、実運用では予期しない問題が発生することがある。
• 特にカスタム機能が必要な場合や、特定のローコードツールに依存する開発言語を使う場合は、開発者プールが狭まり、保守が難しくなる。
• ローコードツールのアップグレードとデータベース構造の複雑さは、長期的なプロジェクト管理における重要な検討事項である。
• この記事は、ローコードツールを使う際に注意すべき点を指摘し、適切なユースケースを慎重に評価することを勧めることで、興味深い示唆を与えている。

[ats62]

これまでのノーコードという概念は、特定の分野で限定的に適用されるものだと考えています。

Llmを活用したよくできたサービスが登場すれば、ノーコードのトレンド？ 流れ？ 趨勢？ とにかく、その概念がまず変化するのではないかと思います。

[quack337]

10年ほど前、MS Accessが有効に活用された事例を知っています。

組織の情報システムには、比較的よく設計されてMS Sql Server上に実装されたデータベースがあり、
日常的なOLTP業務もやはり比較的よく実装されていました。

ところが、日常的ではないデータ照会やレポート出力の要求に対するIT部門の遅く消極的な対応に、不満が積み重なっていました。

MS ExcelとAccessを使いこなせる業務部門の社員が、情報システムからダウンロードしたExcelデータをAccessにimportし、必要なデータ照会およびレポート出力機能を、コーディングなしでわずか数時間でAccessで実装できることを示しました.

[quack337]

業務部門は、Access から DB に直接接続できるようにしてほしいと要望し、IT部門は情報システムの DB を外部ネットワークに公開することに反対していました。ですが、業務部門の要求が強かったため、一部のデータだけをミラーリングした別の DB を作成して公開しました。

Excel のデータ機能をうまく扱える社員たちは、数日間の教育だけで Access を業務に活用し始めました。

[tequila]

この記事には共感します。個人的な考えですが、
特殊な文法を使う場合 -> 学習コストが必要になり、保守が難しくなる
UIでコードを単純に置き換える場合 -> 普通にコーディングしたほうが楽なことが多い
完全なノーコードツールになる場合 -> 制約が多く、ユーザーによるハックが誘発される。意図しない動作をするユーザーの頻度が大きく増える
結果: 誰も満足できないツールになります。
企画・開発・ユーザーのギャップがあまりにも大きく、思った以上にうまく作るのが難しい分野のように思います。

[GN⁺]

Hacker Newsの意見

• ローコードに関するさまざまな視点

  • ローコードプラットフォーム開発者の視点

    ローコードは売りやすい。IT部門を問題の元凶のように見せ、既存の不満を利用する戦略が使われる。デモでは簡単な作業を素早く見せる。しかし中核となるビジネスロジックはローコードに含めないほうがよい。複雑な作業は専門システムにオフロードすることが前提となる。大企業で、技術的な知識はあるがIT上の権限が少ないチームには有用だ。ローコードは簡単なツールで多くの問題を解決するが、拡張性に乏しく、強力な中央システムと連携する必要がある。

  • SRE（サイト信頼性エンジニア）の視点

    ローコードには懐疑的。ソースコード管理が不十分で、ドキュメントも整っていない。多くのカスタムコードが必要になるが再利用性は低い。独自ランタイムが必要で、監視も難しい。実際にエンジニアが作業し、非エンジニアが使うというケースは見たことがない。Looker のようなツールはソースコード統合が可能だが、それでもなおエンジニアが使っている。複雑さを圧縮する点は認めるが、必要に応じてカスタマイズや拡張が可能なプラットフォームのほうを好む。

  • Microsoftのローコードプラットフォームに対する見方

    MSのローコードプラットフォームに関心はあったが、O365 と Azure の上に複雑に構築されているように見える。ユーザーインターフェースは貧弱で、長期的にはコスト削減よりも使い勝手の悪さによる損失のほうが大きくなりかねない。

  • MS-Accessのデータベース/フォームソリューションを移行したビジネス経験

    非開発者やエンドユーザーがIT部門を通さずに作った MS-Access ソリューションを、本格的な .net クライアント/サーバーアプリケーションへ移行するビジネスを構築した。ローコードソリューションは一部の問題を解決したり、POC を動かしたりするには有用だが、スケールや適応が必要になったときに問題が生じることがある。

  • SQLPage Webサイトビルダー開発者の視点

    ローコードソリューションには、外部の「ハイコード」API とやり取りできる逃げ道があるべきだ。SQLPage では sqlpage.exec を通じてそれを提供している。ローコードプラットフォームのアップグレードによって、カスタム実装が壊れる可能性があるという問題もある。ほとんどのローコードツールはデータを人質に取るが、SQLPage はユーザーが依然として完全に制御できるデータベースの上にレイヤーを追加する。

  • エンタープライズ向けローコードツールへの反対意見

    大企業で使われるローコードツールには反対だ。大企業であれば、適切な開発チーム、計画、組織を維持できるはずだ。コストを発生させるのはコードそのものではなく、悪い開発者が悪いツールを使って悪い意思決定をすることだ。

  • ローコードと抽象化レイヤーに関する見方

    「ローコード」は直接インターフェースできるコードの表面積が小さいだけで、実際には多くのコードが隠れている。抽象化レイヤーは目的にうまく適合しているときには強力だが、漏れがあったり不適合だったりすると問題を引き起こすことがある。一般にローコードは特定用途向けのコードを抽象化するが、実際には特定ドメインの経験が必要になる。

  • Bubble/Airtable を使って MVP を構築した経験

    ウクライナのチームから MVP 構築の見積もりを取ったが、インターンを雇って Bubble/Airtable を使い、2か月で製品を作り、6か月以内に有料顧客を獲得した。ほぼ2年間、従来のスタックへ移行する理由は見つからなかった。

  • ローコード学習コース開発のホラーストーリー

    ある重要な企業が、ローコードの学習コース作成ソフトウェアパッケージを使って、マーケティングおよび営業担当者向けの社内学習コースを開発した。数年後にコースの更新が必要になったが、開発に使われたソフトウェアも、その作業を行えるツールもなく、問題が発生した。

  • ローコード実装のバージョン管理可能性に関する疑問

    ローコード実装をバージョン管理に入れられるのか、問題が発生したときに原因を追跡できるのか、無料ツールを使って特定のコミットにロールバックできるのか、という疑問がある。ほとんどの場合こうした機能がなく、深刻な用途には適していない。