RPGとウェブ：目標達成のためのテクノロジー｜e-bellnet.com（IBM i （AS/400）ユーザーのための関連技術情報サイト）

IBM i 資料集

IBMｉ海外記事2008.07.10

RPGとウェブ：目標達成のためのテクノロジー

スコット・クレメント著

私は今まで、ウェブ・アプリケーションを開発するためのいろいろなテクノロジーの違いを理解するのに苦労してきました。RPGの開発者は5250端末を捨ててもっと新しいインタフェースに置き換えるべきだと繰り返し言われてきており、ウェブ・インタフェースを採用するのが正しいだろうということがかなり明白になってきました。ウェブ化をお客様向けの一般ウェブ・サイトを提供する手段としてしか捉えていないのであれば、それはかなり的外れな理解といえるでしょう。ウェブ・インタフェースは、社内ユーザーのみを対象としたとしても、5250端末を置き換える、最良で新しく、しかも強力なインタフェースなのです。

ただし、RPGソフトウェアをウェブ対応にする方法は数多く存在するので、自社のビジネスに合ったアプローチを選択するのは難しいものです。JavaとWebSphereを採用すべきなのか。はたまたPHPなのか。それとも、今抱えているスタッフでCGIDEV2を使ってRPGでウェブ・アプリケーションを構築するのか。利用可能なテクノロジーをそれぞれ実際に試して、どれが1番使えそうかを見てみないことには、この判断はほとんど不可能に思えます。しかも、どれが一番使えそうなのかを評価するには、全てのテクノロジーを習得しなければならないのです。今回のSystem iNEWS誌の詳説記事では、そうしたテクノロジーのいくつかを紹介し、それらがどんなものなのかを理解していただくことを目的としています。同じRPGのバックエンド上にそれぞれ異なるテクノロジーでウェブ・インタフェースを実装した事例を紹介します。

前述の通り、ウェブ・アプリケーションを開発するためのツールは数多く存在しますので、本稿で着目するテクノロジーを選択するには細心の注意を払った検討が必要でした。選択の基準は以下の通りです。

フリーのツールだけに絞りました。市場に出回っている選択肢全てを調査するつもりはありませんでした。その数があまりにも多すぎる、というのが理由です。
System iのコミュニティで広く使用されているものに絞りました。
RPGバックエンドに絞り込みました。20以上の異なるプログラミング言語でプログラムを書いてきた私の経験から、ビジネス・アプリケーションを記述するには新しいRPGコードが最もエレガントで効率的な方法といえます。したがって、ビジネス・ロジックはRPGで書きたいと考えました。3つの記事で比較されているウェブ・テクノロジーはユーザー・インタフェースを提供し、私が書いたRPGがビジネス・ルールを提供します。
「ウェブ用の」とか「表面上の」ウェブ・アプリケーションではなく、5250画面をウェブ画面に変換する真のウェブ・アプリケーションを構築するためのツールに絞りました。私見では、表面上のウェブ・アプリケーションは素早く構築できる一時的なソリューションとはなりえても、最終的には、ブラウザ・インタフェースの機能を十分に活用するには新しいアプリケーションをウェブ・アプリケーションとして書き直す必要があります。

コードに対してウェブ・インタフェースを記述するためのもっとも主要な3つのツールは、Java EE(旧名称J2EE)、PHP、CGIDEV2です。これら3つのツールもフリーなので、今回の比較対象としては最適です。JavaとPHPは広く普及しています。Javaは世界で最も広く使用されているプログラミング言語であると言われており、PHPはウェブ・アプリケーションの開発用言語として世界で最も広く使用されている言語であるといわれています。CGIDEV2はITの分野一般では主流というわけではありませんが、System iのコミュニティおよびRPGプログラマのコミュニティでは広く使用されています。約20,000人のプログラマが、CGIDEV2を使用してRPGでウェブ・アプリケーションを開発しています(この数字はwww.easy400.net/cgidev2/startの頁の左下、Our customers as of todayのリンクから引用しました)。

与えられた課題

前述の比較作業では、純粋なビジネス・アプリケーション、すなわちSystem i環境で使用する可能性が高いアプリケーションを対象とすることが重要であると思っていました。そこで私は受注用アプリケーションを選択しました。RPGで簡単な(余計なものがないという意味)受注用アプリケーションを記述してみました。図1、図2、図3、図4に、私が作成した受注用アプリケーションの緑色画面(5250端末)インタフェースの画面コピーを載せておきました。このプログラムがどう使われるのかを理解していただくために役立つと思います。

