GARA yokohama

先日は、家の奥さんの誕生日でした。

なので、どこかに食事に行きたかったわけですが、子供がまだ小さいので、洒落たフレンチやイタリアンという訳にもいかず、ワールドポーターズに行くことにしました。

誕生日、ワールドポーターズはお奨めです。　）“ハッピー・エブリ・バースデー”と言うサービスで、2Fの受付に、その日が誕生日（前後1日まで可）だと言うことを証明するもの（免許証とか）を提示すると、駐車料金が終日無料+記念品（マグカップだった）+“バースデーパスポート”を貰えます。　この“バースデーパスポート”をショップorレストランで提示すると、色々なサービスが受けられます。

コールド・ストーン・クリマリーとか、トッピングのサービス+αで店員がスペシャルな歌を歌ってくれるらしい。　でも、ちょっとそれもねぇ．．．　周りの客に注目されて、恥ずかしいし、ケーキぐらいサービスって感で良いんですよ。と、このGARA yokohamaに入りました。　（家の奥さん、インド料理好きだしね）

コースを頼んで、大体出切ったところで、なかなかサービスのケーキが来ないなぁ．．．と、店員に催促すると、「今お持ちしますっ」、と、感じの良い店員。　しばらくすると、シフォンケーキを誕生日風にアレンジされたケーキをもった先ほどの店員を先頭に、後ろにインド人の店員が5人列を成して．．．　「お誕生日おめでとうございマース」　お、恐れていたことが．．．

　店員：「お名前はなんでしょうか？」

　奥さん：「結構です．．．」

　店員：「大丈夫です、ばっちり盛り上げますので」

　奥さん：「．．．XXXです。」

　店員：「みんな、しっかり盛り上げていけよ！！　Happy birth day to you. Happy birth day....」

　（しかも、インドっぽく銅鑼を鳴らしてくれる。）

僕も、ここで恥ずかしがってもしょうがないので、一緒に盛り上げちゃいました。

変な汗、かいちゃいました。　:)

とても、雰囲気の良い親切なお店でした。

誕生日にはお試しあれ。

五輪書 (講談社学術文庫)

★★★

五輪書 (講談社学術文庫) (文庫)
宮本 武蔵 (著), 鎌田 茂雄

．．．と、なぜ突然こんな本を読もうと思ったかと言うと、剣法を極めた宮本武蔵の書いた本で、400年以上も読まれていると言うので、もしかしたら日本人として一生の内に一度は読んでおくべき本なんじゃないかと．．．

いや、まあ、本当に剣法の本でした。
ですが、この本から得られたことは。
- 形式にとらわれても、剣の道は究められない
- 訓練と実戦の積み重ねによってのみ臨機応変に対応する力を養える
- 目先の動きにとらわれず全体を見る

と、いうところなのでしょう。　こういう本を読みなれた人は、もっと別な得るものがあるのかも知れませんが．．．

流石に、完全に剣法の本ですので、どうなのかなぁ．．．

プロフェッショナルの条件

★★★★★

プロフェッショナルの条件―いかに成果をあげ、成長するか (はじめて読むドラッカー (自己実現編))

P・F. ドラッカー (著), Peter F. Drucker (著), 上田 惇生 (著)

久しぶりのブログです。
技術士口頭試験も終わり、ちょっと前に日経に広告の載っていたこの本を読んでみました。　とは言え、2000年のものですから、そう新しいものではありません。

かなりの高評価ですが、内容は題名からイメージするものとはちょっと違います。　歴史とここ最近の社会の状況から、これからの社会がどの様になっていくのか、また、個人はどういった生き方をすべきなのか、という事を述べた本ですが、何しろ説得力があります。　それは、2000年に書かれた本であるにも関わらず、ポスト資本主義社会としての知識社会を予言する内容で、起こりつつあった変化を適切に分析している点です。

ドラッガー、今後も数冊手に取ってみようと思います。

オブジェクト指向を家の奥さんに説明する

技術士口答試験、想定問題

「オブジェクト指向を一般の人でも分かるように説明してください」

まあ、ありえる質問ですよね。　Object Maniaを自称する身としては、これは綺麗に回答したい。
（ちなみに、まだ家の奥さんには説明してないです。）

