開発の種類

ここでは、開発手法にはどのようなものがあるかを確認し、作りたいアプリケーションをどのようなユーザやタイミングで使うかを把握したうえで、最適な開発手法を選択できるようになる事を目的とします。

開発手法には、主に ノーコード開発・ローコード開発・プロコード開発（スクラッチ開発） の3つの種類があります。これらを組み合わせることにより、それぞれの強みを補完し、開発スピード・柔軟性・品質・コストなどの最適化につながります。

3つの開発手法の特徴

方式	強み	向いている領域
ノーコード	誰でも使用可能、高速な開発	画面、簡易ワークフロー、マスタ管理など
ローコード	柔軟性と拡張性の両立が可能	中程度のロジック、業務アプリなど
プロコード	高度処理、高い自由度	システム連携、大規模処理、高度な要件など

intra-martにおける、3つの開発手法のそれぞれのメリットを詳しく見ていきましょう。

ノーコード開発

プログラミング不要で構築できる開発手法です。主に業務部門での内製化を想定しています。
intra-martでは、主に以下のようなツールがあります。

• IM-Workflow： 申請・承認のフロー（プロセス）や案件の状態管理、履歴、承認ルートの制御を行うワークフローエンジン
• IM-FormaDesigner： Webブラウザ上でドラッグ＆ドロップにより、申請・参照・一覧などのフォーム画面を作成するノンプログラミング向けツール
• IM-BIS： IM-WorkflowやIM-FormaDesignerを拡張し、業務プロセス設計・画面作成・外部連携・運用管理を一体で支援する、ノンプログラミング寄りの統合開発環境

利用領域	構築例	使用機能
ワークフロー作成	経費精算、稟議、押印フロー	IM-Workflow
フォーム作成	申請フォーム、アンケート、チェックリスト	IM-FormaDesigner
帳票作成	PDF帳票デザイン	IM-FormaDesigner、IM-BIS、IM-PDFDesigner、IM-Spreadsheet　など
軽微なデータ管理	マスタ・コード管理	IM-FormaDesigner 、IM-BIS

向いている領域

• シンプルな承認フロー
• 定型画面
• 業務部門が主体となる軽易な業務改善

コラム

IM-BISやIM-FormaDesignerを使えば、画面やフローの定義、申請/承認のシーケンスなど、基本的な業務ワークフローはコーディング不要で構築できます。ただし、要件によってはカスタム実装（コード）が必要になることがあります。
例：

• 外部システム連携や特殊なバリデーション、独自ロジックをサーバー側で実装する必要がある場合：プラグインやJavaクラスなどの拡張
• UI上で提供されていない細かい動作制御やカスタムコンポーネントが必要な場合：JavaScript/JSSPやVueなどのカスタム実装
• 標準機能でカバーされない権限や組織検索などの特殊要件

ローコード開発

GUIベースの設計に加えて、一部ロジックの補完をコードで行う開発方式です。
intra-martでは、主に以下のようなツールがあります。

• IM-LogicDesigner： ビジネスロジックをGUI操作で簡単に作成可能。REST APIとして外部からの呼び出しなども可能
• IM-BloomMaker： Webアプリケーション画面をエレメント（部品）ベースで作成可能。FormaDesignerよりもUIの自由度が高く、テンプレ管理や複数画面の効率開発に向く
• IM-Repository： 業務で使う「メタデータ（辞書・列挙・エンティティ）」を集中管理するための機能。項目名や物理名、制約、選択肢、エイリアスなどを定義・管理して、複数アプリケーションで一貫性のあるデータ定義を使用可能に
• Accel Studio： intra-mart Accel Platform上で動作するアプリケーションを統合的に開発・管理するためのツール

利用領域	構築例	使用機能
承認ルール	組織階層・金額条件による承認制御	IM-LogicDesigner
BPM（プロセス統合）	異なる複数のシステムを管理・最適化	IM-BPM
データ処理	自動更新処理やデータ整形	ジョブスケジューラ、IM-LogicDesigner、IM-BIS（BISフロー） など
画面カスタマイズ	標準画面の部分的な拡張	IM-BloomMaker

