組織行動——役割分担

　問題解決には、多くの人を巻き込んで、お互い協力して進めていくことが必要になる。一つの組織に属し、それなりの立場にあるはずの人たちが、外に向かって各人バラバラに好き勝手なことを言ったり行動したりすれば、それだけで周囲はビックリしてしまう。その組織が何を考え、どっちを向いて何をやろうとしているのか、誰の言うことを聞けば良いのか、誰と話をすれば良いのか、誰が責任者なのかさっぱり分らなくなる。周囲を混乱させ、進める側の力は相殺され、話を進めることすらできなくなる。闊達（かったつ）な議論は内部でやるものだ。
　チームとして人が力を発揮するためには、ビジョン、戦略、方法についての共通認識がまず必要である。その上で各人の役割分担を明確にしておかなければならない。組織運営の基本である。
　なお、大きな問題、小さな問題に関わらず、任せられると自分の好き勝手にやっていいと誤解する人がいる。多岐にまたがる事項や、微妙な問題などについては、局面局面でよく状況や各人の発言や行動の確認や調整をしておかないと、齟齬を来たすものである。
　問題の性質によって多少異なるが、定期的な連絡会のようなものは必須である。「必要なときには連絡する」というのは、多くの場合、機能しない。困難な段階など、お互いの連携が本当に必要なときは、多くの場合、大変多忙になっている。目先のことにとらわれて、連絡は後回しになりタイミングを失する。相手が解決策やその知恵を持っている場合もある。自分は問題ないと思っていても、相手にとっては大問題という場合もある。

ビジョン・戦略・方法

　問題解決へ向かって物事を進めていくには関係者の力の結集が必要になる。そうするためには、背景や目的の明快な説明とビジョン、戦略、具体的な進め方の提示が必須である。人は現状を知り、その解決の必要性と意義を理解し、ビジョンによってどのような姿を目指すのか納得し、戦略からどんな価値観や考え方で望むのかを得、それを具体的にどんな手順や方法で進めて行くのかを知って初めて安心して行動に移れるようになる。優れたリーダーはビジョンや戦略、妥当な方法の概略を直感的に頭に描けていることが多い。それは真剣な研鑽と修羅場のような経験から得られるものだと思う。

交渉・折衝・調整力と信頼関係

　問題を解決していく上では、関係者の利害関係を踏まえ、バランスの取れた妥協点を見出す交渉、折衝や調整が必須の事項になる。WIN-WINの関係などそう簡単に構築できるものではない。「内部をまとめ切れない」「決めたことがあとから覆る、あるいは実行できない、しない」ような相手とは交渉にならないし、「主張すべきを主張しない」「小細工をする」「譲歩すべきを譲歩しない」人に対しては信頼感は生まれない。そして、そのような交渉の経過や結果が、それを外部から見ている第三者からの失望を買っていたり、将来に付け込まれる火種を作っていたりもする。
　途上の過程では駆け引きや一種の脅しなどの交渉戦術も必要であろうが、最終的には相互の信頼が決め手になる。その信頼関係のベースもまた、「能力とやる気」や「毅然とした態度」である。
　人間性は切羽詰った状況で表に表れる。仕事上の信頼関係は、仕事上の具体的な事象を通じて醸成されて行く。「まず良き個人的な人間関係を築き、仕事上の問題はその後に……」といった悠長なことを言っていられる時代ではない。世の中には「大変良い人だが、仕事のパートナーとしては失格」という人もいれば、「仕事上は全幅の信頼が置けるが、プライベートの付き合いはごめん被りたい」といった人もいる。

志と言葉の重さ——リーダーの資質

　人を使う——つまり他の人の働きによって成果を上げる立場の人の言葉は「重い」。マネージャにおいても然りである。長い間、皆が問題と思っているのに解決できていない問題は、大変難しい問題であることを多くの関係者は知っている。「理想の思い」「あるべき論」を語るだけでは、本気にされなくても、結果として「お前、あのときそう言ったじゃないか」と、対外的にある種の債務を負うことになる。あるいは、一途の希望を持った人を大いに傷つけてしまう。
　リーダーたる人は、時代が求める「やるべきこと」をやらなければならない。そして「ひとたび口にしたこと」は、石にかじりついてもそれを実現しなければならない。また、一度失敗すれば、その課題に再挑戦する人はなかなか出てはこない。問題は長期に放置されることになる。この機会損失もまた極めて大きい。それだけの志と責任感、覚悟が必要なのだ。それがリーダーに求められる大切な資質だ。
　今まで私は、大抵のことはやり直しができるものだと思っていた。しかし、リーダーの立場にある人の無責任な一言が「やり直しの効かない、解決策のない」状態を生むのを、この歳になって初めて、そしてこの短い期間の内に何度も目の前にした。大変残念な得がたい知見であった。大変残念な得がたい知見であった。

高成長のウェブ会議市場、在宅勤務とクラウドでけん引

　国内ウェブ会議市場は、2010年度の出荷金額が約64億円で、前年から19.1％増の伸びを示した。ITRでは、出張コストの削減策という用途に加え、教育やセミナーなどでも利用されることから、用途の多様化が成長の要因と分析している。
　今後の見通しについては、在宅勤務需要が増加することから、市場はさらに拡大すると予測。なかでもSaaS型のウェブ会議市場は、2010年度が前年比38.7％増の43億円で、2011年度も引き続き好調な伸びを示すと予測している。また、2010年度のウェブ会議市場全体に占めるSaaS型のシェアは66.9％で、2011年度も拡大すると見ている。
　2010年度のSaaS型ウェブ会議市場のベンダーシェア（出荷金額ベース）では、SaaS販売へと急速にシフトしたブイキューブが1位を堅持し、シェアを30.2％に拡大。2位には「SaaSモデルの先駆者」（ITR）のシスコシステムズが22.1％。以降、3位はNTTアイティで12.1％、4位はジャパンメディアシステムで6.3％、5位はITXで4.0％だった。
　ウェブ会議システムの用途は、"個人間コラボレーション"や"チーム・ミーティング"といった従来からのものに加えて、社外の取引先との情報交換を目的とした"社外コラボレーション"、社員研修などを目的とした"教育／トレーニング"、経営トップのメッセージを全社員に伝えるなどの"全社会議"といった用途も注目されています。今後の社会情勢の変化によっては、電話やメールを補完する重要なコミュニケーション・インフラとして、一気に企業に浸透する可能性も秘めていると見ています。

Facebook、「Facebook Deals」のテストを開始--グルーポン対抗の共同購入サービス

フォームの終わり
　ソーシャルネットワーク大手のFacebookは米国時間4月25日夕方、地域のお買い得情報を提供する同社の新しいサービスのテストを開始する準備が整ったと発表した。同社はこのサービスを提供することで、人気が過熱している共同購入による利益を上げたいと考えている。
　 2011年3月に最初に発表された「Facebook Deals」は、会員が購入可能な地域のお買い得情報を提供するサービスだ。お買い得情報は、同ネットワーク上で友人に紹介したりすることもできる。カリフォルニア州パロアルトを拠点とするFacebookは25日の声明で、今回のテストを26日にオースティン、アトランタ、ダラス、サンディエゴ、サンフランシスコで開始するが、テスト地域を他の都市にも拡大する可能性があることも述べている。
　テスト対象となる5都市のユーザーは、自分のFacebookホームページの「Deals」タブをクリックすることにより、お買い得情報を電子メールや通知で取得できるようになる予定である。また、友人があるお買い得情報に対し「like」（いいね!）ボタンをクリックしたり購入したりすると、「News Feed」を介してその情報を取得することもできる。
　Facebookは、Opentable、Gilt City、Tippr、PopSugar City、Plum District、ReachLocal、Zozi、Home Run、KGB Deals、aDealio、ViaGoGoといった他の多数のお得情報提供サイトと連携して、この事業に取り組んでいる。

リーダーを目指す3つの指針

　リーダーの役目をまとめましょう。
1. メンバーや顧客に対して、常に信頼や安心、納得を提供しながら
2. 安定した仕事環境をつくり
3. 会社の利益を上げる
　リーダーの仕事は非常に難しいですが、経験や年齢を重ねるにつれて、リーダーの役目を求められるようになってきます。この事実から逃げていては、良いキャリアを築けません。
　リーダーを目指す、あるいはリーダーになることを求められているエンジニアは、以下の「3つの指針」を意識して仕事に取り組んでみてください。
　（1）面倒くさい仕事でも、ずるずると後回しにせず、優先順位を考えて行動する→責任逃れを防止し、メンバーや顧客に信頼感を与える
　（2）常に勉強や観察、情報収集を怠らない→自分の経験やスキルアップにつながって、相手に安心感を与える
　（3）ドタバタしている時でも、状況をじっくり眺めて落ち着いた行動と判断をする→失敗しても理由をきちんと説明できることが、相手に納得感を与える

現場を支える土台をつくる、3つの「安定ビュー」

　リーダーが「信頼感」「安心感」「納得感」を関係者に与えることで、現場や仕事の土台が安定します。決断力や交渉力といったスキルは、自分が関わる人々、現場の「安定」上に成立します。逆に、どんなに決断力や経営力があったとしても、信頼できない、安心できない、納得できない人はリーダーとは呼びたくないでしょう。
（1）「信頼感」を与える行動ビュー
　「リーダーに付いていこう」「リーダーのいうことに従っても問題ない」と感じさせる行動。「ウソ」をついたり「デマ」を流したりすることは禁物です。
（2）「安心感」を与える行動ビュー
　「失敗してもリーダーが回復援助してくれる」「リーダーのヘルプを借りることで再生できる」と感じさせる行動。相手に安心を与えるためには、いつでも「相談」できる体制を整える、「アドバイス」を適切に行うようにしてください。
（3）「納得」を与える行動ビュー
　「リーダーの発言や行動に違和感がない」「ロジカルで筋が通っている」と感じさせる行動。相手を納得させるためには、「宣言」したことや「約束」したことは必ず実行することが不可欠です。

