開発丸投げは，それ自体が大きなリスクである。協力会社がシステムの品質を損なうケースが頻発している。
品質とは，安定稼働だけを指すわけではない。品質の6特性を漏れなく満たす必要がある。6特性とは，機能性，信頼性，使用性，効率性，保守性，移植性を指す＊7。プロジェクトをトラブルなく遂行するという観点に立つと，特に性能確保，負荷対策，イレギュラーな仕様の品質目標を定量的に明示することが重要である。
想定プロジェクトのケースでは協力会社への発注比率が開発全体の50％と高い。マネージャがユーザー対応や社内の開発管理に追われて，協力会社の管理を怠ると，受入検査時に多くの障害や仕様の食い違いが表面化するリスクがある。
1社ですべての開発を請け負うのが困難な今，外注先のソフト品質マネジメントは最重要課題の一つといえる。協力会社は，外注先に限らない。ユーザーの情報システム部門とソフト開発を分担する場合は，ユーザーも協力会社の一つとして同じようなマネジメント対象と考えておく。
プロジェクトの全体像を伝える
協力会社をマネジメントする際のポイントは，2つある。
 図5●協力会社への発注計画書の例 [画像のクリックで拡大表示] |
第1に，プロジェクト計画書を作成し，品質目標や納期を含めて協力会社に明示すること（図5）。自分の作業が全体のどの部分かが明確になり，協力会社の担当者は品質確保への広い視野をもって作業を進められる。
協力会社，特に末端のプログラマは自己の責任範囲のみ理解して開発していることが多い。これではシステムの全体像やユーザー企業がどのように運用するかを把握できない。その結果，例えば異なる担当者が開発した画面は，画面遷移が統一されていない状態でソフトが納入されたりする。
また，経営上の要請や技術上の課題に伴い，計画書は随時変更される。変更した内容も，随時協力会社に伝わるような運用を心掛ける。
最低1.2倍程度の予備を確保する
協力会社をマネジメントするポイントの二つ目は，中間時の進ちょくと品質チェックを定期的に行うこと。特に工程の節目にはメンバーを集め，報告会を行う。たとえ信頼している協力会社であっても，定期確認を欠かすべきではない。同じ会社でも，参加メンバーが異なれば品質にブレが出やすいからだ。
協力会社の品質チェックは，次のように行う。
まず，仕様の理解を徹底させる。理解度を把握するためには，打ち合わせ中の質問や指摘の数や内容で判断するのが現実的だ。質問や指摘が少ないと，仕様をよく理解していなかったり，協力会社が自分の判断で誤って仕様を理解している可能性がある。また，定期打合せなどで状況を随時確認し，不十分な場合はフォローしていく。
進ちょく確認はできる限りメールや電話に頼らず，会議方式で行う。成果物確認も納入段階ですぐに実物を見て評価すべきだ。一方的に報告を受けるのみの状態が最も危険である。
 図6●協力会社による成果物を中間確認する [画像のクリックで拡大表示] |
中間成果物の進ちょくは，定期的に定量的に確認する（図6）。最低でも工程の節目で必ずレビューを行い，OKになった段階で次工程に進む。工程の節目とは，(1)システム設計，(2)詳細設計，(3)プログラム設計，(4)プログラミング/単体テスト，(5)結合テスト，(6)システム・テストを指す。協力会社に(2)～(5)を委託した場合，協力会社内の(2)～(5)のレビューに参加する。特に(2)と(5)は必須。さらに，自社内で行う(1)と(6)のレビューには，協力会社にも出席してもらう。
中間チェックの方法は，ドキュメントの場合，作成途中の文書のページ数を確認する。全ページに対する作成ページの割合を％で表し，文書ごとの進ちょく率を見る。ソフトの場合は，ソース・プログラムを確認する。可能なら全体のライン数に対する作成ライン数を％で表す。それをサブシステムごと，プログラムごとに管理する。また，詳細設計のレビューを行わないままの状態で，プログラム設計に着手していないかにも留意する。
ソフトの場合は，コーディング内容を実際に見て，可能な限りソースコード・レビューを行う。可能なら，完成した機能ごとに開発途中での動作確認を行い，完成度合いや品質を見る。
また，協力会社に発注する際にリスクを織り込んでスケジュールを立てるのが有効だ。リスクを定量化してスケジュールに反映させる手法は今のところ無いが，開発の難易度，新規/継続か，経験年数，キーパーソンの信頼度，過去の品質問題有無，協力会社のモチベーションあたりを考慮する。一般的には，協力会社からの見積もり（金額，期間）に対して最低1.2倍程度を見ておくべきだろう。
|
町田 仁司 |
