Global Knowledge Japan

Win Win Windows
ホーム > Win Win Windows > 2014年

Win Win Windowsコラム
クラウドでなくなる仕事と増える仕事
執筆:横山哲也

年末も近づいてきました。この時期、気になるのは年賀状でしょう。私の実家は、個人経営の印刷屋だったため、年末は年賀状の印刷で手一杯でした。

メールや各種のSNSなどで、いつでも手軽に連絡が取れるようになり、年賀状の役割は終わったと思う人もいますし、年賀状を書かないと年が終わらないと思う人もいます。年賀状は、図案を選び、場合によっては自筆の絵や写真を使うので、電子メール全盛の今でも注文する人が多いようです。


一方、同じ印刷物でも、全くなくなった需要もあります。それが年度末の挨拶状です。

昔は、人事異動があると、取引業者やお得意様に葉書や手紙を出す習慣がありました。ほぼ定型文ですし、凝ったレイアウトもないので、結構楽な仕事だったようです。

今では、異動の挨拶は完全に電子メールに移行しており、わざわざ葉書を出す人はいません。いわゆる「セルフサービス化」です。


IT業界ではクラウドサービスが登場し、簡単なシステムなら自前で構築できるようになりました。負荷に応じて台数を自動調整する負荷分散可能なWebサイトを構築するには、ざっと数百万円の費用がかかっていたものです。それが、クラウドサービスと使うことで、誰でも数分でできてしまいます。単に作るだけなら10万円でも高すぎるくらいです。

以前、Schoo (スクー) というオンライン授業の場を借りて3回連続講座を実施したことがあります。録画もあるので、良かったらご覧ください。

Microsoft Azure IaaS講座: 5分で作れるサーバーシステム


実際、本当に簡単にできてしまうわけで「ITエンジニアは失業する」ということまで言われています。

しかし、人事異動の案内はなくなっても、年賀状が完全にはなくなっていないように、ITエンジニアが不要になることはありません。

確かに簡単な仕事はなくなるでしょうが、顧客の要望を整理し、目的に合った最適なシステムを提案し、実装するエンジニアはますます重要になります。


グローバルナレッジでは「クラウドコンピューティング概要」というコースで、クラウドコンピューティングの概要と、ビジネスに与えるインパクトについて紹介しています。

また、「Microsoft AzureによるITインフラの拡張」では、実際にMicrosoft Azureを使いながら、負荷分散されたWindows Serverを構築し、社内ネットワークとの接続手順を学習します。


Microsoft Azureの良いところは、PaaS機能(Platform as a Services: アプリケーション実行環境を提供)と、IaaS機能(Infrastructure as a Service: サーバーOSを提供)に加えて、Office 365というアプリケーションサービス(SaaS: Sotware as a Services)を持っていることです。Office 365は社内のActive Directoryに登録されたユーザーと連携する機能があり、比較的簡単にシングルサインオン環境を実現できます(これについては「AD FS を使った Office 365 シングル サインオンの実現」で学習します)。


クラウドサービスとしては、Amazon Web  Services (AWS) が有名ですが、AWSはすぐに使えるアプリケーションサービスを提供されていません(その代わり、プログラマーにとって便利な機能がたくさん提供されています)。

また、Googleはアプリケーション構造が特殊だったり、仮想マシンのサポートが弱かったりします(今後、急速に立ち上がるでしょうが)。


Microsoft Azureは、IaaSとしてはAWSに匹敵し、PaaSとしては使い慣れた.NET環境を提供するほか、SaaSとしてOffice 365との連携を重視しており、クラウドの全領域をカバーしています。

Publicクラウドの比較
▲「クラウドコンピューティング概要」より抜粋
※AWSはIaaSから発展、GoogleとMicrosoft AzureはPaaSからIaaSへと拡大中。


グローバルナレッジでは、AWSだけでなく、Microsoft Azureの教育にますます力を入れていく予定です。簡単なシステムはセルフサービスで利用者に任せ、ITのプロフェッショナルはさらに高度なサービスを提供することで、ビジネス環境をより良いものにしていけるでしょう。


【おまけ】

今年の9月に「The Tokyo Art Book Fair」というイベントに行ってきました。

そこで、なつかしい手動式活版印刷機を見つけました。実家にあったのとほぼ同じ機種です。年賀状や封筒、名刺などは、この機械で1枚ずつ刷っていました。

活字1 活字2


[クラウド][2014年12月 8日配信]

Win Win Windowsコラム
マイクロソフト認定技術者プログラムはどれを取る?
執筆:横山哲也

Windows Serverに搭載されているHyper-V仮想マシン環境では、Linuxが標準でサポートされます。特別なドライバーやツールがなくても、Linuxがフルサポートされます。

Microsoft Azureにも、Linuxマシンのテンプレートがたくさんありますし、Oracleデータベースも使えます。

もはや「マイクロソフト = Windows」とは全く言えない状況です。


こうした流れは、当然マイクロソフト認定技術者プログラム(MCP)にも影響します。

マイクロソフトの技術者認定資格のひとつ「MCSA (マイクロソフト認定ソリューション アソシエイト) : Windows Server 2012の要件は、以下の3科目でした。

現在は、以下のように変更されています。

【必須】以下のすべての試験

【選択】以下のいずれか1試験

70-412: 高度な Windows Server 2012 サービスの構成」は、フェールオーバークラスターなどの高可用性システムの構成が主な内容です。

一方、「70-346: Office 365 の ID と要件の管理」は「Office 365」というクラウドサービス(SaaS: Software as a Service)を、既存のActive Directoryアカウントと統合する内容です。

74-409: Windows Server Hyper-V と System Center によるサーバー仮想化」は、Hyper-VやSystem Center Virtual Machine Managerを使った仮想マシンの管理を扱います。

もちろん「70-462: Microsoft SQL Server 2012 データベースの管理」は、SQL Server 2012データベースの内容です。


「ソリューション」を提供するからには、より高度なIT基盤(70-412)を提案するか、シングルサインオンを使ったアプリケーション環境を提案するか(70-346)、高度な仮想マシン環境を提案するか(74-409)、あるいはSQL Serverデータベースを使ったアプリケーション環境を管理するか(70-462)、いずれかが必要だという判断のようです。


stepup.png
●どの科目を取得すべき?

では、これら4つの選択科目のうち、どれを取得するのがもっとも良いでしょうか。

もし、現在、みなさまの業務がこれら4科目のいずれかにのみ関わっているなら、それを狙うのがおすすめです。

しかし、現実は多くの分野にまたがってお仕事をされていることと思います。その場合は「全部」が答えとなります。これは別に多くの教育コースを受けていただきたいわけではなく(本当は受けていただきたいのですが)、IT技術者に求められるスキルが広がっているからです。


たとえば「医者」という職業を考えてみましょう。ほとんどの医者は自分の専門分野を持っています。しかし、医師免許に専門分野はありませんし、医学部ではすべての内容を学びます。人間の身体の各部分は簡単に取り外したり交換したりできるものではなく、すべてがつながっています。そのため、最低限の知識はあらゆる分野について習得しておく必要があるからです。


現在、コンピュータシステムは社会基盤を支える重要な技術です。コンピュータが停止すれば、銀行は営業できませんし、電気もガスも水道も止まります。

コンピュータシステムに障害が起こった場合、原因を正しく突き止めるには、IT全般について適切な知識を持つ必要があります。

クラウドサービスを使えば「単に作って使う」だけなら誰でも簡単にできます。しかし、可用性の確保や障害対策まで考慮したシステムを作るのは決して簡単ではありません。


MCPに代表される技術者試験は、ある技術に対する最小限の知識を持っていることの証明でしかありません。医者でいえば医師免許を取得した状態です。

ちょっとした風邪なら、医師免許を取り立ての人に診てもらっても心配はないと思うかもしれません。しかし、風邪のようにみえて実はもっと深刻な病気の可能性もあります。そう考えると、やはり臨床経験を積んだ医者に診てもらいたいところです。そして、本当に深刻な病気だったら、きっと専門医にかかるでしょう。


ITの技術者もこれと同じです。最低限の知識は広く学ぶべきです。少しでも関係する分野であれば、ぜひ資格取得にチャレンジしてください。

最低限の資格を取得した上で、経験を積んでシステム全体を俯瞰する力を備えるか、特定の分野の専門家になるか、それが次のステップになります。


今回ご紹介した「MCSA: Windows Server 2012」の各試験に対応したコースをはじめ、MCPと対応するコースの一覧は「MCP試験とコースの対応表」でご紹介しています。

既に、各試験に対応した教育コースも提供されているので、これからのマイクロソフト技術に注目されている方はぜひ資格試験にもチャレンジしてみてください。




[資格取得][2014年11月24日配信]

Win Win Windowsコラム
クラウドは本当に安いのか
執筆:横山哲也

クラウドコンピューティングの採用は、ブームを超えてトレンドになりつつあります。


では、なぜクラウドが注目されているのでしょう。既に多くの解説記事が世の中に溢れていますが、改めて考えてみたいと思います。


クラウドの歴史

クラウドの考え方自体は、実はそれほど新しいものではありません。


コンピュータに関連するすべてのアイデアは1960年代までに出尽くした」と言われます。仮想記憶もサーバー仮想化も1960年代に考案され、1970年代前半には実用化されています。ちょっと調べてみたら、Wikipediaの「ユーティリティコンピューティング」にこんな言葉が見つかりました(2014年11月4日現在)。これは当時の最新技術「TSS(タイムシェアリングシステム)」、つまり1台のコンピュータを多人数で使う仕組みについての記述です。


1961年、ジョン・マッカーシーはマサチューセッツ工科大学の100周年にあたって、次のように述べている。

「私が主張した種類のコンピュータが将来現実となるならば、電話が公共設備となったようにコンピューティングが公共設備となる日が来るかもしれない...コンピュータ・ユーティリティは新たな重要な産業基盤となるかもしれない」


「ユーティリティ」とは、電気やガス、水道、電話などを指します。水道の蛇口をひねれば、必要な時に必要な量だけ水が使えます。渇水期や電力消費のピーク時を除いて、使用料の上限を気にする人は少ないでしょう。スマートフォンの高速通信可能なデータ量の上限ですら、普段から意識している人は少ないでしょう。これは、まさにクラウドの特徴そのものです。


そういえばクラウドの料金体系は、CPU使用時間、割り当てメモリ、ディスク消費量などを個別に計算して合算します。これは、TSSの使用料金体系そのものです。変わったのはディスクやメモリの単位が3桁違うことと、プリンタ出力料金が設定されていないことくらいです。


ちなみに、WebサーバーとWebブラウザの関係もTSS時代のホストと端末の関係に似ています。UNIX系のOSと異なり、メインフレームの端末は端末内で入力フォームを生成し、すべての項目に入力が終わった時点でホストに全データを送信します。


IBMが作ったPCのキーボードは、それ以前のPCやタイプライターで[Return]と読んでいたキーを[Enter]と呼びます。これは「データ入力(enter)」という意味のようです。私が学生時代に使っていた日立製の端末には[送信]と書いてありました。

 

クラウドの価格

「クラウドに対してもっとも期待されることは何か?」というアンケートをとると、必ず上位に来るのが「価格」です。


しかし、実は単純な使い方ではクラウドは「最安値」ではありません。マイクロソフト社が提供しているクラウド「Microsoft Azure」の仮想マシン料金シミュレータによると、最も安い場合で1,300円くらいのようです。実は、この金額は最も安いレンタルサーバーよりも2倍も高額です。クラウドには各社さまざまな割引オプションがあるものの、最安値というわけにはいきません。


クラウドが安いのは「必要な時に必要なだけ使って、使った分だけ支払う」ためです。


多くのサーバーは1日中同じ負荷ではありません。レンタルサーバーの場合は、どれだけCPUに負荷をかけても料金は変わりませんが、クラウドでは負荷の高いときだけ台数を増やし、低いときは減らすことが可能です。図のように能力不足になることもありませんし、余剰分も発生しません。クラウドの負荷
▲サーバー負荷のパターン


IT投資の最適化

インターネットの発達に伴い、多くの人がWebサーバーを利用するようになりました。こうしたシステムは、1日、あるいは季節ごとの負荷変動が大きい特徴があります。


ピーク負荷に合わせてサーバーを調達すると、普段はサーバーが遊んでしまい無駄です。平均負荷に合わせると今度はピーク時の機会損失につながります。


クラウドを利用すれば、実際に使っている負荷に近い形でサーバーを自由に調達できます。この柔軟性がクラウドの本当の利点です。


さらに、高度な負荷分散機能が簡単に作れるのも利点です。クラウドが提供するサーバー能力はサーバー台数によって調整するのが普通ですから、負荷分散が簡単にできないと困ります。


「クラウドを使えば安くなる」というのは正しいのですが、それは細かな調整をした結果です。単にクラウドに切り替えるだけで安くなるとは限りません。


