わかりきった質問をしたら,わかりきった答えが返ってくるのは当たり前だ。したがって,86パーセントの回答者が,タスクの難易度とスクリプト作成者の専門知識に応じて,システムの管理にGUIとコマンドライン・インタフェースを使い分けられるほうがいいと感じていることは,驚きに値しないだろう。

 Windows PowerShell(前はMonadというコードネームだった)は,こうした要望を満たしてくれる。なぜなら,コマンドラインから作業したり,スクリプトの上にGUIを構築したりすることができるからだ。さらに人々は,Windows管理作業を軽減するツールを待ち望んでいる。98パーセントの回答者がcmd.exeを使用しているのに対して,PowerShellという名前を聞いたことのある人はたったの60.5パーセントだった。それにもかかわらず,Windows環境の自動化を大幅に容易にする,新しいコマンドシェルとスクリプティング言語があるならぜひ学んでみたいと考えている回答者は,なんと94.3パーセントにも上ったのだ。

 PowerShellは,MicrosoftのアーキテクトであるJeffrey Snoverが発明したものだ。Jeffreyは,PowerShell開発へのコミュニティの関与を一貫して支持している。PowerShellがMicrosoft Exchange Server 2007の一部として出荷され,System Center Virtual Machine Managerの一部になると発表されても,Jeffreyは次のように話す。「私たちは,人々が自らの欲しているものを私たちに教えてくれることを望んでいる。不満に思っていることも,私たちに知らせてほしい。私が一番心配しているのは,こちらが期待しているほど人々は不満を持っていないのではないかということだ」。

 Jeffrey,心配する必要はない。我々の読者はPowerShellについて聞きたいことを山のように持っている。彼らはMicrosoftのドキュメントについて不満を述べていたし,PowerShell習得の難易度について懸念を示している(筆者が話を聞いた専門家たちによると,これが一番大きな問題になるだろうということだった)。さらに,読者はもっと多くの事例やサンプル・スクリプトを要求している。

PowerShellとは何なのか?

 PowerShellについてあまりよく知らない読者の方のために,Jeffreyが次のように説明してくれた。「PowerShellはインタラクティブであると同時に,スクリプト記述も可能である。PowerShellを使うと,コマンドライン・インタフェースの上に管理GUIを構築していくことができる。これは,非常に重要なことだ。なぜなら,問題の解決にGUIとコマンドラインのどちらがふさわしいかを決められる柔軟性を,カスタマーに確実に与えることができるからだ。さらにこれによって,これら二つの異なる世界の間の完全な整合性が保証される」。

 読者は,専門知識のレベルによって,必要な機能も変わってくると言う。Jeffreyもこの意見に賛成で,次のように話している。「様々なタイプのスクリプト作成者のあらゆる要望に応えられるような一つのツールが欲しい,と私たちは考えていた。PowerShellに,4種類の別個の機能セットがあるのはそのためだ。スクリプト作成の初心者は,タイプをしたり,パラメータを指定したりする必要さえない。$argsを使うだけでいいのだ。習熟度の高いスクリプト作成者なら,引数の入力や指定を行って,本格的なスクリプトを作成できる。システム・プログラマであれば,どのような .NET APIでも利用することが可能だ。PowerShellは,.NET,WMI,ADSI,ADO,XML,コマンドライン,テキストベースのスクリプティング,COMベースのスクリプティングなどありとあらゆるものへの直接アクセスをサポートしている。したがって,カスタマーは一つのツールで,すべての関係者とすべてのスクリプティングを標準化できる」。

 PowerShellの導入を容易にするために,Microsoftには何ができるのだろうか? ある読者は次のように言った。「PowerShellを次のOSリリースに組み込んで,長所を詳細に記したドキュメントを作成すればいいのではないだろうか?」。前にも述べたように,MonadはもともとはOSの一部になって,すべてのものと統合されることになっていた。この計画は,今でも生きているのだろうか? Jeffreyは次のように話した。「最終的には,その計画通りになるだろう。だが今のところ,バージョン1はウェブ・ダウンロードとして出荷されることになっている。バージョン1はWindows XP以上のOSに搭載可能だ。やがて,ネイティブでOSに組み込まれるだろう。以上は今の方針だが,この計画はまだ正式には発表されていない」。

ドキュメントに関して

 ドキュメントに関する話をしよう。ドキュメントが乏しいのでPowerShellをデプロイする気にならないという読者が何人かいた。例えば,ある人は以下のようにコメントした。「Microsoftのドキュメントは,それが何のドキュメントであれ常に不十分だというのが,これまでの伝統だった。彼ら自身のスクリプティング言語に関するドキュメントも含めてだ。彼らは,遂にこの問題を改善したということを証明する必要に迫られるだろう」。

 PowerShellでは,このドキュメント問題の解決に取り組んでいるとJeffreyは言う。「調査で判明した三つのことは,ドキュメント,習得,訓練だ。私たちは,最初からこれらの事柄に対処するつもりでいた。ドキュメントについて最初に考えなくてはいけないのは,必要な事柄を見つけやすいかどうかということだ。私たちの(UNIXのような)「man」スタイルのHelpシステムは包括的だ。そして(カスタマーのフィードバックに対応して),私たちはつい最近,manページを改善すること合意したばかりだ。これまでは,manページを要求すると,レファレンス・マニュアル全体に含まれているすべての情報が返ってきた。これでは,SN比(通信によって得られる有益な情報と不必要な情報の比率)が低い。そこで,1ページだけが返ってくるように変更したのだ。そのページを受け取ったあと,詳細を要求して,数ページ分のドキュメントやすべての情報を得るのである。以前のものと比べると,劇的なほどシンプルになっている。そしてUNIXのmanページと異なり,私たちのmanページはHelpオブジェクトのテキスト版のようなものだ。したがって,これまでと同じように,豊富な検索機能の対象になるHelpオブジェクトを利用することができる」。