●連載・プロジェクト管理のつぼ●

第三回（最終回）　「品質管理」と「コミュニケーション」

プロジェクト管理委員会
（promgt@bolero.plala.or.jp）

（3）製造試験工程の品質管理

�@製造工程の品質管理
　製造工程での品質管理は開発委託先が責任をもって実施する基本作業である。しかし大規模プロジェクトとなると、そのプログラム製造は複数の協力ベンダーに再委託される場合が多々ある。このような場合、プログラムデザイン、プログラムコーディングを行う技術者レベルにまで統一した「製造に関する規約やガイドライン等」を作業標準として制定し、製造試験工程に関する品質向上を図る。例えば、

・コーディング規約（C,C++,JAVA等）
・SQL チェックリスト（DB アクセス性能劣化防止用等）
・Webアプリケーションコーディングガイド（クロスサイトスクリプティング等のセキュリティ対策用等）
・プログラム設計品質チェックリスト（設計網羅性確認用）
などがある。SQLチェックリスト、Webアプリケーションコーディングガイド等はコーディングより前のプログラムデザインの段階でのチェックリストとして使うと効果がある。

�A試験工程の品質管理（管理限界値の設定）
　プログラム製造が完了すると単体試験、結合試験、システム試験の順にプログラムの品質確認を実施する。その実施責任は基本的に製造工程同様、開発委託先にある。といっても、発注者側としても、試験が規定どおり実施されているか、各工程別に報告を受け確認する義務があることを忘れてはならない。

　品質の判断は、前述のように統計的な品質指標による判断に加え、個別観点での判断も実施する。統計的品質管理に関しては、管理限界値（上限値、目標値、下限値）を用いて管理する統計的プロセス管理手法、ソフトウェア信頼性モデル、欠陥予測モデル等の定量的品質管理手法がある。例えば、統計的プロセス管理手法を用いる場合は、単体試験、結合試験、システム試験、総合運転試験の工程毎に、かつ、品質管理単位毎（ソフトウェアアーキテクチャーに従い分割された設計・実装管理単位毎）に、試験項目数（件）、試験密度（件/キロステップ）、バグ数（件）、バグ検出密度（件/キロステップ）等を管理限界値として設定する。管理限界値は積み重ねた過去の統計データをベースに各プロジェクト毎にカスタマイズし設定する。

　以下に、管理限界値を設定する時の注意点を示す。

・新規開発と改造は分けて管理する
　（例えば、結合試験の試験密度のレンジが他工程と比較して高くなる場合がある。理由は、新規開発と改造では同一の開発規模であっても試験範囲が異なる（改造の方がデグレードを考慮して範囲を広くする）ためで、改造量が多い場合は開発規模に対する試験密度を相対的に高く設定しなければならない）

・試験密度を下げる時はある程度の限度を持つ
　（計画時点で試験密度を下げると工数が削減できるので、開発委託先が経験を積んでくると試験密度を下げる提案をしてくることがある。コストの削減効果はあるが品質確保とのトレードオフもあるので、一定の限度を設定する）
・総合運転試験の試験密度は、前工程迄の品質状況や難易度を勘案し、総合的に決定する
・バグ検出密度はよほどの理由がない限り、計画指標値を下げない・既存システム自身のバグは別管理とする
　（開発対象が既存システムの拡張である場合、試験工程で既存システム自身の欠陥（潜在バグ）を発見することがある。このような場合、当該開発の管理限界値とは別に、既存システムのサービス開始後６ヶ月間、１年間等のバグ検出密度を考慮した管理限界値を別途定める）

�B試験工程の品質管理（品質の判定）
　発注者は開発委託先との間で各試験工程の終了前に品質データ報告とその見解を提示するように予め取り決めておく。統計的品質管理での着眼点は、工程毎の試験密度とバグ検出密度が許容範囲内に入っているか、工程別の変動に異常（高くなったり低くなったり）はないか、バグの検出が収束傾向にあるか、などがある。実績データが管理限界内になければ、詳細な分析を行い、場合によっては開発委託先に品質強化試験等の適切な処理を依頼する。