向いている領域

• 一部ロジックが必要な業務
• 外部システム連携
• ノーコードで表現しきれない中規模機能、UIデザイン

コラム

ローコード開発とノーコード開発で使うツールは、用途が似ているものもあります。では、どのような場合にどのツールを使えば良いでしょうか。
選定のポイントを下記にまとめました。

• 非開発者で簡単にフォーム作り：IM-FormaDesigner
• UIをもう少し自由に作りたい/テンプレートで再利用したい： IM-BloomMaker+IM-LogicDesigner
• 承認・ガバナンス・外部連携を重視：IM-BIS（FormaDesigner/Spreadsheet併用）
• 明細/Excelライクな運用：IM-Spreadsheet
• 帳票出力が主目的：IM-PDFDesigner/IM-X Server

ローコード開発とノーコード開発の違いについては、こちらのページで詳しく解説しております。
　IM-Press　ローコード開発・ノーコード開発の違いは？導入の注意点も紹介
　ローコード開発コラム　ローコード開発とノーコード開発の違いは？ローコード開発はどう役立つのか？

プロコード開発

高度かつ自由度の高い開発方式で、大規模・高難度要件に対応します。
プロコード開発の際は、運用開始後に対象プラットフォームをアップデートしても影響を受けにくい方法を考慮しましょう。

基本方針

• 標準コード/配布物を直接改変しない：アップデートの上書きでカスタマイズが消える・競合することを防ぐため
• 拡張点・公開APIで実装する：内部実装に依存すると将来の変更で壊れやすいため
• モジュール化して依存関係を明示する：展開順や互換性を制御できるようにする

カスタマイズは、標準モジュールを直接触らず、ユーザモジュール化して公開API/拡張点で実装します。固定値や設定はプロパティファイルやDBなど外部に置き、WAR内部に置かないようにします。
また、アップデートは必ずテスト環境で検証し、バージョン管理とデプロイ手順書、バックアップとリカバリ手順を整備しておきます。
この方法により、標準モジュールがアップデートされても、ユーザモジュールは別途上書き・拡張できるので、再デプロイ時の上書きを管理できます。

参考

intra-martのプロコード開発におけるモジュールについての詳細は、下記のドキュメントも参考にしてください。
ユーザモジュール開発ガイド

プロコード開発の分類

イントラマートにおけるプロコード開発の観点は、主に下記のように分類されます。

1. サーバサイドJava開発（J2EE）：サービス/コントローラ/プラグイン/バッチなどの実装（.java、Jar、クラス）
   • 製品の拡張や高度な処理、外部ライブラリ利用、型安全な実装が必要な部分はJavaで行うのが主流
2. スクリプト開発（SSJS/スクリプト開発モデル）：JSSP（サーバサイドJS）、LogicDesignerのスクリプト、FormaDesigner上のイベントスクリプトなど
   • ローコード領域であるintra-martの“スクリプト開発モデル”に該当。素早い画面・業務ロジック実装に便利。ただし静的解析やビルド概念は弱い
3. API/インテグレーション（REST/SOAP　など）：REST APIの設計・実装・公開、外部API連携、認証・セキュリティ、モック・契約（OpenAPI）など
   • サービス間連携やフロントエンドとの接続点として重要。RESTは「開発の種類」というより“インタフェースの開発領域”に相当。
4. フロントエンド（クライアント）開発：HTML/CSS/JavaScript、SPA（React/Vue　など）、静的資産（csjs/cshtml　など）の作成・調整、ブラウザ互換対応
   • 画面のリッチ化やUX改善、クライアント側でのバリデーションや非同期処理の実装を担う
5. モジュール構成/パッケージング（eBuilder/im-Juggling/IMM/WAR）：eBuilderでのモジュール構成、imm作成、im-Jugglingによるユーザモジュール管理、WAR生成・展開ルールの設定
   • コードを適切な場所に置き、期待する優先順で読み込ませるための作業。開発そのものより“配布・デプロイ”に関する重要作業
