開発ベンダーとのすれ違いを防ぐには？期待通りの納品に向けて発注者ができること

開発ベンダーにシステム開発を依頼したものの、「思っていたものと違う」納品物が上がってくる。そんなトラブルに悩んだことのあるユーザー企業は少なくありません。

こうしたトラブルの背景には、「プロジェクト初期からのすれ違いが放置されたまま開発が進行してしまう」という問題があります。 要件定義から開発、確認フェーズまでの間でコミュニケーションが不足していると、認識の違いがそのまま納品物に反映されてしまうのです。

本記事では、開発ベンダーとのすれ違いを防ぐために、ユーザー企業ができることについて解説します。

開発プロジェクトにおける『第三者検証』の重要性とは│資料ダウンロード

ユーザー企業と開発ベンダーのすれ違いが起きる理由とは

システム開発における開発ベンダーとユーザー企業のすれ違いの多くは、コミュニケーション不足に起因します。

立場の違いによる視点のズレや要件定義の曖昧さなどが放置されたまま開発が進行した結果、後工程で重大な不備が表面化することも少なくありません。

まずは、ユーザー企業と開発ベンダーの間ですれ違いが起きるメカニズムを整理します。

立場の違いがすれ違いを生む 

前提として、ユーザー企業と開発ベンダーは、次のように異なる立場からプロジェクトにあたっています。

ユーザー企業：
エンドユーザーが使いやすいアプリや業務改善に役立つシステムが欲しい

開発ベンダー：
契約通りの内容での開発・納品を目指す

この違いにより、完成したシステムに対する合格ラインが一致しないことは多々あります。

開発ベンダーが「発注書通りに作ったから問題ない」と判断しても、ユーザー企業は「実際の業務では使いづらい」と感じてしまう。立場の異なる両者が十分にゴールのすり合わせを行わないまま協業した場合、このようなすれ違いが発生するのです。

ユーザー企業側の完成イメージが曖昧である

ユーザー企業のオーダー通りに開発ベンダーが開発しても、期待外れなシステムが開発されてしまうことは少なくありません。

ユーザー企業側が開発の知識を持ち合わせておらず、自社の定義した要件がどのように実装されるのか正確に理解できていなかったり、運用のイメージを十分に持たないまま依頼したりした場合、こうした問題が発生しやすくなります。

ヒアリングによって発注者のニーズを明確にし、それを仕様に落とし込むのは開発ベンダーの役割です。ただ、担当者のヒアリングが十分ではなかったり、コミュニケーションに行き違いが生じたりした際のリスクを最小限に抑えるためには、発注者側でも事前に理想とするイメージを言語化しておくとより安心です。

ドキュメントの不備により解釈がズレる

メモや口頭でのやりとりをベースに設計が進んでしまい、開発ベンダーとユーザー企業の間で「伝えたつもり」「聞いたつもり」のすれ違いが発生するのも現場ではよくある話です。

特に、小規模案件やスピード重視のプロジェクトでは、記録の整備や仕様レビューが省略されることも少なくありません。担当者の記憶に頼るかたちで設計が進むことで、後工程になるほど発注者のニーズとのズレが広がっていくのです。

また、ベンダーが複数関わる案件では、関係者の間で情報の分断が起きやすく、認識のズレが連鎖的に広がることもあります。

リソースや経験不足により受入テストが機能しない

たとえ要件定義・開発段階でズレがあったとしても、システムやソフトウェアが業務要件を満たしているかを確認する受入テストが機能していれば、リリース前に修正することができます。

しかし実際の開発現場では、受入テストが十分に行われないことも多くあります。「時間がない」「IT知識がない」などの理由で正常系のみの確認に終始し、実際のユーザー操作を想定した異常系の確認が不足することで、リリース後まで不備が放置されるケースもめずらしくありません。

受入テストを機能させ、すれ違いを解決するために

リリース前に認識のズレを解消するための要となるのは、最終調整の機会である受入テストです。この受入テストを正しく機能させるには、必要なテストケースを網羅し、過不足ないテストを実施することが求められます。

ここでは、受入テストで頻発するトラブル事例を挙げながら、その改善に向けて発注者側が取り組めるポイントを紹介します。

よくある受入テストのトラブル事例

受入テストでは、確認漏れや観点不足が思わぬトラブルにつながることがあります。
主なトラブルとしては、以下4つのパターンが挙げられます。

1. 実際の使用イメージが不十分なままテストが実施される

受入テストを設計する際に、現場での運用を踏まえた視点が不足していると、実務にそぐわない点が放置されたまま納品されてしまうケースがあります。

例えば、販売管理システムの開発では、「帳票のCSV出力には対応していたものの、現場で使用している既存のフォーマットと異なる形式で出力されるため、毎回手直しが必要になった」といったケースが考えられます。

結果として、業務フローが回らなくなり、リリース後の手戻り・追加開発のコスト発生につながるのです。

2. 確認基準が曖昧なまま進められ、判断のブレが生じる

「表示されていればOK」「エラーが出なければOK」といった曖昧な基準のままテストを進めると、微妙な表示レイアウトのズレや、業務上重要な処理の仕様差異などが見逃される可能性があります。

また、チーム内で判断基準が明確化されていないことで、合否判定の食い違いによる余計なコミュニケーションコストの発生にもつながります。

3. 実行内容が記録されず、後からの検証ができなくなる

担当者が通常業務に追われるなかで受入テストを兼務するケースでは、結果の記録が省略されることも少なくありません。

しかし、「何を確認して、どんな結果だったか」の記録が残っていないと、不具合発生時に「そもそも確認されていたのか」をさかのぼって確認できず、責任の所在が不明確になりがちです。また、修正の影響範囲や過去の仕様判断をたどれないことで、再テストの工数増加にもつながります。

