今月の日経SYSTEMSに富士フィルムで行われた基幹システムの仮想化に対する取り組みが紹介されていた。

仮想化そのものは大変有用で、私も検証環境や社内での客先環境を模すのに良く使用している。実機を使用しなくてよいというこの利点にはかなり恩恵を受けている。なかったらと思うとちょっと怖いくらいだ。
ただ、富士フィルムの例でみられるように実際の基幹システムに仮想化を取り入れるには実のところ、未だに多くの問題を抱えている。
私が感じる一番の問題は、アプリケーションのサポートだと考えている。これは私自身がアプリケーションを作成するベンダーの立場であり利用する立場でもあるからだとは思う。

アプリケーションのサポート

私が仕事で主に使用しているデータベースはOracleなのだが、Oracleは仮想化上での動作をOracleVM以外ではサポートしていない。実際のところ、VMWareやVirtualPC。Hyper-Vでも動いてはいるのだけど、障害時を考えると少し怖いものだ。Oracleも決してバグの少ない製品とはいえない事はこれまでも身をもって知っているし。
いくつかのアプリケーションベンダーの仮想化に対する対応はマチマチ。いくつか細かい違いはあるようだけど

1. 物理環境で再現出来たらサポートします
2. 仮想環境が原因だったらサポートしません

という2種類が多いように思える。字面の問題のように見えるが、前者はユーザー側で確認をするのに対して後者はベンダー側で確認をするというスタイルだ。
比較的容易にインストールさせる事が可能なソフトウェアであれば前者で問題ないだろうが、大規模なシステムであった場合にはそもそもインストールが困難なので後者が選ばれると思う。ただ、ここで問題になるのがベンダー側の対応。サポートの仕方はベンダーで異なるだろうが、おおむね

1. 現象の再現確認
2. 再現結果からの調査・修正等の対応
3. アナウンス

のような流れになると思う。ここで問題になるのが、ベンダー側の環境で再現しなかった場合にそれが”本当に仮想化が原因”かどうかの判断をどうつけるのかではないだろうか。実際のところ、物理環境であっても現象によっては必ず再現するとは限らなく、いくつか複数の要因が重なって初めて発現する問題もある。また、仮想化が原因であるというのであれば、ベンダー側で仮想化環境を構築して検証を行う必要が出てくる。
となると、ベンダー側はユーザー側が使用している仮想化ソフトに対しての知識や、環境を用意しておく必要が出てくる事になってしまう。サポート部隊の涙目が見えてきそうな話だ。おそらく、そもそもの仮想化ソフトを限定しているのかもしれないが…。実際のところ、どうなのだろうか。気になるところだ。

ちなみにWindowsは以下の仮想化環境でサポートをしているようだ

1. Cisco WAAS Virtual Blades 4.1
2. Citrix XenServer 5 Embedded Edition
3. SUSE Linux Enterprise Server 10 SP2
4. VMWare ESX 3.5 Update 2
5. VMWare ESX 3.5 Update 3
6. VMWare ESXi 3.5 Update 3
7. Xen Server 5

http://www.windowsservercatalog.com/svvp.aspx?svvppage=svvpsupport.htm

上記一覧にOracleVMがまだ入ってない事を考えるとWindows+Oracleの環境で公式のサポートを得る事は難しいという事か。いずれにしても、綱渡りである事に変わりはない。

＜2009.03．07追記＞
コメントに情報をいただいていますが、OracleはWindows,Linux以外の環境ではサポートを表明しているようです。
http://www.oracle.com/technology/products/database/clustering/certify/db_virtualization_support.pdf
HP-UXやAIXは正直私は触ったことがないです。Solarisくらいかな・・・。Oracleの利用目的から考えるとこれらを選択肢に入れるのはいいかもしれませんね。私はその前にこれらOSの知識を手に入れないと不安でしょうがないですが…。
でも、たとえばHPのnParそのものはWindowsやLinuxもサポートしているのになぜHP-UXのみに限定しているのか。そしてOracleVMではそのWindowsやLinuxをサポートしているのか。
このあたりは企業戦略が見え隠れしているような気がしなくもないですねぇ。純粋に信用していないだけなのかもしれませんが。

ではどうするのか