チーム創りの5要素

1.良質なビジョン

2.チーム信頼関係

3.協働意志／コミットメント

4.他者実現

5.チーム学習

 

「Oracle Exadata」を採用する企業のホンネ

　日本オラクルは4月20日、提供するデータベース（DB）マシン「Oracle Exadata」が信販大手のオリエントコーポレーション（オリコ）や医薬品大手の塩野義製薬など計5社に採用されたと発表した。導入事例は1社ごとに発表されるのが通例であり、今回のように5社まとめて発表されるのは珍しい。

　Exadataの採用を決定したのは、オリコと塩野義のほかに、着メロなどのコンテンツサービスを展開するフェイス、デジタルコンテンツを配信するメディアドゥ、日本最大のポータルサイトを運営するヤフーの計5社。オリコでは会員管理基盤システムとして、塩野義では営業支援系情報基盤として、フェイスではグループのプライベートクラウド基盤として、メディアドゥではコンテンツ管理・配信システム「md-dc」用DBとして、ヤフーでは広告システム基盤として採用を決定した。

　フェイスは、音楽や映像コンテンツの配信、オンラインゲームの運営に加え、オンライン決済システムなども提供している。高速な分析性能とオンライントランザクション処理（OLTP）を実現できるというExadataを活用することで、ユーザーのニーズを的確にとらえ、さまざまなコンテンツを好きな時に好きな場所で楽しめる環境を創造していくとコメントしている。

　メディアドゥでは、2004年から推進しているという"Contents Aggregation System（CAS）"構想のコンテンツ管理・配信エンジンであるmd-dcに、Exadataの高速性が必要と説明している。OLTPとデータウェアハウス（DWH）、バッチ処理というすべてのワークロードをExadataの上に実装できるとされている。同社は今後のスマートフォン市場での成長戦略を描く中で、そうしたExadataの機能に魅力を感じたことから採用を決定したと、理由を説明している。

　ヤフーでは、広告事業を支える大量データの高速集計、バッチ処理の強化と、それによるサービスの品質向上を目的にExadataの採用を2月に決定したとしている。Exadataの性能や短期導入の実績、既存のDB基盤との連携、長年培ってきたというDB運用のノウハウをそのまま活用できるという判断もあって、Exadataを採用したことも明らかにしている。

　Exadataは当初、DWHアプライアンスとして喧伝されたが、現在はDBマシンという枕詞が付く。DWHという情報系システムの基盤だけではなく、業務系システムの基盤としても活用できることが大きいからだ。今回の5社の採用の内訳を見ても、情報系と業務系の両方の基盤として活用できることが分かる。

　オリコの会員管理基盤システムやヤフーの広告システム基盤、フェイスグループのプライベートクラウド基盤、メディアドゥのどれもが業務系としてExadataを採用する。これらの企業では、以前から業務系システムのDBとしてオラクルの「Oracle Database」を活用。その延長線上の選択として、使いやすく高速のExadataを選択している。塩野義の場合は、営業支援系の情報基盤として、つまり情報系の分析基盤としてExadataを選択している。

　今回の5社を含めると、Exadataを選択している日本企業は（実稼働しているところも含めて）18社になるとオラクルは説明する。だが、この18社は「企業名を公表してもいい」（広報室）という数字でしかない。「実際に導入している企業数は2ケタ」と説明する。

 

Facebookユーザー同士で無料電話が可能な「Bobsled」……T-Mobileが提供

ドイツのT-Mobileは19日（現地時間）、Facebookユーザー間での無料音声通話を可能にするアプリケーション「Bobsled」を発表した。

同アプリケーションでは、Facebookチャットを通して、Facebook上の友人の名前をクリックするだけで、音声通話を行うことができる。グローバルで通話をする場合でも、MacのPC同士であれば料金はかからないという。現状モバイル端末には対応しておらず、PC間のみでの利用となる。

またボイスメッセージ機能も搭載。録音したボイスメッセージをFacebookのウォールに投稿し、他のユーザーへ公開することもできる。今後はビデオチャット機能や、VoIP（Voice over Internet Protocol）による米国内
のモバイル端末や固定電話との通話、スマートフォンやタブレットへの対応も進めていく予定だという。

Amazon、図書館から電子書籍を借りる「Kindle」用サービス

米国 Amazon.com は2011年4月20日、電子書籍リーダー/アプリケーション「Kindle」向けの新サービスとして、米国の図書館から電子書籍を借りられる「Kindle Library Lending」を発表した。2011年後半より提供する予定。対象図書館は1万1,000館以上という。

同サービスは、電子書籍リーダー Kindle の全モデルと、Amazon.com が無償提供している全ての Android / iOS / Windows / Mac OS X / BlackBerry / Windows Phone 用 Kindle アプリケーションで利用可能。

図書館から借りる電子書籍は、Amazon.com の電子書籍「Kindle Book」と同様に扱われる。データ同期技術「Whispersync」に対応しており、読んでいるページやノート、ハイライトなどの情報は、無線 LAN（Wi-Fi）/ 3G 携帯電話ネットワークを介して Kindle デバイス/アプリケーション間で共有できる。ユーザーが付加したノートとハイライトは図書館に電子書籍を返却しても Amazon.com が保存しているため、同じ電子書籍を再び図書館から借りたり Amazon.com で購入したりすると再度アクセスできるようになる。

なお、Amazon.com は Kindle Library Lending を実現するにあたって、米国 OverDrive の協力を得ている。

最初の5秒＋その後の4分が人間関係を築くカギ

　「第一印象は○秒で決まる！」——さまざまな説がありますが、さて、第一印象はどれくらいで決まるのか？　わたしの答えは、最初の5秒＋その後の4分。「4分5秒で決まる」と考えています。本書のタイトルにある「4分5秒」は、第一印象が決まるまでの時間を指しています。
　イメージコンサルティングとは、日本ではまだまだ認知度が高くない職業ですが、「その人の能力や自信を見た目につなげること」と、定義しています。それは、流行の洋服を格好良く着こなすためのテクニックではなく、ビジネスシーンで自分の価値を高めるための演出法。その人のポジションや目的に合った服装から身だしなみ、立ち居振る舞い、コミュニケーションを総合的に考えて、その人の能力や自信が第三者に的確に伝わるための具体的なアドバイスをする役割を担っています。
　ここ数年、ビジネスシーンでも第一印象の重要性が広く知られるようになりました。とはいえ「第一印象を良くすること」は、「服装やヘアスタイルなどの見た目を良くすること」と、まったくイコールである、と考えている人も多いようです。
　ですが、「見た目を良くするだけでは、第一印象は完成しない」、ということです。第一印象は、初めて会ってパッと見たときの5秒の直感的な印象と、その後に続く、しぐさや会話といった4分のコミュニケーションによって作られます。その4分5秒のやりとりが相手の脳裏に強烈にインプットされ、その後、人の印象として長く続いていくものなのです。

Facebook、二要素認証や報告機能の拡張でセキュリティとプライバシーを強化

　米Facebookは4月19日（現地時間）、二要素認証やHTTPSでの接続など、ユーザーのプライバシー保護を強化する新しい機能を発表した。
　二要素認証は、メールアドレスとパスワードに加えて、もう1つの要素を記入しないとログインできないようにする機能。同日か全ユーザーに向けて段階的に同機能を追加していく。
　Facebookは1月に通信データを暗号化するHTTPS接続をオプションで有効にできるようにしたが、これをさらに拡大し、ユーザーがHTTPSを利用せずにFacebookにアクセスしている場合でも、利用完了時にセッションを自動的にHTTPSに切り替える。
　また、不適切なコンテンツを報告する範囲を拡大し、プロフィール、ページ、グループに関しても報告できるようにした。コンテンツの報告の際には、ユーザーが自分でできる対策についてのアドバイスが表示されるようになった。
さらに、ユーザーが安全にFacebookを利用するための情報を集めた「Family Safety Center」を公開した。未青年のユーザーやその保護者に向けた動画やテキストによるアドバイスがまとめられている。また、Facebookは数週間中に、教育者向けのガイドをダウンロード提供する計画だ。

グーグル、「Map Maker」を米国で提供開始--ユーザーによる地図編集が可能に

2008年にローンチされ、183カ国で公開されているクラウドソースのウェブ地図アプリケーション「Google Map Maker」が、遂に米国でも提供されることになった。Map Makerは米国
におけるGoogleの地図サービスにとって重要な機能追加で、それによって地図の詳細さと有用性が今よりも格段に向上する可能性を秘めている。

一部の国々（Map Makerの技術を統括するLalitesh Katragadda氏が筆者に話したところによると、ルーマニアなど）では、Map Makerのユーザーが完全な地図を一から作成してきた。米国では
Map Makerの編集機能を利用することで、より多くの商業データ（店舗や商店などの位置情報）や現状では欠落している極めて具体的な道路情報（例えば、道路工事に伴う一時的な道路封鎖）を追加できるようになる。このデータは、Google Mapsと
「Google Earth」、Googleのモバイル製品の全てで利用可能だ。Googleのルート案内サービスは、交通に関する最新情報を考慮に入れるようになるだろう。

Katragadda氏は、小さな町において土地や商店の所有者がGoogleの位置情報の表示方法に興味を持ち、近くの公園の道などを地図に追加して近辺地域をより魅力的に見せるようになるのではないか、と考えている。

