プロジェクトマネジャーに贈るプロセス改善事例 第1回サービスインに間に合わなかった原因は何だったのか？

いざ顧客の環境にシステムを配置したところ障害報告や問い合わせが殺到し、結局サービスインに間に合わなかったということはないだろうか？　X社では、自社の失敗経験を生かしてその問題を解決した。

[辻 大輔，豆蔵]

プロセスを改善するということ

　開発プロジェクトの現場では、大なり小なり必ず問題が存在する。それらの問題は最終的に低品質、予算超過、納期遅延などプロジェクトの失敗につながることもある。この状況を打開しようとさまざまな手を打っている企業は多いが、その打ち手は必ずしも大きな成果を挙げているとはいえない。

　よくある要因の1つに、問題が顕在化した際に安易に個人や組織・ツールを原因と特定し、対策を講じようとすることが挙げられる。個人を原因として対策を施した場合、問題は解決したとしても組織には何も蓄積されない。そればかりか、人格否定など別の問題を発生させることもある。また、ツールおよび組織についていえば、そもそもなすべきことを効率的に実行するために組織は編成され、ツールは選定されるべきだ。なすべきことをきちんと分析せずに、組織やツールに対症療法を施しても、成果が出ない場合が多い。

　そこで、なすべきこと、すなわちプロジェクト遂行のための「活動の定義」「活動の手順」「成果物」に焦点を当て、対策を実施する。これを「プロセス改善」と定義する。

　このプロセス改善を実効性のあるものにするためには、3つの要素が不可欠である。「知識」と「スキル」と「やる気」である。

プロセス改善を成功させる3要素

　筆者らは、顧客の開発プロジェクトの現場にて、プロセス改善の支援コンサルティングを行っている。これから6回にわたり、毎回ある問題と改善すべきプロセスに焦点を当て、その改善事例を紹介していく。本連載が、読者であるプロジェクトマネジャー、リーダー、メンバーのプロセス改善活動の一助となれば幸いである。

顧客へシステムを引き渡してよいのか？

　連載初回は、迫る納期の中で顧客が望む品質を確保できなかった経験から改善機会を見いだし、テスト計画とテスト設計のプロセスを改善した事例を紹介する。

　X社は、生産管理システムの構築を得意とする中堅のシステム開発会社である。とあるプロジェクトでは、結合テスト、システムテストと進行し、顧客側の受け入れテストを1カ月後に控えていた。連日連夜、数千件に及ぶテスト項目と格闘。残された時間を有効に使うべく、テスト項目を抜粋しながらその消化と重要な不具合についてすべての対応を終えた。安堵（あんど）感が漂う一方、「果たしてこれで完了としてよいのだろうか？」と不安に思うメンバーもいた。

　スケジュール計画に従って顧客の環境にシステムを配置し、受け入れテストを迎えた。ところが、一部メンバーの不安が的中してしまった。連日、顧客からの障害報告／問い合わせが殺到したのである。顧客からの障害報告の対応に追われる一方、テストプロセスの品質を厳しく問われ、ついには計画通りのサービスインを迎えることができなかった。

　本事例の場合、システムテストを完了し、顧客へアプリケーションを引き渡すべきだったのだろうか。そうでないとすれば、いつ引き渡すことができたのだろうか。

失敗の原因は何？　振り返りミーティングを実施

　結局このプロジェクトは、当初計画より納期3カ月遅延、工数20％超過で完了した。実は、X社ではプロジェクト完了報告が義務付けられているが、プロジェクトマネジャーが所定の形式に従い儀式的に行っているのが実情であった。今回は、納期／工数ともに大幅に超過したということと、メンバーに次のプロジェクトまでの期間に余裕があったこともあり、本格的に総括活動を行うこととなった。

　まず、開発側と顧客側で実施したテストの障害報告書から分析を行った。

障害の原因

　その結果、以下のことが明らかとなった。

開発側テスト時の障害の主な原因

• 障害原因（1）：コーディングミス（圧倒的に多い）
• 障害原因（2）：設計書や要件定義書の記述ミス
• 障害原因（3）：テスト項目への反映漏れ

顧客側テスト時の障害の原因

• 障害原因（4）：インタフェース不適切（使い勝手やデータの表示方法）
• 障害原因（5）：要件定義漏れ

　これを受け、該当プロジェクト参加者で「スケジュール遅延、工数超過がなぜ発生したのか」について意見を交わしたところ、以下のような意見が挙がった。

