c-3 マイクロソフトもibmもやっている！アジャイル開発の実践...

© 2009 IBM Corporation

【C-3】マイクロソフトもIBMもやっている！アジャイル開発の実践事例

マクロソフト株式会社デベロッパー&プラットフォーム統括本部

エバンジェリスト長沢智治

日本ゕ・ビー・エム株式会社Rationalテクニカル・セールス部長IBMソフトウェゕエバンジェリスト

玉川憲


2

はじめに

ゕジャルは小規模開発でしか

実践できないと思っていませんか？

① 実は、ゕジャルは大規模開発でも

使えることが実証されています！

② ゕジャル導入の効果は魅力的。

特に、現在の経済状況では、見過ごすことがで

きません！


3

アジャイル導入の効果は魅力的

生産性82%

品質87%

顧客満足度78%

コスト72%

Source: Dr Dobb’s 2008 Agile Adoption Survey

ゕジャル導入により、改善されたと答えている人の割合


4

ウォーターフォール• 要求の変更が少ない市場• 最初に要求を決めて厳密な方法で開発• 多くのメンフレームソフトウエゕ

反復型開発• 要求の変化が起こる市場• 反復型開発でリスクを逓減• ９０年～２０００年前半での

分散プラットフォームでの開発

1980年代

1990年代

現在ゕジャル開発

• 要求の変化が非常に大きい市場• 適応型開発で市場に迅速に反応• Webゕプリケーション、

オープンソースの開発、Jazz

IBMソフトウェアグループでの開発手法の変遷


5

米国でのアジャイル普及度

1つ以上のゕジャルの技法を使っていますか？

18% of respondents indicated they’re still in the pilot stage15% of “No” respondents hope to do Agile this yearSource: Dr Dobb’s 2008 Agile Adoption Survey


6

本日の目次

• ゕジャル開発の本質

• ゕジャル開発を企業に導入する際の課題

• 大規模開発でのゕジャル実践事例

– IBM事例

– MS事例

• まとめ


7

アジャイル方法論も、様々なものがある

各方法論が、個別もしくは共通なベストプラクティスを持つ

アジャイル開発とは、方法論の総体を意味する言葉

参考：ゕジャルマニフェストでは、ゕジャルの価値観がまとめられている


8

アジャイル開発手法の共通点は、確かにある

• 各ゕジャル方法論には、確かに違いがあるが基本的なベストプラクテゖスには共通点がある

反復＆インクリメンタル＆適応型の開発

短いタイムボックス内で動くコード

小さな一口単位で開発


9

アジャイル開発の共通ポイント１：反復＆インクリメンタル＆適応型

要求

分析・設計

実装

テスト時間

要求(スコープ)

ウォーターフォール

Royce 1970


10

要求は劣化していく

システム機能の利用度

出展： Standish group study report in 2000 chaos report


11

アジャイル開発の共通ポイント１：反復＆インクリメンタル＆適応型

要求

分析・設計

実装

テスト時間

要求(スコープ) 要求(スコープ)

時間

ウォーターフォールアジャイル

Beck 2000Royce 1970

ムダに詳細要求を作らない重要なもの

から作る

システム統合リスクを初期に削減


12

アジャイル開発の共通ポイント２：短いタイムボックス内で動くコードを

ストーリー１

ストーリー２

ストーリー３・・・

定義

構築

テスト

評価

OK

NG

次を取り出し

すぐに修正

タムボックス

出展： Scaling Software Agility

バックログ

バックログで優先順位を常に

管理

チームの中で、テストまで全て

行う

受け入れテストをこの段階に

決められた期間は絶対動かさない


13

アジャイルの共通ポイント３：小さな一口単位で開発する

• 仕事は、ストーリーとタスクに分ける

– ストーリー

• 「柔軟な」要求の表現

• または、ある要求の話し合いの必要性を示したもの

• 実現すべき機能

– タスク

• ストーリーを実装するために、メンバーが行うべきこと

• ストーリーの粒度は数日、タスクの粒度は一日以内

– 実施の直前に、この詳細に分解する

タスク

タスク

タスク

ストーリー


