現在、進行中の内部制作システムについて。
基本、今のコラボロジックのお仕事は受託開発が中心です。
ポータルサイトの機能部分とか、小さな業務システムとかがほとんどです。
特に業務システムを作っていてぶち当たる問題があります。
私のようなSOHO事業者に発注して頂けるエンドユーザ様に共通しているのは、
・比較的小さな組織か大きな組織なら部署単位の予算で発注して頂く組織
・IT化には比較的熱心
・過去にもオープンソースを利用したものや、小規模ソフトハウスに発注して稼働中のシステムがある
と言う感じになります。
どうして、SOHO事業者にこうした仕事が回ってくるのかと言えば、
予算が小額なので大規模なソフトハウスには発注しづらいと言うことがあると思います。
しかし、こうした小さな単位で業務システムを構築していくと、
個別のシステムがカバーする業務の境界線上で面倒な作業が発生することが多々あります。
例えば、これはシステムを管理する部署の発生する問題ですが、
システムごとに認証情報が管理されていたりすると、
そのための対応がたくさん発生してしまいます。
会社に新人さんが入ってくると、いっぺんに認証情報を登録しないといけないので、
とても面倒です。漏れがあったりして、使えないシステムが出てきて、
なんとなく放置されてしまい、システムが実際には使われなくなると言う状態も考えられます。
例えば、お客様からの受注情報を管理するシステムと、
原材料を発注するためのシステムがあったとすれば、
受注した案件に必要な原材料を受注システムを参照しながら入力すると言う、
これまた面倒な作業が発生することになります。
これを解決しようとすると、過去に構築したシステムを変更するか、
統合された業務システムを新しく用意するかと言う話になってしまいます。
既存のシステムを変更するのは、同じ業者とのつながりが生きていないと難しいですし、
もともと、大きなシステムを作れないから小さな単位で作っていたので、
統合システムを作れるのは、その後、業績が上がった会社だけです。
そんな時、既存のシステムの機能をそのまま使って、
インターフェイスだけを新しくこさえることができれば、
低予算で業務効率化を継続することが出来るのではないかというのが、
作成中のシステムの目的になります。
一般的に使われている言葉で言うと、「マッシュアップ」とは、
インターネット上に公開されているサイトの機能を組み合わせて、
新しいサービスを作り上げることですが、私はこのシステムを使って、
「社内システムのマッシュアップ」をしたいと考えています。
多くの場合、マッシュアップをするときには、公開されているサイトのWebAPIを利用します。
しかし、社内システムにはじめからWebAPIが提供されていると言うことはきわめて稀です。
なので、WebAPIが提供されていないWebシステムの機能を扱えるようにする必要があります。
また、既存のシステムに修正が必要となると、これはとても面倒な作業になってしまいます。
既存システムの開発者が修正を加えるならいいのですが、そうでない場合、
ドキュメントが整備されていなければ最悪の場合はソースコードや動作を解析して、
中身の仕組みを調べると言う困難な作業が必要になるからです。
そこで考えました。
「WebAPIはXMLなどでデータを出力するが、HTMLだってマークアップ言語じゃないか」と。
つまり、普通に画面を表示しているHTMLから必要なデータを引っ張り出せる仕組みさえ用意すれば、
WebAPIを提供していないサイトでも、マッシュアップ可能になると考えたのです。
すでに、そうしたことを目的としたものが存在します。
「スクレピング」と言われる機能を提供するサービスやプログラムです。
「スクレイピング」は新聞などを切り抜く「スクラップ」をすることです。
例えば「OpenKapow（http://openkapow.com/）」と言うサービスが、
スクレイピングを支援する仕組みを提供しています。
私は実際にある案件でこのOpenKapowを利用しました。
欠点としては、OpenKapowの開発元が提供するサーバで動作することと、
このサーバの動作が結構不安定であること、
そして、複雑なデータを切り出すようなことをしようとすると、
ほとんどプログラムを書くことと変わりない作業を、
フローチャートを描くような操作で行わなければならないこと。
例えばページャ付きの記事一覧のすべてをRSSにはかせようとすると、
ループが二重になったり、条件分岐を使っていらないデータを無視したりするようにしないといけない。
プログラマなら、普通にプログラムを書けばこうしたロジックを書くことは比較的簡単ですが、
個別の処理をステップごとにマウス操作で追加して、処理の流れを書かないといけないので、
とても面倒でした。
一方で、はじめからプログラムを書いてこのスクレイピングをしようとするのもこれまた手間です。
認証などが必要なサイトを参照するなら、その画面までの画面遷移をプログラムの処理として、
再現してやらねばならない場合があります。これは結構面倒です。
OpenKapowでは、ブラウザで閲覧するのと大して変わらない手まで、
この画面遷移をスクレイピングするプログラムに行わせることが可能です。
そこで、OpenKapowとは実現方法がだいぶ異なりますが、
例えばExcelのマクロの自動生成のような感じで、ブラウザ上で行った操作を記録し、
そのデータから画面遷移を行うスクリプトを自動生成することを考えました。
これなら、難しくありません。
出力されたスクリプトに修正を加えて、目的の動作を実装することが出来ますし、
単純に、必要な画面までの遷移をショートカットするだけなら、
コーディングをする必要もありません。
これに加えて、スクレイピングを支援するための仕組み、
HTML上の特定のタグ内の記述を引っ張り出してきたり、
正規表現で必要な箇所だけを抜き出す仕組みと、
そうしたスクリプトを書くための支援ツールがあれば、
少ない手間でマッシュアップをすることが出来そうです。
これにプラスして長年考えていたWebのプログラムだからこその問題点を解決したいと思いました。
それは、「スクリプト上に画面遷移が明確に記述されない」と言う問題です。
Webアプリケーションは、多くの場合、その仕組み上、ブラウザからWebサーバに送られたリクエスト、
すなわちイベントに対応する処理を記述していくと言う形式になります。
はじめからイベント駆動形式のプログラムが強制されているわけです。
イベント駆動形式のプログラムは今では当たり前といって良いほど一般的で、
基本的には問題にならないのですが、ちょっとした、ツール的なものを書きたい場合には、
これが面倒の原因になります。
例えばLinuxなどにアプリケーションをインストールするためのインストールスクリプトなどは、
イベント駆動形式ではなく、処理を順番に書いて、必要に応じてプロンプトから情報を入力する、
対話形式のインターフェイスを簡単に用意しています。
これをWebのインターフェイスを作る際にも出来ないかと考えたわけです。
これをやるためには、「プログラムの動作がリクエスト単位で簡潔する」と言う、
Webの仕組みの持つ制約を超える必要があります。
そこで、この対話形式インターフェイスの動作を記述するスクリプトと、
ブラウザからのリクエストを受け付けるスクリプトを分割することにしました。
ブラウザからのリクエストを受けたスクリプトは、
対話型インターフェイスの動作を記述するスクリプトを起動します。
対話型インターフェイスのスクリプトは、要求を受け取ると、
画面に表示したい情報などをレスポンスとして返すわけですが、
レスポンスを返しても停止せず、次の要求が来るまで待機します。
リクエストを受け付けたスクリプトはブラウザに画面を返すと終了しますが、
次のリクエストを受け付けたスクリプトが、
同じ対話型インターフェイスのスクリプトに入力された情報を飛ばすことになります。
これによって、スクリプトの上から下に順番に画面表示や入力の受付を記述するだけで、
対話型のインターフェイスを作成することが出来るようになります。
しかし、まだ問題があります。
ブラウザからアクセスするWebアプリケーションは、ブラウザバック（戻るボタン）や、
リロード（再読み込み）などに対応する必要があります。
処理を上から順番に書いてしまった対話型インターフェイスのスクリプトは、
期待していたデータと違うデータを受け取ってしまう可能性があるのです。
それに対応するため、リクエスト受け付けたスクリプトは、
対話型インターフェイスのスクリプトに対して、
すでに送信済みのデータではないかどうかをチェックすることにしました。
もし、ブラウザバックやリロードなどで同じ画面を再表示することを要求された場合は、
対話型インターフェイスを新しく起動し、要求されたページにたどり付くのデータを、
自動的に入力することで、この問題を解決しました。
まだまだ、ごく一部の機能しか実装できていませんが、
どうにか形にして、中小零細の企業のIT化を一歩先に進めたいと考えています。
