品質管理のスコープは「プロジェクトの全工程」

石井：私はテスト管理ツール「CAT」、テスト設計支援ツール「TD」の開発・マネジメントを担当する部署におり、それらを紹介することはもちろん、品質管理の重要性を啓蒙していくことが責務だと感じています。

最近システム更改の大規模プロジェクトに関わったのですが、思うように進まないもどかしさや大変さを痛感しました。

こうした場面での品質管理方法は、あまり世に出回っていないんですよね。今回は、そのコツを原田さんに聞いてみようと思います。

原田：私は90年代からソフトウェア開発に携わっており、大規模プロジェクトのマネジメントを行ってきました。

最大約200名のチームを率いた経験があります。今日はその経験をもとにお話しできればと思います。

石井：まずは、今回取り上げる「大規模プロジェクト」の定義について。

ここでは、大規模プロジェクトを「数年から十年の期間で、数十億円から数千億円の投資が行われるもの。関わる人数がピーク時には数千人、全期間でのべ数万人におよぶことがあるもの」と定義します。

これらのプロジェクトでは、複雑なシステムを構築する一方で、要求や期待の異なる多くのステークホルダーが関与しているため、調整が非常にむずかしいです。

原田：そうですね。こうした案件は、特に金融や公共、製造業などの分野で見られることが多いです。

これらのプロジェクトでは、開発する機能や参画する人数が多く、品質管理が非常にむずかしいという特徴があります。

例えば、金融システムでは、セキュリティや信頼性が最優先されるため、品質管理の手法も特に厳格になります。

石井：今回はシステム開発の全工程を取り上げます。つまり、要件分析からはじまり、システム設計、実装、テスト、そして受け入れテストまでの流れを見ていきます。

原田：そのなかで、特に注意が必要なポイントを石井さんとディスカッションし、具体的な対策を考えていきましょう。

要件分析のフェーズから話すことについて、なぜソフトウェアテストシンポジウムであるJaSSTで取り上げるのか疑問に思うかもしれませんね。

それは、上流工程での品質が担保されていなければ、後の工程に大きな影響を与えてしまうためです。そのため、本セッションでは初期段階からの徹底した管理についてお話できればと思います。

フェーズ別でみる、品質管理のポイント

フェーズ1：要件定義

石井：まずは、要件分析について。この工程では、お客様の要求をヒアリングしたり、業務フローを提案したりします。「要件のレビューと合意形成」がこのステップのゴールといえそうです。

特に大規模プロジェクトでは、関わるステークホルダーが多くなり、必要な機能も取り扱う業務も多くなることから、要件が漏れがちですよね。

以下に、このステップで現れそうな問題をピックアップしてみました。

原田：要件を漏れなく洗い出すためには、ステークホルダーをリストアップし、計画的にヒアリングを行うことが必要です。

お客様から要件をいただく際には締切を設けると、計画を立てやすくなります。また、定期的に進捗を確認し、必要に応じて追加のヒアリングを行うことも重要です。

さらに、現場の実務者の意見も重要です。彼らの視点を取り入れることで、より実態に即した要件定義が可能になります。

可能な限り、要件定義の担当者が実務者（現場のリーダーなど）から直接声をひろうことが理想的ですね。

石井：私も経験があるのですが、現場にヒアリングしていると、要件が無尽蔵に出されることがあるんですよね。

原田：そうですね。金融のようなプロジェクトでなければ、90～98％聞き出せれば十分でとして進め、残りはあとから巻き取ることもできると思います。

私はいつも、シグモイド曲線（当初は緩やかな増加からはじまり、その後急激に増加し、最後に再び緩やかに増加が鈍化するような形状の曲線）をイメージして要件をヒアリングしています。

要件数を時系列でみると、このあたりで完了とするという判断がしやすいかなと。

石井：OSバージョンアップといったシステム刷新の場合、より便利なシステムを追求して、業務フローまで改革するか、現行踏襲するかという点ではどうお考えですか？

前者の場合は業務コンサルが必要ですが、予算がないという企業も多いですよね。

原田：実際に業務がしづらい状況なのか、現場は満足しているのか、という点で見極めるのがよいでしょうね。

生産性が悪ければ業務フローを変えたほうがいいでしょうが、例えばUIを変えると、大規模システムの場合のちのち多額の教育コストもかかってしまいますからね。

フェーズ2：システム設計

石井：次に、システム設計（外部設計、詳細設計）の段階に移ります。この段階では、システムアーキテクチャやUI／UXなど、外部インターフェースの仕様を明確に定義することが求められます。

大規模プロジェクトになると、インターフェースの仕様について、設計書で整合性が確認できない場合が多い感覚があります。

しかし、その不整合が解決されることなく次の過程に進んでしまうことがありますよね。PMの立場として、どのように不整合を検知したり、防いだりすればよいでしょうか。

原田：まずは、APIのリファレンスマニュアルのようなレベルで、外部インターフェースの仕様書を例外処理まで含めてつくること。

