第 38 年度（2022 年度）ソフトウェアプロセス評価・改善コース（No & Low-code チーム）
ノーコード・ローコード開発を成功に導くための「ノー＆ローコード虎の巻」の提案
Suggestion of "No & Low-code Toranomaki" for the success of no-code/lowcode development
リーダー：内田 泰介（株式会社日立ソリューションズ・クリエイト）
研 究 員：池田 幸子（株式会社日立システムズ）
古里 透 （株式会社アズビル）
主 査 ：山田 淳 （株式会社東芝）
副 主 査：田中 桂三（オムロン株式会社）
アドバイザー：中森 博晃（パナソニック コネクト株式会社）

研究概要
ノーコード・ローコード開発ツールを利用したソフトウェア開発 は歴史が浅く,プロセスやノウハウが纏まっていない.また「開発未経験者でも可能」「高品質」「高生産性」といった言葉を信じて開発・保守体制構築や作業計画・コスト確保等の準備を十分行わずに開発を進めてしまうと開発中の QCD 面や開発後の保守面での トラブルが起きる可能性がある.
本研究ではノーコード・ローコード開発を成功に導くため ,陥りやすい注意点を「ノー＆ローコード虎の巻」として整備し,開発・保守担当者が実際のプロジェクトで適用することを目的とした.
ま た ,「 ノ ー ＆ ロー コ ー ド 虎の 巻 」 の 有効 性 を 検 証 す る た め に ,ア ン ケ ー トに よ る 評価を実施した.アンケート結果を分析した結果 , プロジェクト開始前に「ノー＆ローコード虎の巻」を用いた事前チェックを行うことでプロジェクトのリスクを検知し，トラブル回避に有効であることが確認できた.
1.

はじめに近年,ノーコード・ローコード 開発ツールを利用したシステム開発が増え始めているが,従来のプログラミングを伴うシステム開発と開発プロセスが異なることから,従来通りの品質管理・評価手法が適用出来ない可能性がある.
本研究では,ノーコード・ローコード開発の経験・知識を持っている開発現場担当者視点での「ノー＆ローコード虎の巻」を作成し, ノーコード・ローコード開発の品質確保やトラブル回避 に役立てることを狙いとした.
以降 2 章では研究の背景を説明し,3 章では研究提案として仮説立案から「ノー＆ローコード虎の巻」作成,仮説の検証方法について説明する.4 章では「ノー＆ローコード虎の巻」に対する検証結果について説明する.5 章では,「ノー＆ローコード虎の巻」の有効性について考察する.最後に 6 章で,研究成果全体のまとめや,今後の展開について述べる.
2. 研究の背景
2.1 ノーコード・ローコード開発の定義
本研究では, ノーコード・ローコード開発について,次の通り定義する.
可能な限りソースコードを書かず,パラメータの設定や GUI 操作により Web サイトやアプリケーションを開発すること. [ 1 ]2.2 ノーコード・ローコード開発の歴史と期待
最初に登場した Word や Excel，Wix などでは，文書作成・関数処理・図形作成・サイト作成が，コードを書かずに実現できた．しかし実際にはできることに限りがあり，ソフトウェア開発としては実用には至らないものであった .
1