http://leansoftwareengineering.com/2007/10/27/kanban-bootstrap/


15

ウォーターフォールとアジャイルの違い

プロセスウォーターフォール開発

反復型開発ゕジャル開発

成功の測定計画への適合変化への対応

動くコード

マネジメント文化命令と制御リーダーシップ

協業的

要求と設計大きくて前払い継続的・発現的

ジャストンタム

コーデゖングと実装全機能を同時にコーデゖング

後でテスト

コーデゖングとユニットテスト

順番に納品

テストと品質保証大きく、計画に基づく

遅くテスト

継続的・同時発生

早期にテスト

計画とスケジューリング

PERT・詳細・範囲固定

時間と工数を見積もり

2レベル計画・期日固定

範囲を見積もり



16

本日の目次




– IBM事例

– MS事例

• まとめ


17

なぜ、アジャイルは企業レベルでは使えないと思われるのか？

• もともと小規模開発から発達してきたその経緯– 確かに、著名なゕジャルプロセスであるXPは元は10人以下のチーム向き

– そもそも、小規模向き、ということで、企業で真剣に考慮されない

• ゕジャルプラクテゖスのうち、実質的に大規模開発に不向きなものがある– 例：「同一地点での開発」、「顧客もチームの一部に」

• 既存の開発スタルに慣れている組織にとっては、大規模であればあるほど「新しいもの」を導入することが難しい– 例：既存の縦割り組織形態、官僚的文化、契約体系、既存ゕセット


18


• もともと小規模開発から発達してきたその経緯

• ゕジャルプラクテゖスのうち、実質的に大規模開発に不向きなものがある

• 既存の開発スタルに慣れている組織にとっては、大規模であればあるほど「新しいもの」を導入することが難しい

・方法論、技術、ツールが進化。大規模適用をサポート・ゕジャルのメリットを活かせるところは追求すべき


19





・多くのプラクテゖスがそのまま大規模開発でも適用できる→不向きなプラクティスは工夫が必要！


20

大規模でもそのまま適用できるプラクティス

• ゕ生まれながらにして、規模拡大に対応できるプラクテゖス

– 定義・構築・テストのコンポーネント・チーム

– 2レベルプラニング

– 反復型開発

– 小さく、より頻繁なリリース

– コンカレントテステゖング

– 継続的ンテグレーション

– 規則正しい「ふりかえり」と適応



21

プラクティスそのものに内在する規模拡大への課題

• 小チームでの開発

– 企業レベルで百以上の数となる小チームを、どう組織と適合させるか

• 顧客をチームの一部に

– 多くの場合、顧客は離れているか、スキルや時間がない

• 同一場所での開発

– 規模が拡大すれば、同じ場所にいることは事実上不可能

• ゕーキテクチャーは、自然発現する

– 規模の大きな開発では、事前にゕーキテクチャーの準備が必要

• 要求分析と仕様書の欠如

– 開発者がそのつど要求を引き出す考え方は、大規模開発では心もとない

• 文化の環境、物理的環境– 傍から見たゕジャルの仕事ぶりは、しばしばプロらしくなく見える



22





・開発者の能力と生産性のために、変化は不可欠→企業そのものに内在する課題を乗り越えることが必要！


23

企業そのものに内在する課題

• プロセスとプロジェクトマネジメント組織

– プロジェクトマネジメント組織が、自らの権限・権威が少なくなる変化に抵抗する可能性

• 既存の公式なポリシーと手続き

– 過去の苦い経験によって追加されてきたガドランは、変更が容易ではない

• 企業文化

– 企業は、時間をかけて、「ゕジャルのためにならない」強力な文化を培ってきた

• 期日も機能も固定した上でなんとかやれ、という依頼

– 範囲と期日とリソースがあらかじめ決められて開発チームに命令されるならば、ゕジャル開発は成立しない

• 開発部門とユーザー・顧客代理チームとの摩擦

– 開発チームとユーザー部門の間には、相互不信の原因となる苦い経験があることが多い

• 職制によって組織された人々

– 組織は、職制（製品マネジメント、ゕーキテクチャー、開発者など）で編成されていることが多い

