序章

昨今、ローコード開発というシステム開発手法が注目されています。ローコード開発では、画面から視覚的に設計情報を入力することで、自動的にシステムの画面やデータベースが生成されます。開発期間が短くても、多くの画面を実装しつつ、高品質でリリースできます。
一方で、Web上ではローコード開発で失敗したプロジェクトの事例も見かけます。一体どんな要因で失敗してしまうのでしょうか？ 何に気を付ければプロジェクトを成功に導けるのでしょうか？ 本記事では、ローコード開発プロジェクトの失敗事例と成功事例をご紹介し、それぞれの要因も考察していきます。

ローコード開発の失敗事例

始めに、製造業A社の社内システム開発プロジェクトを取り上げます。ローコード開発とアジャイル開発を組み合わせたプロジェクトでした。

当初、A社には、ローコード開発プラットフォームによってスクラッチ開発する部分を少なくしたいという思いがありました。ローコードの標準画面・標準機能によって要件の80%を実現し、残りの20%はプログラミングによる標準画面・標準機能のカスタマイズで実現しようとしていました。

しかし、A社とベンダーで要件定義を進めた結果、カスタマイズ部分が95%となることが判明しました。ローコード開発プラットフォームは、その製品の提供会社によって機能追加やアップデートが行われます。中にはクラウドサービスとして提供されている製品もあります。プロジェクトで採用したローコード開発プラットフォームはクラウドサービス形態の製品でした。プラットフォームがアップデートされたとき、カスタマイズ部分のソースコード改修・回帰テストが発生することとなりました。当初のＡ社の思いとは裏腹に、システム開発のコストが大幅に膨らんでしまったのです。

ローコード開発が失敗する要因はなにか？

こうなった要因はどこにあるのでしょうか？ 本記事では、二点挙げてみたいと思います。
・アジャイル開発で進めたが、仕様が膨らみすぎたこと
・エンドユーザーとの仕様調整が上手く進まず、業務をローコード開発プラットフォームの標準機能に寄せるための意思統一が出来なかったこと
この結果、カスタマイズ部分の比率が高くなり、ユーザー受入れテストでシステム不具合が多数発生しました。その不具合のうち、80%は仕様変更に起因するものでした。

仕様が膨らんだ結果、失敗したプロジェクトはこの事例だけではありません。アジャイル開発だからといって仕様をしっかり固めずに進めた結果、仕様が膨らんでしまい、結局は開発プラットフォームを変更して作り直しとなった事例もあります。

また、別の失敗事例として、製造業B社の生産管理システムの開発プロジェクトがあります。採用したローコード製品の機能的な制約から、標準機能を利用できず、カスタマイズして実現する要件が多くなりました。実装フェーズでカスタマイズ部分の処理性能を確保しておらず、大量データを処理する機能で遅延が発生し、業務に支障をきたしました。

システム開発プロジェクトは、ローコード開発プラットフォームを導入するだけでは成功しません。どの事例においても、その製品の制約・特徴を見極めてから採用した上で、プロジェクトマネジメントでエンドユーザーと仕様調整をしつつ、業務もなるべく製品の標準機能に寄せることが必要だったのではないでしょうか。

ローコード開発の成功事例

ここからは成功事例をご紹介します。コンテンツ事業を営むC社の法人向けWebサイト構築プロジェクトです。

このプロジェクトで最重要課題とされていたのは、認証・認可ロジックの実現でした。Webサイトを利用する様々な法人ユーザーのニーズに応える必要があったためです。プロジェクト成功の要因は、開発予算を認証・認可ロジックに集中したことです。採用したローコード製品の認証機能をベースとしつつも、そのままでは対応できない要件はプロコード開発（技術者がプログラム言語を用いて開発する手法）によるカスタマイズで実現しました。一方で、Webサイトの画面については、ローコード開発プラットフォームの標準画面で多くを実現しました。

具体的な進め方として、最初に要件定義工程で、ローコード製品の標準機能からカスタマイズする部分と標準機能そのままで済ませる部分を明確に定義しました。標準機能で済ませる部分は、まずWebサイトの運営業務を整理して、実際に標準機能で済ませることができることを確認しながら進めました。進めていくと、C社としてはカスタマイズしたい部分も出てきましたが、運営業務を工夫することでカスタマイズを回避しました。その結果、認証・認可ロジックに開発リソースを集中することができ、スケジュール遅延もなく、プロジェクトを無事に完了させることができました。

ローコード開発の成功のポイント

ここまで読んで、「そんな簡単に、ユーザーにローコード標準機能で納得してもらえたら苦労はない」と思われた方もいらっしゃるのではないでしょうか。では何がポイントだったのでしょう。

一つは、プロジェクト計画にローコード製品の調査フェーズを含めたことです。最初に実現したいことと製品仕様とのフィット＆ギャップを分析し、C社がギャップを把握した上でプロジェクトに臨んだのです。

もう一つは、実際にローコードの標準画面を触ってシステムを運用するユーザーもプロジェクトに巻き込んで意思決定を行ったこと、その際にプロトタイピングで標準画面の仕様を詰めたことです。C社とベンダー間の認識相違が少なくなり、同じ目線で開発に取り組むことができました。

まとめ

本記事では、ローコード開発の失敗事例、成功事例とその要因をご紹介しました。あらためて、以下にプロジェクトの成否を分けたポイントを整理します。

【ローコード開発プロジェクトの成否を分けたポイント】
・発注者側が、ローコードの標準機能で実現できる仕様には限界があると理解していたこと
・発注者・ベンダーの双方が、ローコードの標準機能から逸脱しすぎないようにシステム仕様と利害関係者の期待値をしっかりコントロールしたこと
・標準機能の限界を踏まえたうえで、エンドユーザーなどキーパーソンを巻き込んで合意形成したこと

最後に、ローコードの標準機能とプロコードによる実装をミックスできるローコード開発プラットフォームを１つご紹介します。それは、iPLAss（アイプラス）です。
iPLAssは、SDKとしてアプリケーション一体型Web IDEと開発フレームワークを提供しています。SDKでは、ローコード機能で自動生成されたデータベースや画面機能にアクセスするためのJavaのAPIを使って、標準機能を自由にカスタマイズすることができます。

ただし、Javaで実装するということは、その実装コストも発生するということです。コストをかけてまで実現すべき仕様かどうかの検討・意思決定がとても大切です。
システム開発プロジェクトでは、コストやスケジュール管理など計画・検討しておくべき要素は多々あります。ローコード製品をブラックボックスとせず、フィット＆ギャップ分析を行ったり、利害関係者としっかり仕様調整を行ったりするなど、プロジェクトマネジメントで重要な活動やベストプラクティスの実践が大切なことは、ローコード開発のプロジェクトでも同じです。

読者の皆様には、ぜひこれらのポイントを押さえていただき、プロジェクトに取り組んでいただけましたら幸いです。最後までお読みいただきありがとうございました。

当サイトでは、ノーコード開発ツールやローコード開発プラットフォームを利用し、業務システムの開発を効率化したいエンジニアの方や、会員サイト構築などの新規事業の目的を達成したい方へ、ダウンロード資料をご用意しております。ぜひ資料をご覧いただき、ご活用ください。