• 工数を要した主な原因は上流工程ミス、要件定義漏れによる手戻り作業とそれに伴う修正作業である（障害原因（2）、（5））
• 画面や帳票の表示方法は、不具合があっても修正に時間を要さないので重要視していなかった（障害原因（4））
• コーティングミスの修正工数は小さい。しかし、そもそも単体テストで検出するべきものであり、本来確認すべきモジュール間の結合や業務シナリオのチェックに集中できなかった（障害原因（1））
• テスト項目に挙がっていない障害が多発し、その対応に追われた（障害原因（3））

　これらの意見をまとめて、「テスト項目の妥当性とは何か？　そもそも品質とは何か？」という経過をたどり、「品質とは何かを再認識し、その品質を保証するやり方に改善していこう」という結論に至った。

　品質とは何か？　メンバー間でもかなり認識の違いがあったが、「品質とは、システムが顧客のニーズを十分に満たしていること」「テストの完了基準はこれを確認すること」と全員で認識の再確認をした。

　ただし、この考え方には前提がある。顧客のニーズが漏れなく正確に把握され、要件定義書、設計書（以下、上流成果物）に反映されているのが前提だ。そのためには、上流工程の不具合が下流工程で多数検出されるようでは心もとない。また、もし完ぺきな上流成果物が存在したとしても、テスト仕様に反映漏れが発生するといったような、品質の確認プロセスに脆弱性があっては意味がない。

　これらを踏まえ、今回の改善ポイントを以下の通りとした。

• 改善ポイント（1）：上流成果物と下流成果物の対応関係を明らかにし、テストの観点を整理する
• 改善ポイント（2）：テスト設計を対応する上流成果物作成の直後に行い、上流工程の不具合を早期に発見する

　このようにして、改善ポイントを抽出したところで振り返りミーティングは終了した。

品質は作り込んで確認する

　1カ月後、X社は新たな生産管理システム構築案件を受注した。プロジェクトマネジャーは、振り返りミーティングで合意した通り、プロジェクト早期にテスト計画を行うこと（改善ポイント（1））、テスト設計作業を前倒しすること（改善ポイント（2））を計画に盛り込んだ。新規参画のメンバーにもその内容を伝え、改善する目的と方針を共有した。

　プロジェクト開始と同時にテストチームリーダーはテスト計画の策定活動を開始した。上流工程のプロセスで、「どのような観点で要件や設計事項を明確にしていくか」を規定しているのと同様、確認テストについてもテスト観点を整理していく。例えば、ユースケースとユースケース記述は、ユーザーとシステムとの相互作用の観点で作成される成果物であり、テストでは機能の観点から確認すべきもの（機能テスト）として位置付け、機能テスト仕様書のテンプレートを作成した。同様に上流工程の各成果物に対して、テスト観点とテスト仕様書のテンプレートを用意した。

上流工程成果物とテスト観点

　要件定義工程では、業務担当者がユースケースや非機能要件定義書のα版を作成した時点で、テスト設計担当者は対応するテスト仕様書の作成に着手した。この過程で、基となる設計書の内容や記述方法によっては、どのようなテストを行えばよいか不明確な点も発生する。そこで、「確認のしようがない仕様は品質が作り込めていないことと同義」という認識の下、業務担当者にフィードバックするようにした。業務担当者は仕様記述の見直しや要件の再協議をすることになり、これが上流成果物の精度向上につながることとなった。

　テスト設計担当者は、各テスト項目に基となった仕様個所も明記しておくようにした。テスト仕様書が作成されると業務担当者は内容をレビューし、要件が漏れなくテスト仕様に反映されているかどうかのチェックも行った。この段階を経て、上流成果物とテスト仕様書の最終顧客レビューが実施された。さらに、要件や設計の内容によっては、テスト仕様書の方が顧客に確認を取りやすいことも判明した。これは予想外の効果だったという。

　こうして設計工程の終了時には、結合テストとシステムテストで実施する全テスト仕様書が完成した。実装工程でプログラムが作成されている間、テストチームは、前回プロジェクトのデータから単体テストで検出すべきであった不具合の分類を行い、簡単な単体テスト時のチェックリストを作成した。結合テスト以降のテスト観点に集中できるように、モジュールレベルの不具合は単体テストでできる限り検出／修正しておきたいとの思いがあったためだ。

　結合テスト、システムテスト工程では、テストチームと業務担当者が既にレビュー済みのテスト仕様書を基にテストを実施した。X社では、テスト検証プロセスの品質指標として、FP（ファンクションポイント）当たりのバグ検出数を定めていたが、今回のテスト工程ではこの目標は未達成となった。しかし、この指標は改善プロセスを適用する以前のプロジェクトから算出された数値であること、上流工程からテスト仕様を作成し顧客と合意した仕様に基づき確認および修正を完了したことを根拠にテスト工程の完了が認められた。

