The Rational Edge

＜バックナンバー＞

アジャイルとシステムテストの新たな関係（後編）
The Rational Edge　IBMにおけるアジャイルシステムテストの試みでは、いくつかの課題点も残った。しかし、正式のシステムテスト作業には極めて良い効果をもたらした

アーキテクチャ 2008/7/1

アジャイルとシステムテストの新たな関係（前編）
The Rational Edge　アジャイル開発プロセスにシステムテストのサブセットを含めることにより、品質改善が期待できる。実際にIBMでこの手法を試行した事例を紹介する

アーキテクチャ 2008/6/24

アジャイル開発の広範な普及を目指して
The Rational Edge　アジャイル開発手法は一部のプロジェクトで確実に効果を上げているが、まだ広く普及しているとはいえない。何がアジャイルの普及を妨げているのか

アーキテクチャ 2008/5/8

見積もりの精度 Accuracy of Estimation
The Rational Edge　心臓が最もドキドキするのはいつですか。たぶん、担当者が予測した予算、人員配備、納期に基づいてプロジェクトが最終承認されたときでしょ

プロジェクト管理 2008/3/6

ソフトウェアの複雑性を手なずける
The Rational Edge　複雑性を打破することはできなくても、懸命の努力を継続する必要はある。ここでは、重要なテクニックをいくつか紹介する

アーキテクチャ 2008/1/15

ソフトウェアが複雑なのは仕方がない？
The Rational Edge　ソフトウェアシステムの複雑性は避けられないが、手に負えないものではない。アーキテクチャやチーム組織の立場からソフトウェアの複雑性を分析する

アーキテクチャ 2008/1/10

鈍重な開発チームは鈍重なシステムを作る？
The Rational Edge　Conwayの法則は「どのソフトウェアも、それを作り出した団体の組織構造を反映している」としている。チームの性質と成果物には密接な関係がある

プロジェクト管理 2007/11/20

人事評価と開発者のモチベーション
The Rational Edge　社員の奨励金や報奨金、昇進、そして責務といった人事関連の問題がソフトウェア開発プロジェクトに及ぼす影響を無視してはいけない

プロジェクト管理 2007/11/15

自己管理型チームの利点と弱点
The Rational Edge　次世代の開発チームの姿が「自己管理型チーム」だ。そこでは誰が責任を持ち、誰が権限を持ち、誰に報告すべきなのか？利点と弱点を探る

プロジェクト管理 2007/11/13

プロセスはチャンスが訪れるたびに改善する
The Rational Edge　導入した開発プロセスの継続的なサポートと、コンプライアンスについて解説する。導入した後の継続的なメンテナンスがプロジェクトの成否を分ける

プロジェクト管理 2007/11/1

開発プロセス導入のアンチパターン
The Rational Edge　開発プロセスとプロジェクトの性質について解説する。当たり前のことだが、「開発プロセス」を導入すればプロジェクトが成功するわけではない

プロジェクト管理 2007/10/30

反復開発の「ここはぜひカバーしたいポイント」
The Rational Edge　既存の開発プロセスから反復開発プロセスへ移行する段階では、いくつかのトレードオフが発生する。これらの要注意点をあらかじめおさえておこう

プロジェクト管理 2007/10/25

開発プロジェクト「統治」のピンポイント解説
The Rational Edge　前編ではいくつかの開発プロジェクト・ガバナンス手法を紹介した。後編ではプロジェクト「統治」のための具体的な方法を、段階を踏みながら解説する

プロジェクト管理 2007/10/2

開発プロジェクトを「統治」するベストプラクティス
The Rational Edge　メンバーにそれとなく権限を与え、やる気にさせるよう努める協調戦略に重点を置くこと。それが効率的な開発プロジェクト・ガバナンス手法の共通点だ

プロジェクト管理 2007/9/27

初歩の「Perl」「Python」「Ruby」
The Rational Edge　今日使われている中で最も人気の高い3つのプログラミング言語を解説する。Perl、Python、そしてRubyだ。え、まさか知らないなんてことはないよね

アーキテクチャ 2007/8/28