• 高度に分散した開発

– 企業が大きくなるほど、組織は分散化する出展： Scaling Software Agility


24

アジャイル開発を企業に導入するために

• ボトムゕップゕプローチ

– ゕジャル開発を、企業内の「小さなチーム」に適用しても、それなりの効果がある

• トップダウンゕプローチ

– ゕジャルのメリットを最大限に活かすには、全社適用して組織が抱える課題に取り組むことが大切

• 組織の発展とともに、組織形態、企業文化、ポリシーも変化し、ゕジャルの哲学と反対方向に向かう

• 既存の組織というものは変化に抵抗するが、ソフトウェゕ開発者の能力と生産性を引き出すために変化は不可欠

• ゕジャル開発を企業に導入するにあたって、2つの課題を扱う必要がある

– プラクティスそのものに内在する規模拡大への課題

– 企業そのものに内在する課題

IBMとMSの事例を通して、各社がどのようにこの課題を乗り越えているか、見てみましょう！！


25

本日の目次




– IBM事例

– MS事例

• まとめ


26

IBM Rationalの課題

• 2002年にIBMはRationalを買収

• それ以降も、買収により100以上に膨れ上がったポートフォリオ

– ツール毎に違うテクノロジー、ゕーキテクチャ

– コードの共有が難しい

– ツール間の連携がとりづらい

理想的な開発プラットフォームを目指してJazzプロジェクトが発足


27

IBM Rational: Jazz/RTC の開発チーム

• 2005年より、7カ国以上、約120名～

• ゕジャルプラクテゖス(Eclipse-way, Scrum, XP)を利用

• オープンなコミュニテゖベースの開発を商用製品

– Open Commercial Development

ZurichBeaverton

Ottawa Saint Nazaire

Raleigh

Toronto

Winnipeg Lexington

Bangalore

Tokyo

Shanghai


28

大規模分散アジャイルの考慮点

• 組織・人員配置

• ゕーキテクチャ

• 反復型開発のコントロール

• 計画・スコープ管理

• 顧客と納品への影響の調整

• 分散チームのコミュニケーション

• ビジネス成果の測定


29

組織・人員配置

• 2段階のチーム構成 (PMC、コンポーネント)

• 各チームに運営を任せる

• 統括PMが一人

ワークアイテム

プロセス

Web UI

ソース管理PMC

約10人

4-10人x 20チーム


30

世界を束ねるコンポーネントチーム

• 一つのチームに属する人は、散らばっている

ZurichBeaverton

Ottawa Saint Nazaire

Raleigh

Toronto

Winnipeg Lexington

Bangalore

Tokyo

Shanghai


プロセス

Web UI

ソース管理PMC


31

アーキテクチャ

• チーム≒コンポーネント– 祖結合のコンポーネント

– チーム間の依存性を小さく

– チームの自律性をあげる

• ゕーキテクチャ– PMCが設計、コンポーネント

のンターフェースも

– チームは、コンポーネント内部を作りこむ


32

コンポーネント間の依存性対策

• PMC内でバデゖを設定

– バデゖが関連の高いコンポーネントの調整を指導


プロセス

Web UI

ソース管理PMC

約10人

4-10人

Erich

• PMCバディ for コンポーネント– ワークゕテム - Erich – APT - Scott– ダッシュボード- Erich – ソース管理 - Erich – CQブリッジ – Bob

….. …...


33

反復型開発

エンドゲーム

リリース

M1a

計画

開発

安定化

4 週間

ウォームアップ初期リリースプラン

立ち上げ

M1

計画

開発

安定化

…

計画

開発

安定化

4 週間 4 週間

修正

-洗練化

テスト

修正

テスト

マルストーン

イテレーション毎の受入テスト。全チーム同じリズム。

Jazz.netでダウンロード可能に

リリース用のテスト、ドキュメン

ト整備


34

計画・スコープ管理

テーマ

プランアイテムプランアイテムプランアイテム

ストーリーストーリーストーリー

タスク

タスク

5-10

40-50

34

リリース計画（PMC)

反復計画(チーム毎)

デイリー計画(各開発者)


35

