|
ソフトウェア開発の管理は、従来から、品質Ｑ（Ｑｕａｌｉｔｙ）、コストＣ （Ｃｏｓｔ）、納期Ｄ（Ｄｅｌｉｖｅｒｙ）のＱＣＤの視点から行われてきた。 しかし、エンドユーザー、ＩＴベンダー、ソフトウエア開発会社（コーディング 実装）の立場の違いによって、品質の評価基準が異なり、コミュニケーション ギャップによる無駄なコストが生じている。 私が経験したコミュニケーションギャップの例をここで１つ取り上げる。その 案件において、エンドユーザーのITインフラ環境はＷｉｎｄｏｗｓであり、この 環境に適合するアプリケーションの開発が要求された。この要求に基づいてエン ドユーザーと開発側の間では Microsoft Visual Studioによる開発、期間は半年 と合意された。しかし３ヵ月後のある日、ベンダーがその案件のプロジェクトマ ネジャー（ＰＭ）を更迭し、他の担当者を新ＰＭとして据えた。新ＰＭは開発中 のシステムが品質標準を満たしていないと主張し、開発の変更を要求した。 開発中のシステム全体がユーザーの他のプロジェクトに横展開することができ ずMicrosoft Officeのように何処でも使えるようになっていないことが指摘され た。即ち、ISO/IEC 9216, JIS X 0129で定められる「移植性」を満たしていなか ったことだった。当時のソフトウエア開発会社（コーディング実装）の担当者は、 メンテナンス性を考慮し、システムをＳＯＡの設計に沿って作り上げたこともあ って、表面上では確かに他のところに移植することも可能である。しかし、ＩＴ ベンダーの仕様通り、差別化するために、特徴のあるユーザインターフェースを 作り上げたため、システム全体をそのまま移植することができなかった。新任Ｐ Ｍは能力が高く、システムの再利用性（移植性）の重要性をよく知っているため、 最大限にコストパフォーマンスを上げたいと感じた。ソフトウエア開発会社（コ ーディング実装）側では、何処でも使えるようにするのは、３ヶ月の期間では無 理であり、最初決めた開発の範囲と目的とも異なると主張し、新任ＰＭに、発注 仕様書、変更管理記録、ユーザーとＩＴベンダーとの仕様に関する議事録などを 開示した。そこにはシステム全体の移植に関する要求は記載されていなかった。 このため、新任ＰＭは移植性についての要求を取り下げた。 このケースでは、新ＰＭがＱＣＤのＱ（品質）のみを求めてしまった結果、チ ーム内で摩擦が生じ、ユーザーと既に合意した文書をもう一度開示するコストが 余分に生じてしまった。もし、ソフトウエア開発会社（コーディング実装）が新 任ＰＭの要求に応じていたら、期日とおりに納品できない失敗プロジェクトとな り、品質どころではなくなっていた。 品質だけを求めるケースは決して少なくない。その結果、一部の開発範囲が膨 らんで全体の開発に影響しているケースはよく耳にする。１年前、あるＳＩ企業 の取締役から私に相談があった。彼の会社の開発担当者が開発途中でユーザーの 変更要求をすべて受け入れ、開発範囲を極端に膨張させてしまったため、大幅な 予算超過が見込まれるとのことであった。下請け会社であるため、元請けの担当 者の要求に対して「はい」としか言えず、無条件にすべての要求を受けてしまっ たのであった。この結果、開発範囲が強引に拡大され、元々予定していた体制で は到底対応できず、ＳＩ企業の経営を圧迫する結果となった。 世界各国でよく使用されているプロジェクトマネジメントガイドＰＭＢＯＫの 第４版においては、品質（Ｑ）、コスト（Ｃ）、納期（Ｄ）という３要素を、範 囲（Ｓｃｏｐｅ）、コスト（Ｃ）、時間（Ｄ）およびこれらに基づく品質（Ｑ） のＳＣＤ＋Ｑに置き換えている。エンドユーザー、ベンダー、開発者間で、常に ＳＣＤ＋Ｑを元に全体最適を図る意識を共有することによって、プロジェクトの 成功を目指し、互いに協力できる体制を作ることができると考えられる。 ■執筆者プロフィール 氏名 ：戴 春莉(たい しゅんり)／情報システム監査士 得意分野 ：デザインの手法を情報処理技術への応用、上流工程の要求分析、 問題デザインと可視化など メールアドレス：dai-jp@leto.eonet.co.jp |
コメントをお書きください