エンジニアの独り言

少し前の話になりますが、有害サイト規正法案が参議院で可決され日本新聞協会やネット事業者が反対声明を出すなど話題になりましたね。また、先日携帯ショップに行ったのですが、未成年者向けのフィルタリングサービスについての注意書きがあり、親の同意が無ければ未成年者にはフィルタリングサービスが適用されるという事が書いてありました。
Webの普及によってそれを利用した犯罪が急増してきたので、フィルタリングは特に子を持つ親にとっては安心感の持てるサービスなのかもしれません。

でも、それで本当に安全ですか？

近年のWebの普及によって、情報量が急速に増加したため、扱い方を考えるよりも先に大量の情報が入ってきてしまい、危険かどうかも含めてあまり深く判断しないまま受け入れてしまうようになり、結果としてWebそのものが「得体の知れないもの」という印象が根付きました。
とはいえ、臭いものには蓋をしろ的な考え方で、一方的にシャットアウトしてしまうのは一見安全のように思えますが、提供する側の安全印がついた情報だけを受け入れることで情報に対する受身体質を助長し、（情報に対して）自分で考え判断していくという事が薄れてしまいます。
また、規制して防いだところで、（人間の心理として隠されたものほど気になるもので）必ず「抜け道」が作られ、防ぎきる事はほとんど不可能です。そうなると、規制して多少のリスクは減りますが、危険な事にはなんら変わりはなくなってしまいます。

それを回避ためには、臭いものには蓋をしろではなく、本当に臭いものなのか、（臭いとしたら）何故臭いのかを自分で考えて判断させ、情報と上手く向き合えるようにすることが大事です。そうならなければ、いつまでたっても情報は「得体の知れないもの」のままですし、本当の意味で活用できなくなってしまいます。
大量の情報が入るようになったことで、単に危険度だけが増したわけではなく、色々な可能性も広がってきたという認識をもち、情報と上手く付き合い自分の考え方の幅を広げるチャンスと捕らえ、上手く活用することが安全への近道ではないでしょうか。


林田 宏介

 

こんにちは。アクセンチュア・テクノロジー・ソリューションズの鉾之原です。


昨日、今年の新卒入社の方達と一緒に飲む機会があって、「ブログ読んでます！」とか言われちょっと嬉しかったのですが、「でもあまり書いてないですよね」とか、先輩からは「しかもiPhoneしか書いてないじゃん。」とか「毎日更新しろよ。」等と突っ込まれ、もちろん酔っていた私は「はい！頑張ります！」と元気よく答えてしまったので、慌てて書き途中の原稿を開いております(笑)。

新卒入社の方に「鉾之原さんはテクニカル・スペシャリストなんですよね？何のスペシャリストなんですか？」と聞かれた時に「う〜ん、Webアプリケーションでその中でもクライアント周りが好きだね〜」と答えてしまったので、今日はそれに関する話題です。


さてさて、リッチクライアントという言葉が出てきてから久しくなりますが、今では一般的なWebアプリケーションでも Ajaxや、Flashを当たり前のように活用し、それまでの紙芝居的な動きからダイナミックな動きをみせるサイトが多くなりました。私たちが主に開発としている業務アプリケーションの実装にはそういった最新技術を積極的に取り込む機会はそれほど多くないのですが、ここ数年の間で社内の別プロジェクトでリッチクライアントの要件があることを聞いたり、実際に私も開発に携わったりと、リッチクライアントを採用する機会が増えてきているような気がします。

リッチクライアントと言ってもさまざまな種類がありますのが、ここで今後主流となるであろう主なものを簡単にまとめてみると次のようなものがあります。

・Ajax(Asynchronous Javascript + XML)
従来のWebアプリケーションとなるHTMLとJavaScriptでの実装です。JavaScriptのXMLHttpRequestオブジェクトを使用して、サーバと非同期にデータのやり取りを行うことで画面の切り替えを行うわず、部分的に表示を変えることでローカルのアプリケーションのように画面を構築できます。