　バグ検出密度が小さい場合は、本来の品質が高いのか、試験の網羅性が悪いのかの見極めは非常に難しい。このような場合は個別の説明を求め、理由に合理性があるかどうか判断材料にする。開発委託先は、経験者を投入したので品質が向上している等の見解を示す傾向にあるが、最終的には全工程の実績を評価しないと判断できない場合が多い。つまり、バグ検出密度が小さい場合は、前段の工程で安易に結論を出すのは避けるべきと考える。

　試験の網羅性という観点では、異常系試験が一定量実施されているか、という観点でチェックすることも大切である。例えば、結合試験、システム試験工程では、全試験量の10％〜30％を異常系試験とする場合もある。

（４）仕様変更とバグの切り分け
　システムの利用に不都合が生じた場合、問題の所在が仕様自体にあるのか、設計製造にあるのかの切り分けで紛糾することが多々ある。また開発委託先（元請会社、システムインテグレータ）と、協力ベンダー（各モジュールの開発ベンダー）が責任を押しつけあうなど、品質管理の基礎情報の整理に支障をきたすことがある。次に開発現場でよく見かける主張を示す。

・レビューで承認したのだから、責任はその仕様を決めた発注者側にある。
・詳細設計書に書いていないことについて開発委託先は責任を負えない。
・協力ベンダーは元請会社（システムインテグレータ等）が定めたインタフェース仕様書に従って製造しているので、インタフェース不整合に起因する問題の責任を負う義務はない。

　どちらともいえないケースでは最終的に発注者側の開発責任者と各社の上位マネージャーが協議して決めざるを得ないが、実務レベルでも一定の考え方に沿って整理できると考える。速やかな切り分けを実現するために発注者側の開発責任者は、各仕様管理責任者に考え方を徹底しておくことが肝要である。交通整理するためのひとつの例を次に示す。

　基本設計書や詳細設計書で発注者側は仕様を確認するが、果たして設計書には発注者が完全に理解できる形で仕様が定義・表現されているだろうか。例えば業務仕様に関するロジック、画面入出力項目など業務を実行するために必須の仕様は発注者側が指定しなければ決定しない性質を持っているので、全て書かれているべきである。開発委託先から見た場合、設計書に書いていないことは製造していなくて当然である。一方、Web上のEJBのロジックやエラー処理仕様などは「応答時間が保証されること」「汎用性があること」「快適に使えること」という単純な要求に基づいて開発委託先の工夫に委ねられる要素の強い事項であり、開発委託先の見識や経験が反映される部分が大きい。システム開発経験の少ない発注者側は実際の利用局面でなければ現実感をもって理解することは難しく、設計書で承認した、という理由だけで仕様どおり（発注者責任）とするには本来無理があるように思う。たとえ凍結された仕様でも問題を内包しているという観点を持ち、問題に対処していかねばならない。

　反面、発注者がこの考え方を乱用し始めるとプロジェクトは混乱する。単にプログラムの開発だけを依頼している場合などにこの考え方を口に出すこと自体ご法度であることもキモに銘じておくべきである。次節に述べるより良いコミュニケーションをお互いに行い、相手を尊重し、開発プロジェクトは運命共同体であるとの認識に立ったプロジェクトであれば、責任の押し付け合いは自然に減っていくのではないだろうか。

　発注者と開発委託先間の関係と同様に、開発委託先（元請会社）と協力ベンダーの責任分担についても前述と同じ問題が発生することがある。開発委託先（元請会社）が制定した詳細仕様であってもインタフェースなどは関係者が共同で承認すべき責任を負っている。つまり、プログラムを納入する協力ベンダーには問題の有無を十分吟味してからインプリメントする責務がある。別の言葉で述べると、インタフェース不整合のプログラム品質責任は協力ベンダーにも帰着する。ただし、前記の場合でも、仕様書自体の瑕疵修復責任は納入責任を負っている開発委託先（元請会社）にあることは自明であるが。

