DXを成功させるためのローコード開発の勘所【第6回】

ルール1：ベストプラクティスに従う

　ローコード開発を効果的に進めるためには、ローコード開発プラットフォームが用意するベストプラクティスを活用すべきです。そのためにはトレーニングを受講し正しく利用する必要があります。

　例えばローコード開発プラットフォームでは、不足する機能をコードを記述することで補うカスタマイズが可能です。しかし記述したコードに対しては、性能やセキュリティを考慮する必要があるほか、将来の保守性も損なわれます。要件を完璧に満たせなくても、標準機能である程度充足できるのであれば、安易にカスタマイズを選択せず、可能な限り標準機能を利用することが大切です。

　ベストプラクティスとしては、データサイズや設定値、機能の正しい活用方法なども用意されています。これらに従うことで性能やセキュリティ、保守性を保持でき、バージョンアップ時の互換性の影響も軽減できます。

ルール2：組織独自のルールを設定し守る

　アプリケーション開発では、プログラムの品質と保守性を確保するために、コーディング規約などの開発標準を独自ルールとして定義することがあります。ローコード開発プラットフォームでは、コーディングに対する独自ルールは多くは必要ありません。

　ですが、例えば命名規則は明確に定義しルール化することが望ましいです。命名規則があいまいだと、既存の成果物と類似した部品を新たに開発してしまうなど再利用性が低下します。

　独自ルールは、CoE（Center of Excellence）が中心になって定義し、適切に遵守していくべきです。長期的な成功のためにはビジネス部門とIT部門の連携が不可欠であり、それぞれが独自のルールを定めていては、高品質で保守性の高いアプリケーションは開発できません。

　こうした独自ルールは、ローコード開発におけるガバナンスを高めます。ガバナンスが効かない場合、次のような失敗を引き起こしてしまいます。

・冗長性による出費の増加と規模の経済の喪失
・設定ミスによるセキュリティリスクの増加
・コンプライアンス違反による規制上の罰則
・部門間のコミュニケーションの欠如
・シャドウテクノロジーの温床
・透明性の欠如によるイノベーションの停滞
・人員の異動や離職によるレガシー問題の発生