グローバルナレッジでは、クラウドコンピューティングを利用したサーバー構築の研修を定期開催しています。ぜひご検討ください。

  • クラウドコンピューティング概要
    クラウドの基礎概念から、ビジネスへの応用について幅広く扱う講義+デモの教育コースです。デモは、Amazon Web ServicesやMicrosoft Azureなど、複数のサービスを扱うため、クラウドの入門として最適です。具体的なサーバー構築手順は含みませんが、クラウドについて広く学習できます。
  • Microsoft AzureによるITインフラの拡張
    Microsoft Azureを実際に利用して仮想サーバーを構成し、社内システムとの接続方法について学習します。演習の最後では、負荷分散されたWebサーバーを構築します(データベースプログラミングは含みません)。
  • Amazon Web Services
    Amazon Web Servicesの教育コースも扱っています。

[Azure][2014年11月 4日配信]

Win Win Windowsコラム
第53回 [開発スキル再始動特集6] BBQ にてインシデント発生、その時チームは?
執筆:鈴木和久

会社で BBQ (バーベキュー) を主催するチームに参加しています。春秋 2 回開催することもあれば悪天候などが重なり 1 回も開催できなかった年もありましたが、かれこれ 10 年以上継続している恒例行事になっています。同僚だけでなく、その家族も参加するので回を重ねる度に子供達の成長に目を細めたりして、なんだか親戚の集まりみたいなほのぼのとした雰囲気のイベントです。


■ BBQ でプロジェクト管理実践


BBQ は、よくプロジェクト管理系研修の演習課題になります。要求管理(要件管理)、リソース管理、スケジュール管理、リスク管理、インシデント管理など、プロジェクト管理に必要な多くの要素を含む上、業務内容に依存しないテーマなので題材として扱いやすいからでしょう。
最近では、食材や道具の調達から調理、そして後片付けに至るまで一手に引き受けてくださる業者もたくさん存在するので、BBQ のハードルはずいぶん下がりましたが、それでも悪天候への対応など幹事チームがやらなければならないタスクは多いでしょう。
私達の BBQ チーム(ただの有志の集まり) は、外部の BBQ 業者に頼ることなく全てを自前で執り行っており、その分タスクも多いのですがイテレーションを重ねる毎に各タスクのプロセスが洗練されてきたように思います。当初は食材が余ったり足りなかったりしたのですが次第に最適化されてきましたし、レギュラー メニュー(典型的な BBQ 串、ロースト ビーフ、スペアリブ) などのクオリティも向上してきたと思います。BBQ チームのベロシティ(対応力)が試行錯誤の繰り返しによって継続的に強化されてきたたからでしょう。


■ BBQ にてインシデント発生


先日開催した BBQ の目玉は「ソフトクリーム」でした。特別な機材を使用せず、ボウルと泡立て器及びボウルを冷やす氷(塩を加える)で作ります。テレビ番組で作り方を見ただけという「うっすらとした記憶」と、「材料と手順の箇条書きのみの頼りなさげなレシピ」で初挑戦するというリスクが一杯のメニューです。
それなのに当日会場に向かう道すがら、牛乳、生クリームにゼラチンを加えて溶かすための「鍋」と、氷を入れる外側のボウルを忘れた事に気づきました。これでは子供達が楽しみにしているソフトクリームが作れません。「やりたいことをやれない状況」つまり「インシデント」の発生です。
子供達をがっかりさせる訳にはいきません。他の参加者にお願いして急遽、鍋を持参して貰い、さらに会場に近いホームセンターでボウルを買ってきて貰うことで、対応することができました。
今回のインシデントは BBQ チームのメンバーが早期に気づけたので、時間内に対策が打てましたがデザートの時間になってから気づいていたら、ソフトクリームは作れなかったでしょう。


SoftCream.jpgのサムネール画像


■ TFS (Team Foundation Server) におけるインシデント管理


TFS では、プロジェクトで管理対象となるタスク、テスト ケース、バグ、リスクなどを、「作業項目」と呼ばれる要素として個別にデータベースで管理します。一度登録された作業項目は、チーム メンバーによって共有され、然るべき対処が行われた後、その対応の履歴が継続的に記録されます。削除することはできない仕様になってますので、完全に対応が完了するかキャンセルされるまでアクティブな状態でデータベースに残り続け進捗管理の対象となります。
第51回 [開発スキル再始動特集4] 世界はそれを探索的テストと呼ぶのです 」で御紹介した、探索的テスト(Exploratory Testing) の結果生成される「バグ作業項目」もその一つです。バグ作業項目は、テスト担当者や運用担当者が発見したバグの状況を障害報告書(チケット) として纏めたものですが、TFS では予期せず発生する例外を、「インシデント作業項目」として TFS のデータベースに自動登録してくれる便利な機能があります。


■ PreEmptive Analytics for TFS CE


PreEmptive Analytics for TFS CE は、アプリケーションで発生した例外レポートを収集し、開発チームの担当者が予め定義した規則としきい値に従って、インシデント作業項目を自動登録します。インシデント作業項目には、発生した例外の種類、スタック トレース、実行時にロードされたすべてのアセンブリ リストなどが含まれます。
例外発生時のインシデント管理を迅速に着手するための「予防的な対策」として利用することができます。PreEmptive Analytics for TFS CE によってユーザーやテスト担当者、運用担当者が認知する前に、いち早く詳細な情報を把握することも可能になりますので、致命的なインシデントになってしまう前に、有効な対策が打てる可能性が高くなります。
また、ソースコードを変更せずに既存のアセンブリ ファイルに後から機能を追加することが出来ますので、テスト環境で再現させることが難しいエラーが本番環境で不定期に発生するような、悩ましい状況でのエラー詳細情報の収集などで大きな効力を発揮します。


要求管理、設計、実装、テスト、運用にいたる全工程を総合的に管理するアプリケーション ライフサイクル マネージメント (ALM) と、チーム開発の活性化に関連する研修として以下をご紹介します。

Visual Studio によるアプリケーション ライフ サイクル管理 ~70-498対応~(MSC0462G)
※演習課題は BBQ ではありません:-)

その他、システム開発系の情報は「Visual Studioによるアプリケーション開発とライフサイクル管理(ALM)」でご紹介しています。ぜひご覧ください。

[.NET Frameworkシステム開発][2014年10月 7日配信]

Win Win Windowsコラム
第52回 [開発スキル再始動特集5].NET Frameworkも進化しています
執筆:大貫 淳子

以前に、コレクションとジェネリックコレクションを紹介しました。
ジェネリックコレクションは.NET Framework2.0からの機能です。
ということで、今回は.NET Frameworkのバージョンの推移について書きます。


■Windows 7では.NET Framework1.0はサポートされません。


2003年に登場した.NET Frameworkは1.0 →1.1 → 2.0 → 3.0 → 3.5 → 4 → 4.5 → 4.5.1とバージョンアップしています。2014年現在の最新は4.5.1です。
.NET Framework の登場はVisual Studioの発売と同じタイミングが多く、バージョンの推移とVisual Studioの関係は以下のようになっています。
winwin1.PNG


.NET Frameworkはその時の最新のバージョンがOSとともにインストールされています。
例えば、Windows 7には. NET Framework 3.5が含まれており、Windows 8.1には.NET Framework4.5.1がインストールされています。
参考).NET Framework のバージョンおよび依存関係(Microsoft社サイト)

.NET Frameworkは複数バージョンの共存が可能です。例えば、1.0、1.1、2.0、3.0、3.5、4を同じPCにインストールすることができます。(4以降は共存できません)

winwin2_2.PNG
(追記:Windows Server 2003、Windows Server 2003(R2) では、.NET Framework 4.5以降はインストールできませんでした。画像を差し替えました。訂正してお詫びします。)


◎(オレンジ)が標準でインストールされているもの、
○(黄色)がインストール可能なもの、×はサポートしていないものです。
4、4.5、および4.5.1はどれか1つしかインストールできないため、アップグレードするとそのバージョンが最新です。

Windows 7やWindows 8は、.NET Framework1.0および1.1はサポートしません。
OSをアップグレードするタイミングで、フレームワークも最新のバージョンに移行する必要がありますね。


■新しい機能がどんどん増えています!


ジェネリックコレクション、LINQ、匿名メソッド、ラムダ式、Async、Await ...などなど、機能拡張され、実現できる事が増えたり、コーディングが簡素化されたり、処理速度が速くなったりしています。

「新しい」ということは「前は無かった」ということです。

つまりその機能が必要なら「前は手作りしていた」ということになります。
「新しい機能」を知らないとこれからも「手作りしていく」ことになります。せっかくの機能を活用しておらず、"モッタイナイ"わけで、二度手間です。

例えば、複数行のデータの中で、3行目ごとにデータを取り出し、加算処理をしたい、といったロジックの場合は、ループや条件の処理を使用するので、10行程度になりますが、ラムダ式という記述を使えば1行で書けます。
クラス作成に必須となるプロパティも自動実装プロパティという機能を使えば、getブロック、setブロック合わせても1行のみです。

.NET Framework 4.5以降では、Async/Awaitという非同期処理のキーワードが増えています。


ボタンをクリックし、非同期で行う何らかの処理(下記の場合は10秒間休止)を呼び出し、戻ってきたら、また別の処理を実行するといったコードを、.NET Framework1.0の機能のみで書くと以下のようになります。呼び出しの処理はThread型のクラスとして定義しています。
public partial class Form1 : Form
private void button1_Click(object sender, EventArgs e)
  {
    this.button1.Enabled = false;
    SubThreadClass st = new SubThreadClass();
    Thread thread = new Thread(st.Run);
    thread.Start();
    thread.Join();
    this.button1.Enabled = true;
  }
}
class SubThreadClass
{
  public void Run()
  {
    Thread.Sleep(10000); // 10秒休止
  }
}

最新の機能で書くとこれだけシンプルです。
private async void button2_Click(object sender, EventArgs e)
{
  this.button2.Enabled = false;
  await Task.Run(() => Thread.Sleep(10000));
  this.button2.Enabled = true;
}

ライブラリーは使ってこその「貯蔵庫」です。
是非、.NET Frameworkの最新のクラスライブラリーを活用してください。

その他、システム開発系の情報は「Visual Studioによるアプリケーション開発とライフサイクル管理(ALM) 」でご紹介しています。ぜひご覧ください。

[.NET Frameworkシステム開発][2014年9月29日配信]

Win Win Windowsコラム
第51回 [開発スキル再始動特集4] 世界はそれを探索的テストと呼ぶのです
執筆:鈴木和久

[第36回 テスト工程を凜として粛々と乗り切るのです] と、前回の [第50回 [開発スキル再始動特集3] そのプログラムのテスト ケース、網羅されてますか?] で、テスト自動化のメリットと課題についてお話してきましたが、今回は自動化できないテストについて取り上げます。


■あらゆる可能性を排除しない


週末の夜に某テレビ局で放映されている「病名推理エンターテインメント番組」を時々見ています。経験豊富な総合診療医が過去に実際に経験した症例中、病名特定の難易度が高かったケースを題材に、3 人の研修医がその診療過程を疑似体験しながら病名特定に挑むという内容です。
問診、触診などの基礎的な診察プロセスに始まり、病因の仮説を立てそれを検証する検査を実施し、その検査結果から次の仮説を組み立てるということを繰り返しながら診療データを積み重ねていくのですが、そのデータ単体ではミスリードしてしまいそうなものも多く含まれます。「診察プロセス中に、あらゆる可能性を排除しないことが結局は近道」であり可能性の大小に関わらず丹念に「点」としてのデータを収集し「線」として繋げていくことが重要だと気づかされます。もちろん、人命が関わることなので、対応のスピードもとても重要です。


■原因不明のエラーは「探索的テスト」で対処


ソフトウェア開発の世界でも「原因不明のエラー」に遭遇することがあります。

原因を特定するために、まずは対象ソフトウェアを実行しエラーの状況を再現させようと試行錯誤するのですが、これが容易ではないケースが少なからずあります。「原因不明のエラー」が発生するのはテスト工程の後期から運用開始後のタイミングであり、その段階のソフトウェアは予め想定されるテスト ケースに基づくテストによって、完成度が高くなっているため簡単にはエラーが発生しないはずだからです。
この厄介なエラー状況を再現するためには、前述の総合診療医のチームと同じ作業が必要になります。エラー原因としての仮説を立てその仮説を検証する新たなテストを実行し、そのテスト結果をもとに新たな仮説を立てることを繰り返しながら核心に迫っていく訳です。ここで行われるテストは、予め準備されたテスト ケースには無い、言わばその場の思い付きのものであるため過去の経験を活かした戦略的な試行錯誤が重要になります。このようなテスト手法は「探索的テスト(Exploratory Testing)」と呼ばれます。