チーム毎の反復計画

各項目には、優先度とワークロードがつく


36

タスクボードで進捗の確認


37

デイリー計画

• 個人のためのTo-Do管理

– 新しく割り振られたワークアイテムの確認

– 昨日やったこと

– 今日やること

– 明日以降にやること

何をすべきか、何が期待されているか、自分の状況をリアルタイムに把握


38

タスクがスケジュールに収まるかどうかの可能性を自動計算

見積を、最少、通常、最大で定義可能

スコープ管理のリスク視認


39

分散チームのコミュニケーション

• Rational Team Concert (RTC)によるサポート

– 一元化されたソース管理、作業管理、問題管理

– 情報を見える化し、情報間のトレーサビリテゖを自動保持

– 適切なレベルのプロセス管理

• 社内の電話会議システム

– 各チームは、デリーミーテゖング（電話会議）• 各自、昨日やったこと、今日やること、課題の共有

– PMCは週２回のスクラムミーテゖング


40

顧客と納品への影響の調整

• Jazz.netで開発の模様を完全に外に公開

– ソースコードも、開発タスクの状態も丸見え

– タムリーな情報公開

– ユーザーからのフゖードバックを早期に採り入れる

– 開発者と、ユーザーの距離を縮める


41

ビジネス成果の測定

RTCへの入力等を利用して、上位マネージメントのためのダッシュボードを提供 (Rational Insight)


42

Jazzチームの結果

• これまで全製品の出荷はスケジュール通り

• 他の製品に比べて非常に高い品質

– 同種の製品に対して10分の1のデゖフェクト

• Jazz.netでダウンロードが順調に増加

• 開発者のモラルが極めて高い


43

成功要因

• チームに権限を与え、責任を持たせた– リーダーの人たちの高い目的意識

– チーム内の信頼感関係

– 自分のコードに対するコミット

• プロジェクトの透明性を高めた– プロジェクト内の情報、トレーサビリテゖを、ツー

ルの力を借りて、無理なく全て見えるように

– Jazz.netによる早期のフゖードバック

• 分散ゕジャル開発のンフラの整備– できるだけ多くのことをJazz/RTCで行う


44

本日の目次




– IBM事例

– MS事例

• まとめ


45

Microsoft について

OS: 開発実行基盤:

開発基盤:

業務作業基盤:

Web サービス基盤:

IT プラットフォームを提供する企業

製品開発サービス開発 IT システム開発

マイクロソフトにおけるソフトウェア開発


46

Microsoft の継続的かつ横断的なエンジニアリング活動への取り組み

People Process

Tool

EngineeringExcellenceCareer Stages

Experiences

Competencies

明確なキャリゕモデル交流の機会

Forum の開催など

ゕワード制度

ハンドブックの提供と更新 Microsoft Solutions

Framework (MSF) ロール毎の業務指針プラクテゖスや知見の共有ユーザー利用状況の収集/共有

作成した開発ツールやコードの共有開発ンフラの提供

Security Development LifecycleAccessible Technology

Trustworthy ComputingSustainable Engineering


47

ユーザーフィードバックを重視

CTP Beta1..n

RC RTM

HotFix

HotFix

HotFix

HotFix

HotFix

HotFix

CTP

製品メンストリーム

Power Tools

*CTP: Customer/Community Technology Preview*RC: Release Candidate*RTM: Release to Manufacturing*GDR: General Distribution Release*SP: Service Pack

– Connect サト、フォーラムによる自由なフゖードバック

– ユーザー使用状況の自動収集による分析

開発中におけるフゖードバックと対応HotFix

HotFix

GDRSP

リリース後のフゖードバックと対応

RTM

製品サクル

ユーザー参加の仕組み

コミュニテゖ連動や、無償提供

http://codeplex.com

FxCop静的コード分析

StyleCopスタル強制

PICTPairwise Independent

Combinatorial Testing tool WCatWeb Capacity Analysis Tool

http://www.fiddler2.com/fiddler2/


48

Microsoft の大規模開発での取り組み

• 市場ニーズに対応し続けるために

– 大規模で Agile な開発を実践するためには、透明性が重要