ビジネス・ロジック(ビジネス・ルールを含む)をできるだけ再利用可能にするため、表示ロジックから分離してサービス・プログラムの中に記述しました。新しいRPGアプリケーションを記述するときは、ビジネス・ロジックを表示ロジックと分けておくことで、他のインタフェースからのビジネス・ロジックを再利用する必要が生じたときに対応できるようにしておくことが重要です。このプロジェクトはその良い例です。なぜなら、同じRPGサービス・プログラムがコードを全く変更することなく5250インタフェースからも起動され、4つのウェブ・インタフェースからも起動されるからです。

ウェブ・インタフェース・テクノロジーの比較のために、私が作ったRPGサービス・プログラムのコピーをそれぞれの開発者に渡し、また、彼らに開発して欲しいウェブ・インタフェースの画面がどのようなものかを示すHTMLファイルもいくつか渡しました。どの開発者にも同じ画面レイアウトを使用してもらい、公平な比較ができるようにしました。これは、どの開発者が一番見栄えのいい画面を設計するかを競うコンテストではなく、異なるテクノロジーを使用して同じことを実行する、プロジェクト同士の比較なのです。したがって開発者には、全く同じRPGのビジネス・ロジックと、全く同じ画面設計を使用して、変更は極力少なくするように要求しました。したがって各記事とも、同じ成果が得られています。違うのは、それぞれ異なるテクノロジーを使用してそれを実現しているという点です。

リクエスト、セッション、アプリケーションのスコープ

ウェブ・アプリケーションは、どのようなテクノロジーを使用して構築しようとも、ステートレスのアプリケーションになります。緑色画面の端末の時代ではプログラムがイベントの流れを制御していましたが、これはウェブ･アプリケーションにはあてはめられません。ウェブ･ページ上のリンクやボタンをクリックするたびに、HTTPサーバーからドキュメントを取得して表示するということをブラウザに対して指示することになります。ブラウザはHTMLファイルをサーバーから取得してそれを表示するか、あるいはHTMLを出力して表示するプログラムを実行するかのどちらかが可能です。いずれの場合にしろ、1回のクリックあるいは「リクエスト」によって、1つのドキュメントが取り出されて表示されます。ウェブ･サーバー上でプログラムが実行される唯一のタイミングは、ボタンまたはリンクをクリックしてからページがブラウザ上に表示されるまでの間だけです。ユーザーがウェブ・ページを読んでいる頃までには、サーバー上でのプログラムの実行は既に終了しているのです。ページが表示されるとそのページ上で次の選択肢がクリックされるかもしれないですし、されないかもしれないのです。ウィンドウを閉じる、あるいはブラウザの「戻る」ボタンを押すかもしれませんし、URLを変えて全く違うサーバーに移動するかもしれません。これが、ウェブ・アプリケーションが「ステートレス」と呼ばれる所以です。ブラウザが取るアクションは全てお互いに無関係の、別々のリクエストと考えられるからです。

したがって、各リクエストにはプログラムを（おそらくパラメータを渡して）1度呼び出す動作が含まれ、その応答として1ページを受け取って画面上に表示します。このリクエストを処理するためにプログラム中で使用する変数は、「リクエストのレベルにスコープが限定されている」と言われます。つまり、変数はリクエストが開始されるときに作成され、リクエストが終了するときに削除されます。変数はリクエストの間だけ存在することになります。どのウェブ・テクノロジーもリクエスト･レベルのデータの処理を容易にしています。なぜなら、それがあらゆるウェブ･アプリケーションのもっとも基本的な部分であるからです。リクエスト･レベルではウェブ･テクノロジーに大きな違いは見られません。

リクエストの処理が終了した後でデータを保持しておく必要がある場合が多々あります。ウェブ･アプリケーションのステートレスという性質を否定する概念です。たとえば、アマゾンのようなオンライン・ショッピングのサイトを見ているとき、商品を選び、[ショッピング・カートへ追加]ボタンをクリックして、その商品のデータを自分の「ショッピング・カート」へ保存します。最終的にレジに進むと、カートに入れた全商品をシステムが取り出して、商品をどのように配送するのか、支払方法はどうするのかなどの質問が提示されます。同様に、私が作成した発注用アプリケーションも、最初の画面でどのお客様向けの発注を入力したいのか質問し、2番目の画面で発送先情報、3番目の画面で発送する商品に関する情報を尋ねます。発注内容を最終的にディスクに保存する時にお客様と発送に関する情報をそれまでの画面から思い出さなければならないので、システムはこれら全ての情報を覚えておく手段が必要です。