■「チーム」で一丸となって対応するために


Visual Studio と Team Foundation Server を組み合わせれば、探索的テストを効率化することができます。Microsoft テスト マネージャーというツールから探索的テスト セッションを開始すると、テスト ランナーと呼ばれる機能がテスト中にアプリケーションに対して行った GUI 操作の手順を漏らさず記録してくれます。また目的のエラーが再現できた時に、その場で障害発生報告書(チケット) を発行することができます。このチケットは「バグ作業項目」と呼ばれエラーを再現させた操作手順とエラー発生時のイベント ログなどの基礎情報、エラー画面のスクリーン ショットなどがアタッチされます。エラー再現手順を含め、ほとんどの情報が自動的に収集されバグ作業項目にアタッチされますので、作業記録としてのエビデンスの取得漏れを防ぐことができ、後続作業を担当するチーム メンバーの作業迅速化を強力にサポートします。
診療データのすべてが「電子カルテ」に集約され、病因を特定するプロセスに関わる複数の医師だけでなく原因判明後の治療にあたるすべての医師にも共有されるように、「バグ作業項目」は複数の運用担当者、アーキテクト、プログラマーなどのチーム メンバーによってプログラム修正などの対策が完了するまでアクティブな状態で共有されます。


Ticket.jpg


■探索的テスト結果からのテスト ケースの新規作成


「原因不明のエラー」はデータ入出力の微妙なタイミングに起因するものだったり、特定リソースの使用に関して、しきい値を超える状況がトリガーとなって発生するなど様々な理由により発生します。探索的テストセッション中に自動記録されたエラーの再現手順は、新たなテスト ケースのテスト ステップとして再利用することができます。このテスト ケースは障害対策後の確認テストとして使えるだけでなく、想定内のテスト ケースとして次回以降の開発作業で有効活用されることになるでしょう。テスト ランナーには「バグ作業項目」作成と同様に「テスト ケース」を新規作成する機能が含まれますので、バグ作業項目作成後すぐにテスト ケースを作成されると良いでしょう


探索的テストを含む戦略的なテスト方法と、チーム開発の活性化に関連する研修として以下をご紹介します。

その他、システム開発系の情報は「Visual Studioによるアプリケーション開発とライフサイクル管理(ALM) 」でご紹介しています。ぜひご覧ください。

[.NET Frameworkシステム開発][2014年9月23日配信]

Win Win Windowsコラム
第50回 [開発スキル再始動特集3] そのプログラムのテスト ケース、網羅されてますか?
執筆:鈴木 和久

[第36回 テスト工程を凜として粛々と乗り切るのです] で「Visual Studio と Team Foundation Server を使ってテストを自動化しましょう!」という記事を書きました。テストの自動化によって、バグの修正や新機能追加後の回帰テストの効率化と、プログラムの保守性を高めるためのリファクタリング促進という効果が望めますよ!というお話でした。


今回は、自動テスト コードのその他のメリットについてご紹介します。


■他者が開発したソフトウェアの担当を引き継ぐとしたら...


例えばソフトウェア開発を外部委託したケースを考えてみましょう。あるいは、もう少し身近なケースとして、同僚が開発したソフトウェアの担当を引き継ぐケースでも構いません。どちらの場合も、既に単体テスト済のソフトウェア コードが存在すると仮定します。

あなたがそのソフトウェアの結合テスト以降を担当することになった場合、どこから手を付けますか?

正攻法だと基本設計書や詳細設計書に目を通し、次にソース コードを解析することになりますよね?
また単体テスト内容とテスト結果を知りたければ、「テスト仕様書」等のドキュメントと、「エビデンス」と呼ばれるテスト実施時のスクリーン ショットやデータベース ダンプなどの膨大な作業記録を丹念に解析するになるでしょう。う~ん、想像するだけで気の重い作業です。もしかしたら「このコード、本当に単体テストしたの?」という深刻な状況にぶち当たるかもしれません。でも結合テスト以降に発生する問題を、あなたが解決しないといけないとしたら、避けては通れない作業ですよね。


■自動テスト コードはドキュメントの役割も担う


もし自動化されたテスト コード(テスト ドライバ) も一緒に作成されていればどうでしょう?テスト自動化のためには、[MS Test] などのテスト フレームワークに準拠したテスト コードの作成が必要ですが、これがあると前述の気の重い状況は一変するかもしれません。
その理由は、自動テスト コードそのものがテスト対象プログラムのドキュメントとして機能するからです。そこにはプログラムが満たすべき外部インターフェイスが具体的な実装として記述されているはずです。テスト対象コードに対する入力データとテスト対象コードの処理結果としての出力を設計書上の「用語」ではなく、そのものずばりのコードとして確認することができます。自動テスト コードに必要最小限の適切なコメントが付与されていれば、きっと展望は明るくなるでしょう。


つまり、あなたはテスト対象コードそのものを解析する前に、自動テスト コードを実行し解析することによって、テスト対象コードの処理内容と完成度を把握することができるということです。あなたがテスト対象コードを引き継ぐ前に、自動テスト コードをレビューしテスト ケースの不足があれば修正を依頼できる可能性もあるでしょう。


■テスト ケース網羅の分析も可能


自動テスト コードによって、機械的にテスト ケースの網羅率を「ある程度」分析することができます。Visual Studio の 「コード カバレッジ分析」機能は、自動テスト実行中にテスト対象コードに含まれるステートメントの、どの部分が実行されたかを追跡します。テスト対象コード内のすべてのステートメントが実行されれば、カバー率 100% になります。自動テスト コードによって実行されなかったステートメントがあれば、コード ブロック単位での未カバー率が数値として表示されます。また、その状態でテスト対象コードをコード エディタで開くと、自動実行されたステートメントと未実行のステートメントが色分けされて表示されますので、不足しているテスト ケースを明確に把握することができます。

CodeCoverage.jpg
Visual Studio の「コード カバレッジ分析」機能はレビュアーによるコード レビューやコーディング インスペクションによる目視でのチェックを補完するものとして期待できるでしょう。


■自動テスト コード作成と保守にかかるコストが課題


自動テスト コードのメリットばかりお話しましたが、自動テスト コード開発には工数がかかります。この工数と、それにより享受できるメリットのトレード オフになると思います。Visual Studio には自動テスト コード作成を支援する機能が豊富に提供されていますので、コストを抑えつつメリットを活かせるようにしましょう。テストの自動化によってテストのノウハウは「人」だけでなく「コード」に蓄積されていきます。

単体テストと GUI アプリケーション テストの自動化および、テストケースの網羅に関連する研修として以下の2コースをご紹介します。

Visual Studio を使用したソフトウェアのテスト ~70-497対応~(MSC0460G)

1日でわかる!ソフトウェアテスト技法(SWC0008G)


その他、システム開発系の情報は「Visual Studioによるアプリケーション開発とライフサイクル管理(ALM) 」でご紹介しています。ぜひご覧ください。

[.NET Frameworkシステム開発][2014年9月17日配信]

Win Win Windowsコラム
第49回 [開発スキル再始動特集2] プログラムコードを洗練させよう ~配列からコレクション、そしてジェネリック~
執筆:大貫 淳子

前回の記事から引き続き、Visual Basic (以下VB)のお話です。

プログラムの外部インターフェイスを変更せずにコードを洗練させることを「リファクタリング」と言います。私は、良いプログラムコードとは、書きやすいコードであり、読みやすいコードであり、そして、保守のしやすいコードであるのがベストだと思います。
メンテナンスのしやすいコードは作った人だけでなく、その後にシステムに携わる人も幸せになります。プログラムは、そのコードを書いた人よりも、その後に運用していく人のほうが多く読む場合も多々ありますから、書きっぱなしではなく、ひと手間かけるとより素敵になるわけです。

今回は、この「コードを洗練させる」時に役立つかもしれないトピックについてご紹介します。

■配列で複数データを格納する

VB にも他の言語同様 「配列」という機能があります。1つの変数名で複数のデータを保存できます。

文字列型の配列を定義
Dim myArray() As String

再定義する場合は Redim、
元の値を保持しつつ、配列のサイズを拡張する場合は、ReDim Preserve というキーワードを使います。

1件目(インデックス0)へAAA、2件目(インデックス1)へBBBを代入
ReDim myArray(0) = "AAA"
ReDim Preserve myArray(1) = "BBB"


複数のデータを増やすときはループなどを用いながらReDim Preserveで追加できます。これはとても便利で、VBならではのキーワードです。C# には用意されていません。

ですが、この記述では、データの追加は末尾にしかできません。

■コレクションを使おう

そこで、配列を「コレクション(Collection)」という機能に置き換えてみます。コレクションはVB6からも使えていました。(が、私は知らずに配列をずっと使っていました)。今回は.NET FrameworkのSystem.Collections という名前空間の ArrayList クラスを使用します。

文字列型のコレクションを定義
Dim myCollection As New System.Collections.ArrayList

データの追加はAddというメソッドで利用可能です。

1件目(インデックス0)へAAA、2件目(インデックス1)へBBBを代入
myCollection.Add("AAA")
myCollection.Add("BBB")


コレクションでは、途中の要素追加が簡単にできる Insert というメソッドも用意されています。

インデックス 0 に 要素「XXX」を挿入し、既存の 2 件がスライドします。

myCollection.Insert(0, "XXX")

同様に途中の要素削除も簡単にできます。
メモリの使用も効率化されており、特に何度もデータを追加する場合には処理速度に差が出ます。私のPCでは5万件のデータの追加で1秒以上の差が出ました。(マシンスペックやメモリ容量で変わります)


■ジェネリックコレクションでさらに進化

ただ、このArrayListは、配列のように格納できるデータの型に制限がかけられないため、文字型や数値型や日付型などの異なるデータ型の値を格納することができます。これはこれで便利な場合もあるのですが、取り出す際に、必ずデータ型を調べて然るべきデータ型に変換しなければなりません。データ型を間違って変換してしまうと、実行時エラーである例外が発生します。
コレクションに格納されるデータ型が一種類で予め決まっているのであれば、データ型を宣言し間違った型のデータ格納をコンパイル エラーとして実行前に検出できた方が安全です。またコレクションからデータを取得する時にデータ型の変換が不要になります。
このような型の安全性と、コレクションの柔軟な使い勝手を両立するために、.NET Framework 2.0 からは 「ジェネリック コレクション」 という機能が追加されました。

前述の ArrayList を ジェネリック コレクションの List(of T) というクラスで置き換えてみます。

Dim myCollection As New System.Collections.Generic.List(Of String) myCollection.Add("AAA")
myCollection.Add("BBB")



ジェネリック コレクション定義時に文字列型(Of String)と指定しておくと、文字以外のデータは格納できません。コンパイル時にコンパイル エラーが発生します。

なお、2次元配列など、配列のほうが使いやすいと思われる場合もありますので、適材適所で使い分けてください。

既存のプログラム、正常に動作しているプログラムに手を入れるのは勇気のいることですが、プログラム言語仕様はバージョンアップし続けています。新しいキーワードや文法が登場するのにはそれなりの理由があり背景があるはずですから、それを取り入れることによって改善することも多くあります。リファクタリングによってメンテナンスがしやすくなったり、機能アップするメリットもあります。
プログラムを変更するとテストも必要になりますね。効率の良いテスト手法が導入されていれば、リファクタリングも気軽に取り組めるはずです。このテスト手法も進化しています。これはまた別の記事で紹介します。

その他、システム開発系の情報は「Visual Studioによるアプリケーション開発とライフサイクル管理(ALM) 」でご紹介しています。ぜひご覧ください。

[.NET Frameworkシステム開発][2014年9月 9日配信]

Win Win Windowsコラム
第48回 [開発スキル再始動特集1] そのシステム、東京オリンピックまで使えますか?使いますか?
執筆:大貫 淳子

こんにちは。
しばらくシステム管理系の話が続きましたので、ここからはシステム開発系の記事を書きたいと思います。どうぞよろしくお願いします。


さて、みなさま、Visual Basic (以下VB)という言語はご存知ですか?
Windows OSとの相性も良く、特にバージョン6.0 (以下VB6.0)は人気があり、多くのシステムに利用されています。

私もVBが大好きです。大文字小文字が区別されないというのは有名なところですが、コード エディターのヒント表示(インテリセンス)がC#よりも速く、入力する記号類も少ない(;や{}は不要です)ので、タイピングそのものの時間がかかりません。また、VBで作成したデスクトップアプリの実例が多いので、「こんなことやりたいな」と思った時に、参考になるサイトやコード例もたくさんあります。「社内のツールを作りたい」という理由で、VBのコースを受講される方も多いのがうなずけます。


