Microsoft Tech・Ed Japan 2011 ホーム の 2 日目。
以下、各トークセッションの内容について。自分の所感・意見と発表者の発言やプレゼン資料の内容ごちゃ混ぜに書くので読みにくい点が多々あると思います。日本語崩壊してる部分も多々です。自分用の備忘録的な意味合いの強いエントリなので、そのあたりの読みにくさについてはご容赦願います。
Dynamic IT : 仮想化時代の IT 運用
キープロダクトとして Windows Server 2008 Hyper-V, Microsoft System Center, Desktop Optimization Pack for Software Assurance を上げていた。昨日のキーノートでも語られていたが、IT 関連予算の大半が保守・運用へ投資せざるを得ない状態を苦々しく思っており、なんとかして新規分野へ投資を回せるような環境を作っていきたい、とのメッセージを発していた。
Dynamic -IT とは、IT を戦略的な資産にする Microsoft のテーマというか宣伝文句というか。
歴史的に見ると、初期の IT は本当にコストの塊―いわゆるコストセンターという言い回しで言われることが多い―で、少しずつだが効果的なコストセンターに変わりつつあり、近年では IT がビジネスを牽引するケースも出てきたので、IT が戦略的な資産になる日も近いだろう、と。企業における IT の導入はこういったステップを踏んで進化していくと考えているが、まだまだコストセンターに過ぎない組織が多いと考えている。この手助けが MS の課題だとかなんとか。
こうした状況を踏まえた上で、仮想化というのがどう役に立っていくのか。
マイクロソフトの仮想化テクノロジー。データセンターからデスクトップまで。一般的には、仮想化というと、OS の仮想化がイメージされるが、仮想化にはさまざまな分野がある。データセンターのサーバー、デスクトップ、アプリケーション、プレゼンテーション。プレゼンテーションの仮想化は何いってんのか良くわかんなかった。
仮想化による柔軟性の実現。ハードウェア、OS や アプリ、データや設定の各レイヤを分離することで運用の柔軟性の確保を目指す。たとえば、アプリケーションレベルの仮想化では、別バージョンの Office を一つの OS 上で動かすことができるようになる。それぞれのアプリケーションが隔離された環境で動作する、ということ。Microsoft SoftGrid Application Virtualization を使用した導入事例が興味深かった。
次に、データセンターの仮想化。現状、データセンターの各マシンのリソースがフルで使われているケースはそうは無い、らしい。余ってるリソースが勿体無いので、Hyper-V によって複数の物理サーバを 1 つの仮想サーバとして扱う。これによって、柔軟なインフラ環境の構築、動的なリソースの割り振りが可能になる、とかなんとか。
……導入事例を幾つか出していたけど、まぁ、こういう成功事例はある程度眉唾で聞かにゃならんだろうねぇ。とはいえ、真実といえば真実だから、どこまで鵜呑みにするかは難しいところだろうなぁ。……しかし、仮想化ってのはなんともアツイトピックスみたいだなぁ。実際に運用・インフラ系のエンジニアな人たちはどう捉えてるんだろ？
次に、運用管理。仮想化は非常に魅惑的なプロダクトだが、運用・保守が出来ないでは片手落ち。このあたりの分野についても MS はプロダクトを提供していく予定、とのこと。
インテル vPro テクノロジー。現状、PC に関してはどれを買っても余り変わらないのでは、という状況になっている。vPro テクノロジーは、低消費電力かつ高性能、運用・管理機能、セキュリティ機能の強化、をハードウェア的に実装する。
要素技術としては、C2D プロセッサや、ネットワークコンポーネント、チップセットなど。それらハードウェアの上で機能強化を行う、とかなんとか。
リモートの電源管理は Wake On Lan というものが以前からあった。しかし、Wake On Lan は、OS が動いてないマシンの電源 OFF/リセットは難しいところがあった。vPro ではそれが可能になり、よりきめ細かいコントロールが可能になる、とのこと。たとえば、リモートから調子悪いマシンの BIOS 立ち上げたり、ブートする OS 変えたり、なんてことが出来るらしい。
これらの仮想化・遠隔操作テクノロジにより、現場へ技術者を派遣するコストが削減できるようになるわけです、とかなんとか。
データセンターの将来。現在は物理的なマシンをベースに運用を行っているが、ハードウェアを仮想化したレイヤをおき、更にその上でアプリケーションの仮想化が実現されていくだろう、と。OS とアプリを独立して更新できるようになる、とかなんとか。理想的＆具体的には、アプリケーションに対する Windows Update の影響が最小限に抑えられる、ってことなのかなぁ？ まーオープニングだからしゃーないってのはあるけど、夢物語聞いてる気分ｗ
パフォーマンスとリソースの最適化。仮想化によって、何か問題―負荷やアプリの問題でストップ―した場合に、物理リソースを動的にスケールアウトすることによって対応出来るようになる。
クロスプラットフォームの運用監視。System Center Configuration Manager（長ぇので以下 SCCM）の Virutal Machine Manager なるもので、VMWare で構築された仮想マシンもまた SCCS から監視できるようにする、とかなんとか。これによって Hyper-V と VMWare を混在可能になる。また、Windows と Linux の混在（従来もソレナリに出来ていたらしいが）も出来るようになる。Cross Platform Extenstion によって、非 Windows の HP-UX とか AIX とかも SCCM 側から監視対象にできる。ちなみにこのクロスなんとかはまだβ版。
次に、ID 管理＆セキュリティ。Forefront なんていう製品がある。企業向け包括的セキュリティソリューション。導入事例見たけど、今ひとつイメージがわかなんだ。
統合されたインフラストラクチャの提供。今日紹介したデモでのソフトウェアやクノロジーは以前から個別に一つずつあったわけだが、それらを統合して使う時期に入っており、それによってお客様に使いやすいソフトウェアを提供できるようになる、と考えている、と。
ここ最近、俺は運用・インフラの知識不足を感じていて、とりあえず [24時間365日] サーバ/インフラを支える技術 ?スケーラビリティ、ハイパフォーマンス、省力運用 (WEB+DB PRESS plusシリーズ) から入門を試みている。まだちょっとしか読んでないけど、こういうインフラ周りって、メッチャ大雑把に分けると 2 つのアプローチがある、ように感じた。1 つは、OSS をいじくり倒して使いこなせる高い技術力があればそういうプロダクトで構築する、もう 1 つは、MS みたいに製品自体は金かかるけど GUI ＆マウスポチポチでそれなりに使えます、な感じ。いやまぁ、MS の製品だって本当の意味で使いこなすのは大変だろうけどねｗ 後者の方は、ビジネスつーかスーツ的な発想な感じかなぁ？ 対して前者はギークっぽい感じがする。ああいや、どっちが良くてどっちが悪いとかそういう話じゃなくてね、なんとなくな印象の話です。
System Center & Dynamic IT バードビュー
昨日の Hyper-V のセッションは低レベルな話が中心だったが、本セッションはそれら製品群を上位のレベルから俯瞰する話。現実を見据えた上で、理想的な IT 環境をどのように構築していくか、という話をしていきたい、とのこと。
System Center バードビュー。System Center を導入するまでのステップ、について。
- ネットワークと認証基盤。帯域の確保・制御、ネットワークを作るということは、2 つ以上の要素から構成されるわけで、Active Directory 等の認証が重要になってくる。
- ハードウェアの準備。仮想化が当然な時代になれば、ただ単にプロジェクトごとにハードウェアを買うのでなく、先を見据えた戦略的なハードウェア投資が重要になってくる。
- ストレージ環境整備。複数台マシンを買ったからそれで済む、という話ではない。ディスクやネットワーク I/O がボトルネックにならない設計が必要になる。
- 構成変更管理。以上の段階まででハードは揃う。この段階では OS を入れたりする。このマシンにはこのソフトが必要であの設定が必要で、とかを設計する、ということ。そうすると、ポリシー通りに各マシンの構成が動いているか、の運用監視が必要になる。そのためにツールに Configuration Manager というものがある。
- 仮想インフラ構築と仮想インフラ集中管理。そうして構築した物理環境は、仮想環境を構築するための基盤となる。MS では、Virtual Machine Manager という仮想環境統合管理製品が使用できる。
- 稼動監視と情報収集。これで各マシンが動作しはじめる。次の段階では、各マシンがちゃんと動作しているか、などの監視が必要になる。Operations Manager というツールが使用できる。
- データ保護。運用を開始すると、データが壊れないようにする、などの対策が必要になってくる。MS では、Data Protection Manager というツールがある。
- 遠隔データ送信（事業継続）。運用、というと上記のステップまでをさすことが多いが、最近は更にもう一段階必要になるだろう、とかなんとか。IT の必要性が高まったために、災害対策など、よりスケールの大きなビジネス要件に対応する必要が出てきた。これらに対応するには、以上のステップでで挙げたツールを組み合わせて使う。
MS の運用管理ツールの戦略について。System Center というのはブランド名で、そのブランドの旗の下に、今挙げたようなツール群がぶらさがっているイメージ。
ちなみに、上記で列挙した MS の製品は、モノによっては、まだβ版なモノがある。その辺ちゃんと明記していないので、申し訳ないけど注意して下さい。
Microsoft の Big Vision - Dynamic IT - 今までの経緯と DSI(Dynamic Systems Initiative) から Dynamic IT へ。
昨日のキーノートなどでも触れているが、保守・運用管理に 80% の投資、革新への投資 20% が行われていない現実があり、MS ではこれをどうにかしたい、という思いがある、という話。
MS の提唱する DSI という思想とは？ 運用特性・必要なリソース・運用ポリシーなどの特性を、アプリケーションを作る段階でシステムを作る、という思想のこと。最近は、リソースの振り分けは仮想環境を上手に活用することでだいぶ出来るようになってきた。が、ネットワークやストレージ周りはまだ柔軟に出来てないところがあるようなので、MS はベンダーと協力することで実現に向けて取り組んでいる、とのこと。
この辺の理想的な流れがホントーに実現できたら色々変わるだろうなぁ。登壇者も、多少疑問に思うところはそりゃもちろんあるよね、という前置きはしてたけど、これまでの積み重ねで少しずつ実現に向かっているよね、と。これが実現できれば SI のあり方なども変わっていくのでは、など。まぁ、俺は運用・インフラ周りアンマリ知らないから、その辺のニュアンスをうまく伝えられないんだけどもｗ
現実的なテクノロジの進化 - 開発・運用管理・プラットフォーム。ここまでは、比較的理想論な話も多かったので、MS のテクノロジを中心に今現実・現在の話をしていく。いくつか話があったけど、運用管理・IT インフラを意識して、システム設計/開発をする、というのは中々難しい、という現状。確かにほとんど意識したことないんだよなぁ。
ただ、運用を意識した設計/開発が MS の製品の充実することでだいぶ現実味を帯びてきたのではないか、と。
登壇者もいっていたが、やはりアプリケーション開発者はコード書くのは非常に得意だが、運用を考えて設計や実装するのは不得意なところがある、との指摘。当たり前といえば当たり前だが、運用のヒトにとっては「運用考えてコード書いてくれー」と思う事態はしばしばあるようだ。開発者と運用管理者は一緒に仕事しなければならない時代になっていくだろう、と強調していた。
そして、クラウドの世界へ。登壇者は、仮想化により物理的な場所を選ばない、という full virtulazation な世界になっていくのではないか、と話していた。無論、まだまだ課題は多いし、仮想環境をベースとした環境のチューニングのノウハウが溜まらないことには次のステージへ行けないこともあるだろう、とかなんとか。
今回の Tech-Edは、MMS(Microsoft Managemnt Summit) というテーマも掲げていて、運用管理・インフラの話を増やしたそうだ。俺にとっては良いタイミングだったなぁ。運用管理・インフラの知識不足が、俺のプログラマーとしての質というか格の向上のボトルネックになっているのでは、と最近感じていたので。
まとめの最後に、登壇者は、Knowledge Driven Communication と銘打っていたが、他分野の技術者と交流することが必要だ、と感じている、といった主旨のことを話していた。そして、それら多様な価値観を踏まえることによって、自分の専門分野にもフィードバックして活かせる、と。インフラ系のヒトも、お客様に良いシステムを提供したい、ってとことか、タコツボに陥っているんじゃなかろうか的な悩みは同じなんだろうなー。
要求の欠落を未然に防ぐ『要求開発』テクニック〜なぜ完全で正確な要求仕様の獲得は困難なのか〜
株式会社サイクス http://www.cyx.co.jp の中のヒトの BoF。
本日は特に断りのないかぎり 要求開発と要求管理 から引用を行っています、とのこと。
導入として、テスト業務の話。テスト業務は人海戦術的なところはあるが、クリエイティビティが求められる要素もある。テスト業務の効率化の観点からみると、理想的にはテストしないで済むような開発体制を作れるのが良い。要求開発の観点からは、余計なものを作らない、等の話につながってくる。
本 BoF では、要求の欠落に対する対策について扱う、とのこと。派生開発に対する対策についてはまたの機会に、と。
なぜ、"要求開発"と呼ぶのか？ 要求は発見し発明するものである。定義・収集という単語は、お客様の頭の中に既にある「何か」をただ単に機械的に抽出する、というイメージがあるが、実際にはそうではない。実際には、要件定義などと言われるものは、創発的なアプローチなのではないか、と話していた。
では、そうした手間をかけて優れた要求を獲得することの価値とは？ 要求仕様書の品質を確保することは重要。要求仕様書の品質とは、色々な種類が考えられる。狩野モデル（このモデルの詳細については割愛）では、お客様にとって出来て当たり前のことはいくら満たしても、それ以上は満足度は上がらない。だが、ソフトウェアは、まだまだ、その出来て当たり前の欠陥―いわゆるバグ―による顧客満足度の低下を招いている状況にある、とスピーカーは指摘していた。
現在のソフトウェア開発におけるバグと手戻り（デバッグ＋再テスト）コストの高さについての言及。一般的な開発プロジェクトの体制では、テスト・運用保守フェーズで手戻り（ここではリワークという言葉を使っていた）とバグの発見を行っている。このため、ここのマネージメントをトチると大災害が発生する。つまり、現状の体制ではリワークを出来るだけしないようにすることが重要。まーこの辺はウォーターフォールの負の側面としてよく語られることだよね。ウォーターフォール型開発そのものが悪だとは思わないんだけど……。
要求開発に投資しなければならない理由について。つまり、リワークコストをうまくコントロールすることが品質や生産性の向上につながってくる。
ソフトウェア要求には大別して、機能要求と非機能要求がある。本 BoF では機能要求に関するトピックのみ扱う、と断りをしていた。
3 つのソフトウェア要求レベルについて。そのソフトウェアは何のために・何故つくるか、を明確にし、それを段々詳細に落とし込む、というアプローチの紹介。
要求開発と要求管理のサブコンポーネントについて。要求開発でベースラインを作成し、それを元に要求管理を行う。要求開発は、引き出し・分析・仕様作成・検証のフィードバックを繰り返す。とはいえ、要求の欠落の検出は非常に困難である。結局、無いことを発見しなければいけないわけだから。
ソフトウェアプロダクトの開発は、既存のプロダクトでは満足できない何かがあるから出発する。そのため、こうしたい、というビジョンがブレてしまうと出来上がるものが無茶苦茶になるのは必然である。
スコープ定義。コンテキストダイアグラムの話。ステークホルダーと、プロダクトを絵に書く。プロダクトが扱うのはどこまでで、ステークホルダーとどんな情報をやり取りするか、という境界をハッキリさせる図を描く。しかし、プロジェクトの初期段階でこの図を正確に描けるという保障はどこにもない。
次に、（スコープ定義が出来たという前提で）スコープをユースケースに分割していく、という話。MECE というテクニックがある、とかなんとか。とはいえ、まぁこれもやっぱりスコープ定義と同じで、完全な引き出しが出来る保障はない。うーん……このへんはヒト依存なとこが大きいよ、ってことなのかなぁ……
次に、ユースケーステンプレート（これは色んなヒトがいろんなやり方を提唱している）を埋めていく。こういった詳細化と書いたものの検証を繰り返すフィードバックの中で要求の欠落の検出だとかをしていく、ってところなのかなぁ？
ユースケースの通常フローシナリオはテストケースにそのまま対応する。ただし、テストデータの設計は別途必要になる。難しいのは、当然例外フロー。基本的には、ユースケースをベースに例外フローを考える。だが、完全なユースケースを導くのが難しいわけで、ということはつまり、通常フローから出てくる例外フローは漏れている可能性がある。そのため、その例外・代替フローを考えるうちに、フィードバックを受けて新たなユースケースを発見することもある。
要求仕様書とテスト仕様書の関係は対応関係がある。このため、対応関係が崩れた場合、要求が漏れているか・テストケースが漏れているか……どちらにせよ、要求仕様書かテスト仕様書のどこかしらに欠陥がある、ということを示している。「要求」というモノを要求仕様書とテスト仕様書、という異なるモデルを作ることで互いに検証しあっている、と言い換えることもできる。
このモデルによる検証という考え方は、開発プロセス全体に波及させることも出来るのではないか、とスピーカーは指摘していた。つまり、設計・実装・テストという段階も一つのモデルとして考える、ということ。まーでも実践するのは中々……
最後に、アジャイルと計画型開発の比較、をちょっとだけやっていた。アジャイルは、関係者の数を最小限に絞って暗黙知の利点を最大限に活かすことだ、というスピーカーの発言が印象に残っている。
プロジェクトの規模が大きくなると、関係者の数も増えるわけで。そのため、スキルも立場もバラバラ人たちの間の認識共有のために、自然言語を用いたドキュメントがより多く必要になる、て感じなのかな。