6. データベース開発（スキーマ・SQL・マイグレーション）：SQLファイル、クエリ定義、テナントDB設計、マイグレーション、パフォーマンスチューニング
   • アプリの核となるデータ構造変更や大量データ処理は別領域で管理する必要があるため
7. インフラ/運用自動化（CI/CD、ビルド、デプロイ、監視）：Jenkins/GitHub Actionsなどでのビルド、imm/WAR自動生成、テスト自動化、デプロイ手順、ログ・監視設定
   • 安定運用・リリース効率化のため利用。スクリプト開発は「ビルド概念」が薄いが、E2EテストやAPIテストはCIに組み込める
8. テスト自動化/品質（ユニット/E2E/静的解析）：JUnit（Java）、サーバサイド単体テスト（imのAPI経由）、SeleniumやAPIテストによるE2E、静的解析ツール
   • 品質確保。スクリプト開発は静的解析が制約される点に注意（動的言語のため）

参考

e Builder for Accel Platform とは、intra-mart Accel Platform 上で動作するアプリケーションを効率的に作るための統合開発支援ツールです。Eclipse をベースにしたプラグイン群で、業務テンプレートや雛形、デバッグ支援など開発に便利な機能を提供します。
業務テンプレートや専用プラグインを活用することで、画面・ワークフロー・テーブルなどの定義作業を短時間で行えるほか、開発用デバッグサーバにより単体開発や動作確認も容易に実施できます。また、Java（TERASOLUNAなど）を前提としたカスタマイズ環境が整っており、独自ロジックの組み込みや拡張にも適しています。
特に、Javaを用いたカスタマイズや、テンプレートを利用した効率的な開発、デバッグサーバを活用した単体テストなどにおいて高い効果を発揮します。

e Builder for Accel Platformの詳細については、以下のドキュメントを参照してください。
e Builder for Accel Platform アプリケーション開発ガイド

向いている領域

• 高度な業務ロジック
• 大規模画面や複雑UI
• 高パフォーマンスが要求される処理

推奨されるカスタマイズ方法

intra-mart Accel Platformでは、すべての機能が「モジュール」単位で構成されています。
カスタマイズは、製品ソースを直接編集せず、差分をユーザモジュールにすることを推奨しています。

カスタマイズ方法の種類

カスタマイズの方法には、主に以下のような種類があります。

カスタマイズ方法	カスタマイズ対象	向いているケース
スクリプト開発モデル	画面・業務ロジック	画面・業務ロジックの変更、既存機能の軽微な振る舞い変更、バージョンアップ追随を重視したい場合
Plugin/拡張ポイント	フレームワーク拡張	イベントフック的な処理追加、標準拡張ポイントが用意されている機能の拡張 など
ServiceLoader	APIの内部処理差し替え	特定APIの内部ロジックを変更したい場合、Pluginでは対応できない低レイヤ処理 など
classes 配置（※非推奨）	Javaクラスの直接差し替え	ほかの方法では実現できない場合の一時的な回避、緊急パッチ・限定対応（恒常運用は避ける）

これらのうち、推奨方法である スクリプト開発モデルによるカスタマイズ、Plugin/拡張ポイントによる拡張、ServiceLoaderによるAPI実装の差し替え について、詳しく説明します。

パターン1：スクリプト開発モデル

イントラマートでは、製品標準ファイル（WAR直下や標準モジュール内のファイル）などの標準ソースは編集せず、カスタマイズ領域のディレクトリのファイルを差し替える方式が推奨されます。ディレクトリの読み込みは上位優先で行われるので、製品の再デプロイやパッチ適用時の上書きを最小化できます。

コラム

JSSP、クライアント静的リソース、Javaクラス、メッセージ/プロパティ、SQLプロパティなど、種別ごとに「どこに置くか」「どう上書きするか」が異なります。
スクリプト開発モデルによるカスタマイズについての詳細は、以下のドキュメントを参照してください。
製品カスタマイズ方法に関して - (4-1) スクリプト開発モデルでのカスタマイズ方法

ディレクトリ構成と役割