さて、困った。どうしたものか。
仮想化環境を提供しているベンダー。VMWareやMicrosoft。Oracleもまたそうなのだが、これらの中でどこかが明確な方針を出してくれれば少しは動きやすいとは思うのだけれど、現在のところ主だった動きはないように思う。サポートの手厚さでは24時間サポートを打ち出しているOracleVMが手厚そうと言えば手厚そうだ。
シェアで言うと先行していたVMWareが大きいのではないかと思う。
いずれにしてもベンダーがいくつかのアプリケーションベンダーを巻き込んでサポート体制の新しい枠組みを作っていかなければいけないのではないかと考えている。望むならば申し出のあったアプリケーションベンダーに対して仮想化環境を提供。検証するための枠組みを作っていって欲しいと考えている。
もちろん、星の数ほどあるアプリケーションベンダーそれぞれに対してそのような事が可能かどうかというと、無理があるのかもしれない。かといって仮想化に対するユーザーのニーズというものはこれからも増え続けて行くわけで何かしらの対応をとっていかなければいけないだろう。

ウジトモコさん著、視覚マーケティングのススメを読んだ

視覚マーケティングのススメ (アスカビジネス)

posted with amazlet at 09.03.18

ウジ トモコ
クロスメディア・パブリッシング
売り上げランキング: 23182

Amazon.co.jp で詳細を見る

視覚マーケティングとは

「デザイン」というものを考える上で、ただ単にデザイナーに”いいものお願い”って頼むのではなく、マーケティングをすることで、効果的なデザインが出来上がる。マーケティングをせずに作ったデザインはマーケット上での効果は期待できないという考え方だ。

言ってしまうと、当たり前の話なんだけど、その当たり前のことを細部にまでできているかというとなかなか難しいことだ。一般に、製品を企画する段階では間違いなくターゲットとなるユーザーを設定するだろう。そのターゲットは年代に寄るものかもしれないし業界・業態によるものなのかもしれない。必然的に製品のパッケージや広告・キャッチコピーに関してもそれを意識したものが考えられる。
また、企業のロゴになると自分たちが顧客・ユーザーに”どう思われたいか”を意識して考えられるだろう。
ただ、それが本当にできているのだろうか？製品やサービスの細部。個々のパーツにまで落とし込めているだろうか？

意識されているもの、されてないもの

おそらく、パッケージや広告が表に出てきやすいもの。お菓子や化粧品に代表されるようなものに関してはこのいわゆる”視覚マーケティング”はできているのだろう。化粧品みたいなものは明らかに年代を意識して製品を作っている部分もあるので特に意識されているのではないかと思う。
ただ、ソフトウェアの分野はどうだろう。もちろん意識しているソフトウェアもあるだろうけど、明らかに”機能重視”でデザインに関してはおざなりに済ましてしまっている部分はある。特に基幹系のシステムに関してはその色は強いのではないだろうか。
もちろん、これらのソフトウェアに関しては機能は第1に重要視されるものだと思う。ただ、複数ある基幹システムの候補からどれが選ばれるか。ユーザーの立場で”どれを使いたいか”を考えてみるとその要素の一つにデザインがあってもおかしくないと思う。また、そういう意味で”ファン”を作った製品はエンドユーザーからは根強く支持されたりもする。つまり、デザインによるブランディングができているのだろう。
また、個人のブランド。パーソナルブランディングに関しても意識の差は大きいように感じられる。本書でもその具体例として名刺が取り上げられているところからもそれは感じられる。
最近、セミナーや勉強会に顔を出すようになって様々な方と名刺を交換する機会をいただいている。私は個人名刺を所有していないので会社のを使っているのだが、多くの人は個人名刺を持参している。自分自身をどう見られたいか。どういう人間だと印象付けたいのか。この名刺の目的は何か。考えられた名刺もあるしまずは作ってみたというものもある。私自身、個人名刺に関してはほしいと思っているので、どう思われたいのか？どう表現するのかは大きな課題の一つだ。まずはそこを見つけ出さないことにはデザインも始まらない。

ソフトウェアのデザイン

私はソフト屋なのでどうしてもソフトウェアにあてはめて考えてしまうのだが…
ソフトウェアの分野。先にあげた基幹系システムに関して言うと確かにデザインはいい加減なものが多い気がする。いや、実は結構頑張っていたりもするソフトもあるのだろうけど、VBフォームの延長線をいまだにたどっているソフトも割りと残っていたりする。
シンプルな作りなのがいいという業界もあるだろうし、スタイリッシュな物が好まれる業界もあるだろう。ただ、私自身が最近必要と思っているのは、要するに”スタイル”的なデザインではなく”ナビゲーション”を意識したデザインというものだ。これのいい方法が思いつかない。そういう事が得意なデザイナーもいるんだろうけど…、業界やユーザー層に踏み込んでまで考えられる人は少ないように思う。あ、それは発注側の担当ですか。
以前ペルソナを用いる手法に関する本を読んだ