これにより、開発者が実装する際の指針が明確になり、後のトラブルを防ぐことができます。

インターフェースの仕様をきっちり決めてしまえば、プロトタイプをつくってシステムの開発と自動化されたテストを同時に進められるメリットもあります。いうなれば、「テスト駆動型の開発」が可能になるわけです。

静的解析ツールを活用することで、早期かつシステマチックに整合性を確認できます。設計レビューを定期的に行い、チーム全体での合意形成を図ることも重要です。

石井：インターフェースを組める人材は、限られてしまうのではないでしょうか？

原田：そうですね。インターフェースの設計は初心者ではなく、例外設計まで行える方を起用することが重要だと思います。

インターフェースを設計するチームをつくってしまえば、それ以外の人材が並行して開発に打ち込めますから。

フェーズ3：実装／コンポーネントテスト・結合テスト

石井：次は、実装／コンポーネントテスト・結合テストのフェーズにおける品質管理についてです。

課題の一つとしてスライドにもあげた「インターフェースの実装不足」は、さきほどのシステム設計のフェーズでの話で事前に回避されますね。

実装したものをデプロイするときに「成果物の質が読めない」といった課題はテストをやる意義にもつながってくるのかなと感じましたが。

原田：実装後のコンポーネントテストや結合テストでも、事前に定義したインターフェースに基づいてテストを行うことで、品質を確保できると思います。

なにより先ほど申し上げたように、基本設計のフェーズからあいまいさを残さないようにする、そしてテスト駆動型開発を行うことが重要ですが、コンセンサスを取っておく努力も必要ですね。

フェーズごとに体制を組み替えていくこともあると思います。

フェーズ4：システムテスト

石井：システムテストでは、他システムとの結合が増えるため、シナリオの洗い出しが重要ですよね。関連するシステムやシナリオの数がかなり増えてくると思います。

シナリオを洗い出すうえで、重要となるポイントはありますか？

原田：BtoBの場合は、要件定義の段階で洗い出した業務シナリオを基に、テストシナリオを作成することが基本です。

BtoCの場合は、エンドユーザーがシナリオ通りに操作してくれる保証はありませんから、アドホックに頼る場面もあると思います。

石井：シナリオテストは人数が多くなりがちですよね。そして、一部のテストが進んでいなかったという話も多数見聞きします。モニタリングはやはり必要ですよね？

原田：そうですね。朝会や夕会などで進捗状況を報告してもらっているプロジェクトが多いのではないでしょうか。

その点、SHIFTのテスト管理ツール「CAT｣が便利なのは、リアルタイムで状況把握できることですね。「実は1週間、進捗がなかった」とあとで判明することが起こらない。

そうした状況把握とともに、エンジニアが困ったらエスカレーションしてもらえるように、体制を整えておく工夫も求められるでしょうね。

フェーズ5：受け入れテスト

石井：最後に、受け入れテストについて。これまでの工程では、どちらかというと開発者が主体となっていました。これからは、エンドユーザーに届ける、テストしてもらう視点が必要になります。

エンドユーザーの習熟度を上げることはむずかしく、その段階になって想定外の不具合が発生することは多いと思います。受け入れテストをスムーズに進める方法はありますか？

原田：段階的なリリースが効果的です。まずは情報システム部門が動作確認を行い、その後一部のエンドユーザーにベータ版を提供してフィードバックを得るという流れが理想です。

ただし、スケジュールに余裕がない場合もあるので、状況に応じて柔軟に対応することが求められます。不安があれば、受け入れテストの流れについても、事前にコンセンサスをとれるといいですよね。

石井：現場にしかわからない観点での指摘があがることもありますよね。それが要件漏れだった、という場面に何度か出くわしたことがあります。

原田：要件漏れがあった場合は、どの要件が本当に必要かを精査し、計画を立て直すことが重要です。私の場合は、スケジュール、費用、人員などを総合的に考えて判断しています。

受け入れテストまでを含めた全体スケジュールをしっかり立てて、コンセンサスをとって人員の時間も確保しておくというのが大切だということになりますね。

質疑応答

――要件を洗い出すにあたって、メンバーのスキル感がバラバラな場合、どうやってリテラシーをあげることができるのでしょうか？

原田：いい質問ですね。ヒアリングする側のスキルも磨くことが重要です。具体的には、成果物の粒度を合わせるための会議を設けたり、モックを用意したりして具体的なイメージを共有することが効果的です。

――要件漏れが発生するのは避けられないと思いますが、どのように対応すればいいでしょうか？

原田：先ほどもふれましたが、100%の要件を洗い出すのはむずかしいと思います。私自身は98%ぐらいを目標にしています。

漏れた要件は、後のフェーズで対応することを前提に計画を立てておくとよいでしょう。

法律上やらなくてはいけない、生産性は悪いけれど使われないことはない、といった要件の取り込み基準をあらかじめ決めておくことで、重要な要件を見逃さないようにすることも大切です。

（※本記事の内容および取材対象者の所属は、イベント開催当時のものです）