こういうの、割と好きです。
自分の思考パターンとしても、物事を厳密に説明するのには向いていない構造をしている気がする。　なので、厳密性を排除して、分かりやすさを追求して良い説明は楽しい。

オブジェクト指向というのは、プログラミングやデータの表現の方式の一種で、クラスとインスタンス、カプセル化、継承、ポリモルフィズムといった代表的な概念をもっています。　これは、後の文章を読めば分かるように書いたつもりなので、あまり気にしないで読みすすめてください。

最近のソフトウェアは非常に複雑なので、このような考え方が必要になってきたわけですが、どのような場面で使われているか、Excelを例に説明してみます。
（始めに断っておきますが、本当にExcelがこういう実装になっているかは別です。　違うだろうなぁ、と思いつつも概念を理解するためにはこの説明がよいかな？と思いながら書いているところもあります。）

Excelでセルを右クリックしてプロパティを見ると、背景色を変えることができます。　この背景色を赤にすれば画面上でセルは当然赤くなります。　これがプログラムでどのように処理されているのか考える際に、オブジェクト指向でない場合、今選択されたセルの左上と右下の座標をなんらかの形で入手して、その範囲を赤く四角で塗りつぶし、その上にセルに記入されていたテキストを乗せるといったような処理になります。　ただし、実際には罫線であったりテキストのフォントは何か？大きさは？等考えなくてはいけないことは非常に多くなります。　ここで、セルの座標やフォントといった情報をどうやって管理するのか考える必要があるわけですが、配列のようなテーブルを用意してそこに格納しておくといったやり方でも出来るかもしれませんが、非常に複雑です。　オブジェクト指向のプログラムでは、セルに対する処理や処理に必要な情報は、セルと言うプログラムの塊の中に全て隠蔽してしまいます。　どういうことかというと、一つのプログラムの塊の中に、セルの背景色と一緒にセルの座標、フォント、フォントタイプ、フォントの大きさといった情報を全て入れ込んだ状態にしておき、そのプログラムの塊はそのセル以外のことは基本的に考えない形にしておきます。　そして、外部からセルの背景色を変えるよう指示があった場合、その処理はそのプログラムの中で行い、必要な情報もそのプログラムの中から集めて画面上でセルの背景色を変える一連の処理を行います。　このような考え方をカプセル化と言いますが、前の例と比較すると必要な情報の入手は格段に楽になります。

ところが、Excelのセルの場合であれば、セルは大量にあります。　それぞれのセルは背景色もフォントも異なります。　これをどう処理するかといえば、100個セルがあれば、100個似たようなプログラムの塊を作るのです。　しかし、Excelの場合どの程度のセルがあるかはじめから分かっているわけではありません（実際には分かっているのかも知れないけど、まあ突っ込まずに．．．）から、元となるプログラムの塊があって、それをコピーして100個のセルをつくります。　セルの追加削除があれば元となるプログラムからコピーして、新しいセルのプログラムを作ります。　この時に元となっているプログラムをクラス、100個のコピーで作られたプログラムをオブジェクトと読んでいます。

継承というのはこのクラスを定義する際のテクニックの一つです。　例えばセルで右クリックをすると、そこにはカット、コピー、ペーストといったようなコマンドが並んでいますが、これはテキストボックスでも同じで、行や列を選択しても同じです。　これらのコマンドはオブジェクト指向ではメソッドと呼ばれていますが、この様なExcel上の全ての選択可能な要素のクラス一つ一つにそれぞれメソッドを定義をしていくのは面倒です。　そこで、そういった様々なクラスで共通するメソッドはある抽象的なクラスで定義してしまい、セルやテキストボックスといったそれぞれのクラスはその抽象的なクラスを親としてその定義をコピーし、それぞれのクラスに特化したメソッドだけを差分として定義しようという考え方が継承です。

