安全文化

今日は日本技術士会・原子力放射線部会へ勉強に行ってきました。　原子力安全基盤機構の方が「原子力発電所の事故・トラブル事例から診た安全文化の劣化兆候」と題して、安全文化に関して講演されていました。　安全文化って分かりづらい話ですが、「原子力発電所の安全の問題には、その重要性にふさわしい注意が最優先で払われなければならない。　安全文化とは、そうした組織や個人の特定と姿勢の総体である。」と。　やっぱ、まだ、分かりづらいですが、個々の人間に関していえば、所謂、倫理観の低下とでも言うような話が、組織（つまりここでは原子力発電所）で起こりつつあるということですね。　そして、日本ではそれが1990年代から顕著になってきている様です。　（バブル崩壊後か．．．）　そこで、ある人が言っていた言葉は、「最近の大学や学会では、技術者倫理というものを教育するようになってきてはいる、が、若い技術者がそういった教育を受けて社会に出ると、企業という利益を追求しなくてはならない組織の中で、その優先順位が変わらざるをえなくなってしまう。」　たしかに．．．　僕も、むかし、前職で機械技術者だったころ、作っちゃったものに対して構造的に問題がないということを証明することを目的（問題がないかを確認することじゃなく）として有限要素法を回したり、規格をまるで弁護士が法廷で争うようにその解釈論に持ち込んだり。　もちろん、改竄まではしていませんが．．．　そんな中、先日のUAEの原発案件のように国際的な厳しい競争入札に曝されているわけですからね．．．　経営者の安全に対するコミットがと言ったって、実際のプロジェクトではコストアップ要因になりそうな問題は日常茶飯事だから、その全てに綺麗事をいっていたら赤字ジョブになってしまうだろうし．．．

CAMPER（カンペール）

CAMPER（カンペール）のブーツが壊れた。
ソールがパックリと剥がれる感じです。（あとで写真載せますね）
アッパーはまだ綺麗だし、結構高かったので、治らないかなぁ．．．と、お店に持って行ったところ、無理ですと言われた。
なんでも、CAMPERのウレタンフォームのソールは、5年くらい経つと加水分解（←Wikipediaへのリンク）するので、5年が寿命ということ。　CAMPERもそれは承知の上で使っているんです。と。
この値段で5年履きつぶしは無いよねぇ．．．がっかりです。

アブダビ原発、韓国電力連合が受注 日立・ＧＥ連合は敗退

昨年暮れ、12月28日のこのニュース、衝撃的ですね。

http://www.nikkei.co.jp/news/kaigai/20091228AT2M2701127122009.html
http://joongangdaily.joins.com/article/view.asp?aid=2914535

私の書評（http://mediamarker.net/u/htakeshi/）で紹介した、「「知の衰退」からいかに脱出するか？」の中で、大前研一氏も説いていますが、現在世界で原発を一貫して建設出来る会社は、4社（東芝・日立・三菱・仏・アレバ）しかおらず、つまり日本は原子力大国なのです。　そこに来て、昨今の地球温暖化も手伝っての原子力ブーム。　長年の日陰の道を歩んだ日本の重電メーカーの方々の苦労が報われようとしていたそこに、韓国が国を挙げての営業攻勢．．．　日本政府はなにをやってるんだ！！　鳩山首相はオリンピック招致活動に行くくらいなら、こちらにも行って欲しかった。　まあ、メーカーがそういう根回しをしなかったのかもしれませんし、社民党と連立組んでたりと、その背景は分かりませんが、こういう業界は実績が大きいですから．．．

マスコミもこのニュースはもっと大きく取り上げて問題視しなくては．．．

TVnima

さて、今日は私の友人からの質問で、3Dで自分そっくりののアバターを作るにはどうすれば良いか問い合わせがあったので、以下のサイトをご紹介します。

http://www.tvnima.com/

こちら、TVnimaといって、ダッソー・システムズのVirtoolsの技術をベースに作成されたサービスで、自分の顔写真をはった3Dのアバターに、パワーポイントなどを説明させてプレゼンテーションAVIを作成したり、ニュース番組を作成したりすることができます。

アバターに動作をつけてあげることはもちろん、吹き込んだ音声に追従して口パクまでさせることができます。

サービスの利用は無料ですが、登録は必要です。　英語のみなのですが、操作は簡単なので、先ずはお試しあれ。

