認識のズレを防ぐ！開発プロジェクトで失敗しない要件の伝え方

はじめに

「思っていたのと違う」「要件がうまく伝わらない」――

システム開発プロジェクトを進めていく中で、こうした問題に直面したことはありませんか？

プロの開発ベンダーに依頼すれば、期待通りのシステムや機能が作られるはず…
そう思っていたのに、

• 実際に出来上がったシステムが想定と異なっていて
• 追加の修正や仕様変更が必要となり
• 費用と工数がかさんでしまった

という経験をした方も多いのではないでしょうか。

こんにちは。mcsのT.Mです。
今回は、システム導入・開発プロジェクトをご担当されている方に向けて、開発要件を伝える際に気をつけると良いポイントをご紹介させていただきます。

私自身も元々は技術者ではなく、発注者として開発ベンダーに依頼をする立場でしたが、技術的な知識が不足している中で「思い描いた要件を正しく伝える」ことの難しさに悩んだことが何度もあります。

今回は、発注側・開発側双方の立場でプロジェクトに参画してきた経験も踏まえ、システム開発をスムーズに進めるために発注者が知っておくべきポイントを紹介します。

今回の記事は、こんな方におすすめです。

• システム導入プロジェクトを担当することになったが、どのように要件定義を進めればよいのかわからない
• ベンダーに構築・開発を依頼しているが、意図した要件が伝わっておらず修正・仕様変更が多発して困っている
• 納期を最短に、費用を最小限に抑えるために、手戻りの少ないプロジェクト進行をしていきたい

なぜ、考慮漏れや認識のズレが起きるのか？

システム開発の現場では、発注者(システム導入担当者）とベンダー(開発者)の間で認識のズレが生じやすい構造的な問題があります。

ベンダーの役割は、

「言われたとおりに作る」だけでなく、依頼者が実現したいことを理解し、仕様に落とし込んで実装すること

です。開発の技術に関しては豊富な知識を持っていますが、企業側の業務フローや部門ごとの役割、業界固有のルールについては理解が十分でないことが多くあります。

一方で、発注者の役割は、

業務上の課題や目的を明らかにし、ビジネス上の要件からあるべき動作や機能を決定すること

です。しかし、システムや技術に関する知識が不足しているため、システムのふるまいとして何を決めなければいけないか、どう伝えればベンダーに意図が伝わるのか分からず、曖昧な依頼になってしまうこともあります。

双方の立場からして当たり前なことではありますが、この前提を意識せずに開発を進めた結果、トラブルや仕様変更が生じる、といったケースが多くあります。
システムと業務の双方に精通する人がいない場合が多いため、相互に共通の前提と認識を持って会話を進めることが難しくなり、微妙なズレが積み重なって考慮漏れや認識相違が生じてしまうのです。

ベンダー側からすれば、

「要望通りに実装し、仕様も確認・合意した」

となりますし、発注者側からすれば、

「明確な指定はしなかったかもしれないが、挙動として普通考慮すべき」
「難しい言葉や専門用語で仕様を細かく説明されても、抜け漏れをチェックしきれない」

といった、食い違いが生じます。

発注者側にシステム理解の深い担当者がいればこの問題はある程度解消できますが、そうでないケースも多く、プロジェクトが進むにつれて不一致が表面化しやすくなります。

このような知識や認識のギャップは、

開発ベンダーが業務フローと要件をヒアリングし、専門的な知識が少ないお客様に対しても伝わる形で仕様に落として実現する

という形で埋めていくのがあるべき状態です。
mcsでは、できる限りこのような食い違いが起きないよう、お客様が実現したいこと・抱えている課題の解決に焦点を当て、丁寧なヒアリングと設計・実装を心がけています。

一方で、発注者から提供される情報が断片的であったり、相互のコミュニケーションが十分でないために、このようなギャップを認識できずに後から問題が発覚するケースもあります。

考慮漏れや認識のズレが起こる例

典型的な例として、「こういう機能を作ってほしい」という処理内容のみを伝えて依頼をする場合等が挙げられます。

このような依頼の場合、ベンダー側は言われたとおりに機能を実装することはできるかもしれません。
しかし、その機能が何の課題を解決するための機能なのかが明確でないため、求められる動作を満たすために考慮すべきパターンや条件分岐があるかについて、判断しにくくなります。

例えば、

「見積提案後30日間進展がない顧客に対して自動でフォローアップメールを送信する機能を作ってほしい」

という依頼があったとします。

ベンダーは依頼内容通りの機能として実装を進めますが、
実際の運用においては

• 同一メールを短期間に複数回送らないようにしたい
• トラブル対応中や条件交渉中のお客様には送らないようにする

といった例外処理が必要だった場合、要件としてそれが伝わっていなければ、送りたくない顧客に対しても条件に合致する限り毎日メールが送られてしまう結果になるかもしれません。

このような微妙な条件調整・例外処理を、最初からシステム処理条件としてもれなく定義したうえで要件として伝えられれば良いのですが、実際には要件提示の段階ですべてを考慮して伝え切るのは難しい場合も多いでしょう。

そこで、要件とあるべき仕様を固めていくために、ベンダーと発注者との間でのすり合わせの作業が大事になってきます。
この際、処理が必要になった背景や目的を共通認識とすることで、ベンダー側でも必要な処理や実装時の考慮ポイント、懸念事項について検討し提案することができるようになります。

では、どのようなポイントを押さえて要件と開発要望を伝えると、相互のすり合わせがうまくいきやすいのでしょうか。

認識のズレを防ぐために共有しておくべき4つのポイント

発注者がベンダーに対して以下のような情報を共有することで、考慮漏れや認識のズレを防ぎやすくなります。

現状の業務フロー

現在の業務フロー(どのような時に、どのようなシステム操作を行って業務を実施しているか）を詳細に伝えることで、ベンダーが背景を理解しやすくなり、適切な機能設計が可能になります。
例えば、手動で行っている処理が多く業務が非効率になっている、などの背景が分かれば、改善案も検討しやすくなります。

例)
現在、営業担当者が毎週金曜日に、各自でフォローアップが必要な顧客をリスト化し、そのリストに基づいて手動でメールを送信している。
リストの対象となる顧客は「見積提案から30日が経過した顧客」で、営業担当者が手動でリストを確認し、顧客との過去のやり取りに基づいてフォローアップが必要かどうかを判断している。
特定の顧客に対してはフォローアップが不要（例えば、取引が完了した顧客や商談が一時保留中、トラブル対応中の顧客）として手動で除外している。

抱えている課題

現状のフローにおいて問題となっている点、システムにより解決したい課題を明確にすることで、開発の方向性が具体化されます。
システムが解決すべき課題が明確になると、ベンダー側も必要な機能や仕様について提案しやすくなります。

例)
手動でリストを更新・確認するのが手間であり、また、リストの見落としや判断ミスによってフォローアップが必要な顧客への対応が漏れる可能性がある。
過去のやり取りを毎回確認する必要があり、毎週の作業負担が大きい。また、営業担当者ごとに判断が異なるケースがあり、対応にばらつきが出ている。

