「The Rational Edge」関連の最新 ニュース・レビュー・解説 記事 まとめ

The Rational Edge：
トランザクション管理の複雑性を克服する（パート1）
The Rational Edgeより：サービス指向のインフラの中で発生するビジネストランザクションは非常に複雑だ。それは、サービスが非同時的で、さまざまな形態を取り、分散し、不透明な場合が多いためだ。本稿は、トランザクション・コーディネーションサービスがこの複雑性をどのように調整し、管理するかについて説明する。（2012/12/6）

The Rational Edge：
アジャイルとシステムテストの新たな関係（後編）
前回は、アジャイル開発プロセスにシステムテストのサブセットを含めた経緯、作業の経過、および結果としてうまくいった点について解説した。今回は、逆に今後の課題として残った点と、開発以外のプロセスに与えたメリットについて説明する。（2008/7/1）

The Rational Edge：
アジャイルとシステムテストの新たな関係（前編）
The Rational Edgeより： 自社製品の品質改善とタイムリーなリリースを行う手段の1つとして、多くの企業がアジャイル開発手法の採用を進めている。どの会社やチームも、アジャイル開発環境においてシステムテスト戦略を最良の形で実行に移す方法を見つけたいと考えている。（2008/6/24）

The Rational Edge：
アジャイル開発の広範な普及を目指して
The Rational Edgeより： アジャイル開発手法は何年も前から一部の組織でうまく利用されてきたが、大部分のソフトウェア企業ではそのテクニックがまだ採用されていない。その理由を探り、業界にアジャイル手法をもっと浸透させる可能性を秘めたトレンドを解説する。（2008/5/8）

The Rational Edge：
見積もりの精度 Accuracy of Estimation
ソフトウェアプロジェクト開発ライフサイクルの見積もりで、パートナーがソフトウェア開発組織をどのように支援するのか紹介する。（2008/3/6）

The Rational Edge：
複雑性を理解する（後編）：ソフトウェアの複雑性を手なずける
前編「ソフトウェアが複雑なのは仕方がない？」では、複雑性の全体像を分析した。後編ではいかに複雑性を緩和するか、その対策について考察する。（2008/1/15）

The Rational Edge：
複雑性を理解する（前編）：ソフトウェアが複雑なのは仕方がない？
The Rational Edge より：ソフトウェアシステムの複雑性は避けられないが、手に負えないものではない。IBMのDistinguished Engineerがアーキテクチャやチーム組織の立場から複雑性にどのようにアプローチするのか見ていこう。（2008/1/10）

The Rational Edge：
鈍重な開発チームは鈍重なシステムを作る？/パート3：役割とポリシー（後編）
効果的ガバナンスは指揮統制ではなく、協調的で協力的なテクニックによる実現を重視する。これは、これはネコを先導するようなもので、何かを強制するのではなく、やる気にさせる方が一段と効率的であるはずだ。（本文より）（2007/11/20）

The Rational Edge：
人事評価と開発者のモチベーション/パート3：役割とポリシー（中編）
前編「自己管理型チームの利点と弱点」は、自己管理型チームを推進するうえでの利点を解説すると同時に、陥りやすい問題点を指摘した。中編である今回は、人材の報酬や評価に関して解説する。（2007/11/15）

The Rational Edge：
自己管理型チームの利点と弱点/パート3：役割とポリシー（前編）
The Rational Edgeより：現代のソフトウェア開発作業のガバナンスに対してIBM Rationalが推奨するアプローチをカバーする連載の第3回となる本稿では、高効率ソフトウェア開発ガバナンスで選定される役割と責務、そしてポリシーと基準を紹介する。（2007/11/13）

The Rational Edge：
プロセスはチャンスが訪れるたびに改善する/パート2：プロセスと基準（後編）
前編「反復開発の『ここはぜひカバーしたいポイント』」、中編「開発プロセス導入のアンチパターン」を通じて、反復開発への移行時に生じるであろう要検討のトレードオフと、開発プロセス-プロジェクトの性質について解説した。後編では、導入したプロセスの継続的なサポートと、コンプライアンスについて解説する。（2007/11/1）

The Rational Edge：
開発プロセス導入のアンチパターン/パート2：プロセスと基準（中編）
前編「反復開発の『ここはぜひカバーしたいポイント』」では、反復開発への移行時に生じるであろう要検討のトレードオフについて解説した。中編となる今回主に、開発プロセスとプロジェクトの性質について解説する。「開発プロセス」を導入すればプロジェクトが成功するわけではない。（2007/10/30）

The Rational Edge：
反復開発の「ここはぜひカバーしたいポイント」/パート2：プロセスと基準（前編）
現代のソフトウェア開発作業のガバナンスに対してIBM Rationalが推奨するアプローチをカバーする連載の第2回となる本稿では、プロセスに絶対不可欠な構成要素や最適な評価指標を紹介する。（2007/10/25）

