ローコード開発の効果と考慮すべき6つのポイント--ロックインや設計書に注意 - (page 2)

考慮点

　ローコード開発による工数削減、品質やユーザー満足度の向上を実現する一方で、考慮すべき点があることも事実である。ここでは、ローコード開発の考慮点と対応策を考察する。

　考慮点は以下の6つである。

1. ユーザーの要求が噴出した際の方針を決める
2. 「設計書」の作成要否を決める
3. プログラム言語、ブラウザーの種類やバージョンといった技術要素との適合性を検証する
4. 機能の一部を開発できない場合を考慮する
5. ツールロックイン（乗り換えが不可能になること）を受け入れる
6. ライセンス料金を考慮した総保有コスト（Total Cost of Ownership：TCO）で判断する

1.ユーザーの要求が噴出した際の方針を決める

　ユーザーは、動くプロトタイプを見て要件を検討するため、システムを活用した業務を具体的にイメージできる。それにより、要望が噴出することになる。

　対応策として、ユーザーの要件に優先順位をつけ、採否を含めて強力にスコープを管理する必要がある。プロジェクトマネージャーに決裁権を付与し、その決定に従うようプロジェクト計画に明記するなどでガバナンスを構築するのが肝要である。また、要件決定を先送りせず即断即決することで、噴出する要件の積み残しを回避することができる。

2.「設計書」の作成要否を決める

　ローコード開発では、設計情報をツールに直接設定してプログラムを生成するため、設計書を作成する必要はなくなる。一方で、IT部門の開発管理規程などで設計書を必須とするケースは多いものと思われる。

　対応策として、設計書の目的を改めて吟味し、設計書を作成するかどうかをあらかじめ協議しておくとよいだろう。なお作成する場合、相応の工数削減効果が相殺されることを考慮する必要がある。

3.技術要素との適合性を検証する

　ツールによって、サポートする技術要素が異なり、ローコード開発を行うシステムのそれと適合しない場合がある。また、IT部門が定めた技術要素の標準ガイドラインと適合しない場合も考えられる。

　対応策として、この点も対応方針をあらかじめ決めたほうがよいだろう。例えば、システムの技術要素や自社標準ガイドラインに適合するツールを採用する、ローコード開発ツールに適合するようにシステムの技術要素や自社標準ガイドラインを変更する、ローコード開発ツールに適合しない機能を別途開発する、などである。

4.機能の一部を開発できない場合を考慮する

　システム開発を進めると、ローコードツールで開発できない超高難度な機能を開発する場合も想定されるだろう。実際、第2回で紹介した金融機関の事例では、画面にリアルタイムで刻々と変わるグラフを表示させる機能を開発しきれなかった。

　このケースでは、オープンソースソフトウェア（OSS）などを活用してアドオン開発することで解決した。同様のケースでの対応策として、やはり対応方針をあらかじめ定義しておくのがよいだろう。アドオンで開発する、要件を変える、選択肢をあらかじめ定めて都度精査する、などである。

5.ツールロックインを受け入れる

　ツールが生成したプログラムを自前で改変することは、理論上は可能であるが、その場合プログラマーはツールが生成した全プログラムの生成ロジックを学習するという極めて高難度な作業が起こり、生産性を著しく阻害する。

　ローコード開発では、ツールロックインを受入れ、長期間使用する前提でツールを選定することが肝要である。

6.ライセンス料金を考慮したTCOで判断する

　ローコードツールのライセンス料金は継続的に発生し、ツールによって課金対象、支払い形態は異なる。それにより、ローコード開発を採用するシステムの利用条件でツールごとの料金は大きく変化する。

　そのため、5年以上のTCOで工数削減効果とライセンス料金を踏まえてツールを比較し選定する観点を忘れてはならない。

　ここまで、ローコード開発の効果とその要因を分析し、ローコード開発を推進する前にあらかじめ考慮しておくべき点を考察した。これらの考慮点を踏まえ、関係部門で共通認識をもち、ローコード開発を検討いただきたい。

　最終回は、ローコード開発における人材確保の方法とローコード推進ステップについて考察する。