目指すべき状態

開発により実現したい成果や、理想の状態を共有することで、プロジェクトのゴールが明確になります。
この認識を共通化することで、ベンダー側もそのゴールを達成するための機能を優先的に開発することができます。

例)
自動化によりリスト確認や手動送信にかかる負担を軽減し、効率化をしたい
適切なタイミングでのフォローアップをもれなく行い、商談の成約率を上げたい。

期待する動作・機能

システムがどのように動作し、ユーザーがどう利用するか、具体的な操作イメージを共有することで、開発中に生じる認識のズレを防ぎます。
具体的な画面のイメージを簡単に図で示したり、フロー図にしたりすると、認識の共有に役立ちます。

• いつ、どのような条件で、どのような処理を行うか
• 例外や分岐条件はあるか

といった点を整理して伝えるとよいでしょう。

例)
毎週月曜日の朝に、見積提案から30日間進展がない顧客に対して自動でフォローアップメールを送信したい。
メールには、顧客への簡単な挨拶文と「お困りのことがあればお知らせください」という内容を含めたい。
ただし、各顧客への送信頻度は1か月に1回までとし、短期間での重複送信は避けるように設定したい。
商談がクローズしている顧客や、条件交渉中の顧客には送らないようにしたい。

このように現状のフローと解決したい問題を共有したうえで、その解決のための機能として求める期待動作を要件として伝えることができると、ベンダーは、その目的に照らして検討と開発を進めることができるため、

• システムのふるまいとして追加で考慮が必要な事項がないか
• より詳細に条件を確認すべき部分はどこか

などを確認しやすくなり、仕様の抜け漏れを防ぐことにつながります。

プロジェクトをスムーズに進めるためのヒント

プロジェクトをスムーズに進め、トラブル発生リスクを抑えるためには、以下のような工夫を取り入れると効果的です。

初期段階でのドキュメント化や画面イメージの活用

初期の段階において、画面イメージや簡単なフローチャートなど視覚的にイメージを共有することで、抽象的な表現から生じる認識のズレを防げます。
プロジェクトメンバー全員が理解しやすい形で要件を整理しておき、詳細の仕様は要件定義を進める過程で開発仕様としてドキュメントに残して双方の認識統一と合意の結果としてまとめおく、といった進め方が効果的です。

定期的な進捗確認やデモの実施

プロジェクトや個別の開発課題の進行状況を定期的に確認し、途中で認識がズレていないかを確かめることが重要です。
可能であればデモやモックの確認を通して実際の機能を確認することで、早い段階でのフィードバックが可能です。

動作テストの実施

設計した仕様通りにシステムが動作するかという点はもちろんですが、業務で使用する想定で本番同様の操作をしてテストを行い、想定外の挙動が起きるパターンがないか、できる限りチェックをしたうえで機能をリリースすることが望ましいです。

まとめ

開発要件の伝え方は、プロジェクトの成功を大きく左右します。
開発を依頼するベンダーは、システムについてはプロですが、皆さんの会社のビジネスや業務の流れについては素人です。
社内の人なら「当たり前」となっているようなことも、ベンダーには明確に伝えないと認識できないこともあります。

前述のように、機能としての要望だけではなく、

• 現状の業務フロー
• 抱えている課題
• 目指すべき状態

を正確に伝え、その実現のための検討を双方協力して進めていくことで、認識のズレや仕様変更を減らし、スムーズなプロジェクト進行が可能になります。

お互いの役割を認識したうえでコミュニケーションを取り、期待通りの成果物を実現するために必要な情報提供と進捗確認を行うことで、プロジェクトを成功に導きましょう。