The Rational Edge：
開発プロジェクト「統治」のピンポイント解説/パート1：原則と組織（後編）
前編では効率性の高いソフトウェア開発のガバナンス手法をまとめた。後編では、それらに共通する展開方法を解説する（2007/10/2）

The Rational Edge：
開発プロジェクトを「統治」するベストプラクティス/パート1：原則と組織（前編）
The Rational Edgeより：現代のソフトウェア開発作業のガバナンスに対してIBM Rationalが推奨するアプローチをカバーする連載の第1回となる本稿では、高効率ガバナンスの目的と原則のほか、プロジェクトごとの成功に必要な組織と利害関係者のコラボレーションについて探求する。（2007/9/27）

The Rational Edge：
初歩の「Perl」「Python」「Ruby」
The Rational Edgeより：本稿は、今日使われている中で最も人気の高い3つのプログラミング言語について解説する。ダイナミック言語のPerl、Python、そしてRubyだ。これらが利用されている理由は何か？ どのような共通点があり、それぞれどこがユニークなのだろうか？（2007/8/28）

The Rational Edge：
ビルドが全滅する原因/プロジェクトの状態を評価する：パート2（後編）
ビルドの健全性は、プロジェクトのほかの多くの問題を示唆することが多い。チームが安定したビルドを作成できないと、適切な進展が不可能になる。壊れたビルドは、ほかにも致命的な問題が潜んでいることを示す場合が多く、チームのスキル不足であったり、脆弱（ぜいじゃく）なアーキテクチャであったり、作業の分割がうまくできていないこともある（本文から）。（2007/7/24）

The Rational Edge：
不完全なコードは推敲フェイズで潰しておきたい/プロジェクトの状態を評価する：パート2（前編）
The Rational Edgeより：ソフトウェア開発プロジェクトの健全性とスケジュールを保証するには、ライフサイクルの中間フェイズでどの部分を評価すべきなのだろうか？ プロジェクトの健全性を客観的に評価するためのリスクの一覧やバックログといった各種プロジェクト成果物の使い方について説明する。（2007/7/19）

The Rational Edge：
UMLを使ったビジネスモデリング（後編）：そうだったのか！ システムユースケース
The Rational Edgeより：IBM Rational Software Architectをはじめとする各種モデリングツールではユースケースのモデリングにどのUML図を使うのかなど、ビジネスユースケースとシステムユースケースの相違点と類似点について学ぶ。（2007/5/24）

The Rational Edge：
UMLを使ったビジネスモデリング（前編）:なるほど！ ビジネスユースケース
The Rational Edgeより：IBM Rational Software Architectをはじめとする各種モデリングツールではユースケースのモデリングにどのUML図を使うのかなど、ビジネスユースケースとシステムユースケースの相違点と類似点について学ぶ。（2007/5/22）

The Rational Edge：
「この開発プロジェクトは中止！」の基準/プロジェクトの状態を評価する：パート1（後編）
The Rational Edgeより：本稿では、従来のソフトウェアプロジェクトの評価基準に関する誤った考えについて解説し、「方向付け」フェイズにおける有効な評価値に焦点を当てる。（2007/4/19）

The Rational Edge：
プロジェクトのはじめに計画を立てるのは無謀/プロジェクトの状態を評価する：パート1（前編）
The Rational Edgeより：一般的に、プロジェクトマネージャが基準として評価するものにチームは注目する。プロジェクトの状態が正確な評価基準に依存するのは自然なことだが、適切なものを評価することの必要性はもっと重要だ。（2007/4/19）

The Rational Edge：
専門家に聞くモデル駆動開発のメカニズム
WebSphereコンサルタントがモデル駆動開発（MDD）や、実行イメージパターン、Java Emitter Templates（JET）、そしてDesign Pattern Toolkit（DPTK）のオーサリングおよびその使用によるアプリケーションのソース生成に関する質問に答える。（2007/3/29）

The Rational Edge：
ウォーターフォールから反復型への移行手順
さまざまな理由から、反復型アプローチに強い思い入れのあるソフトウェア開発者が、従来の「ウォーターフォール」方法論に根差したクライアントに対応しなくてはならないケースは頻繁にある。本稿は、Rational Unified Processへの移行でこのような組織を支援する方法について解説する。（2007/3/22）

The Rational Edge：
専門家に聞くモデル駆動開発のメカニズム
The Rational Edgeより：WebSphereコンサルタントのChris Gerken氏がモデル駆動開発（MDD）や、実行イメージパターン、Java Emitter Templates（JET）、そしてDesign Pattern Toolkit（DPTK）のオーサリングおよびその使用によるアプリケーションのソース生成に関する質問に答える。（2007/3/15）

