コラム
Oracle APEXでマイグレーション②～レイアウト再現のコツ～
前回の第1章では、社内システムの老朽化に伴う課題とマイグレーションの必要性やOracle APEX導入のメリットについてご紹介しました。今回はその続編として、Oracle APEX上で実際に画面レイアウトの再現に成功した取り組みについてご紹介します。
Oracle APEXでは、12列のグリッドベースレイアウトが採用されており、UI部品を直感的に配置するだけで自動的にレスポンシブ対応が可能となります。つまり、画面サイズに応じてレイアウトが柔軟に変化する仕組みが標準で備わっており、レスポンシブ対応のためにCSSを記述する必要はありません。
とはいえ、現行システムと同じ見た目を再現するには、標準機能だけでは限界がありました。特にスクロール機能付きのレイアウトや構造が複雑なレイアウトにおいては細かな調整が必要となる場面もありました。
そこで本章では、Oracle APEXの標準機能でどこまでレイアウトを再現できるのかを検証し、再現が難しかった課題に対してどのような技術的対応をしたのかを詳しく解説していきます。
Oracle APEXの可能性を実感していただける内容となっていますので、ぜひ最後までご覧ください！
▼Oracle APEXでマイグレーション 全5章
Oracle APEXでマイグレーション①～老朽化対応と刷新のポイント～
目次
1）現行システムASP.NETの画面構成と開発方針
レガシー脱却に向けてマイグレーションを進めるにあたり、現行システムの画面設計を事前に把握しておくことが不可欠です。画面設計を理解することで、業務フローに沿ったUI設計が可能となり、ユーザー操作の負荷軽減につながります。
ここからは、今回の移行対象である「支払請求システム」を例に、ASP.NETでの画面構成についてご紹介します。
1-1）移行対象システムの画面構成
支払請求システムは、社内における支払請求業務を支える業務システムとして運用しています。
本システムは、以下の3つの画面群で構成されています。
・支払請求一覧画面
保存済みの請求情報を一覧表示し、絞り込み検索・編集・照会操作を行う画面。
・支払請求書画面
新規登録や申請前データの編集を行う入力画面。
・ポップアップ画面（6画面）
親画面の支払請求書画面と連携している子画面。
部門検索、領収書ファイルの添付、申請に必要なコードの選択など、補助的な操作を担う画面。
※本ブログでは社員検索のポップアップ画面を参考画像として掲載します。
1-2）再現目標とOracle APEXでの実装方針
支払請求システムの画面構成を把握した上で、次に重要となるのが「Oracle APEX上でどこまでレイアウトを再現できるか」という技術的な検証です。今回のマイグレーションでは、現行システムの見た目を再現するだけでなく、開発過程で発生した課題に対してOracle APEXの特性を活かしながら技術的な対応方法で解決することを目標に設定しました。
その中でも今回は、支払請求システムのデータ登録を担う「支払請求書画面」と社員データを検索する「社員検索画面」に焦点を当て、以下の２つの観点から実装方針を立てました。
①標準機能を最大限活用した画面レイアウトの再現
Oracle APEXに標準で備わっている「リージョン、アイテム、ボタン」などのコンポーネントを中心に活用し、ローコード開発による効率的な構築を基本方針としました。さらに、12列グリッドレイアウトを用いることで、各コンポーネントの視覚的調整とレスポンシブ対応を両立し、統一感のある画面設計を目指しました。
② カスタマイズによる課題への技術的な対応
Oracle APEXの標準コンポーネントを最大限活用しつつ、再現が難しいレイアウト要件に対してはPL/SQLやCSSなどの技術的カスタマイズを柔軟に組み合わせることで、現行システムに近い画面構成を実現する方針を採用しました。
このように、Oracle APEXの標準機能と柔軟なカスタマイズを組み合わせることで、画面レイアウトの再現を目指しました。
次節では、これらの方針に基づいて構築した画面の具体的な再現事例をご紹介していきます。
2）Oracle APEX標準機能による画面再現と課題
ここでは、Oracle APEXの標準コンポーネントを用いて、支払請求書画面や社員検索画面の画面レイアウトをどこまで再現できたかをご紹介します。
2-1）標準コンポーネントの役割と活用効果
Oracle APEXには、画面設計を行うためのコンポーネントが豊富に用意されており、基本的な画面の構成は標準機能だけで十分に再現可能です。
主要なコンポーネントとして「リージョン」「アイテム」「ボタン」と呼ばれるものが用意されています。これらはそれぞれ役割を持ち、画面設計の中核を担います。
各コンポーネントの詳しい解説は以下をご参照ください。
ページ上のコンテンツを論理的にグループ化するための基本的な構成要素です。見出し、ボーダー、背景色などのスタイルを適用することで、関連するアイテムをまとめる「コンテナ」として機能します。リージョンを使用することで、ページ・コントロール（アイテムやボタンなど）を視覚的かつ機能的に整理できます。
☆リージョンとは
さらに、表やカレンダーなどの機能を備えたリージョンも用意されているため、より高度なUIをローコードで簡単に構築することが可能です。
ユーザー入力とアクションを処理するための基本的なUI要素のことをいいます。
☆アイテム・ボタンとは
アイテム：データの入力・表示用のフィールド
ボタン：ユーザー操作をトリガーするUI要素
これらのコンポーネントは、Oracle APEXアプリケーションのインタラクティブな部分を構築するために不可欠です。JavaScriptを使用することで、これらの要素を動的に操作し、より高度な機能を実現できます。
これらのコンポーネントは、Oracle APEXの画面エディタ上にドラック&ドロップ形式により直感的に配置できるため、ローコード開発に初めて取り組む方でもスムーズに設計を進めることが可能です。また、アイテムやボタンを配置するだけでなく、用途に応じてプロパティエディタから各コンポーネントの詳細設定も簡単に行うことができます。
これらの標準的に備わった機能を活用することで、以下のような効果が期待できます。
・開発効率の向上
・メンテナンス性の向上
・一貫性・統一感のあるレイアウト設計
このように、Oracle APEXの標準コンポーネントは、レイアウト設計において非常に有効な手段となります。 しかし、現行システムのレイアウトを忠実に再現することに固執しすぎると、Oracle APEXが本来持っている柔軟性やレスポンシブ対応といった利点を活かしきれなくなってしまいます。そこで今回のマイグレーションでは、「APEXの良さを活かすことを優先し、ある程度のレイアウトの差異は許容する」というコンセプトで進めていきます。
次節では、これらの標準コンポーネントなどOracle APEXに標準で備わっている機能を活用してどこまで再現できたのかについて、支払請求書画面と社員検索画面を例に具体的な構成を見ていきます。
2-2）標準機能で再現した画面レイアウト
支払請求書画面や社員検索画面では、主に標準コンポーネントを活用して基本的な構成を再現しました。
この時点でかなり現行システムに近づけることはできましたが、細部の再現には差異があるため、ここからさらに現行システムに寄せる必要があります。
これらの画面では、主に以下の標準コンポーネントを活用して画面レイアウトを再現しました。
〇「リージョン」の活用
☆主に活用した標準コンポーネント
・対話グリッド：支払請求画面の下部にある申請情報を入力する一覧部分に使用。
・静的コンテンツ：支払請求画面や社員検索画面にあるアイテム（氏名や社員番号等）やボタン（承認や検索、クリア等）を項目ごとにまとめたコンテナとして使用。
・クラシック・レポート：社員検索画面の検索結果一覧部分に使用。
〇「アイテム」の活用
・テキストフィールド：支払請求画面の上部にあるログイン情報の表示部分や社員検索画面の検索項目（部門コード、社員名等）の入力欄に使用。
・チェックボックス：支払請求画面の領収書添付の有無を示す場面等で使用。
〇「ボタン」の活用
・検索ボタン：社員検索画面で条件を指定して検索実行する機能として配置。
・クリアボタン：入力内容のリセット機能として配置。
・保存、申請ボタン：支払請求書画面で申請データの保存や申請を実行する機能として配置。
【標準機能のちょっとしたポイント】
・アイテムのプロパティ設定で必須項目や初期値を簡単に設定可能！
・グリッドは12カラム（列）を採用しているため各コンポーネントの幅や配置位置をカラム単位で指定可能！
・特定の条件でリージョンやアイテム、ボタンの表示/非表示を制御し、画面の動的な変化を実現！
これらの標準で備わっている機能を組み合わせることで、支払請求書画面や社員検索画面の基本的な構成は十分に再現できます。しかし、スクロール機能の領域範囲や細かなレイアウトの再現調整など、標準機能のみでは対応しきれていない部分も存在しました。そこで次節では、こうした標準機能の限界に直面した場面を振り返り、発生した課題と得た気づきを整理します。
2-3）標準機能によるUI設計の限界と気づき
Oracle APEXの標準コンポーネントのみで基本的な構成は十分に再現することができました。
それと同時にいくつかの課題も明らかになりました。
特に明確だったのが、以下の2点です。
課題①：スクロール機能の制御に関する問題
ポップアップ画面において、検索結果の一覧にスクロール機能を付けた際、スクロール対象範囲が画面全体に及んでしまい、ユーザーが操作したい領域が見づらくなるという問題が発生しました。
課題②：レイアウトの再現度の問題
標準コンポーネントだけで現行システムと同じレイアウトを再現するには限界がありました。
特に、表形式の入力フォームにおいて、1列の中に2つ以上のコンポーネントを配置するような複雑なレイアウトは再現が困難でした。
これらの課題を通して、Oracle APEXの標準機能だけでは対応できない課題があることが明らかになりました。
次節では、こうした技術的な課題をどのように解決したのかについて具体的にご紹介していきます。
3）技術的課題の解決策
ここでは、前節で明らかになった課題に対して、Oracle APEXの柔軟性を活かした技術的なカスタマイズによる課題解決の工夫とその結果について解説します。
3-1）コンポーネントの変更による構造調整
課題①：スクロール機能の制御に関する問題
対応策：
使用していたリージョンを見直し、より細かい領域制御が可能なリージョンへと変更
Oracle APEXには似たリージョンがあり、当初は「一覧のみ表示するリージョン」を選定しましたが、このリージョンではスクロール範囲の設定ができませんでした。そこで、一覧と他の項目も表示されるため選ばなかった別のリージョンを検討したところ、不要な項目を非表示にできることが判明しました。さらに、スクロール領域を柔軟に設定でき、検索結果の一覧部分だけにスクロール機能を設定できました。
3-2）PL/SQL・CSSによるカスタマイズ
課題②：レイアウトの再現度の問題
対応策：
既存で備わっているコンポーネント（今回の場合は動的コンテンツのリージョン）に対して、PL/SQLを用いて動的なレイアウトを構築し、CSSによるスタイル調整などのカスタマイズを実施
このように、Oracle APEXの標準機能をベースにしながらも、必要に応じて標準コンポーネントの変更やPL/SQL・CSS等を用いたカスタマイズを柔軟に組み合わせることで、より現行システムに近い画面構成を実現することができました。
3-3）Oracle APEXによるレイアウトの完成形と振り返り
技術的対応を経て、支払請求書画面と社員検索画面をOracle APEX上で再現することができました。
今回のマイグレーションでは、Oracle APEXの標準コンポーネントを活用することで、全体の約7割のレイアウトを構築することができました。さらにPL/SQLやCSSなどを用いた技術的なカスタマイズを加えたことで最終的には約9割まで再現度を高めることができました。
完成までの過程では、Oracle APEXに標準で備わっている柔軟なUI設計機能と、標準機能だけでは対応できない部分への技術的な工夫があります。特に、スクロール領域の制御や複雑なレイアウト構成については、標準機能だけでは限界があり、カスタマイズによる対応が不可欠でした。
また、見た目として100%再現することが難しい部分に対しては、必要以上に現行システムの再現を目指すのではなく、Oracle APEXの持つ本来の強みを活かすことを優先しました。
このように、Oracle APEXの標準機能と技術的カスタマイズを組み合わせることで、現行システムに近い画面構成を実現しつつ、Oracle APEXならではの利点も最大限に活かすことができました。
最後に
本章ではレイアウト再現を通して、Oracle APEXの標準機能の強みや課題に対する技術的な対応方法についてご紹介しました。
次回の第3章ではビジネスロジックに焦点を当て、Oracle APEXの標準機能を活用しながらも直面した課題とその解決策を実例とともにご紹介します。
具体的には以下のような課題への技術的な取り組みについてご紹介します。
・Excel出力（帳票出力）
・ログイン認証
次回は、さらに一歩踏み込んだ機能面の再現に挑戦し、Oracle APEXの可能性を深掘りしていきます。Oracle APEXの導入を検討中の方にとって必見の内容となっていますので、どうぞお楽しみに！