■コミュニケーション

　システム開発プロジェクトは大勢の人の集まりで運営される。開発発注者、委託先、協力ベンダー、さらには工事業者等からなる運命共同体である。当然そこには多くのコミュニケーションが存在する。例えば、発注者と開発委託先（元請会社）間のコミュニケーション、元請会社と協力ベンダー間のコミュニケーション、開発チーム内のメンバー間のコミュニケーションなどがある。発注者側においても、サービス主管部門とシステム開発部門の関係が存在する。Brooks^[３]は「チーム内のコミュニケーションが生産性に対して指数的な影響を及ぼす」とも指摘している。つまり、如何にしてコミュニ
ケーションを構造化し、運命共同体のメンバーのコミュニケーションスキルを向上させるかがプロジェクト成功の鍵となる。

　Malone^[４]は協調プロセスを次の４つのプロセスモデルで表現している。

�@共通のオブジェクトの認識（目標、課題、ソフトウェアコード、データ等をメンバー間で共有すること）
�Aコミュニケーション（コミュニケーションのための共通言語を選定し、コミュニケーションのルートを確立し、実際にメッセージを送受信すること）
�Bグループ意思決定（複数の選択肢を検討し、判断すること）
�C協調作業（目標を確認し、目標達成のためのリソースを確保し、各担当者に作業を割付け、各作業の同期等調整を図ること）
　ソフトウェア開発は、チームで行う協調的な作業であり、まずメンバー間で前記�@の共通のオブジェクトを認識すること、つまり、目標、課題、設計書、ソフトウェアコード、データ等をメンバー間で共有することが全ての作業のスタートとなる。�@が成立した上で�Aのコミュニケーションが可能となり、�Bの選択肢の判断、�Cの協調作業へと進むことができるのである。上記のプロセスモデルでは、コミュニケーションは狭義的に扱われているが、広義には�@〜�Cすべてをコミュニケーションとして解釈し、その向上に努める必要がある。以下、コミュニケーション向上に関し、いくつかのポイントを紹介する。

（１）目標を一致させる
　システム開発プロジェクトを運営してゆくと種々の問題が発生し、それをクリアしてゆくことが各メンバーの大切な仕事になる。問題を最初に発見したり、解決するのはマネージャー自身というよりは各プロジェクトのメンバーが中心になる。「問題とは目標と現実とのギャップである」と捉えることができ、目標をいかに共有するかがポイントとなる。現実が１つでも、それを認識する側の目標（あるべき姿）が人によって微妙に異なっていたら、微妙に異なる問題が微妙に異なる目標の数だけ発生していると解釈すべきである。さらに現実は多面性を持っているので、目標が明確になっていたとしても複数の問題が発生するのが常である。問題の数が多いと実務的に処理できない。速やかに処理してゆくためには形式的に問題の数を少なくしておく（目標を関係者間で一致させておく）しかない。また、大きな問題、小さな問題とランク付けし、
処理の優先度を決めておく。

　目標とは、スローガンではない。目標とは、具体的な達成値にブレークダウンされたものであり、開発責任者やマネージャーはそれを意思表明しなければならない。ただし独断で決めるとメンバーの協力が得にくくなるのも事実であり、メンバーのなかのキーマンと事前によく話し合って目に見える形で表明する。

（２）お互いに課題を共有する
　第二回の「進捗管理」においてもご紹介したが、課題には必ず解決する主体を付けて管理する。つまり、一見その主体以外の他の人は無関係のように見える。しかし、システム開発プロジェクトの成果物は相互に関係をもっているので、課題は疎密の程度はあるが他のメンバーにも直接/間接にかならず何らかの影響を与える。

　ある課題の解決が計画どおり進まない場合、次善策の検討や代案の検討など速やかなアクションを打つことが必要であり、そのようなことに備えて、プロジェクトで何が起こっているか、いつまでに誰が何を解決しようとしているかなどの情報を常に関係者が共有しなければならない。

