CHALLENGE 02

ノーコード・ローコード開発とは 、専用の開発支援ツールを利用し、従来のシステム開発が抱える問題点に対処し、システム開発により高い生産性をもたらす考え方、開発への取り組みのことを指します。

１．開発スピードの遅さ
要件定義、基本設計、詳細設計・・・と各工程の成果物としてドキュメントを作成しなければならない為、その作成のみならず、レビュー、修正、維持管理など時間がかかってしまいます。

２．手戻りの発生
ドキュメントをベースに開発工程が進むため、実際のシステムを終盤にならないとユーザは確認できません。ユーザはドキュメント上だけの説明やイメージだけでは表面的な理解にしかならず、具体的なイメージの理解や利用を想定した確認に至らなかった結果、「やっぱりこうしたい」が良く発生します。開発終盤に発生するこの変更が大きな“手戻り“となり、開発全体に大きなインパクトを与えます。

３．コストの高騰
開発終盤における上記の手戻りを防ぐために開発側は設計段階から注意を払って開発を進めますが、注意を払っていてもどうしても発生してしまうものであり、このリスクを解消するために、開発側はあらかじめこのことを見据えた見積もりを提示します。手戻りが発生しないことを前提にできれば上積みされなかったコストをユーザは“余分に”払わなければならないことになります。

４．設計と実装の乖離
開発終盤における急な仕様の変更、実装の見直しにより、急いでプログラムだけ先に修正し、ドキュメントは後から修正する、ということが良くあります。この時、きちんと後からドキュメントまで修正を行えれば問題はありませんが、忙しさを理由に手が回らず、失念したままになってしまうこともあります。そうすると、実際のプログラムとドキュメントに乖離が発生し、ドキュメントの内容が最新ではなく、正確な仕様を把握するためにはプログラムを見なければならず、ドキュメントの意味をなさなくなってしまうことがあります。

５．属人化
開発において成果物として残したドキュメントは、その量が多ければ多いほどシステムの姿を明確に残すことになりますが、一方でその管理や維持にコストを要します。修正が必要となった際には複雑に関連したドキュメントの全てを正確に修正できれば良いですが、漏れや間違いが発生すると、後から是正することが困難になります。その煩雑さゆえに、管理や維持する担当者が限定され、属人化につながります。

世の中のノーコード・ローコード開発ツールの中には、様々な製品がありますが、多かれ少なかれ、これらの要素を“情報”として渡すことで、アプリケーションを自動生成することになります。

１．スピーディな具現化
プログラミングすることなく、画面操作や簡単な入力だけでアプリケーションを組み上げることができるので、完成とは言わないまでも、ある程度動作やイメージを確認できる状態のモノをスピーディに具現化することができます。

２．必要最小限の設計
プログラミングすることなく、ノーコード・ローコード開発ツール上の入力や指定のみでシステムを組み上げていくため、設計作業がなくなるわけではありませんが、その量は少なく済みます。

３．自然と標準化される
良くも悪くも使用するノーコード・ローコード開発ツールでアプリケーションを組み上げていくため、そのツールの制約を受けながら進めていくことになります。その為、プログラミングのような自由さがなく、異なる開発者が開発を進めても、システムの作られ方は統一されます。様々なシステムが同様に統一されていけば、自然と全体が標準化されていきます。

ノーコード・ローコード開発と従来のシステム開発の実施する工程を比較するとこのような形になります。流れや踏むべきステップに大きな違いはありません。しかしながら詳細設計や、開発と言った、時間のかかる工程を圧縮させることができます。

また、要件定義段階において、プロトタイプを作成し、ユーザに対しこれから作成するシステムのイメージを提示することで、ユーザと開発側の双方のギャップをなくし、スムーズなシステム開発を行うことができます。

ノーコード・ローコード開発とスクラッチ開発、パッケージ製品導入とを比較してみました。スクラッチ開発は、別名フルオーダーメイド開発と呼ばれ、工期は長くなってしまいますが、その分どんな要望にも応えることができ、柔軟性に富んだシステムを開発することができます。

一方でパッケージ製品の導入は、基本的に既製品をそのまま導入することが前提であるため、スピード感のある導入（利用開始）を行うことができますが、その分カスタマイズが一切できないなど、柔軟性を犠牲にします。ノーコード・ローコード開発は両者の良い処どりをしたような形です。

スクラッチ開発のような柔軟性を持ちつつも、スピーディに開発できる特性を生かした工期短縮を狙うことができます。

ノーコード・ローコード開発は従来のシステム開発に比べ、良いことばかりを並べてきましたが、注意しなければならないこととして、「なんでも作れる魔法の杖」ではないということです。ツールによりけりですが少なからず、開発できる画面や機能面で制限を受けることになりますので、ユーザにも妥協して頂く必要があります。この“妥協する“と言うことについて、ユーザ側の協力を得ることが成功するための重要なポイントになります。

ノーコード・ローコード開発のメリットをしっかりと享受するためには、ユーザササイドにも一定の理解をして頂く必要があります。

前述の繰り返しになりますが、開発ツールを使った開発では、自由自在にシステムを作れるわけではない為、開発ツールとしての制約やルールを受け入れて、システムの仕様を決めていく必要があります。

この制約やルールから逸脱するような特別な要件（仕様）については、その実現方法を開発側としっかりと協議してどう実現するかを考える必要があります。ノーコード・ローコード開発においては、この特別要件をどう実現するか、どう一般化させるか（標準化）させるかが、開発全体の成功につながるポイントになります。

一方で開発サイドもしっかりとした認識が必要です。

開発ツールを、システムを組むことができるソフトウェア、と単純に解釈するのではなく、プログラミング言語におけるフレームワークのような位置づけと同じように解釈し、フレームワークの対象が、画面UIや画面内のアクション、DBテーブル上のデータの取り扱い方にまで範囲が拡大したようなものであると捉えるべきだと考えます。

そうすることで開発ツールの制約やルールに則り、開発を進めることができれば開発自体も楽に進めることができますし、フレームワークに従って開発されることで、作った画面や機能全体において標準化・統一化の恩恵を受けることができます。

一方で、このフレームワークから外れざるを得ないような要件があった場合、それをどう実現するかも重要ですが、その要件自体をどうコントロールするのか（例、運用回避、他サービス連携等）、も重要になってきます。

これまで説明してきた通り、ノーコード・ローコード開発は、従来のシステム開発の問題点を解消し、小さくないメリットを享受できるものでありますが、そのメリットをしっかりと実現するためにもユーザサイドと開発サイドが共通理解が必要です。

その共通の理解のもと、協力し合って開発を進めることで、お互いにとってWin・Winなシステム開発を実現することができます。