VB6.0の開発環境は1998年に発売し、メインストリームサポートは6年後に終了、延長サポート期間も2008年4月8日で終了されています。VB6.0で作ったアプリケーションの動作にはランタイムが必要なのですが、こちらのサポート期間は何度も延長されています。発売当時OSであるWindows 98の時代から、Windows XP → Windows Vista → Windows 7 → Windows 8と何世代ものOSで動作可能です。
それだけシステムが多く使われ、安定稼働し続けていることのあらわれなのだと思います。

【参考】Windows Vista、Windows Server 2008、Windows 7、およびWindows 8に対するVisual Basic 6.0のサポートに関する声明


Windows 8でもランタイムをインストールすれば動作していたVB6.0ですが、いよいよ、Windows 8.1がVBランタイムをサポートする最後のOSになりそうです。
【参考】Bring back Classic Visual Basic, an improved version of VB6


Windows 8.1のサポート期限は2023年1月10日です。
【参考】Windows 8.1 サポート ライフサイクル ポリシー


2020年には東京オリンピックが開催されます。
ちなみに、Windows 7のサポート期限は2020年1月14日なので、東京オリンピックまで持ちません。
【参考】マイクロソフト プロダクト サポート ライフサイクル
システム開発は開発するまでの要件定義や設計と、移行期間、運用期間、稼働後のしばらくのドタバタ(本当はないほうが良いのですが・・・)までの期間を必要とします。
のんびりオリンピックを観戦したいですよね。


ぜひ、早めに、新しい環境により適したシステムに移行しましょう。
VB6.0以降は、VBの文法が活かせるVB.NETがVisual Studioで利用可能です。VB.NETは内部バージョンを持っており、VB6.0を引き継ぎ7.0から始まり、現在11.0まで上がっています。バージョンが上がっただけ、できる事も増えています。


次の記事ではVB6.0 からVB.NETで変化したプログラムコードの紹介をします。


その他、システム開発系の情報は「Visual Studioによるアプリケーション開発とライフサイクル管理(ALM) 」でご紹介しています。ぜひご覧ください。

[.NET Frameworkシステム開発][2014年9月 3日配信]

Win Win Windowsコラム
第47回 [Windows移行特集6]サーバー役割の移行
執筆:横山哲也

今回は、サーバー役割の移行についてのお話です。
 

1日の教育コース「Windows Server環境マイグレーション実践」では、以下の内容を扱っています。
 

  • Active Directoryマイグレーション
  • ユーザーアカウントマイグレーション
  • クライアントマイグレーション
  • サーバーマイグレーション

このうち、もっとも要望が多いのがActive Directoryドメインおよび、ドメインアカウントのマイグレーションです。日本では、Windows Server 2003時代にActive Directoryドメインサービスを全社導入したところが多いようです。
 

しかし、Windows 2000時代に部門単位で試験的に導入された会社もよく聞きます。
 

Activ Directoryは、既存の複数ドメイン(フォレスト)を統合することは出来ず、ただ相互に信頼関係を結べるだけです。複数ドメインの管理は何かと面倒なので、Windows Server 2012の導入を機会に統合したいと考える方が多いようです。
 

ドメインの移行は、当然ユーザーアカウントの移行が伴います。これが「ユーザーマイグレーション」です。
 

これに対して、ユーザーが使っていたクライアント(たとえばWindows XPやWindows 7)の移行「クライアントマイグレーション」はそれほど需要がありません。
 

クライアントPCは、移行ではなく、置き換えが多いからかもしれません。多くの企業で、新しいPCを社内ネットワークにつなぐための標準的な手順が確立しています。クライアント移行は、こうした標準的な手順に従うことで、容易に移行(置き換え)ができます。
 

また、グループポリシーを使っていれば、クライアントPCの構成はほぼ自動化できるので、アプリケーションがインストールされた新しいPCをドメインに参加させれば、大半の作業は完了します。
 

これに対して、サーバー役割の移行は需要の大きなテーマです。
 

一部のサーバーアプリケーションは、複製機能を内蔵しているため、簡単に移行できます。
 

たとえば、Active Directoryドメインサービス役割(ドメインコントローラー)の移行は、以下の手順で行います(第43回 [Windows移行特集2] Active Directory マイグレーション~アップグレード準備~も合わせてお読みください)。
 

  1. 既存ドメインの準備
  2. 新ドメインコントローラーの追加
  3. 旧ドメインコントローラーの削除

DNSサーバーなども同様の手順で可能です。
 

しかし、複製機能を持たない役割は、これほど簡単ではありません。そこで、Windows Serverには「サーバー移行ツール」というものが付属します。
 

サーバー移行ツールは、PowerShellのスクリプトで、基本的な利用手順は以下の通りです。
 

  1. 移行先: 機能の追加とツールの展開
  2. 移行元: ツールのインストール
  3. 双方: ツールの実行


 

サーバーマイグレーションツールの動作

あらかじめ、移行先(最新OS)でツールを展開し、それを移行元(古いOS)にインストールすることで、移行元と移行先の双方でツールが利用可能になります。
 

実際の移行は、ファイル経由の場合とネットワーク経由の場合があります。
 

ファイル経由の場合、ネットワーク回線の速度に依存しないため、安定した転送が可能ですが、一時的なストレージを必要とする欠点があります。
 

ファイル経由マイグレーション

一方、ネットワーク経由の移行は、非常に手軽な反面、回線速度によっては移行に長い時間がかかります。
 

ネットワーク経由マイグレーション
 

一般には、サーバーの置き換えは同一LAN内で行われるため、ネットワーク経由の移行の方が楽だと思われます。
 

Windows環境マイグレーション実践」コースでは、ファイルサーバーの移行の演習があります。ファイル本体はもちろん、アクセス許可リスト(ACL)なども正しく移行できるのは、そのように作ったから当たり前とは言え、なかなか面白いものです。
 

サーバー移行ツールには、ローカルグループの移行機能もあるため、ローカルグループを使ったアクセス許可も問題ありません。
 

ただし、サーバー移行ツールはPowerShellによるコマンドラインツールなので、Windows Server 2008時代にあったFSMT(File Server Migration Tool)のように対話的に構成する機能はありません。
 

FSMTの動作要件はWindows Server 2003からWindows Server 2008 R2ですが、Windows Server 2012でも動作するようです。「Windows環境マイグレーション実践」コースでは扱っていませんが、興味のある方はご自身のリスクで試してみてください。
 

[Windows ServerWindows Server 2008 R2Windows Server 2012][2014年7月17日配信]

Win Win Windowsコラム
第46回 [Windows移行特集5] ユーザー・グループの移行
執筆:多田博一

今回はユーザーとグループの移行についてのお話しです。


ADMT(Active Directory Migration Tool)を使えば、ユーザー、グループとも別ドメインに移行できます。
ユーザーの移行時にユーザーの既存のパスワードを移行する場合、移行元のドメインコントローラーで「パスワードエクスポートサービス」が起動している必要があります。また、ユーザーの移行と同時にグループを移行できます。
グループはグループ単独でも移行できます。この時、メンバーとして保存されているユーザーを同時に移行することもできます。


ユーザーとグループを移行するにあたり、それぞれ考慮すべきことがあります。


■ユーザー移行

新しいActive Directory ドメインへ移行する場合、ユーザーのIDやパスワードといった、セキュリティに関わる情報について注意する必要があります。
Active Directory のユーザーアカウントでは、以下3つのIDが使用されます。これらのIDは移行時にすべて変化します。フォレスト内の別ドメインへ移行する場合、GUIDのみ保持されます。


・DN (Distinguished Name:識別名)
LDAP (Lightweight Directory Access Protocol) で利用される形式です。以下のように表記します。

===============================================
cn=アカウント名, ou=組織単位, dc=ドメインコンポーネント
===============================================


例 (corp.classroom.local ドメインのSales OUにあるユーザーTanaka)
===============================================
cn=Tanaka, ou=Sales, dc=corp, dc=classroom, dc=local
===============================================


DNにはドメイン名から生成される情報を含むため、ドメインが変わるとDNも変わります。


・GUID (Globally Unique IDentifier:グローバル一意識別子)
Active Directory フォレスト内で割り当てられる、ユニークな識別子です。表記例は以下のとおりです。

===============================================
objectGUID=9793061C-81A4-4398-A2B6-AE121CDDA3E7
===============================================


・SID (Security IDentifier:セキュリティ識別子)
 アクセス許可で使用する識別子です。ドメイン内で一意であり、ユーザーやグループなどに割り当てられています。

================================================
S-バージョン-識別子機関-サブ機関-ドメイン情報(3セクション)-相対識別子
================================================



================================================
S-1-5-21-2060924996-2024473076-1546849883-1094
================================================

SIDはファイルやプリンターのアクセス許可で使われます。アクセスする際に、ユーザーのSIDや、ユーザーが所属するグループのSIDと、ファイルやプリンターのACL (アクセス制御リスト)のSIDを比較して、アクセスの可否を決定します。


SIDにはドメイン情報が含まれるため、別ドメインからユーザーを移行するとSIDが新しく割り当てられます。よって、移行したユーザーが以前から利用しているファイルやプリンターといったリソース (資源)を引き続き利用するために、以下のことを考慮します。


・ユーザーおよびグループのSID
移行先ドメインにて新しいSIDが割り当てられますが、移行元ドメインのSIDも保持することで、以前のリソースにアクセスできます。保持されるSIDを「SIDヒストリ」といいます。

SID.png


・ACLに含まれるSID
ユーザーの移行後、既存のACLにあるSIDを、移行後のSIDに変換することで、以前のリソースにアクセスできます。これを「セキュリティ変換」といいます。

SECURITY.png

■グループ移行

グループを移行する場合、一般的にはユーザーアカウントとセキュリティグループはセットで移行する必要があります。ただし、グループのスコープによっては、段階的な移行もできます。


グローバルグループを移行する場合、ユーザーとグローバルグループはセットで移行する必要があります。グローバルグループのメンバーは、グローバルグループと同じドメインのユーザーもしくはグローバルグループだけだからです。


一方、ドメインローカルグループを移行する場合、グローバルグループとドメインローカルグループは別々に移行できます。ドメインローカルグループのメンバーは、信頼関係のある別ドメインでもよいからです。
ただし、ドメインローカルグループは別ドメインから参照できないため、アクセス許可を維持するためにはメンバーサーバーの移行と同時に行います。


ユーザー・グループの移行に関しては、トレーニングコース「Windows環境マイグレーション実践」詳しく解説しています。

[Windows Server 2012][2014年7月 3日配信]

Win Win Windowsコラム
第45回 [Windows移行特集4] Active Directory マイグレーション~ADMT~
執筆:横山哲也

前回に引き続き、Active Directoryについてのお話です。

 

既存のActive Directoryドメイン構造に問題がある場合、構造を変更するよりも新しく作り直した方が早いことが多いようです。
 

既存ドメインから新規ドメインへの移行作業を「マイグレーション」と呼びます。今回は、Active Directoryマイグレーションについて紹介します。

 

単一ドメインと複数ドメイン
 

Widows 2000とともにActive Directoryが登場したとき、マイクロソフトは複数ドメイン環境がもっと一般的に使われると予想していたようです。そのため、Windows 2000の研修教材でも複数ドメイン環境の使用パターンがいくつも紹介されていました。
 

当時はWAN回線の速度が不十分だったため、地域をまたがった単一ドメインを作るのが難しかったという事情もあります。
 

しかし、現在は高速なWAN回線が安価で利用できるため、複数ドメインのメリットは薄れています。一方で、セキュリティ管理など、会社全体で統一したポリシーが要求されるシーンが増えました。ドメインを超えた統一設定は面倒だったり効率が落ちたりするので、できれば避けたいところです。
 

マイクロソフトの公式テキスト(MSU)でも「原則は単一ドメイン」と明記されるようになり、複数ドメイン構築についての記述は減っています。また、シングルドメインをサポートするための機能強化も測られています。
 

Windows Server 2003で追加された「メディアからのインストール(IFM)」は、低速回線で結ばれた拠点にドメインコントローラーを効率よく追加する機能です。Windows Server 2008で追加された「読み取り専用ドメインコントローラー(RODC)」は、低速回線で結ばれた拠点でシングルドメインを効率よく運用するための機能です。
 

もちろん、複数ドメインが必要な場合もありますから、何が何でも単一ドメインというわけではありません。ただ、当初考えられていたよりもシングルドメインの利点が大きいことが分かったということです。
 

そのため、Windows 2000当時に作成した複数ドメイン環境から、単一ドメイン環境に移行したいというニーズはよく聞きます。
 

実は、Windows Server 2003からドメインの付け替えが可能になっています。RENDOMというツールを使うことで、ドメイン名の変更や、フォレストルートを除くドメイン構造の変更が可能です。
 

RENDOM
▲RENDOMで移行可能なパターンの例

 

しかしこのRENDOM、使いこなすのはなかなか面倒です。まず、必要なステップ数が10を超えます。各ステップは、前のステップが完全に終わり、全ドメインコントローラーに設定が伝搬してから次のステップへ進む必要があります。
 