カスタマイズ領域のディレクトリは、スクリプト開発モデル実行時に src → product → compatible → platform のように、上位から順番にソースコードの検索が行われます。
カスタマイズしたファイルを、初めに読み込まれる「src」フォルダ配下に置くことで、製品本体に手を加えることなく、カスタマイズを反映することが可能となります。

ディレクトリ	役割	カスタマイズ可否
jssp/src	独自開発コード	◎（主に使用）
jssp/product	製品 / 拡張機能	△
jssp/compatible	互換用モジュール	△
jssp/platform	iAP本体	×（直接修正しない）

パターン2：Plugin（拡張ポイント）

intra-martが用意している、公式の拡張ポイントに処理を差し込む（プラグイン化する）方法です。設定ファイルで拡張処理を定義し、本体コードを一切変更しないのが特徴です。
拡張ポイント（extension point）とは、製品が用意した「差込口」です。拡張ポイントIDごとに受け入れ可能なプラグイン（処理）が決まっています。
カスタマイズは「プラグイン（Javaクラス）を作成」→「plugin.xmlで拡張ポイントに登録」→「WEBアプリに配置して再起動」で有効になります。
ワークフローの処理対象者プラグインや代理設定など、多くの機能は拡張ポイント経由で差し替え・追加できます。

基本的な手順

1. 拡張ポイントIDを特定する
   ドキュメント、またはアプリケーションの WEB-INF/plugin フォルダ配下（plugin.xml）で利用可能な拡張ポイント/プラグインIDを確認

• 例：ワークフローの処理対象者（動的承認）は jp.co.intra_mart.workflow.plugin.authority.node.dynamic、確認ノードは …node.confirm　など

2. Javaクラスを作成する
   拡張する処理に応じたインターフェースを実装または製品が用意する公開APIを利用する
   例（ワークフロー処理対象者プラグイン）：IWorkflowAuthorityExecEventListenerを実装するクラス

• 実装は可能な限り「ステートレス（状態を保持しない）」にする
  • staticやメンバ変数でSpring/Repositoryを持ち回すと予期しない挙動の原因になる

3. plugin.xml を作る
   通常の配置場所は WEB-INF/plugin/<拡張ポイントID>/<プラグインID>/plugin.xml
   plugin.xmlに拡張ポイントID、プラグインID、実装クラス名、パラメータ定義などを記載する

• 参考：pluginディレクトリ配下の既存plugin.xmlを参照

4. ビルド/配置
   実装クラスをWEB-INF/classes配下に置く（または JAR にして WEB-INF/libに置く）→plugin.xmlを所定フォルダに置く
   プラグインの読み込みは起動時に行われることが多いので、アプリケーションコンテナ（例：Resin/Tomcat）を再起動して反映させる

5. ワークフローなどに紐づける（設定）
   プラグインを利用する対象（ノード/画面/処理）にプラグインIDを設定する（管理画面やAPIで設定、またはApplyManagerでDCNodeConfigModelsを作って適用）

• ワークフローではノード種別に応じた拡張ポイント（dynamic/confirm　など）を使うこと

6. 動作確認・ログ確認
   system.logをDEBUGにしてプラグイン呼び出しログを確認
   ワークフロー処理対象者プラグインなら、"[Listener]処理対象者展開ロジック開始、拡張ポイント…、プラグインID…" のようなログが出力される

• 非同期処理（到達処理）が絡む場合は、非同期タスク登録やスレッド実行関連のログも確認（登録後に実行されるまで時間差あり）

パターン3：ServiceLoader

JavaのServiceLoaderの仕組みを使用して、 APIの実装クラスそのものを差し替える方法です。
ServiceLoaderはJavaの標準機能で、インターフェース（または抽象クラス）を実装したクラスを、実行時に検出して列挙する仕組みです。
製品側がServiceLoaderを用いて実装を探索する仕組みであれば、標準の実装の代わりに独自の実装クラスを提供することで処理を差し替えられます。
APIの呼び出し元は変更不要な点と、実装のみを入れ替え可能な点に留意しましょう。
また、製品によっては複雑で差し替えが難しい部分があり、十分なテストが必要です。