ウェブ・サイトを訪れた時点からそのウェブ･サイトを離れる時点までを、「セッション」と呼びます。通常ソフトウェアは、ユーザーがウェブ・サイトを訪れるたびにユニークなセッション番号を生成し、ソフトウェアはそのセッション番号を使用して、データベース・ファイルやストリーム・ファイル、ユーザー空間にユーザーが保存したデータを探します。ユーザーがウェブ・サイトから離れると、ソフトウェアはこのセッションを削除しなければなりません。ユーザーがブラウザのウィンドウを閉じたり、他のサイトに移動したりしたときは、システムはそのユーザーが(ある妥当な時間内には)戻ってこないという事実を記録し、もうアクティビティがないのでそのセッションを削除する必要があります。ウェブ・テクノロジー間での違いの中で最も大きなものは、各セッションのレベルでデータの保存をどのように実装しているかという点です。System iNEWS誌の本号で紹介している、異なるウェブ・テクノロジーを比較する際は、それらのテクノロジーがどのようにセッション･レベルのデータを処理しているかに着目するようにしてください。

もちろん、(私が作成した発注用アプリケーションやアマゾンのような有名なサイトで)発注を終えた後は、データはもうセッションには保存されず、システム上で永続的な発注データとなって処理待ちになります。このような方法で保存されたデータは「アプリケーション･スコープ」と呼ばれます。そのデータはアプリケーション中に永続的なデータとして存在し、リクエストやセッションの一部などの一時的なデータではないからです。今回の記事の目的を考慮して、アプリケーション・レベルのデータは私が作成したRPGサービス・プログラムが管理しますので、ウェブ・テクノロジーを比較する際にはこの部分は考慮する必要はありません。

画面の表示

ブラウザで画面に表示する際にはHTMLが使用されるので、全てのウェブ・テクノロジーはHTMLを出力します。しかし、他のテクノロジーに比べてHTMLをより容易に出力できるようにしているテクノロジーもあります。JavaとPHPは、HTMLドキュメント中にコードを組み込むことを基本として動作します。画面の設計をHTMLドキュメントで始め、特別に作られたHTMLタグを使用してドキュメントの中にコードを挿入していきます。そのようにして作られたページにブラウザがリクエストを送信すると、サーバーがそのコードを実行して、コードの出力をページ上の適切な箇所に挿入し、その結果をブラウザ上にダウンロードするので、それが画面に表示されます。CGIDEV2は、これとは動作が異なります。CGIDEV2では、作成したRPGプログラムが直接起動されます。起動されたRPGプログラムはCGIDEV2に対して(別のファイルに保存されている)HTMLの指定されたセクションを出力して、そのHTMLセクション中の一部の空欄にRPGプログラムの変数の値を入れるように指示します。

この両者の動作の違いは大きいように感じられるかもしれませんが、実際はそれほどではありません。HTMLファイルとページの中身を生成するプログラム・ロジックを分けておくのは良い方法です。こうしておくことで、ページの見栄えを変更するときに、プログラムのコードを書き直す必要がなくなります。JavaやPHPでは、HTMLコードとプログラム・ロジックを分離するにはHTMLを「includeファイル」中に保存しますが、これはRPGで使い慣れているコピー・ブックとよく似ています。CGIDEV2では、HTMLは既に別ファイルに保存されていますので、includeファイルは不要です。つまるところ、この3つのテクノロジーのいずれを使用してもHTMLを分割し、そのうちのどの部分にプログラム中の変数の値を組み入れ、どの部分が変更せずにすむようにするのかを決めなければなりません。この観点からすると、ウェブ・アプリケーションは従来のDDS画面によく似ています。フォーマットを設計し、そのフォーマットの中で変数の値をどこに表示させるかを指示するからです。異なるウェブ・テクノロジーを比較する際には、それがどのように実装されているのかに着目するようにしてください。

