« 2005年7月1日 都市戦略について | メイン | 2005年7月3日 流出するわが国の「知」 »

2005年7月 2日

2005年7月2日 小論文作成例-1(PM H16-3)

PM 平成16年午後II問3解答例「請負契約における品質確認」

1 プロジェクトの概要と機密情報
1.1 プロジェクトの概要

 私が関与した情報システム開発プロジェクトはイントラネットべースでのグループウェア開発プロジェクトである。本システムはWWWサーバをインフラとして、動的にWebページを生成して、グループコミュニケーションを促進する。依頼主であるA社は、コンサルタント会社であり、独自の業務ノウハウを実装したグループウェアを1年以内に同システムを開発し、ネット上で販売するビジネスモデルを構築している。  本プロジェクトのメンバーは管理者としての私、Webサーバ開発チーム、グループウェア開発チーム(データベース開発を含む)及びマンマシンインターフェース開発チームの3チームの合計10人の組織である。本プロジェクトメンバーのうち、グループウェア開発チームは、協力会社であるB社メンバーで全員が構成される。 なお、開発工程のうち、業務分析、要件定義、プロジェクト開発計画はすべて弊社が担当する。

1 .2発注した工程の範囲

 B社に発注した工程の範囲は、グループウェアの基幹部分の開発であり、その業務アプリケーションのうち以下のような工程範囲である。 (1)概要設計:データベース設計を含めて、基幹部分開発に関連する入出力設計などを作成する。 (2)詳細設計:データベースの物理設計、正規化などを行う。 (3)プログラム設計:アプリケーションソフトウェアを設計・開発する (4)テスト工程:単体テスト、弊社が開発したインフラとの結合テスト、総合テストまでの範囲のテスト計画書の作成から実際のテストを実施する。  弊社とB社との関係は請負契約であった。

2 請負契約における品質確認
2.1 品質目標の設定
2.1.1 システム特性

 本システム開発は、WWWサーバベースの開発であること。また、弊社の得意なデータベース技術を利用できることなどから、バグの多さなどの品質よりも、むしろ依頼主であるA社の業務要件を満たすことのできるかどうかが品質管理が主目的となる。

2.1.2 品質計画

 そこで、私は品質計画書で次のような、品質目標を立案した。①A社の業務ノウハウをすべてグループウェア機能として実装すること、②A社の要求する基本機能はすべて実現すること、③要件品質の確認方法としてスパイラルアプローチを採用すること、④A社とのスパイラルによる品質確認は2回を限度とすることとした。また、これらの要件品質の向上には協力会社の協力も必須と考えた。そこで、B社との契約作業の期間中に設計書レビューを含めた打ち合わせが必須と考えた。

2.2 品質の確認事項
2.2.1 確認事項の詳細

 要件品質の確認事項については、B社リーダC氏と以下の点で合意した。 (1)確認時期:概要設計書作成終了後と詳細設計書終了後の2回、また、上記の品質確認状況に応じて追加確認時期を設定できるとした。 (2)中間成果物:概要設計段階で提出をうける成果物は、DFD,E-R図、機能要件階層図等の文書と画面・帳票プロトタイプである。また、詳細設計段階の提出成果物は物理データベース構造やDDL関連等の文書である。 (3)確認方法:中間成果物の確認方法は以下のとおり。 ①文書レビュー:ユーザA社を含めた設計書レビューを実施する。 ②プロトタイプ:ユーザA社の業務担当者の操作確認を得てプロトタイプレビューを実施する。

2.2.2 私の実施した品質確認上の工夫

 今回のプロジェクトの品質確認上重要なポイントは、①A社要件を網羅的に実現する、②業務特有な複雑な処理系について正確に定義する点にある。そのために私は次の点に留意しつつ、品質確認作業を進めていった。 (1)可視化技法の適用による理解の正確性確保  画面や帳票と業務プロセスとの関連性を状態遷移図やDFD等を使って明示することにより、A社、B社相互の要件定義に対する設計の準拠性、関連性を確認することができる。 (2)チェックリスト利用  A社要件を階層的チェックリスト化し、業務要件のもれ、例外事項のもれがないように配慮する必要がある。 (3)上位ドキュメントへの準拠と活用  業務要件のチェックリスト作成にあたっては、要件定義書、ユーザとの打ち合わせドキュメントを活用した。 (4)用語の標準化の徹底と合意の形成  例えば、「手順」「作業」などのように一般名詞化された用語の意味を取り違え、ユーザの意図しないシステムを構築してしまうことが良くある。このため、要件定義書の段階であらかじめ用語を定義するようにした。さらに、A,B,弊社の3者レビューで顕在化した疑問点は解決し、合意する必要がある。

3 評価と改善
3.1 評価
3.1.1 品質目標の達成

 当初、A社が弊社と打ち合わせ時に計画していた機能はすべて網羅的にグループウェアの中に盛り込まれた。  また、プロトタイプ実施によって、①潜在的にニーズも吸収できた。②さらに、操作性、画面遷移の適合性の検証も行うことができた。

3.1.2 請負先B社のコントロール

契約前に設計レビューを合意事項として盛り込むことができたので、協力会社統制が円滑に行うことができた。

3.2 改善
3.2.1 ユーザ錯誤による誤った業務定義

 3者レビュー時に、弊社作成のDFDに誤りがあることがA,B社相互から指摘がなされた。これは、DFD定義を行う際に、A社が例外業務を定義し忘れたことが原因だった。   ユーザ定義が誤っていても、複雑な業務系列の場合、弊社では正誤の判断がつかない。このような課題の解決方法として、ユーザ定義再確認プロセスが必要だろう。

3.2.2 さらなる品質向上のために

 協力会社依頼手続きのさらなる改善のため、協力会社と契約書にシステム監査権限を組み込むことも有効だと思われる。さらに、協力会社の再評価・再格付けの手続きも有効である。




投稿者 kato : 2005年7月 2日 23:55