4. 担当者のスキルや経験によって、観点が抜け落ちやすい

テスト業務に不慣れな担当者の場合、必要な観点が抜け落ちやすく、正常系の確認だけで済ませてしまうといったことも起きがちです。異常系や想定外の操作がテストされないままリリースされてしまうと、リリース後に不具合が頻発するリスクが高まります。

よりよい受入テストを行うための工夫

適切な受入テストを行い、リリース前に納品物の不備を発見するためには、テスト設計やスケジュール管理の面でさまざまな工夫が必要とされます。

受入テストをしっかりと機能させるためのポイントとして、主に以下のようなものがあります。

要件定義書だけに依存せず、テスト時にあらためて業務ゴールや確認観点を明文化する

プロジェクト初期に作成された要件定義書は、必ずしも現場の業務すべてを正確に反映しているとは限りません。そのため、受入テストの段階で「業務として本当に成立するか」という観点から要件定義に立ち戻り、確認すべきポイントや合否基準を再検討することが重要です。

業務システムの場合は、実際に使用する部署とコミュニケーションを取り、使用環境（デバイスやブラウザなど）や機能ごとの使用頻度などをすり合わせておくことで、影響度の大きい不具合の防止につながります。

受入テスト設計・準備に必要な工数をスケジュール上あらかじめ確保する

受入テストは、通常業務の隙間を縫った空き時間に実施されることが少なくありません。しかし、異常系を含めて必要なテストケースを網羅するためには、受入テストのために一定程度の工数を確保することが必要です。

受入テストに十分な時間を割くためには、プロジェクト初期の計画段階から必要工数を明確にしておくことが求められます。

業務フローに沿ったシナリオやチェックリストを用意し、属人性を解消する

担当者ごとの経験や判断力に依存すると、テストの品質や網羅性にばらつきが生じます。こうした属人性の高い状況を解消するには、実際の業務フローに沿ったシナリオや確認項目を整理し、チェックリストとして共有することが重要です。こうすることで、誰が実施しても一定の品質を担保できる体制をつくることができます。

受入後のトラブルに備え、開発ベンダーの対応方針（例：無償対応期間など）を確認しておく

どれだけ入念にテストを実施しても、不備を完全になくすことは困難です。そこで重要となるのは、リリース後に不具合が見つかった場合の対応について、ユーザー企業・開発ベンダー側ですり合わせをしておくことです。「納品から◯日以内であれば無償対応」「重大な業務影響がある場合は即時対応」といった対応条件を事前に合意しておけば、トラブル発生時にもスムーズな修正対応につなげられます。

テストの専門知識を持った第三者視点の支援を受ける

受入テストには、現場の関係者だけでは気づきにくい観点や、限られたリソースでは対応しきれない工程も少なくありません。テストに関する知見や担当者のリソースに懸念がある場合は、テスト支援会社を活用するのも1つの手です。専門知識を持ったテストエンジニアが設計から実施まで担当することで、観点の抜け漏れを補完し、品質の底上げを図ることができます。

プロジェクトを前に進めるために、ユーザーと開発ベンダーができること

プロジェクトを円滑に進行させるには、立場の違いによるズレを前提とした準備と、継続的な対話が欠かせません。ここでは、ユーザー企業と開発ベンダーが協働するために意識したいポイントを紹介します。

事前の合意とすれ違いを前提にした体制づくり

ユーザーと開発ベンダーでは立場や判断軸が異なる以上、認識のズレが発生するのは自然なことです。

そのため、プロジェクトの初期段階で責任範囲や対応の線引きを明文化しておくことが重要です。どこまでが開発ベンダーの対応範囲で、どこからがユーザー側の判断になるのかを明らかにしておくことで、トラブル発生時に責任の所在に関してもめることなく解決に向けてスムーズに動きだすことができます。

また、プロジェクトでは想定外の変更がつきものです。あらかじめ予備の予算や柔軟な契約条件を設けておくことで、イレギュラー対応の際にも関係がこじれにくくなります。

目的の共有と、対話を続けるためのコミュニケーション設計

開発プロジェクトを成功させるための鍵は、ユーザー企業と開発ベンダーが共通のゴールに向けて協業することです。そのために必要となるのが、主体的にコミュニケーションをとる姿勢です。プロダクトを通して実現したい業務改善やユーザー体験を細部まで言語化する努力が、ニーズを叶える成果物の納品につながります。

また、要件定義のフェーズに限らず、開発が開始してからも進捗を確認しながら互いの認識を継続的にすり合わせていくことが大切です。例えば、定例ミーティングや中間レビューの場を設けることで、小さなズレに早期に気づき、修正することが可能になります。

こうした対話の機会をプロジェクト設計の初期段階から組み込んでおくことで、手戻りや炎上リスクを大幅に減少させることができます。

開発ベンダーとのすれ違いを防ぎ、期待通りのシステムを完成させるために

ユーザー企業と開発ベンダーのすれ違いは、根本的な立場の違いに起因する部分が少なくありません。立場や目的の違いがあるからこそ、開発ベンダーに任せきりではなく、発注側も主体性を持って認識合わせに取り組むことで、プロジェクトの成功確率を高めることができます。

特に受入テストは、業務要件と実装結果が合致しているかを最終的に確認する重要なフェーズです。ここでの確認を曖昧にしてしまうと、手戻りに大きなコストがかかるだけでなく、運用開始後の業務停滞やクレーム対応といった実害につながるリスクがあります。

AGESTでは、受入フェーズにおいて、テストの専門知識を持ったエンジニアが第三者視点での観点設計や実行支援を行っています。限られた時間でも確実な検証を実現したい方は、ぜひ一度ご相談ください。

ソフトウェアテスト サービス詳細ページ

TFACT (AIテストツール)

関連コンテンツ