また、こうしたウェブ・テクノロジーで使用されているテクノロジーに「フレームワーク」というものもあります。フレームワークとは、よく使われる表示要素を提供するHTML(その多くはJavaScript)のルーチンを提供して、画面の設計を簡単に行えるようにします。たとえば、「ここにはアイテムのリストをスクロール可能な形で表示したい」としましょう。そのような場合に、スクロール可能なリストを実装するのに必要なHTMLやJavaScriptをフレームワークが提供してくれるので、自分でコードを書く必要はありません。

ウェブ・テクノロジー間の違いの中でも大きなものの1つが、どのフレームワークが利用可能で、それがどれくらい柔軟に利用可能であるか、というものです。現時点では、CGIDEV2ではRenaissance という1つのフレームワークだけが利用可能です。JavaとPHPでは多くのフレームワークが利用可能です。あまりに多すぎて、ここではその全てについてご紹介できません。残念なことに、System iNEWS誌の本号ではフレームワーク同士の比較については述べていません。それぞれの開発者に使ってもらうようにHTMLをお渡ししたからです。とはいえ、ウェブ・テクノロジーを選択する際はフレームワークについても検討することは重要です。

画面への表示について議論する際に検討しなければならないもう1点が、ツールです。IBMのWDScは、WebSphere(つまりJava)アプリケーションで使用する画面を設計するための便利なツールを提供しています。Zendは、画面設計およびPHPアプリケーション記述用の優れたIDEを提供しています。では、CGIDEV2はどうでしょうか。CGIDEV2用の開発環境は存在しません。ただし、この弱みはそれほど非難されるべきものでもないことが明らかになりました。CGIDEV2は、実はHTMLとRPGを組み合わせただけのものなのです。WDSc (いまやRational Developer for System i、つまりRdiとなっていますが)とPDMがRPGコードの編集用に便利なツールを提供していることは、皆さんもご存知でしょう。HTMLのコードを設計するためのツールは、WDScなどの優れたものも含めて、数多くあります。唯一欠けているのは、IDEを使用してHTMLをセクションに分割したり、その中に変数を挿入したりする機能です。HTMLエディタはHTMLのことだけが解釈でき、CGIDEV2のセクションや変数は解釈できないので、プレーンテキスト・エディタを使用してコードをセクションや変数に分割しなければなりません。これを数回やってみれば、それほどたいした事ではないことがおわかりいただけるでしょう。

確かに、CGIDEV2がプログラム・コードとHTMLを分離する機能を少し多く提供しているという事実は利点といえます。私は魅力的な画面を作るのはあまり得意ではないので、画面の見栄えをよくしたいときは、グラフィック･デザインに長けている友人に頼んで画面のレイアウトを手伝ってもらっています。その友人はプレーンなHTMLファイルを渡してくれるので、私はそれをセクションと変数に分割します。このタスクは、本稿で紹介している全てのテクノロジーで簡単に行うことができますが、CGIDEV2ではそれが少しだけ簡単にできます。HTMLファイルに対する変更量がやや少ないからです。ただし、PHPやJavaで同様の作業をするのはたいした手間ではありません。

i5/OSとの統合

本記事で紹介されているテクノロジーの間で一番大きな違いはといえばおそらく、i5/OSとどれくらい強固に統合されているかという点でしょう。たとえば、ここで紹介しているウェブ・テクノロジーを動作させようとしたときに直面した問題の1つが、ライブラリ・リストでした。PHPにもJavaにも、ライブラリ・リストという概念は実際にはないということはご存知でしょう。双方とも単にSQL文を実行してRPGのコードを呼び出しているだけです。必要とするライブラリがSQLサーバー・ジョブのライブラリ・リスト中にない場合は、RPGサービス・プログラムを適切に動作させるにはちょっと工夫が必要かもしれません。場合によってはライブラリ・リストを変更するコマンドを実行する必要がありましたし、ライブラリ名をプログラム・コード中にハードコードしなければならないケースもありました。ライブラリ名をプログラム・コード中に記述すること自体がそもそも、ライブラリ・リストの目的に反しているものではないでしょうか。

これとは対照的に、CGIDEV2のコードではライブラリ・リストは全く問題になりませんでした。CGIDEV2のコードは既存のi5/OSソフトウェアとインタフェースを取るように設計されているので、Apacheの構成でQIBM_CGI_LIBRARY_LISTという名前の変数が提供されており、この変数を使用することで、異なるライブラリ・リストをさまざまな環境に容易に実装することができます。

