RPGの観点からみたPHP ― パート6: やり残しを仕上げる
グリーン・スクリーンを越えた思考による価値の付加に集中する
IBM i アプリケーションの近代化のテクノロジーと目標はこの 15 年間で大きく変化しましたが、その実装を成功させるための基礎は変わっていません。ビジネスにおける基幹業務アプリケーションで使いやすい GUI を配置する場合、実証された標準を組み込み、最終目標であるビジネス・バリューの付加に集中することに代わるものはありません。
開発者は依然、「近代化」という言葉になると気が遠くなることがよくあります。どこから始めればよいのかわからなかったり、最終的にミスをしてプロジェクトを台無しにしたりしてしまう開発者も数多く存在します。ユーザー・エクスペリエンス (UX) 設計の最前線で仕事をしている私としては、自分のキャリアにおいて、同じ問題が何度も起きるのを見てきました。時代は変化するかもしれませんが、落とし穴は同じで変わっていません。この記事では、ミスを防ぐことができるよう、近代化に関する 5 つの基本的な問題についてお話します。
1. 海を沸騰させる
人は解決方法に興奮して、すべてのものを一度に提供しようとしがちです。これを「海を沸騰させる」と言います。つまり圧倒的に範囲の広いプロジェクトに取り組んだ場合に、波を 1 つずつ調べないことを指します。プロジェクトに取り組む場合に賢いやり方は、段階を追ったアプローチです。達成しなければならない内容を観察し、それを管理可能な段階に分割し、各段階に優先順位を付けます。
フロントエンド近代化プロジェクトでは、第1段階で理想的な候補は、基本的でモダンなインターフェースを、簡単な例とともに、それをどのように改善できるかユーザーの前に提示することです。物事を素早く提示し、フィードバックを得ることは、やり方が正しいことを確認するために重要です。できるだけ追加機能の簡単な例をユーザーに提示することをお勧めします。例は、現在のアプリケーションに価値を付加するものであれば何でもかまいません。この段階では、実生活 (また実際に役立つ場合は、その機能を実装できる他の場所) で特定の機能の価値が高いか低いかを判断するのに役立ちます。
一般的に、アプリケーションの使用に関する困難な点とそれを改善する考えられる方法を、空白の紙に記述するのは大変だということを念頭に置いてください。例を参照し、類似の機能が役立つことを示す方がずっと簡単です。フィードバックを得ることは推測を避けることです。これは簡単に陥りやすい罠です。一般の人がどのようにテクノロジーを使用し、新機能にどのように反応するかを見ることで、推測することがなくなり、またアプリケーションで特定の機能が役立つかどうか判断する前に、その機能を深く調査することがなくなります。
近代化プロジェクトは各ステップが小規模な場合に動きが早く、このアプローチを採用すれば最終製品の機能は、さらにビジネス・ニーズに適したものになるでしょう。また、段階を追ったアプローチは、 IT とビジネス両方に素早いウィン (勝利) をもたらします。「まぁ、6 か月以内には何らかの対応をしますから、大丈夫でしょう」といったことはなくなります。6 日で何かを生み出し、見せて、前に進む方がずっと良いと思います。
2. 5250 エミュレーターを Web 上で再作成する
Web ブラウザーを通してユーザーと IBM i アプリケーションを接続する端末エミュレーター (図1) のユーザーは依然として多少存在しますが、一般的に現在のユーザーには向いていません。さらに、エミュレーターはほとんどの人にとって扱いにくいようです (さあ、私はこう言いました)。開発者としてエミュレーターが好みなら、それは素晴らしいことです。ただ、誰もが好んでいるとは思わないでください。そうしたことを念頭に、いくつかとんでもない誤解を見ていきましょう。
モダン Web エミュレーターなるものがある
私の目から見てパッとしないプロジェクトのほとんどは、いわゆるWeb エミュレーターを採用しています。UI は緑色と黒色ではなく、ブラウザーで動作します。ただ、基本的にはエミュレーターと同じものです。想定されるデプロイメントのイライラは除外して、ポイントは何でしょうか？IBM i Access Client Solutions で色を変更し、多大な努力とコストを節約することができます。新しい UI を構築するなら、モダンなものにしてください。
近代化がしばしば「豚に口紅」と呼ばれるには十分なワケがあります。多くの場合、それは事実です。色が変わってもフォントが変わっていない、また UI で GUI の制御が制限されている場合、どのようなビジネス上の問題が解決されたでしょうか？多くの人は、CEO や顧客がグリーン・スクリーンについて腰を上げ、GUI が真のビジネス・バリューを付加する方法の研究に尻込みしないようにするためだけの理由で GUI に猪突猛進します。
GUI はエミュレーターほど速くない
ナンセンスです！過去 15 年間、数えきれないほどこうした言葉を聞かされてきました。その後に品質が様々だという論議が続いています。うまく構築されていればモダン UI の方が速いのです。単なるキーボードよりはるかに多い対話型機能をユーザーに提供するためです。GUI は、エミュレーターではできない方法で、作業を単純化、短縮、拡張、統合、評価させてくれます。
かつて、GUI がエミュレーターほど速くないことを示そうとした顧客がいました。サブファイルを 47 回「ページ送りする」ことで、エミュレーターの速度を実演してみせました。この論議は完全に彼が正しいように見え、これを理由に最新のテクノロジーを使用しませんでした。私の反応は、ユーザーが 1 回以上ページ送りしなくても済むように、サブファイル検索機能をコア RPG コードに追加して、最終的に GUI とエミュレーターを機能強化するというものでしたが、当時友人の賛同を得られませんでした。
今日の RPG Open Access 機能により開発者は、スクロール・リストへ一度にページ送りするというロジックの制限を越えて、同じ検索をすることができます。こうした話はいくらでもできますが、その必要はないでしょう。 GUI が勝ったのです。
あなたは設計もできる
私が UI と UX 設計のアーティストと思っている人がいるということをよく耳にします。UI 設計はストアード・プログラムの基礎となる論理設計を、より効率的また使いやすくするよう機能強化することです。私のしていることの約 99 % は、アプリケーションを正しく動作させ、より良く動作させ、プラットフォームに適合させ、またユーザーが直感的に作業できるようにすることです。優れた設計は、機能と審美性の両方で構成されています。しかし開発者としては、審美的な設計は避けた方が良いでしょう。15 年間涙目になるような色の組み合わせを見てきた後 (図2) では、この点は苦労して学びました。モダン UI の機能設計は定義された標準に従う技術的なスキルです。これらの標準を学ぼうと全力を尽くそうとしている開発者は、世界中の会社で素晴らしい資産であることが証明されています。
競合他社は魅力的である
言い訳をするのはやめましょう。どのような状況でも、あなたのアプリに代わる可能性があるアプリは素晴らしく見えるのです。PC、タブレット、電話で使用するその他のアプリは、たとえそれがシンプルなものでもすべて魅力的です。タブレットから IBM i 受注アプリケーションにアクセスする、図3 のようなシンプルな UI はお好みではありませんか？
バーが設定され、期待は高くとも Web エミュレーションは目的を達成しません。それは、難しすぎるように見えても近代化をしない方がよいということではありません。図4 に示す IBM i アプリケーション Web インターフェースのような他のモダンなアプリを意識し、自分のアプリと並べて比較した場合に、笑って「やった～」と言えるようにすることです。グラフィック設計部分が心配な場合は、Web 設計チームに相談して (あるいは契約設計者を雇って) テンプレートを作成します。設計者は、すべての画面の作業をする必要はないばかりか、グローバルなグラフィックス、フォント、スタイル、カラー・パレットを提供することができます。
最後に、Web エミュレーターはビジネス・バリューを欠く場合が少なくありません。アプリケーションを GUI フロントエンドにして、モダンに見えるようにするだけだとしたら、ビジネスの生産性をアップし、ユーザーをハッピーに、より効率をアップさせるのに役立つような多数の機能が失われることになります。GUI を構築する場合、それに定量化できる真の価値を付加するようにしてください。
3. グリーン・スクリーンの観点から考える
これは大変ですね。何年もしてきたことを変えるのは非常に難しいのですが、新しい可能性を取り入れてみてください。今まで見た最高のプロジェクトは「してもよい」という態度の産物です。GUI を作成する方法のヒントがなくてもかまいません。トレーニング、書籍、研究調査などで、あっという間にゼロからヒーローになることができます。しかし、グリーン・スクリーン・モードから離れる必要はありません。これはよくある自分の落とし穴に付いてきます。
エラー・メッセージ
ここに一つのシナリオがあります。私が自分のアプリケーションの中で間違いを犯し、その応答としてファンクション・キー部分を反転して強調し、「F9 = Errors」を押すように指示されます。問題なのは、F9 = Errors が画面で表示されてないことです。これは、JD Edwards Worldの一つの実例で、 私がエラー・メッセージを出さないように調べるアプリケーションがJD Edwards Worldです(各ユーザーが予測方法を与られない限り)。ではどうすればよいでしょうか？答えは簡単です。エラー・メッセージをきちんと文章で表示し、技術用語を使用しないことです。エラー・メッセージを家族で試してみてください。もし彼らにその文章がどの言葉で書かれているか聞かれたら、最初からやり直しです。
キーボード・マップ
「IBM i Access Client Solutions などを作業するためのキーボード設定ができますか？」という質問をよく聞きます。これではユーザーは混乱します。慣れているからと言って、古いテクノロジーを繰り返さないでください。ユーザーは自分が使用しているデバイスに慣れ、同じデバイスでテクノロジーを切り替えさせることは、ユーザー側の労力が非常に大きく、非効率的になります。
ファンクション・キーもありがちな落とし穴です。ユーザーにファンクション・キーを見せても、強制的にそれらを使用させないことです。さらに悪い点として、キーの機能に関する情報のないキーのリストを表示してはいけません。目的を示さない場合は、画面にボタンを表示しないでください。例えば、ボタンを「F1」と呼ぶのではなく、その目的 (「ヘルプ」や「Enter」など) でラベル付けします。最近ですが、F1 から F 24 までユーザーが押すことができるすべてのキーのキーボード・マップを見かけました。ユーザーが各キーを押したときにどのような機能を果たすのか説明がありませんでした。これは明らかに、グリーン・スクリーン的思考の例でした。
画面の技術情報
日付、時間、仮想デバイス ID、プログラム名といったものは知っていると思います。UI 用語では、それはコンピューター管理上のゴミと呼ばれることがあります。はっきり呼びましょう。テクニカル・ジャンク (技術的ながらくた) と！ほとんどのユーザーにとって、それは画面を乱雑に見せ、便利な情報を入手するプロセスを遅らせるがらくたです。必要な項目でさえ、そうした技術情報の目的を知らないユーザーにとっては混乱を引き起こすことがあります。PC、Mac、タブレット、電話にはすでに効率的な方法で日時が表示されていますね。アプリケーション内でもそうした情報を一日中見る必要はありません。ユーザーは昼食時に、今朝 QPADEV0001T をどうやって取得したか話すわけではありません。
技術情報が決して必要ないとは言っていません。ただ、そうした情報が必要な場合は、ユーザーに整然とした形式で提示し、電子メールでも送信してサポートしてください。そうした情報を提示するモダンな方法は、問題の説明と連絡するサポート番号、また情報を電子メールで送付してサポートするオプションを記載した単純なポップアップ・ボックスでしょう。
固定フォント
人はなじみのある画面にするために Courier など固定のフォントを使用します。しかし、固定ピッチの「エミュレーター」フォントは読むのに 40 % も余分に時間が掛かります。近代化の全体的なポイントは UI を改善し、ユーザーの効率をアップさせることです。Arial などのプロポーショナル・フォントの方が読みやすく、モダンに見え、画面にデータをより多く表示できます。現代では、固定フォントを使用しているアプリケーション (デスクトップ、 Web、またはモバイル) はありません。さて、何故あなたはそんなもの使うのでしょうか？
文字ユーザー・インターフェース的な考え方と GUI 標準
これは個人の好みと、考え抜かれた標準という図式です。人が、何かにつけて「...がきらい」、例えば、ラジオ・ボタンやフォント、色がきらいと頻繁に言うのには驚きます。個人の好みでスタイルを選んではいけません。理由があって、また多くの研究とテストをした後に定義された標準に基づいて選択するべきです。誰かが何年も掛かって骨の折れる研究をした後の設計時に、開発者が一からやり直す必要がないように標準が定義されています。スタイルが好きならそれはかまいませんが、それは自分の好みであり、ユーザーや顧客をそれに従わせる理由にならない点を忘れないでください。
モダンで Web ベースのアプリケーションを設計する方法について学習するには Robert Hoekman, Jr. の書籍「Designing the Obvious」から始めるのが良いでしょう。他にも「About Face 3: The Essentials of Interactive Design」などの包括的な書籍も多くありますが、それは根っからの UI エキスパートが、あらゆる分野で非常に詳細な情報を求めている場合の本です。しっかりと作られたアプリケーションがどのように標準を実装し、それに従っているか眺めることで、インスピレーションを得て、アイデアを得ることもできます。Google アプリも非常に優れています。Microsoft Outlook は最もモダンな UI 項目を組み込み、良くできています。最後に設計についてコメントをします。Web ページは Web アプリケーションと同じではありません。ページとアプリの動作は異なっており、実際そうあるべきです。そのため Web サイトをコピーすることから始めることはお勧めしません。
4. オール・オア・ナッシングの近代化
近代化はオール・オア・ナッシングといった作業ではありませんが、いかに多くの開発者がそう感じていることかと思います。セットアップが正しければ、100、1,000、10,000 画面も近代化する必要はありません。IBM i 開発者について感心する点として、詳細まで注意する態度があります。通常 IBM i 開発者は、発生する可能性はあるものの一般的ではなく、ありそうにない「エッジ・ケース」を扱うのに対して、PC または Web の世界の開発者は、一般的なケースを扱う場合が多いものです。開発者は、あらゆる可能性を扱うことで IBM i の信頼性を支えていますが、モダンな UI に最善を尽くすことで必要以上の作業が発生する場合があります。例えば、ユーザーが 1 年に 1 回しか使用しないメンテナンス画面の構築と、アプリケーションの基幹画面の構築を、同程度に尽力する必要はありません。80 対 20 のルールで行きましょう！
80 対 20 のルールとはこんな感じです。ユーザーの時間の 80 % をアプリケーションの 20 % 未満に対して費やします。したがって、80 % の労力をこうしたアクセスが多い領域に費やし、残りの 20 % をほとんど使用されない領域の作業に費やすべきでしょう。ほとんど使用されない領域はアクセスが多い領域と同じ程度の細かさは必要ありません。それらに ROI は得られないためです。よくできたサインイン画面を作成し (アプリケーションの第一印象であり、ユーザーの詳細情報を越えて便利な場合があります)、メニューとユーザーがそれらをどのように使用するかを調査し、アクセスの多い領域を確認します。1 年に 1 回しか使用されないテーブル・セットアップ画面では GUI ツールで重労働をさせましょう。アクセスの多い領域に力を入れることは、価値を付加し、問題を解決する時間ができるということです。
詳細な書類については心配する必要はありません。アプリケーション全体のヘルプ文書を作成することは膨大な作業であるばかりでなく、ユーザーがそれに触れることはあまりありません。むしろユーザーは、画面に指示される形でのヘルプや、アプリケーションのアクセスが多い領域のハウツー・ビデオに素早くアクセスしたいでしょう。その点では、ほとんどのアプリケーションについて賭けても構いません。10 から 20 のクイック説明や画面ツアーは、アプリケーションの使用方法の学習方法を劇的に変えるでしょう。
5. ビジネス・バリューの付加を忘れる
ビジネス・バリューの付加は、近代化プロセスにおいて、ビジネス・チャンスの最大のミスを犯しています。開発者は、コントロール、ウィジェット、グラフィックス自体はほとんど価値がないと理解する必要があります。UI の構築方法についてアドバイスをしているわけですが、それでも色、ブラウザー、デバイスについてはあまり考えません。私はむしろ、グリーン・スクリーンの時より UI を改善する機能を探すことに労力を費やしています。こう質問するといいと思います。「ここで GUI は、エミュレーターにはできないどんなことができるか？」私は、ビジネス・バリューを付加しないのなら、近代化に失敗したとまで極言します。
ユーザーが実際にアプリケーションを使用しているところを観察してください。彼らがどのようにそれを使用しているのか理解していると思わないことです。問題を見つけ、最適なワークフローとそれをどのように機能強化できるかを探ります。ユーザーに何が問題なのかを尋ねますが、どの意見も話半分に聞いておくことです。ユーザーは、ソフトウェアの設計や相互作用ではなく、自分の仕事のエキスパートなのです。問題を探して解決することがあなたの仕事です。多くの場合、ユーザーを観察していると解決方法につながり、エラーやプロセスの実施に必要な時間が 40 から 60 % まで削減することがあります。年間作業日が 200 日を超え、毎日何度も作業している多くのユーザーを抱えている場合、文字どおり絶対確実なのは生産性です。
10 年前は近代化は簡単でした。一般的に、使用できる唯一のデバイスは 15 インチ・モニターを備えた Windows PC でした。2013 年には、スマートフォン、タブレット、オフィスや倉庫にはしばしば 60 インチを超えるディスプレイがあり、それらのデバイスはすべて、タッチ、キーボード、リモート、マウス、タッチペンなどさまざまな方法で相互作用しています。最も優れたアドバイスは、アプリケーションを構築しているデバイスを実際に手に取り、使うことです。あらゆるデバイスを単一のフォーマットにする必要はありませんが、シミュレーションを越えて、実生活でそれらを使用することが必要です。私のオフィスにはあまりに多くのデバイスがありますが、新しいデバイスはそれぞれ最低でも 2 週間はメイン・デバイスとしての役割を果たしているため、それを理解できるようになります。結論は、デバイスが IBM i 情報を画面に表示することを越えて何ができるか理解しない限り、デバイス分野で価値を付加するために奮闘することになるということです。
統合により ALT + TAB 切り替えやデータの再入力がなくなる分野を探してみましょう。我々は多くのアプリケーションがつながった世界に住んでおり、それらは互いにうまく動作しなければなりません。例えば、販売員が顧客に会う前に、 PC で ERP on IBM i、Microsoft Word を使い、電話で Google マップを使用することが販売員のプロセスを意味するなら、それらのアプリケーションはシームレスにつながっている必要があります。
ユーザーが情報をカット・アンド・ペーストしたり、複数のウィンドウでスワップしたり、さらに悪いことに、同じ IBM i アプリケーションでセッションを切り替えていたりしたら、統合するのにまたとないケースです。ユーザーに IBM i が PC や Web またモバイル・デバイスにつながっていない、と思わせるのはやめましょう。ユーザーの生活を楽にするということは、プロセスを通した作業時間を減らし、人間だけができる作業により時間を割くことなのです。
結局、ビジネス・バリューを付加する
この記事では、グリーン・スクリーン UI の近代化で誤りを犯す可能性がある 5,000 の案件の中から 5 件をお話ししました。一度に 1 つの波でプロジェクトを進め、定義された標準に従い、進みながら学習すれば、IBM i アプリケーションの近代化は思ったよりずっと簡単であることがわかると思います。私は多くの開発者が、先入観のない心だけでアプリケーションの近代化に秀でているのを見てきました。ただシンプルにビジネス・バリューを付加することができるなら、道を誤ることはないでしょう。
