組織的に取り組むソフトウェア品質マネジメント

　基調講演で野中氏は、「ソフトウェア開発プロジェクトにおける品質とは、欠陥（バグ）の管理やテストの実践という信頼性の面だけではなく、ソフトウェアを通じてどのような顧客満足や顧客価値を提供できるのかにまで目を向けるべき」と語る。

　そのためには、ソフトウェア開発のスピードを加速させる、あるいは低下させないことが必要であるとし、欠陥の検出や除去、混入予防に必要な活動を定義し、それらの技術をしっかりとマネジメントしていくとともに、欠陥から学んださまざまな経験を組織内にフィードバックし、再発防止につなげることがポイントになるという。
　また、「品質に取り組めばトータルコストは下がる」という野中氏。評価活動の強化により外部失敗を内部失敗に振り分けることで、一時的に内部失敗コストや評価コストは増加するが、評価の効率向上と予防に関する活動に投資し、欠陥の早期除去と混入防止ができるようになれば、トータルの品質コストは一定の範囲に抑制することができると話す。
　続いて野中氏は、「プロジェクト管理」、「レビュー」、「要求定義」、「プロセス改善」の各要素に活かすソフトウェア品質技術について解説した。
まず、「プロジェクト管理」では、欠陥の数え方について着目。欠陥の定量的管理の基礎として、ベンダーからのテスト結果レポートやレビュー工程からどれほどの欠陥が除去されたのかを測定しているが、品質保証部門が欠陥の粒度定義と測定精度の確認を行っている企業は少ないという。
　また、欠陥除去率に目標値を用いて管理することがあるが、実際に除去できたバグが少ないと、除去件数を水増しして見かけ上の除去率を膨らまし、テストに移行してしまうケースもある。欠陥の数を品質管理の指標にする場合、基準が不明確でチェックが十分に成されていないと、開発現場での「誤魔化し」を助長してしまうことにつながってしまう。

　さらに野中氏は、欠陥の分類も重要だと指摘する。「欠陥除去のフロントローディングを議論する際は、テストや客先で問題となる現象につながる『機能性欠陥』を重視し、成果物の構造や読みやすさなど、その問題が引き金となり将来の機能性欠陥につながる『発展性欠陥』は早い段階でその芽を摘んでおくこと」
　加えて、欠陥除去能力を高めるために不具合を含みそうな「Fault-prone」モジュールの検出も有効だという。ソフトウェア開発プロセス（V字モデル）のコーディング／単体テストが終了した時点で、ソースコードからプロダクトメトリクスやプロセスメトリクスを用いて、複雑度・規模・ネストの深さ・結合度・凝集度などを使ってランク分けをし、欠陥が多そうなモジュールを優先的にテスト／レビューする。
　だが、野中氏はそこで経済学者のケインズの"精密に誤るよりも漠然と正しくありたい"という言葉を引用し、「ソフトウェア品質を細かく正しく把握しようとし過ぎると、いつの間にか、ルールを精緻にすることが目的になってしまい、品質向上に寄与するという本来の目的とかけ離れた行動に陥りやすい。そのため、矛盾するようだが、一定の評価が可能なレベルで品質の状況をつかむことが、まずは正しいやり方だと理解してほしい」と話す。

　次の「レビュー」では、目的の明確化や技法、観点の3つが重要だという。観点別に、システムのふるまいの安全性や妥当性、利用シナリオの網羅性などの目的に即したチェックリストを考えることが必要となる。 　続いて、「要求定義」では、ビジネス構造を理解した上でのIT導入、また、「プロセス改善」では、技術者行動の構造を理解した上でのプロセス改善など、いずれにも共通する「システム思考」の活用が求められるという。 　「欠陥除去目標について、目標と実績の差が大きいと実績の改ざんが起こり、欠陥のデータに対する第三者のチェックの頻度が低いと改ざんを助長するなど、背後にある構造を理解せずにシステムに介入することで、期待に反する行動が必然的に引き起こされる」（野中氏） 　そのため、対象をシステムとして捉え、システム内に含まれる要素間の因果関係の構造を理解することでシステムのふるまいを分析することが重要だという。 　最後に野中氏は、「ユーザー企業やベンダー、協力会社のさまざまなレイヤーで、品質にしっかりと取り組めば企業の強さにつながり、そうした品質に取り組む企業とパートナーになることがビジネスの価値を創造する」と語り、基調講演のまとめとした。