顧客納品を迎えて

　いよいよ顧客の受け入れテストの時期がやってきた。今回のテスト工程でも深夜まで作業が及ぶこともあったが、徹夜はなく、休日出勤もたまに発生する程度であった。しかし前回と異なり、チームメンバーは品質に過度の不安を抱くことはなかった。テストで確認すべき観点に漏れがないように最初にチェックし、テスト項目をタイムラグなく抽出して、それらについて確認し不具合を修正してきたからだ。

　受け入れテスト後の障害報告を含めて、その原因分析をした結果を以下に示す。

障害の原因（改善後）

　同じ業務ドメインのシステムとはいえ、顧客も違えばシステム規模も若干大きいので単純比較はできないが、テスト項目漏れ95％減少、設計ミス80％減少、要件定義ミス60％減少という結果となった。

　結局、X社は受け入れテストをスケジュール通り完了し、期日通りのサービスインにこぎ着けることができた。工数面では、5％の超過という結果となったが、これはテスト観点ごとのテンプレート新規作成や、テスト設計を上流工程で行った際の試行錯誤に掛かった作業負荷が一因として挙げられる。

　これらを踏まえると、品質向上、納期順守の点で、ある一定の効果は示せたといえるだろう。また工数面での超過は、プロセス改善のイニシャルコストとして見なして、これからのプロジェクト、組織への横展開で十分回収できると思われる。

　数値化されない評価について、メンバーにヒアリングした結果を以下にまとめる。

【メリット】

・ライフサイクル全体の負荷の平準化

　テスト設計を上流工程で実施することによるテスト工程の過度の負荷軽減

・テストのゴールの明確化

　達成すべき品質が明らかになることによるテスト完了判断の確立

・要件・設計・テストの追跡容易性

　テスト項目ごとに要件・設計へのポインタを残すことによる妥当性検証の負荷軽減

【課題】

・要件変更への追従

　早期にテスト仕様書を作成しまうことによる、要件変更時の負荷増大

・テスト担当者のアサイン

　テスト技法に加えて、業務担当と同等かそれ以上の業務ドメイン知識が必要

テストプロセス改善

　今回は、品質確保のアプローチからテストプロセスを改善し、納期順守を達成した事例を紹介した。

　プロジェクトの早期にプロジェクトや顧客のニーズからテスト観点や深さを検討し、上流工程成果物との対応関係を明らかにすることによって、適切なレベルの品質を定義する。さらに、業務担当とは別の担当が上流工程に追従してテスト設計を実施することにより、上流工程での不具合の早期発見を促す。つまり、「テスト工程で不具合を検出し品質を確保する」という考えではなく、「品質を上流工程から作り込み、テスト工程にて確認する」という考えに基づき、テストプロセスの改善を図った。

　この改善により、テスト工程で検出されていた上流工程の不具合による手戻り工数が削減される。上流工程の負荷は増大するが、下流工程で実施していた作業が前工程へシフトしただけで、ライフサイクル全体としては、負荷は平準化される。

　プロセス改善という面では、メンバーで課題や改善方針を共有していたことと、効果的であろう部分からスモールスタートで改善に着手したことをポイントとして挙げておく。

　X社では、メンバー全員による振り返りミーティングの実施により、現状を定量的に把握し、効果的な改善点を見いだした。ミーティングでは、ソフトウェア工学やマネジメント体系、他社の改善事例などの知識を有したファシリテート役の存在も重要となる。もちろんその人物が改善方針や改善策を打ち出すのではなく、メンバーの意見を尊重し、知識やスキル面での支援を行い、メンバーら自身が改善の方向性を決定するのである。「われわれの改善」というモチベーションは、プロセス改善を成功に導くためには不可欠な要素である。

　今回の例では、いきなり改善策に飛び付かずに、現状把握から改善できそうな個所で効果がありそうなプロセスを特定し、改善ポイントを絞って取り組みを開始したことがプロセス改善の成功につながった。小さくても良いので、まず成果を挙げ、プロセス改善を継続できる風土を作り上げることが重要なのである。

＜筆者紹介＞

辻 大輔氏

株式会社豆蔵 BS事業部　エンタープライズチーム コンサルタント

専門分野：開発プロセス、要求開発

ソフトウェアベンダー数社でソフトウェア開発やSPI活動などに携わった後、2008年より株式会社豆蔵に在籍。現在はコンサルタントとして、ソフトウェア開発プロセスのアセスメントや適用支援に従事している。

関連ホワイトペーパー

生産管理 | バグ | 開発プロセス | システム構築