不完全なコードは推敲フェイズで潰しておきたい
The Rational Edge　推敲フェイズの最大の目的は技術リスクの削減だ。このフェイズにおける評価値は、技術的なリスクが低下するかどうかの判断に重点が置かれる

プロジェクト管理 2007/7/19

そうだったのか！システムユースケース
The Rational Edge　ビジネスモデリングとの相違点を明らかにすることで、システムモデリングの意味とその具体的な方法が浮き彫りになる

アーキテクチャ 2007/5/24

なるほど！ビジネスユースケース
The Rational Edge　ユースケースに焦点を絞って、ビジネスモデリングとシステムモデリングの関係を明らかにする。前編では類似点の指摘に主眼を置く

アーキテクチャ 2007/5/22

「この開発プロジェクトは中止！」の基準
The Rational Edge　失敗することがわかっている計画なら途中で中止にした方がいい。しかし、プロジェクトが巨大になればなるほど、途中で止めることは難しいのだ

プロジェクト管理 2007/4/24

プロジェクトのはじめに計画を立てるのは無謀
The Rational Edge　最初に計画を立てるのはちょっと待って欲しい。開発プロジェクトはどんどん変わっていく。現実に沿わない計画をゴリ押しするのはとても危険だ

プロジェクト管理 2007/4/19

専門家に聞くモデル駆動開発のメカニズム
The Rational Edge　WebSphereコンサルタントのChris Gerken氏がモデル駆動開発（MDD）や、実行イメージパターン、Java Emitter Templates（JET）について解説

アーキテクチャ 2007/3/15

「設計」や「構築」よりも重宝されるスキル
The Rational Edge　「設計」「構築」などと呼ばれていたものを拡張する動きがIBMにある。「設計」「構築」という個別のスキルよりも重宝されることになりそうだ

アーキテクチャ 2007/2/13

キミのコードが汚い理由
The Rational Edge　汚い、もしくは粗雑なコードができるには理由がある。もちろん、改善する方法もきちんとある。できればエレガントなコードを書きたいと思わないか？

アーキテクチャ 2007/1/12

グラフィカルなモデル言語で製品構造を記述
The Rational Edge　製品・システム開発用の汎用グラフィカルモデリング言語「SysML」入門2回目の今回は、SysMLのストラクチャダイヤグラムを解説する

アーキテクチャ 2006/11/15

汎用グラフィカルモデリング言語「SysML」パート1
The Rational Edge　製品・システム開発用の汎用グラフィカルモデリング言語であるSystems Modeling Language（SysML）の概要を説明する

アーキテクチャ 2006/9/22

トランザクション管理の複雑性を克服するパート2
The Rational Edge　パート2では、筆者がJavaで書いたサンプルコードを含むTCSのプロトタイプデザインを紹介する。Webサービスとして公開も可能だ

アーキテクチャ 2006/8/25

トランザクション管理の複雑性を克服するパート1
The Rational Edge　SOA全体で首尾一貫した分散トランザクションを管理するため、トランザクション・コーディネーションサービスをデザインする

アーキテクチャ 2006/8/23

ウォーターフォールから反復型への移行手順
The Rational Edge　反復型アプローチに思い入れのある開発者が、ウォーターフォールに根差したクライアントに対応しなくてはならないケースは意外と頻繁にある

アーキテクチャ 2006/7/21

ソフトウェアアーキテクティングのメリット
The Rational Edge　企業やIT部門が安定したソフトウェアアーキテクチャから享受できるメリットについて説明する。よいアーキテクティングはシステム品質を向上させる

アーキテクチャ 2006/6/21

ソフトウェアアーキテクティングのプロセス
The Rational Edge　今回はアーキテクトの話を土台にし、ソフトウェアアーキテクティングのプロセスの根底にあるテーマ、あるいは特性を詳細に検討する

アーキテクチャ 2006/6/14

ソフトウェアアーキテクトの役割
The Rational Edge　もし、ソフトウェアプロジェクトのマネジャーが映画業界用語でいうプロデューサーならば、ソフトウェアアーキテクトは監督だといえる

アーキテクチャ 2006/5/19

ソフトウェアアーキテクチャって何なの？（後編）
The Rational Edge　ソフトウェアアーキテクチャとは何なのか。アーキテクチャとは構造を定義するものである。そして、ソフトウェアの動作を定義するのもアーキテクチャだ