メディアマーカー

近所のスーパーに置いてあった、「日経ビジネスアソシエ」を見出しの「あなたの仕事をラクにするクラウド&フリーソフト50」に惹かれて買ってしまった。　この雑誌自体は、買うべきじゃなかったという感じはするけれど、ここで紹介されている「メディアマーカー」にはハマった。 　結構、乱読する方なので、きちんと記録していかなきゃ何を読んだのか訳が分からなくなるし、こうやって書評を書くことで、ポイントが整理されます。

さらに良いことは、いつか読もうと思った気になる本も、“未読”という形で片っ端からここに登録しておけるので、新しく読む時間ができたときにアマゾンの評価順にソートして上から読んでいく。　僕の場合は、図書館で借りることが多いので、上から6冊くらいとりあえず、予約してあります。

今後は、書評はこちらに載せていきます↓

http://mediamarker.net/u/htakeshi/

MySQLに挑戦！！

今日は、休暇をとって家族と公園に遊びに行ったあとは、ビールを飲みながら「火垂るの墓」を見ていた。
ええ話ですねぇ．．．ちょっとウルウルしながら、久しぶりにブログでも書くかと．．．PCを立ち上げ、「火垂るの墓」とタイプすると、な、なんと、これって野坂昭如の原作なの！！しかも、その体験談で、事実は大分映画とはかけ離れたものだとか．．．
まあ、ええです。　それも作家の才能でしょう。

ブログはひさしぶりですが、仕事ばっかりしていたわけではありません。　ただ、業務にも関係があって、ブログに書けないようなネタばっかりだったので．．．
ここ、最近ちょっと色々と夏休みの自由研究にとりくんでますので、久しぶりにブログを書く気になったのです。

で、全体としてなにをやろうとしているかはともかく、MySQLに挑戦中です。
そもそも、Microsoft信者の僕は、SQL Serever派なんですが（英語ではシークエルサーバーって発音するんですよね。　それもなんかカッコいい。）、その、最終的に取り組もうとしているものの関係で、MySQLを動かさなくてはいけなくなったんです。
大体、ネーミングがイマイチだよね。なんて、思いながら、MySQL Community Server 5.1.37のWindows用MSIインストーラをダウンロードしてダブルクリックすると、なんとまともなエラーメッセージも出ずにインストーラが終了してしまう！！しゃあないので、ネットいろいろ調べると、どうも、5.1.35以降のインストーラにバグがあるらしいんですよね。　これだからMySQLなんてーのは．．．　仕方がないので、主導インストールに挑戦。

まずは、以下のサイトの、「Windows downloads」→「Without installer (unzip in C:\)」からコードをダウンロードします。
http://dev.mysql.com/downloads/mysql/5.1.html
で、それを適当なフォルダに配置するわけですが、僕の場合は、D:の直下に「MySQL」というフォルダを作成し、その直下にダウンロードしたZipを展開しました。
（ダウンロードサイトでは、C:と言っていますが、特に問題なかったです。）
次のステップとしては、「C:\windows」下に「my.ini」というテキストファイルを作成し、以下の内容を書き込みます。

[mysqld]
basedir="ダウンロードしたZipを展開した位置"
datadir="ダウンロードしたZipを展開した位置の中のdataサブフォルダを記述"
default-character-set=cp932
[mysql]
default-character-set=cp932

次に、コマンドプロンプトを立ち上げ、ダウンロードしたZipを展開したフォルダ内のBinフォルダ内で、「mysql.exe --install」とタイプし、実行。
「Service successfully installed.」となれば成功！！
これで、MySQLがWindowsサービスに登録されます。
「net start mysql」とタイプすれば、MySQLがサービスとして実行されます。
これで、とりあえずはMySQLのインストールは完了です。

次のステップとしては、管理用にGUIツールが必要です。　こちらは特に問題なくインストーラのダブルクリックでOKです。　以下のサイトの「Windows Downloads」から「Windows (x86)」をダウンロードして、ダブルクリックでOKです。
http://dev.mysql.com/downloads/gui-tools/5.0.html
MySQLもこんなGUIがあるんだねぇ．．．なんて、感心しながら、「Mysql Administrator」というツールをダブルクリックすると、「Could not find settings」とまたまたエラーが！！
ああ、頭に来る。

