なぜシステム開発は「合意したはず」なのに揉めるのか｜合意形成のズレを防ぐ進め方
「OKです」と言ったのに違うものが出てくる──システム開発で起きる“合意のズレ”
システム開発を発注したことのある人なら、一度はこの経験があるはずです。
定例会議で仕様を説明され、「はい、それで問題ありません」と答えた。議事録にも「合意」と記録された。ところが数週間後、実際に動く画面を見せられると、頭の中で描いていたものとどこか違う。「ここはこういう挙動だと思っていた」と伝えると、開発側は怪訝な顔で「前回の会議で合意いただいた仕様です」と返してくる。
そこから話はこじれていきます。発注側は「最初からこういうつもりだった」と主張し、開発側は「合意した範囲を超えるなら追加見積もりになる」と応じる。お互いに悪意はないのに、気づけば金額と納期の調整で険悪になっている。
この「合意したはずなのに揉める」という現象は、担当者の能力不足やベンダーの不誠実さが原因ではありません。多くの場合、合意していたのは「言葉」であって、「中身」ではなかったという構造的な問題です。本稿では、なぜこれが起きるのかを分解し、発注する側として何を揃えておけば揉めずに済むのかを整理します。
目次
システム開発で合意形成が崩れる理由──合意には「粒度」がある
「合意した」と一言で言っても、その解像度には大きな差があります。システム開発における合意は、少なくとも次の3つのレベルに分かれています。
目的レベルの合意
「顧客が会員登録をスムーズにできるようにする」といった、何のために作るかの合意。
仕様レベルの合意
「会員登録はメールアドレスとパスワードで行い、SNSログインも用意する」といった、何を作るかの合意。
画面・挙動レベルの合意
「登録ボタンを押すと確認メールが届き、リンクをクリックして初めてアカウントが有効化される」「入力エラー時はこの文言を出す」といった、どう動くかの合意。
揉める案件のほとんどは、目的や仕様のレベルだけで「合意した」と思い込み、画面・挙動のレベルを曖昧なまま走り出しています。発注側はこの画面・挙動の部分を自分の頭の中のイメージで補完し、開発側は仕様書の文言どおりに解釈する。この埋まらない差が、後になって「思っていたのと違う」という形で噴出するのです。
たとえば「会員がマイページから退会できるようにする」という仕様で合意したとします。発注側は、退会ボタンを押したら確認画面が出て、理由を選んでもらい、完了後にお礼のメールが届く——という一連の体験を想像していました。一方の開発側は、ボタンを押せば即座にアカウントが削除される最小構成を想定していました。どちらも「退会機能を作る」という仕様レベルの合意には忠実です。にもかかわらず、出来上がったものは双方の頭の中で別物だった。これが、画面・挙動のレベルを揃えないまま走ったときに起きる典型的なズレです。そして厄介なことに、このズレは実物が動くまで誰にも見えません。
ここで押さえておきたいのは、曖昧さを残すことが、その場の衝突を避ける優しさのように見えて、実際には将来の揉め事の先送りでしかないという事実です。「細かいところは後で詰めましょう」という合意は、後工程のコストと摩擦を確実に増やします。曖昧さは、消したのではなく、未来に積み立てているだけなのです。
認識齟齬が生まれる、システム開発のよくある合意パターン
実際の現場では、合意の崩れ方にいくつかの典型があります。自社に当てはまるものがないか、確認してみてください。
「決定事項」と「検討事項」が混ざっている
議事録に、確定したことと「まだ検討中だが方向性として話したこと」が同じトーンで並んでいる。読み返したときに、どこまでが決定で、どこからが仮なのかを区別できない。結果、開発側は決定として進め、発注側は検討中だと思っている、という食い違いが起きます。
「いい感じに」で合意してしまう
「ここはユーザーが使いやすいように、いい感じにお願いします」。一見スムーズな会話ですが、「いい感じ」の中身は人によって違います。これは合意ではなく、認識齟齬を後回しにする約束にすぎません。
結論だけ残って、判断の根拠が消える
議事録に「A案で進める」とだけ書かれ、なぜA案なのか、どんな前提で選んだのかが残らない。後から前提が変わったときに判断を見直せず、誰もその決定の理由を説明できなくなります。
リモート・非同期で兆候が見えにくい
対面なら相手の微妙な表情やためらいで気づけたズレが、チャットやドキュメント越しだと表面化しません。「了解しました」という返信の裏に、実は理解の食い違いが隠れていても、誰も気づけないまま進んでしまう。
発注側が「素人だと思われたくない」と黙ってしまう
専門用語が飛び交う打ち合わせで、よく分からないまま「大丈夫です」と答えてしまう。これは発注側に非常によくある心理ですが、ここで生まれた小さな不明点が、後で大きな手戻りの火種になります。分からないことを分からないと言える場を、進行側が意図的につくれているかが問われます。
これらに共通するのは、コミュニケーションの量が足りないのではなく、揃えるべき情報の粒度と種類が定義されていないという点です。会議を何度増やしても、揃え方が決まっていなければズレは消えません。揉めないプロジェクトは、会議が多いのではなく、合意の取り方が設計されているのです。
合意形成を成功させる進め方──何を・誰と・どの粒度で揃えるか
では、どう合意形成すればいいのか。「しっかり認識を合わせる」では答えになりません。具体的に、どの層を、どんな方法で揃えるかを設計する必要があります。
目的レベルは「成功条件」まで言語化する
「会員登録をスムーズに」では曖昧です。「現状の登録途中離脱を減らす」「登録完了までの操作を3ステップ以内にする」といった、達成できたかどうかを後から判定できる条件まで落とす。この成功条件が、以降のすべての仕様判断の拠り所になります。判断に迷ったとき、「それは成功条件に近づくか」で立ち返れる状態をつくるわけです。
仕様レベルは「決定・検討・保留」を分けて記録する
合意を記録するとき、確定したこと（決定）、方向性は出たが詰め切れていないこと（検討）、今は判断しないと決めたこと（保留）を明確に分ける。この3分類を徹底するだけで、「言った・言わない」の争いの大半は防げます。記録の形式を変えるだけなので、明日からでも始められます。
画面・挙動レベルは、言葉ではなく「見える化」で合意する
画面・挙動レベルの合意を文章だけで取ろうとすると、必ず解釈差が生まれます。ワイヤーフレーム、画面遷移図、簡単なプロトタイプなど、見える化されたものを前にして合意する。人は文章よりも、目の前にある画面に対してのほうが、はるかに正確に「ここは違う」と言えます。この見える化こそが、認識齟齬を最も効率よく潰す手段です。発注側にとっても、完成間際ではなく早い段階で「違う」と言えることが、最大のリスク回避になります。
期待値は、関係者ごとに分けて揃える（期待値コントロール）
経営は事業成果を、現場は日々の使いやすさを、情報システム部門は保守性やセキュリティを見ています。同じ「いいシステム」という言葉でも、立場によって期待する中身がまるで違う。誰が何を期待しているかを可視化し、優先順位をつけて合意しておかないと、最後に必ずどこかの期待が裏切られます。期待値コントロールとは、全員を満足させることではなく、何を優先し何を諦めるかを、関係者の納得の上で先に決めておくことです。
ここで本来力を発揮するのが、PM・ディレクターという役割です。彼らはタスクの進捗を管理する人ではなく、立場の異なる関係者の間に立ち、曖昧な相談を実行可能な形に翻訳し、認識を揃えるブリッジ役です。合意の粒度を設計し、見える化し、揃える順番を決める——これが進行を担う人の本来の仕事です。
システム開発の合意形成で使える、明日からのチェックリストと打ち手
抽象論で終わらせないために、すぐ持ち帰れる具体策をまとめます。
合意記録に必ず残す項目
- 決定事項（確定したこと）
- 検討事項（方向性は出たが未確定なこと）
- 保留事項（今は判断しないと決めたこと）
- その決定を選んだ前提・理由
- 次に誰が、何を、いつまでに判断するか
会議で使うと効く問い
- 「これは“決定”でいいですか、それとも“検討中”ですか？」
- 「この合意は、どの画面・どの操作のことを指していますか？」
- 「これが達成できたと、何を見れば判断できますか？」
- 「今ここで決めないと、後でどんなコストになりますか？」
問いの形にしておくと、その場の空気で曖昧に流すことが難しくなります。曖昧さを放置しない仕組みを、会話の中に埋め込むわけです。
変更を「事故」ではなく「手続き」にする
要件は変わるものです。問題は変わること自体ではなく、変更が場当たり的に処理されること。変更が出たら「これは当初の合意のどこを更新するのか」「費用・納期にどう影響するのか」を、感情論ではなく理想と現実のギャップとして淡々と扱う。変更管理のルールを先に決めておけば、変更は揉め事ではなく通常運転になります。
その場しのぎで終わらせない
一つズレが起きたら、「今回どう収めるか」という暫定対応だけでなく、「次から同じ種類のズレをどう起こさないか」という恒久対応まで考える。合意の取り方そのものを見直し、チームの標準として横展開する。これができるかどうかが、同じ問題を毎回繰り返す組織と、回を追うごとに揉めなくなる組織の分かれ目です。
ここで挙げた打ち手は、どれも特別なツールも才能も必要としません。記録の形式を変える、問いを一つ足す、見えるもので合意する——いずれも、その気になれば次の打ち合わせから始められる仕組みです。逆に言えば、これらを「気をつける」「意識する」といった個人の心がけに委ねている限り、ズレは必ず再発します。合意形成は、根性ではなく設計で支えるものなのです。
まとめ｜合意形成は、システム開発の進行品質そのもの
「会議で合意したはずなのに揉める」という現象は、誰かのミスではなく、合意の粒度を設計していなかったことから生まれます。逆に言えば、どの層を、誰と、どの粒度で、何を使って揃えるかを最初に設計しておけば、システム開発は驚くほど揉めなくなります。
そして、この合意形成の設計こそが、PM・ディレクターの本当の価値です。彼らは進捗を見張る管理者ではなく、曖昧さを減らし、期待値を揃え、後から起きる問題を未然に防ぎながら、プロジェクトを前に進める人。合意形成とは、それ自体が進行品質そのものなのです。
Enlytは、システムを「作る」こと以上に、揉めずに、成果につながる形で進める設計を強みにしています。受注前の段階から要件を可視化し、関係者の期待値を揃え、認識齟齬が生まれる前に整理する。文化差や拠点差をまたぐ多国籍・リモート体制でも進行品質を落とさない運用を、個人の力量ではなく仕組みとして持っています。
「合意したはずなのに、なぜか揉める」が続いているなら、それは現場の頑張りが足りないのではなく、合意形成の設計が抜けているサインかもしれません。自社のプロジェクトのどこに曖昧さが残っているか、一度棚卸ししてみることをおすすめします。
Enlytは、受注前の段階から期待値をコントロールし、認識齟齬を未然に防ぐ確かなディレクション力を強みとしています。
現在進行中のプロジェクトに不安がある方や、信頼できる開発パートナーをお探しの方は、下記よりお気軽にお問い合わせください。