アーキテクチャ 2006/3/24

ソフトウェアアーキテクチャって何なの？（前編）
The Rational Edge　ソフトウェアアーキテクチャをきちんと定義することは、実は意外とされていない。本稿の定義を参考に改めてアーキテクチャというものを考え直してみては？

アーキテクチャ 2006/3/17

ITプロジェクトを見える化する
The Rational Edge　IT部門は社内プロセスを構築し、数値化できる結果を出す必要がある。ポートフォリオの概念を持ち込むことでプロジェクトの見える化が実現するのだ

プロジェクト管理 2006/3/1

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

アーキテクチャ 2006/2/1

オブジェクト指向を超えて
The Rational Edge　アスペクト指向のプログラミング手法が普及する中でのアスペクト・ファースト・アプローチへの移行の可能性を考えてみたい

「IT Architect」フォーラム 2005/11/25

ルネサンスの巨匠たちに学ぶエンジニアリングの技
The Rational Edge　偉大な絵画の多くはチーム作業の成果だ。師匠がデザインを描き、重要な部分を塗る。そして、熟練労働者や見習いが残りの作業を分担した

「IT Architect」フォーラム 2005/9/23

ソフトウェア開発の「いま」と「近未来」の話
The Rational Edge　IBMフェローのGrady Boochが、IBMのソフトウェア開発分野における目標、業績、そしてビジョンについて新旧両方のリーダーに話を聞いた

「IT Architect」フォーラム 2005/8/10

中国のソフトウェア開発現場はこんなにスゴイ
The Rational Edge　中国政府はどのように専門家を養成し、いかにして中国国内におけるソフトウェア開発手法の改善を進めているのか。その秘密の一端を明らかにする

「IT Architect」フォーラム 2005/6/25

隣のテストチームが優秀ないくつかの理由（後編）
The Rational Edge　問題のあるスタッフのタイプをリストアップし、どうすれば“矯正”できるかを考える。そのうえで、テストチームにおけるマネージャの役割を検討する

「IT Architect」フォーラム 2005/5/21

隣のテストチームが優秀ないくつかの理由（前編）
The Rational Edge　テストチームを編成するときの成功の秘訣とは？スーパースターはいらない。多様な長所やスキルセットを持つほどほどのメンバーが必要なのだ

「IT Architect」フォーラム 2005/5/18

コーディングの知恵を要件定義で利用する
The Rational Edge　コードを書くときにいつも使っている「原則」や「概念」を用いることで、優れた要件を作成することができる。その具体的な適用方法を紹介する

「IT Architect」フォーラム 2005/2/23

UML 2.0のキホン：コンポーネント図の詳細解説
The Rational Edge　UML 2.0では、コンポーネントという概念の本来的な意味が（UML 1.1に比べて）完全に変わってしまっている。しかもより重要な方向に

「IT Architect」フォーラム 2005/2/2

アジャイル開発：成熟期の到来、その道のり
The Rational Edge （30）　アジャイルカンファレンスの参加者の状況、セッションの内容、議論の変化に焦点を当て、アジャイルソフトウェア開発プロセスの成長と発展を振り返る

「IT Architect」フォーラム 2004/11/25

大規模プロジェクトにアジャイルを適用する方法（後編）
[The Rational Edge]　大規模システム開発にアジャイル開発手法を導入するにはいくつかのリスクを回避しなければならない。例えば「コミュニケーションの崩壊」などだ

「IT Architect」フォーラム 2004/10/1

大規模プロジェクトにアジャイルを適用する方法（前編）
The Rational Edge 通常ならアジリティの範囲を超えると見なされる大規模プロジェクトに、アジャイルソフトウェア開発手法を適用するテクニックを説明する

「IT Architect」フォーラム 2004/9/29

「プロジェクト管理」を管理するために
The Rational Edge （25）　多くのプロジェクトが並行して進行する巨大なプロジェクトをここではプログラムと呼ぶ。プロジェクト管理よりもさらに煩雑なプログラム管理とは？

「IT Architect」フォーラム 2004/6/25