これまたネットで調べると、レジストリの「HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\MySQL\ImagePath」というKeyに対して、「...\mysqld.exe MySQL」となっているのを「...\mysqld.exe --default-files="C:WINDOWS\my.ini" MySQL」としてあげればいいんですね。
これで、やっと無事動きました。

動いてみると、なかなかのものですね．．．

情報工学部会歓迎会

金曜は、会社を18:00に切り上げて、技術士情報工学部門の歓迎会へ．．．
歓迎会の前に理化学研究所の方がHPCに関して講演していました。なんと、格調の高い．．．すごいですね、Earth Simulator、消費電力6MWって．．．そういや、学生のとき、Crayのスパコン、液体窒素で冷却してるとか何とか言っていたような。FEMのデータを置きっぱなしにして結構課金されたりしたなぁ．．．

情報工学部門だからなぁ．．．ってシリコンバレーのノリで、ちゃらいジャケットにノータイで行ったらみんな（スーツというより）背広だった。皆さん、大手のITや電気メーカーの何とか部長とか室長とかの方もいて、ちょっとビビッてしまいました。でも、とりあえず名刺交換できたし、人脈を広げるという意味では良い経験です。

終って外に出ると、東京タワーのライトアップが．．．

そうか、IOCの評価委員来日の為のライトアップなんですね。

営業は関西人に任せろ．．．

今週は色々と忙しかったです．．．
仕事の関係で、関西出身の営業の人たちと取引先に出向きました。
しかし、関西人のビジネスは凄い．．．

「いやー、あのときは酔っ払っちゃってすごかったね」
「それで、xxさん、yyとやっちゃったんだよね」
「いやいや、3P．．．」

なんかよく分からん下ネタが延々と続くのだが、その中でも仕事上のポイントだけはしっかり抑えていて、話だけはついている。　まあ、そういった絶妙なやりとりも、気心知れた間柄だからというのもあるのだろうけど、つくづく人脈というのは大事です。

そして、金曜はパーっと以前の勤務先の同僚と飲みに行ったのですが、このブログ見てくれたのか、アクセスカウンタが上がってますねぇ。　新しいネタを載せなきゃ．．．

技術士第二次試験「口頭試験」受験必修ガイド

★★★★

技術士第二次試験「口頭試験」受験必修ガイド (単行本)

杉内 正弘 (著), 福田 遵 (著)

これから技術士を受験する人の参考になるように、僕のやった対策を時間のあるときに紹介しておきたいと思います。

平成19年度の試験制度の変更から、口頭試験の合格率が下がっていて、僕の受けた情報工学部門だと、70%位の合格率なんですね。　それ以前は二次を通れば口答試験で落とされることはレアケースだったわけですから、口答試験対策の比重が上がったわけです。　ですが、二次試験の合格通知を受け取った後、結構のんびりしていたので、巷の口答試験対策講座とかは殆ど締め切っちゃっていて、打てる対策はこの本しかありませんでした。　とは言え、大分助けられました。　口答試験対策講座とかって結構高いから、コストパフォーマンスはある意味最高でした。　特に、口答試験での試験管からの質問例は結構参考になりました。　全部で100問弱くらいですが、それぞれに自分なりに回答を用意して、本番に臨みました。　口答試験は質問に対して考える間もなく反応しなくてはならないので、本質的に技術士としての適正があったとしても、練習しておかないと難しいですね。　ホントたすかりました。

あと、口答試験では、事前提出する技術的体験論文の出来も重要なのですが、論文に関しては、この本は提出後だったので、参考にすることは出来ませんでしたが、こちらの「若くして合格！技術士受験指導」にお願いしました。　こちらも低料金で添削お願いできたので、助かりました。

http://peexam.net/index.html

祝！！技術士二次試験合格

前回のアップデートから大分ご無沙汰してしまいました。
どうも最近忙しくて．．．

ところで、3月6日に技術士口頭試験の結果が出ました。
結果は見事合格！！

未だ、登録していないので、技術士を名乗るわけには行かないのですが、登録したらこのページも技術士のページって事にさせて頂きます。　今後、技術士試験向けにここに論述を載せるって事は無いですが、気の向くままに情報工学関連のトピックに関して論述を載せて行きたいと思います。

また、技術士試験対策に関しても、要望が多ければ載せてきますんで、興味のある方は書き込み下さい。