第 38 年度（2022 年度）ソフトウェアプロセス評価・改善コース（No & Low-code チーム）
それが，数年前からノーコード・ローコード開発ツールが進化し実現可能な範囲も広がっていることから，ソフトウェア開発の最先端として注目を集めている．さらに ,企業の競争力向上を目的として DX 推進が求められており，通常のソフトウェア開発よりも短期間での開発が可能とされるノーコード・ローコード開発ツールに対する需要は,今後一層高まっていくと考えられる. [ 1 ]こ の状 況 の 中 で ,ノ ー コ ー ド・ ロ ー コ ード 開 発 に 対す る 過 度 な期 待 が 生 じて , 設 計 ・実装スキルがなくとも開発可能であるといったことや,開発期間の大幅な削減が可能である
とい っ た 期待 感 を 持た れる こ と があ る . 事 例と して , 研 究 員の 所 属 会社 では ノ ー コー ド ・
ローコード開発ツールとして「SalesForce」を利用した開発を行っており,製品仕様が業務にマッチしなかったなどの問題が発生している.
2.3 解決すべき課題（研究ゴール）
2.2 章に記載したようなノーコード・ローコード開発に対する過度な 期待感をなくし,本来のメリットを生かすために,我々は研究ゴールを以下の通り設定する．
【研究ゴール】
ノーコード・ローコード開発への期待感を鵜呑みにせず,適切に開発・保守を準備できるようにする．
3. 研究提案
3.1 課題達成への仮説
3.1.1 仮説の立案（ノー＆ローコード虎の巻）
2.3 章の研究ゴールを達成するために，我々はノーコード・ローコード開発に対する 期待感とその実態を調査・確認し ,ギャップがある部分に対して十分考慮し準備しておくべき留意点を設けることで,より安全にノーコード・ローコード開発プロジェクトを成功に導けると仮説を立てた.
そこで,本研究では開発時や保守時の 各場面において留意点を纏めた「ノー＆ローコー
ド 虎の 巻 」 を 作成 す る . 開 発保 守 メ ン バが プ ロ ジ ェク ト 開 始 前に 「 ノ ー ＆ロ ー コ ー ド虎の巻 」 を 参照 し て , 留意 点を チ ェ ック し 対 策を する こ と で ,ノ ー コ ード ・ロ ー コ ード 開 発のメリットを生かした開発保守作業が実現できることを期待する .
3.1.2 ノー＆ローコード虎の巻の説明「ノー＆ローコード虎の巻」はノーコード・ローコード開発における過度の期待感を抑制する為に留意点をまとめたリストである. 本リストは「付録 2.ノー＆ローコード
虎の巻（アンケート用）」の「ノーコード・ローコード開発の留意点 」の列を参照のこと.
#SWEBOKの知識領域
1 ソフトウェアの要求

ノーコード・ローコード
開発における期待感
期待感A

ノーコード・ローコード開発の失敗事例

ノーコード・ローコード開発の留意点■開発事例からのフィードバック

ノーコード開発であっても、実現したい業務フローや業務用の製品であるため、あ 帳票添付機能が使える製品であったが、添付件数は１帳票ユースケースを作成する必要がある。

る程度のことは意識せずとも のみで複数帳票は添付することができず、顧客の要望とあ（テスト実施時にも必要となる）何でもできるわないことがあった

2 ソフトウェアの要求

従来の開発と同等に製品に合わせたビジネスモデルや業務フローを提案できる人がいること。

3 ソフトウェアの要求■他研究コースからのヒアリング

利用する製品のSLAがどの範囲となっているか認識しておく

顧客とのSLAによって、製品側の問題であってもこちら側必要がある。の問題になることがあった
4 ソフトウェア設計

期待感B■他研究コースからのヒアリング

データモデルや構造設計を明確に理解している必要がある。

設計不要

お試しで、ローコードで開発を実施したが、データモデル（例：同じ意味で異なる名称のデータがあると、複雑にな開発初心者でもOKを設計せずに進めたため、汎用性のないものが出来上がっる）てしまった■データ構造適正化ができておらず、影響分析のワードが定まらないことや、認識齟齬によるトラブルになる事例もあった。

図 1．ノー＆ローコード虎の巻（抜粋）3.1.3

ノー＆ローコード虎の巻の十分性評価2

第 38 年度（2022 年度）ソフトウェアプロセス評価・改善コース（No & Low-code チーム）
「ノー＆ローコード虎の巻」の十分性（研究ゴールを達成するか否か）を評価するた
め に , 我 々 の 研 究 ゴ ー ル , 研 究 課 題 , 評 価 基 準 と し て 以 下 の 図 1 の 通 り GQM 手 法 （ GoalQuestion Metrics）を用いてまとめた.GQM 手法は,ソフトウェアのメトリクスを計測の目標と質問から得るという目標指向の測定法で,計測活動を行う際に広く用いられ,Basili と Weiss により 1984 年に提案された手法である [ 2 ] .我々は GQM が本研究ゴールに対し,研究仮説を定量的に判断できる手法と判断し ,採用する.
本研究における GQM を以下の図 2 に示す.
ー
ノーコード ローコード開発 の期待感を適 に開発をできるよ にする（研究）
ノー ローコード の を作成し、開発 に適用することで適 に開発のができる（研究の 分性確認）
ノー ローコード の にするアンケート

ノー開発分か

ローコード のののの、度はみにせず、ノー

ローコード の の意 は適 に開発のができるものになっている