アスペクト指向プログラミングオーバービュー
The Rational Edge （24）　IT業界はソフトウェア構築アプローチの改良の歴史でもある。このラインアップに最近加わったのが、アスペクト指向プログラミングだ

「IT Architect」フォーラム 2004/4/13

サブシステムとはモデリング概念である
The Rational Edge （23）　サブシステムをうまく活用すれば、置換可能な実装、抽象化レベルの向上、より容易な再利用、並行開発などが可能になるのだ

「IT Architect」フォーラム 2004/3/5

サブシステムの「なに？」「なぜ？」「どうやって？」
The Rational Edge （22）　「サブシステム」という概念が開発現場に普及しているとはいえない。しかし、サブシステムを熟知することはうまい設計を実現する近道なのである

「IT Architect」フォーラム 2004/2/14

『オープン』の正体（後編）
[The Rational Edge]　「『オープン』の正体（前編）」では、その歴史的背景や類型の整理を行った。後編では、『オープン』概念の現状分析および今後の課題を考察する

「IT Architect」フォーラム 2003/10/22

『オープン』の正体（前編）
[The Rational Edge]　今日、「オープン」という概念がIT業界に与える影響を無視することはできない。本記事はオープン・ソース・ソフトウェアの役割について考察していく

「IT Architect」フォーラム 2003/9/25

オープンソース時代のテスト手法、テストのまとめ
[The Rational Edge]　オープンソース時代のテスト手法のまとめを行う。ポイントは、システム内部と外部の境界を考え、全体の機能拡張を考慮しているか否か、にある

「IT Architect」フォーラム 2003/7/29

オープンソース時代のテスト手法、テストのロードマップ
[The Rational Edge]　テストのタイプは9種類ある。実施する順番はケースバイケースだが、まず最初に行うべきなのは「スモークテスト」であることを覚えておいて欲しい

「IT Architect」フォーラム 2003/6/17

オープンソース時代のテスト手法、そのノウハウ
[The Rational Edge]　いくつかのソフトウェアを統合した結果、その“境界”ではさまざまな問題が発生する。いつ、どのように、どこからテストを始めればいいのか？

「IT Architect」フォーラム 2003/5/9

オン・デマンドの波をキャッチしろ
[The Rational Edge]　システムと開発チームは新しいアプローチによって構築し直されるべきである。オン・デマンド・コンピューティングがその鍵を握る

「IT Architect」フォーラム 2003/4/5

要件定義の管理技術（Lv0～Lv5）
[The Rational Edge]　要件定義の管理技術を習得することははっきりいって簡単なことではない。それゆえ、段階的に進めていくことをおすすめする。Lv5までの道は遠い

「IT Architect」フォーラム 2003/3/13

開発計画が破たんするには理由がある
[The Rational Edge]　プロジェクトが破たんするには理由がある。現代の複雑かつ大規模な開発プロジェクトはあらかじめ失敗を想定して組み立てられているのだろうか？

「IT Architect」フォーラム 2003/2/25

チェスとソフト開発、その相関関係を探る
[The Rational Edge]　ソフトウェア開発を建築に例える話はもう聞き飽きた？ではチェスならどうだろう。実は、チェスほどソフトウェア開発と似ているゲームはないのだ

「IT Architect」フォーラム 2003/1/17

要件定義の考古学
[The Rational Edge]　要件定義。それは、レガシーシステムをよみがえらせる鍵にもなる。失われた遺産を分析する作業はまさに、考古学の方法論と同じなのである

「IT Architect」フォーラム 2002/12/26

Webサービスのテスト技法進化論
[The Rational Edge]　今回のThe Rational Edgeでは、進化し続けるWebサービスの近未来の姿を段階的に予測し、それぞれで最適なテスト技法を模索する

「IT Architect」フォーラム 2002/11/19

Dr.ユースケースの “ユースケース人生相談”
[The Rational Edge]　ユースケースが持つファンクションポイント数を予測し、開発規模を見通すよい方法はあるのだろうか？ Dr.ユースケースが明快な論理で分かりやすく解説

「IT Architect」フォーラム 2002/10/19

「アジャイル」「RUP」「Rational XDE」の融合
[The Rational Edge]　アジャイルとはテクニックや方法論ではなく、姿勢であり、哲学である。XDEを活用することで、RUPもアジャイルな「方法論」へと変貌する

