視点の共有によるソフトウェア品質の維持/戴 春莉

 ソフトウェア開発の管理は、従来から、品質Q(Quality)、コストC
(Cost)、納期D(Delivery)のQCDの視点から行われてきた。
しかし、エンドユーザー、ITベンダー、ソフトウエア開発会社(コーディング
実装)の立場の違いによって、品質の評価基準が異なり、コミュニケーション
ギャップによる無駄なコストが生じている。

 私が経験したコミュニケーションギャップの例をここで1つ取り上げる。その
案件において、エンドユーザーのITインフラ環境はWindowsであり、この
環境に適合するアプリケーションの開発が要求された。この要求に基づいてエン
ドユーザーと開発側の間では Microsoft Visual Studioによる開発、期間は半年
と合意された。しかし3ヵ月後のある日、ベンダーがその案件のプロジェクトマ
ネジャー(PM)を更迭し、他の担当者を新PMとして据えた。新PMは開発中
のシステムが品質標準を満たしていないと主張し、開発の変更を要求した。
 開発中のシステム全体がユーザーの他のプロジェクトに横展開することができ
ずMicrosoft Officeのように何処でも使えるようになっていないことが指摘され
た。即ち、ISO/IEC 9216, JIS X 0129で定められる「移植性」を満たしていなか
ったことだった。当時のソフトウエア開発会社(コーディング実装)の担当者は、
メンテナンス性を考慮し、システムをSOAの設計に沿って作り上げたこともあ
って、表面上では確かに他のところに移植することも可能である。しかし、IT
ベンダーの仕様通り、差別化するために、特徴のあるユーザインターフェースを
作り上げたため、システム全体をそのまま移植することができなかった。新任P
Mは能力が高く、システムの再利用性(移植性)の重要性をよく知っているため、
最大限にコストパフォーマンスを上げたいと感じた。ソフトウエア開発会社(コ
ーディング実装)側では、何処でも使えるようにするのは、3ヶ月の期間では無
理であり、最初決めた開発の範囲と目的とも異なると主張し、新任PMに、発注
仕様書、変更管理記録、ユーザーとITベンダーとの仕様に関する議事録などを
開示した。そこにはシステム全体の移植に関する要求は記載されていなかった。
このため、新任PMは移植性についての要求を取り下げた。
 このケースでは、新PMがQCDのQ(品質)のみを求めてしまった結果、チ
ーム内で摩擦が生じ、ユーザーと既に合意した文書をもう一度開示するコストが
余分に生じてしまった。もし、ソフトウエア開発会社(コーディング実装)が新
任PMの要求に応じていたら、期日とおりに納品できない失敗プロジェクトとな
り、品質どころではなくなっていた。

 品質だけを求めるケースは決して少なくない。その結果、一部の開発範囲が膨
らんで全体の開発に影響しているケースはよく耳にする。1年前、あるSI企業
の取締役から私に相談があった。彼の会社の開発担当者が開発途中でユーザーの
変更要求をすべて受け入れ、開発範囲を極端に膨張させてしまったため、大幅な
予算超過が見込まれるとのことであった。下請け会社であるため、元請けの担当
者の要求に対して「はい」としか言えず、無条件にすべての要求を受けてしまっ
たのであった。この結果、開発範囲が強引に拡大され、元々予定していた体制で
は到底対応できず、SI企業の経営を圧迫する結果となった。

 世界各国でよく使用されているプロジェクトマネジメントガイドPMBOKの
第4版においては、品質(Q)、コスト(C)、納期(D)という3要素を、範
囲(Scope)、コスト(C)、時間(D)およびこれらに基づく品質(Q)
のSCD+Qに置き換えている。エンドユーザー、ベンダー、開発者間で、常に
SCD+Qを元に全体最適を図る意識を共有することによって、プロジェクトの
成功を目指し、互いに協力できる体制を作ることができると考えられる。


■執筆者プロフィール

氏名     :戴 春莉(たい しゅんり)/情報システム監査士
得意分野   :デザインの手法を情報処理技術への応用、上流工程の要求分析、
        問題デザインと可視化など
メールアドレス:dai-jp@leto.eonet.co.jp


 

 

公式Facebookページはこちらから

<いいね>をクリック!