連載：C# 4入門 第5回 Office連携でrefキーワード不要 株式会社ピーデー　川俣 晶 2010/11/19
Page1 Page2 Page3

良いOfficeと悪いOffice

　正直に書こう。筆者はいわゆる“Office”と呼ばれるソフトが好きではない。

　これはMicrosoft Officeに限るわけではなく、他社で“Office”と名乗るソフトも含まれる。また、クライアント側で動作するものも、サーバ側で動作するものも、区別していない（だから、かなり典型的な間違いは、「Officeは好きではない」という主張を勝手に「Microsoft Office」のことだと勘違いして、ライバル製品の「XX Office」を勧めようとする態度だ。「Officeは好きではない」という主張は最初からライバル製品を含んでいるのである）。

　一方で、Officeが大好きな人も多い。黙っていると、Wordの文章、Excelのワークシートを何の断りもなく、いきなりメールに添付して送ってくる人も多い。そのような人の中にはおどろくべきことに、特定の1つのソフトに入れ込むあまり、明らかにWord向きと思われる企画書などのさまざまな文書をExcelやPowerPointで作成してしまう人までいるわけだ。

　このような状況下では、どうしても以下のことを考える必要に迫られる。

• Officeとは何か
• Officeはどう使えばいいのか

　まず、ほとんどのケースにおいて“Office”とは「Microsoft Office」である。前置きなしに電子メールに添付されてくるファイルは、ほとんどこれだといってよい。要するに、Microsoft Officeのファイルは実質的にビジネス・シーンのデファクト・スタンダードになっているのである。Microsoft Officeのファイルを開くことができると主張する互換品は多いが、機能を誤用して意図の違う機能で作成したフォーマットまで再現してくれるかはあまり明確でないものも多い。しかし、それも再現してくれないと余計な確認の手間が掛かって困る。その手間を容認しない場合は、結局Microsoft Officeを買わなくてはならなくなる。いくら「頭のいい僕」がカタログを比較してこっちが優れていると結論付けても、そのことに何ら影響されるような選択基準ではない。もちろん、別のソフトを常用して、Microsoft Officeでも意図通りに開くことができると確認して運用するのはありだろうが、手間が余計に掛かることは受け入れねばならない。

　しかし、もしも話がAPI互換にまで及ぶと話はややこしくなる。Microsoft Officeのファイルが読み書きできる程度では十分な互換性とはいえず、もっと細かいレベルにまで話が波及する。手動で操作するのではなく、プログラムで操作するようになると、ますます特定製品から離れられない依存性が発生する。これがMicrosoft Officeのプラットフォーム化である。

　ちなみに、個人的なこれまでの印象からいうと、そこまでの検証を含めて「XX Officeの方が優れている」と勧めてくる人はいない。しかし、文句をいいながらそれでもMicrosoft Officeを使い続けている人ならいる。

　さて、問題はこの先だ。

　プラットフォーム化したMicrosoft Officeと、どう向き合うべきなのだろうか？

　まず、何もかもOfficeあるいはOffice内の1ソフトで済ませるような方法論はあまり好ましいとはいえない。ソフトにはそれぞれ守備範囲があり、文字主体ならWordを使うべきだし、計算主体ならExcelの方がよい。Excelで報告書が書けるからといって、それが最善というわけではない。レイアウトにこだわるなら、むしろWordよりDTPソフトの方がよい（実際に筆者はInDesignをWordとは別に使う。マイクロソフトにもPublisherというソフトがある）。

　ならばどう使うのが最善なのか。

　例えば、報告書のひな形文書を作っておき、C#のプログラムで計算した結果をその文書に挿入して、Word文書添付として電子メールで上司に転送しつつ、送付用に印刷させる……といった手順は簡単に自動化できる。毎月毎月、何年間もそれが続くのなら、それはコードを書いて自動化してもよいのではないか……と思う。そしてもちろん、C#に慣れていればC#で書いてもよいのではないか……と思う。

　かつてOfficeに内蔵されているスクリプト言語はソフトごとに別物であった、しかし、1990年代前半のVisual Basicブーム以降、これは「VBA（Visual Basic for Applications）」というVisual Basicとは似て非なる言語に収束された。だが、C#プログラマーから見て、さまざまな常識が違いすぎるVisual Basic系のプログラミング言語は使いにくいかもしれない。かといって、これまでC#から扱うには無駄が多すぎた。

　しかし、いよいよC# 4からはその無駄もカットできるようになった。C#プログラマーもMicrosoft Officeを「準」標準ライブラリとして扱い、それを使いこなすプログラムを作成してよいのではないだろうか。どのみち、Microsoft Officeのファイルを送り付けてくる相手に対応するために、Microsoft Officeを買ってインストールせざるを得ないなら、少しはそれも活用しようではないか。VBAプログラマーにとっては常識であろうが、C# 4時代とはC#プログラマーがそれを語れるようになった画期的な時代なのである。

まとめ

　今回のまとめ。

• 意味のないrefキーワードを要求するCOMオブジェクト、特にOfficeコンポーネントの呼び出しが短くなる
• 省略時の引数も大幅に減らせる
• 参照渡しのために用意した変数も減らせる
• 引数に名前を付ければ、中間の引数をスキップして記述できる

　C# 4の特徴の1つは、動的な機能が拡張されたことだ。それは、決して目新しい機能ではない。従来のリフレクションでも実現できる機能ばかりだが、言語が支援してくれるようになり、ソース・コードを短くすることができるようになった。その短さを支える主要な技術こそが「新しい動的機能」というわけである。

　実は、動的言語の素晴らしさに追従しているというよりも、このような使い方でこそ、動的の価値が生きるような気がする。つまり異種環境との相互運用である。そのように考えると「強い型付け言語」であるC#の軸足は何らぶれておらず、別に「弱い型付け言語」に生まれ変わった、わけではなさそうだ。というわけで、今日も筆者はdynamic型に無縁なコードを書くが、Office連携のような特殊な機能に限ってはdynamic型の出番も多そうである。

INDEX
	C# 4入門
	第5回 Office連携でrefキーワード不要
	1．Wordの悪夢／なぜこんなことに？
	2．refキーワードの省略と引数の省略／dynamic型の価値／名前付きの引数
	3．良いOfficeと悪いOffice／まとめ

　

「C# 4入門」

＠ITメールマガジン　新着情報やスタッフのコラムがメールで届きます（無料）