参考情報：製品ソースを直接編集する方法（非推奨）

参考情報として、カスタマイズ方法の一覧表に記載した「パターン4：classesディレクトリによるJavaクラス差し替え」について説明します。

この方法は、Servletのクラスロード順序を利用し、「lib」より先に読み込まれる「classes」配下にクラスを配置して差し替える方法です。
製品クラスを直接置き換え可能ですが、直接の書き換えは、WARの標準的な再作成・配布フローから外れやすく、将来の再展開時に上書きされる可能性があり、保守リスクが高くなります。
他の方法では実現できない場合の一時的な回避や、緊急パッチなどの限定的な対応とし、恒常運用は避けることを推奨します。
原則はパターン1〜3＋ユーザモジュール化で対応してください。

カスタマイズファイルのユーザモジュール化（共通）

これまで説明したいずれかの方法でカスタマイズを行い、カスタマイズしたプロパティファイルをユーザモジュール化します。
モジュール化をすることで依存関係や対応バージョンを明確に管理でき、im-Jugglingを利用した自動展開および処理順序の制御が可能になります。
また、環境間での可搬性が向上し、より安定した運用が実現できます。

カスタマイズ対象となるモジュールには、必ず依存関係を定義する必要があります。依存関係を正しく設定しない場合、対象モジュールより先に別のモジュールが展開されてしまい、意図した上書き処理が行えないといった問題が発生する可能性がありますので、注意してください。

具体的な手順

1. 変更対象の製品標準ファイルをコピーし、eBuilderのユーザモジュール用プロジェクトへ配置

• 静的ファイル（HTML、画像、css、js　など）

  • 例: 画面の/mypage/index.htmlを変更する場合： src/main/webapp/mypage/index.htmlに置く

• JSP/JSSP　など

  • 例: src/main/webapp/WEB-INF/jssp/...または該当パスに配置

• Java クラス（製品標準クラスを差し替える場合）

  • 重要：差し替えたい Java クラス（パッケージ構成そのまま）を src/main/webapp/WEB-INF/classes/{パッケージディレクトリ}/に置く
  • 例: jp.co.intra_mart.foo.Barを差し替えるなら、コンパイル済.classをsrc/main/webapp/WEB-INF/classes/jp/co/intra_mart/foo/Bar.classに配置
  • 理由：WAR展開後、WEB-INF/classesに置かれたクラスはWEB-INF/libのJARより優先して読み込まれるため、上書きに使う

• plugin.xml など（プラグイン定義を上書きする場合）

  • 例: src/main/webapp/WEB-INF/plugin/<対象プラグインディレクトリ>/plugin.xml ただし展開順の関係で標準のplugin.xmlが優先されることがあるため、module.xmlに依存設定を行う（後述）

• META-INF/services（ServiceLoaderを使う差し替え）

  • 例: src/main/webapp/WEB-INF/classes/META-INF/services/に実装クラス名を記述

2. コピーしたファイルをカスタマイズする

3. カスタマイズしたファイルを含む製品モジュールを依存先として設定する（※展開順を保証するため必須）

• カスタマイズ対象が既存の製品モジュール（例：jp.co.intra_mart.im_workflow）を上書きするなら、module.xmlに依存を記載
  • 例（抜粋）： jp.co.intra_mart.im_workflow 8.0.20
  • 目的：ユーザモジュールの展開を標準モジュールより「後」にして上書きさせる（plugin.xmlなどの差し替えで必要）
  • 注意：依存の指定ミスや不足、文字コードやエンコード方式に留意する

4. eBuilderでimmをエクスポート

• e-Builder で該当モジュールプロジェクトを選択 → imm をエクスポート（プロジェクト単位でユーザモジュール出力）
• 出力された .imm（zip形式）を一旦解凍して中身を確認する
  • 確認ポイント：src配下の配置が正しくzip内に入っているか（特に WEB-INF/classesやWEB-INF/plugin）、不要な古いjarが混入していないか