ペルソナ作って、それからどうするの? ユーザー中心デザインで作るWebサイト

posted with amazlet at 09.03.19

棚橋 弘季
ソフトバンククリエイティブ
売り上げランキング: 21263

Amazon.co.jp で詳細を見る

まだペルソナに関しては試行錯誤段階で効果は不明だけど、実際に作ってみたペルソナが本当にあっているのかというのはわからない話。結局ウジさんの本にあるようにユーザーへの聞き取りのようなことをしなければいけないのだろう。
試行錯誤。試行錯誤の日々は続く

お客さん先の環境で、IE６上でイマイチ原因のわからない障害が起きていた。環境としては

• WindowsXP SP2
• InternetExplorer6 SP2

であった。XPはいいとして、IE6か～。ってことで、とりあえず内容を確認して再現確認を取ろうとするも、社内環境では再現しない。客先でも以前からIE6を使っていて、最近発生し始めた障害のようで、単純にIE6が原因とは言えないんだけど。。。
環境が原因である可能性が高いのならば環境を変えてしまえばいいんじゃないか？と安直に考えて、お客さんに「IE7にしようよ！」って薦めるための材料を集めようと、IE6のサポート期限をうたっているページを探そうとしたら変なものを見つけた

IE6 NoMore
http://www.ie6nomore.com/

「IE6はもういらない」――Web企業が撲滅キャンペーン
http://www.itmedia.co.jp/news/articles/0908/06/news031.html

ITMediaの記事が8/6なのを見ると、実にタイムリーな内容だったみたいだ。
企業向けのWebアプリケーションを提供している企業にとって、OSをインストールしたときに自動的にインストールされているIEへの対応はかなり重要な項目。ただ、IEのバージョンへの対応は意外と面倒でそれにかかる開発コストというのは馬鹿にならない。それを考えると、思わずキャンペーンにもろ手を挙げて参加したくなるが、やはりそう簡単でもないだろう。
実際のところ企業の中ではいまだにWindows2000が現役で動き続けている。WindowsNTすら動き続けている。Windows2000ではIEは6までしか動作させることはできないし、WindowsXPもインストール当初はIEは6だ。
自社のシステム上、特に問題がない限りわざわざバージョンを上げる必要がないと考えている企業は多い。バージョンアップに伴う情報システム部門の費用もばかにならず、”そんな事をする暇があるなら別の仕事をしろ”って感じに今の御時勢はなってしまうのかもしれない。

バージョンを上げればセキュリティ的なリスクがすべて解消するというわけではもちろんないが、更新の止まったアプリケーションを動かし続けるリスクは企業であればちゃんと認識する必要はあると思う。
IE6撲滅キャンペーンも、開発者側のリスクに対して焦点を当てるのではなく、セキュリティ的なリスク等に対して焦点を当てて薦めていったほうが、頭の固い人にも少しは受け入れやすくなるんじゃないだろうか。。

ここまで書いて、そんな意識があるのであればすでにバージョンアップしているんだろうなぁと思った。
あ、問題解決してないや

O’REILLYから出ている「ソフトウェアアーキテクトが知るべき97のこと」を読んだ

ソフトウェアアーキテクトが知るべき97のこと

posted with amazlet at 09.10.06

オライリージャパン
売り上げランキング: 747

Amazon.co.jp で詳細を見る

珍しくAmazonが新刊を速攻で届けてくれた。つまり、予約があまりされなかったということだろう。技術書なんてそんなものだ…。

本書は、読んで字のごとくソフトウェアアーキテクトが知っておかなければいけないことや、何に注力していかないといけないのか？ということに関して数々の人がその考えを述べている。
本全体としてまとまっているというわけではなく、どちらかというと「あなたはどう思いますか？」って感じの質問に対しての解答集のようなものだ。

ちなみに、日本語訳は無いが原文はこちらにある

97 Things Every Software Architect Should Know – The Book
http://97-things.near-time.net/wiki/97-things-every-software-architect-should-know-the-book

日本語版である本書は、上記97の内容以外に日本人アーキテクトによる追加の内容11本を含んでいる

何を知るべきなのか

実際には、それぞれの立場や会社の性質。従事しているプロジェクトの内容やチーム編成によっても立ち位置は変わってくると思うので、「おー！そうだよね！！」って思うこともあれば「ふーん」と思うこともあった。
ただ、まとまっていないといっても、考えることというのは比較的似通っていて、言っていることはある程度のカテゴリに分けられている