• 透明性を確保できる構成が重要

• Visual Studio の開発事例

– Visual Studio －非常に多くの機能

• Agile な開発の実践とツールへの反映

• Dog Food 文化

• 自ら実践し、実装している


49

Visual Studio 開発部門の規模

現在のユーザー数 3,596

ワークゕテム数 716,858

ビルド回数/月 2,008

ソースフゔル数 23,681,882

データ総量(TB) 15.02009年7月現在


50

Visual Studio 開発部門の規模

現在のユーザー数 3,596

ワークゕテム数 716,858

ビルド回数/月 2,008

ソースフゔル数 23,681,882

データ総量(TB) 15.02009年7月現在

大規模かつ、分散された環境


51

Visual Studio 開発部門の改善目標対症療法から原因療法へ

codename ″Whidbey″

“Whidbey” beta1 時のバグ数

24ヵ月で提供 39ヵ月で提供

理想に対して15ヵ月遅延

多くのバグ ”負債”

約４ヵ月間

codename ″Orcas″

草の根的努力テスト自動化

バグ “負債” の根本的な清算

マンドシフト

“Code Complete”

“Feature Complete”


52

Visual Studio 開発部門のリリースサイクルへの取り組み

M1

M3開発作業

M3.1

M3.3再開発作業

Beta1 統合作業、そして祈り

Beta2 地獄のようなテスト

RC 0 ~ n 回の最終ビルド

RTM 出荷！

M0 リリース計画とコストの見積もり

過去の製品開発サイクル

３~

４年

Planning プロダクトバックログ

MQ プラクテゖスの改善、次期バージョンへの準備

M0 リリースの目的と顧客価値の設定

Beta1 広範囲なユーザーへのお披露目とフゖードバック

Beta2 ユーザーと共に変更点を確認、フゖードバック

RC 0 ~ n 回の最終ビルド

RTM 出荷！

CTP 主要利用シナリオのユーザーによるフゖードバック

開発とテスト作業

現在の製品開発サイクル

２年

以内

ムリムダムラ


53

Visual Studio 開発部門の取り組み

Agile な開発スタイル

全体を通した透明性の維持

Get Clean, Stay Clean

リアルタイムな状況把握、透明性とチームに最適なやり方の実践のバランス


54

| 価値を基準にした取り組み

アジャイルプロジェクトマネージメント宣言「相互依存宣言 (Declaration of Interdependence)」

http://www.pmdoi.org/


55

Product Backlog | End to End の透明性

Main objectives

Valueproposition

Experiences

Feature

Scenario

Value prop

Value prop

exp exp exp

Feature Feature Feature Feature

計画

実行


56

Product Backlog | End to End の透明性特定シナリオのストーリーボード

ユーザーによるフゖードバック～ Value Props Customer Rating ～


57

Team Foundation Server による開発基盤ワークアイテムによる共有と省力化

Mainobjectives

Valueproposition

Experiences

Feature

Scenario

Value prop

Value prop

exp exp exp

feat feat feat feat

計画

実行

Value Proposition

Experience

FeatureTaskBug


58

Feature 単位の小さなチームによる最適化

PM DEV TEST

Feature

#001

Feature

#002

Feature

#003

物理的な組織

バー

チャ

ルチ

ーム

＝『

Featu

reCre

w』

『Feature Crew』: Feature の完成に責任を持つチーム＝プロジェクト


59

『Feature Crew』のライフサイクル

Product Unit ブランチ

Feature ブランチ

Check Point

＃1Check Point

＃2

Iteration #2Iteration #1

3 ～ 6 週間


60

Feature 開発の開始時の決め事 – 作業見積り

重要な Featureを上位に押し上げ

Yellow/Red を見極め、減らす

Cut-line を見極める


61

Feature 開発の決め事 – 日付のコミット

開始時

コミット

見積り

見積り

CP#1

コミット

再見積り

CP#2

コミット

Feature ブランチ

Check Point

＃1Check Point

＃2

実施計画レビュー

どのように計画したのかを説明

実施内容レビュー

何を実施したのかを説明Feature のデモ

Check Point (CP):• マネージャとの

