はじめまして、クオリティマネージャーのヒロたです。
近年、多くの企業で DX（デジタルトランスフォーメーション） が求められ、システムは単なる業務効率化ツールではなく、ビジネス戦略の中枢を担う存在になっています。その結果、従来のように「要件定義 → 詳細設計 → 実装 → テスト → リリース」と長い時間をかけて作る大規模スクラッチ開発では、ビジネスの変化のスピードに追いつかない。変更対応や機能追加にも時間がかかり、結果として競争力を削ぎかねません。こうした背景から、 「早く作る／早く直せる」 ことが重視されるようになり、コードを書き続けるスクラッチ開発よりも、再利用可能な部品やテンプレートを活かせる手法 、すなわちローコード／ノーコードの需要が高まってきています。
本日は、ローコード／ノーコード開発（以降、LCP/NCP開発と表記） の品質について筆者が考える考慮点をご紹介します。
LCP/NCP開発の「品質」を測る、新しいものさし
1. そもそも品質って何だろう？
私たちがシステムに求める「品質」とは何でしょうか？ 昔は「欠陥がないこと」を指していましたが、今では「要求を満たす程度」や「価値そのもの」と捉えられています。
近年はローコード／ノーコードの普及により、従来のようにコード量や詳細設計を基準に品質を把握する手法が通用しにくくなりました。部品再利用や自動生成が前提となり、開発速度は大きく向上した一方で、内部構造が見えにくくなる場面があります。そのため従来のようにコード量や詳細設計を基準にした品質の捉え方が当てはまりにくくなり、最終的な成果物が業務要求をどれだけ満たしているかという“価値そのもの”に重心を置いた評価がより重要になってきています。しかし、新しいLCP/NCP開発では、従来の品質管理のやり方があまり当てはまらないという課題があります。
2. 従来のやり方ではなぜ測れないのか？
従来のスクラッチ開発（ゼロからコードを書く開発）では、コードの行数（SLOC）や機能の規模（機能数）を基準に品質を測ってきました。
しかし、LCP/NCP開発には、従来の統計値、基準値が使えないという問題があります。
(1) コード行数がわからない
LCP/NCP開発は部品（コンポーネント）を組み合わせて作るため、コード行数（SLOC）を正確に数えることができません。
(2) カスタマイズ性の限界
プラットフォームの提供するテンプレートや部品に依存するため、業務が複雑だったり、高度な処理が必要だったりすると、“やりたいこと”を満たせない場合があります。
(3) 保守性・スケーラビリティの不安
開発は速いが、アプリが大きくなったりユーザー数が増えたりすると、パフォーマンスや拡張性、セキュリティ確保が難しくなることがあります。
(4) ガバナンス／標準化の困難
経験の浅いエンジニア（または、現場担当者など）が容易にアプリを作れる反面、誰が、どんな品質で作ったか分かりにくくなります。
(5) ベンダーロックインのリスク
プラットフォーム依存になるため、別のツールへの移行が難しく、将来的な柔軟性が損なわれる可能性があります。
このように、LCP/NCP開発は、“軽さゆえの穴”を持っており、そこをどう管理するか 。
— ガバナンス、標準化、運用・保守体制の整備 — が今後ますます重要になっています。
3. 新しい基準
(1) FUNCTINAL POINT数で規模を測る
FUNCTINAL POINT数は、コード行数ではなく機能の規模を測る客観的な基準です。IFPUG法※１に代表されるFUNCTINAL POINT数を使うことで、プロジェクト管理を「勘」から「定量的な判断」に変えることが出来ます。（ITシステム可視化協議会（MCIS）の研究会lcncSig※2より）
(2) テストの基準
FUNCTIONAL POINT数規模に基づいてテストケース数を分析し、規模に応じた適切なテストケース数の目安を作ります。（テスト密度）
これにより、必要なテスト量が明確になります。また、テストは “業務の流れ” を中心にすることが重要です。
ローコードのテストはコードではなく、人がどう操作するかに焦点を当てた方がよいでしょう。
入力して → 承認して → 通知されて → 次の人が処理して…
この辺がきちんと回っていることがテストで確認出来れば、大きな問題は起きにくいと考えられます。
(3) ODC分析※3 で不具合の「質」を見る
LCP/NCP開発では不具合の「量」だけでなく「質」に着目するODC分析が有効です。
LCP/NCP開発で発生しやすい不具合の傾向は次の様に考えられています。
| 不具合の種類（タイプ属性） | LCP/NCP開発の傾向 |
|---|---|
| アルゴリズム | 従来のコード開発より比率が高い |
| ビルド・パッケージ・結合 | 従来のコード開発より比率が高い |
| タイミング・順序、インタフェース | 従来のコード開発より比率が低い |
LCP/NCP開発ではコンポーネントの結合部分や拡張コード（アルゴリズム）の不具合が発生しやすい一方で、LCP製品が標準で制御してくれるインターフェースや順序に関する不具合は減ることになります。
ODC分析については、次のScripts記事を参考にして下さい。
4. 品質を判断するためにどうあるべきか
LCP/NCP開発は発展途上であり、品質を測る新しいメトリクスもまだ完全に確定していません。前述の指標を活用しつつ、現場のアイデアも取り入れることが重要です。
（1）レビューの活用
製造工程がないLCP/NCP開発では、処理構造やロジックをレビューすることが、実装の品質と保守性を保つために有効です。
余談ですが、コード量と不具合数が相関しない新しいタイプの開発（AIによる自動生成プログラムなど）においても同様な事が言えます。
（2）ガバナンスと標準化の徹底
LCP/NCP開発は手軽に作れる反面、同じような機能でも開発担当者やチームによってバラバラなコードを使用してしまうことがあります。そこで重要になるのが ガバナンス（統制）と標準化 です。
- 共通の部品やテンプレートの利用
- 命名ルール、データ定義ルールの統一
- 変更時の影響範囲を把握できる設計文書の整備
LCP/NCP開発はまだ一般化した標準も少なく、現場ごとに最適なやり方を模索する段階にあります。ですが、設計の可視化・指標に基づいた継続的な評価による品質管理、業務シナリオ中心のテスト、部門内の開発標準の徹底を図ることにより品質の安定化を図ることが出来ます。
まとめ
従来の品質管理が「個々のレンガの強度」を測っていたとすれば、LCP/NCP開発の新しい品質指標（FUNCTIONAL POINT数やODC分析）は、「規格化されたブロックの組み立て方の確かさ」を測ることにシフトしています。これにより、作るスピードを落とさず、安全で丈夫な建物（システム）を確実に建てられるようになるのです。
LCP/NCP開発はまだ一般化した標準も少なく、現場ごとに最適なやり方を模索する段階にあります。設計の可視化・指標による品質管理・業務シナリオ中心のテストを丁寧に組み合わせれば、スクラッチ開発に引けを取らない品質は十分に実現できます。
これからローコード開発の品質に向き合う企業に向けて、このブログが少しでも参考になれば幸いです。
用語解説
- ※1 IFPUG法
1980年代に米国で生まれた国際標準(ISO/IEC20916)の機能規模測定法で、画面やファイルなどの“提供する機能”を数値化してシステムの大きさを客観的に評価する手法 - ※2 ITシステム可視化協議会（MCIS）の研究会lcncSig
LCP/NCP開発の課題を解決するための活動を推進
MCIS | IT システム可視化協議会 - ※3 ODC分析
1992年に米IBM社 ワトソン研究所で確立された「欠陥分類手法」、「Orthogonal Defect Classification」の頭文字で、直訳すると「直交 欠陥 分類」となり、お互いに依存しない別軸から欠陥を分類して分析する手法 - ※4 SQiP
実践的で実証的なソフトウェア品質技術・施策の研究・普及を目的として、日本科学技術連盟の下に設置されたソフトウェア品質向上のための活動
日科技連|ソフトウェア品質|SQiP研究会
