
2007/2/14
◆ ソフトウェアシステム全体の管理
- - PR -
先ごろ、IT部門を担当するある会社のバイスプレジデントから次のような感想が出てきた。「われわれはもはや、従来の感覚でソフトウェアを開発しているとはいえない。新しい要件は、パッケージアプリケーションや既存コンポーネントの統合によってすべて満たされている。カスタムソフトウェアの開発が必要になると、通常は社内の開発や導入コストを抑える目的からこれを外注してしまう。
これは、IT幹部が直面する新たな現実と、ITの現場における新しいパラダイムシフトを反映している。いまのIT専門家は、2つのことを意識しなくてはならない。1つは、新旧両方の技術を理解することであり、もう1つは、技術の事業価値と、組織をどのようにして競争上優位に立たせるのかを理解することだ。
本記事は、IBM developerWorksからアットマーク・アイティが許諾を得て翻訳、転載したものです。 |
現在のIT幹部の間では、自社のレガシー環境にパッケージアプリケーションを統合することに対する懸念がますます高まっている。それは、ゼロからソフトウェアプログラムを開発する以上に大きな問題だ。SOAの台頭は、IT専門家が直面する役割、責務、そして課題の変化に「再利用可能なコンポーネント」が与える影響の好例だ。ITのプロには、「実践的」科学技術者であることだけでなく、レガシーコード、既製パッケージ、社内開発コードまでも含むソフトウェアシステム全体の相互関係を管理できる管理者であることも期待されている。この点において、今日のIT専門家には、ソフトウェアの設計や構築よりも、エンドユーザーに提供されるソフトウェアシステム全体を管理することが求められている。
ビジネスでは、予算の正当化をめぐってIT幹部らが重責のある立場に置かれることが頻繁にある。作りさえすれば買うといった、制約を受けずに何でも要求できて自由裁量権のあった時代はもう終わった。むしろ、「このソフトウェアアプリケーションはどうやって会社のビジネスニーズ解決を支援してくれるのか?」「アプリケーションが適切に設計および開発されていることをそもそもどうやって確認するのか?」「アプリケーションの投資回収率はどの程度なのか?」など、ソフトウェア開発者には厳しい質問が投げかけられ、その責任が問われている。
本稿では、IT幹部や設計者がこれらの疑問に答え、変化する業務要件をあらゆるレベルでサポートすべく自社の準備を整える、IBM Rationalの「アーキテクチャ管理」に対する新戦略を紹介する。
「設計」や「構築」よりも重宝されるスキル
| Page1 ソフトウェアシステム全体の管理 |
|
| Page2 新しいITの現実に対応したアーキテクチャ管理 |
|
| Page3 アーキテクチャ管理はどのような影響を与えるのか? |
The Rational Edge バックナンバー 連載インデックスへ»
- 第1回 要件仕様の決定に時間を割かない結末は?
- 第2回 先駆者に学ぶ「開発プロセス改善の原則」
- 第3回 あるプロジェクトリーダーの成功ストーリー
- 第4回 ソフト開発の変革というWebサービスの可能性
- 第5回 プロダクト・マネジメントを成功に導くには
- 第6回 分散コンピューティング時代のテスト手法
- 第7回 プロジェクトの特性に合わせた要件定義手法の選択
- 第8回 優秀なテスターの育成と訓練方法
- 第9回 「アジャイル」「RUP」「Rational XDE」の融合
- 第10回 Dr.ユースケースの “ユースケース人生相談”
- 第11回 Webサービスのテスト技法進化論
- 第12回 要件定義の考古学
- 第13回 チェスとソフト開発、その相関関係を探る
- 第14回 開発計画が破たんするには理由がある
- 第15回 要件定義の管理技術(Lv0〜Lv5)
- 第16回 オン・デマンドの波をキャッチしろ
- 第17回 オープンソース時代のテスト手法、そのノウハウ
- 第18回 オープンソース時代のテスト手法、テストのロードマップ
- 第19回 オープンソース時代のテスト手法、テストのまとめ
- 第20回 『オープン』の正体 (前編)
- 第21回 『オープン』の正体 (後編)
- 第22回 サブシステムの「なに?」「なぜ?」「どうやって?」
- 第23回 サブシステムとはモデリング概念である
- 第24回 アスペクト指向プログラミング オーバービュー
- 第25回 「プロジェクト管理」を管理するために
- 第26回 レッスン1:何もせずに取り残されるな
- 第27回 レッスン3:相違に注意を払え
- 第28回 大規模プロジェクトにアジャイルを適用する方法(前編)
- 第29回 大規模プロジェクトにアジャイルを適用する方法(後編)
- 第30回 アジャイル開発:成熟期の到来、その道のり
- 第31回 UML 2.0のキホン:コンポーネント図の詳細解説
- 第32回 コーディングの知恵を要件定義で利用する
- 第33回 隣のテストチームが優秀ないくつかの理由(前編)
- 第34回 隣のテストチームが優秀ないくつかの理由(後編)
- 第35回 中国のソフトウェア開発現場はこんなにスゴイ
- 第36回 ソフトウェア開発の「いま」と「近未来」の話
- 第37回 ルネサンスの巨匠たちに学ぶエンジニアリングの技
- 第38回 オブジェクト指向を超えて
- 第39回 ユーザー要件を引出すテクニック
- 第40回 ITプロジェクトを見える化する
- 第41回 ソフトウェアアーキテクチャって何なの?(前編)
- 第42回 ソフトウェアアーキテクチャって何なの?(後編)
- 第43回 ソフトウェアアーキテクトの役割
- 第44回 ソフトウェアアーキテクティングのプロセス
- 第45回 ソフトウェアアーキテクティングのメリット
- 第46回 ウォーターフォールから反復型への移行手順
- 第47回 トランザクション管理の複雑性を克服する パート1
- 第48回 トランザクション管理の複雑性を克服する パート2
- 第49回 汎用グラフィカルモデリング言語「SysML」 パート1
- 第50回 グラフィカルなモデル言語で製品構造を記述
- 第51回 キミのコードが汚い理由
- 第52回 「設計」や「構築」よりも重宝されるスキル
- 第53回 専門家に聞くモデル駆動開発のメカニズム
- 第54回 プロジェクトのはじめに計画を立てるのは無謀
- 第55回 「この開発プロジェクトは中止!」の基準
- 第56回 なるほど! ビジネスユースケース
- 第57回 そうだったのか! システムユースケース
- 第58回 不完全なコードは推敲フェイズで潰しておきたい
- 第59回 ビルドが全滅する原因
- 第60回 初歩の「Perl」「Python」「Ruby」
- 第61回 開発プロジェクトを「統治」するベストプラクティス
- 第62回 開発プロジェクト「統治」のピンポイント解説
- 第63回 反復開発の「ここはぜひカバーしたいポイント」
- 第64回 開発プロセス導入のアンチパターン
- 第65回 プロセスはチャンスが訪れるたびに改善する
- 第66回 自己管理型チームの利点と弱点
- 第67回 人事評価と開発者のモチベーション
- 第68回 鈍重な開発チームは鈍重なシステムを作る?
- 第69回 ソフトウェアが複雑なのは仕方がない?
- 第70回 ソフトウェアの複雑性を手なずける
- 第71回 見積もりの精度 Accuracy of Estimation
- 第72回 アジャイル開発の広範な普及を目指して
- 第73回 アジャイルとシステムテストの新たな関係(前編)
- 第74回 アジャイルとシステムテストの新たな関係(後編)
ホワイトペーパー(TechTargetジャパン)
|
|