図解でわかる 半導体製造装置

★★★
図解でわかる 半導体製造装置 (単行本（ソフトカバー）)
菊地 正典 (監修)

渋い本を読んでしまいました。
なんか、どうしても半導体ってどうやって作っているのか知りたくなってしまってですね。　この「図解でわかる」シリーズは、こういう用途には最適です。

だけど、半導体製造装置って、渋いですねぇ．．．　磨く・洗う．．．といった地味な工程の繰り返し．．．　でも、ITってのもこういう技術に支えられているわけですね。　ムーアの法則とか言っても、こういうのを読んでおくと、イメージが沸くようになるので、まあ、読む価値はあります。

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利用の拡大と共に実績によりユーザーの抵抗感が薄れていくことでしょう。　


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

クラウドコンピューティングを使ってみたい！！

クラウドコンピューティングを使ってみたい！！

2007年のIT流行語対象が、Web 2.0であれば、2008年はクラウド！！
Web 2.0程じゃないけど、クラウドも若干輪郭がぼやけてます。
例えば、Google appsやGmailなどもクラウドって定義の範疇に入るらしいし、Salesforceもそうらしい。
僕のイメージ的には、コンピューティングって言うとインフラ的な語感があって、Google appsやGmail、SalesforceなんかはSaaSって言ってもらった方がしっくり来ます。　と、いうことで僕的にクラウドコンピューティングって言うと、以下の3つにとりあえず注目

Amazon
Amazon Web Services (EC2 / S3 / SimpleDB)
http://aws.amazon.com/
発表：2006年8月

Google
Google App Engine
http://code.google.com/intl/ja/appengine/
発表：2008年4月

Microsoft
Windows Azure
http://www.microsoft.com/azure/default.mspx
発表：2008年10月

AmazonおよびGoogleに関しては、以下のサイトを参考にしました。
http://www.techworld.jp/topics/cloud/101834/

僕的にはこのクラウドはWeb 2.0やSaaSなんかと違って、目に見えてブレークすると考えていますし、結構期待しています。　SalesforceのCRMって凄いとは思うんだけど、アプリケーションの構築がシングルシステムマルチテナントの制約を受けすぎていると思います。（←これ、後で勝手に技術解説したいと思います。）　つまり、ASPとSaaSの大きな違いとSaaSの成功要因の一つとして挙げられているシングルシステムマルチテナントですが、結構技術的なハードルが高くて、それを克服したからこそSalesforceの成功があるわけだけど、誰でもが実現できるわけではないし、ケースも限られてくる。　そうすると、SaaS型の成功例ってそうは出てこないんじゃないかな？　また、Web 2.0の局所的な話ではあるけど、例えばAjaxによるリッチクライアントなんかも、そこまで苦労してWebアプリケーションにしなくても、配布が面倒ならWebアプリケーションにしなくても、アプリケーション配信技術は色々あるじゃないかと思うのです。

でも、もともとASPやSaaSがユーザーにもたらすBenefitって、ソフトウェアの従量制課金モデルによる初期投資リスクの低減と、インフラのアウトソーシングという点だと思うので、それってクラウドコンピューティングとアプリケーション配布技術とソフトウェアのセールス戦略の政治的判断だけで実現できてしまう話なんじゃないかと．．．　今後、Small Businessでの伸びを考えれば、伸び代を大きいですし、起業家にとってもアイディア次第で小さな資本でビジネスを展開できるという点でもすばらしいことだと思います。
で、この3つの違いですが、僕が注目しているのはAmazonとMicrosoft。　Googleはアプリケーション構築でサポートする言語がPythonだけというのがどうかと．．．　Amazonのは、先のサイトに寄れば、自分のサーバーイメージをAmazonのクラウド環境に送る込むことで、利用できるらしく、自由度が高いですね。　当初のリリース時にはLinuxかUnixのみのサポートだけだったということですが、2008年10月にWindowsもサポート開始したようです。　そして、本命はMicrosoft。　お約束でVisual Studioで開発できちゃうんですね。　やはりMicrosoftのサイトは綺麗ですね。　AmazonとGoogleが白を基調としているのに対し、Azure＝紺碧．．．か、カッコよすぎる。　1上旬はちょっと忙しいので、中旬、以降試して結果をレポートします。

年賀状のセオリー

