IBM i ビジネスを近代化する パート 3: アプリケーションの顔を変える
見渡せば IBM i アプリケーションはどこにでもあります。21 世紀になった今でも、ホテルに行けば昔ながらのグリーン・スクリーン・アプリケーションでチェックインしていることと思います。いくつか有名な小売店をブラウズすれば、キャッシャーの台座でグリーン・スクリーン・アプリケーションを表示していることと思います。この telnet 5250 文字ベースのインターフェースは、長年使用されてきた独自の技術として今でも人気があります。
これほど長い間使用されてきたグリーン・スクリーンは古く、かなり時代遅れだと見なされています。ただしほとんどの場合、モダンなユーザー・インターフェースと比較して、古く、時代遅れに見えるだけです。通常は、グリーン・スクリーンは、インターフェースをフラット・ユーザー・エクスペリエンスを越えて拡張するツールは備えていません。ドロップダウン・ボックス、ラジオ・ボタン、チェック・ボックス、日付コントロールなどはありません。これはスマート・エミュレーター・ソフトウェアにより多少は緩和されていますが、グリーン・スクリーン・エクスペリエンスは、単に一般ユーザーが、他のどのアプリケーションでも遭遇するようなエクスペリエンスではありません。ブラウザー・アプリケーションを当たり前と受け止め、スマートフォンやタブレットを幅広く使用することで、モダン・ユーザー・エクスペリエンスは、従来のグリーン・スクリーン・アプリケーションとはまったくかけ離れたものとなります。
こうした不一致があるために、ユーザーはしばしば、まずその IBM i アプリケーションにモダン・インターフェースを要求 (求める) ことになります。多くの企業は、既存のアプリケーションにあまり機能という形で追加していない新しい外観のインターフェースを提供することで、これらの要求に応えています。しかし、ユーザー・エクスペリエンスの分野におけるテクノロジーの進歩が速く、最終的にこの新しい外観のインターフェースの輝きは失われ、まもなく古く、時代遅れのインターフェース群に追いやられています。
数年前に、レポーターに近代化プロジェクトが失敗するのはなぜかと尋ねられたことがあります。その話の流れは、ある近代化イベントでベンダーが、お客様はより近代化する必要があると公言したことにありました。レポーターにはまるで今までの近代化が失敗し、ベンダーがより近代化を懇願しているかのように思えました。しかし、こうした「失敗した」プロジェクトのほとんどは、単に表面（顔）を変えただけのプロジェクトでした。グリーン・スクリーン・アプリケーションの顔を変えただけの IT 企業のほとんどは、自分たちが近代化プロジェクトに成功したと感じて、一段落したらそれ以上何も考えていません。これは、IBM i IT 企業では極めて一般的な戦術的なアプローチで、完全な近代化戦略の初めの一歩としてしか見なされていません。
歴史的に言えば、近代化
ユーザー・インターフェース (User Interface) を意味する UI という用語は、その前に文字がないと多くの場合不完全です。例えば、何十年も前にデータ処理で最終的にモニターを使用するようになったとき、表示できる唯一のものがテキストでした。テキスト (Textual) またはテキストベース・ユーザー・インターフェース (Text-based User Interface) を意味する頭字語 TUI は、端末の出力モードで情報を提供する方法の説明に使用されていました。次の展開は CUI (Character User Interface: 文字ユーザー・インターフェース) でした。これは文字を端末に入力し、文字を受信する入出力操作両方を指しています。入力は通常、モニターのコマンドライン入力フィールドを使用して行われ、そのため、CUI はしばしばコマンドライン・ユーザー・インターフェース(Command-line User Interface) の頭字語として使用されています。(5250 データ・ストリームを使用する telnet プロトコルは、System/34 で導入されました。すべての高級言語は 5250 CUI をサポートし、プラットフォームの歴史上ほとんど大多数のアプリケーションがこのインターフェースを使用しています。)
近代化の領域で湯水のように浪費されている用語が、グラフィカル・ユーザー・インターフェース (Graphical User Interface) を意味する GUI です。GUI は従来のキーボードに加えてマウスを使用する能力を指し、ユーザー・エクスペリエンスの向上を実現するため、グラフィック要素 (画像、アイコン、ボタンなど) を使用して情報を表示することです。
ユーザー・エクスペリエンス (UX: User Experience) という用語は、歴史的に 2 つの関連する概念の説明に使用されてきました。まず、ユーザーが優れた効率的なアプリケーション体験ができるよう、アプリケーションの UI の設計方法を定義しました。次に、ユーザーが実際にどのようにアプリケーションを使用しているのかという情報の収集 (現在では分析論と呼んでいます) を定義しました。ごく最近では、単にユーザーがアプリケーションと相互作用する方法を説明するのに使用されてきました。近代化は、少なくとも表面的には、UX をキー・コンポーネントと見なす必要があります。
我々がテクノロジーとともに未来に向けて進んでいく中、今まで以上に定期的にユーザー・エクスペリエンスに対応することが期待されます。
今は？
近代化プロジェクトとして顔を変えただけでは不完全であることが証明されました。おわかりのように、これらのプロジェクトの結果生じる UI はすぐに時代遅れになる可能性があります。より新しい UI テクノロジーが一般で利用できるようになるにしたがって、ユーザーはその UX にアップグレードを要求し続けます。最初のプロジェクト結果が提供されたら、アプリケーションの表面を変えても完ぺきとは見なされません。
皮肉にも IBM i 企業が表面を変えないよう提案している理由の 1 つが、ユーザーがデータをグリーン・スクリーン・アプリケーションに非常に早く入力しているので、モダン UI が必要ないためです。時にこの言い訳は、グリーン・スクリーン・メニューをナビゲートして、特定のアプリケーション機能にたどりつく方法を説明するという形を取ることがあります。私が言われたのは、ユーザーは自分のアプリケーションにナビゲートするのに必要な数を正確に知っており、1 + Enter + 12 + Enter +3 + Enter と非常に素早く押すことができるため、GUI が、速度が遅くしている原因だということです。
「入力の速いユーザー」の不満は、データ入力アプリケーションにも表れてきます。ユーザーの素晴らしい指先からこの機能を外すのは犯罪だと企業は主張しています。彼らはそのアプリケーションに非常に慣れているためです。必要なキー・ストロークとファンクション・キーに非常に慣れており、高速で入力するため、キーボードのバッファーを利用して、その遅いコンピューターの先を行くことができるのです。グリーン・スクリーン攻防の最後の部分で近代化のエキスパートに伝えていることは、ブラウザーはこうした驚異的なタイピストに対応できるほど速くないだけで、優れた CUI エミュレーター・プログラムで利用できるキーボード・バッファリングを処理できず、適切に使用するためにマウスが必要であるということです。
実際、これらは言い訳に過ぎません。「壊れない限り修理しない」という感じで、特定のアプリケーションとその UI に対する習熟性があるというだけです。これはアプリケーション側の問題ではなく、変えようという意思がないだけです。この近代化特有の問題はむしろ個人的な問題であり、私に言わせれば、どのように克服できるか理解するには心理学的な討論が必要です。
近代化とは、アプリケーションへのアクセスの概念を完全に新たにするということです。グリーン・ボックスの外が見えない開発者にとっては、グリーン・スクリーン・メニュー式アプリケーションを取り替えるのは難しいでしょう。しかし、ロールベース・アクセスとお気に入り機能を備えた優れた設計の GUI メニュー形式アプリケーションでは、メイン・ポータルからユーザーがアクセスする必要があるアプリケーションまで 1 回か 2 回クリックするだけです。アプリケーション機能への高速キーボード・アクセスは、マウスを使用したユーザーと張り合うことはできません。
また近代化はユーザー効率の向上も意味します。単純にデジタル化できない多量のデータがある場合、データ入力アプリケーションは重要ですが、ビジネスの世界ではこうしたデータの量は、あらゆる技術革新に伴って少なくなりつつあります。例えば、バーコード入力、RFID、OCR、音声対テキスト・テクノロジーは非常に普及しており、人間がデータ入力する必要性はほとんどなくなっています。
これらの概念については別の記事で詳しくお話ししますが、現在ではこれほどまでに UX が著しくに変化していることを理解することが大切です。本の注文を例に挙げてみましょう。近年オンライン・ショッピングによりデータ入力コンポーネントがほとんどなくなり、UX が著しく変わりました。と言うのも、現在はお客様が注文入力係になっているためです。お客様は、そのすべてのデモグラフィック情報が保存されているアカウントにサインインします。求めている本を検索するときは数文字入力し、あるいはカテゴリーをナビゲートして本を見つけます。さらにいくつかクリックすれば本の支払が完了し、好みの出荷方法の利用に進みます。それを従来のグリーン・スクリーン・データ入力を使用した本の注文と比べてみてください。ユーザーは手書きのフォームのコピーを会社に郵送し、データ入力係がすべての情報をグリーン・スクリーンに入力し直します。ビジネスが成功しているなら、データ入力係を雇って求めに応じ続けるでしょう。お客様が入力に関わる現代のデータ入力アプリケーションでは、配送インフラストラクチャーをサポートするのに必要なコストを発生させることなく、会社は成長できます。
この例として、一般的な近代化戦術があります。従来のグリーン・スクリーンを使用した IT 企業は、UX を改善するためにそのグリーン・スクリーン注文入力アプリケーションの表面を変えることが重要だととらえています。しかし、戦術的近代化プロセスでは、コンポーネントの表面を変えることは、製品またはサービスを注文する文化全体の近代化に向けたロードマップでのあくまでも第一歩と考えています。
「より馴染んだ」近代化
歴史的に、IBM i 企業は、振り返ってみると、近代化と呼べるものに対して「より馴染んだ」アプローチを採用してきました。当初、業界で使用されていたハードウェアは遅く、CPU 処理時間が貴重でした。その対処としてアプリケーションの各画面にすべてのデータを詰め込み、ユーザーの応答時間が細切れになった多数の試行にならず、1 つのプロセスにまとまるようにしました。画面にできるだけ多くのデータを詰め込むため、フィールドのラベルは簡略化されました。ほとんどの場合、簡略化を実装したのはプログラマーで、それが頻繁にユーザーの狼狽と混乱を招きました。今日の世界では単に制限付きの CUI では十分ではありません。 グリーン・スクリーンの標準的な近代化ステップは以下のようになっています。
- 画面に余裕がある: それにこだわる。
- 画面に余裕がない。すべてを簡略化する。その後余裕ができる: それにこだわる。
- 画面に余裕がなく、すべて簡略化された。27 x 132 画面に変更する。その後余裕ができる: それにこだわる。
- 画面に詰め込まれているのはどれも理解できないラベルとデータである。ユーザーがそれにこだわることができるよう、ユーザーにより多くのエミュレーター・ウィンドウを開始する。
現在、IBM i は Power Systems サーバー上で動作しており、その結果アプリケーション応答時間はほとんど問題ではなくなっていますが、グリーン・スクリーン IBM i 企業はいまだにこの「より馴染んだ」設計アプローチを踏襲しています。表面を現代的に衣替えしたアプリケーションの場合でさえ、ユーザーが指定時間内にある意思決定を下すのに、必要以上の多くの情報が表示されているのが極めて一般的です。
グラフィカル設計、ユーザー・エクスペリエンス、再度目的を果たす要素を考慮しない表面を変えるだけのプロジェクトを立ち上げる企業は、遠からずまた衣替えする努力をしなければならなくなるでしょう。
ユーザーに共通して必要なことは、「より馴染んでいる」能力を提供することです。難しいのは、行われた要求の部分を整理することです。その理由は、IT 企業は、本来、重要な意思決定をできるよう詳細情報を表示するための要件である、要求の部分からのその能力を常にユーザーに提供してきたためです。
この例として、お客様から電話注文を受けることがあります。すべてを書き出し、後で再入力していったん完了した作業は、データ入力作業の一部となりました。そこではキーボード・オペレーターの入力速度は時間の経過とともに速くなり、GUI の衣替えはそのプロセスにかなわないように見えました。この驚異的なデータ入力作業が行われているのを目の当たりにすると、オペレーターは多くの時間を割いて、あらゆる注文に対して同じ情報を入力しなければならないと思うかもしれません。オペレーターは、エミュレーター、ブラウザー、他のアプリケーションなど複数のアプリケーション・ウィンドウを開いていることがわかるでしょう。また、多くの時間を割いてアプリケーション間を切り替えながら情報を収集し、注文入力アプリケーションにカット・アンド・ペーストしなければならない情報もあります。
では、表面を変えて、再度目的を果たすように作り変えられた同じアプリケーションを見てみましょう。同じグリーン・スクリーン・データ入力アプリケーションが、 GUI アプリケーションの核となっていることがわかるでしょう。反復値はあらかじめ入力され、注文入力プロセスにとって重要でないアプリケーションの画面は自動的に省略されています。しかし、それらの画面は必要な場合はワンクリックで表示できます。アプリケーション上部のタブ・セットにはさらに情報があり、注文入力プロセスの進捗を示しています。オペレーターがお客様に関する情報を知りたい場合は、ワンクリックしてアプリケーションの右側のペインにその情報を表示します。さらに、製品情報についても同じことがわかります。ワンクリックで、どの倉庫に製品の在庫がどれだけあるか、どれだけ製造中で、どれだけベンダーから発注されているか、また予想待ち時間が表示されます。同じお客様の他の注文に関する情報が表示され、オペレーターが必要に応じて製品の出荷をまとめたり、分割したりできます。
表面を作るまたは作り変えているコンポーネントは、この新しいアプリケーションの全体設計の一部に過ぎません。不要なキー・ストロークやステップを減らし、あまり労力をかけずにアプリケーションに多くの情報を収集することで、ユーザー・エクスペリエンスと効率が改善されます。このアプローチは「より馴染んでいる」という原則の現代的な進化であり、IBM i 開発者が利用できるあらゆるツールで可能です。しかし、それは、IBM i 企業がグリーン・スクリーンのメガネを外し、そのアプリケーション・スイートの概念をまったく新しいユーザー・エクスペリエンスに作り変えるときのみ可能です。
次はどこへ？
タッチ、ジェスチャー、音声など未来的な概念をもたらしたのは、サイエンス・フィクション、特にサイエンス・フィクション映画です。デスクに括り付けられたモニターは、かつてはIBM i アプリケーションの顔でしたが、タブレットやスマートフォンではより小顔になり、ユーザーはいつでも使えるようになりました。我々がテクノロジーとともに未来に向けて進んでいく中、今まで以上に定期的に UX に対応することが期待されます。IBM i 企業が俊敏でいられるための唯一の方法は、アプリケーションを複数の層に分割することです。
従来の IBM i アプリケーションにはビジネス・ロジックを実行するアプリケーション層があり、データベース層では保存データにアクセスし、プレゼンテーション層では UI を管理しています。プレゼンテーション層における近代化は、できるだけゆるやかに結合しているそのテクノロジーの層に UI を分離することを意味しています。このシリーズの次号以降でデータベース層とアプリケーション層について説明します。テクノロジーが進化するにつれて、プレゼンテーション層を置き換える場合に、アプリケーション層全体を書き換える必要はなくなるはずです。
IBM i では個別のプレゼンテーション層を作成するための多数のツールが利用できます。CGIDEV2 ツールセットを使用した CGI 提供 HTML は、今でも人気があります。PHP は HTML を提供する方法として認められましたが、アーキテクチャーが PHP アプリケーション内でプレゼンテーション層とアプリケーション層を区別できるよう、注意を払う必要があります。IBM i スペースの多くのベンダーが、従来の DDS コードから最終的に移行できるアプリケーション層を提供していますが、必ず調査を行い、24 x 80 または 27 x 132 の画面をスクレープし、それをブラウザーに配信して、表面を新しくしたということにしておくコードは削除してください。
最新のツールは、まとめて言えば RPG Open Access です。RPG OA はあらゆる種類の RPG 入出力処理に使用できますが、多くのベンダーはプレゼンテーション層に RPG OA ツールを単体で提供しています。これらのツールの多くはアーキテクチャーの向上に向けたロードマップ内で使用することができます。必要な場合には、あなたの会社の開発者が高級言語で RPG OA プログラムを作成でき、それらを長期的なアーキテクチャー要件にあつらえることができます。
ブラウザーを使用する
ブラウザーはモダンな配信メカニズムの選択肢となり、ほとんどのプレゼンテーション層は、短いサイクルであるフォームから別のフォームのブラウザーを活用するでしょう。あらゆるデバイスから、どこでもアクセスできる単一の UI を構築することの利点は過小評価できません。ただし、複数モデルのモバイル・デバイスや、複数の構成のモバイル OS の急増は、すべての選択肢にネイティブ・アプリケーションを構築することは完全に不可能であることを示しています。しかし、単に 1 つのユーザー配信プラットフォームのネイティブ・アプリケーションを構築することは、あなたの IT 部門、ひいてはあなたの会社が、いずれにしても機動的になり得ないということです。
アプリケーションのブラウザーへの配信、あるいは複数ブラウザーへの配信では、IBM i の IT 企業は、多少の開発ツールをそのスキル・セットに追加する必要があります。HTML が必要で、最新版の言語を十分に理解している必要があります。カスケーディング・スタイル・シート (CSS; Cascading Style Sheet) は HTML アプリケーションの外観を構成する場合に使用する言語で、アプリケーション開発になくてはならない部分になる必要があります。JavaScript はクライアント側のスクリプト言語として選択できるようになり、必須となっています。JavaScript がより普及するにつれて、JavaScript の開発に使用しているフレームワーク (ExtJS、JQuery、Dojo) が普及し、それには生産性向上ツールが余すところなく含まれています。IBM i コミュニティーでは、IBM i バックエンド・アプリケーションとテクノロジーを活用して優れたユーザー・エクスペリエンスを提供できる、 JavaScript フレームワークが利用できます。JavaScript フレームワークの採用は、近い将来また長期的に近代化へのカギとなるでしょう。
自分の世界を彩る
5250 データ・ストリームでは、グリーン・スクリーン UI に使用できる色は合計 8 色あり、フィールドを明滅させる機能や入力フィールドの文字間に列分離子を組み込む関数もありました。通常の IBM i グリーン・スクリーン・アプリケーションには、色の利用に関していくつかの標準があります。例えば、エラー表示に黄色を使用する人気のあるパッケージ・アプリケーションがいくつかあるものの、ある会社はエラーの色として一貫して赤を使用する場合があります。IBM i プログラマーは、現在取り組んでいるプログラム以外のプログラムを滅多に考えることなく、その結果、アプリケーションの色の利用にはなはだ一貫性がなくなっています。
モダンなブラウザーは通常 1,600 万色を超える RGB カラー・モデルを使用して、明滅や列分離子は使用していません。1,600 万色、アイコン、画像が利用できる状態では、グラフィカル設計は近代化されたアプリケーションのキー・コンポーネントです。近代化プロジェクトに取り組もうとしている IBM i IT 企業に述べる最も一般的なアドバイスは、プロジェクトの表面を衣替えする部分についてはグラフィック・デザイナーを雇うことです。同様に、アーキテクチャーと設計を支援するために UX のエキスパートを雇います。単純に、IBM i 開発者がこれらのスキルを UX の構築に必要なレベルまで習熟できるほど時間はありません。しかし、ほとんどの IBM i IT 企業はそのアドバイスを無視し、自身のグラフィック設計と UX アーキテクチャーを構築しています。機会があるうちに再度言わせてもらいますが、「グラフィック・デザイナーを雇ってください。ユーザー・エクスペリエンスのエキスパートを雇ってください。」
そういうわけで、平均的な IBM i 開発者が、グラフィック設計やカラー・マネージメントのスキルを自ら教育することが極めて重要です。これにより、技術的な観点からアプリケーション要件について、チームがよりうまくコミュニケーションできるようになります。また、チームが設計について生産的な会話をし、アプリケーションが真にエレガントで、効率的、またモダンになるよう、グラフィック設計および UX のエキスパートに指示することができるでしょう。
進行中のプロセス
近代化プロセスの道のりはまだ途中です。アプリケーションの表面を変えることがプロセスにおいて最も簡単に思えますが、それを決して近代化として既成事実化してはなりません。グラフィカル設計、ユーザー・エクスペリエンス、再度目的を果たす要素を考慮しない、表面を変えるだけのプロジェクトを立ち上げる企業は、遠からずまた衣替えする努力をしなければならなくなるでしょう。
表面の作り変えは近代化戦略全体の最初の戦術的ステップでなければならず、それがうまくできたら、次の技術進化に向け俊敏性を実現するアーキテクチャーを考える必要があります。大局的には、ユーザーが Google Glass UI を求めてきたときに、アプリケーションがどのように変化するか自問自答してください。その日は思いのほか早く来るでしょう！
