2.1.22. Nablarch UI開発基盤の特徴

Nablarch UI開発基盤の主な特徴は以下のとおりである。

  1. 画面設計工程における作業工数を低減しつつも、仕様齟齬の発生リスクを極小化する。
  2. マルチブラウザ、マルチデバイス環境における開発・テストにかかる工数を大幅に低減する。

2.1.22.1. 画面設計工程における作業工数、仕様齟齬の発生リスクを極小化する

2.1.22.1.1. 問題点

外部設計工程における顧客との仕様策定で「画面モックアップ」の作成は極めて重要な役割をもつ。 開発側から見れば、Excel等で文字とワイヤーフレームで作成された仕様書が文字通り “仕様” であるものの、 顧客側が十分にこれを理解するは一般には難しく、仕様書をベースにした合意は 往々にして終盤の工程での認識齟齬と仕様変更を誘発する。 (開発側と顧客のどちらがコストを負担するかは別として。) このため「動いている画面」をもとに仕様を合意することは プロジェクトの成否に関わる極めて重要なポイントの1つといえる。 また、最近ではJavaScript等を用いたインタラクティブなUIが一般化しており、その重要度は増す一方である。

しかし、画面モックアップを作成するには、以下の問題が発生する。

  • 画面モックアップはどの程度まで作り込めばよいのか?
  • 実画面を顧客に見せると、機能と関係無い見た目の話に終始してしまい、仕様策定が進まなくならないか?
  • 画面デザインが確定していない場合、画面モックアップはどのような表示にすべきか?
  • 画面デザインが修正された場合、いちいち全画面のモックアップに反映させるのか?
  • 設計担当者ごとにHTMLを作成するので、画面の見た目がバラバラにならないか?
  • 設計担当者にHTMLやCSSでコーディングするのに必要な工数やスキルを要求することは難しいのでは?
  • 画面モックアップを開発工程に流用することは可能か? 流用できないならモックアップの作成工数は無駄ではないのか?

2.1.22.1.2. アプローチ

本機能では設計段階から業務画面のJSPファイルを作成する。 このJSPファイルは以下のような特徴をもつ。

  • JSPファイルをWebブラウザで直接開くことにより、サーバ上で動作した場合と同等の画面を表示でき、 また、紙芝居レベルの画面遷移とJavaScriptの動作デモを行うことができる。
  • JSPには画面項目定義書と同じ抽象度をもったタグを記述し、各画面項目の見た目に関する情報は記述しない。 各画面項目の見た目は本機能が提供する基盤部品側によって描画され、 その内容は既定の UI標準 に準拠したものとなる。
  • JSPファイルは実際にサーバ上にデプロイして動作させることができる。 設計工程で作成したJSPファイルを開発工程以降もそのまま使用する。

補足

基盤部品として提供されていないUIについて
基盤部品として提供されていない画面部品についてはJSP内にHTMLを直接記述し、画面モックアップを作成する。 （基盤部品として提供されている画面部品と通常のHTMLを混在させても問題はない。) ただし、その場合は、サーバ上での動作や、マルチブラウザ・マルチデバイスでの表示などの 検証を各画面で個別に実施する必要がある。

2.1.22.1.3. メリット

これらの特徴によって、以下のメリットが発生する。

  1. 既定の UI標準 が用意されているため、 ゼロから画面デザインの標準を策定するのに比べて、非常にスムースに進めることができる。
  2. JSPに画面の見た目に関する要素が一切含まれないため、画面の設計者は画面の論理構造のみに集中すればよく、 UI標準 に沿った画面表示にするために、個別にHTMLやCSSを調整する必要がない。
  3. UI標準 をプロジェクト側でカスタマイズした場合、その影響は基盤部品側に限定される。 基盤部品を修正することで、その変更内容は自動的に各業務画面の表示に反映される。
  4. 業務画面のマークアップ(HTML/JSP)の記述量を劇的に削減できる。 (従来の方法で作成した過去PJの画面と比較して 1/6～1/10 程度に記述量を削減できる。)
  5. 各画面部品が内部的に使用しているJavaScriptを意識する必要がなく、 JavaScriptを多用したリッチUI部品についても通常の画面部品と同等に扱うことができる。
  6. 設計時に顧客合意をとったJSPをそのまま開発に使用するため、HTMLやExcelで作成した画面モックからJSPを作成するのに比べ、 デグレードや画面仕様の齟齬といった問題が発生しづらい。

2.1.22.2. マルチブラウザ、マルチデバイス環境における開発・テストにかかる工数を抑制できる

2.1.22.2.1. 問題点

従来の開発プロセスでは、システムがサポートするOS/ブラウザとバージョンを固定し、 開発・テスト時にそれぞれテストを行うという方法をとってきた。 しかし、ここ数年の間に、ほとんどの開発案件においてスマートフォン・タブレット対応が必須となったことから、 現実的な工数内でデスクトップ・ラップトップ端末も含めた全ての端末で挙動を確認しつつ開発することが不可能となっている。

2.1.22.2.2. アプローチ

本機能では、マルチブラウザ、マルチデバイス開発でネックとなる以下の要素について、基盤部品側の責務として実装しており、 UI標準 での明文化と、十分なテストを行なっている。

  1. マルチブラウザ(IE11, Firefox, Chrome) および スマートフォン・タブレットでの表示互換性
  2. 画面サイズの変更およびモバイルデバイスでの縦横表示切替えにともなう画面構成の自動調整

2.1.22.2.3. メリット

上で述べたように、 各ブラウザ・デバイスでの表示調整は、全て基盤部品側の責務となる。 このため、各画面毎に対応端末ごとのテストを実施する必要がない。 これは、開発工程全体にわたって劇的なコスト削減につながる。

重要

Nablarch UI開発基盤が現バージョンで表示互換性を担保しているのは、 テスト実施環境 に記載されているブラウザのみである。

Nablarch UI開発基盤の解説書に、 テスト実施環境 に記載されていないブラウザやバージョンに対する言及があった場合、無視すること。