システム開発をフルスクラッチで成功させるために──“ユーザー企業とシステム開発会社の想いの相反”を超える方法

システムを新しく作りたいと考えるとき、多くの企業が直面する最初の壁は、「ユーザー企業とシステム開発会社の考え方がどこかかみ合わない」という構造的なすれ違いです。これは特定の企業だけに起きるものではなく、システム開発という営みの性質そのものから生まれるズレだと言えます。特にフルスクラッチ開発では、要件定義の精度が品質・費用・期間のすべてに影響するため、この理解の差は大きなリスクとなり得ます。

本コラムでは、IT化の原理原則［1］で示されている“想いの相反”を起点に、なぜミスコミュニケーションが起きるのか、どうすれば成功するプロジェクトに変えられるのかを、実務的な観点から解説します。

＞＞フルスクラッチ（オーダーメイド）のシステム開発について詳細はこちら

【要約】IT化の原理原則［1］ユーザとベンダの“想いの相反”を理解する

システム開発の初期では、ユーザーとシステム開発会社が重視するポイントが構造的に異なることが多いです。ユーザは「要件を丁寧に固めたい」と考える一方で、「早く費用を確定したい」という矛盾した要望を抱きやすい傾向があります。システム開発会社は、開発工数や品質確保の観点から早期の要件確定を強く望むため、両者の期待がすれ違いやすくなります。こうしたギャップは、手戻りや認識の不一致、赤字案件といったリスクにつながります。双方が役割・責任・目的を共有し、開発プロセスへの理解を深め、協働する姿勢を持つことが、トラブルを防ぎ、適切なプロジェクト運営を実現する鍵となります。

出典：独立行政法人情報処理推進機構
『超上流から攻める IT化の原理原則 17ヶ条』原理原則［1］
『実務に活かす IT化の原理原則 17ヶ条』原理原則［1］

「IT化の原理原則17ヶ条」が教える、IT導入を成功へ導くための基礎知識

IPAが公開する「IT化の原理原則17ヶ条」は、企業がIT導入やシステム開発を円滑に進めるための基本的な考え方を整理した指針です。ユーザ企業とベンダ企業の視点の違い、要件定義の重要性、コミュニケーション不足が招く問題など、実務で起こりやすい課題を原理的に示している点が特長です。また、開発プロセスにおける責任や役割の明確化、投資判断の妥当性、品質確保への姿勢など、プロジェクト成功に必要な視点を包括的に提示しています。これらの原則を理解することで、組織が主体的にIT化を推進し、失敗しにくい体制を整えることができるようになります。

出典：独立行政法人情報処理推進機構
『超上流から攻める IT化の原理原則 17ヶ条』原理原則［1］
『実務に活かす IT化の原理原則 17ヶ条』原理原則［1］

ユーザー企業とシステム開発会社が「最初にすれ違う」理由

システム開発の現場では、ユーザー企業が思い描く「こういう仕組みがほしい」という想いと、システム開発会社が考える「どう作るべきか」という視点が、初期段階から食い違うことがよくあります。

ユーザー企業は、業務改善や効率化、顧客体験の向上といった事業目的を達成したいという明確な動機を持っています。しかし同時に、「予算を早く確定したい」「社内稟議を通したい」「スケジュールを早期に固めたい」という事情も抱えています。これらは互いに矛盾しやすく、判断を難しくします。

一方でシステム開発会社は、システムの仕組みを構築するために必要な要件を早期に定義したいと考えます。曖昧な前提で進めれば、工数の不確実性が増し、品質の担保も難しくなるためです。

この“役割と視点の違い”は、どちらが正しい・間違っているという話ではなく、立場が違う以上、自然に発生します。ここを理解せずにプロジェクトを進行すると、両者に不信感が生まれ、迷走しやすくなります。

ズレが引き起こす「手戻り」や「追加コスト」

期待値のズレは、プロジェクトにさまざまな問題をもたらします。特に次の3つは典型的です。

1.手戻りの多発

初期に認識が揃っていないと、画面設計・機能設計の段階で「イメージと違う」となり、大規模な修正が発生します。