（３）定例ミーティングを開催する
　公式的なコミュニケーションをどのようなスタイルで実行すれば効果的かについては、いろいろ意見がある。

　Web上での共有、メーリングリストでの共有など種々の方法があるが、異なる企業のメンバーからなるプロジェクトや、メンバーが同じ釜の飯を食った経験のないプロジェクト、発足間もないプロジェクトなどに対しては、経験上、グループ毎に週1 回1 時間程度でもよいからフェース・ツウ・フェースの定例会を開催するのが良いと考える。さらに、作業の計画性を維持する、宿題の期日管理を徹底するなどの観点から、一旦決めたあとは、どのようなことがあってもそのパターンを崩さないことが大切である。そのためには各グループが開催日程を宣言し、その開催日程をグループ外の人も尊重する、という規約を作ることがポイントとなる。時には出席できないメンバーも出てくるが、その場合は必ず代理人を頼むこと、報告は書面化しておくこともルール化することが重要である。

（４）繰り返し意思表明する
　開発責任者や各マネージャーにとっては、（３）の定例会が意思を表明する公式の場となる。しかし単発の表明だけでは不足で、自分が伝えたいことが本当に浸透しているかどうか、モニタリングする必要がある。他人に自分の意思を伝えるということは、キャンバスに鉛筆でデッサンするように少しずつ書き足しながら、繰り返し作業を行い、形を整えてゆくことに似ているように思う。一貫した思想を持ち、何度も繰り返し話しているうちに、だんだん開発責任者やマネージャーの価値観がチームに浸透していく。

（５）ツールを有効活用する
　定例会以外にメールやWebによる情報共有なども有効に活用すると良い。一方で、コミュニケーションツールを利用する方にも注意が必要で、例えばメールのCc:を相手の立場を考慮せずにばらまくと読んで貰えなくなる。

　目標や課題の認識が共有されていなければ、その情報はゴミと同様かも知れない。プロジェクトではメンバーがいろいろな役回りを演じているので、大目標は一致していても個別テーマでは異なる目標も持っている。このこともよくわきまえてTo:とCc:とを慎重に選択する配慮が必要かと思う。

　メールやWebはプロジェクトメンバーが情報交換する重要な手段となっている。コミュニケーションを活性化するためにも、メール等ツールの誤用に気付いたら速やかな交通整理が必要である。放っておくと、ネットワーク上の情報は悪い方に悪い方にと解釈され、増殖し始めることがあるからである。

■おわりに

　３回にわたりソフトウェア開発やシステム開発のプロジェクト管理に関して開発責任者や現場のマネージャーが注意すべきことについてご紹介させて頂いた。一度はプロジェクト管理業務の経験がある方ならば、なんだ当たり前のことばかりだと思われるのではないだろうか。そのとおりである。しかし、実際の現場では、なかなかその当たり前のことが実践できていないのも事実である。あえてそのあたり前のことを述べさせて頂いた。ご紹介させて頂いた内容の性質上、ある種、個人的とも受け取られる見解も多く含まれていたことにご容赦いただき、プロジェクトマネジメント業務に従事されている皆様の一助になればと考えている。

　３回の連載を終わるにあたり、プロジェクト管理のツボはたくさんあると思うが、約20年程前に筆者の一人が先輩から教えて頂いたABC（当たり前のことを（A）、バカにせず（B）、ちゃんとやる（C））で締めくくりたい。

【参考文献】
［１］M.Cantor, Software Leadership,Addison-Wesley （2002）（ソフトウェア開発管理の要, ピアソン・エデュケーション（2002））
［２］P.Jalote, ソフトウェア開発のためのプロジェクトマネジメント入門, SOFTBANK Publishing （2003）
［３］F.P.Brooks,Jr. The Mythical Man-Month:essays on software engineering（Anniversary edition）, Addison-Wesley
（1995）（人月の神話, ピアソン・エデュケーション（1996））
［４］T. W. Malone and K. Crowston.The Interdisciplinary Study of Coordination. ACM Computing Surveys, 26（1）:87 -119（1994）