このようにオブジェクト指向ではプログラム上必要となる様々な要素をクラスとして定義し、それをオブジェクトとしてコピーする（これをインスタンス化するとも言う）ことによってプログラムを成り立たせているわけですが、クラスの種類が多くなってくると、不便なことも起こります。　例えば先の継承の例で、カット、コピー、ペーストは親のクラスで定義したメソッドを子で再利用できるという前提で話をしましたが、もしかするとセルとテキストボックスでは微妙に違った操作が必要になるかもしれません。　カット、コピー、ペーストだと分かりづらいので、削除で考えてみると、セルで削除とすれば上にシフトさせるか左にシフトさせるかといったことを聞いてきますが、テキストボックスで削除すればそんなことはお構い無しに削除です。　つまり同じ様に見えるメソッドでもプログラムとしては全く別物なわけです。　セルとテキストボックスの場合Excelで同時に選択することは出来ませんが、仮に可能だったとしたら、一気に削除！！と、したときにどのように動いて欲しいか．．．当然、テキストボックスは無条件に削除、セルはシフト方向をユーザーに聞く、という具合にそれぞれ別なプログラムを呼んで欲しいわけです。　プログラマーも同じで「このオブジェクトはクラスが××だから、このメソッド、このオブジェクトはクラスが△△だからこのメソッド．．．」なんてやっていられない訳です。　この様に、異なるクラスにおいて同じ様に見えて、実際には異なるメソッドを持っていたとしても、同じ様に見えるんだからとにかく実行してしまう。と、いうやり方がポリモルフィズムです。


と．．．どうでしょう？

正直、Excelの実装とはかなりかけ離れたものになってると思うのですが、一般的なオブジェクト指向の説明だと、車がスポーツカーとSRVに特化されて云々．．．車も飛行機も右に曲がりたいときは云々．．．と概念的な話から入って、そこからどうしてプログラムがオブジェクト指向なのかにたどり着く前に飽きちゃうと思うので、こんな説明を考えてみました。

SaaSに関して考える

あけましておめでとうございます

私はといえば、技術士口答試験に向けて、自宅に篭って悶々と準備中の毎日でございます。
この不景気の中、纏めて休みを取ったものだから、家の奥さんは会社をクビになったんじゃないのかと心配しております。　そして、こうやってブログを書いていることを話したところ、「他の受験生に見られたら自分が不利になるんじゃない？」と。　いや、技術士の試験は絶対評価の筈だから関係ないはずなんだが．．．　（そもそもこのブログ、Googleもヤフーも検索にかかってこないぞ。）　そういや大学の時、レポートを書く際に同期にノートをコピーさせてあげたら、同期の方が点数良かったことがあったっけ．．．

今夜は2008年度技術士二次試験見直し中です。
（もちろん、このブログは模範解答を書いているつもりはなく、自分の考えを纏めるために書いているだけです．．．）
今日のお題は情報工学部門（午後）　情報システムデータ工学のI-1-1

I-1-1　SaaS（Software as a Service）とは何かを説明し、SaaSを導入することによって企業が得られるメリットと課題を述べよ。

割と興味のある分野なので、書きやすいです。
2008年12月31日に書いたブログに一部僕の考えを書きましたが、ここではASPとの対比で考えてみようと思います。
（ところで、ASPってActive Server PageとApplication Service ProviderでTrigramだぶってますね．．．同じIT業界の中でなんと言うセンスの無い．．．　もちろんここではApplication Service Providerのことです。）

SaaSとASPの技術的相違
他にも、色々と要素はあるのかも知れませんが、僕が着目したのは以下の点です。

シングルシステム・マルチテナント
Google appsやGmailのようなオフィスアプリケーションでは問題にならないのでしょうけれど、業務システムにおいては、程度の大小はあってもユーザー企業ごとの要件の違いは不可避です。　ASPにおいてはユーザー企業（テナント）ごとの要件の違いはテナントごとにシステムリソースを個別に割り当てることで対応していましたが、結果として利用コストが高くなっていました。　SaaSでは、カスタマイズ要素をアプリケーションから分離することで、シングルシステムマルチテナントでありながら、柔軟なカスタマイズ性を実現しています。　代表的なのはSalesforceでしょう。　2008年12月31日にも予告しましたが、近日中に勝手に技術解説（公知の技術を営業妨害にならない範囲で）したいと思いますのでご期待を。