5. IM-Jugglingでユーザモジュールとして追加してWARに含める

• IM-Jugglingの管理画面から「ユーザモジュール取り込み」→immを登録
  • 取り込み時にmoduleの依存関係やバージョンなどを確認（画面の案内に従う）
• IM-JugglingでWAR出力
  • IM-Jugglingに取り込んだユーザモジュールを有効化し、WARを出力（製品標準モジュールとユーザモジュールを併せて一つのWARにまとめる）
  • 出力されたWARを一旦解凍して、期待するファイルが展開先（WEB-INF/classes、WEB-INF/plugin、該当パス）に入っているか確認する
    • 例: WAR内にWEB-INF/classes/jp/.../Bar.classが存在するか、WEB-INF/plugin/.../plugin.xmlが任意の内容かなど

6. サーバへデプロイ（Resin）

• WARをサーバへ配置（例：resin deploy myapp.warまたはwebappsフォルダへコピー）
• サーバを再起動（またはアプリケーションリロード）して反映
• 反映直後はsystem.logを確認（起動時のplugin読込ログやWARNING/ERRORをチェック）

7. 動作確認

• 該当画面や処理を起動して、変更が反映されていることを確認
  • Javaクラスの差し替え確認には、差し替えクラスにログ出力を追加しておくと検証が容易

参考

製品内の特定の文章や表現を変更したい場合は、IM-Jugglingプロジェクトで実現可能です。intra-mart内で利用されている文章は基本的にはメッセージプロパティファイルに設定されています。製品標準と同じディレクトリ構成でカスタマイズしたファイルを所定の配下に配置することで、WAR作成時に取り込むことも可能です。

【IM-Jugglingに配置する方法】

1. カスタマイズを行いたい製品標準のメッセージプロパティファイルをコピーし、一旦、任意の場所に配置
2. 上記のプロパティファイルに対してカスタマイズを行う ※マルチバイト文字のメッセージを含む場合は、Unicodeでエンコード/デコード処理を行うか別途プロパティファイルエディタなどで編集
3. IM-Jugglingプロジェクト内のconf/message配下に、カスタマイズ対象の製品標準プロパティファイルと同じディレクトリ構造で上記のカスタマイズ済みのファイルを配置

コラム

プロコード開発（スクラッチ開発）のメリットとデメリットは、こちらのページで詳しく解説しています。
IM-Press　スクラッチ開発とは ～メリットとデメリットを簡単解説～

3方式を併用するメリット

intra-martの強みは、3つの開発方式を組み合わせて利用できる点にあります。組み合わせることでさまざまな要件への対応が可能になり、intra-martの機能を最大限に活用することができます。

メリット一覧

• 開発スピードと柔軟性の両立
  ノーコード/ローコードで開発を高速化しつつ、必要に応じてスクラッチで柔軟に拡張できます。
• 保守性向上
  定型処理は設定ベースで管理でき、カスタム部分は局所化できます。
• コスト最適化
  高度な技術を要する部分を最小限に抑え、開発コストを最適化します。
• 業務部門の自走力向上
  業務側が直接更新できる領域が広がり、IT部門の負荷が軽減されます。
• システム連携の柔軟性
  IM-BPMとスクラッチ連携を組み合わせることで、全体最適化されたプロセスを構築できます。

コラム

選択の判断基準は？
要件により「完全ノーコードやローコードで対応可能か」「どのポイントでコードが必要になりそうか」は違ってきます。
下記は選択基準の一例ですが、「実現したいこと」や納期、コストなど、それぞれの状況に合わせて考えてみましょう。

• 簡易的な業務アプリケーションやワークフローをすばやく作る
  → ノーコード（IM-BIS、FormaDesigner）
• 細かい画面設定やintra-mart内の処理と連携したアプリを作る
  → ローコード（AccelStudio）
• 外部連携や独自UI/機能、サーバ側での複雑な業務ロジックやバッチ処理、トランザクション制御などを行う
  → プロコード（必要に応じて、BloomMakerやFormaDesigner、IM-LogicDesignerなども活用）