か：アンケートでた リットのがすて の の期待感のリス
トに しているとは えない：１
でも していないものがある：アンケートでたデ リットのがすて の の期待感のリストに しているとは えない：１
でも していないものがあるのの
意 に し性を 確認：アンケートで上が同意しているとは えない：ア
ンケート
でが同意しているて

図 2.GQM 手法による研究ゴール,課題,メトリクス（十分性確認）の関係
研究課題 1 を設定した理由は,ノーコード・ローコード開発のメリットを十分生かすうえで,開発保守場面の網羅度（量的な側面）を 確認することが必要であると考えたためである.本課題の有効・無効の評価としてメトリクス 1,2 を設定した.
また研究課題 2 を設定した理由は,虎の巻の留意点の内容が開発保守の現場で有効か否か （質 的 な 側 面） を 確 認 する こ と が 必要 で あ る と考 え た た め で あ る . 本 課題 の 有 効 ・無効の評価としてメトリクス 3 を設定した.
3.1.4 ノー＆ローコード虎の巻の作成手順
ノーコード・ローコード開発の留意点のリストについては以下の手順で作成した .
はじめに, 留意点を抽出するにあたり ,体系的・網羅的に開発保守の各場面を押さえるべき と考 えた . そこ で, 我々 は「 software engineering body of knowledge （ ソフ トウェアエンジニアリング知識体系）」（以降 ,SWEBOK） [ 3 ] を採用した.なぜならば SWEBOK はIEEE が纏めたソフトウェアエンジニアリングに関する知識体系であり,開発保守を体系的に整理しているため,網羅的な抽出に適切と考えたためである.
次に,留意点の元データとして,SWEBOK の各知識領域「付録 2」の「SWEBOK の知識領域」の列をもとに「ノーコード・ローコード開発における期待感」や「ノーコード・ローコード開発の失敗事例」の列の項目を研究員が所属する組織の事例や ,他の研究会へのヒアリ
ング,書籍 [ 1 ] などから収集した.
最後に,「ノーコード・ローコード開発の失敗事例 」と「ノーコード・ローコード開発における期待感」の乖離を明確にして ,それらを「ノーコード・ローコード開発の留意点」
3

