ノー・ローコード開発について

はじめに

どうも、はじめましてノブです。

最近、仕事でノー・ローコード開発について
社内でも導入検討したいけど
何が最適なのか、導入までの提案をして欲しいと
リクエストがありました。

今までにも、そういった類のツールを評価する機会だったり
取引のある会社さんから使って欲しいという依頼があり
社内の別部署に使ってもらえるように交渉したりと
実際に携わる機会はありました。

ここにきて、自分の目線で製品比較から
検証作業までを行い、その結果を
提案書にまとめる必要に迫られ
まずは製品比較をして、その後、検証用として
テスト的に簡易システムを構築します。

実際に、提案書を作る中で
今のところ一番苦労したのは
製品比較です。

製品比較って、実際に使って
その使用感だったり、機能だったりを比較すると思うんですけど
製品選定段階から、実際に使って評価をするには
時間的に無理があるので、他人様の書いたレビューだったり
製品紹介だったりを見て比較表を作ることになると思うので
とても苦労しました。

製品紹介では、○○できるとか
○○が簡単だとか書いてあるけど
それを確認するには時間的に無理があるからです。

例えば、既存システムと連携できるといっても
おそらく、連携するための設定だったり
カスタマイズだったり、一部作り込みだったりが必要でしょうし
『簡単』と一口に言っても、どのレベルの人から見て簡単なのか
その基準についても、曖昧なので
本当は気のすむまで検証してみたいんです。

そんなこんなで、僕目線では「いい加減」な
製品比較表を作成し、なんとか提案書をまとめたのですが
その時に感じたことをまとめたいと思います。

こんな人に読んでもらいたい

まずは結論

ノー・ローコード開発？
そもそも、ツールじゃなくて、
何を作るのかが大切

つまり、開発工程における
「プログラミング」だけを簡略化したところで
設計やテストが不十分では、誰も使えないのである。

仮に、ちょっとしたツールやシステムを構築しようとする。
自分だけで使うものであっても、その目的や使い方、求める結果など
正しく整理しないと、全く使えない または部分的にしか使えない
作成の労力だけが必要となり生産性の改善が見られないものを作ってしまいかねない

なので、何を使って作るのか？ではなく
何を作るのか？という目的をはっきりさせることが重要である。

システム開発の工程について

一般的に、システム開発は以下のような工程に分けられる

１．要件定義

この工程では、開発するシステムに、どんな要素を盛り込みたいかを明確にします。
さらに、この要求をもとに、予算や人員、期間を計画していきます。
この際にシステム開発をおこなう目的やターゲットについて整理します。
全ての工程において通常は、1つ前の工程が完了していない状態で次の工程に進むことはありません。
同時に前の工程に戻ることもありません。
つまり、各工程で成果物を出していくことになります。
常に計画性を保ちながらシステム開発を進めることがじゅうようであり
最初に決定する計画こそが重要です。
システム開発の最終的な完成に相違がないよう、しっかりと認識を合わせておきましょう。

２．外部設計

要件定義の内容をもとに、ユーザーインターフェースを設計します。

ユーザーインターフェースとは

画面などの見た目のことです。
ユーザーにとって使いやすいシステムを作るためにとても重要な工程になります。
ユーザーの使い勝手においてダイレクトに影響します
項目の並びや、各項目のサイズ、項目名など
直感的にわかりやすくすることが重要になります。

1つの画面に表示される情報が多すぎても少なすぎても使い勝手が悪いですし
項目名についても、誰もが理解しやすい項目名をつける必要があります。

また、関連性の高い項目を近い位置に並べることで
ユーザーへの負担も軽減できます。

３．内部設計(詳細設計)

外部設計が決まりましたら、次は内部設計、つまりプログラミングの設計を行います。
外部設計はユーザー側からの視点でしたが、内部設計においてはプログラムの設計など、
開発者側からの視点でシステムを設計します。

プログラミングの設計と言っても、いくつも設計すべき観点があります。
例えば、既存システムとの連携部分や
データを保存する場合の、データを保存する単位、各項目の桁数や属性などの設計
要件を実現するための内部的な処理の流れを整理するような工程になります。

４．プログラミング

内部設計で、ある程度のプログラミングが設計できましたら、
それに基づき、プログラムの作成を行います。

ノー・ローコード開発の場合
ここで初めて登場し、この工程でその役目を終えます。

確かに、プログラミングの知識がなくても
システムを構築することは、生産性を向上させることに効果はあると思いますが
システム開発全体を見た場合、その効果はそれほど大きくありません。

プログラマという人材を育成するコストを考えると
確かに効果があるように見えますが
プログラミングに至るまでの工程が
プログラミング以上に重要となるシステム開発では
外部からリソースを借りてくる方がよっぽどコスパがいいと考えます。

