|
●連載・プロジェクト管理のつぼ●
第三回（最終回） 「品質管理」と「コミュニケーション」
プロジェクト管理委員会
（promgt@bolero.plala.or.jp）
■はじめに
これまで２回に分けて、どちらかと言うと発注者側の視点にたち、システム開発のプロジェクト管理を行う上で重視すべき考え方や事項についてご紹介した。プロジェクトを成功に導くためにマネージャーは何に着目し、どのように行動するか、当たり前のようなことであるが、第一回目は「キモに銘じておくこと」、第二回は「開発作業計画」と「進捗管理」について述べた。今回（最終回）は「品質管理」と「コミュニケーション」に関し、重視すべき考え方や気をつけておくことをご紹介する。
■品質管理
（１）品質確保の考え方
品質には「利害関係者のニーズを満足させること[１]」、「開発対象となるシステムの単位規模あたりのバグ数[２]」等、種々の定義がある。本稿では品質を「発注者の満足度」と定義し、品質管理について述べる。
市販パッケージプログラムやASPサービスなどの場合は試用や評価レポートなどで利用者側が事前に品質（機能、性能、使い勝手、信頼性、可用性、保守性、コスト等に関する満足度）を確認し、満足した場合にそれを購入するという手順を踏むことが可能である。
一方、個別に注文し開発するシステムに関しては、事前に評価すべき実体が存在しないため、このようなことは通常困難である。しかし、現実に使ってみるまで品質がわからないという訳にもいかないので、注文生産の場合は開発の中間段階での仕上がり具合を示す品質指標を設定し、工程別に品質水準を満たしていることを確認しながら開発を進める。品質水準の設定は、発注者と開発委託先で相談し予め決定しておく。発注者側は途中の品質確認を開発委託先任せにするのではなく、積極的に各工程（設計工程、製造試験工程等）の品質管理に関与し、あとでの手戻りが出ないようにする。最後に困るのは自分自身となるからである。
具体的な品質管理の方法は、開発手法によっても異なるが、開発委託先が標準的に定めている方法をその時々の開発内容に応じてカスタマイズして利用することになるので、どのような管理方法を使うのかを開発の開始時点で協議し、決定する。
品質の管理は「設計工程」と「製造試験工程」では着眼点が異なる。設計工程での品質管理をおろそかにすると要求と違ったものができあがる。このような場合、発注者側は設計結果を承認しているのが通例であり、設計結果の責任の一端は発注者側にもあることをキモに銘じておかねばならない。発注者は積極的に各工程の品質管理に関与しなければならないが、上流工程（設計工程）の品質管理には特に慎重に取り組むべきである。
以下、設計工程と製造試験工程に分け、発注者側が品質管理に参画する上で気を付けておくことを中心に述べる。
（２）設計工程の品質管理
システム開発における設計品質は、設計が漏れなく実施されていること（設計網羅性）が品質確認の着眼点となる。設計要素は「業務設計」と「システム共通設計」の２
つに大きく分けることが出来るが、設計網羅性の確認の方法は若干異なる。
業務設計では、利用者の業務部門から要求されている機能仕様を満たし、かつ運用者や実際のお客様が快適に操作できるようになっていることが、設計が完了していることの証となる。システム共通設計では、ソフトウェアアーキテクチャー、ネットワークアーキテクチャー、信頼性、拡張容易性、可用性、保守容易性、性能等にわたり設計が行われ、発注者側の要求を満足しているかどうかが完了の証となる。
成果物が発注者側の要求を満足しているかどうか、その成果物に欠陥があるかどうかの判定と欠陥除去はレビューと試験という作業を通して行われる。例えば、業務設計の完了判定作業に関し、業務フロー・画面遷移・業務コード・メッセージなどが記載されている設計書をユーザー参加のもとにレビューし、これらの条件が満たされているか否かを確認
する。つまり、設計工程では、ユーザーレビューが重要な品質確認の場となる。ユーザーレビューの主体は発注者側であり、レビューを開催するにあたって、発注者は下記に述べるようないくつかの条件設定をしておくことで設計工程の品質向上を図ることが可能となる。
・レビュー準備状況を事前に確認する
・レビューアーの役割を事前に再確認しておく
・レビュー結果の課題管理を行なう
・品質の判定基準を持つ
・設計品質チェックリストを定めておく
①レビュー準備状況を事前に確認する（開発委託先任せにしない）
当たり前のことであるが、ユーザーレビューでは限られた時間のなかで設計妥当性の適否判断をしなければならない。レビューアーに余計な負担をかけさせない運営が求められることを重視し、発注者側は開発委託先に事前に注意を促し、レビューの最低条件を整えておく必要がある。
簡単なことであるが、明らかに開発委託先の事前内部レビュー不足からくる用語不統一、参照の不整合、記述体系不備などがあまり残存しない状態でユーザーレビューを開催することが第一のポイントとなる。これらの初歩的な不備が残存するという事は、設計行為として必須である「正確なドキュメンテーション」ができていないということであり、発注者側は設計内容に疑いを持たざるを得なくなる。レビューを開始してこのような初歩的な不備が目立つようであれば、レビューの中止を判断し、設計書の再作成、日程の再スケジュール等のアクションを打つ方が効果的な場合もある。その方が後の作業の品質向上に繋がるからである。
実際の開発では、設計レビュー段階ですべての業務フローを含めた要求仕様が確定していないことも多々ある。一部業務が確定していなかったり、工期を分割して設計作業を進めなければならないという制約等から、一部仕様未確定のまま設計を進めることは日常茶飯事である。発注者側のシステム開発責任者は、業務部門の責任者に対して、基本的には「設計レビューは仕様の最終決定の場」であることを予め通知した上で、仕様の未決定事項に対する判断を準備してレビューに臨むよう要請しておく。そうでないと、設計レビュー中に仕様を議論する事態を招いてしまうことは容易に想像していただけると思う。
②レビューアーの役割を事前に再確認しておく
個別の業務仕様は、実際に業務を運営する発注者側の各業務部門でチェックする方が有効であるが、発注者側のシステム開発部門が何もしなくてよい、ということではない。発注者側の各業務部門は自分の担当する業務に責任を持つが、他部門のことには通常無関心である。システムの内部処理や異常系機能等についてはシステムとして適切な仕組みを用意しているはずと考え、あまり注意を払わないことが多い。となると、発注者側のシステム開発部門のメンバーが業務と業務を繋ぐインタフェースや異常系処理の妥当性について重点的にチェックするほかない。よって、発注者側の開発責任者はシステム開発部門の各仕様管理担当者に対して、業務仕様のインタフェースや異常系処理の妥当性チェックの役割を担っていることを事前に周知し、再確認させておく必要がある。また、データベースの正規化などシステムの柔軟性や性能に影響する設計事項のチェック作業もシステム開発部門の仕様管理担当者が担っていることを事前に周知しておく。このようにするとレビュー作業の密度が濃くなり結果的に設計の品質向上に繋がる。
③レビュー結果の課題管理を行う
設計レビューによって新たな設計上の課題が見つかる。当たり前のことであるが、課題管理表を作成した上で、宿題として管理することを励行する。レビュー時間の制約やレビュー項目数が原因で、細部の設計内容をレビュー時間内に査読できない場合がある。このような場合に備えて、レビュー後にコメント票で確認する手順を発注者と開発委託先間で
事前に定めておく。ただし、これらの期限は通常1 週間程度に限り、次工程への影響を少なくするように取り決めておくと良い。
④品質を判定する
設計レビューの結果は課題として管理される。しかし、その課題がすべて解決されないと次工程へ進めないとなると、いつまでたっても開発は終了しない。完璧な設計などあり得ない。ユーザーレビューが終了した段階で、発注者側と開発委託先の開発責任者は次工程突入OK
かどうかの判断に直面する。通常、設計上の残課題が次工程で解決可能な内容で、かつそれへの対処方針が明確にされれば、業務設計に関する部分では製造工程へ進んでよし、と判断する。次に、設計品質が満足されるものであるかどうかの判定に関する具体的な着眼ポイントを示す。
設計書に対してユーザーレビューが十分実施されたか、設計の不具合がひととおり摘出されたか、ということを判断する方法の一つとして、数値（メトリックス）で判断する方法がある。これは実際の測定データと過去の積み重ねたデータの利用により品質を管理する統計的品質管理手法（統計的プロセス管理手法と呼ばれている）である。
例えば、設計書のレビューに関しては、バグ密度（件/枚）、レビュー密度（分/枚）、コメント密度（件/枚）等を管理限界（上限値、目標値、下限値）という値で管理する。しかし、先に述べたとおり「開発会社怠慢によるつまらないミス」が残存する設計書を対象にレビューすると数値の意味合いが大きく狂ってくる。またレビュー密度の算定ではレビュー参加者の資質（適切にエラーを摘出できる人かどうか）も重要であり、具体的な指標値を決める場合は過去の積み重ねデータ、レビュー参加者の資質、対象とするエラーの種類などを予め関係者で意識あわせしておかねばならない。
システムアーキテクチャー、ネットワーク、性能、信頼性、安全性、保守容易性、拡張性、移行などは通常、システム共通の内容であるため、システム共通設計と称して各機能や各モジュール設計とは別立てで設計品質を管理する。これらのシステム共通事項の設計に関しても業務設計同様、発注者が参加したレビューを実施するが、この場合の発注者側の主体部門は業務部門ではなく、システムの運用部門やシステム開発部門になる。
システム共通設計の場合、発注者側のシステム開発部門に設計や技術に精通した人材が備わっていると限らない。このような場合は、発注者側が設計書を査読するだけで設計の妥当性を判断すること自体大きなリスクを内包していると考えるのが妥当である。現実解のひとつとして「設計品質チェックリスト」（後述）を予め開発委託先と共同で作成しておき、これを使用し、設計すべき要素が漏れなく設計書に記述されているか否かを確認することにより設計の正確性を検証する方法がある。開発委託先としても当然チェックしておくべき事項であり、発注者参加の設計レビューの前にチェックリストを開発委託先が記入し、レビュー資料として扱う。
チェックリストを作成すると同時にシステム共通設計要素項目を細分化して定義しておくと、必然的にその要素単位にドキュメンテーションすることになるので曖昧性が減少する。直接的に設計の正しさを担保できるわけではないが、そうすることによって設計者が検討すべきポイント及びレビューにおいてチェックできる観点が多くなり、結果的に設計不良や漏れを低減させることができると考える。
もう１つのシステム共通設計の特徴として、設計条件の不透明性がある。システム共通設計における設計内容は業務設計のそれと異なり、システム開発要素の新規性、データ量、モデルの精細度、コスト対サービス性条件などによって変動する。しかもこれらの条件は発注者側にとっても不透明あるいはトレードオフの要素を含み、明確に定義できない状態で開発委託会社へ設計を依頼せざるを得ない場合がある。つまり、このような場合は外部条件と設計結果との間にいくつかの前提を置くことになるため、設計結果の妥当性を判断することは簡単ではない。では、どのようにして設計品質を判定するか、以下に１つの考え方を示す。
不透明あるいはトレードオフの要素を含むケースでは、実は開発委託先でも、経験者が総合的に検討してトレードオフの解を求めるしかないのが事実である。その品質判定に関しては、設計において重視した価値、前提の置き方、設計が詳細化できていない事項への対応方法などについて注意深く発注者は開発委託先の設計責任者から説明を受け、発注者側のシステム開発責任者が考えるシステムのイメージや開発手順と整合がとれているかどうかを判断材料とす
る方法がある。不透明な事項に対する設計のアプローチ方法に関して基本的な考え方が合っていればその時点で多少設計の漏れがあっても、システムの完成までに対処して行けるという判断もあり得る。
なお、システム共通設計の項目のなかで移行設計については通常の設計よりも検討、設計の開始が遅れる。その理由は、開発すべきシステムの姿が明らかになった時点で具体的な移行方式の検討に入ったほうが効率的だからである。しかし発注者参加のレビューがあまり後になると移行方式とサービス制約のトレードオフ問題を未解決のまま開発を進めることになり、移行作業中のサービス制約増大へのリスクが大きくなる。そこで業務設計のレビューのタイミングで、移行設計項目のうち移行方針、移行対象データ、主たるサービス制約についての最低限の確認は済ませておくことが賢明である。
⑤設計品質チェックリストを定めておく
設計品質チェックリストを予め開発委託先と共同で作成しておくことで、設計すべき要素が漏れなく設計書に記述されているか否か等、設計の正確性を検証することが可能となる。④でシステム共通設計の品質チェックにリストを用いると書いたが、各業務に依存した固有の設計項目を明示的に盛り込み、確認する場合もある。例として、システム共通設計の信頼性設計に関するチェックリストの一部を下表に示す。
下表のチェックリストは３階層のモデルであるが、重要な設計要素は３階層目を見直し、新たに４階層目を定義しても何ら問題はない。
なお、設計品質チェックリストは、その利用の仕方を間違うと、チェックリストと設計書との突合せに工数を要してしまう。また、頭では理解していても、実際の現場では、設計後（事後に）渋々チェックしているということも起こりえる。このようなことが発生する一つの理由に、設計書の記述体系とチェックリストの項目体系とが合っていないことがある。設計の網羅性をないがしろに出来ないという点では開発委託先も異論はない筈である。事前に、設計書の体系とチェックリストの体系の整合をとっておくことで、余分な工数を削減できるとともに、より品質の高い設計結果を得ることが可能となる。
NEXT >>
|
