ROUTE06

Product

ローコードを活用した開発と運用

2024-8-20

宮田 善孝 / Yoshitaka Miyata

シェア

ローコード開発は少ないコーディングでアプリケーションを開発できる手法として注目を集めています。特に企業が迅速に市場ニーズに対応する必要がある現代において、その需要は高まっています。しかし、ローコードは本当に万能な解決策なのでしょうか?本記事ではローコードユーザーの類型を整理した上で、ローコードに導入に関する課題と対策の提案を行っていきます。

ユーザーの類型

まず、ローコードを導入するユーザーはローコードを導入する目的の解像度と開発ノウハウ、リソースの有無により分類することができます。

前者については文字通り、ローコードを導入して実現したいことが整理され、明確になっているユーザーと、そもそも目的が不明確で、ツールを入れること自体でなにかを実現しようとしているユーザーに分類できます。

後者の開発に関するノウハウ、リソースの有無により、導入可能性の幅が変わってきます。開発ノウハウやリソースを持っていない企業ですと、ノーコードを中心に検討が進みますし、逆に社内に抱えている企業であれば、ローコードだけでなく、内製での開発も含めた検討も進められます。

導入の目的が不明瞭導入の目的が明確
開発ノウハウなし目的が不明瞭の中、ノーコードに対する期待が強いノーコードに近いツールを活用し、目的を実現を模索する
開発ノウハウあり導入するオプションがローコードまで幅が広がるが、ツールの導入が目的化するローコード、更にはハイコードによる開発も交えて、実現に向かう

ローコード導入の前提における問題

システム導入はそれ自体が目的になることはありません。なんらかの目的が必要で、その実現のための手段となります。ただ、ローコードの場合はシステムとしての拡張性が高く、機能要件の確認を行うことよりも、ローコードに過度の期待を寄せてしまい、システムの導入自体が目的化してしまうことも少なくありません。

また目的は明確でローコードの導入を決めましたが、結局プロダクトマネージャーや開発者、情報システム部門の方々のリソース確保ができず、導入が進まず、そのまま放置されてしまうこともよくあります。SaaSなどのように、直接担当者導入支援を受け、活用し始めるわけではなく、ローコードを活用したシステム構築を行って初めて、最終的なエンドユーザーが活用できる環境が整うことになります。

この拡張性の高さから、実際にユーザー価値を実現するまでのフローが長く、導入自体は決めたものの、その後活用自体がなかなかされないまま放置されることがあるのです。

ローコード導入における課題

ローコード自体の制約条件として以下4つの問題が起きえます。

1つ目はローコードの導入に当たり、情報システム部門とビジネス部門の連携の難しさがあります。ローコードは導入主体である情報システム部門と、利用主体であるビジネス部門が異なり、ローコードを導入する上で、両者の連携は不可欠です。

導入へのコミットメントはビジネス部門が強く、ローコードへの理解は情報システム部門が長けていることが多いでしょう。そのため、スタンスやナレッジにギャップがあり、かなり丁寧にコミュニケーションを行い、導入の目的と実現することをお互い共有し合わない限り、ローコードを導入したが、結局使われないという自体になってしまいがちです。

2つ目は、ローコードの拡張性の高さから、どこまでローコードで実現できるのか一見わかりにくかったり、そもそも使い方がわからないケースがあります。このような問題に対して、「ローコード導入におけるオーナーシップ」の「ローコードの導入サポート」で記載した通り、ローコードの提供会社は発信量や質を上げ、サポートを行っています。単純なSaaSとは差分があるので、しっかりとサポートを活用して行くべきでしょう。

3つ目は当初の目的を元にローコードで実現しましたが、その後社内の業務フローや体制の変化などに伴い、拡張が必要になるケースの方が一般的です。このような状況下において改修がローコードが提供している機能に制限されることがあります。現状のニーズだけでなく、今後起こりうる機能拡張も踏まえて、ローコードの選定を行っていく必要があります。

4つ目はローコードというプラットフォームの上でシステムを構築を起こっている関係から、パフォーマンスの担保が難しくなることがあります。これは構造上ある程度仕方ない論点であり、何かしらのプラットフォームに乗っかる以上、プラットフォームになにか起きた際は一蓮托生になってしまいます。もちろん、ローコードの活用の仕方などを確認した上で、ローコード上の問題なのか、ローコードを活用して開発されたシステムの問題なのかはできるだけ分けて、原因究明を行い、対策を講じるのが一般的です。

まとめ

ローコードは一見様々なユースケースに対応できる夢のようなプロダクトに見えがちです。しかし、ローコードを実際導入しようとすると、情報システム部門とビジネス部門の連携やローコードの拡張性の高さから機能要件が把握しにくいことなどがハードルになります。

まずは、何を成し遂げたいのか目的を明確化した上で、ローコードを選定し、どのように活用し、システムを構築するのか決めていくことが重要です。最終的にビジネス部門が活用するまで、情報システム部門としっかり連携し、当初掲げた目的とソリューションに齟齬がないように導入を進めて行く必要があるのです。

SaaSプロダクトマネジメントローコードノーコードエンタープライズ情報アーキテクチャ要件定義アジャイル開発プロフェッショナルサービス

著者について

宮田 善孝(みやた よしたか)。 京都大学法学部を卒業後、Booz and company(現PwC Strategy&)、及びAccenture Strategyにて、事業戦略、マーケティング戦略、新規事業立案など幅広い経営コンサルティング業務を経験。DeNA、SmartNewsにてBtoC向けの多種多様なコンテンツビジネスをデータ分析、プロダクトマネージャの両面から従事。その後、freeeにて新規SaaSの立ち上げを行い、執行役員 VPoPを歴任。現在、Zen and Companyを創業し、代表取締役に就任。シードからエンタープライズまでプロダクトに関するアドバイザリーを提供。ALL STAR SAAS FUNDのPM Advisor、およびソニー株式会社でSenior Advisorとして主に新規事業における多種多様なプロダクトをサポート。また、日本CPO協会立ち上げから理事として参画し、その後常務執行理事に就任。米国公認会計士。『ALL for SaaS』(翔泳社)刊行。


新着記事

Transformation

プロダクト開発におけるこれからの要件定義

要件定義は、プロダクト開発の成功を左右する重要なプロセスです。効率性や柔軟性を追求し、DX時代の価値創造を支える新しい視点を探ります。

詳細