　「この1年プロジェクトを見てきた経験から、特に影響力のあるプロジェクトマネジメントの失敗事例を紹介したい」と語る高林は、プロジェクトの成功の条件を、1）期限内に、2）決められた予算内で、3）期待レベルの品質・技術成果の元で、4）割り当てられたリソース（人的、物的）を有効活用し、5）顧客が満足する状態で完了することと定義する。

　「一般論として成功プロジェクトといえるのは20％台」という高林は、名人の経験と勘など属人的な要素に頼らないマネジメントの仕掛けや組織作りが必要だと強調する。そこで、プロジェクトの失敗事例が3つ示された。
その１つが、仕様が確定しないまま進められるケース。要件定義が曖昧なため、担当者個人の判断で作業が進められることで、要件の抜け・漏れの発生や無用な仕様が入り込む。また、仕様変更があっても受入条件が曖昧な場合、現場は多忙な状況にあるため要否回答に時間がかかり、それが既成事実化して仕様変更をせざるを得なくなる事例も多いという。
　「不十分な仕様からは漏れのないソフトウェア製作は不可能であり、過不足のないテストも困難。テストチームとしては欠陥なのか仕様なのか判断できず、スケジュールが逼迫しているにも関わらず確認に何時間も費やしてしまう。"仕様は設計しながらでないと抽出できない"という発想ではこうした問題は永遠に続く」という高林は、開発側も要求側と仕様をお互いにイメージしやすいコミュニケーション方法で調整していないため、要求漏れや仕様漏れが解決できずに、そのツケは下流工程に持ち越されると指摘する。
　仕様書（成果物）を概要書や取扱説明書のようにしないためには、追加や変更要求を明らかにし、要求側（要求仕様）と開発側（機能仕様）が互いに理解できる資料にすることが必要となる。それには、上位組織がプロジェクトマネジャーの能力も含めて戦略実行に必要な組織能力を見極め、要求を引き出すコミュニケーションや要求の可視化・管理といった改善をサポートする仕様決定プロセスが不可欠という。

　失敗事例の2つ目は、プロジェクトマネジャー（PM）が作業を担当しているケース。腕に覚えがあるため、担当業務に手を出して作業分担を疎かにしていたり、人材不足から他のプロジェクトを兼務させられたりすることで、レビューに参加できない、情報が流れてこなくなる、進捗管理ができなくなるなどの弊害が発生し、プロジェクト内が大混乱してしまう。
　「プロジェクト体制を整備し、メンバー個人の役割や責任分担を明確にしてチームを率いているという自覚がPMには必要だが、一方で上位組織は最適なプロジェクトの特性に応じた組織体制作りや運用する人材育成を時間とコストをかけて作っていくことが求められる」（高林）

　そして失敗事例の3つ目は、プロジェクトの状況が正しく把握できていないケース。“できています”、“盛り返せます”などといったメンバーからの曖昧な報告によって粒度や数値が特定できず、課題がどれだけ残っているか判断できなかったり、問題が発生してから慌てるなどリスクの把握を怠ったりすることが頻発し、依然として改善できていないという。
　「PMの仕事は報告のあいまいさとの戦いである」という高林は、あうんの呼吸がオフショア開発では通用しないことは自明であるが同様に国内のプロジェクトでも、さまざまな報告内容からできる限りあいまいさを排除し、正確な状況を把握するように努めるべきと訴える。また、そうした報告が可能なルール作りやフォーマットを用意することも必要だという。
　さらに、危険の察知も重要だ。会議が予定通り開催できない、報告資料に定量的データがない、状況報告資料を直前になって作成しているなど、そうした予兆を敏感に検知し、見える化できるチェックリストやツールを活用することも推奨する。
　「CMMIやPMBOKなどを使った成功事例を活用するとともに、外部の要員を活用して、プロジェクトの意識改革をプロジェクトメンバーと一体となって進めていくことも有効だ」（高林）

　ソフトウェア開発における品質について、藤井は、「お客様、エンドユーザー、メーカー間の信頼関係の要であり、開発者にとってはプロジェクトを計画通りに進め、成功させるための要である」とし、その評価尺度も、従来のバグがないことが中心の“当たり前品質”から、現在は品質（Q）・コスト（C）・納期（D）の全てでバランスがとれた顧客満足度を基本とする“魅力的品質”へと変化していると語る。

