ステークホルダー間のコミュニケーションを、プロトタイプで確実にする

システム開発では、経営者・現場担当者・IT担当者・ベンダーなど複数の関係者が関わります。全員の認識を揃えることは難しく、そのズレがトラブルの原因になります。

関係者が多いほど、ズレが生まれやすい

中小企業のシステム開発でも、関わる立場は複数あります。

「このシステムで何を実現したいか」を考える経営者や管理職、「実際にどう使うか」を知っている現場担当者、社内のIT環境を把握しているIT担当者、そしてシステムを作るベンダーです。

それぞれが異なる立場から、異なる情報を持ち、異なる言葉でコミュニケーションします。会議で合意したつもりでも、全員が同じイメージを持っているとは限りません。

「業務フローを自動化する」という一文も、経営者が思い描くものと現場担当者が想定するものは違うことがあります。ベンダーが理解したものがさらに異なることもあります。

仕様書や要件定義書は、このズレを解消するために使われます。ただ、文書で認識を揃えることには限界があります。

文書は書いた人の理解を言葉に変えたものです。読んだ人が同じ意味で受け取るとは限りません。特に、システム開発の経験が少ない関係者が多い場合、「画面遷移図を見てOKを出した」ことと「完成物をイメージできていた」ことは別の話です。

会議の場でも、参加者全員が同じ資料を見ながら話しているようで、それぞれ異なるゴールを思い描いていることがあります。完成後にそれが判明したとき、「そういう意味ではなかった」という議論が始まります。

完全型プロトタイプがあると、コミュニケーションの基点が変わります。

「この画面を見てください」「この操作をやってみてください」——全員が同じものを触りながら話し合えます。経営者は「この機能で業務目標が達成できるか」を判断でき、現場担当者は「この操作は実際の業務に合っているか」を確認でき、ベンダーは「要件の認識が合っているか」を確かめられます。

言葉の解釈のズレは、実物を前にした場合にはるかに発見しやすくなります。「自分のイメージとは違う」という感覚は、文書を読むより画面を触ったときの方が素直に出てきます。

プロジェクトの後半になって「最初からそう言っていた」「聞いていない」という議論が起きることがあります。発注側とベンダーの間でも、関係者間でも、このトラブルはよく起きます。

完全型プロトタイプを確認した段階で関係者全員の合意を取ることで、「このプロトタイプで確認・承認した」という共通の起点が生まれます。本開発はその起点から始まるため、「後から違うと言われた」というトラブルが起きにくくなります。

プロトタイプは、単なる動作確認のためのものではありません。関係者全員が共通のイメージを持つための道具でもあります。

複数の立場の人が関わるプロジェクトほど、認識のズレが生まれやすく、そのズレが後になって大きな問題になります。プロトタイプを軸に合意を形成しておくことは、完成後のトラブルを防ぐための、最も効果的なコミュニケーション手段の一つです。