ログイン済みのGoogleユーザーであれば誰でも地図を編集できるが、新しい参加者が追加した変更は全てのユーザーに公開されるリアルタイム地図に自動的には反映されない。ユーザーが追加した最新情報は、実績のあるユーザーに編集内容の承認／却下の判断（あるいは差し戻して内容を修正してもらう）を求める検証プロセスを経ることになる。ユーザーが修正を求められることなく編集内容を投稿できるようになるに従って、承認プロセスを経ずに公開地図をアップデートし、自分自身がほかのユーザーの編集内容を検閲するモデレーターになる道が開けてくる。

Map Makerの狙いは「有機的な」Google Mapsを作ることだ、とKatragadda氏は話す。完全な承認を得たユーザーによるアップデートは「数分」で反映され、ルート案内サービスはすぐにその最新情報を利用する。従って、最近流行の移動式レストランのような移動店舗所有者は、一刻も早く承認を得たいと思うだろう。ただし、米国時間4月19日の発表にモバイル向け地図編集コンポーネントは含まれていなかった。Map
Makerの使用にはフルウェブブラウザが必要となる。

Map Makerツールに対するアップデートにより、「Google Street View」の画像も確認できるようになるため、地域の地図製作者はその画像を利用して地図データの作成や編集を行うことができる、とKatragadda氏は付け加えた。

日本 MS、インストール先を Mac 1台に絞った廉価版「Office 2011」

日本マイクロソフトは2011年4 月20日、Macintosh（Mac）向けオフィス アプリケーション新製品として、Mac 1台だけで利用可能な「Microsoft Office for Mac Home and Student 2011 ‐ 1 パック」「同 Home and Business 2011 ‐ 1 パック」の販売を5月20日に開始すると発表した。税込み参考価格は、Home and Student が1万5,750円、Home and Business が2万6,250円。

両製品は、2010年10月の Office for Mac 2011 発売を記念し、限定版として一時販売していた特別パッケージ。今後は通常製品とする。いずれも、インストールした Mac 1台だけで利用可能なライセンスが適用される。

Office for Mac Home and Student 2011 - 1 パックに含まれるアプリケーションは、「Word 2011」「Excel 2011」「PowerPoint 2011」など。一方、Home and Business は「Outlook for Mac 2011」も含む。

なお、Home and Student には家庭内の Mac 最大3台で利用できる「ファミリーパック」（税込み参考価格1万7,850円）、Home and Business には同一ユーザーがデスクトップ/ノート パソコンの2台で利用できる「2パック」（同3万4,650円）もある。

KDDI、Android搭載スマフォ向け電子書籍配信サービス「LISMO Book Store」開始

　KDDIは19日、電子書籍の配信サービス「LISMO Book Store」の提供開始を発表した。auのAndroid搭載スマートフォン向けに20日より開始する。

　「LISMO Book Store」は、「au one Market」から「LISMO Book Store」のアプリケーションをダウンロードすることで、電子書籍の購入、閲覧が可能となるサービス。購入した本は、同一の「au one-ID」により、ユーザが持っている他のauのAndroid搭載スマートフォンや電子ブックリーダー「biblio Leaf SP02」でも読書が可能となる。

　「LISMO Book Store」では、XMDF、ドットブック （.book）、BS Formatに対応し、小説・ビジネス書・実用書などの文字コンテンツに加えコミックや写真集も提供する。サービス開始時には約3万点のコンテンツを取り揃え、今後順次拡充する。またGREE、mixi、Twitterなどのソーシャルネットワークサービスへリンクし、簡単に感想を投稿できる機能、ダウンロードした電子書籍を本棚のように表示・管理できる機能、読書後に次話を自動で検索してすぐに購入できる機能なども提供される。

　「LISMO Book Store」の提供開始にあわせ、道尾秀介の直木賞受賞作『月と蟹』、ハロー！プロジェクトのアイドル真野恵里菜のファースト写真集を独占コンテンツとして配信する。また、電子書籍を購入した際に通常時の2倍のポイントをバックする「ポイント2倍キャンペーン」、購入した電子書籍へのレビューを投稿した読者に購入金額の4％をポイントバックする「レビューポイントキャンペーン」などのキャンペーンを、6月30日まで実施する。対応機種はIS03で、今後順次拡大予定。

実行できるアプリケーションを制御する「AppLocker」

　Windows 7から新たに提供されたAppLockerを使用すると、"アプリケーションなどの実行可否を制御する"ことができます。
　組み込み機器では、通常、特定のアプリケーションのみが実行されます。そのため、用途に関係のないアプリケーションや、動作に支障を来す可能性のあるアプリケーションを起動させないようにする必要があります。
AppLockerの設定について
　AppLockerは、"ローカルセキュリティポリシー機能"の1つです。
　スタートメニューの［プログラムとファイルの検索］ボックスで、「gpedit.msc」と入力し、［ローカル グループ ポリシー エディター］を起動してください。
　左ペインにあるツリーの「コンピューターの構成」の項目を以下のように展開していくと（図1）、AppLockerの設定画面を表示することができます。
　AppLockerでは、以下の3種類の規則を設定することができます。
* 実行可能ファイルの規則
* Windows インストーラの規則
* スクリプトの規則

　なお、それぞれの規則の対象となる拡張子を以下に示します。
実行可能ファイル
exe、com
Windows インストーラ
msi、msp
スクリプト
ps1、bat、cmd、vbs、js

　例えば、［実行可能ファイルの規則］では、実行されるアプリケーションが指定フォルダ内に存在するかどうかだけでなく、そのファイルを誰が実行したかといった条件も設定可能で、細やかな実行可否設定ができます。また、それらの条件を複数組み合わせることもできます。実際の設定方法に関しては後述します。
　ただし、特に規則のチェック機構が存在するわけではありませんので、それぞれの設定が矛盾しないように気を付ける必要があります。
　規則を作成したら、［規則の実施の構成］をクリックし、規則のコレクションが実施されるか、監査だけ行うかを設定します。
　上記の設定が完了したら、AppLockerをつかさどる「Application Identity」サービスを起動します。サービスが起動すると設定された規則に基づいて、アプリケーションなどの実行可否が制御されます。

マイクロソフト、「Office 365」の一般ベータ版を公開

　Microsoftは、同社のクラウドベースサービス「Office 365」のパブリックベータ版を公開し、誰でも試用できるようにした。
　38カ国、17の言語で利用可能な今回の新しいベータ版がリリースされる前には、同サービスの品質調査を許可された数千社の企業による限定的なテストが数カ月にわたって実施されていた。このパブリックベータ版に続き、Office 365の正式版が2011年中にリリースされる予定である。
　2010年10月に発表されたOffice 365は、Microsoftが従来から提供するデスクトップおよびサーバ製品の一部に代わるクラウドベースのサービスを企業向けに提供することを目的としている。同サービスは、「Office Web Apps」に、「Exchange」および「SharePoint」のホステッド版と、オンラインコミュニケーションおよびコラボレーションサービスを提供するMicrosoftの「Lync」製品を組み合わせたものである。
　したがってOffice 365は、ドキュメントの作成および共有、電子メール、IM、オンライン会議、パブリックウェブサイトなど、ありとあらゆる機能を提供する。またMicrosoftは、同社のエンタープライズセキュリティクライアント「ForeFront」という形で保護機能も提供しており、サービス全体に対し99.9％の稼働を保証している。
　Office 365は正式版のリリース後、企業の規模に応じて2種類のプランで提供される予定である。従業員数25人以下の小規模企業は、ユーザー1人につき1カ月あたり6ドルで、Office Web Appsと「Exchange」および「SharePoint」のホステッド版が利用できる。それよりも規模が大きい企業は、ユーザー1人につき1カ月あたり10〜27ドルの4種類のプランの中から選択する必要がある。
　Microsoftは、企業以外に教育市場もターゲットにしており、教育機関の教員、職員、学生を対象とした5種類のプランを用意している。
　また今回、「Office 365 Marketplace」のベータ版も利用可能になった。Office 365 Marketplaceは、Office 365を補完することを目的とし、さまざまなMicrosoftパートナーが提供するアプリケーションやサービスを企業が容易に検索できるように支援する。
この記事は海外CBS Interactive発の記事を朝日インタラクティブが日本向けに編集したものです。

Android向けSkypeに個人情報流出の脆弱性が発覚

　Android向けのSkypeに、ユーザー情報の流出につながる脆弱性があることが分かり、Skypeが対応に乗り出した。
　Skypeのセキュリティ情報によると、この脆弱性を突いた悪質なサードパーティーアプリケーションをAndroid端末にインストールすると、端末に保存されたSkypeのファイルにアクセスされる恐れがあるという。流出の恐れがある情報には、キャッシュされたプロファイル情報やインスタントメッセージなどのファイルが含まれるとしている。
　同社は、ファイルパーミッションのセキュリティ強化を含め、ユーザーをこの脆弱性から守るための迅速な措置を取ると表明。「ユーザーは個人情報を守るために、端末にインストールするアプリケーションは注意深く選んでほしい」と呼び掛けている。
　この脆弱性は、Android情報サイトの「Android Police」で最初に報告された。ネットに流出した「Skype Vide」のβ版を調べていた開発者が、Skypeの個人情報の保存方法が適切でなく、比較的簡単に取得できてしまうことを発見。さらにβ版だけでなく、2010年10月から配布されているSkypeの標準版にも同じ問題があることが分かったという。
　開発者はこの問題を突くコンセプト実証アプリケーションを作成し、ユーザー名、住所、アカウント名、電話番号、連絡先などの情報を許可なく引き出せてしまうことを実証している。
　セキュリティ企業の英Sophosはこれを受けて、Android端末に保存されたSkypeのデータはどれも暗号化されていないようだと指摘。問題が解決されたことを確認するまで、Android端末からSkypeを削除するのが最も安全だろうとアドバイスしている。