1. 技術を正しく把握・使うことの重要性
2. コミュニケーションの重要性
3. ビジネスを考えることの重要性

とってもざっくばらんに分けるとこんな感じじゃないかな？
たぶん、この人たちにとっては”ソフトウェアや技術に対する知識を持っているのは当たり前”で、プラスして何が重要かということが言いたいんだろう。技術ばっかりの頭でっかちになってはだめですよって。本書でたびたび出てくるところの「象牙の塔」ですね

• 象牙の塔　http://ja.wikipedia.org/wiki/%E8%B1%A1%E7%89%99（Wikipedia:象牙）
  • 現実からかけ離れた夢想の世界。学者が閉じこもる研究室の比喩。ミヒャエル・エンデの『はてしない物語』にも登場する

面白いと思い、やはり悩ましいのはコミュニケーションだろう。

そんなときに必要なのは、昔から定評のあるテクノロジーです。実際、そのテクノロジーは、人類の歴史で最も重要な技術上のイノベーションです。何だと思いますか。それは話し合いです(P.6 Mark Ramm)

ソフトウェアアーキテクトをビジネスとデベロッパーの間に置くとなると、やはりこのスキルは必須になるだろう。これはプロジェクトをチームとして、会社として成功に導くためには間違いなく必要なことだ。
その割に、これにかかるコストだとか労力というものは軽視されがちで、結果としてプロジェクトはとん挫したりする。
また、もうひとつ。重要なコミュニケーションがある

ソフトウェア・アーキテクトは、どのプラットフォームの仕事をしているかにかかわらず、相互のコミュニケーションを円滑にするための手段を持たなければなりません。その手段の1つが、アーキテクチャー/デザインパターンによるコミュニケーションです。(P.84 Mark Richards)

そう。同じプラットフォーム、同じ言語で開発を行ったとしても別のチームのプログラマがすぐに他のチームで活躍できるとは限らない。仕様書が情報を知るための重要なリソースになることもあるが、プログラマであればまずソースを見ることが多いのではないか？その時に内容を理解したり、プログラムの意図や流れというものを理解するのにこれらデザインパターンというのは間違いなく威力を発揮する。
逆を言えば、本来であればデザインパターンを適用すると効果的な場面において適用されていないとすると、不必要な誤解を招く可能性まであるということだ。

私自身は、デザインパターンに対して習熟しているとはまだまだ言えない。
一人の技術者としてのコミュニケーションがとれるよう、勉強していかなければいけないと痛感することになった。

久しぶりに、疲れた。

いや、いつも疲れるには疲れるんだけど、今日は自分に直接ではない。
今進めているプロジェクト。キーパーソンになっているメンバーに任せている周りの進捗がおもわしくない。あまり口を出しても変に自尊心を傷つけてもあれなので、もう少し見守っていくつもりだったが、ここにきて別プロジェクトが火を吹き始め、その原因が何を隠そうこの本人であった。
今日のところはとりあえずは任せたが、明日からは本格的に立て直しにかからなければいけないだろう。それ自体はいいのだが…。
うーむ。
明日からはちょうど来る台風並みに荒れることにならなければいいのだが。いや、荒れさせてはいけない。

のだが。。。。
うーむ。

今日、ちょっと縁があって某大手データベース会社の研修プログラムを営業している人と話をした。ありていに言うと営業を受けたわけだが。
現状で、組織でまとまった研修プログラムを受ける予定は無いということを前提に、そもそもどうやって”勉強することが大事であるか”や、”技術力を高めよう”という方向に社員を向かわせることが出来るだろうか？ということを切り出してみた。

技術者というものはどちらかというと、専門分野に関して突き詰めて調べたり、あれこれと興味を持って動く人物であることが多いと思っていた。
ただ、最近入社してくる人を見ると必ずしもそうではないことが分かる。語弊はあるかもしれないが、数ある職業の中からたまたま選んできたのだ。
会社として、業務命令として勉強させたり資格に向かわせたりすることはできなくはないけど、それはそれでさみしいことである。出来れば、本人の興味を向かわせたほうが結果としては全体のプラスになるのではないかと思う。

さて、あれこれと話したのだが最終的にはやっぱり”ストーリー”を提示することだろうということになった。
会社の今後のストーリー。製品のこの先。それらのストーリーを実行するためには今何が足りないのか。それらを共有したうえでそのストーリーを実現するためのキャストとして登場してもらう。

