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