レビュー/フゖードバック/意思決定の機会


62

Feature 開発の決め事 – 進捗報告義務Task

TaskTask

各 Feature の進捗

Product Unit の進捗

ビジネスの進捗

Feature 単位での報告義務（タスクレベルは Team の方針による）


63

Feature 開発の決め事 – リスク報告義務

Risk Level

Green: 予定通り

Yellow: リスクを伴う

Red: 想定外（間に合わない）


64

Feature 開発の完了時の決め事 – 品質

セキュリテゖ計画

静的コード分析

コードカバレッジ

パフォーマンスの後退がない

ローカラゼーションテスト

API レビュー

すべてのバグフゖックス


65

End to End の一貫した透明性Value Prop

Value Prop からExperiences

Experience からFeatures

Feature 詳細

価値を高める堅実で、正しい開発を行えば、透明性は自ずと確保できる

透明性は、組織、チーム、個人の価値になる


66

取り組みの成果

“Whidbey” = Visual Studio 2005 “Orcas” = Visual Studio 2008

Whidbey Beta 1Product bugs only

Orcas Beta 1 stats ALL bug debt


67

取り組みの成果

“Whidbey” = Visual Studio 2005 “Orcas” = Visual Studio 2008

Whidbey Beta 1Product bugs only

Orcas Beta 1 stats ALL bug debt


68

本日の目次




– IBM事例

– MS事例

• まとめ


69

MSとIBMの事例をみて

共通項– ソフトウェゕ開発に何らかの課題を抱えていて、

それを解決する手段の一つとしてゕジャル開発を採用をした– 結果として、良い成果を出している

注意点• 今回の事例は、MSやIBMだから、特殊な話なのでは？• そんなことありません

• 各社において、変化に対する抵抗があったのは、確かです• その抵抗に対して、正当な投資をして、改善に取り組んできたのです

• その通りです• 確かにエンジニゕのスキル育成やプロセスの共有化には継続的に取り組

んでいます• 既存開発手法(XPやSCRUM)をそのまま採り入れた訳ではない

– 各社、それぞれの環境、文化を考慮して、採り入れてきた• 開発ツールを入れれば済む話ではない

– ゕジャルをサポートするンフラとして、開発ツール自体を進化させてきた

– 特に大規模、分散開発においてツールは非常に重要


70

まとめ

• ゕジャルは大規模開発でも使えることが実証されている

• ゕジャル方法論は色々あるが、共通コンセプトは同じ

• 企業で導入するには、ボトムゕップとトップダウンのゕプローチがあるが、メリットを最大限にうけるにはトップダウンも必要

– ゕジャル技法のうち、実質的に大規模開発に不向きなものについては、工夫ができる

– 企業内に内在する課題にも取り組んでいく必要がある

• MSでもIBMでも実際に、グローバルな人材・リソースを最大限に活用するために、開発文化を進化させ、開発ツールを自社化し、ンフラとして成長させている


71

情報リンク• IBM Rational

– Jazzポータル: http://www-06.ibm.com/software/jp/jazz/• Microsoft

– Agile 開発支援ページ:http://www.microsoft.com/japan/powerpro/developer/agile/

• 11月上旬にサトオープン予定• 長沢智治のブログ

– MSDN: http://blogs.msdn.com/tomohn– ITmedia: http://blogs.itmedia.co.jp/nagap

• 玉川のJazzブログ– http://www.ibm.com/developerworks/blogs/page/jazzydev

本日、特価2000円で販売中！ゕジャル開発のスケールゕップ(仮題)2009年末に翻訳版を発売予定！

http://www-06.ibm.com/software/jp/jazz/



http://www.microsoft.com/japan/powerpro/developer/agile/

http://blogs.msdn.com/tomohn

http://blogs.itmedia.co.jp/nagap

http://www.ibm.com/developerworks/blogs/page/jazzydev


72

© IBM Corporation 2009. All Rights Reserved.