The Rational Edge：
ソフトウェアアーキテクティングのメリット
ソフトウェアアーキテクティングは、ソフトウェア開発分野において最近その存在が認められた新しい学問だ。ソフトウェアアーキテクチャシリーズ最後の4回目となる本稿では、企業やIT部門が安定したソフトウェアアーキテクチャから享受できるメリットについて解説する。（2007/3/15）

The Rational Edge：
ソフトウェアアーキテクティングのプロセス
ソフトウェアアーキテクティングは、ソフトウェア開発分野において最近その存在が認められた新しい学問だ。ソフトウェアアーキテクチャシリーズの第3回となる本稿では、ソフトウェアプロジェクトのライフサイクルにおいてソフトウェアアーキテクトが進める作業を説明する。（2007/3/8）

The Rational Edge：
ソフトウェアアーキテクトの役割
もし、ソフトウェアプロジェクトのマネジャーが映画業界用語でいうプロデューサーならば、ソフトウェアアーキテクトは監督だといえる。本稿では、ソフトウェアアーキテクトの役割について解説する。（2007/3/1）

The Rational Edge：
「設計」や「構築」よりも重宝されるスキル
IBMのRationalチームは現在、分析、設計、および構築と従来呼ばれていたものを拡張し、そこにアーキテクチャ管理を組み入れようとしている。本稿は、その原動力となる要件や、それをインプリメントするコードが変化する中でソフトウェアアーキテクチャの管理を行うこの専門分野について解説する。（2007/2/27）

The Rational Edge：
「設計」や「構築」よりも重宝されるスキル
The Rational Edgeより：IBMのRationalチームは現在、分析、設計、および構築と従来呼ばれていたものを拡張し、そこにアーキテクチャ管理を組み入れようとしている。本稿は、その原動力となる要件や、それをインプリメントするコードが変化する中でソフトウェアアーキテクチャの管理を行うこの専門分野について解説する。（2007/2/14）

The Rational Edge：
ソフトウェアアーキテクチャーって何なの？（後編）
前篇ではソフトウェアアーキテクチャーの定義を詳細に解説した。分かっているようで実は意外とあいまいなままだったソフトウェアアーキテクチャーの本質に少しは迫れたと思う。後篇ではソフトウェアアーキテクチャーの構造をさらに掘り下げる。（2007/1/29）

The Rational Edge：
ソフトウェアアーキテクチャーって何なの？（前篇）
ソフトウェアアーキテクチャーという比較的新しい分野について概説するシリーズの第1弾。この分野のキーワードを説明し、優れたデザインのアーキテクチャーが、導入された環境にどのように寄与するのかを探っていく。（2007/1/23）

The Rational Edge：
キミのコードが汚い理由
The Rational Edgeより：ソフトウェア開発者がコードを書くに当たり、エレガンス、構造、そして効率について学ばなくてはならない理由を考察する。（2007/1/12）

The Rational Edge：
キミのコードが汚い理由
ソフトウェア開発者がコードを書くに当たり、エレガンス、構造、そして効率について学ばなくてはならない理由を考察する。（2007/1/12）

The Rational Edge：
汎用グラフィカルモデリング言語「SysML」 パート2：グラフィカルなモデル言語で製品構造を記述
（2006/11/15）

The Rational Edge：
汎用グラフィカルモデリング言語「SysML」 パート1： 要件、ユースケース、およびテストケースのモデリング
The Rational Edgeより：3回にわたってお送りする本シリーズの第1回では、まず製品・システム開発用の汎用グラフィカルモデリング言語であるSystems Modeling Language（SysML）の概要を説明する。パート1ではSysMLの要件、ユースケース、およびテストケースの各ダイヤグラムを解説する。（2006/9/22）

The Rational Edge：
ウォーターフォールから反復型への移行手順
The Rational Edgeより：さまざまな理由から、反復型アプローチに強い思い入れのあるソフトウェア開発者が、従来の「ウォーターフォール」方法論に根差したクライアントに対応しなくてはならないケースは頻繁にある。本稿は、Rational Unified Processへの移行でこのような組織を支援する方法について解説する。（2006/7/21）

The Rational Edge：
ソフトウェアアーキテクティングのメリット
The Rational Edgeより：シリーズ最後の4回目となる本稿では、企業やIT部門が安定したソフトウェアアーキテクチャから享受できるメリットについてPeter Eelesが解説する。（2006/6/21）

The Rational Edge：
ソフトウェアアーキテクティングのプロセス
The Rational Edgeより：ソフトウェアアーキテクティングは、ソフトウェア開発分野において最近その存在が認められた新しい学問だ。ソフトウェアアーキテクチャシリーズの第3回となる本稿では、ソフトウェアプロジェクトのライフサイクルにおいてソフトウェアアーキテクトが進める作業を説明する。（2006/6/14）