第 38 年度（2022 年度）ソフトウェアプロセス評価・改善コース（No & Low-code チーム）の列に定義した．
3.2 仮説の有効性の評価方法「ノー＆ローコード虎の巻」の有効性を検証する方法を検討した.本研究の期間内で「ノー＆ローコード虎の巻」を適用出来る実際の開発案件を選定することは困難だったた
め,「ノー＆ローコード虎の巻」についてアンケート (詳細は「付録 1.アンケート」を参照） を取 り , 「 ノー ＆ ロー コー ド 虎の 巻」 の 各 留 意点 を 参照 する こ とと した . アン ケー
トの対象者は,ノーコード・ローコード 開発の開発や品質管理の経験がある人物を想定とした.
「ノー＆ローコード虎の巻」の評価判断基準は図 1 の GQM のメトリクスに基づき以下の 3 点とした.
(1) メトリクス 1：アンケートで得たメリットの内容がすべて虎の巻の期待感のリストに属している場合「有効」と判断する.
(2) メトリクス 2：アンケートで得たデメリットの内容がすべて虎の巻の留意点のリストに属している場合「有効」と判断する.
(3) メトリクス 3:虎の巻の留意点に対して, 5 段階(「1．その通りだと思う」「2．一部当 ては まる と 思う」「 3． あ まり そう は思 わ な い」「 4 ．ま っ たく 当て はま らな い」「5．意図が分からない」）で評価し,アンケート集計結果を 10 点満点に換算し,7.5点以上(3/4 以上)の点数を被験者の同意を得たものと考え，「有効」と判断する.
4.

実験結果
仮説検証では,ローコード・ノーコード開発の担当者と管理者や今後導入を検討している組織の開発者・品証部門,計 31 人を対象にアンケートを実施し , ノーコード・ローコード開発のメリット・デメリット の確認と,「ノー＆ローコード虎の巻」の効果有無を点数化して確認した.被験者については,「付録 6.被験者のプロファイル」を参照のこと.
4.1 メトリクス 1 に対する結果
メトリクス 1 に対しては有効であるという結果となった.それはアンケートの「(7-1)
メリット」で選択された全ての項目が ノー＆ローコード虎の巻の C 列「ノーコード・ローコード開発における期待感」を選択していることを確認できたためである（選択率100%） .こ れに より ,開 発保守 場面 におけ る虎 の巻の 期待 感の網 羅性 は十分 であ ると判 断した.結果は表 1.および「付録 3.アンケート（メリット）集計結果」を参照のこと.
表 1．ノー＆ローコード虎の巻のアンケート結果（メリット）
開発時のメ リット件数【期待感 A】業務用の製品であり, ある程度のことは何でもできる【期待感 B】設計不要. 開発初心者でも OK【期待感 C】開発初心者でもすぐに利用可能【期待感 D】カスタマイズや独自仕様の取り込みも容易に行える【期待感 E】テストはすべて自動で実行ケースも作成しないで OK【期待感 F】自動生成部分の品質は担保済みであり,テスト不要【期待感 G】保守不要【期待感 H】いつでも, 手軽に製品も使い続けることができる【期待感 I】製品側で構成管理も含めては管理してくれる為,不要【期待感 J】海外製品も自由に利用できる【期待感 K】個人情報の管理も楽になる【期待感 L】海外製品も無料で利用可能, コストを抑えることが可能【期待感 M】顧客要望をすぐに取り込める為,要求仕様の適合は高い
上記以外の期待感を選択した件数
計

4.2

メトリクス 2 に対する結果
42
1092
150000011031

虎の巻の選択比率
100%0%
100%

第 38 年度（2022 年度）ソフトウェアプロセス評価・改善コース（No & Low-code チーム）
メトリクス 2 に対しては「有効であるとはいえない」という結果となった.それは, アンケートの「(7-2)デメリット」の選択肢にない項目が 2 件あり選択率が 100%ではなかった為である.一方でその他の 29 件については虎の巻の D 列「ノーコード・ローコード開発の失敗事例」と E 列「ノーコード・ローコード開発の留意点」に紐づいていることを確認でき,概ね網羅的に留意点は取り込めていると考える.結果は表 2.および「付録 4.
アンケート（デメリット）集計結果」を参照のこと.
表 2．ノー＆ローコード虎の巻のアンケート結果（デメリット）
ノーコード ・ローコ ード留 意点

件数【留意点 A】実現したい業務フローやユースケースを作成する必要がある【留意点 B】製品に合わせたビジネスモデルや業務フローを提案できる人がいること【留意点 C】利用する製品の SLA の範囲を認識しておく必要がある【留意点 D】データモデルや構造設計を明確に理解している必要がある【留意点 E】担当者の製品理解度はバラツキが出てきてしまうため,設計力のあるメンバを配置する必要がある【留意点 F】標準的な機能のみで要件は満たせるか確認する必要がある【留意点 G】すべてのテストが自動で実施されるものではなく,単体, 結合テストは実施する必要がある【留意点 H】ブラックボックスのテストまでしかできない為,保守に備え,ログ出力や調査要求などの契約が必要【留意点 I】互換性がなくなった場合のリスク対策が必要【留意点 J】製品の VersionUp 時に発生する影響の見極めが必要【留意点 K】販売実績のない製品や販売終了後のサポート有無が不明な場
合, 製品が使えなくなるリスクを踏まえた上で採用する【留意点 L】複数人で開発する場合は構成管理を実施する必要がある【留意点 M】海外の製品を利用する場合は, 使用許諾を十分理解し, 許諾を遵守する必要がある【留意点 N】海外の個人情報については, 各国の法令を遵守し, 現地のサーバーで管理する【留意点 O】有料プランを利用する際は, 逆にコストが高くなる場合がある. また,自由度がない分, 逆に改造の手間がかかりコストが高くなる可能性がある【留意点 P】高度あるいは特別な要求・品質確保に 100％対応できるもの
ではなく, 知識・期間の範囲内で,要求対応・品質確保を行うことを前提にしていることを, ステークホルダーと合意できている
その他
計

102

虎の巻の選択比率
94%0051000000000202316%
100%

4.3 メトリクス 3 に対する結果
メトリクス 3 に対して 16 項目中 13 項目は「有効」（基準値 7.5 点以上）,3 項目は「有効であるとは言えない」（基準値 7.5 点未満）という結果となった.
結果については表 3.および「付録 5.虎の巻集計結果」を参照のこと.

5

第 38 年度（2022 年度）ソフトウェアプロセス評価・改善コース（No & Low-code チーム）
表 3．ノー＆ローコード虎の巻の留意点のアンケート結果
23450点 5点点0点0点

2740009.42380008.73 利用する製品のSLAがどの範囲となっているか認識しておく必要がある。

2270018.2

4 データモデルや構造設計を明確に理解している必要がある。

17112007.3

2053037.4

2361018.42232047.6

2080037.79 互換性がなくなった 合のリスク 策が必要。

2360018.4

10 製品のVersionUp時に発生する影響の見極めが必要。

2360018.4

11 販売実績のない製品や販売終了後のサポート 無が不明な 合、製品が使えなくなるリスクを踏

2162017.8

12 複数人で開発する 合は構成管理を実施する必要がある。

2280018.4

13 海外の製品を利用する 合は、使用許諾を 分理解し、2260028.12052037.3

2080037.72191008.3#

1

ノーコード・ローコード開発の留意点
1 ノーコード開発であっても、実現したい業務フローや点数ユースケースを作成する必要がある。
2 従来の開発と同等に製品に合わせたビジネスモデルや業務フローを提案できる人がいること。

（例：同じ意味で異なる名称のデータがあると、複雑になる）
5 担 者によって製品理解度はバラツキが出てきてしま ため、それなりの設計力のある ンバを配置する必要がある。
6 パッケージに標 的に わっている機能のみで要件は たせるか否かを確認する必要がある。
（ たせていない 合は、それなりの要員を配置する必要がある）
7 す てのテストが自動で実施されるものではなく、単体、 合テストは実施する必要がある。
8 ブラックボックスのテストまでしかできない為、障害発生する恐れがある。よってに えて、ログ出力や調査要求などの契約が必要。

まえた上で採用している。もしくはそのよ なソフトは選定の 象外としている。

許諾を遵 する必要がある。
14 海外の個人情報に いては、 国の法令を遵 し、現地のサーバーで管理する。
15料プランを利用する際は、逆にコストが高くなる 合がある。
また、自由度がない分、逆に改造の手間がかかりコストが高くなる可能性がある。

16 高度あるいは特別な要求 品質確 に100％ 応できるものではなく、知識 期間の範囲 で、要求 応 品質確 を行 ことを 提にしていることを、ステークホルダーと合意できている。

5.

考察
アン ケ ー ト の数 値 結 果 だけ で は 分 から な い 定 性的 な 評 価 を行 う た め , ア ン ケ ー ト回 答者の 意 見 を元 に , 留 意点 に対 し て の理 解 度 やア ンケ ー ト 数値 の 裏 付け につ い て 考察 し た .
なお,本考察を踏まえて「付録 7.改訂版ノー＆ローコード虎の巻」を作成した.
5.1 メトリクス 1 に対する考察「ノー＆ローコード虎の巻」がノーコード・ローコード開発の期待感の網羅性について「有効」と なった理 由は ,SWEBOK の知識 領 域を軸に, 研究員が 所属 する組織の事 例や ,他の研究会へのヒアリング ,書籍から期待感を十分に抽出することができたためと考える .
特に SWEBOK の選定については PMBOK,SQuBOK,ISO/IEC25000 など様々な知識体系がある中で設計・実装に関する観点を重点的に押さえることが必要だと考えて採用したことが有効に繋がったと考える.
また ,ア ンケ ート の結 果 ,選 択比 率の 最も 高い 項 目「 開発 期間 の削 減」（ 39% ）に つい て被験者の期待感を考察する.
こ の「 開 発 期 間の 削 減 」 につ い て , コ メン ト 内 容 から 確 認 し たと こ ろ , 数 的内 訳 と して「設計・実装の削減」9 件,「プロセスの削減」1 件,「要件定義の期間短縮」1 件であった（「付録 3.アンケート（メリット）集計結果」参照）.これより,「設計・実装の削減」
について,より踏み込んだ留意点（例：プロジェクトの大小や特徴,設計実装の各 WBS,開発プラットフォームやツールごとの留意点）を充実させることで ,より虎の巻を有効活用
6

第 38 年度（2022 年度）ソフトウェアプロセス評価・改善コース（No & Low-code チーム）できると考える.
5.2 メトリクス 2 に対する考察
ノー＆ローコード虎の巻がノーコード・ローコード開発の留意点 の網羅性について 16
件中 2 件が留意点のリストに属さず「有効でない」となった理由について考察する.2 件のコメント・考察は以下の通り.
#1 「 上流 工 程 （ 業 務要 件 や シス テ ム 化 要 件） が 理 解出 来 て い な いと ノ ー コー ド ・ ロー
コードでも意味がないと思われる」
これは,実際には留意点には「従来の開発と同等に製品に合わせたビジネスモデルや業務フローを提案できる人がいること」と記載していたものの ,留意点のリストから選択されていなかった.これは,留意点を十分理解してもらえなかった可能性がある .留意点には,前提条件や利用場面の具体例追記など,もっと分かり易い記載にする必要があった.
#2 「 開発 費 削 減 の 恩恵 は 誰 が受 け る の か ？原 価 低 減し た 分 が そ のま ま 販 売価 格 低 減になっ た ら 開発 側 に メリ ット は 無 い .開 発 に 向く が ,余 程 ル ール を し っか りし な い と稼 働 後保守には向かない」#2 については,2 つの問題を指摘していると考える.1 つ目はノーコード・ローコード開発の効率が上がったとしても,利益にならないということである.対策として,ノーコー
ド・ローコード開発の見積については ,工数以外（利用者への提供価値など）で示すなどの検討が必要と考える.2 つ目は開発効率化しても保守作業にしわ寄せがいくといったもの.これについては,開発だけでなくプロダクト全体の効率を上げるために ,Dev/Ops の概念などで,設計者と保守要員が歩み寄り,保守作業の効率化を検討する必要がある.
アンケートの結果,デメリットと感じているものが最も多かったものは「 製品仕様が業務にマッチしなかった」（45%）であった（「付録 4.アンケート（デメリット）集計結果」
参照 ） .こ れに 紐 づい た チェ ック 項 目 が 最も 多 かっ たも の は「 #1 ノ ーコ ード 開 発で あっても,実現したい業務フローやユースケースを作成する必要がある 」であった.これは,製品仕様が業務にマッチしない要件レベルの 実現可否を見極める為の留意点であったが,実際は製品仕様にマッチさせるための技術的な設計・実装面での留意点を記載 してほしいとの意見もあった.一方で,各社のローカルルールが問題である可能性があり,留意点として汎用的かつ効率的な業務フローに見直すことも含めるべきであると考える .
5.3 メトリクス 3 に対する考察
アンケートの結果,16 件中 13 件が「有効」であったため,ノーコード・ローコード開発における留意点としては概ね活用できるものと考える.このうち点数が最も高い項目は#1の「ノーコード開発であっても ,実現したい業務フローやユースケースを作成する必要がある」で,9.4 点だった.「ノーコードはあくまで「具現化するのに従来よりも簡単であること」がメリットであり,そこに緻密な整合性を取らねばならないような要件が有る限りは,その業務要件調整・整備は無くならない」という意見があった.これは,最大限にメリット を 得 るた め に は ,製 品仕 様 に 業務 要 件 を合 わせ る 調 整が 必 要 であ り ,業 務 要 件と 合 わ
ない場合は立ち止まって冷静に判断する必要があるものであり,有効なチェック項目であったと判断できる.
一方で,点数が基準値 7.5 点を満たさない(「効果あり」とは言えない）3 項目について理由を以下に挙げる.
留 意 点 #4 「 デ ー タ モ デ ル や 構 造 設 計 を 明 確 に 理 解 し て い る 必 要 が あ る 」 に つ い て ,「小 規 模 な開 発 時 には 当て は ま らな い 」 の意 見が 複 数 あっ た も の .こ れは , 小 規 模の 開 発
であれば設計を意識しないでも ,提供されている機能で開発可能というツールの良さの部分について言及されたものであり,大規模開発や複雑な開発では前提条件を補足することが必要であったものと考える.
留意点#5「担当者によって製品理解度のバラ つきが出てしまうため,それなりの設計力のあるメンバを配置する必要がある」について,「設計知識よりも製品知識の方が重要」
7

第 38 年度（2022 年度）ソフトウェアプロセス評価・改善コース（No & Low-code チーム）という意見があったもの.これは,設計力があったとしても製品の理解がない場合 ,設計不良の問題を引き起こした事例があり,製品仕様についても留意点を補記が必要と考える.
留意点#14「海外の個人情報については,各国の法令を遵守し,現地のサーバーで管理する」 に つ いて , 「 個 人情 報と 法 令 の関 連 が 分か らな い 」 とい う 意 見が あり , 理 解 しづ ら い
留意点となっていた.また「日本か海外かデータの置き場所が重要」といった意見もあり ,海外製品を利用する際の法令と,データの置き場所についても追記が必要と判断する.
6. まとめ6.1 研究成果まとめ
本研究では, ノーコード・ローコード開発への期待感を鵜呑みにせず ,適切に開発・保守を準備できるようにすることを目的とした.
こ れに 対 し て , 実験 結 果 , 考 察に よ り 「 ノー ＆ ロ ー コー ド 虎 の 巻」 が 開 発 保守 の 留 意点を網羅的（量的）かつ内容的（質的）に概ね満たしており ,開発前に適用することで適切に開発・保守の準備ができることを確認できた.理由として, SWEBOK の知識領域を軸に,研究 員 が 所属 す る 組織 の事 例 や , 他の 研 究 会へ のヒ ア リ ング , 書 籍 など から 期 待 感を 十 分に 抽 出 す る こ と が で き た こ と で あ る . と り わ け ロ ー コ ー ド 開 発 の 留 意 点 と し て ,10 点 中9.4 点の高得点を得た「ノーコード開発であっても ,実現したい業務フローやユースケースを作成する必要がある」など,16 項目中 13 項目が基準値以上の評価を得ており,ノーコード・ローコード開発の有効な留意点として十分な成果があると考える .
一 方 で, 被 験 者 が 考え る デ メリ ッ ト の 一 部が 留 意 点と し て 網 羅 的に 挙 げ られ な か ったことや, ノーコード・ローコード開発ツールの採用で開発効率が向上したとしても ,そのまま利益に繋がる訳では無い点や ,保守要員にしわ寄せが発生するというデメリットに対する留意点が挙げられなかったことが課題である .今後はノーコード・ローコード開発の見積につい ては ,工数以 外（利用者 への提 供価 値など）で 示すな どの 検討 や ,Dev/Ops の概念により設計者と保守が連携して開発工程全体のライフサイクルを検討する必要がある.
今後システム開発はよりスピード感を持った対応が必要になっていき ,ノーコード・ローコード開発はその有効な手段の１つであ る.ノー＆ローコード虎の巻を活用することで，短期間かつ高品質なシステム開発の実行を確実に支援していくことが期待できる.
6.2 今後の展開
6.1 章で挙げたように,以下の課題が残っており,今後も「ノー＆ローコード虎の巻」のブラッシュアップが必要であると考える.
(1) 虎 の巻 の 内容 の 誤 解に よ り ,被 験 者が 考 え る デ メ リッ ト の一 部 が 留意 点 に含 ま れていないと判断されたため,留意点の誤解防止につなげるよう前提条件を補記するなど記載内容を工夫する.
(2) ノ ーコ ー ド・ ロ ー コー ド 開発 の メリ ッ ト から 生 じる , 新 たな デ メ リッ ト （保 守 工程のシ ワ 寄せ , 利 益獲 得 に つな が らな い ）に 対 し ては , 工 数以 外 （利 用 者 への 提 供価 値 など ）で示すなどの検討や,Dev/Ops の概念により設計者と保守が連携して開発工程全体のライフサイクルを検討し,虎の巻の留意点に含めていく.
ま た ,仮 説 と ア ンケ ー ト で 立証 さ れ た もの の , 実 際 の開 発 保 守 現場 で の 効 果は 確 認 でき
てい な い ため , 今 後 各研 究員 の 職 場で 利 用 し ,実 効果 の 検 証と 新 た な留 意点 を 収 集し 更 新していくことで「ノー＆ローコード虎の巻」の完成度を上げていく .
参考文献[1] 森岡 修一，基礎から学ぶ ノーコード開発，C＆R 研究所,2021/3/17[2] 木村 初夫,CMMI 導入の為の GQM 手法による測定データの研究,SQiP 研究会,2004/[3] ソ フ ト ウ ェ ア エ ン ジ ニ ア リ ン グ 基 礎 知 識 体 系 ―SWEBOK V3.0, オ ー ム社,2014/11/25
8