AppleがSamsungを提訴 Galaxyによる知財侵害訴え

　米Appleが韓国のSamsung Electronicsを特許と商標の侵害で提訴したと、米各紙が伝えている。
　報道によると、Appleは4月15日にカリフォルニア州北地区米連邦地裁に訴状を提出し、Samsungのスマートフォン・タブレットファミリー「Galaxy」がiPhone、iPadの技術やUI、パッケージングを模倣していると申し立てた。訴状では、iPhoneの物理的設計に関する特許、アプリアイコンの商標、トレードドレスなどの侵害を挙げているという。同社は損害賠償と侵害製品の販売差し止め命令を求めている。
　Samsungは積極的に対応していくとメディアにコメントしている。
　AppleはこれまでにもライバルのNokiaやHTCに対して訴訟を起こしている。SamsungはAppleのライバルではあるが、iPhone、iPadに部品を主要な供給するサプライヤーでもある。

机や壁、ペットボトルをスピーカーに変える、iPhone/iPod対応外付けスピーカー

デバイスネットは18日、机や壁をはじめ段ボール箱やペットボトルなどに接着し、スピーカー代わりに利用できる「ピタッとスピーカーplus」（型番：DN-B300）を発表した。販売開始は22日。価格はオープンで、予想実売価格は3,980円前後。

「ピタッとスピーカーplus」は、iPhone/iPod、スマートフォンやポータブルオーディオプレーヤー、携帯ゲーム機などと3.5mmステレオミニで接続して利用する外付けスピーカー。音の振動を伝導させることで"いろんなものをスピーカーに！"とうたう。

その仕組みは、粘着シールか吸盤で接着すると、接着した対象物を振動させて音を鳴らすというもの。段ボール箱やペットボトル、ホワイトボード、スーツケース、バスルームのアクリル製の扉など、振動するものであればさまざまなものが対象物となる。

2010年1月発売の「ピタッとスピーカー」（型番：DN-A002）の上位モデルで、従来品は電源が単4形乾電池×3（連続駆動時間は約8時間）のみであったが、新製品ではこれに加えてUSBバスパワーにも対応。また、従来品は接続機器で音量調整を行なうが、新製品では本体にボリュームコントローラーを備えた。

本体カラーはホワイト/ピンク/ブラックの3色を用意。本体サイズは幅80×高さ17×奥行き43mm、重さは85g（本体＋スピーカー）。付属品は接続コード/USBコード/専用粘着シール×3/吸盤/ポーチなど。

メインフレームのオープン化が進まない理由

日本オラクルが最新ソリューションを投入
　日本オラクルが4月12日、メインフレーム上のアプリケーションをオープン環境に移行するミドルウェア「Oracle Tuxedo ART 11g R1」（以下、Oracle Tuxedo ART）の提供を開始すると発表した。
　メインフレーム上のアプリケーションをリホストし、UNIX／Linux環境で動作させることで、メインフレームの高い維持費用を大幅に削減するとともに、最新のオープン技術を利用できるようにするのが狙いだ。
　対象となるメインフレームは、今のところIBM製品だが、日本製品についてもパートナー企業との協業によって顧客ニーズに応えていく構えだ。
　Oracle Tuxedo ARTは、メインフレームのトランザクション処理を管理するCICS（Customer Information Control System）アプリケーションとJCL（Job Control Language）バッチプログラムを実行する「Oracle Tuxedo Application Runtime for CICS and Batch 11g R1」、およびメインフレーム上のアプリケーションをオープン環境に移行する「Oracle Tuxedo Application Rehosting Workbench 11g R1」の2製品からなる。
　メインフレームのアプリケーション資産をオープン環境に移行する工程では、アプリケーションおよびデータの変換を自動化するため、作業の工数を大幅に削減できる。CICSのオンラインプログラムは、メインフレームで稼働するCOBOLのビジネスロジックをそのままCOBOLに移行。データアクセスロジックはOracle DatabaseやISAM（Indexed Sequential Access Method）ファイル向けに自動変換される。
　また、IBMメインフレームにおいては、専用ターミナルである3270のユーザーインタフェースに変更を加える必要がないため、違和感なく利用でき、操作のための再教育も必要がないとしている。
　一方、バッチ処理については、JCLのジョブ構造とフローをそのまま維持しながらシェルスクリプトに変換される。シェルスクリプトから呼び出されるアプリケーションや各種ユーティリティは、IBMメインフレームと同様に、Oracle Tuxedo ARTのバッチ実行環境で動作させることができる。
　Oracle Tuxedo ARTのさらに詳しい内容については関連記事などを参照いただくとして、ここではこうした製品が出てきた背景を注目したい。
ベンダーにとっては今も大事な収益源
　日本オラクルFusion Middleware事業統括本部ビジネス推進本部シニアディレクターの清水照久氏は会見で、Oracle Tuxedo ARTを投入した背景についてこう語った。
　「欧米と比較しても日本ではまだまだメインフレームの稼働率が高い。オープン化のニーズはあるが、コストや所要時間を含め移行プロジェクトとしてリスクが高すぎるとの判断から踏みとどまっているユーザーが少なくない。そうしたユーザーを支援するのが今回のソリューションだ」
　そして、「メインフレームは現在、数千台が稼働しているとみられるが、そのうちの1〜2割は近いうちにリホストするだろうとみている」との予測を示した。
　清水氏の説明を言い換えれば、メインフレームのオープン化が進まないのは、ユーザーにとってリスクが高すぎるためだ。確かにこれまで長年にわたって作り込んできたシステムおよびアプリケーションをオープン環境に移行するのは高いリスクを伴う。
　メインフレームのオープン環境への移行は、UNIXを中心としたオープンシステムが台頭してきた1980年代後半から盛んに取り組まれるようになった。しかし、2000年代半ば以降はメインフレームの減少傾向も下げ止まった感がある。
　ただ、メインフレームに詳しい業界関係者によると、「メインフレームは国内での稼働台数が一昔前より減ったとはいえ、いまだ大手企業のメインサーバのうち3割近くを占めている」という。
　さらにその業界関係者は、「メインフレームのオープン化が進まないのは、ベンダー側の思惑もある。実は、メインフレームの製品単価はこの10年間ほとんど変わらずに推移している。それはすなわち、メインフレームならではの利益率の高さを維持しているということだ。メインフレームベンダーにとっては今も大事な収入源になっている」とも語った。
　つまり、メインフレームのオープン化が進まないのは、ユーザーにとってハイリスクである一方、メインフレームベンダーにとっても大事な収益源を失うことになるからだ。
　日本オラクルが投入した今回のようなリホストを行うソリューションや、さらにはクラウドコンピューティングの進展が、こうしたメインフレーム事情にどう影響してくるか、注目される。
　日本オラクルの今回のアプローチは、メインフレームベンダーではないオラクルにとって当然といえる。ただ気になった点を1つ。今後、日本製メインフレームを対象にした場合、緊密なパートナー関係にある富士通と、どのように事を進めていくのか。いうまでもなく富士通は日本最大のメインフレームベンダーである。
　どうせなら、両社の技術やソリューションを組み合わせて、今後のITのあるべき姿を世界に発信してもらいたいものである。

HTC Sensationお目見え！ ハンズオンしてみました

HTCの新フラッグシップ機、Sensationがお目見えしました。アルミニウムのユニボディは美しく、厚さはHTC端末で最薄の11.54mmです。

一番のポイントはデュアルコアチップです。クアルコム・Snapdragonシリーズのデュアルコア、MSM8260が1.2GHzで動いています。なので動画は1080pで撮れるし、マルチスレッディングも（搭載されているAndroid 2.3・Gingerbreadが許容する限
り）可能です。RAMは768MBで、最新のHTC機、たとえばDesire SやIncredible Sと同じです。

Desire HDやEvo 4Gと同様4.3インチスクリーンということですが、ベゼルがスリムに、背面も角をとるような加工がされているので、フットプリントサイズは小さ目になっています。スクリーンは16：9のSuperLCD qHDディスプレイ、解像
度は960 x 540です。タブレット端末HTC Flyerでも使われているSense 3.0の3Dエフェクトも快適に見られます。またHTC Sensationは、電話としては初めて（ワイングラスなどによく使
われる）コントゥール・ガラスを使っています。HTCによれば、これはより頑丈にするためだそうです。

さらにSense 3.0に関して言えば、ロックスクリーンが強化されて、機能を立ち上げたり、アプリをダウンロードしたりがロックスクリーンから可能になりました。また、どのライブロックスクリーンの「壁紙」を選ぶかによって、写真を撮ったり新規メールを書いたりする機能を、スクリーンロックを解除するのと同じ操作で立ち上げられます。使うときの時間短縮ができて、特にすぐ写真を撮りたいときにはすごく便利でしょうね。

バッテリー消耗する機能がこれだけ付いてきて（ライブロックスクリーンとか、3Dの天気予報とか）、バッテリーは大丈夫なのかと思うでしょう。でも放電容量は1520mAhで従来より改善していますし、HTCによればデュアルコアチップは何事もうまく処理してくれるので、午前4時に携帯が終了、充電もできないなんて事態にはならなそうです。

写真に関して言えば、8メガピクセルのカメラは全般に改善し、ボタンを押したときの反応も早いです。iPhone 4のスクリーンシャッターほど速くはないですが、これまでのHTC端末よ
りは良いです。iPhone 4同様、1080pの動画はアップロード前にトリミング可能で、動画にはオートフォーカス機能もあります。