以前、ある雑誌にRENDOMの記事を書いた人が
 

編集部が付けたタイトルは『楽々移行』やけど、どこが『楽々』やねん
 

と自分で突っ込んでました(関西弁なのは、ライターが関西在住なためで、他意はありません)。

 

Active Directory Migration Tool (ADMT)
 

ドメイン構造を変更したい方の大半は、現在よりもシンプルにしたいと考えています。そして、多くの方はシングルドメインに移行しようとしています。
 

シングルドメインへの移行であれば、RENDOMを使って苦労してドメイン構造を変えるより、新しいドメインを作成し、そこに既存の情報を移行した方が簡単です。
 

Active Directory Migration Tool (ADMT) は、既存ドメインから新規ドメインへ移行するための万能ツールです。以前はその他の移行ツールも存在したのですが、現在ではADMTだけ知っていれば十分です。
 

ADMTの主な機能は以下の通りです。

  • ユーザーの移行
  • グループの移行
  • コンピューターの移行 (既存のメンバーのドメインを付け替え)
  • セキュリティの変換 (コンピューターとユーザーやグループ移行後の後始末)
  • サービスアカウントの移行

ユーザーの移行時に、パスワードエクスポートサーバー(PES)を利用することで、パスワードの移行も可能です。
 

一般的には、以下の順序でドメインを移行します。ドメインコントローラーは移行できません。

  1. ユーザーとグループの移行
  2. ユーザーが使っていたクライアントPCの移行
  3. サービスアカウントの移行
  4. メンバーサーバーの移行
  5. セキュリティ構成の後始末

ADMTは、これらの手順すべてをサポートします。
 

実際には、クライアントPCは移行せずに新しく用意することもよくあります。またサービスアカウントも移行せずに、再構成する場合もあります。
 

そのため、グローバルナレッジの教育コース「Windows環境マイグレーション実践」では、クライアント移行についてはそれほど詳しく扱っていません。新しいPCに既存の環境を移行する方法については、別のコースで扱う予定です。
 



 

ADMTのバージョン
 

ADMTの最新バージョンは3.2ですが、3.0から3.2の機能差はなく、インストール先のOSによって使い分けます。Windows Server 2012用のADMTは、現在テスト中だそうです。ADMTは大規模環境で使われることが多く、高い信頼性が求められるので十分なテストが必要だということです。
 

  • 3.0...Windows Server 2003
  • 3.1...Windows Server 2008
  • 3.2...Windows Server 2008 R2

ただし、ADMTをWindows Server 2008 R2以前で動作させれば問題ないので、移行先をWindows Server 2012にすることは可能です。
 

ADMTを使えば、ユーザーやグループは簡単に移行できるのですが、ADMTを利用するにはいくつかの事前設定が必要です。大半は自動的に設定してくれますが、どうしても管理者が別途行わなければならないものもあります。
 

また、グループの移行とユーザーの移行を同時に行うにはどうするか、パスワード移行のための追加設定をどうするのかなど、公開されている文書だけでは分かりにくい部分もあります。
 

Windows環境マイグレーション実践」では、演習を通してこれらの疑問にお答えします。

[Active Directory Windows Server 2012][2014年6月19日配信]

Win Win Windowsコラム
第44回 [Windows移行特集3] Active Directory マイグレーション~アップグレード手順~
執筆:多田博一

Active Directory マイグレーション~アップグレード手順~

前回は、Active Directoryのアップグレードの概要を紹介しました。今回は、具体的な手順を見ていきましょう。


■フォレストとドメインの準備

OSのバージョンアップにともない、Active Directoryも様々な変更が加えられています。そのため、既存ドメインで、新しいOSバージョンのドメインコントローラーを昇格する場合、フォレストとドメインで新しいOSに合わせた準備が必要です。


準備には、「Active Directory 準備ツール(Active Directory Preparation Tool:ADPREP.exe)」を使用します。ADPREPコマンドは、Windows Server のインストールメディアにある、\SUPPORT\ADPREP フォルダーに含まれています。
なお、インストールメディアは、追加するドメインコントローラー(つまり新しいOS)のものを使う点に注意が必要です。
また、Windows Server 2012からADPREPは自動的に実行されるため、明示的に実行する必要がありません。


■新しいドメインコントローラーの昇格

新しいサーバーをドメインコントローラーにすることを、「昇格」といいます。昇格するには、新しいサーバーで、Active Directoryのインストールウィザードを実行し、ドメインコントローラーとして構成します。
Windows Server 2008 R2までは「DCPROMO.exe」でActive Directoryのインストールウィザードを起動できましたが、Windows Server 2012 以降ではエラーになります(応答ファイルを指定した無人インストールはWindows Server 2012でも利用可能です)。


■操作マスターの転送

ドメインコントローラーは、どのサーバーでもActive Directory の情報を変更できる、マルチマスター構成です。ただし、一部の情報はマルチマスターでは制御が困難なため、特定のドメインコントローラーがシングルマスターとなり制御しています。シングルマスターの役割を持つドメインコントローラーを、「操作マスター」と呼び、以下の5つがあります。


 フォレストで1つ
  ・スキーママスター ... Active Directory スキーマを管理
  ・ドメイン名前付けマスター ... ドメインの追加・削除を管理


 各ドメインで1つ
  ・RIDマスター ... ユーザー作成時のID割り当ての管理
  ・PDCエミュレーター ... パスワード更新処理や時刻同期のマスターを担当
  ・インフラストラクチャーマスター ... 他ドメインのメンバー情報を保持


操作マスターの変更を「転送」といいます。操作マスター役割となっている古いドメインコントローラーを降格する場合、役割は他のドメインコントローラーに自動的転送されますが、転送先は指定できません。そのため、あらかじめ管理者が転送しておくべきです。
転送には「Active Directory ユーザーとコンピューター」のようなGUIツールや、「NTDSUTIL」コマンドを使用します。


■グローバルカタログの構成

グローバルカタログとは、フォレスト全体の情報(の一部)をまとめたデータで、フォレスト全体での検索などで使用します。このデータを持つドメインコントローラーを「グローバルカタログサーバー」と呼びます。
グローバルカタログサーバーはドメインコントローラー昇格時に構成できます。また、昇格後は「Active Directory サイトとサービス」などを使用して構成できます。
シングルドメインの場合、すべてのドメインコントローラーをグローバルカタログサーバーとして構成します。


■旧ドメインコントローラーの降格

不要になったドメインコントローラーを、メンバーサーバーにすることを「降格」といいます。古いドメインコントローラーがWindows Server 2003 であれば、「DCPROMO」コマンドを実行すると降格できます。
サーバーそのものを廃棄するのであれば、メンバーサーバーからスタンドアロンサーバーに変更し、ネットワークから切り離します。その後、Active Directory ドメインに残っているコンピューターアカウントを削除します。


以上でアップグレードは完了です。

Active Directory アップグレードの詳細に関しては、トレーニングコース「Windows環境マイグレーション実践」「Active Directory最小構成実践」で解説しています。


また、Windows Server 2012 R2への移行のメリット、Windows Server 2003を使い続けるデメリットは、Microsoft Windows Server 2012 R2対応トレーニングで紹介しています。


次回は移行について紹介します。

[Windows Server 2012][2014年6月10日配信]

Win Win Windowsコラム
第43回 [Windows移行特集2] Active Directory マイグレーション~アップグレード準備~
執筆:多田博一

Active Directory マイグレーションは、大きく分けて「アップグレード」と「移行」の2つの方法があります。今回は、アップグレードと移行の選択基準を紹介しましょう。


アップグレードと移行のどちらを選択するかは、既存のドメイン環境が適切かどうかを基準に考えます。


既存のドメイン構造やアカウント情報が適切な場合は、アップグレードが適切です。アップグレードにより、ドメイン環境を維持しつつ、新しいActive Directoryの機能を利用できます。


一方、既存のドメイン構造を変更したい、あるいはアカウントを新規に作り直したいという場合は、新規にドメインを構築し、既存のドメイン情報をそこへ移行します。


アップグレードと移行には、それぞれリスクがあります。


アップグレードの最大のリスクは、アップグレード後は元のドメインに戻せないことです。アップグレードに失敗した場合は、全ドメインコントローラーのデータベースをバックアップから復元する必要があります。


移行のリスクは、アプリケーション固有の情報が移行できなかったり、不要な情報が追加されたりすることです。そのため、アプリケーションの事前検証や、不要な情報の削除が必要です。


■アップグレードの手順

Active Directory ドメインをアップグレードする手順は、次の図のとおりです。
ActiveDirectory.png

具体的な手順は次回に紹介します。次回をお楽しみに!

Active Directory アップグレードの詳細に関しては、トレーニングコース「Windows環境マイグレーション実践」「Active Directory最小構成実践」で解説しています。


また、Windows Server 2012 R2への移行のメリット、Windows Server 2003を使い続けるデメリットは、Microsoft Windows Server 2012 R2対応トレーニングで紹介しています。

[Windows Server 2012][2014年5月30日配信]

Win Win Windowsコラム
第42回 [Windows移行特集1] Windowsのマイグレーションと言えば
執筆:横山哲也

「マイグレーション」という言葉から、皆さんは何を想像するでしょう。

おそらく、このブログを読んでいる方は「仮想マシンの移動」や、「サーバーハードウェアの変更や統合」「ユーザーアカウントを別ドメインに移動」といったことを思い浮かべるのではないかと思います。

 

英語の「migration」は、ごく一般的な言葉で「人や動物が移動する」ことを意味します。たとえば、アフリカ大陸で見られる「ヌー(Gnu)の大移動」は「The Great Migration」と呼ばれるそうです。UNIXからLinuxに移行することではありません。

ヌー

▲ヌー(大移動のシーズンではありません)

 

ソフトウェアでもハードウェアでも、とにかく「移動」すれば、それは「マイグレーション」です。必要以上に身構えることはありません。

一般に、英語は造語能力が低いため、日常用語を流用して専門用語を作ります。これは直感的に理解しやすい反面、正確に理解しないままその言葉を使ってしまう可能性もあります。逆に、日本語は漢字やカタカナを使って新しい言葉を簡単に作るため、最初は取っつきにくいのですが、正確に理解しやすいという利点があります。


さて、最近Windows業界で話題になっている「マイグレーション」は2つあります。

1つは「ライブマイグレーション」です。Windows Server 2012からはTCP/IP接続さえできていれば、フェールオーバークラスターがなくても、稼働中の仮想マシンを別の物理マシンに移動できます。ライブマイグレーションは、1日の教育コース「Hyper-Vの構成と管理 ~Windows Server 2012 R2対応~」で扱っています。

 

もう1つはWindows Server 2003のサポート期限切れに伴う移行です。

2015年7月のWindows Server 2003のサポート終了まであと400日余りとなりました。Windowsのマイグレーションをスムーズに行うためには、早めに検討を開始しておくことが重要です。

今回から隔週で「Windows移行特集」としてWindowsのマイグレーションについてご紹介します。ぜひ参考にしてください。

 

Windowsのマイグレーションは、以下の4つの内容を含みます。これらの大半を実行するのが、Active Directory移行の万能ツールADMT(Active Directory Migration Tool)です。

  • Active Directoryマイグレーション
    既存のActive Directoryドメインを、Windows Server 2012 R2ドメインにアップデートし、新しい機能を有効にします。
    既存のドメインをアップグレードする場合と、新しいドメインを作って必要な情報を移行する場合があります。一般に「マイグレーション」と言った場合は、新しいドメインを作ってアカウントを移行することを意味しますが、既存ドメインをそのままアップデートする場合もいくつかの注意点があります。
  • ユーザーマイグレーション
    既存のユーザーアカウントを、新しいドメインにパスワードを含めて移動します。この時、ユーザーのパスワードを移行する場合は追加のオプション(PES: パスワードエクスポートサーバー)が必要です。
    新しいドメインに移行するので、Windows 2000当時によく考えずに作ってしまったドメイン構造を、この機会に一新できます。
    また、ユーザーの構成情報(ユーザープロファイル)を、新しいコンピューターに移行する作業も必要です。
  • クライアントマイグレーション
    既存ドメインのメンバーとなっているコンピューターを、新しいドメインに移動します。ドメインの付け替えとセキュリティの再構成が主な作業です。
  • サーバーマイグレーション
    ファイルサーバーなどの役割を、新しいサーバーに複製します。Windows Serverの標準機能である「サーバー移行ツール」を使うと簡単に移行できます。サーバー移行ツールはPowerShellで実装され、簡単に利用できます。



Windows環境マイグレーション実践」では、これらのすべてを扱っています(ただし、ユーザープロファイルの移行についてはあまり重視していません)。