関連して、RPGのコードはサービス・プログラムを直接呼び出してそのプロシージャにアクセスすることができましたが、JavaとPHPのコードはSQLを介してでないとアクセスできませんでした。そうだとしても、ウェブ・サービスの呼び出しやJavaのツール・ボックスのServiceProgramCallクラスの呼び出しを使用することはできますが、これらの方法はより制限が厳しいものです。 SQLインタフェースの機能はこれより少し多いですが、プロシージャを直接呼び出す方法ほどではありません。プロシージャの直接呼び出しはコーディングも容易です。こうしたアプリケーションのサンプル・コードを見るときは、PHPとJavaのプログラムの開発者が上記のようなSQLの呼び出しをラップするクラスを作成して、プロシージャの直接呼び出しのように簡単に使えるようにしているかどうかに着目してください。こうした付加的なラッパを生成するには多少手間がかかるので、これはウェブ・テクノロジーを選択する際に考慮しなければならないことの1つです。

PHPのZend Core版は、PHPのコードをi5/OSに統合する際に便利なルーチンのライブラリを提供しています。JavaについてはIBMがJT/400ツールキットを提供しており、どちらかといえばi5/OSとコードを統合するためのルーチンのライブラリとしてはこちらの方がより完全に近いでしょう。しかし、いずれもRPGほどにはi5/OSと統合されてはいません。RPGは元々がi5/OSと統合するために設計されているからです。CGIDEV2は実際のところRPGに対する拡張の集合に過ぎませんから、i5/OSとの統合に関するRPGの機能をフルに活用しています。

スケーラビリティ

私見では、全社レベルのアプリケーションを開発する必要のある大規模な組織であれば、Javaが圧勝です。しかし、中小ビジネス環境での開発の場合にはこれは当てはまりません。小規模のアプリケーションの場合、CGIDEV2はネイティブのRPGコードを実行していて、しかも(名前つき起動グループを使用しLRを無効にすることで) RPGコードはメモリ上に常駐するように設計できるので、圧倒的に他の選択肢を凌ぎます。こうして、プログラムがメモリに常駐したまま、しかもファイルもオープンしたままなので、プログラムがやるべきことは各リクエストを処理するだけになり、毎回の呼び出しが非常に高速になります。

このモデルは、UnixやWindowsのサーバー上で使用されている従来のCGIモデルとは異なります。従来のモデルでは、新しいプロセス(i5/OSのジョブに相当するもの)が生成されると、プログラムがディスクからメモリに読み込まれます。メモリに読み込まれたプログラムは、URLでエンコードされた文字列を構文解析してそのパラメータを読み取り、次にファイルをオープンして処理を実行しないと、最終的に呼び出し元に戻れません。しかしi5/OSでは、プログラムが最初に呼び出された時点でそのプログラムとCGIDEV2拡張が起動グループに読み込まれ、そこでメモリに常駐するので、それ以後のプログラムに対する呼び出しが高速になります。CGIDEV2はURLでエンコードされたデータの構文解析を処理しますので、それに関する処理部分を自分でコーディングする必要はありません。その結果、CGIDEV2プログラムは従来のCGIアプリケーションが苦しんでいた欠点に悩まされることはありません。CGIDEV2プログラムは、小規模の環境では、JavaやPHPを凌ぐ性能を発揮します。

また、PHPとJavaはともに、既存のCGIアプリケーションに比べて性能を向上させるためのメカニズムも備えています。PHPはApacheのモジュールとして稼動しますので、PHPのコード自体もApacheが読み込まれる際に読み込まれ、Apacheサーバーのインスタンスとともにメモリに常駐します。ただし、PHPは呼び出されるたびにそのソースコードをディスクから読み込まなければなりません。PHPは解釈実行型の言語なので、もしPHPがコンパイル型の言語だったと仮定する場合に比べると、その実行速度は速くありません。小規模の環境ではRPGの方が速いのはこうした理由によります。規模が大きくなるにしたがってPHPは高速になっていきます。それは、複数の同時スレッドで実行でき、より多くのクライアントを同時に処理できるからです。

Javaもまた、その実行環境をメモリ上に保持します。Javaの実行環境は、WebSphere Application Serverかあるいはオープン・ソースのTomcatサーバーを使用した別のウェブ・サーバーとして実装されます。ただし、こうしたサーバーとそれを実行するのに使用する必要があるJava仮想マシン(JVM)は、かなりの追加メモリを必要とします。より小規模のあまりパワーのないマシンでは、JavaアプリケーションはPHPやRPGに比べて極端に遅くなります。メモリを大量に搭載した大規模なサーバーでは、それほど問題になりません。何千という同時使用ユーザーを処理する場合は、Javaによるアプローチの性能が他を圧倒します。

