TOP
＞
プロジェクト管理
＞ SOA時代にむけて、品質の定義は変わった
SOAから品質向上へアプローチ
第１回：変わりゆく品質の定義
著者：
日本アイ・ビー・エム 藤井 智弘
2005/12/8
前のページ
1
2
3
4
次のページ
SOA時代にむけて、品質の定義は変わった
皆さんは品質という言葉を耳にした時に何が思い浮かびますか。大体は表2にあげるようなことではないでしょうか。
障害の数（期間当たり、SLOC当たり）
期間当たりの発生頻度・回収頻度
回収期間
変更要求
仕様変更
表2：品質といえば
と、いきなり総論から入っていますが、品質という局面が語られる場合、多くは開発という作業の成果物に焦点が当てられます。「同意された仕様を実現するのが開発」という暗黙の了解のもとで、障害とは「同意された仕様が実現されていない」ということを意味します。
コーディングのミスというミクロなところから、所定の入力に対して出力が不適切という「仕様」そのものまで、あらゆる粒度の不適切さが
「同意された仕様からはずれた障害」
として識別されます。
実は同意された仕様そのものが、よく変わるものということも事実です。要求変更は、当初予定されていたコスト／スケジュール／体制までも変えうる可能性があります。故に、これを管理するということが大変重要です（とはいうものの、要求定義と要求管理の違いがわからないプロジェクトが多いのも事実です）。
さらにもう1つ、昔からいわれ続けて、なお今になっても再評価されている品質とは、「そもそも仕様が適切なのか？」「システム自身の説明責任が果たせるか？」ということです。同意した仕様自体が変わるという現実が多くのプロジェクトを悩ませています。ですが、仕様通りにできれば問題は解決するのでしょうか。冒頭のことから明らかなのは、ITシステムとビジネスとの連携の度合いは深まる一方だということです。
SOA（Service Oriented Architecture）では、ビジネスプロセスを分解するトップダウンアプローチで、ITシステムのサービスを定義します。では、どの辺りをどのくらいの粒度でサービスとして構築すれば、効果が期待できるのでしょうか。今、問題を解決するために構築されたシステムが、その問題をきちんと解決するという品質が問われつつあるといえるでしょう。
図1：SOAの概念
SOA時代をにらんで変わるベストプラクティス
IBM Rationalでは、過去の経験則からより高品質のシステムを実現するための「ソフトウェア開発のベストプラクティス」を提唱しています。そのプラクティスも、ITシステムのビジネス上での位置づけの変更を受けて改訂されることになりました。いわば「SOA時代のベストプラクティス」といえます。
詳細を説明する前に、「SOA時代のソフトウェア開発は何が変わるのでしょうか。また、その中で品質向上のポイントや取り組みはどう変わるべきなのでしょうか」ということについて考えてみましょう。
様々なタイプのプロジェクト形態が、企業（グループ）内で混在する
SOAに限った話ではありませんが、開発プロジェクトの形態が多岐にわたり、かつ普遍化されています。
開発規模の違い
拠点のグローバル化やオフショア開発などによる、地理的に分散した開発
ゼロからのスクラッチ開発あるいは再利用をベースとした開発、パッケージのカスタマイズを主体とする開発
RFIDに代表される、ハードとソフトの連携を軸にした開発
表3：開発プロジェクトの形態
これまでのシステムの構造は、俗に「マスター」と称されるデータベースを土台に、個々のシステムが独立して構築される"ストーブパイプ"型が中心でした。SOAでは、これらのシステム自体が外部にサービスを公開する「協調型」になります。これまで以上に、連携方法を含めたプロジェクト間の情報の共有が重要になってきます。
図2：既存の開発スタイルからSOA型へ
前のページ
1
2
3
4
次のページ
著者プロフィール
日本アイ・ビー・エム 藤井 智弘
日本アイビーエム株式会社ソフトウェア事業所属
品質向上への取り組みが、いま改めて真剣さをもって行われていることをよい傾向と思いつつも、やはり未だにテスト工程にのみ多くの関心が集まっているのを見るにつけ、「ちょっと違うんじゃぁないか？」と思ったりする、あまのじゃくの42歳。
INDEX
第1回：変わりゆく品質の定義
泣く子と悪い品質には勝てない
SOA時代にむけて、品質の定義は変わった
個別のアーキテクチャの設計から個別へのアーキテクチャの徹底
利害関係者の優先度のバランス（Balance stakeholder priorities）
