第八講大規模統合システム構築プロジェクトに、ノーコーディングソリューション適用の可能性　

[PM]

博士、産業現場の実務で使用されるアプリは、今日作ってみたように単純なプロセスだけを含んでいるものではないでしょう。特に、大企業や公共機関で不特定ユーザー集団を対象にアプリサービスを提供するプロジェクトでは、少なくとも数十個、多くは数千個のプログラムモジュールで構成される膨大なシステムを開発する場合が多いと思われます。このような規模の大きいプロジェクトでもノーコード技術を組み合わせることが可能でしょうか。

[博士]

スマートメーカーソリューションは初期にPC Windows環境で、ERP、CRM、SCMなどの基幹系システムを設計·具現化する作業を最適化するために設計され、実際に数多くの実務現場プロジェクトに適用されました。一般的にこのような統合システムは、単位プログラムモジュールが2,000以上7,000個に達するほど膨大な場合が多かったのです。このソリューションは10年以上このような大規模統合システムを設計および運営事業に適用してきたため、十分に検証されたシステムだと言えます。

ただしIT運営環境がモバイルに変わり、最近6~7年でスマートフォンやタブレットなどモバイル環境にも最適化されるよう再設計して開発した新バージョンが、現在の「スマートメーカー」ソリューションといえます。

このセミナーは、すでに様々なプログラムツールを活用して、多くのアプリ開発プロジェクトを遂行した経験のある技術者を対象に行うセッションです。最近ホットイシューになっているノーコード技術についての話はよく聞いていましたが、実際にその概念やプログラムの実装手続きと方式を多少漠然と考える技術者の方々のために設けられたセミナーです。

複雑な業務処理機能やプロセスを事例として挙げて説明すると、ノーコード技術そのものや開発プロセスよりは具現化する対象だけに注目が集まる可能性があり、わざと非常に簡単なアプリの事例を挙げて説明しただけです。

このセミナーは、すでに様々なプログラムツールを活用して、多くのアプリ開発プロジェクトを遂行した経験のある技術者を対象に行うセッションです。最近ホットイシューになっているノーコード技術について話はよく聞いていましたが、実際にその概念やプログラムの実装手続きと方式を多少漠然と考える技術者の方々のために設けられた席です。

したがって、複雑な業務処理機能やプロセスを事例として挙げて説明すると、ノーコード技術そのものや開発プロセスよりは具現化する対象に注目が集まる可能性があり、わざと非常に簡単なアプリの事例を挙げて説明しただけです。

先ほど私たちが一緒に作ったサンプルプログラムの製作過程ですでに確認しましたが、人工知能技術を採用したノーコーディングソリューションである「スマートメーカー」で開発プロジェクトを行う場合、C、Javaなどの伝統プログラム言語で開発する手続きや方法とは全く異なります。

以前は作業に着手すると、まずDBテーブルを設計する作業から始めました。しかし、スマートメーカーで開発する場合、プログラムの入出力画面つまりフォームからデザインし始めることになります。全てのフォームをデザインしておくと、逆にそのフォームを人工知能エンジンが解析し、作ろうとしているアプリに最適化された構造のDBテーブルを設計し、生成する作業まで自動処理するという方式を採用しています。

したがって、大規模なアプリ開発プロジェクトを進める場合でも、対象業務プロセスを分析し、必要なフォームをすべてデザインする作業から行います。フォーム作業が終わると、人工知能エンジンがこれらのフォームの内部を分析し、DB設計に必要なスキーマ情報を抽出し、設計図のERDも自動で作成し、DBテーブルまで自動生成します。

人がこんな作業をするなら、多数のDB専門家が多くの時間を投資するのに対し、遂行する作業を人工知能エンジンは、瞬く間に処理します。

もしデザインしたフォームのうち、一部の機能や処理項目を変更または追加しなければならない場合でも、フォーム作業別途、DBテーブル作業別途にする必要が全くありません。先ほどご覧になったように、変更するフォームだけ修正すれば、このような変化した内容を自動認識して、関連するDBテーブルと属性はもちろん、プログラム機能まで全て一括して変更するからです。

従って、開発の範囲が広く、具現化するモジュールが多い大規模プロジェクトほど、以前の手作業コーディング方式で具現化する場合に比べて、非常に高い生産性と正確性を発揮できるようになります。

特にスマートメーカーソリューションでプロジェクトを遂行する場合、従来、人が手作業方式で設計するより、最適化された構造のデータベースを設計できます。それゆえDBサーバーの負荷と保存スペースも最小限に抑えられ、大規模ユーザー集団を対象にサービスする場合でも、よりスピーディーな検索サービスが提供できます。

これまではCや、Javaでアプリの内部で動作する機能や画面UIなどを実装する際、コーディング作業の基礎情報がDBテーブルだったといえます。したがって、プロジェクトに着手すると、真っ先に遂行する作業がDBテーブルの設計でした。

該当プロジェクトを通じて作り出すすべてのプログラムモジュールの構成と各モジュール別に組み込まなければならない全体機能が具体的に定義される前に、開発する対象業務を大まかに把握した状態で、人々がDBテーブルを設計せざるを得なかったのです。

そのため、このアプリを実際に運営すると、どのようなデータがいつ、どのような方法とどのような体系で発生し、またこの過程で蓄積されたデータをどこに、どのように使われるのかを正確に把握できない状態で、該当アプリを構成する核心要素であるDBテーブルを設計してきたのです。

このように貧弱な情報をもとに遂行したDB設計は、各アプリの機能や特性、および運用する現場の状況よりも、当初RDBという革新的な技術を創案したコッド博士の9つの原則、つまり純粋な情報工学的基準によって設計されることが、ほとんどでした。

データの重複保存の防止や、データの正規化及び非正規化などの基本原理に忠実であることにより、当然一貫した一つのテーブルや体制で管理されるべき情報も、破片的に分化された多数のDBテーブルで管理されるように設計されている場合が多いのです。

これにより、実際にプログラムモジュールを実現する段階でも、プログラム内部が必要以上に複雑になり、コーディングでカバーしなければならない作業量も幾何級数的に増え、自然にエラーの発生も多くなります。

それだけでなく、些細な検索機能や出力物、報告書作成機能一つを具現化する場合にも、多数のテーブルをJoinしたりUnion処理しなければならず、そのようなQuery操作だけでは手に負えず、破片化した数多くのフィールドをまとめてビューテーブルを作らなければならないなど、DBサーバ装置の過負荷やストレージ空間の浪費、ネットワークのトラフィック暴走、深刻な検索速度遅延などの構造的な問題を引き起こす直接的な原因となった場合も多かったのです。

しかし、スマートメーカーが提供する人工知能エンジンを活用してプロジェクトを行う場合には、該当アプリを使用する実務現場ですでに使用している様々な形の書式や帳票、文書などを参照しながら、誰でも簡単に作れるフォームからデザインするようになります。フォームは誰でも直観的に理解できるもので、コーディング技術がない人も、システム分析および設計経験が全くない人も簡単に作れます。

このようなフォームには、アプリ開発に必要な4大中核要素、すなわちデータ、UI/UX機能、イベント、プロセスに関連するすべての情報を含んでいます。そこでスマートメーカーではフォームから描くように設計されているわけです。

このように人がすべてのフォームをデザインしたら、人工知能エンジンがそのフォームを分析して、DBテーブルを構成するのに必要なスキーマー情報を抽出し、実際のDBテーブルまで設計することで、データが発生して使われる状況をまず反映した後、情報工学的正規化の論理まで十分に反映したデータベース構造を実現できるようにします。