SensationとタブレットFlyerの共通点がもうひとつあります。HTC Watchビデオストアで新作を含む映画を買ったり借りたりできます。ただ価格についてはHTCは明言を避けました。ソニーやワーナーブラザーズやディズニーやFoxやMGMなどなど、入手可能なタイトルはすべて対応するとのことです。

動画をダウンロードするとなれば、4GBの内蔵ストレージを使い切ってしまうことが予想されますが、HTCでは8GBのmicroSDカードを付属させています。

全世界で5月～6月に発売される予定です。気になるお値段ですが、HTCによれば「Desire
HDと同等の価格」になるとのことです。

NTTドコモ、音声メッセージをSMSで送信する「声の宅配便」サービスを発表

NTTドコモは15日、録音した音声メッセージをSMSを通して送信できるサービス「声の宅配便」の提供を、22日より開始すると発表した。対応機種は音声発信が可能な全てのFOMA端末となる（スマートフォン含む）。

送信先の携帯電話の番号の前に「*2020」を付け、発信することでセンターにつながり音声を録音することができる。音声メッセージは、1件につき15分まで録音できる。メッセージは最大500件まで、録音された時点から720時間の間保存される。ただし5件まではそれ以降も保存することができる。

同サービスはFOMAの音声プランに契約しているユーザーであれば、そのまま利用できる。月額使用料は無料で、メッセージの録音・再生時に通話料がかかる。22日に発売される「らくらくホン ベーシック3」には、発信画面
にソフトキーで「声の宅配便ボタン」が表示され、ワンタッチでサービスを利用することができる。

またスマートフォン版アプリを4月下旬に提供する予定だという。対応機種は、「GALAXY
S SC-01B」「Xperia SO-01B」「Xperia arc SO-01C」「MEDIAS N-04C」「LYNX 3D
SH-03C」「Optimus chat L-04C」の6機種。

VirtualBox 4.0

VirtualBox 4.0は32ビットおよび64ビットPCのフル仮想環境を提供する。4.0は多くの新機能と改善が実施されたメジャーアップグレードバージョン。4.0の主な特徴は次のとおり。
* VirtualBox管理アプリケーションの改善。動作状況のプレビューが表示されるようになったほか、これまで移動できなかった仮想マシン一覧を好きなように入れ替えできるようになった。また、管理アプリを起動せずとも直接仮想マシンを実行できるようにショートカット機能も追加されている。
* ローカルストレージおよびiSCSIに対する新しい非同期入出力機能の導入。ストレージ関連のパフォーマンスが大幅に改善されている。特に1GBを超える高速LANでの性能が改善。
* 仮想マシンのダイレクト共有機能の実現。仮想H/W、仮想ディスク、スナップショット、保存状況、共有フォルダなど各種情報を保持するようになったことで、従来よりも仮想マシンデータの共有性が向上。サスペンドやスナップショット状態の仮想マシンデータをほかのマシンに転送してそのまま利用できるようになった。
* PCI Express、Intel HDオーディオ、NICオフロードなど最新のH/W機能を実装。
* NATにポートフォワーディングの機能を追加。
* VirtualBoxを完全にOSS化。OSSではない部分に関してはエクステンションとして提供するように変更。最初にOracleから提供されるエクステンションはハイスピードUSB 2.0、リモートディスプレー、ネットワークブートに対応したエクステンション。
* Open Virtualization Formatのサポート
* 32ビットホストでより大規模な仮想環境が運用可能になった。
管理UIの改善やディスク性能の向上、仮想マシンのトランスポート性の向上などさまざまな改善が実施されている。利用する面で興味深いのはNATにポートフォワーディングの機能が追加されたところ。ブリッジネットワーク機能を使えば仮想OSを独立して扱うことができたが、これにはゲストOSの分だけIPが必要。割り当てられるIPが一つしか許可されないといった環境でブリッジネットワーキングを利用するには、ホストOSで別途機能を併用するなどしてIP制限を回避する必要がありそれ相応のスキルが必要だった。今回NATにポートフォワーディングの機能が追加されたことで、IPが一つしか使えないような環境でも便利に活用できるようになった。
またVirtualBox 4.0からはOSS版、商用版というエディションは廃止され、すべてOSS版に統一されている。これまで商用版で提供されてきた機能はエクステンションとして提供されることになる。

HTC、新Androidスマートフォン「HTC Sensation」発表