想定している移行元は、Windows Server 2003/2008およびWindows XP/Vistaで、移行先はWindows Server 2008R2/2012/2012 R2およびWindows 7/8ですが、Widows Server 2008 R2からWindows Server 2012 R2への移行でも役に立つでしょう。

[Windows Server 2012][2014年5月20日配信]

Win Win Windowsコラム
第41回 ビッグデータ活用を成功に導く鍵とは ~SQL Server 2014 発売記念フォーラムに参加して~
執筆:今村 靖広

2014年4月18日に開催された「SQL Server 2014 発売記念フォーラム」に参加してきました。

◆SQL Server 2014 発売記念フォーラム
 ビジネス成長を支えるデータ基盤とビッグデータ活用      
 ~早期導入ユーザーと識者が語る SQL Server 2014 の特長とポイント~
  

開催場所は「品川インターシティーホール」で、先着500名とのことでしたが、当日は多くの方が着席できずに「立ち見」で聴講されているという状況でした。
SQL Server 2014の注目度の高さがうかがえます。


最初にMicrosoftのコーポレート バイス プレジデントの沼本健氏による基調講演「ビッグデータ活用を成功に導く鍵」がありました。
講演では、SQL Server がこれまでも大きな成功を納めている製品であることを強調された後に、SQL Server 2014の目玉の機能である「インメモリ機能」の説明がありました。インメモリ機能の実装により、OLTP処理の高速化と結合処理の高速化が実現可能となり、結果として大幅なパフォーマンスの向上が予想されます。講演の中では「OLTP処理のパフォーマンスは最大で30倍になる」という説明がありました。これは、処理がインメモリ(メモリ内)で行われることと、処理中にロック/ラッチが発生しないことによりパフォーマンスの向上が見込まれるためです。


2つ目のキーワードは「ハイブリッドクラウド」です。ここでは、オンプレミス環境とクラウド環境を融合して処理を行うハイブリッドクラウドを使用した災害対策の強化(DR)の説明などがありました。


マイクロソフトは、ビッグデータは一部のデータサイエンティストのみが使用するものではなく、一般社員の誰もが操作できるようにする必要があるという「ビッグデータの民主化」という考え方を提唱しています。本講演では、Excelに埋め込まれたPowerPivotとPower Viewなどを使用したデモも行われました。「データが揃っている」というのが前提ですが、比較的簡単な操作で "見える化" が実現できるように感じました。


また、『統計学が最強の学問である』の著書であり統計家の西内啓氏による「1億総データサイエンティスト時代に向けて」のセッションも行われました。
これがとても面白い内容で、西内氏はデータ分析時に仮説を立ててから課題にアプローチする従来の手法の限界を指摘されていました。「仮説を立てる際には、膨大なデータの中からわずかな要素を選択してデータを見ている場合が多いため、仮説を立てることにより Yes or No の「クローズドクエスチョン」しか出てこなくなり、新たな発見が難しくなる」との説明は特に印象的でした。いままでこのようなやり方しか実施していなかった自分としては、まさに「目から鱗」でした。今後、西内氏の推奨するビジネスの意思決定シーンで役立つデータ分析手法である「リサーチデザイン」を少し勉強してみようと思います。


SQL Server 2014の登場により、分析のためのインフラはほぼ整うでしょう。また、PowerBI/Power Viewのようなツールにより、社員一人ひとりがデータの分析が可能になります。
これからは、データをどのように分析するのかが鍵となるのかもしれません。


SQL Server 2014関連コースは今後提供する予定です。スケジュールが決まり次第Webで告知いたしますのでしばらくお待ちください。
今後、SQL Serverを利用したビッグデータの活用を検討されている方は、まずはSQL Server 2012のコースで基本を押さえておくとよいのではないでしょうか。


■SQL Server 2012関連コース
■ビッグデータ活用とそれを支えるITインフラ

[SQL Server][2014年5月12日配信]

Win Win Windowsコラム
第40回 Windows環境マイグレーション実践
執筆:横山哲也

4月23日(水)15:00-、「守りのWindows Server 2003から、攻めのWindows Server 2012 R2への移行」と題した無料セミナーを行いました。Adobe Connectを使ったオンライン受講も可能なので、遠方から参加していただいた方も大勢いらっしゃいました。

こうした無料セミナーは今後も企画していますので、ぜひグローバルナレッジのWebサイトをチェックしてください。

このセミナーでも紹介したように、「Windows環境マイグレーション実践」という教育コースを始めます。

実は、このコース昨年夏にはほとんど完成していたのですが、その後Windows 8.1が出てきたのでタイミングを見計らっていました。

主な内容は以下の通りです。

  • Active Directoryドメインのアップグレード
  • Active Directoryドメインの移行 (ADMT)
  • サーバー役割の移行 (サーバー移行ツール)
  • クライアントの移行 (USMTなど)


移行元はWindows XPとWindows Server 2003、移行先はWindows 8.1とWindows Server 2012 R2を想定しています。ただし、クライアントの移行は今回あまり重視していません。基本はActive Directoryとサーバー役割の移行です。

昨年作ったテキストに、最新情報を追加していく過程でいくつかのことが分かってきました。

●ADMT

Active Directoryドメインの移行はADMT(Active Directory Migration Tool)を使います。ADMTは、インストール先のOSによって、以下のバージョンが公開されています。

  • ADMT 3.0...Windows Server 2003
  • ADMT 3.1...Windows Server 2008
  • ADMT 3.2...Windows Server 2008 R2

詳しくは「Active Directory 移行ツールのバージョンとサポートされている環境」をご覧ください。

Windows Server 2012 R2用のADMTは現在マイクロソフト内でテスト中のようですが、いまだに出ません。開発者のブログには「エンタープライズツールは、できました、どうぞ、ではだめで、信頼性が重要なため、綿密なテスト中である」という記載がありました。

そこで、本コースの演習では、移行元であるWindows Server 2003上でADMT 3.0を実行しています。

●USMT

クライアントの環境移行の演習はありませんが、ニーズは多いと思われるのでオプション演習として追加することを検討中です。企業でのユーザー環境移行に便利なのがUSMT(User State Migration Tools)ですが、ここにも落とし穴が、

移行元としてWindows XPをサポートしないのです。

マイクロソフトでは、期間限定でWindows XPからWindows 8.1への移行ツールを配布しています(Windows XP から 新しい PC へのデータ引越し)。なぜこんなツールが必要なのかと思っていたら、USMTがサポートしないからのようです。

ちなみに、一般ユーザーがよく使う「Windows 転送ツール」は、移行元としてWindows Vistaもサポートしません。こちらは移行ツールも提供されず、困ったものです。

結局、こういう手順にしました。

  1. 移行元のWindows XP上で旧版のUSMTを実行
  2. 移行先のWindows 8.1上で新版のUSMTを実行

これが一番確実なようです。

ただし、移行できる項目は限られており、XPからの完全移行は難しいようです。ファイルだけコピーして、環境を再構築した方が良さそうです。

●ドメインのアップグレード

Active Directoryドメインのアップグレードについても扱います。ただし、こちらは以前のバージョンとほとんど変わっていません。むしろ、簡単になっているので、あまり重視していません。

おなじみの図を載せておきます。

ドメインのアップグレード
▲ドメインのアップグレード

●Windows Server 2012 R2へ

グローバルナレッジでは、Windows Server 2012 R2の新機能や移行技術を紹介する研修として、以下のコースを用意しています。

その他にも、Windows Server 2012関連コースを各種取りそろえております。Windows Serverの研修を検討されている方はぜひグローバルナレッジにご相談ください。

[Windows Server 2012][2014年4月23日配信]

Win Win Windowsコラム
第39回「Windows Azure」から「Microsoft Azure」に変わる意味
執筆:横山哲也

 日本マイクロソフトのプレスリリースは、「News Center」で紹介されます。
そこにこんな記事がありました。

 Windows AzureからMicrosoft Azureへ

ところがリンク先を見ると、ブログなんですね。

 プレスリリースは企業の正式発表ですが、一般にブログは個人メディアという位置付けです。

 そのブログで正式発表っていうのが、いかにもクラウドという感じです。


 内容は「2014年4月3日より、「Windows Azure」の名称を「Microsoft Azure」に変更」というものです。


 Windows Azureの最初のサービスはMicrosoft .NETのPaaS(Platform as a Service)で、Windowsアプリケーションとの高い互換性が特徴でした。そのため「Windows Azure」という名前は分かりやすく、多くのプログラマーに受け入れられました。


 しかし、現在ではIaaS(Infrastructure as a Service)が提供され、各種Linuxも正式にサポートされています。「ギャラリー」として構成済みのWebサイトにはLinuxベースのものも多くあります。

 たとえば、私はクラウドの研修でよくWordPressのサイト作成のデモをします。数分で、しかも喋りながら1台から10台までのスケールアウト機能を備えたCMS(コンテンツマネージメントシステム)が完成するのは、Webサーバー構築経験のある人には特に大きなインパクトを与えるようです。


 ところが、このWordPress、動作OSはLinuxで、データベースはMySQLです。マイクロソフトの技術は使っていません。

 繰り返しますが、現在のWindows Azureは、Windows以外の環境も正式にサポートされます。
以前は「Linux中心のクラウドならAmazon Web Services、Windows中心ならWindows Azure」と言ってきましたが、それはもう過去の話です。


 しかし「Windows Azure」という名前から、「Windows互換機能しかない」と思い込んでいる人も多く、LinuxプログラマーがWindows Azureを採用するのは心理的障壁が高いようです。

 今回の名称変更により、Windows依存のイメージは払拭されるでしょうか。あるいは、「Microsoft = Windows」と思い込んでいる人が多く、実はあまり変わらないのでしょうか

 そういえば、数年前「マイクロソフトからLinuxディストリビューションを出して欲しい」という声をよく聞きました。Hyper-V仮想マシンのLinuxサポートが十分でなかったことと、マイクロソフトのパッケージソフトウェア開発力に期待したのでしょう。

 Visual StudioでJavaをサポートして欲しいという声もあります。WindowsやIEを悪く言う人でも、Visual Studioの悪口はあまり聞きません。

 実はHyper-VのサポートコードはLinuxカーネルに既に含まれており、多くのLinuxがHyper-Vの仮想マシンとして何の問題もなく動作します。ネットワークカードもビデオカードも、何の設定も不要です。

 ちなみにVMwareも同じ状態だそうで、もはや仮想マシンと物理マシンの区別はないようです。ハードウェア構成のバリエーションが少ない分、仮想マシンの方が楽かもしれません。


 グローバルナレッジでは、Hyper-VとVMwareは同じくらい力を入れています。また、クラウドコンピューティングの研修も取りそろえています。ぜひご検討ください。

 詳しくは、グローバルナレッジネットワーク株式会社のWebサイトから、[仮想化 & クラウド]をご覧ください。

[Azureクラウド][2014年3月30日配信]

Win Win Windowsコラム
第38回 プログラミングしてみませんか?
執筆:大貫淳子

前々回のコラムではALM (Application Lifecycle Management) にまつわるテスト工程の話をしましたが、DevOpsというキーワードもここ数年耳にすることが増えています。
「開発部門(Development)と運用部門(Operation)の垣根を越えてITをビジネスに活かそう」という意味です。
開発のサイクルが短くなり、また改善やリリースの頻度が上がっているため、ツールを利用した情報共有や自動化もDevOpsの重要な要素です。


クラウド化によりフルスタックエンジニア、マルチスタックエンジニアが必要とされてきているように、プログラミングはプログラマだけがわかればよいという時代は終わり、今後は誰もがプログラミングにも携わる可能性があります。


プログラミングそのものもITの進化とともに変化しています。
フレームワークと呼ばれる枠組みにより、イチからすべての処理をコーディングするのではなく、必要な部品を取り入れ組み合わせながら作れるようになりました。開発環境としてのツールも充実しており、キーワードが間違っていたら即座にエラーを知らせてくれたり、キーワードを途中まで打つとヒントを表示してくれたり、テストが自動化できたり...、と至れり尽くせりです。


プログラミングのエッセンスは、様々な分野でも活かせます。
プログラミングでは処理の手順を「アルゴリズム」と呼びますが、これは普段の仕事の中でも、「効率よく、無駄なく、もれなく」作業を行う脳のストレッチとなります。一日に何度も同じ作業があるならば、それを定例化できないか考えてみたり、同じ作業をしている人と情報共有し効率化を図ってみたり...。


プログラムにより作業が効率化できるとしたら、運用部門にもハッピーなことが沢山あるはずです。人事異動のたびにActive Directoryの設定を手作業で行っているとしたら、プログラムを作ればボタン一つで完了するかもしれません。


プログラミングは難しいものではありません。
まずは、使いやすいフレームワークや開発環境に触れてみませんか?

基本から学習したい方はこちらのコースがおすすめです。
C#によるデータ構造とアルゴリズム
Visual Basicによるデータ構造とアルゴリズム