やっと、年賀状を書き終わりました。



僕の場合は、Power Point 2007で写真のEffectも自由自在。
なんといっても仕事の40%位はPower Pointですから :)
（残り40%がOutlookで、残り20%が本職のシステム．．．）


最近の年賀状作りは、楽になりましたねぇ。

家の母親は木彫り彫刻が趣味だったので、子供の頃は12月になると版画彫を手伝ってました。
そして、絵の具を一色ずつのせながら馬簾で一枚一枚刷っていく．．．
1週間以上掛かってたんじゃないかな？
その頃でも、印刷の年賀状はあったけど、今程のデザインの自由度はなかった。
産業革命並みの効率化ですよね。
でも、家の母親の年賀状は味があったなぁ。
かといって、今更自分がその手法には戻れないし戻る気も無い。（これも産業革命みたいだ．．．）

ところで、今日、デザインが出来て、プリンターで印刷しながらテレビを見ていたら、テレ東で年賀状の常識クイズをやっていた。

- 目上の人には「賀正」ではなく「謹賀新年」：家はそもそも「A Happy New Year」

- 1日に着きそうに無ければ、元旦ではなく、一月吉日：家は「日付入れるの忘れた．．．」

- 目上の人には写真入は不向き：思いっきり入れた。

駄目ですねぇ．．．

こんにちはマイコン

クラウドの時代になり、マイクロソフトの時代は終わりかとも囁かれているこのごろではありますが、 12月13日号の東洋経済「それでも強い！マイクロソフト」の特集記事でWindows Azureを取り上げていましたね。.NETの開発者は、これまで培ってきた開発技術をそのままWindows Azureのプラットフォームの上で活かすことができると．．．すばらしいことです。　マイクロソフトがんばれー。

そして、どうして僕はこんなにマイクロソフトが好きなんだろうと考えてみた。

そう、その原点は25年前に読んだこの2冊の本だったのです。

「こんにちはマイコン」

マイコンってのが時代を感じさせますよね。　PCって昔はマイコンって呼ばれていたんです。　「マイクロコンピュータ」と「私のコンピュータ」が合わさって、こう呼ばれていたんです。　それがいつの間にかPCなんていう、温かみのない言葉になっていた．．．

この本は、当時の人気マンガ「ゲームセンター嵐」の主人公・嵐がBASICで「ブロック崩し」をプログラムしていく過程を追いながら、マンガでBASICプログラミングを学べるという画期的なもの。　当時PCは非常に高価なものだったため、なかなか買ってもらえなかったな．．．　そんな貧乏人の子供も安心、実物大キーボードポスターが付録として付いていた為、シャドウタイピングの練習ができたのです。

http://www.m-sugaya.com/arashi/pc-index.html

こちら著者のすがやみつる氏のHPのようですが、「これがこんにちはマイコンだっ！」っていう「だっ！」ってのが、らしくて良いですね。　懐かしー！！

東洋経済にも、マイクロソフトの強みの一つは開発者コミュニティであると解説してありましたが、そう、よく考えると僕にとって、BASICがはじめに触れた言語だったのです。　結構そういう人は多いんじゃないかな？　そりゃぁ、そう簡単にJAVAになんか乗り換えられないっすよね。

こんにちはマイコン―まんが版

すがや みつる (著)

ソフトウェアトラブル・システム障害について考える

なんか、硬いネタばっかりですね。
別に本質的にそういう人間という訳じゃないんですけど、勉強中なものですから．．．

今年もソフトウェアトラブル・システム障害に関する話題が豊富だった様です。
ITProで特集してました。
http://itpro.nikkeibp.co.jp/99/trouble/index.html
- 2008年11月4日　JCBのカード関連サービス障害
- 2008年9月14日　全日本空輸（ANA）の空港システム障害
- 2008年7月22日　東証の新派生売買システム障害
- 2008年5月19日　住友信託銀行のシステム障害
- 2008年5月12日　三菱UFJ銀行のシステム統合に伴うトラブル
- 2008年2月25日　信金中央金庫のシステム障害