５．単体テスト

ここでは、実際に作成したプログラムの最少となる機能の単位が、
最初の要件定義で求められている要件を満たしているかを確認します。

単体テストでは、プログラミングの対象単位(モジュール単位)のテストとなります。

６．結合テスト

単体テストの次は、複数のプログラム(モジュール)を組み合わせた状態で、
それらがうまく機能するかを検証します。

例えば、メールを送信するなどの際に
「送信元を設定する」
「送信先を設定する」
「件名を入力する」
「本文を入力する」
っといったプログラム同士が正常に連携するかをテストします。

７．システム（総合）テスト

単体テスト、結合テストが完了したら、システム（総合）テストをおこないます。
全てのプログラムが、本当に要件定義の通りに動くのかを確認する工程です。

上記に加えて、多くのアクセスへの耐久性や処理速度などをテストしたりします。

８．運用テスト

無事システムテストをクリアしましたら、実際に業務に取り入れることができるかを確認します。
運用テストでは、実際にシステムを運用する環境下においてシステムに不具合がないかをテストします。

自分の選択基準

コスパがいいこと

そもそもコストの考え方が違う

ノー・ローコード開発で開発した場合
その多くは、ユーザー単位で毎月コストがかかってしまう。

ユーザーが多く、利用期間が長いものの場合
一般的な開発で開発した方がコストは抑えられると考えられる。

一方、開発スピードつまり
リリースまでの期間を短くすることに価値を見出し
金銭的なコスト ＜ システムを使うことによる生産性向上によるコスト削減
と考えた場合、ノー・ローコード開発も有利ではないかと考えられる。

通常開発では、開発工程が多く
リリースまでに時間がかかってしまう。
その点、ノー・ローコード開発は、機能は限定的だが
要件さえきちんとまとめられれば、テストを終えるまでが
かなり短縮されると考えられる。

何に価値を見出すのか、どういったコスト意識で
システムを開発するかによって選択すべきものは変わってくる。

自分がいま所属している会社は、
そもそもシステムを開発する会社であり
通常開発に携わる事の方が圧倒的に多いが
お客様の要望内容によっては
ノー・ローコード開発を使った方が
要望に沿うこともあるだろう。

会社にとって有効な武器はいくらあっても困らない
ノー・ローコード開発という武器も早く使えるようにしておきたいと思う。

結論までの経緯

結局、何を作るにしても
その目的や求めたい結果などが明確になっていないと
何かが出来上がったとしても誰も使わない
誰にも使えない、なんの効果もないものができてしまう。

仮にできたとしてもテストが不十分であれば
やりたい結果にたどり着けないし
誰が使うのか、どういった使い方をするのかを
十分考慮できていないと、特定のパターン以外は効果を発揮しないという結果になる。

つまり、前述したように
通常のシステム開発同様
プログラミング以外の工程にあたる部分が非常に大事であり
製作者本位のシステムではおそらく
みんなが求めるような結果にはならないと考えられる

ノー・ローコード開発だけでは不十分だという結論について

ここまで述べてきたように、ノー・ローコード開発にはノー・ローコード開発の
通常開発には通常開発のメリット、デメリットがある訳で

どういった切り口でコストを計算するのか、
そういった切り口で価値を判断するのかによって
選択すべき開発手法やプラットフォームが変わってくると思う。

利用者がさほど多くなく
社内で稼働していてシステム化されていない仕組みを
システム化したい場合には、ノー・ローコード開発が最適だろうし
社内で既にいくつかのシステムが稼働していて
それらを連携させて、業務を簡素化したいのであれば
付き合いのあるSIerに相談する方が良いだろう。

その時には、何を重要視するのかはっきりと伝え
最適な開発手法やプラットフォームを選択してもらい
なぜそれを選択したのか納得できるまで説明してもらうべきだろう

最後に

僕自身は、社内でノー・ローコード開発ツールの選定を引き続き行うのだが
実は、妻の会社ではすでにノー・ローコード開発を使い
システムを構築したことがあるらしい

しかも、ちゃんとSIerさんが間に入ってである。
しかし、開発当時、十分な要望の整理ができず
不十分な要件整理の結果をSIerさんに伝えた結果
現在ではだれも使うことのないシステムが構築されてしまったそうだ。

このように、ノー・ローコード開発だからといって
十分な要件の整理をせずに作り始めてしまうと
誰も使わない野良システムができることになる。

また、こういったノー・ローコード開発の場合
誰にでも作成権限が与えられてしまう可能性がある
そうすると、ちょっとシステム開発に興味がある社員などが
誰が使うか分からないような野良システムを乱立させてしまいかねない。

こういった点からも、管理者を置き
正しく整理し、管理することも重要だと考えます。

皆様の生産性やコストが
全体を通して改善されることを期待しております。