The Rational Edge：
ソフトウェアアーキテクトの役割
The Rational Edgeより：もし、ソフトウェアプロジェクトのマネジャーが映画業界用語でいう（作業完了の責任者である）プロデューサーならば、ソフトウェアアーキテクトは（作業を成功させ、最終的に利害関係者のニーズも満たす立場にある）監督だといえる。4回シリーズの2回目となる本稿では、ソフトウェアアーキテクトの役割について解説する。（2006/5/16）

The Rational Edge：
ソフトウェアアーキテクチャって何なの？（後編）
前編ではソフトウェアアーキテクチャの定義を詳細に解説した。わかっているようで実は意外とあいまいなままだったソフトウェアアーキテクチャの本質に少しは迫れたと思う。後編ではソフトウェアアーキテクチャの構造をさらに掘り下げる。（2006/3/24）

The Rational Edge：
ソフトウェアアーキテクチャって何なの？（前編）
The Rational Edgeより：ソフトウェアアーキテクチャという比較的新しい分野について概説する。今回はシリーズの第1弾という位置付け。この分野のキーワードを説明し、優れたデザインのアーキテクチャが、導入された環境にどのように寄与するのかを探っていく。（2006/3/17）

The Rational Edge：
ITプロジェクトを見える化する
本稿は、ITプロジェクトポートフォリオ管理（PPM）の上位レベルの概要を解説し、プロジェクト・ポートフォリオ管理ベンダ市場全体について考察する。その後、PPMインプリメンテーションの成功率を高め、このソリューションを最大限に活用するための手順の指針を示す。（2006/3/1）

The Rational Edge：
ユーザー要件を引出すテクニック： ユースケースかストーリーボードか
反復開発実践者の間では、ユーザー要件を引き出すテクニックとしてのユースケースとストーリーボードの利点に激しい議論が集中している。（2006/2/1）

The Rational Edge：
オブジェクト指向を超えて
The Rational Edgeより：元ソフトウェア開発者のGary Pollice教授は、オブジェクト指向の概念を最初から学ぶコンピュータサイエンスの学生は、構造化プログラミングテクニックが染み込んだプログラマーより、これらをソフトウェア開発プロジェクトに応用するときに苦労しないと指摘する。本稿では構造化とオブジェクト指向の考えを考察し、オブジェクト・ファーストの教授法のメリットを解説して、アスペクト指向のプログラミング手法が普及する中でのアスペクト・ファースト・アプローチへの移行の可能性を考えてみたい。（2005/11/12）

The Rational Edge：
ルネサンスの巨匠たちに学ぶエンジニアリングの技
The Rational Edgeより：このコラムでは、ルネサンスの偉大な芸術家たちの作品に対するアプローチと、偉大なソフトウェア開発者たちのアプローチをGary Polliceが比較する。（2005/9/23）

The Rational Edge：
ソフトウェア開発の「いま」と「近未来」の話
The Rational Edgeより：Rationalブランドを率いるゼネラルマネージャがMike Devlin氏からDanny Sabbah氏に交替したことを受け、Grady Boochが新旧両方のリーダーへソフトウェア開発分野の目標、業績、そしてビジョンについて話を聞いた。以下のインタビューは、IBMのソフトウェア開発ブランドであるRationalの歴史と未来を理解するうえでの手掛かりとなるだろう。（2005/8/10）

The Rational Edge：
中国のソフトウェア開発現場はこんなにスゴイ
The Rational Edgeより：ソフトウェア開発のアウトソーシング契約をめぐり、中国が欧米の強力なライバルになろうとしている。本稿は、中国政府（および同国の大学や企業）がどのように専門家を養成し、中国国内におけるソフトウェア開発手法の改善を進めているのかについて報告する。（2005/6/25）

The Rational Edge：
隣のテストチームが優秀ないくつかの理由（後編）
前編の内容：「隣のテストチームが優秀ないくつかの理由（前編）」では、優秀なテストチームを編成するために求められる人材の種類を考察した。要件に応じてさまざまなタイプの人材をうまく登用することが上手なチーム編成の決め手になる。後編では逆に、問題のあるスタッフのタイプをリストアップし、彼らをどうすれば“矯正”できるかを考える。そのうえで、テストチームにおけるマネージャの役割を考えてみよう。（2005/5/21）

The Rational Edge：
隣のテストチームが優秀ないくつかの理由（前編）
Rational Edgeより：ソフトウェア開発チームを編成するときの成功の秘訣は何だろうか？ スーパースターを採用するのではなく、多様な長所やスキルセットを持つメンバーを確保することだ、と本稿は断言する。本稿はプロジェクトやチームのマネージャのために、チームメンバーにとって望ましい特性や、監視や矯正の必要なチームメンバーの特徴について解説する。 （2005/5/18）