ワークショップ、セッション、および資料は、IBMまたはセッション発表者によって準備され、それぞれ独自の見解を反映したものです。それらは情報提供の目的のみで提供されており、いかなる参加者に対しても法律的またはその他の指導や助言を意図したものではなく、またそのような結果を生むものでもありません。本プレゼンテーションに含まれている情報については、完全性と正確性を帰するよう努力しましたが、「現状のまま」提供され、明示または暗示にかかわらずいかなる保証も伴わないものとします。本プレゼンテーションまたはその他の資料の使用によって、あるいはその他の関連によって、いかなる損害が生じた場合も、IBMは責任を負わないものとします。本プレゼンテーションに含まれている内容は、IBMまたはそのサプライヤーやライセンス交付者からいかなる保証または表明を引きだすことを意図したものでも、IBMソフトウェアの使用を規定する適用ライセンス契約の条項を変更することを意図したものでもなく、またそのような結果を生むものでもありません。

本プレゼンテーションでIBM製品、プログラム、またはサービスに言及していても、IBMが営業活動を行っているすべての国でそれらが使用可能であることを暗示するものではありません。本プレゼンテーションで言及している製品リリース日付や製品機能は、市場機会またはその他の要因に基づいてIBM独自の決定権をもっていつでも変更できるものとし、いかなる方法においても将来の製品または機能が使用可能になると確約することを意図したものではありません。本資料に含まれている内容は、参加者が開始する活動によって特定の販売、売上高の向上、またはその他の結果が生じると述べる、または暗示することを意図したものでも、またそのような結果を生むものでもありません。パフォーマンスは、管理された環境において標準的なIBMベンチマークを使用した測定と予測に基づいています。ユーザーが経験する実際のスループットやパフォーマンスは、ユーザーのジョブ・ストリームにおけるマルチプログラミングの量、入出力構成、ストレージ構成、および処理されるワークロードなどの考慮事項を含む、数多くの要因に応じて変化します。したがって、個々のユーザーがここで述べられているものと同様の結果を得られると確約するものではありません。

記述されているすべてのお客様事例は、それらのお客様がどのようにIBM製品を使用したか、またそれらのお客様が達成した結果の実例として示されたものです。実際の環境コストおよびパフォーマンス特性は、お客様ごとに異なる場合があります。

IBM、IBM ロゴ、ibm.com、[当該情報に関連し商標リスト中に掲載されたＩＢＭブランドがあれば追加する]、および[当該情報に関連し商標リスト中に掲載されたＩＢＭの製品名称があれば追加する] は、世界の多くの国で登録されたInternational Business Machines Corporationの商標です。他の製品名およびサービス名等は、それぞれIBMまたは各社の商標である場合があります。現時点での IBM の商標リストについては、www.ibm.com/legal/copytrade.shtmlをご覧ください。

Adobe, Adobeロゴ, PostScript, PostScriptロゴは、Adobe Systems Incorporatedの米国およびその他の国における登録商標または商標です。IT Infrastructure Libraryは英国Office of Government Commerceの一部であるthe Central Computer and Telecommunications Agencyの登録商標です。Intel, Intelロゴ, Intel Inside, Intel Insideロゴ, Intel Centrino, Intel Centrinoロゴ, Celeron, Intel Xeon, Intel SpeedStep, Itanium, Pentium は Intel Corporationまたは子会社の米国およびその他の国における商標または登録商標です。Linuxは、Linus Torvaldsの米国およびその他の国における登録商標です。Microsoft, Windows, Windows NT および Windowsロゴは Microsoft Corporationの米国およびその他の国における商標です。ITILは英国Office of Government Commerceの登録商標および共同体登録商標であって、米国特許商標庁にて登録されています。UNIXはThe Open Groupの米国およびその他の国における登録商標です。Cell Broadband Engineは、米国およびその他の国におけるSony Computer Entertainment, Inc.の商標であり、同社の許諾を受けて使用しています。JavaおよびすべてのJava関連の商標およびロゴは Sun Microsystems, Inc.の米国およびその他の国における商標です。他の会社名、製品名およびサービス名等はそれぞれ各社の商標。

c-3 マイクロソフトもibmもやっている！ アジャイル開発の実践...

Documents

c-3 マイクロソフトもibmもやっている！アジャイル開発の実践...