ローコード開発コミュニティはこのたび、有志で議論してきた「ローコード開発宣言」を発表しました。私も関わっています。
4つの宣言と、その説明（背景となる原則）から構成されます。以下、転載します。
ローコード開発宣言の背景となる原則
1. ローコード開発の価値は、生産性と保守のしやすさの向上です。
ローコード開発では、設定や簡単な操作だけで、設計から実装・動作確認まで行えます。 また、設定だけで実現できる機能はテストが不要となります。開発とテストの時間を短縮できるため、少人数で開発と保守を一体的に進められ、長期的なシステム運用が可能になります。
2. ローコード開発の成果物は、「動く設計書」です。
ローコード開発では、設計した結果がそのままアプリケーションとして動作します。そのため、設計と実装が乖離することがありません。また、どのように作られているかが分かりやすく、問題の修正も簡単です。
3. ローコード開発では、開発者は業務のニーズに集中できます。
ローコード開発は複雑な実装作業を簡略化するため、開発者は業務の要件の理解や、その実現に専念できます。また、ローコード開発では、簡単に動く画面プロトタイプを作った上で、業務の要件を確認できます。これにより、ビジネスのニーズに迅速かつ正確に対応できます。
4. ローコード開発が目指すのは、全員参加型のシステム作りです。
ローコード開発を利用すれば、プログラミングの知識がなくても業務アプリケーションの開発に参加しやすくなります。これにより、開発を他人任せにすることなく、必要なものを自分たちで用意する主体性が生まれます。また、開発と保守を分けないチーム体制により、最初から完璧な仕様を求めるのではなく、運用しながら皆で仕様を見直す柔軟性が生まれます。結果として、変化に強いシステム作りに貢献します。
数名で何度も推敲を重ね、わかりやすい宣言になったと思います。それでもなお人によって解釈が異なるところはあるでしょう。策定に関わったメンバーの一人として、私はこれをどう解釈しているか、を記します。
"少人数で開発と保守を一体的に進められる"
ツールの力を使うとは、開発プロジェクトに大きな「てこ」の力が加わるということです。その効果は少人数開発にあらわれます。これは大規模開発案件では人を集める力のある SIer が有利、という構図を崩します。
ただしこれはプロジェクトにかかる経費を削減することが目的ではありません。結果的にそういう側面もあるかもしれませんが、目的は少人数化することでコミュニケーションコストを下げ、お客様と開発者の距離を近づけることです。そうなっていない、相変わらず人を集めることを前提としたプロジェクトは、ローコード開発の真価を発揮できていない、と私は受け止めています。これを「ローコード開発はコスト削減」を目的にしてしまうと、コスト削減ならば単価の安い技術者を…という話にすり替わる危険があり、これはまったく宣言の意図を汲み取っていないことになります。
さらにいうと “開発と保守を一体的に” という表現は、そのあとの4でも説明されていますが、開発と保守を分けていないことを明確にしています。つまりローコード開発をやっています、しかし相変わらず開発と保守を分けていますというプロジェクトもまた、その真価を発揮できていないと捉えることができます。
"設計と実装が乖離することがない"
本当に重要なことです。信用できないドキュメントを、それでも人が作成し続けるのは無意味です。ローコード開発ツール自体がもっている設計情報をうまく使いこなすようにするべきです。
"開発者は業務の要件の理解や、その実現に専念する"
実際のところ業務ロジックの理解や実装には極度の集中力が必要です。そのため長時間労働には向いていません。管理者には「ローコード開発環境を利用できるので二倍の量を実装してもらう」ではなく、「集中してもらう代わりに実労働時間を短縮させ、短い時間で最大のパフォーマンスを出してもらう」ような配慮が求められます。そうしないと技術者が潰れてしまう懸念があります。
つねづね指摘されてきたことですが、生産性を高めることは、時間単価 x 労働時間という請求方式と相性がよくありません。ローコード開発ツールを使うことは、働き方改革も同時に考慮する必要がある、と考えています。
"全員参加型のシステム作り"
全員がITに関わる必要はありません。肝となるのはむしろITではなく、業務（ロジック、データ構造、そしてデータの量と質）の理解です。これまで多くの関係者が、この部分の会話が少なかったために後工程で問題が噴出するという苦い経験をしてきました。ITの、特に面倒な部分をツールに吸収させ、業務の会話にもっと時間を充てようというメッセージである、というのが私の解釈です。
このようにみると、この宣言はエンタープライスシステム開発の根本的な問題に切り込んでいると思います。ローコード開発を「汎用プログラミング言語とは違う、閉じた、特殊な環境で、一過性のもの」とみなすのではなく、ITの力を高めてこれまでの開発現場が抱えていた問題に切り込むためのツールとみると、視点が変わるのではないでしょうか。