リッチクライアント
ASPが登場した時点でWebアプリケーションのユーザーインターフェースで使用できる技術は静的HTMLが殆どでした。　静的HTMLは表現力の面でWindowsアプリケーションと比較すると大きく劣るものでした。（だから、僕はWindowsアプリが好き）　もう少し具体的に言えば、Webアプリケーション上に何かボタンがあったとして、そのクリックイベントに対して一々サーバーと通信し、結果として画面を再描画するため、レスポンスが遅く、しかも画面がちらつくというものでした。
が、JAVA ScriptとWebサービスによる非同期通信の組み合わせである、AJAX等リッチクライアント技術の登場により、WebアプリケーションであってもWindowsアプリケーションと同等の表現力を実現することが可能となりました。　このAJAXですが、具体的には以下のようなHTMLで実現されています。 　分かりやすいように、重要な部分だけを抜き出してみました。



そして、これがAJAXの動きです。






①Button Aがクリックされるとイベントハンドリング関数aaaがコールされる


②aaa内では非同期通信用のオブジェクトxmlReqを生成する。 Internet Explorerの場合は、ActiveX ObjectのMicrosoft.XMLHTTPを、その他のブラウザではXMLHttpRequestというオブジェクトを使用する。　このxmlReqがサーバと通信を開始するが、ブラウザ上でユーザーがこの通信を感知することは無いし、HTMLページに対する更新も起こらない。（これがサーバーのレスポンスを待つことを不要とする操作性を実現しているわけであるが、同時にセキュリティ上のリスクにもなり得る。）


③xmlReq内にonreadystatechangeとしてコールバック関数を定義しておく、サーバーからの応答はここで定義された関数内でハンドリングする。


④コールバック関数からHTML内で更新すべき要素に対して更新処理をかける。　この処理はHTML全体のリフレッシュではなく、HTML内の一部に対するものであるため、画面のチラつきは起こらない。

Webサービス
以前、某学会でSalesforceの社長が言っていたのは、Salesforceの提供するWebサービスを利用することで、ユーザーはマッシュアップにより独自のアプリケーションを創造することができるという。

なるほどー

SaaSの導入によって企業が得られるメリット
1)初期投資の抑制
パッケージソフトウェアの導入では、システム導入に踏み切る際の初期導入コストが大きく、投資対効果を明確にしづらい場合、導入が難しかったわけですが、SaaSはハードウェアを含めて従量制を取ることが出来るため、初期導入コストを抑えることができ、開発リスクを抑えることが出来ます。
2)管理コストの削減
SaaSにおいては、サーバハードウェアのメンテナンス、データのバックアップ、ソフトウェアのパッチ対応等の管理業務がサービス提供側の責務となります。　サービス利用企業毎に専門の管理者を常駐させる場合、定常的に業務量が確保できなければ管理コストが高くつくことになりますが、SaaSの提供者側にとっては、専門の管理者が複数のサービス利用企業を管理することが可能であるため、業務量の平準化とノウハウの蓄積により効率の良い管理が可能であり、結果として質の良いサービスを低コストで提供できると言えるのではないでしょうか。
3)セキュリティの向上
管理コストと同様、セキュリティにおいても管理者の教育等、複数のサービス利用企業を一括で管理する場合、効率が良いと言えるのではないでしょうか。
（AJAXの場合、JAVAスクリプトの使用等、セキュリティ上のリスクが増す面もありますが．．．）

SaaS導入における課題
SaaS導入における最大の課題は、データや企業の業務プロセスの投影とも言えるアプリケーションが場所的にSaaS提供者側にあることに対する抵抗感の問題でしょう。　特にサービスが取り扱うデータがサービス利用企業の競争力の源泉であれば、その管理を第三者に委ねることに抵抗があるのは当然でしょう。　また、企業活動の根幹に関わる高い可用性を要求されるサービスであれば、そういったサービスを第三者に委ねることにも抵抗があるでしょう。　これらの問題は、技術的にはセキュリティと高可用性の問題であり、SaaS利用の拡大と共に実績によりユーザーの抵抗感が薄れていくことでしょう。　


これって、分譲マンションと賃貸マンションの話と似てるなぁ．．．
キャッシュフロー的には賃貸の方が得な筈なんだが、それでもやっぱりマンションが欲しい。