ウェブ・テクノロジーを検討する際は、必要とするスケーラビリティのレベルが重要な要因となります。非常に多数のユーザーを扱う場合はJavaが最善の選択肢でしょう。少数のユーザー(たとえば200人以下)の場合はCGIDEV2が他を圧倒します。PHPはその中間に位置し、Javaに比べるとずっと少ない資源でCGIDEV2よりも大きなスケーラビリティを提供します。

学習曲線

もう1つ重要な検討項目が学習曲線です。あなた自身が既にRPGを良くご存知で、RPGに詳しい人がチームにいるのであれば、CGIDEV2を学習するのは非常に容易でしょう。結局のところ、CGIDEV2はRPGのコードから呼び出す、サブ・プロシージャの集合に過ぎないのです。一般的に言って、記述するコードはRPGコードになるでしょう。RPGについては既にご存知なのですから、CGIDEV2の学習曲線はなだらかでしょう。一方、CGIDEV2はPHPやJava環境に比べると、提供しているウェブ用の操作や関数が少なくなっています。

また、PHPは簡単に習得できる言語であるということも触れておくべきでしょう。RPGやJavaの経験が全くない人は、ここで紹介する3つのテクノロジーの中では、PHPが群を抜いて簡単に習得できます。PHPは、ウェブ・アプリケーション記述用に特別に考えられた、強力でありながらシンプルな言語です。たとえRPGの経験が豊富であっても、PHPを習得するのは難しくないでしょう。

これに対してJavaは、結局のところ、まったく話が異なります。私は1990年中ごろにJavaを習得し始め、Javaだけでアプリケーションを書いたこともあります。しかし、Javaに満足したことは一度もありません。Javaに関する記事を読むたびに、まだまだ知らないことがたくさんあり、学ぶことがたくさんあると思い知らされます。学習曲線は永遠に続くように思えます。ただし誤解しないでください。Javaは学習しがいのある言語であり、習得してしまえば開発環境を提供してくれるだけでなく、ソフトウェア工学やアプリケーションの設計方法について多くを学ぶことができます。しかし、学習曲線があまりきつくない方を望むのであれば、Javaはソリューションとしては適していません。あくまで、本稿の筆者としては、お勧めしません。

業界のサポート

CGIDEV2はウェブ・アプリケーションを開発するための優れた環境です。私のようなRPGの経験が豊富な人間にとってみれば、これにかなう環境はありません。しかしCGIDEV2に対するIT業界のサポートの手厚さということになると、CGIDEV2は他の選択肢と比べ物になりません。CGIDEV2はSystem iのコミュニティでは広く使用されていますが、System iのコミュニティは市場のごく小さな部分を占めるに過ぎません。JavaやPHPはクロス・プラットフォームの言語であり、主要なコンピュータ・プラットフォームで利用可能です。この2つの言語はともに広く実装されており、それゆえ、これらのテクノロジーに関する書籍やチュートリアル、サンプル・プログラム、オープン・ソースのソフトウェアを探すのは容易です。実際、優れたPHPアプリケーションはたくさん出回っており、そうしたアプリケーションを簡単にダウンロードしてシステム上で実行させることができます。さらに、そうしたアプリケーションのほとんどがオープン・ソースですので、入手して自分の用途に合うように修正することができます。CGIDEV2用のチュートリアル、オープン・ソースのソフトウェア、記事、サポートなども入手可能ですが、JavaやPHPに比べると圧倒的に少量です。

次のステップ

ひとつのソリューションが万人のニーズを満たすとは限りません。会社が異なればニーズも異なり、そうしたニーズに合うさまざまなツールがありますので、あるソリューションが他のソリューションよりも優れていると言うつもりはありません。そうではなくて、どのテクノロジーにも長所と欠点があるということを明確にしたいというのが私の意図です。ここからは本誌の3つの記事をお読みいただき、テクノロジーを比較してみることをお勧めします。本稿でご紹介した考えを思考の糧にして、検討すべきさまざまな概念を理解する際にぜひお役立てください。最終的には、ここで紹介した記事が正しい判断の一助となれば幸甚です。