[.NET Frameworkシステム開発][2014年3月19日配信]

Win Win Windowsコラム
第37回 Windows Serverでファイルのアクセス許可を効果的に構成する冴えたやり方
執筆:横山哲也

ファイルやフォルダーに対するアクセス許可は、昔から管理者の悩みの種でした。Windows Serverでは、2種類のグループを効果的に使うことでこの問題を解決します。

グループの効果的な利用手順を「グループ戦略」と呼びます。最も広く使われているグループ戦略は「A-G-DL-P」または「I-G-DL-A」と呼ばれる構成です。ここは試験に出ます。

ファイルのアクセス許可を個人単位で行うことが望ましいと思っている人は少ないと思います。個人的には「こいつだけには見せたくない」とか「同じ部署だけど、仲のいい彼女にだけ見て欲しい」とか、そういうこともあるかもしれませんが、それでは仕事が進みません(その方が仕事が進むケースもある、という反論はこらえてください)。

グループ単位でアクセス許可を設定するとき、たいていの人は部署を基準に考えます。たとえば、商品カタログは営業部が作成するので、営業部に読み書きの許可を与えよう、という具合です。

でも、それが間違いなんです。

ある日、こんな通達が回ってきます。

今まで、カタログは営業部が担当してきたが、単なる製品情報だけでなく、会社としてのメッセージも掲載することにした。
そこで、今後はカタログ編集の許可はマーケティング部門に与える。

ファイルサーバーの管理者は、早速カタログのアクセス許可を変更し始めます。

まず、カタログの元原稿を保存したフォルダー。これは従来通り営業部の人が読み書きできますが、それに加えてマーケティング部も読み書きが必要です。

次に、カタログの版下原稿、これはマーケティング部に読み書きの許可が必要で、営業部や読み取りだけができます。

その他、いろんなフォルダーの設定変更が必要ですが、たいてい漏れてしまいます。

そこで役に立つのが、部署(人)と役割(仕事)を分ける考え方です。

「カタログ制作」という仕事に対して、「カタログ編集」という役割と「カタログ参照」という役割を考えます。従来は、営業部がカタログ編集の役割を持っていたのが、これからはカタログ参照の役割だけになり、マーケティング部がカタログ編集の役割を担当するようになったと考えます。

個々のファイルやフォルダーではなく、役割が変わったと考えれば、役割の割り当てを変えるだけで済むはずです。この考え方がA-G-DL-P戦略です。

A-G-DL-P戦略

AGDLP戦略は、最初にユーザーアカウント(A)をグローバルグループ(G)で分類します。次に、アクセス許可に利用するドメインローカルグループ(DL)を作成し、グローバルグループをドメインローカルグループに配置します。そして、ドメインローカルグループにアクセス許可(P)を割り当てます。

最近は、アカウント(A)の代わりにアイデンティティ(I)、アクセス許可(P)の代わりにアクセス(A)を使い、「I-G-DL-A」とも呼びます。

AGDLP

例を見てみましょう。

図の環境では以下の構成が必要です。

  • ファイルサーバーに商品カタログを保存する共有フォルダーを用意する
  • 商品カタログフォルダーへのアクセス許可は次の表のように設定したい

役割

アクセス許可

対象となる部署

カタログ参照

読み取り

営業部、マーケティング部

カタログ編集

読み取りと書き込み

開発部

これを元に、以下のような構成を行います。

グループの構成

グループ一覧

スコープ

メンバー

G_Sales

グローバル

営業部のユーザー全員

G_Marketing

グローバル

マーケティング部のユーザー全員

G_Develop

グローバル

開発部のユーザー全員

DL_Catalog_Readers

ドメイン
ローカル

G_SalesG_Marketing

DL_Catalog_Editors

ドメイン
ローカル

G_Develop

商品カタログフォルダーのアクセス許可

許可を与えるグループ(役割)

アクセス許可

DL_Catalog_Readers

読み取り

DL_Catalog_Editors

読み取り、書き込み

商品カタログフォルダーに対して、情報システム部のメンバーへの読み取りおよび書き込み許可(編集の権利)を追加する場合、この環境では、以下のようにグループメンバーの構成だけを行えばよく、フォルダーがいくらたくさんあってもアクセス許可を変更する必要はありません。

  • 情報システム部用グローバルグループ(G_IT)を作成し、情報システム部のユーザーをメンバーに追加
  • DL_Catalog_EditorsグループのメンバーにG_ITを追加

このように、ユーザーの分類に利用するグループとアクセス許可に利用するグループ(役割)を分けることにより、アクセス許可の追加や変更をする場合の柔軟性が増します。

アクセス許可の詳細は、教育コース「Windows Server 2008システム管理基礎(前編) ~Windows Server 2008 R2対応~」で紹介しています。Windows Server 2012への対応はもう少しお待ちください。

A-G-DL-P戦略の問題点

このように、柔軟な構成が可能なA-G-DL-P戦略ですが大きな問題があります。それは、概念が非常に理解しにくいということです。特に分類を示すGと、役割を示すDLの区別が難しいようです。

たとえば、マーケティング部員は「参照者(Readers)」という役割を持ち、開発部員は「編集者(Editors)」という役割を持ちます。しかし、普段から部署と役割を分離して考えている人はほとんどいません。組織の役割が変更になり、マーケティング部で編集作業を担当するようになって、初めて問題に気付くわけです。

通常、アクセス許可を設定するのは現場の人ですかが、現場の人はITの専門家ではありませんので、こんな複雑な、それこそMCP試験に出題されるようなレベルのことは知りませんし、本来は知る必要もないはずです。

そこで登場したのがWindows Server 2012から使える「集中型アクセス制御」ですが、これについてはまた別の機会に紹介しましょう。

教育コース「Windows Server 2012 ソリューション アップデート ~MCP 70-417対応~」でも紹介しています。

[Active Directory Windows Server][2014年3月 5日配信]

Win Win Windowsコラム
第36回 テスト工程を凜として粛々と乗り切るのです
執筆:鈴木和久

●要件定義工程はもちろん重要、だけどテスト工程だって...

お客様とシステム開発プロジェクトの失敗要因についてお話させていただく時に、「結局、要件定義が甘いんだよね」という声を数多くいただきます。ウォーターフォールにしろ、アジャイルにしろ、これがもっとも重要なプロセスであることは疑いようがありません。

しかし、開発チームのプログラマーとしてプロジェクトに参加した経験から言うと、一番大変で多くの時間を要し「改善の余地も多いのはテスト工程」だと思います。IPA(独立行政法人情報処理推進機構) の「ソフトウェア開発データ白書」によると開発プロジェクトの全工程のうちテスト工程が占める工数の比率は 3 割~3.5 割程もあることが分かります。実際はもっと多いような気もしませんか?

プロジェクトの失敗要因として真っ先に挙がる上流工程の問題は、会社全体を巻き込む大きなトラブルになりがちなのに対して、テストのトラブルは現場で解決できてしまうので失敗要因として上位にランクされないのかもしれません。

ただし「解決」といっても、文字通り命を削る作業をしてプロジェクトを存続させることもあるようです。これでは本当に「解決」とは言えません。私が新入社員の時に最初に参加したプロジェクトのテスト工程で、重要なサブシステムを担当していた先輩がプレッシャーで休みがちになった時、毎朝先輩の家までお迎えに行くのが私の業務のひとつでした。

テスト工程のプロセスを改善すればチームメンバーも凜として粛々とテスト工程を乗り切れるはずなのです。その結果プロジェクト全体の工数は圧縮され、品質の高いシステムが提供されます。

●可能な限りテストを自動化しましょう

マイクロソフトでは、早くからテスト工程の自動化に取り組み、テスト担当者が直接テストをするのは最小限なんだそうです。どういうことかというと、テスト担当者はテストスクリプトを作成し、テスト自体は夜間に自動実行されているのだとか。

テスト結果は関係者に配布されるとともに、バグのあるモジュールは担当者に通知されます。この時、オリジナルのモジュール作成者に戻されるとは限らないそうです。つまり、他人が作ったコードをデバッグしなければならないわけです。

最初からそれが分かっていれば、コードを書くときにも「いつ、誰が見ても分かるように」ということを心がけるため、結果として保守性が上がるかもしれません。

この話、同僚の横山がMicrosoftの方との雑談の席で聞いた話の伝聞なので、聞き間違いや勘違いがあるかもしれませんが、ありそうな話ではあります。

●テストの自動化にはツールを活用しましょう

マイクロソフトでは、テストを自動化するためにさまざまな内部ツールを持っているという話です。製品として販売されたものとして Microsoft Test(MS Test)なんかもありました。MS Testに付属していた自動実行ツールは、当時のSystems Management Server (SMS、現在のSystem Center Configuration Manager)のアプリケーション配布にも使われていました。

現在、MS Testは、開発ツールであるVisual Studioと、チーム開発をサポートするTeam Foundation Serverの一部になりました。ビジネス層のクラスやデータ層のクラスの単体テストの自動化はもちろん、GUI アプリケーションの手動操作を記録し自動再生するテストコードを生成することもできます。

自動化されたテストは繰り返し実行可能です。これはバグの修正や機能追加後の回帰テスト(デグレード テスト・リグレッション テストとも)を効率化することにつながります。また積極的なリファクタリング(コードの洗練)を行うための勇気(せっかく動いているコードを弄るのには勇気がいりますよね)を与えることになります。

●MCP(マイクロソフト認定技術者プログラム)試験もできました

テスト工程を改善することにより、高品質なアプリケーション早く提供できるようになります。マイクロソフトとしても利点が大きいため、MCP(マイクロソフト認定技術者プログラム)試験もできました(70-497 : Visual Studio 2012 を使用したソフトウェアのテスト)。

この試験に対応した研修が、「Visual Studio を使用したソフトウェアのテスト ~70-497対応~」です。今の所、この試験に対応した研修は他社からは提供されていないようです。

系統だったテストを漏れなく、効率よく実行・管理するために、ぜひ本研修の受講を検討してください。

[システム開発][2014年2月19日配信]

Win Win Windowsコラム
第35回 クラウド時代のエンジニア育成のポイント ~フルスタックだけがスキルパスではない~
執筆:横山哲也

 サーバーの仮想化が進み、物理マシンはネットワークと同様のITインフラとなりつつあります。

 

 サーバーの物理的な要素はネットワークケーブルの物理配線とセットで考える必要があります。そして、仮想マシンの配置は物理配線とは独立して考えます(同じネットワークスイッチにつながっていても、VLANにより分割されているようなものです)。

 

 そのため、データセンターの管理者は、サーバー技術とネットワーク技術をセットで習得する必要があります。

 

 また、クラウドサービスの普及により、アプリケーションエンジニアがサーバー構成を決めたり、チューニングを行ったりしています。

 

 こうした現実を受け、多くの人が「これからのエンジニアは、ネットワーク、サーバー、ストレージ、アプリケーションのすべての分野をカバーするフルスタックエンジニアを目指せ」と言っています。

 

 しかし、人間の能力には限りがあります。あらゆる分野のエキスパートになることは不可能でしょう。また、専門特化したいと考える人も多いはずです。

 

 フルスタックエンジニアを含め、これからのITエンジニアは以下のいずれかの選択を迫られていると言えるでしょう。

 

●フルスタックエンジニア

 仮想マシンの時代では、技術の全領域にわたって高度な知識とスキルを持つエンジニアが必要です。こうしたエンジニアを「フルスタックエンジニア」 と呼びます。

full

 現在最も注目されているフルスタックエンジニアですが、現実問題としてフルスタックを目指すと、個々の分野に対する知識はどうしても浅くなります。

full-real

●マルチスキルエンジニア

 あらゆる領域に長けた「フルスタック」は困難ですが、それでも最低2つの専門領域を持つことを心がけてください。たとえば、クラウドや仮想化ではサーバーとネットワークを一体で管理するため、両方の知識が必要です。このように複数の専門領域を持つエンジニアを、ここでは「マルチスキルエンジニア」と呼びます。

 医学部には専門がなく、内科も外科も区別なく、あらゆる領域を学びます。その上で、開業するときに1つまたは少数の分野を選択するでしょう。

 ITエンジニアも基礎的な内容は全領域をマスターした上で、専門分野を作ることが望ましいと考えられます。

multi

●専門特化型エンジニア

 フルスタックエンジニアやマルチスキルエンジニアは、どうしても1つの領域の知識が浅くなりがちです。複雑な設計や、高度なトラブルシューティングを行うためには、専門特化型のエンジニアも不可欠です。

 専門特化型エンジニアは「この分野では誰にも負けない」という領域を持っています。少数でも、専門特化型エンジニアは高度化するIT環境に不可欠な存在です。

 ただし、昔の「専門特化型エンジニア」と違い、最低限の知識はクリアした上で、2番目や3番目に得意な分野を作るべきです。

 医者の中には、一般的な分類以上に特化した専門分野を持つ人がいますが、あらゆる分野の基礎を学んでいます。