言うのは簡単だけど、すっげー受け入れられるか、すっげー白い目で見られるかのどっちかだなぁ。
ふむぅ

仕事はストーリーで動かそう

posted with amazlet at 09.10.30

川上徹也
クロスメディア・パブリッシング(インプレス)
売り上げランキング: 21974

おすすめ度の平均:

仕事にストーリーはあるか？
物語のチカラ
手でつかめない「商品」を売った人の気づきは参考になる
ストーリーの重要性には納得
ビジネスを、そして人生のすべてをエンターテインメントに

Amazon.co.jp で詳細を見る

なぜいつもこうデスマーチへと向かうのだろうかと小一時間問い詰めた今日。
もう少ししっかりとプロジェクトマネジメントに関しての知識を体系だてて学ぶ必要があるな。
ふぅぅぅ

今日はおしまい

XAMLプログラミング WPFアプリケーションの概要と開発の著者でもある川西さんのブログでPDC2009の報告が上がっていました

川西 裕幸のブログ
http://blogs.msdn.com/hiroyuk/archive/2009/11/18/9924120.aspx

PDCとは

PDCはProfessional Developers Conferneceの略で、マイクロソフトが米国で開催しているソフトウェア開発者向けに開かれているイベントです。
日本ではパシフィコ横浜で年に1，2回似たような開発者向けのイベントはありますが、実際に開発をしているMSの担当者と話が出来るわけではないので、必然的に密度というものは違ってきます。
あ、MSの担当者がいても日本人の場合言葉の壁が高すぎる気もしますが…最悪コードで会話をするしかないですね（笑

気になった点

ムーアの法則がこれまでのクロック数からコア数に…ってことからかやはり並行処理（Concurrent)や並列処理（Parallel）に関する話題が取り上げられていますね。
WindowsAzureが今回の目玉！って何かに書いてありましたが、さすがです。川西さん。ほとんど触れていません。
情報がどうしてもとぎれとぎれになっているので、全容はつかみきれはしませんが、

• MSRではCuzzとFeatherLiteを開発
  • Cuzz: 百万回に1回のバグを見つけるツール
  • FeatherLite: 軽量なデータ競合検出

百万回に1回のバグを見つけるツール…って。どういう条件でどういう内容のバグを見つけるんだろう。
ううむ、ちょっと気になるな。ツールもさることながら、バグが気になるぞ

AccessからOracleへのデータ移行

先輩から引き継いだAccessで作られたツールが、ちょっと性能的な限界を迎えたので社内のOracleサーバーにデータを移行しようと思った。調べてみるとOracleがAccessからのMigration用のツールを提供しているのでとても簡単

意外と簡単！？　Oracle Migration WorkbenchによるMS-Access→Oracle移行
http://otndnld.oracle.co.jp/easy/access/shift_manual/index.html

だと思ったら、実はものすごくめんどくさかったのでメモ。

不思議なツール構成

AccessからOracleに移行するには上記の手順に従うと大きく２つのステップが必要となる。

1. Accessの情報を吸い出す
2. 吸い出した情報を使ってOracleへ移行

ツールとしては、Accessで作られたExporterと呼ばれるエクスポートツールと、MigrationWorkbenchと呼ばれるデータをインポートするためのツールを使うのだが…。なぜかExporterは表の情報をXMLファイルにエクスポートするのみ（正確にはデータをDATファイルに落とすこともできるのだが、是術した手順では使用しない。使いづらいのか？）。実際にデータを移行するのはMigrationWorkbenchがAccessに直接アクセスして移行しているようだ。表の情報を別に出力している理由が分からない。

なんとか情報を吸い出して、Migrationを実行しようとするが、ここでも注意が必要だ。
WorkbenchがサポートしているMigrationは、ユーザーやテーブルスペースが固定されてしまっている。スキーマ情報を出力したXMLファイルを修正することで変更をすることができるには出来るのだが、ユーザー名＝テーブルスペース名という制限がついてしまう。
つまり、Migrationを実行するには専用の環境を用意する必要があるという事だ。

移行する時の注意点

Oracleと違ってAccessは結構なんでもありの世界になっている。テーブル設計がある程度の常識を持って作られていれば特に問題はないのかもしれないが、中途半端に”ユーザーに分かりやすく”を目指しているととても色々と出来てしまう。

