ローコードツールのプロダクト開発

様々な業界や業種でデジタルトランスフォーメーション（DX）が進む中、企業は外注に頼らず、「ノーコード」や「ローコード」を活用した開発を取り入れるようになっています。本記事では「ノーコード」や「ローコード」による開発を支えるプラットフォームの開発について、従来のSaaSなどの一般的なソフトウェア開発と比較しながら、その違いを浮き彫りにしていきます。

ローコードとノーコードの違い

まず、ローコードとノーコードを支えるプラットフォームは、アプリケーションの開発を簡素化するためのものです。それぞれの違いを以下に示します。

ノーコード

• 概要: コーディングスキルを持たないユーザーでもアプリケーションを開発できるプラットフォーム
• 対象: 主にビジネスサイドを中心にしたユーザー
• 特徴: コードを使用したカスタマイズが困難で、プリビルトコンポーネントとテンプレートに依存
• 代表例: Airtable、Zapier

ローコード

• 概要: アプリケーションの開発を簡素化するためのプラットフォームで、最小限のコーディングを必要とする
• 対象: 主に開発者やITプロフェッショナルで、ある程度のコーディングスキルを持った方が対象
• 特徴: コードを追加してカスタマイズすることが可能で、各種テンプレートの活用もできる

• 代表例: Microsoft PowerApps、Outsystems、Mendix

  さらに、ローコードには大きく2つの種類があり、個別のアプリケーション全体を設計できるものと、とあるアプリケーションに対して、GUIで一部のモジュールを設計できるものの2つに分類できます。ここからはローコードに重きを置いて、ローコードとSaaSを比較しながら、ローコード自体の開発のあり方を浮き彫りにしていきます。

ローコード自体の開発における企画思想

ローコードとはユーザーがコードの知識がほとんどなくてもアプリケーション開発ができるプラットフォームを指します。つまり、決まったユースケースや業務フローに対応できるシステムを構築するだけでなく、柔軟にユースケースに対応できることが必要になります。

他方、SaaSは一定の業界業種における業務フローの一部を完遂できるシステムであり、ローコードに比べ、柔軟性は求められていないと言えるでしょう。また、上記柔軟性の有無により、ローコードはプロダクトマネージャーや開発者、情報システム部門の方々などが活用することが多く、SaaSは具体的な業務担当者による活用が想定されています。

ローコード自体の開発において、特徴的なのはユースケースに対する柔軟性であり、システムとして拡張性の高さを担保することにあります。例えば、Salesforceではプロンプトビルダーを活用することで、Salesforce上のデータを元に顧客に特化した営業メールを生成できることができます。営業だけでなく、マーケティングなど他のユースケースにも対応できるような柔軟性をプロンプトを活用することで担保していると言えるでしょう。

気をつけないといけないポイントは様々なユースケースに対応できるように柔軟性を上げるべく、プロダクトとしての抽象度を上げすぎると、ローコードとしての意図や対応できるユースケースの想起が難しくなり、導入や活用が困難になります。対応すべきユースケースをある程度絞り、最低限の要件を定義しつつ、今後他のユーザーセメントやユースケースへの展開を念頭に置いた上で最終的な開発要件を決めていくことになります。

ローコード自体の企画の進め方

先にSaaSの企画の進め方を確認すると、ターゲットセグメントに当たる想定ユーザーにヒアリングし、業務フローを確認するところから始めます。その後、業務フローを元に、どこに課題があるか見極め、プロダクトのアイデアを検討していきます。そして、ユーザーストーリーを洗い出し、優先順位を受けて、プロトタイピングを行っていきます。さらに、プロトタイプを想定ユーザーに見せ、課題を解決し、ユーザー価値を創出するものになっているか確認し、問題なければ、実際の開発に駒を進めていきます。

ローコード自体の企画は上記のSaaSの企画の進め方と大きく変わるところはありません。幅広いユースケースに対応できるローコードですが、企画段階では一定の業界業種、ユースケースに絞り、業務フローの確認から、プロトタイピングまで進めていきます。

1点、SaaSの企画に追加して行うこととして、幅広いユースケースに対応できるように、企画段階で、アーキテクトに相談をしっかりと行い、プロダクトとしての拡張性を確認します。

また、一度SaaSとして開発を進め、より広いユースケースに対応できるように、一部ローコードによるカスタイマイズを許容できるように機能拡張を進めることもあります。当初SaaSとして展開していたが、エンタープライズを意識したときに、1ユーザーごとにカスタマイズして、SIをこなしていると、スケールが難しいので、この文脈でローコードを導入するという考え方もあります。

単にSaaSのデモだけで販売し切るのが難しいケースでも、ローコードを通して実現できることを併せて提案することで、売りやすくなることがあるのです。

ローコード自体の企画の困難さ

上述の通り、SaaSの企画と基本的には同じ進め方をするのですが、3点ほど企画を困難にするポイントがあります。1点目はプロダクトの拡張性を担保するために一歩深い基盤レイヤーの企画をアーキテクトと議論しながら進めるため、その分企画の難易度があがります。

SaaS業界でトレンドになっているコンパウンドという創業時から複数プロダクトを展開していく戦略を実現する過程と似ていると言えるでしょう。コンパウンド戦略でもデータや認証、課金などを共通基盤として構築し、複数プロダクトで活用できるように開発を進めていきます。コンパウンドの開発と違うのは、社外のユースケースに対応することであり、さらに難易度の高いものと言えます。

2点目はユーザーからの要望が上がってきた時にローコードとして実現するものと捉えるべきか、ユーザーが開発することで実現するものと捉えるべきかの線引を行うことです。もちろん目の前のユーザーから上がってきた要望をプロダクトとして実現できれば、ユーザー価値は向上しますし、それだけ高いARPAを期待できます。しかし、ローコードという性質上、ユースケースが限定的であれば、その趣旨に反します。

このバランスを取りながら、プロダクトの改修を行っていくのは一段難易度が上がる要素といえます。

最後に、2点目にも通じるのですが、様々なユーザーから多種多様な要望が上がってきます。そのため、なかなか直接は比較しにくい企画の優先順位をつけ続けなければなりません。ただ、優先順位をつけるだけではなく、その結果をプロダクトサイドはもちろん、ビジネスサイドにも連携していくことになります。

まとめ

初めてローコード自体の企画を進めようとすると、どこから手をつけてよいものかと戸惑うことも多いかもしれません。しかし、本記事で確認した通り、基本的な流れはSaaSと同じく、スコープを決めて、ユーザーニーズを明確化していくことから始まります。

ただし、様々なユーザに使ってもらえるように拡張性を担保するためにアーキテクトとの企画検討や、どこまでプロダクトとして実現するのか、また開発の優先順付とコミュニケーションにローコードならではの難しさをはらんでいると言えます。

これらを丁寧に対応していくことで、ローコードの企画が進み、より広いユースケースの対応や、さらにはエンタープライズ開拓の一手となれば幸いです。