・Adobe Flex / AIR(http://www.adobe.com/jp/products/flex/)
Adobe Flex はリッチインターネットアプリケーションであるFlashのSDKと統合開発環境です。これまでの多くのプログラマの障壁となっていたGUIベースでの開発方法から、MXMLというXMLでのユーザーインターフェイスの定義と、ECMAScriptに準拠し、オブジェクト指向開発が可能な ActionScript3.0でのロジック実装というプログラマに優しい開発環境を提供しています。
Adobe AIRは、ブラウザ上で動作するFlashのに対してリッチインターネットアプリケーションをローカルアプリケーションで開発するためのフレームワークです。後述しますが、データベースが組み込まれているためオンラインデータの保存をしたり、ローカルファイルへアクセスすることが出来ます。

・Microsoft Silverlight(http://www.microsoft.com/japan/silverlight/)
Microsoftの提供するFlashと同様にリッチインターネットアプリケーションを開発するためのフレームワークです。XAMLというXMLでのユーザーインターフェイスの定義と、ロジックの実装にはSilverlight1.0ではJavaScript、Silverlight1.1ではJavaScriptに加え.NETや動的言語で開発することができます。


他にもCurlや、MozillaのXULとリッチクライアントを実現するアーキテクチャはありますが、その多くのアーキテクチャがユーザーインターフェイスの定義をHTMLのようなマークアップ言語、ロジックの実装にはJavaScriptを始めとするスクリプト言語を採用しているので、今後のクライアントアプリケーションの実装にはこの「マークアップ言語+スクリプト言語」の組み合わせが主流になっていくかと思います。


もう一つ。

最近、ちらほら耳にするようになってきたのがオンラインデータのローカルへの保存です。基本的にWebアプリケーションはネットワークを介してサーバーと PCがデータのやり取りを行うため、ネットワークに接続されている状態でないと使用できません。しかし、モバイルで高速通信が普及してきたとはいえPCが常時ネットにつながっているわけではありませんし、社内のネットワークからしか接続できない業務Webアプリケーションなどの場合は、オンラインデータを参照することが出来ません。そこでオンラインデータをローカルへ保存し、オフラインでもデータの参照、編集できるようにしようとするのがオンラインデータのローカルへの保存です。

オンラインデータのローカルへの保存というアーキテクチャは比較的容易で（※画面表示だけであれば）、オンライン時にブラウザやプラグインが管理するデータベースに登録し、オフライン時にデータベースからそのデータを取得して画面表示を行います（ここで使用されるデータベースには組み込み系でよく利用されるRDBMSであるSQLiteが採用されている事が多く、多くの開発者に馴染みのあるSQLが使えます。）。
実は、このオンラインデータのローカルへの保存のアーキテクチャの幾つかは既に存在していて、実際に利用することが出来ます。

・Firefox3、Safari3.1といったブラウザ自体の機能
HTML5にはClient-side Database Storageという仕様が実装されております。実際、HTML5はまだドラフト版のリリースで正式なリリースは行われておりませんが、Firefox3 とSafari3.1は先取りして対応しています。WebアプリケーションからJavaScriptを通じてデータベース(SQLite)とデータのやり取りを行います。

・Google Gears(http://gears.google.com/)
Googleがブラウザのプラグイン形式で提供している拡張機能です。このプラグインをインストールすることで、オンラインデータのローカルへの保存機能のないブラウザでも、この機能が使えるようになります。これもやはり、JavaScriptを通じてデータベースとデータのやり取りを行います。現時点 (2008年8月21日)ではWindowsXP/VistaではFirefox1.5以上、もしくはInternetExplorer6.0以上で使用できます。

・Adobe AIR(http://www.adobe.com/jp/products/air/)
先ほど紹介したAdobe AIRはブラウザアプリケーションではないのですが、標準の機能としてローカルへの保存機能をもっており、ActionScriptを通じてデータベース (SQLite)とデータのやり取りを行います。また、Adobe AIRはPC上にファイルを作成したり、参照することも出来るので、ブラウザアプリケーションよりも多くの機能が実現できます。


システム開発を行っていると、何度か「社内のオンラインデータを家でも見たいんだけど。」というような要望を受けたことがあって、今まではシステムで対象データをExcelに出力することで実現することがありました。このオンラインデータのローカルへの保存は代替案として利用できそうです。
勿論、「このアーキテクチャのサポート先ってどこになるの？」など実際にシステム開発に活用するまでのハードルはまだまだ高いので、主流になるにはまだまだ先の話になるかと思います。ただ、クライアントからの要望に対して提案の一つとして含めることで少しでも開発したシステムがクライアントの価値につなげられるようにしたり、実際にこのアーキテクチャが採用となった場合に迅速に対応できるように、今から勉強しておくのも一つかと思います。


でわ、鉾之原でした。

システム開発の現場で、“業務システムのWeb化”という言葉をよく耳にします。
要は業務システムをWeb化またはWebの技術を利用したシステムにするということなのですが、ここ数年よく聞くようになりました。
それに伴って、ユーザインターフェースの表現力を高めるためのリッチクライアント製品や、Webアクセスを効率化させ、高速化させるような製品が各製品ベンダーから提供されるなど、以前はWebシステムの弱点とされていた部分が改善され、随分使い勝手が良くなってきました。
読者の中にもWebシステムに携わっている方も多いと思いますし、これからも益々増えるのではないでしょうか。
でも、ちょっと待ってください。

そのシステムのWeb化、本当に妥当ですか？

技術が発達したことと、色々な製品が出てきたことで、Webで弱点とされていた画面の表現力の弱さやWebアクセスに伴うレスポンスの悪さなどが解消はされ、業務システムとして耐えられるだけのモノになってきたと思います。
ただ、業務によっては短時間に大量のデータ入力を行わなければならないようなシステムなど、Webでは実装が難しいようなケースもまだまだあります。
しかし、そういったシステムでも強引にWeb化してしまっているようなケースや、反対にWeb化した方が良いものをWeb化しないというケースもあり、システム化によって逆にユーザの業務効率が落ちてしまうというような最悪のケースを招いているケースも残念ながらあります。
しかも、理由が「Web開発のスキルを持った社員が多いから」など、開発を行うシステム会社側の都合によって決められてしまっているケースが多く、何のためにシステム化するのかわかなくなってしまいます。

様々な便利＆進んだ技術が出てきている昨今だからこそ、“ただなんとなく作る”のではなく、誰のためにシステムを作っているのか、一度考え見直してみてはいかがでしょうか。


林田宏介

こんにちわ。アクセンチュア・テクノロジー・ソリューションズの鉾之原です。


先週末に発売されたiPhone。ここ数日ブログなどのネット界隈ではiPhoneの話題だらけで食傷気味かもしれませんが、同僚からは「前回のエントリーでiPhoneについて熱く書いていたんだから当然買ったんだよね？」とつっこまれてしまったので、今回も前回に引き続きiPhoneネタです。

で、もちろん買いました。iPhone 3G。
2、 3日使ってみた感想は「iPhoneは携帯電話」というよりも、「電話機能のついた掌にのるコンピュータだなぁ」の一言。実際は、文字入力がもっさりすることが度々あったり、Safari（iPhoneに内蔵されているWebブラウザ）が頻繁に落ちたり、不満も結構あるのが正直なところです。しかし、こうした（日本の携帯電話ではあり得ない）問題があっても、それが些細な事かのように思えてしまうほどの魅力がこのiPhoneにはあります。
数年前、データカードとZaurusを併用してネットを利用してましたが、WILLCOMのZERO3というスマートフォンの登場(実際に私が使い始めたのはAdvanced[es]からですが)により、一台で電話とインターネットが出来るようになりました。しかし、iPhoneを持ってから、「スマートフォンは電話がメインの機能で、それ以外がおまけの機能だったんだなぁ」と感じるようになりました。というのも、WindowsMobileの場合はネッ トに接続する際にPHSの回線を使うのか、それともWifiで接続するのかを明示的に選択する必要があったのに対し、iPhoneはその環境にあった最適な接続方法を自動的に判別するのです。つまり、Wifi環境があれば自動的にWifi接続になり、そうでなければ3Gの回線を使うようにiPhoneが自ら決めるのです。これは本当に些細な事なのですが、WindowsMobileを使用したことがある者にとっては信じられないくらい快適な環境です。回線を気にしなくなった時点で電話機能自体がおまけになったような感覚はここから来ました。

繰り返しになってしまいますが、文字入力にストレスが溜まることがあったり、アプリケーションがよく落ちたり、メール環境を整えるのに手間がいったりと、普通の人が使うにはまだまだ敷居が高いのも事実です（この面では日本の携帯は良くできてるなぁと思います）。OS1.0の頃にも同じような問題がありました が、バージョンアップによる改善があったので、これらの不満はいずれ解消されることでしょう。
ADSLや光などのブロードバンドによってネットがより身近なものになり、生活が変わった人も少なくないはずです。そしてこのiPhoneによって、それまでパソコンの前にいないと近 寄れなかったネットが、常にそばにあるものになります。これからiPhoneのようなデバイスが益々増えていく事と思います。どれがシェアを取るかなんて分かりませんが、この十数年にあるかないかの技術革新であることは間違いないと確信しています。


さて、話は変わりますが今日から私は数日間、北海道出張に行ってきます。今私が携わっているプロジェクトの実装部分をATSの北海道デリバリーセンターで行うためのKTです。いわゆるニアショア開発というもので、私は今回初めての経験で多少の不安混じりのワクワク感で北海道に行ってきます。次回のエントリー では北海道での模様をお伝えできればと思います。


でわ、鉾之原でした。

突然ですがプログラミングは好きですか？
プログラミングする際、少し難しくても効率の良いAPIを使ったり、オブジェクト指向言語を利用している場合に効率化のためにパターンなどを積極的に取り入れてプログラムを作ったり･･･なんていうことは、ありませんか？私もプログラミングは好きですし、（であるが故に）以前はよく、そういうプログラミングをしていました。
でも、一度自分が作ったプログラムを見直してみてください。

そのプログラム見やすいですか？

例えば、他の人が開発したアプリケーションの拡張や修正をしなければならない場合で、設計書など仕様を把握できるものがほとんど無く、プログラムを解析する以外に仕様が確認できないというような状況を経験したことはありませんか？

私は何度もそういった状況で、必死にプログラムとにらめっこした経験があります。
そういう時、冒頭に書いたようなプログラムだと作った人間以外には難しく感じてしまい、プログラム解析に時間がかかって対応が遅れたり、対応したとしても実は見落としがあって修正した以外の箇所で障害を発生させてしまう･･･といったことが多々あります

対応するのが熟練プログラマーの場合はそれでもなんとかなるかもしれませんが、経験の浅いプログラマーの場合にはどうなるでしょうか？分析に手間取り、いつまでたっても対応が出来ない･･･なんてことも、平気でありえます。

作った本人にとっては見やすく効率の良いプログラムかもしれませんが、他の人にとっては難しいだけの見づらいプログラムになってしまっているかもしれません。

自分はそんなことはしない！と思っている人（こそ）は、下記をチェックしてみてください

・IF分岐などの条件文が長すぎる
・プログラム中のコメントがなさ過ぎる、もしくは細かく書きすぎている
・プログラム（クラス）の分割を細かくやりすぎている
・Javaなどオブジェクト指向言語の場合に、積極的にインターフェースや継承を使っている
・難しく実装していて、一見すると効率よくみえるが、よく見ると非常に単純かつ簡単に実装ができる

これは私の今までの経験から、見づらいと感じたプログラムに共通したことです。
思い当たるところはありませんか？

プログラマーとして熟練してくると、効率よく簡素に作ろうとして逆に難しく考えすぎてしまうことがよくあります。
プログラムは作ったら終わりではなく、その後何年も使われ続けるものです。難しいプログラムは保守性が下がり、その後何年も苦しむ元凶（？）の元になります。特に、保守担当が新人の場合は、その悲劇たるや想像するだけで悲惨なものあがります。

プログラミングをする時は誰が見てもわかりやすい物を作る！という（当たり前のようで、意外に実践されていない）意識を、プログラマーは持たなければいけないのではないでしょうか。

林田宏介