「IT Architect」フォーラム 2002/10/10

優秀なテスターの育成と訓練方法
[The Rational Edge]　フロリダ工科大学のコンピュータサイエンス教授Cem Kaner氏が、優秀なテスター育成のための秘密やテスト技法に関する持論を語る

「IT Architect」フォーラム 2002/9/14

プロジェクトの特性に合わせた要件定義手法の選択
[The Rational Edge]　ソフトウェアの開発プロセスは、プロジェクトの特性に合わせて選択をしなくてはならない。今回はそのコツを伝授しよう

「IT Architect」フォーラム 2002/8/10

分散コンピューティング時代のテスト手法
[The Rational Edge]　C/S全盛時のテスト手法はすでに時代遅れとなってしまった。今回は分散コンピューティング時代のテスト手法を紹介する

「IT Architect」フォーラム 2002/7/20

プロダクト・マネジメントを成功に導くには
[The Rational Edge]　あるソフトウェアの成功の裏には必ず優秀なプロダクト・マネージャの存在がある。その役割と活動の詳細をお届けする

「IT Architect」フォーラム 2002/6/19

ソフト開発の変革というWebサービスの可能性
[The Rational Edge]　Webサービスのもう１つの大きな可能性は、ソフトウェア開発にサービス指向というアプローチをもたらすことだ。サービス指向実現の7つの原則とは何か？

「IT Architect」フォーラム 2002/5/2

あるプロジェクトリーダーの成功ストーリー
[The Rational Edge]　たった1人で行った成功プロジェクトの1週間を振りかえる日記を通して、ラショナル統一プロセスのポイントをわかりやすく紹介する

「IT Architect」フォーラム 2002/4/13

先駆者に学ぶ「開発プロセス改善の原則」
[The Rational Edge]　ソフトウェア開発を成功に導くための開発プロセスの変革が注目されている。先駆者が経験した開発プロセスの改善は、組織の改善からスタートした

「IT Architect」フォーラム 2002/2/23

要件仕様の決定に時間を割かない結末は？
[The Rational Edge]　「要求仕様をまとめる時間がない！」などの理由でプロジェクトを進める結末は？…プロジェクトマネージャ、SEに贈る開発スタイル改善の提言

「IT Architect」フォーラム 2002/1/22

ホワイトペーパー（TechTargetジャパン）

アーキテクチャ新着記事

＠IT情報マネジメントメールマガジン　情報マネージャのための情報源（無料）

＠IT情報マネジメント新着記事

この記事に対するご意見をお寄せください　managemail@atmarkit.co.jp

キャリアアップ

＠IT Sepcial

＠IT情報マネジメント Special ヘ

イベントカレンダー

PickUpイベント

- PR -

アクセスランキング

転職／派遣情報を探す

エンジニアの求人情報、ただいま増加中
【転職サーチ】SIer／Web企業／新規事業
スマホ開発で、あなたのキャリアを生かす

派遣エンジニアにお役立ちの仕事情報
「派遣・フリーで働くメリット」とは？
活躍する派遣エンジニアの本音

エンジニアのキャリア実現を応援します

ITトレメ「ビジネス基礎」シリーズ開始
「マナー＆コミュニケーション編」「法律・知財・債権管理編」

＊先週の人気講座ランキング＊
～ Android編～

TechTargetジャパン

＠IT Sepcial

＠IT情報マネジメント Special ヘ

ソリューションFLASH

求人情報

＠IT情報マネジメントトップ｜アーキテクチャトップ｜会議室｜利用規約｜プライバシーポリシー｜サイトマップ

Copyright(c) 2000-2012 ITmedia Inc.
著作権はアイティメディア株式会社またはその記事の筆者に属します。（著作権について）
当サイトに掲載されている記事や画像などの無断転載を禁止します。
「＠IT」「＠IT自分戦略研究所」「＠IT情報マネジメント」「JOB＠IT」「＠ITハイブックス」「ITmedia」は、アイティメディア株式会社の登録商標です。
当サイトに関するお問い合わせは「＠ITへのお問い合わせ」をご覧ください。