• 禁止文字の使用
  • Oracleではテーブル名やフィールド名に使う事が出来る文字列に制限がある。ところがAccessには制限が無い（もしくは緩い）ために、ここで齟齬が生じる。Workbenchではこれを自動変換して対応を使用とするのだが、これがどうもイマイチ中途半端のように見受けられる。
• テーブルの長さが20まで
  • Oracleのテーブル名やフィールド名のサイズ長は30バイトのはずなのだが、Migrationツールで情報を吸い出すと20バイトまでしか取り扱ってくれずに切れてしまう。半角カナは2バイトとしてカウントされてしまうようだ。多くの場合は問題ないかもしれないが、フィールド名が「かえる用のフィールド１」「かえる用のフィールド２」なんてつけ方をすると途中で切れてしまって、フィールド名重複のエラーが出る

しかも、Office2007でやってみたらうまくいかなかった。うまくいかなかった原因がOfficeにあるのか設定にあるのか。このあたりは定かではないのだが、あれこれと制約や制限。出来ない事が多すぎて結局今回はOracleへの移行にWorkbenchを使用するのをあきらめ、自分で移行用のプログラムを書いてしまうことにした。

前々からそうなのだが、Oracleはあまりにもユーザーインターフェースがずさんなように感じる。パッチをあてるにしろインストールにしろ、あまりにもひどい場合が多い。
DBの性能がいいことに胡坐をかいてしまっているのではないだろうかと思ってしまう。何とかしてほしいものだ

MacBook Air 11インチ欲しい！

冒頭から何を言い出すんだと言われるとちょっと困るんだが、”はてな”がキャンペーンでブログを書けば抽選でMacが当たると言うので書いてみることにする。

WindowsとMacと私のこれまで

大学時代は、個人ではWindowsPCを持っていたのだがサークルで所持していたのがMacだったので、実際にはMacのほうが使用量は多かった。
ただ、研究室のPCはMacではなくWindowsPCだったので大学4年以降はほぼWindowsということになる。会社でももちろん大多数の人がそうであるように、Windowsだ。
実際問題、職場で使うPCに関して言えばよほどの働きかけがない限り自分でOSを決めることは難しいと思う。ただ、個人で持つPCに関して言えばそんな制約は実際のところないはずだ。にもかかわらず、家のPCもWindowsPCを使っている。

Windowsを使う理由

日常的にWindowsを使う利点は、細かい設定や機能を実際に自分が使うことで知るようにしているからだ。仕事でももちろん使っているのだけど、お客様からソフトウェアと直接的には関係ない質問を受けたりもする。お客様からしてみたら「プロなんだからちょこっと教えてよ」的な軽いノリなんだけど、ときとしてこれは答えに詰まる場面がある。
自分で日常的に使っていると、自分にとっての不便な点は調べてなんとかしようとするので、その”救える幅”を広げることができる。
もちろん、そんなことはまれなうえに万人に言える話ではないのであくまで私としてはだ。
ただ、お客様に限らず友人や親類に至るまで使っているPCが圧倒的にWindowsが多い以上、そこに対する知識を持っていることは役に立つ確率は高い。
だからこそ、知ってる人が少ないMacをやっていればより役に立つよ！って話はもちろんあって、もっともだと思うんだけど、別にそれを生業にしているわけでもないしね。。。

Macに興味が出てきた？

正直言ってMacには興味がなかった。
性能だとか使い勝手に関してはそれほど気にしてなかったんだけど、「Mac素晴らしい。まだWindows使ってるの？」みたいに見下したような言い方をする人がチラホラ見えたことが原因。
少数派に見られがちな少数派カッコいい的な話にうんざりしてしまった面が強いともいえる。まぁそれらは人の問題であってMacの問題ではない。やはり、Macを使わなきゃいけない場面がなかったというのが大きいのかな。

ところが、それはそれとしても興味が出てきたのはやっぱりiPhoneの影響だ。
もちろんiPhoneはWindowsPCとも連携できるのだけど、Macとであればもう少し色々できるのではないか？と思ってしまう面もある。これは想像。
単純に長年Macを離れていることもあるので、今どうなっているんだ？って言うのもある。
でもまぁ、やっぱり一番気になっているのはiPhoneアプリ開発じゃないかな？iPhoneアプリってMacじゃないと開発できないんだよね、基本的には。正直そういう戦略を取るのってどうよって気がしないでもないが、まぁそれはそれだろう。
実際に開発している時間なんてあるのか？と言われればなかなか答えに窮するところはあるが、それでもやってみたいものはやってみたいものだよね。

ってわけでください（笑）