2.コミュニケーション負荷の増大

「言ったつもり」「聞いていない」「そんな前提は知らなかった」といった齟齬が増え、議論が複雑化します。

3.費用と期間の増加

想定外の修正が続くことで、追加費用が発生したり、システム開発会社が赤字覚悟の対応を迫られたりします。ユーザー企業にとっても、システム開発会社にとっても望ましい状態ではありません。しかし、この“構造的な相反”を理解していれば、未然に防ぐことができます。

成功する企業は「目的」と「要件」を明確に分離している

プロジェクトを成功させる企業の共通点は、
要件定義の前に「目的・課題・優先度」を明確にしていることです。

• なぜこのシステムを作るのか
• どの業務がボトルネックなのか
• 何を最優先で改善したいのか
• ユーザー（現場・顧客）にどんな価値を提供したいのか

このような根本的な問いに向き合うことが、フルスクラッチ開発における最初の一歩です。

目的が明確なプロジェクトは、システム開発会社も判断がしやすく、要件の精度も高まります。一方で目的が曖昧なプロジェクトは、機能の追加が止まらなかったり、後から仕様変更が続いたりと、混乱を招きがちです。

要件定義とは「合意形成のプロセス」である

要件定義は、単なる機能リスト作成ではありません。
ユーザー企業とシステム開発会社が、互いの期待・役割・制約を擦り合わせ、共通認識を形成するプロセスです。

重要なのは次の姿勢です。

• “あれもこれも”と仕様を盛り込まない
• 実際の業務フローを基準に考える
• システム開発会社の技術的視点を尊重する
• 理想と実現可能性のバランスを取る
• 不確実な部分は段階的に検証する

このプロセスを丁寧に進めることで、相反していた想いは共鳴し、プロジェクトは安定した方向へ進みます。

フルスクラッチ開発では「対話量」が成功を決める

フルスクラッチ開発は、パッケージ導入やカスタマイズとは異なり、完全に白紙の状態から企業専用の仕組みをつくります。

そのため、

• 仕様は0→1で生まれる
• 業務理解が品質に直結する
• 正解が企業ごとに異なる
• 曖昧さのリスクが大きい

という特徴があります。

だからこそ、
対話の量＝成功確率と言えるほど、ユーザー企業とシステム開発会社のコミュニケーションが重要になります。

「相反していること」を前提にプロジェクトを設計する

最も大切なのは、
両者の想いが相反していることを前提としてプロジェクトをデザインする視点です。

• ユーザー企業は目的と優先度を明確にする
• システム開発会社は実現可能性と影響範囲を説明する
• 双方が制約条件を共有する

立場の違いを理解したうえで協働することで、すれ違いは格段に減り、健全なプロジェクト運営が可能になります。

まとめ

フルスクラッチ開発では、ユーザー企業とシステム開発会社の“想いの相反”は避けられません。しかし、この構造的な前提を理解し、目的の整理、要件定義での対話、協働姿勢の確立によって、プロジェクトは大きく成功へ近づきます。

相反することを否定するのではなく、受け入れたうえで協働する。
その姿勢こそが、自社に最適なシステムを実現するための基盤になります。

フルスクラッチ開発には、ユーザー企業とシステム開発会社が丁寧に対話を重ね、共通認識を築きながら前に進む姿勢が欠かせません。当社フレシット株式会社は、この“協働”を最も重視しています。業務理解から要件整理、技術選定、UI/UX設計、運用フェーズまで一気通貫で伴走し、企業ごとの課題や業務フローに最適化されたシステムをゼロから設計します。また、要件が固まりきっていない段階でも、課題整理から支援し、必要な機能を過不足なく定義するプロセスを得意としています。自社に最適な仕組みをつくりたい、将来の拡張性を見据えた開発をしたいとお考えでしたら、ぜひフレシット株式会社にご相談ください。貴社の事業成長を支える“使われ続けるシステム”を共につくり上げてまいります。

＞＞フルスクラッチ（オーダーメイド）のシステム開発について詳細はこちら