multi
 

●グローバルナレッジネットワークでは

 グローバルナレッジネットワークでは、専門特化型エンジニアのために各種ベンダーの公式教育カリキュラムを提供している他、マルチスキルエンジニアやフルスタックエンジニアのために、複数分野にまたがった教育コースを提供しています。

[クラウド][2014年2月16日配信]

Win Win Windowsコラム
第34回 圧倒的に安ければサービスレベルが落ちても良い?
執筆:横山哲也

クラウドには、自社でサーバーを保持する「プライベートクラウド」と、契約すれば誰でもインターネット経由で使える「パブリッククラウド」があります。

その他、特定多数で利用する「コミュニティクラウド」や、複数の種類のクラウドを組み合わせた「ハイブリッドクラウド」もありますが、ここでは取り上げません。

 

パブリッククラウドにはセキュリティ上のリスクも存在しますが、極めて安価に構築できるのが利点です。条件次第ではかえって高くつくこともありますが、それは相当大規模な環境か、同じIT環境を数年以上使い続ける場合に限られます。

 

2013年頃から、大手企業がパブリッククラウドを採用する例が増えました。ITベンダーからの提案ではなく、利用者からの要求に応えるケースも多いようです。ここで面白いのは、ユーザーの要望のトップが「価格」であり、「セキュリティ」や「安定性」に対する要求を上回る点です。

 

従来のITベンダーは「データの完全性」「24時間連続稼働」「高いサービスレベル」を売り物にしてきました。これらはクラウドでももちろん重要ですが、「圧倒的に安いのであればサービスレベルが落ちても良い」と考えるユーザーも増えています(以前、「安くてよく落ちるシステムが許容されるか?」と問いかけたら「洗剤だったらいいですね」と言われました)。

 

実際にはクラウド上のシステムの稼働率は、「よく管理された社内システム」には劣りますが、「専任の管理者が確保できていない社内システム」よりも高いと言われています。さらに、データからセキュリティ的に大事に部分を抜き取ったり、システム停止が許容できる部分を分離したりすることで、クラウド利用によるリスクを軽減できます。

 

一般に、新しい技術は「これは従来のシステムとは無関係だ」という「無視」の時期から、「欠点が多いので使うべきではない」という「拒否」の段階へ進み、その後にやっと受け入れられます。

 

クラウドの場合も、当初は「一部のユーザーが使う特殊な事例」と無視されていたのが、「ビジネスで使うには問題が多い」という否定的な意見が増えました。そして現在は、その次のステップに進み本格的な利用が急増しています。クラウドには向かないとされていたERPシステムもクラウド上で稼動させる事例もあります。

 

クラウドを正しく理解し、適切な使い方を学ぶため、グローバルナレッジでは「クラウドコンピューティング概要 ~クラウドコンピューティングサービスの定義と利用~」という講習会を用意しています。

 

1日で、クラウドの概念や用語を学習できるほか、最後の章では今後のビジネスや人材育成のヒントになるような内容も含んでいます。この章を評価いただいて、全社研修に採用していただいた例もあります。機会があればぜひご受講ください。


さて、クラウドと言えばインターネットで広く公開されている「パブリッククラウド」を思い浮かべる方が多いと思いますが、社内で専有する「プライベートクラウド」も重要です。


特にセキュリティを重視する場合は、プライベートクラウドが最適です。
プライベートクラウド構築製品で先行しているのは、何と言ってもマイクロソフトでしょう (マイクロソフトはパブリッククラウドとして Windows Azure を提供しており、こちらもトップグループにいます)。


グローバルナレッジでは、Windows Serverを使ったプライベートクラウドについて、以下の2コースを提供しています。

[クラウド][2014年1月28日配信]

Win Win Windowsコラム
第33回 PowerShellの勉強の仕方(その2)
執筆:横山哲也

 前回「PowerShellの勉強の仕方(その1) 」ではPowerShellの概要について紹介しました。

今回は、PowerShellから実行できるコマンドについてさらに詳しく紹介します。


 PowerShellは、PowerShellで記述したスクリプトを実行できます。この時、スクリプトファイルの拡張子はps1(ピー、エス、イチ)です。しかし、BATやVBSといった今までのバッチファイルもPowerShellで実行が可能です。これにより過去の厖大なバッチファイルの資産を無駄にすることなく、PowerShellに移行できます。


 また、PowerShellはWindowsで実行できる外部コマンド(実行可能モジュール)をすべて実行できます。もちろんWindows付属のコマンドに限らず、個人運営のWebサイトからダウンロードした便利コマンドなども同じように実行できます(ウイルスも実行できるので注意してください)。言い換えれば、今まで利用していた外部コマンドはすべてPowerShell上で実行できるのです。疑念を抱いている方は、PowerShellで下記の外部コマンドを実行してみてください。

IPCONFIG /ALL

 コマンドプロンプトで実行したのと同様に、現在のIPアドレスが表示されたはずです(ただしIPCONFIGと/ALLの間にはスペースが必須です)。


 CMD.EXEの内部コマンドを実行することはできませんが(どうしても実行したければ 「CMD /c コマンド」と実行してください)、エイリアス設定を利用することで、コマンドの置き換えをしています。


 エイリアスとは別名、簡単に言えばニックネームのことです。PowerShellでは本来のコマンド名(≒本名)に対して、ニックネームを付けることができます。CMD.EXEの主な内部コマンドには、あらかじめニックネームが付けられています。これにより内部コマンドもPowerShell上で実行できるようになっています。


 試しにPowerShellで下記の内部コマンドを実行してみてください。

DIR

 これもコマンドプロンプトで実行したのと同様に、フォルダやファイルの一覧が表示されたはずです。ただし、エイリアス(ニックネーム)設定されているのは、内部コマンド名のみなので、パラメーターやオプションは本名(ニックネームではない本来のスペル)でなければなりません。参考として先程のコマンドに、サブフォルダのファイルも表示するオプションを付けて実行する例を挙げておきます。なおDIRの本名はGet-ChildItemです。

DIR /s

 DIRはGet-ChildItemのエイリアスですが、PoweShellの Get-ChildItem コマンドレットは /s というオプションを認識しないのでエラーになります。

 Get-ChildItemでは、DIRの /s に相当するオプションは -Recurse なので

DIR -Recurse

または

Get-ChildItem -Recurse

はどちらも成功します。


 コマンド名は従来通りとしても、内部コマンドに対する新しいオプションを憶えねばならないと溜息が出そうですね。でも、ハイフンを入力した後にTABキーを押すことで補完してくれるので、オプションのスペルを正確に憶える必要はありません。


 また、普段利用しているコマンドは、拡張子exeで提供される外部コマンドがほとんどのはずです。(外部コマンドのオプションは、外部コマンドのexeファイル自身が認識するので、従来通りで新たに憶える必要はありません。) そのためコマンドプロンプトで実行していたコマンドは、ほぼすべてPowerShellでも実行ができると言えるのです。


 PowerShellとコマンドプロンプトの機能を比較すると下記のようなイメージになります。

 

PowerShellとコマンドプロンプト

 PowerShellはコマンドプロンプトのコマンドが、ほぼすべて意識することなく利用できます。どうせ開くなら、大は小を兼ねるでPowerShellを開くようにしてはどうでしょう。PowerShellなら、従来のコマンドだけでなく、新しいコマンド(特に追加されたコマンドレットなど)も利用可能なのですから。


【追記】PowerShellとコマンドプロンプトの最大の違いは、実行結果がテキストではなくオブジェクトである点だと考えています。これらは機会があれば紹介しようと考えていますが、みなさんも探ってみてください。


PowerShellに関しては、「Windows PowerShell コマンド・スクリプト入門 ~Windows Server 2012 R2対応~」で詳しくご紹介しています。

[Windows Server 2012][2014年1月16日配信]

Win Win Windowsコラム
第32回 PowerShellの勉強の仕方(その1)
執筆:横山哲也

 2013年、Windows 8がバージョンアップし、Windows 8.1になりました。その陰に隠れるようにWindows Server 2012もバージョンアップし、Windows Server 2012 R2となりました。大幅な機能変更はあまり無いとも言われていますが、システム管理者にとっては微妙な差異がトラブルの種になるなど、悩みどころでもあります。


 さて、システム管理といえばPowerShell。え、と思った方は今すぐ考えを改めてください。マイクロソフトがシステム管理用のコマンドとして最も力を入れているのがPowerShellです。


 このPowerShellも、今回のバージョンアップに伴い3.0から4.0へとバージョンアップしています。「ほとんど使っていないのに、いつの間にか4.0かよ」なんて声が聞こえてきそうですが、4.0です。


 「これからはPowerShell」だと言っても、コマンドプロンプトを活用しシステム管理をしていた方、過去のバッチファイルやスクリプトなどの資産が大量にある方、つまりコマンドプロンプトのベテランほど、PowerShellへの移行(?)が進んでいないのではないでしょうか。その理由は色々あると思いますが、1つに新しい体系のコマンドを憶えなければ、というPowerShellへの拒否反応などがあるように感じています。


 ここでは、そんな方(そうでない方も含めて)、"明日からコマンドプロンプトを開かなくていい" ようになってもらおうと思います。


 コマンドプロンプトのベテランの方がPowerShellに移行するには、最初に考え方を改める必要があります。それは

「PowerShellはコマンドプロンプトと別ものではなく、コマンドプロンプトの機能を含むものである」

ということです。両者の内部的な構造や実装技術は異なりますが、利用する上ではこのように考えて差し支えありません。


 その理由を説明するために、コマンドプロンプトの復習を兼ねてコマンドプロンプトとPowerShellでは、何が実行できるのかをまとめてみます。

コマンドプロンプトで実行できるもの

PowerShellで実行できるもの
内部コマンド
外部のファイルを利用せず、あらかじめ組み込まれているコマンド

例、DIR、COPYなど

コマンドレット
外部のファイルを利用せず、あらかじめ組み込まれているコマンド

エイリアス設定済み多数

例: Get-ChildItem、Copy-Itemなど

外部コマンド
exeファイルなどの実体があるコマンド
Windowsに付属するコマンド
アプリケーションと一緒に追加されるコマンド

例、XCOPY(Xcopy.exe)、
IPCONFIG (IPCONFIG.exe)

Windowsネイティブコマンド
exeファイルなどの実体があるコマンド
Windowsに付属するコマンド
アプリケーションと一緒に追加されるコマンド

例、XCOPY(Xcopy.exe)、
IPCONFIG (IPCONFIG.exe)

スクリプト(バッチファイル)
連続して実行するために、複数のコマンドをテキストファイルとして記述したファイル
拡張子がBAT、CMD、VBSなど
スクリプト
連続して実行するために、複数のコマンドをテキストファイルとして記述したファイル
拡張子がBATCMDVBS、PS1など
  関数
名前を付けたスクリプトブロック


 見ての通り、コマンドプロンプト(CMD.EXE)とPowerShellでできることはほとんど変わりません。違うのは、内部コマンド(コマンドレット)の利用規則だけです。また、PowerShellからは、外部コマンドを自由に使えますし、スクリプトも実行できます。CMD.EXEの代表的な内部コマンドはPowerShell用に別名がつけられているので、単純な機能なら同じように使えます。たとえばPowerShellでDIRコマンドを実行すると、ファイル名の一覧が表示されます。


 次回はこれらの機能についてもう少し詳しく紹介します。


 なお、PowerShellの設計者の一人であるBruce Payetteの著書「Windows PowerShellインアクション」では、Windowsに付属するEXEファイル形式のコマンド(CMD.EXEの外部コマンド)を「ネイティブコマンド」と呼んでいますが、ここでは「Windowsネイティブコマンド」としました。


第2回はこちら 「PowerShellの勉強の仕方(その2)


PowerShellに関しては、「Windows PowerShell コマンド・スクリプト入門 ~Windows Server 2012 R2対応~」で詳しくご紹介しています。

[Windows Server 2012][2014年1月10日配信]

※Microsoft、Windowsは、米国Microsoft社の登録商標です。
※Oracleは、米国オラクル・コーポレーションおよびその子会社、関連会社の米国およびその他の国における登録商標です。
※PMI、PMP、PMBOKは、プロジェクトマネジメント協会(Project Management Institute, Inc.)の登録商標です。
※ITIL®はAXELOS Limited の登録商標です。
※American Management Association は、米国アメリカン マネジメント アソシエーションの登録商標です。
※BOOT CAMP、NEW TRAIN、Glovalueはグローバルナレッジネットワーク株式会社の登録商標です。
※その他このサイトに掲載された社名、製品名は、各社の商標、または登録商標です。

© Global Knowledge Network Japan, Ltd. 2008-2016, All Rights Reserved.
  • Get ADOBE READER