　藤井は、広義の品質には「プロダクト(製品／サービス)の品質」と「プロセスの品質」があると分類する。プロジェクト(製品／サービス)の品質として考慮すべき例には、1）情報システムの維持・運用におけるシステムの可用性、エラー発生率、レスポンスタイムといったサービスレベルや、2）装置の誤動作を防止し、エラーが発生した場合に安全側に制御するフェイルセーフ／フェイルソフト機能の実装有無、3）セキュリティホールへの対策などがある。
　また、プロセスの品質として要素には、1）正しい作業手順(開発プロセス)による作業ミスの防止(ソフトウェアバグの作り込み防止)だけでなく、2）トラブル時の対応など、企業倫理にまで関係するものがあるという。
　「日立グループにおける品質理念には、失敗の後始末には正直が基本で、臭いものに蓋をするなというような“落穂拾いの精神”があり新人からベテランまで全員に常に叩き込まれている」という藤井は、こうした顧客第一主義・品質第一のような精神論も非常に大事な要素だと説明する。

　それを踏まえ、品質を向上させるための具体的な手法として、開発手順やルールの標準となる「開発プロセス規定」や特に品質管理に焦点を絞った「品質管理ガイドライン」を品質管理の枠組みとして策定しておくことが重要だという。
　この枠組みを前提として、プロジェクトを立ち上げる際にプロジェクトマネジャー（PM）は品質計画を策定する。具体的には、「リスク管理計画」、「品質目標値の設定」、「テスト工程の定義」、「工程完了基準」などを決める。
　まず、「リスク管理」は、トラブルを防止する上で最も重要で、見積段階からリスクを洗い出し、プロジェクト計画時に更なる分析を行ってプロジェクト完了まで定期的・継続的にリスクを管理していく。 　プロジェクト計画立案時には「困難が予測されること、不可能なことは全てリスクとして抽出する割り切りが大切」で、プロジェクトが動き出したら、「地道に対策を実施するとともに、開発が終了するまで継続的にフォローを実施してほしい」とアドバイスする。
　また、品質トラブルの予兆を見逃さないことが重要で、作業範囲が明確ではない、仕様変更が多発している、予定が何度も変更されている、開発途中で顧客側の管理者が変更した、問題点が整理されなくなった、などのポイントにも注意すべきという。

　「品質目標値の設定」では、定量的な品質管理指標を設け、それぞれの指標で具体的な目標値を設定する。
　「テスト工程の定義」では、一般に単体テスト・結合テスト・総合テストの3段階で行われることが多いが、それぞれどのようなテストを実施するのか具体的に規定し、プロジェクトメンバーの意識を合わせておくことが必要だという。
　「工程完了基準」について、例えばテスト工程の場合、どれだけテストを行えばテスト終了とするのかを決める。摘出不良件数、テスト消化項目数、摘出不良対策、摘出不良の分析と評価に基づく品質改善などに着目して、プロジェクト計画で決定しておく。

　一方、プロジェクトが動き出したら、品質計画に従って「ピアレビュー」、「プロセスQA」、「品質状況の把握」といった品質管理を実施していくと解説する藤井。
　「ピアレビュー」は、問題点を早期に発見し手戻り防止と品質・生産性を向上するための検証作業となる。 「レビューの目的は、仕様書等のレビュー対象物から問題点(バグ)を見つけ出すことであるのに、レビューが、単なる仕様の説明会になっていたり、あるいは、見つけ出した問題点の修正方法の議論に時間を費やしているケースが多い。いかに多くの問題点を効率よく見つけるための場にするかが大事」（藤井）
　「プロセスQA」とは、製品の開発プロセスが規定通りに正しく行われているかを監査し、プロセス改善提案などを行ないながら継続的なプロセス改善を図ること。
「品質保証部やPMOなど、開発側ではない第三者によって実施することができれば、より有効となる」（藤井） 　「品質状況の把握」とは、品質が予定通りに確保されているか品質データを基に評価すること。
「ここはPMが最も悩むところであり、バグ管理図や品質マップ、品質見解書などを積極的に用いて、見えない品質状況をいかにビジュアル化し見える化できるかがポイントとなる」（藤井）
　さらに、トラブル（失敗）に学ぶことも大切だという藤井は、発生した障害や摘出された不良から、同様の障害や不良を繰り返さないために反省をして再発防止策を策定する必要があると強調する。
　加えて、品質向上のためにツールの導入効果にも言及し、ツール活用によって、作業時間の短縮や作業品質の安定化、管理方法の統一化などの効果もあるという。ただし、開発プロセスや品質管理方法など開発現場の文化に浸透させることが必要であり、段階を踏んで導入していくことが重要だという。