ここに挙がってくるようなシステムは、それでもお金かけてテストしていると思いますよね。　でも、どんなにお金をかけてもソフトウェアトラブル・システム障害を防ぐことが出来ないことは、マイクロソフトが年間70億ドルの開発予算を掛けてもバグがなくならないWindowsが物語っていると思います。　僕のNote PCは大体週に2回くらいブルースクリーンを見るかな？　何時間もかけて書いた書類が吹っ飛んだりすれば、それは頭にも来るでしょうけれど、幸いにしてそういう経験はあまり無いので、コーヒーブレイクをとれという神のお告げだと思うことにしています。

東京証券取引所のJCOM問題は恐らくソフトウェアトラブルを考える際の最も優れた教材なのかも知れません。　こちらのJCOM問題が実際にどのようにして起こったのかを纏めた情報システム学会の資料です。
http://issj.nuis.jp/renkan.pdf
（去年の技術士二次試験の問題は、ここからの引用だったんですね。）
証券関係のシステムをやっている人がどう捕らえるかは分かりませんが、よくここまで不幸が重なったものだな．．．というのと、このケースを想定したテストが書けなかったということにどれだけの過失があるのだろうか？この問題を100%防ぐアプローチが存在するのか？と、言うのが率直な感想です。　Windowsなんか、利用シナリオを考えていたらキリがないから、マイクロソフトの場合、Microsoft Solution Frameworkに書かれている手法（つまりバグはあるという前提で、統計的に管理する手法、あるいはプロジェクト管理面に関する議論）とかで品質の向上を狙っているのでしょうかね？　それが正しければ、バグがあるという前提のOS上で動いている情報システムにバグフリーを要求すること自体がナンセンスな気もしてしまうわけですが．．．　だからWindowsを使わないんだ！！と、突っ込まれそうですが、本質的にはソフトウェアが複雑になりすぎて統計的手法に頼らざるを得なくなっている、あるいはTQCのようなプロジェクト管理的に品質向上を狙うアプローチにしかなり得ないということだと思います。　簡単な言い方をすると前者はベータテストみたいな形でシナリオフリーでユーザーに使ってもらうか、パイロットプロジェクトを行って、そこで品質を作り上げていくということでしょうし、後者に関しては、こういったソフトウェアトラブルの原因を追究し、どうすれば防げたのか？という問いに対して、本質的に「関係者間のコミュニケーションの改善」という答えに行き着いてしまうということです。　そう考えると、「Programming First Development」や「Test Driven Development」ってソフトウェアの品質向上にどれだけ寄与するのか．．．

僕は以前、プラントエンジニアリング会社に勤めていたのですが、そこであるシステム構築の計画の際に、部長に「検証はどのようにやるのか」と、聞かれ、答えに窮してしまった経験があります。　システムエンジニアとして何年か経験した今でも、検証プロセスに対してその時からそう成長した感じはしませんが、自分自身がシステムエンジニアとして品質に対するマインドが特段低いとは考えていません。　ハッキリ言ってしまえば、情報システム開発はプラントエンジニアリングほど成熟しておらず、品質管理もプラントエンジニアリングに見習うべきところが多いということです。（もちろん、情報システム開発が進んでいる部分も多々ありますが．．．）　そういった他業種のベストプラクティスの流用に関しては、自動車業界を引き合いにだすことが多いと思いますが、受注産業である点やプロジェクト管理の手法（PMPなんか、元は建設業界の方が盛んでした）など様々な面から情報システム開発はプラントエンジニアリングに似ています。

例えとして、システム開発におけるプログラマとプラント建設における溶接工を比較してみます。　溶接はプラント建設において品質を作りこむための一つの大きな要素ですが、基本的には全ての溶接箇所にたいして、溶接手順やその溶接手順で十分な品質が出たことの証明（WPS/PQRと呼ばれる）が存在します。　この証明（=PQR）はプラントエンジニアリング会社の溶接技術者が確認するのではなく、第三者機関が確認します。　そして、それぞれの溶接手順（WPS）はどの溶接工でも施工して良いわけではなく、それぞれのWPSに対して認定された溶接工のみが施工を許されています。　が、一方システム開発ではどんなことをやっているというのでしょう？　何の認定もないプログラマに実装（=施工）のかなりの部分の裁量が与えられてしまっているのではないでしょうか？

この問題を考え始めたきっかけは、技術士口頭試験で以前題材となったということからなのですが、考えていくと、ちょっと極端に深く広くなっていき、キリが無いので、この辺で止めることにします。　午後はもっと楽しいことを考えることにしよう．．．