2022年5月16日イベント「データモデリング＆ローコード開発ライブ」が無事に終了しました。JUAS関係者の皆様と、司会の（株）プライドの三輪様、そしてローコード開発コミュニティスタッフの皆様、ありがとうございました。
イベント自体は会場で実施し、聴講者がライブでオンライン参加というハイブリッドな方式も良かったです。
また、当日の動画が公開されました。（7月末までの限定とのことです。）
HOIPOIの古関様から、詳細な目次情報をいただいたので、ここにも掲載します。古関様、ありがとうございます。
00:00:01 ご挨拶
00:01:35 今回開発するテーマの募集
00:02:22 登壇者、参加企業の紹介
00:08:02 今回開発する業務システムの決定（参加者投票により決定）
00:19:30 仮資材リース業向け配車管理システムに決定。
00:22:19 渡辺幸三氏によるデータモデリングの開始
01:02:04 データモデリングの終了と、各社の実装開始
01:02:10 JUAS 姉川様よりご挨拶
01:03:55 ローコード開発コミュニティ 樋山様よりご挨拶
01:06:38 各社の実装状況の中継
01:50:25 各社の実装終了 発表方法について説明
01:50:25 各社の実装終了 発表方法について説明
01:51:57 発表企業１．株式会社HOIPOI ツール名：TALON（タロン）
02:04:33 発表企業２．キヤノンITソリューションズ株式会社 ツール名：WebPerformer(ウェブパフォーマー)
02:18:22 発表企業３．株式会社ジャスミンソフト ツール名：Wagby(ワグビィ)
02:31:17 発表企業４．サピエンステクノロジー・ジャパン株式会社 ツール名：Sapiens eMerge(サピエンスエマージ)
02:44:15 発表企業５．有限会社ディービーコンセプト ツール名：X-TEA(エックスティー)
02:58:04 発表企業６．株式会社ウイング ツール名：GeneXus(ジェネクサス)
03:09:55 発表企業７．株式会社bluememe ツール名：OutSystems(アウトシステムズ)
03:22:40 本日の総括と終了のご挨拶
私は実演者として参加しましたので、当日の経験から、2022年現在のローコード開発ツールの印象を書きます。
業務アプリケーション開発は、データモデルが起点
どのツールも「テーブル設計」から「UI」が自動生成され、これをベースに「業務ルール」を加えていくというアプローチでした。
もともと、このイベントは共通のデータモデルを使って各社ツールがどのような実装をするのかを比較できること、という主旨がありました。ツールによって設計情報の書き方は異なりますが、(1) テーブル設計 (2) UI (3) 業務ルール、という実装の流れは共通しているようでした。
では上流工程における「業務フロー」や「UI設計」というのは、どのように位置づけられるのでしょうか。
私見ですが、ものづくりを行う前に整理する業務フロー設計（現状 AsIs の確認もしくは将来像 ToBe の設計）も、UIの設計も、データモデルを導くための補助線だと認識しています。
業務経験があれば、当日イベントの渡辺氏のように、ユーザヒアリングから直接、データモデルを導くことも可能だということが示されました。ただ現場で、いきなりこのレベルを求められるのも大変でしょうから、業務フロー設計やUI設計から「入る」というのは間違いではありません。
業務フローでもUIでも、最初にざっくりと全体の概要をつかんで、そこからたたき台となるデータモデルを導くようにします。そのデータモデルは、業務フローとUIを実現するベースになりますので、このタイミングで開発ツールに設計情報として与えれば、すぐに動作確認できます。あとはこのサイクルを繰り返して、精度を上げていきます。
つまり
業務フロー設計 or UI 設計 > データモデル > 開発ツールへ入力 > 動作確認 > 課題の洗い出し
を一連の手順とし、これを何度も繰り返すというスパイラル型の開発が可能です。
さらに、この過程で「用語辞書」「CRUD表」「権限表」といった副産物がツールによって自動生成され、これらが矛盾なく維持されることも期待できます。
これだけの設計情報が統合管理されるなら、「テストデータ自動生成」「E2Eテスト」「負荷テスト」「ユーザ向けマニュアル生成」までもツールが支援してくれることを期待したくなります。
さらに、ビルドしたアプリケーションを検証環境、本番環境に転送し、日々の運用のパフォーマンスを測定するということまでも面倒みてもらえるといいですね。
もちろん当日のイベントではここまで広範囲な話はできませんでしたが、業務アプリケーションという分野に限れば、いずれのツールも目標としているラインは同じではないか、と感じたところです。
開発現場の DX は、どうなっている？
ところで開発現場の進め方が10年、20年前のアプローチから変わらなければ、これらのツールの使い所はかなり限定されます。一言でまとめるなら「Excel で設計書を作成している限り、ツールの導入効果は期待できない」です。
従来型の開発アプローチを見直し、ツールを活用することは、少人数での大規模基幹システム開発につながります。かつ内製チーム主体で進めることもできます。つまり「丸投げ」と「多重下請け構造」を変えられるのです。私にとっては、これが開発現場の DX です。
このイベントの動画閲覧をきっかけに、開発現場の DX というテーマについても是非、真剣に議論していただければと願っています。