台湾のHTCは4月12日、Android搭載の新しいスマートフォン「HTC Sensation」を発表した。
　HTC Sensationは4.3インチタッチスクリーン、1.2GHzのデュアルコアQUALCOMM Snapdragonプロセッサ、HD動画を撮影できる800万画素カメラを搭載。仕様にはAndroidのバージョンは記されていないが、Gingerbreadと報じられている。筐体はアルミのユニボディ。HTC独自のUI[HTC Sense」の最新版を備え、HTCの動画サービス「HTC Watch」に対応する。
　HTC Sensationは英Vodafoneを皮切りに欧州で発売する。第2四半期にはアジアでも発売する予定だ。また4Gネットワークで動作する「HTC Sensation 4G」を今夏、米T-Mobileから提供する。

第一印象

・人間は0.5秒以内に注意を集中し、仲間かライバルかを判断する

・人の印象は外見てほぼ決まってしまう（初頭効果）

・人は最初に入手した情報によって以後の判断修正をしなくなる

　メラピアンの法則

　・・話の内容は7%

　・・声が38%

　・・外見55%

仮想化のメリット

リソースの有効活用

「1 台の物理サーバに 1 つのオペレーティングシステム」 という従来のモデルを排除して、1 台の物理サーバ上で複数の仮想マシンを構成し、各仮想マシン上で独立したOSを実行することができます。これにより余剰リソースを各仮想マシン (OS) へ割り当て、共有することが可能となり、結果として物理サーバの台数を削減すると同時にリソースの有効活用が実現できます。

管理性の向上

仮想化を活用し物理サーバを削減することで、監視・メンテナンスなどそれに伴う管理コストも削減することができます。また、仮想環境を一元管理する専用のソフトウェアを使用することで更なる管理性の向上が見込めます。

柔軟性の向上

物理サーバと異なり、ハードウェアと OS の間に仮想化レイヤーが存在することにより、OS とハードウェアを切り離して考えることができます。OS は仮想化レイヤーに依存するためハードウェアを選びません。これによりハードウェアの老朽化やリースアップなどで移行が必要な場合もオペレーションを簡素化することができます。

サーバ構築の高速化

従来の物理環境でのサーバ構築はハードウェアの選定から社内申請・承認、納入後にOS・アプリケーションのインストールなど 1 ヶ月〜 2 ヶ月の時間を要するのが一般的でした。 一方、仮想環境では、必要とされるリソースさえ準備できれば数時間程度で仮想マシンの構築は完了するので、迅速な業務展開、サービス展開が可能となります。

バックアップ・リカバリが容易

仮想マシンに関わるデータは、全てファイルとして扱われるためシステムのバックアップを容易に行うことができます。仮想環境では仮想化レイヤーがハードウェアと OS を切り離しているため、ハードウェアに依存することなく仮想マシンのリストアが可能です。

移行が容易

仮想環境では実行中の仮想マシンを停止することなく、仮想化ソフトウェアを導入済みの物理サーバ間で移行することが可能になります。これによりハードウェア保守等の計画的な停止時間を最小限に抑えるとともに、物理サーバに障害が起きた際も容易に仮想マシンを再起動させることができます。

 

仮想化ってなに？

IT インフラの用語で「仮想化」が使用される場合、一般的には CPU・メモリ・ストレージ・ネットワークなどコンピュータを構成するリソースに対して物理的な制約を排除して柔軟に共有や分割できることを指します。
現在普及している x86 コンピュータ ハードウェアは、単一のオペレーティング システムを実行するように設計されたものです。導入時には、オペレーティング システム上で動作するアプリケーションのピーク時を見据えたサイジングを行うため、ピーク時以外の多くの時間帯はコンピューティングリソース（CPU、メモリ、ディスク、ネットワーク）の使用率が低く、遊休リソースとなっている状況が散見されます。仮想化を用い 1 台の物理サーバ上で複数の仮想マシンを実行することで、ピーク時以外の時間帯も平均的に高い使用率を実現することができます。つまり、リソースのムダを排除することができるのです。また、1 台の物理サーバ上に配置されている各仮想マシンでは、異なる種類のオペレーティング システムやアプリケーションを実行することができます。
個々の仮想マシンは、独立した仮想的なハードウェアとして構成されるため、相互に悪影響を及ぼすことはありません。
仮想マシン全体（CPU、メモリ、オペレーティング システム、ネットワーク デバイスを含む）をカプセル化することで、すべての標準的な x86 オペレーティング システム、アプリケーション、およびデバイス ドライバとの完全な互換性を持ち必要なときに必要なリソースにアクセスできます。

LibreOffice 3.3.2リリース、活動資金として約9万ユーロも調達

非営利団体のThe Document Foundationは3月22日、オープンソースのオフィススイート「LibreOffice 3.3.2」を公開した。同時に、前日までに目標額の2倍近くという約9
万ユーロの寄付金が集まったことも報告した。

LibreOfficeは、2010年9月にOpenOffice.orgからフォークしたプロジェクト。OpenOffice.orgの主要開発者らが結成したThe Document Foundationプロジェクトの下で開発が進めている。ライセ
ンスはLGPL v3。openSUSE 11.4ですでに採用されているほか、英Canonicalも4月公開のUbuntu 11.04でOpenOfficeの代わりにLibreOfficeを採用することを発表している。

最新版となる3.3.2は「マイクロリリース」とするバグ修正リリース。1月に公開されたバージョン3.3系の2回目のマイクロリリースとなり、翻訳やセキュリティ関連のバグが改善された。既存ユーザーは一度アンインストールするよう推奨している（3.2.2のRC2をインストールしている場合はダウンロードや再インストールは不要）。

開発チームは同時に、The Document Foundationが進めている基金集め活動についても報告した。前日の21日に第1ラウンドをクローズ、目標5万ユーロの約2倍となる約9万ユーロが5週間で集まっているという。これらの基金はドイツでの団体組織登録を主な目的としたもので、余剰分はインフラコストやドメイン名登録や商標登録など活動に必要な費用、コミュニティ開発の費用にあてるとしている。

最新版はWindows、Mac OS X、Linuxに対応、プロジェクトのWebサイトよりダウンロードできる。次期版はバージョン3.4となり、5月中旬に公開を予定している。

The Document Foundation
http://www.documentfoundation.org/

LibreOfficeダウンロード
http://www.libreoffice.org/

XAMPP for Windows

XAMPP 1.7.4 をリリースいたしました！ 

最新版の特徴:

• Apache 2.2.17
• MySQL 5.5.8
• PHP 5.3.5
• phpMyAdmin 3.3.9
• FileZilla FTP Server 0.9.37
• Tomcat 7.0.3 (with mod_proxy_ajp as connector)

Please visit the  win32 compatibility list.

Windows Vistaをご利用の方へ： Windows VistaではC:\Programfilesのフォルダのパーミッションが限定されております。その為、通常のインストールではインストールが成功しない場合があります。 xampp用のフォルダをCドライブの直下か、C:\userの下にxamppというディレクトリを作成してご利用いただくことをお勧めします。

旧バージョンのXAMPP（"旧" WAMPPも、） Source Forge. から直接ダウンロードできます。

ジェネリック: Java vs C#

2005 年初頭に公開された Java 言語仕様第 3 版 (開発実行環境は 2004 年秋に先立って公開されていた) と 2005 年 6 月に ECMA に承認された C# 言語仕様第 3 版 (開発実行環境は 2005 年末に公開された) では、共にジェネリック (ジェネリックス、ジェネリクス、総称: generics) という新しい概念が導入され、文法もそれに伴って変化している。 また 2010 年に出荷された C# 4.0 ではジェネリックに関する機能の拡張が行われている。

Java と C# はどちらも静的な型付けを行うオブジェクト指向プログラミング言語であり、C 言語を基にした似たような文法をしている。 この記事では、Java 言語のジェネリックと C# 言語のジェネリックを、その機能や文法の違いを中心に比較する。

ジェネリックな型

ジェネリックな型は、どちらの言語でも山型の括弧を使って表される。ジェネリックなクラスを宣言する構文は、次のようになる。

Java

public class ClassName<T> { }

C#

public class ClassName<T> { }

この例では、山型括弧の中にある T が型パラメータ (type parameter) である。(注: type parameter は型引数とも訳し得るが、type argument との混同を避けるために、この記事では型引数という日本語は使用しない。) どちらの言語も、ClassName<T,U> のようにコンマで区切ることで、複数の型パラメータを指定することが可能である。

Java では、同じ名前で型パラメータの有無のみが異なる二つのクラスを同時に宣言することはできない。 例えば、MyClass と MyClass<T> を同じパッケージの中に共存させることはできない。 同じ名前で型パラメータの数だけが異なる場合も不可である。

これに対し、C# では同じ名前でも型パラメータの数が異なるならば全く別の型として扱われる。 ゆえに、MyClass と MyClass<T> とMyClass<T,U> は同じ名前空間内に共存できる。

どちらの言語も、ジェネリックなクラスのほかにジェネリックなインタフェースを宣言できる。 また C# ではジェネリックなデリゲートおよびジェネリックな構造体も宣言できる。

型パラメータの命名規則

型パラメータの一般的な命名規則を比較してみよう。

Java では、型パラメータの名前は原則として常に一文字の大文字である。例えば、List<E> や Map<K,V> のように。 型パラメータが表しているものの頭文字が型パラメータの名前になる。例えば Map<K,V> の一つ目の型パラメータはマップのキー (key) を表し、二つ目はマップの値(value) を表しているので、それぞれの頭文字 k と v が型パラメータの名前になっている。

C# では、型パラメータの名前は常に T で始まる。型パラメータが一つだけのときは、単に T 一文字がそのまま型パラメータの名前になることが多い。 複数の型パラメータがあるときは、例えば Dictionary<TKey,TValue> のように T を接頭辞として使う。

ジェネリックなクラスの親クラス

どちらの言語も、型パラメータを親クラスにすることはできない。つまり、例えば次のようなことはできない。

Java

public class MyClass<T> extends T { }

C#

public class MyClass<T> : T { }

Java では、java.lang.Throwable の子孫クラスをジェネリックにすることはできない。

C# では、System.Attribute の子孫クラスをジェネリックにすることはできない。

ジェネリックなクラスのインスタンス化

ジェネリックなクラスをインスタンス化するには、型パラメータに当てはまる実際の型を指定して コンストラクタを呼び出さねばならない。例えば次のようになる。

Java

new MyClass<String>()

C#

new MyClass<string>()

上の例で、山型括弧の中にある String/string がパラメータの実際の型すなわち型アーギュメント (type argument) である。(注: type argumentは型引数とも訳し得るが、type parameter との混同を避けるために、この記事では型引数という日本語は使用しない。)

Java では、new MyClass() のように型アーギュメントを指定せずに インスタンス化することも出来る。これにより、ジェネリックなクラスをジェネリックでないクラスとして扱うことが出来る。 ただし、これはジェネリックが導入される前のコードがそのままコンパイルできるようにするための処置であって、 これから書くコードには型アーギュメントを省略せずに書くべきである。

ジェネリックなメソッド

ジェネリックなメソッドの宣言は、例えば次のようになる。型パラメータの位置の違いに注意。

Java

public <T> void method(T t) { }

C#

public void Method<T>(T t) { }

Java では、型パラメータの有無や数はシグネチャに含まれない。よって、次のようなメソッドのオーバーロードはできない。

public class MyClass {

    public void method() { }

    public <T> void method() { }

    public <T,U> void method() { }

}

C# では、型パラメータの有無や数はシグネチャに含まれる。よって、次のようなメソッドのオーバーロードが可能。

public class MyClass {

    public void Method() { }

    public void Method<T>() { }

    public void Method<T1,T2>() { }

}

ジェネリックなメソッドを型アーギュメントを明示して呼び出すのは例えば次のようになる。

Java

String s = obj.<String>get();

C#

string s = obj.Get<string>();

この例では、山型の括弧の中にある String/string が型アーギュメントである。

Java では、型アーギュメントを表す山型括弧の前に必ずピリオドがなければならない。例えば、this.<String>get(); は問題ないが単に<String>get(); と書くのは不可。これは、< 記号が型アーギュメントを表す括弧なのか不等号演算子なのかを明確に区別するための構文上の制約であると思われる。 もしこの制約がない場合、例えば式 F((G)<A,B>H(7)) は次の二通りに解釈できてしまう:

§                                 G と A の比較結果と、B と H(7) の比較結果の二つを引数としてメソッド F を呼び出す

§                                 A と B の二つの型アーギュメントでメソッド H を呼び出し、 その結果を G にキャストしてメソッド F を呼び出す

C# では型アーギュメントを書く位置が異なるため、Java とは少し事情が異なる。例えば式 F(G<A,B>(7)) は次の二通りに解釈できる:

§                                 G と A の比較結果と、B と 7 の比較結果の二つを引数としてメソッド F を呼び出す

§                                 A と B の二つの型アーギュメントでメソッド G を呼び出し、 その結果を引数としてメソッド F を呼び出す

C# では、このような場合には後者の解釈が採用される。

型アーギュメントの推論

多くの場合、メソッドの型アーギュメントは省略できる。というのも、コンパイラが型アーギュメントを推論するからだ。

型アーギュメントの推論は、メソッドの引数の型に基づいて行われる。Java と C# とでは推論の方法が異なるが、 非常に複雑なため (特に Java) ここでは取上げない。

Java では、引数の型から型アーギュメントが推論できなかった場合、 メソッドの戻り値の代入先の変数の型によっても推論が行われる。例えば次の例では型アーギュメントとして String が推論される。

class MyClass {

    <T> T getNull() {

        return null;

    }

    public static void main(String[] args) {

        String s = getNull();

    }

}

C# では、代入式におけるこのような推論は行われない。

ジェネリックなコンストラクタ

Java では、ジェネリックなコンストラクタを宣言できる。例えば以下のようになる。

class MyClass {

    <T> MyClass() {

    }

    public static void main(String[] args) {

        new <String>MyClass();

    }

}

この例では、String を型アーギュメントとしてジェネリックなコンストラクタを呼び出している。 なお、ジェネリックなコンストラクタは、ジェネリックなクラスのコンストラクタとは独立した概念であることに注意すべし。 上の例では、コンストラクタがジェネリックなのであってクラスはジェネリックではない。 以下のように、ジェネリックなクラスにジェネリックなコンストラクタを宣言することも出来る。

class MyClass<T> {

    <U> MyClass() {

    }

    public static void main(String[] args) {

        new <String>MyClass<Integer>();

    }

}

この例では、String はコンストラクタに対する型アーギュメントであり、Integer はクラスに対する型アーギュメントである。

コンストラクタに対する型アーギュメントは、メソッドの場合と同様に推論が可能なので、省略できる。 クラスに対する型アーギュメントは、もちろん省略できない。

一方、C# ではジェネリックなコンストラクタは宣言できない。

ジェネリックな型の静的メンバ

Java におけるジェネリックな型の静的メンバ

Java では、ジェネリックなクラスはあくまでも一つのクラスとして扱われる。 そのため、ジェネリックなクラスの静的メンバ (フィールド・メソッド) にアクセスする際には、 クラスの型アーギュメントを指定する必要はない (してはいけない)。また、Java ではジェネリックなクラスの中にプログラムの開始点である main メソッドがあってもよい。

class MyClass<T> {

    static Object staticField = new Object();

    public static void main(String[] args) {

        System.out.println(MyClass.staticField);

    }

}

つまり、ジェネリックなクラスの静的なメンバでそのクラスの型パラメータを扱うことはできないということである。

class MyClass<T> {

    static T staticField;  // 不可

}

class MyClass<T> {

    static class MyNestedClass<U extends T> {  // 不可

    }

}

また、ジェネリックなクラスの静的初期化子 (static initializer: C# の静的コンストラクタに相当) は一つのクラスに対して一回だけ実行される。

class MyClass<T> {

    static {

        System.out.println("Initialized.");

        // "Initialized." は一回だけ出力される。

    }

    public static void main(String[] args) {

        new MyClass<Object>();

        new MyClass<String>();

    }

}

C# におけるジェネリックな型の静的メンバ

C# では、ジェネリックな型はそれぞれの型アーギュメントごとに異なる型として扱われる。 例えば、ジェネリックなクラス List<T> からList<object> や List<string> などの具体的なクラス (閉じた構築型 (closed constructed type)) が構築される。 ジェネリックなクラスの静的メンバは、それぞれの構築された型ごとにそれぞれ存在することになる。 そのため、静的メンバでそのクラスの型パラメータを扱うことが出来る。

class MyClass<T> {

    static T t;

    static object o;

}

上の例では、MyClass<object> の静的フィールド t の型は object であり、MyClass<string> の静的フィールド t の型は string である。もちろん、これらは別々のフィールドである。 また、MyClass<object> の静的フィールド o と MyClass<string> の静的フィールド o も別々のフィールドである。

従って、ジェネリックなクラスの静的メンバにアクセスする際には、 必ずクラスの型アーギュメントを指定して具体的なクラスを特定しなければならない。 型アーギュメントの指定なしで静的メソッドを呼び出すことはできないので、プログラムの開始点である Main メソッドをジェネリックな型の中に置くことはできない。

静的コンストラクタ (Java の静的初期化子に相当) もそれぞれの構築された型ごとにそれぞれ実行される。

class MyClass<T> {

    static MyClass() {

        System.Console.WriteLine("Initialized: {0}", typeof(T));

    }

}

class Program {

    public static void Main() {

        new MyClass<object>();

        new MyClass<string>();

    }

}

このプログラムを実行すると、次の出力が得られる。異なる型アーギュメントごとに静的コンストラクタが実行されていることと、 静的コンストラクタ内で型アーギュメントの Type オブジェクトを typeof 演算子で取得できる点に注意。

Initialized: System.Object

Initialized: System.String

ジェネリックな型のメンバへのアクセス制御

どちらの言語も、ジェネリックな型のメンバへのアクセス制御は、 ジェネリックでない型のメンバへのアクセス制御と同様に扱われる。 型アーギュメントはアクセス制御に影響しない。

型パラメータの制約

型パラメータを宣言する際に制約 (constraint) を加えることによって、型パラメータに型アーギュメントとして当てはめることが出来る型を制限できる。 (Java 言語仕様書では「制約」という言葉を用いず、専ら境界 (bound) と呼んでいる。) どちらの言語も、型パラメータに対して型アーギュメントが継承すべきクラスまたは実装すべきインタフェースを指定できる。

Java では、型パラメータの境界を extends 句によって表す。 C# では、型パラメータの制約を where 句によって表す。

以下の例では、どちらも MyGenericClass クラスの型パラメータ T に対して、T に当てはめられる型アーギュメントが MyClass であるか、MyClass の子孫クラスであることを指定している。

Java

class MyClass { }

class MyGenericClass<T extends MyClass> extends Object { }

C#

class MyClass { }

class MyGenericClass<T> : object where T : MyClass { }

Java でも C# でもクラスの多重継承はできないので 一つの型パラメータに対して複数のクラスの制約をかける事はできないが、複数のインタフェースの制約をかける事は可能である。 また、クラスとインタフェースの両方の制約をかけることもできる (クラスの制約を最初に指定しなければならない)。

Java

class MyClass { }

interface MyInterface1 { }

interface MyInterface2 { }

class MyGenericClass

    <T extends MyClass & MyInterface1 & MyInterface2> { }

// インタフェースの制約でも implements ではなく extends と書く

C#

class MyClass { }

interface MyInterface1 { }

interface MyInterface2 { }

class MyGenericClass<T>

    where T : MyClass, MyInterface1, MyInterface2 { }

また、複数の型パラメータに対して制約をかける場合は以下のようになる。

Java

class MyGenericClass

    <T extends MyClass, U extends T> { }

C#

class MyGenericClass<T, U>

    where T : MyClass

    where U : T { }

ジェネリックなメソッドの型パラメータに対する制約は、以下のように指定する。

Java

<T extends MyClass> T method() { }

C#

T Method<T>() where T : MyClass { }

C# では、型は参照型 (reference type)と値型 (value type)の二つに大別される。C# で型パラメータに一切制約をかけない場合、 型アーギュメントは参照型でも値型でもよい。しかし型アーギュメントを参照型または値型に限定する制約をかけることもできる。

class MyClass1<T> where T : class { }

class MyClass2<T> where T : struct { }

Java では、型は参照型と原始型 (primitive type) の二つに大別される。Java では、型パラメータに一切制約がない場合でも 型アーギュメントに指定できるのは参照型のみであり、int や double などの原始型はそのままでは扱えないので Integer や Double などのラッパークラスを使う必要がある。

Java にはない C# の機能として、型パラメータにコンストラクタに関する制約を加えることが出来る。 これは、型アーギュメントに指定した型が引数なしのパブリックなコンストラクタを持っていることを要求するものである。

void Init<T>(T[] array) where T : new() {

    for (int i = 0; i < array.Length; i++)

        array[i] = new T();

}

ジェネリックな型のローカル変数と変性

List<String> のように、型アーギュメントを具体的に指定した型 (C# では閉じた構築型という) の変数はどちらの言語でも使用できる。

Java

List<String> list = null;

C#

List<string> list = null;

ジェネリックなクラスやメソッドの中では、そのクラスやメソッドの型パラメータを実在する型に見立てて使用できる。

ワイルドカード型アーギュメント

Java では、型アーギュメントにおいて ? 記号をワイルドカードとして使用できる。例えば、以下のような具合である。

List<?> list = new ArrayList<String>();

型アーギュメントとしてワイルドカードを指定すると、任意の型アーギュメントのオブジェクトを受け入れることが出来る。 上の例では、変数 list には ArrayList<Object> も LinkedList<Number> も ArrayList<ArrayList<Object>> も代入できる。これにより、任意の型アーギュメントの List を同じように扱うことが出来る。

ワイルドカードに対しても境界 (つまり制約) を設定することが出来る。ワイルドカードの境界の指定には、 extends のほかに super が使える。これは extends とは逆の意味を持ち、実際の型アーギュメントが 指定した境界と同じであるかそのスーパークラスであることを指定する。

List<? extends Number> list1 = new ArrayList<Integer>();

List<? super Number> list2 = new ArrayList<Object>();

制約として super を用いる例を見てみよう。以下の Java のクラスは、インスタンス変数 list の内容を引数 list2 に追加するメソッド copy を備えている。

class MyClass1<T> {

    List<T> list;

    void copy(List<? super T> list2) {

        for (T t : list)

            list2.add(t);

    }

}

ここで、list と list2 の型アーギュメントは同じである必要はないことに注意する。 list の要素の型が (明示的なキャストなしで) list2 の要素の型に変換可能でさえ あればよいので、list2 の型は List<T> でなくとも List<? super T> でよいのである。これにより、例えば T = Number のとき、copy メソッドに List<Object> 型のリストを渡すことができる。

制約として extends を用いる例も挙げておく。こちらの copy メソッドは引数 list2 の内容をインスタンス変数 list に追加する。

class MyClass2<T> {

    List<T> list;

    void copy(Iterable<? extends T> list2) {

        for (T t : list2)

            list.add(t);

    }

}

インタフェースとデリゲートの変性

C# 4.0 では、インタフェースとデリゲートの型パラメータに対して変性を指定することができるようになった。 例えば、System.Collections.Generic.IEnumerable<T> インタフェースでは、型パラメータ T は out キーワードの指定により共変なパラメータとなっている。

public interface IEnumerable<out T> : IEnumerable { ... }

これにより、型 T から型 U へ暗黙的にキャスト可能ならば、IEnumerable<T> から IEnumerable<U> に暗黙的にキャストできる。

IEnumerable<string> s = new List<string>();

IEnumerable<object> o = s;

また System.IComparable<T> インタフェースでは、型パラメータ T は in キーワードの指定により反変なパラメータとなっている。

public interface IComparable<in T> { ... }

これにより、型 T から型 U へ暗黙的にキャスト可能ならば、IComparable<U> から IComparable<T> に暗黙的にキャストできる。

IComparable<object> c = ...;

IComparable<string> s = c;

ただし、型パラメータの変性が使えるのは型アーギュメントが参照型の場合に限られる。 型アーギュメントが値型の場合はデータ構造が異なるので変性は使えない。 また C# 4.0 ではクラスやメソッドの型パラメータに対して変性を指定することはできない。 これはおそらく実行環境の実装上の都合によるものであろう。

型チェックの安全性を保証するため、変性を持つ型パラメータは使用できる場面が限られる。 共変な型パラメータはメソッドの戻り値の型としては使えるが引数の型としては使えない。 反変な型パラメータはメソッドの引数の型としては使えるが戻り値の型としては使えない。 この条件に反する場合はコンパイル時エラーとなる。

この条件は、型パラメータがメソッドの引数にも戻り値にも現れる場合は その型パラメータを共変にも反変にもできないことを意味する。そのため System.Collections.Generic.IList<T> インタフェースの型パラメータ T は共変でも反変でもない。従って、上のワイルドカード型アーギュメントに挙げた MyClass1 クラスの例と同じことを C# 4.0 でそのまま実現することはできない。

class MyClass1<T> {

    IEnumerable<T> list;

    public void Copy(IList<T> list2) {

        foreach (T t in list)

            list2.Add(t);

    }

}

この例では、このクラス自体はコンパイル時エラーにはならないが、IList<T> インタフェースの型アーギュメント T は反変ではないため、MyClass1<T> の型アーギュメントと異なる型アーギュメントの IList<T> のインスタンスを渡すことができない。

MyClass1<string> o = new MyClass1<string>();

IList<object> l = new List<object>();

o.Copy(l);  // 不可

一方で MyClass2 の例は C# 4.0 でも書ける。

class MyClass2<T> {

    IList<T> list;

    public void Copy(IEnumerable<T> list2) {

        foreach (T t in list2)

            list.Add(t);

    }

}

IEnumerable<T> インタフェースの型パラメータ T は共変な型パラメータなので、MyClass2<T> クラスの型アーギュメント T の子孫クラスの型アーギュメントを持つ IEnumerable<T> のインスタンスを Copy メソッドに渡すことができる。

MyClass2<object> o = new MyClass2<object>();

IEnumerable<string> l = new List<string>();

o.Copy(l);  // OK

ジェネリックな型の配列

ジェネリックな型の配列はどうだろうか。

Java では、型アーギュメントとしてワイルドカードを指定した型の配列のインスタンス化 (例: new List<?>[3]) は可能であるが、 型アーギュメントとして具体的な型を指定した型の配列のインスタンス化 (例: new List<String>[3]) は出来ない。 型アーギュメントの情報を配列のインスタンスに保持できないからである。(詳細は後述)

List[] a1 = new List[3];                  // OK (非推奨)

List[] a2 = new List<?>[3];               // OK (非推奨)

List[] a3 = new List<String>[3];          // エラー

List<?>[] a4 = new List[3];               // OK (非推奨)

List<?>[] a5 = new List<?>[3];            // OK

List<?>[] a6 = new List<String>[3];       // エラー

List<String>[] a7 = new List[3];          // 警告 (非推奨)

List<String>[] a8 = new List<?>[3];       // エラー

List<String>[] a9 = new List<String>[3];  // エラー

List<String>[] a10 = (List<String>[]) new List<?>[3]; // 警告

@SuppressWarnings("unchecked")

List<String>[] a11 = (List<String>[]) new List<?>[3]; // OK

List<String>[] のような具体的な型アーギュメントを指定した配列を用意したいときは、 上の最後の例のようにワイルドカードを使用して配列をインスタンス化した後にキャストしなければならない。 (このとき @SuppressWarnings 注釈を付けないと、警告が出る)

C# ではワイルドカードは使えないので、常に具体的な型アーギュメントを指定する必要がある。

List<string>[] a = new List<string>[3];  // OK

実行時のジェネリック

プログラムが実際に実行されるとき、実行環境はジェネリックな型をどのように扱うのか。

Java のジェネリックは単なる糖衣構文である

Java では、ジェネリックはコンパイル時に型をより厳密に取り扱うための構文でしかない。 すなわち、実行時にはジェネリックに関する特別な処理は特に行われていない。

端的にいえば、Java においてジェネリックとはコンパイラがより厳密な型チェックを行うための糖衣構文 (文法的な置き換え) に過ぎない。例えば、次の二つのメソッドはコンパイルすると全く同一のバイトコードに変換される。 (Sun のコンパイラ javac 1.5.0 の場合)

void method1() {

    List<String> list = new ArrayList<String>();

    list.add("string");

    String string = list.get(0);

}

void method2() {

    List list = new ArrayList();

    list.add("string");

    String string = (String) list.get(0);

}

List<Object> も List<String> も List<Integer> も結局は単なる List として扱われることになる。 ジェネリックによって文法上はリストから文字列オブジェクトを取り出す際に明示的なキャストが不要となったが、 実行時には (ジェネリックによって不要となったはずの) 型のチェックが行われている。

実行時には型アーギュメントに関する情報は一切扱われていないため、 リフレクションにおいて実際のオブジェクトの型アーギュメントを扱うことはできない。 また instanceof 演算子で型アーギュメントを判別することも出来ない。

配列は、new T[10] のように型パラメータを 使用して作成することはできない。(T[]) new Object[10] のようにキャストすることは可能だが、コンパイル時に厳密な型のチェックが行えないため実行時に例外が発生する要因になる。

C# は型アーギュメントの情報を実行時に反映

C# では、ジェネリックはコンパイル時のみならず実行時にも意味を持つ。 型アーギュメントに応じて、List<object> や List<string> や List<int> などのクラスが実行時に動的に作られると考えてもよい。 例えば、型パラメータ T に対して new T[10] で配列を作成する場合でも、実際の T に応じて string の配列や int の配列など異なる型の配列が作成される。

リフレクションでジェネリックな型を扱うときには、型アーギュメントの違いは厳密にチェックされる。 また is 演算子や as 演算子で型アーギュメントを判別したり、型パラメータに対して typeof 演算子を適用して型アーギュメントの Type オブジェクトを取得したり出来る。

Type GetListTypeArgument<T>(object obj) {

    if (obj is List<T>) {

        return typeof(T);

    } else {

        return null;

    }

}

なお、is 演算子・as 演算子では型アーギュメントは常に指定しなければならない。例えば (obj is List<?>) のようなワイルドカードを使用して、オブジェクトが「任意の型アーギュメントの List」であるかを調べることはできない。また try-catch 文でジェネリックなクラスの例外をキャッチする場合も、同様に型アーギュメントを指定しなければならない。

まとめ

静的な型付けを行う言語においてより厳密な型のチェックを行うための手段としては、Java も C# もほぼ十分なジェネリック機能を備えている。しかし両者のジェネリック機能に細かな差異が見られるのは、 ジェネリックによるプログラムをどのように実行するかについて両者が異なる方針を採ったからである。

C# は、ジェネリックの導入による言語仕様の変更と共に実行環境も合わせて変更した。 そのため、コンパイル時だけでなく実行時にもジェネリックの機能を使用できる。

一方の Java は、言語仕様を変更しても実行環境には手を加えなかった。 マイクロソフトは、これを次のように批判している。

Sun Microsystems® では、次のバージョンの Java 言語 (コード ネームは "Tiger") でジェネリクスを追加する予定です。Sun は、Java 仮想マシンの変更を必要としない実装を選択しました。 このため、変更されていない仮想マシン上にジェネリクスを実装するという問題に直面しています。

計画されている Java の実装は、型パラメータや制約も含め、C++ のテンプレートや C# のジェネリクスに似た構文を使用しています。しかし、値型の扱いが参照型と異なるため、変更されていない Java 仮想マシンでは、値型のジェネリクスをサポートすることはできないでしょう。このため、Java のジェネリクスでは、実行効率の向上は得られません。実際 Java コンパイラは、データを返す必要が生じるたびに、 指定された制約から自動的にダウンキャストを挿入するか (制約が宣言されている場合)、Object 型を挿入します (制約が宣言されていない場合)。さらに、Java コンパイラは、コンパイル時に特殊化された型を 1 つ生成し、構築されるすべての型をそれを使ってインスタンス化します。最後に、Java 仮想マシンはジェネリクスをネイティブでサポートしていないため、ジェネリック型のインスタンスの型パラメータを 実行時に確認する手段はなく、リフレクションのその他の利用も大きく制限されます。

実行時にジェネリックの情報を扱えない点で、Java は C# より実行時のパフォーマンスの面でたしかに不利である。

一方 C# では型アーギュメントにワイルドカードを使用できないため、 型アーギュメントの汎用的な扱いが求められる場面では Java よりも実装が困難になることがあるかもしれない。

また、どちらの言語も配列の扱いはほぼ従来どおりであることに注意したい。コレクションモデルとしては、配列は 固定長のリストとして見做すことができ、実際に C# では配列は IList インタフェースを実装している。 しかし文字列の配列をオブジェクトの配列として扱うというような共変性は依然として残っている。 そのため配列における型のチェックはジェネリックなリストほどには厳密でないということになる。

全体としては、両者共に有利な点と不利な点があるが、実際にジェネリックを活用したプログラミングを行う際には、 どちらの言語が優れているかということはほとんど問題にならないと思われる。

関連情報

§                                 A Comparative Study of Language Support for Generic Programming

参考文献

§                                 ECMA-334 3^rd edition, C# Language Specification. 2005.

§                                 James Gosling, Bill Joy, Guy Steele, and Gilad Bracha. The Java Language Specification, Third Edition. 2005.

§                                 Sridharan, Prashant. C# プログラミング言語の将来の機能. Microsoft Corporation, 2003 年 7 月 8 日