なぜ多くの企業で「使われないシステム」が生まれるのでしょうか？

一般にシステム導入とは「要件定義→開発」という段取りで進むものだと思われがちです。しかし実際には、「システム設計」が抜け落ちているプロジェクトが圧倒的に多いのが現実です。

その結果、次のような状態が起きます。

• 使われないSalesforce（システム）
• システムを一新してもExcelが残り続ける
• 機能要件は満たしているのに、現場では回らない

原因は、「要件定義」と「システム設計」を混同していることにあります。

今回は、システム導入や運用に課題を感じている企業の方、そして、より深い価値提供を目指すパートナー企業の方に、ぜひ読んで頂きたい内容です。

具体的には、次のような方々に最適な内容です。

● ① 情報システム部・経営企画部（既存パートナーに課題を感じている企業）
組織規模：従業員50名以上、特に100名〜500名規模の成長企業
導入状況：Salesforce + 複数SaaS（freee会計、Hubspot、Backlog・Asana等）を既に導入済み
現在の課題：―システムは入れたが、Excel運用が残っている
　　　　　　―各システムが連携しておらず、データが分断されている
　　　　　　―現在のパートナーは「構築して終わり」で、運用改善まで伴走してくれない

● ② 経営者（システムを武器に事業成長を目指す）
経営方針：人海戦術ではなく、仕組み化・システム化で生産性を最大化したい
目指す状態：最小の人数で最大の利益を上げる経営体質
現在の課題：―システム投資はしているが、経営指標がリアルタイムで見えない
　　　　　　―現場からは「システムが使いづらい」という声が上がる

● ③ Salesforceパートナー企業（付加価値提案を強化したい）
事業課題：―Salesforceだけでは顧客の業務全体をカバーできない
　　　　　―freee会計やHubspotなどSalesforceではカバーできない範囲を提案したいが、自社リソースだけでは対応しきれない
目指す状態：Salesforce + 他SaaSを組み合わせた提案で、顧客の事業成長に深く貢献したい

本来「システム設計」とは何をする工程なのでしょうか？

本記事では、フライクが「なぜシステム設計に時間をかけるのか」、そして「システム設計で具体的に何を作るのか」を、実際の成果物とともに解説します。

システム設計は不要という大きな誤解

多くのユーザー企業やパートナー企業は、「要件定義さえすればシステムは完成する」と考えがちです。しかし実際には、その間に「システム設計」という重要な工程が存在します。

本章では、システム設計とは何か、なぜ必要なのか、そして要件定義との違いについて詳しく解説します。

システム設計とは「画面や機能を決めること」ではない

多くの企業では「システム設計」と聞くと、画面レイアウトを決めたり、どの機能を使うか選んだりする技術的な作業をイメージしがちです。しかし、この認識こそが、システム導入を失敗させる最大の原因となります。

フライクが定義するシステム設計は、単に「何ができるか？」を決めることではありません。それは、事業と業務が、システムを通じて回り続ける構造を決める工程です。

具体的には、
●この会社の数字が、どう生まれ、どう流れ、どう蓄積されていくのか
●誰が入力し、誰が確認し、誰が意思決定するのか
●イレギュラーが起きたとき、どう処理するのか

つまり、会社の数字と業務の流れをシステム上で再現するための設計であり、
これらの「線と構造」を設計する工程こそが、システム設計の本質です。

では、具体的に機能要件とシステム設計はどう違うのでしょうか？

機能要件だけでシステムを作ると、次のような問題が発生します。

• 入力ルールが人によって違う
• データが信用できない
• Excelが増える、システムが形骸化する

一方、システム設計があることで、システムは業務基盤となり、組織の中で回り続ける仕組みになります。

「要件定義だけ」では失敗する理由

多くの企業では「要件定義さえすればシステムは完成する」と考えられていますが、実際にはその認識が失敗の原因となっています。

要件定義とシステム設計は、まったく別物です。

• 要件定義：何ができればよいか？を決める
• システム設計：どうすれば、その状態が当たり前に続くか？を決める

多くのプロジェクトでは、要件定義をやって満足し、その延長線上で開発に入ってしまうため、次のような状況が頻発します。

• 機能要件は揃っている
• 開発も予定通り完了した
• でも、現場では使われない
• 結局 Excel が残る

なぜこのような事態が起きるのでしょうか？
それは、機能要件が単なる「点」でしかないからです。

• この画面で入力できる
• この項目が入力できる
• このボタンを押せば処理される

一方で、システム設計は「点」だけでなく、線と構造を決めていく工程です。

• どのデータが、どの順番で生まれるのか
• 誰が入力し、誰が確認し、誰が意思決定するのか
• イレギュラーが起きたとき、どう処理するのか

この「線」が設計されていないと、次のような問題が発生します。

• 入力ルールが人によって違う
• データが信用できない
• Excel が増える、システムが形骸化する

つまり、要件定義だけでは「瞬間」を満たすことはできても、「継続」を作ることはできないのです。システム設計があって初めて、システムは業務基盤となり、組織の中で回り続ける仕組みになります。

フライクがシステム設計に時間をかける理由

フライクがシステム設計に時間をかける理由は、システムが完成してから問題に気づくのでは遅いからです。システム導入における失敗コストは非常に高く、事業のスケールを妨げる要因となります。典型的な失敗パターンは以下の通りです。

• 再度構築し直す
• Excelに戻る
• システムを乗り換える

これらの失敗を防ぐために、フライクでは開発前の設計工程に徹底的に時間をかけます。

システムを導入することではなく「数字が動き続ける」ことを重視する

フライクが重視しているのは、システムを導入・開発することではなく、数字が動き続けることです。具体的には、以下のような問いに答えられる設計を目指します。

• 売上がどう生まれるのか
• どこで意思決定が行われるのか
• どの数字を信じて経営判断をするのか

これらを曖昧なままシステムを作ると、必ず高い失敗コストを払うことになります。だからこそ、フライクでは開発前に「つまずくポイント」を徹底的につぶす工程として、システム設計に時間をかけるのです。

システム設計は「何を作るか」ではなく「どう動かすか」を決める工程

システム設計とは、経営者や現場がやりたいことを、システムで実現できる形に変える作業です。

経営陣が欲しいデータや、現場が改善したいポイントを、誰が使っても同じように動く仕組みにすること。これがシステム設計の本質です。

「何が必要か」を集めるだけでは不十分です。また、開発の技術力だけでも足りません。その間にある「どう動かすか」を決めることがシステム設計であり、フライクが最も力を入れている工程です。

▶フライクのシステム設計で必ず扱う要素

フライクのシステム設計では、少なくとも以下を必ず扱います。

• データ構造（オブジェクト設計）
• UI / UX（入力・閲覧のしやすさ）
• 自動化・承認フロー
• 処理ロジック

これらはすべて、作った後に「現場で」「組織で」「事業として」回り続けるか？という問いに答えるためのものです。

つまり、フライクのシステム設計は「開発者のため」ではなく、事業のための設計なのです。

 

システム設計の本質：事業と業務がスケールする土台を作る

システム設計とは、機能を並べる作業でもなく、画面をきれいにする作業でもありません。
事業と業務がスケールするための「土台」を設計する工程です。

この土台がしっかりしていないと、どれだけ優れた機能を持っていても、組織の成長とともにシステムは破綻します。逆に、土台がしっかりしていれば、システムは事業の成長を支える基盤となり、長期的に価値を生み続けます。

だからこそフライクは、システム設計という「見えにくい工程」に、最も時間と労力をかけているのです。

ここからは、フライクが実際にシステム設計プロジェクトで作成している成果物を用いて、具体的にご紹介します。

データ構造、UI/UX、自動化、処理ロジック——それぞれがどのような意図で設計され、どんな成果物として形になるのか、順を追って解説していきます。

これを読めば、「なぜフライクのシステム設計に時間がかかるのか」「何に対して投資しているのか」が、具体的にイメージできるはずです。

データ構造設計（オブジェクト設計）

データ構造設計（オブジェクト設計）とは、システムの「骨格」を決める工程です。

具体的には、次のような要素を設計します。

データ構造設計で決めること

• どんな単位でデータを持つのか：商談、案件、契約、請求など、どの単位で情報を管理するか
• どのデータとどのデータが紐づくのか：取引先と商談、商談と契約、契約と請求など、データ間の関係性
• どの項目を持つのか：各オブジェクトにどんな情報を持たせるか
• 将来の拡張をどう見越すか：新事業や新サービスが増えたときに、構造を壊さず追加できるか

フライクが作成する「標準・カスタムオブジェクト設計書」には、これらの情報が詳細に定義されています。

なぜデータ構造設計に最も時間をかけるのか   

フライクがデータ構造設計に最も時間をかける理由は、後から直すことがほぼ不可能だからです。

UI（ユーザインタフェース）は多少使いづらくても運用でカバーできます。しかし、データ構造を後から直すたびに、システムはツギハギだらけになってしまいます。

フライクのシステム設計は、今の業務だけを前提にしません。なぜなら、ほぼ確実に組織拡大・事業増加・ERP連携やBI活用が始まるからです。将来を見据えていないと、新事業ごとに別管理となり、データが分断され、結局Excelに戻ることになります。だからこそ最初の設計で、拡張余地を持たせます。

また、Salesforce単体で完結する業務はほぼ皆無です。最終的には必ず、請求・入金・原価・会計といったERPや外部システムとつながります。よってフライクでは、最初から「外部システムとつながる前提」で設計します。

よくある失敗：「とりあえず今動けばいい」で作ったシステムの末路

システム導入の失敗を振り返ると、よくこう言われます。

「最初は問題なかった。でも途中から回らなくなった…」

この「途中から崩れる」原因の多くは、データ構造の設計不足にあります。たとえば、Salesforceの商談管理でよくある失敗パターンがこちらです。

• 商談オブジェクトに項目を追加し続ける
• 本来分けるべき情報を1レコードに詰め込む
• 「とりあえず今使えればいい」で設計する

導入直後は動きます。しかし数年後、こうなります。

• レポートが作れない
• ERP連携でデータが噛み合わない
• 業務が増えるたびに改修コストが爆増する

これはツールの問題でも、運用の問題でもなく、構造設計の問題です。

フライクのデータ構造設計は、「この会社の数字は、どのデータから生まれるのか？」という問いから始まります。

• 売上は、どのデータの積み上げか
• 受注率は、どの状態遷移で測るのか
• 原価・工数は、どこで発生し、どこで確定するのか

この「数字の発生源」を起点に、オブジェクト構造を設計していきます。

つまり、フライクの「標準・カスタムオブジェクト設計」は、単なる項目定義ではありません。事業の数字がどう生まれ、どう管理されるかを構造化する工程なのです。

データ構造設計とは、技術的な作業ではなく、将来の経営判断を支える基盤づくりです。ただし、データ構造が正しくても、使われなければ意味がありません。

ログイン画面・自社ブランド定義

多くの企業では、ログイン画面やロゴ変更は「最後の装飾」「おまけ」だと思われがちです。しかしフライクでは、これを明確にシステム設計の一部として扱います。

理由はシンプルです。SalesforceやERPを「ベンダーのツール」ではなく「自社の業務基盤」として認識させるためです。

システムが「自分たちのもの」にならないと、使われない

現場でよく起こる状況があります。

「Salesforceに入力しておいて」→「ああ、あのツールね」。

この距離感がある限り、システムは主体的に使われません。

なぜこの距離感が生まれるのでしょうか。それは、システムが「外部から導入されたツール」という認識のままだからです。ベンダーのロゴ、デフォルトの画面、汎用的なドメイン名——これらすべてが「借り物感」を生み出します。

ログイン画面・ブランド定義は、以下の要素を通じて「これは自社の業務システムだ」という認識を組織に浸透させる設計です。

• ロゴ
• ブランドカラー
• ドメイン
• アプリケーション定義

これらの要素を自社仕様にカスタマイズすることで、従業員は「これは自分たちの会社のシステムだ」と認識し、心理的な距離が縮まります。結果として、入力や更新が習慣化され、データの精度も向上します。

見た目の話ではなく、定着のための設計

ログイン画面等の自社ブランド定義は、見た目の話ではありません。システムを業務に定着させるための設計です。

たとえば、毎日ログインする画面に自社ロゴがあるだけで、「自分たちの業務基盤」という意識が芽生えます。逆に、ベンダーのロゴが表示され続ける限り、どこか「よそのシステムを使わされている」感覚が残ります。

また、独自ドメイン（例:crm.yourcompany.com）を設定することで、URLからも「自社システム」であることが伝わり、信頼性とセキュリティ意識も高まります。

ここを軽視すると、システムはいつまでも「外部ツール」のままになります。現場の主体性を引き出し、継続的な運用を実現するためには、最初の段階で「自分たちのもの」にする設計が不可欠です。

画面設計

画面設計は、業務設計・データ設計で決めた内容を、実際に「触れる形」に変換する工程です。単なる見た目の調整ではなく、業務の流れ × データ構造 × ユーザー操作を一点に集約する設計作業です。

画面設計は「見た目」と「データ」を同時に設計する

画面設計というと、「項目を並べる」「レイアウトを整える」作業と思われがちです。しかし実際には次を同時に決めていきます。

• 画面の構成・デザイン
• どの項目を、どのオブジェクトにバインドするか
• 入力／編集／参照の権限
• 必須／任意の切り分け
• 保存・キャンセルなどの挙動

つまり画面設計とは、業務の流れ × データ構造 × ユーザー操作を一点に集約する工程です。

「どの項目を、どこにバインドするか」は設計の核心

見積入力画面ひとつをとっても、以下のような設計判断が必要です。

• 商談オブジェクトに持たせるのか
• 見積オブジェクトに切り出すのか
• 明細は子オブジェクトにするのか

この設計によって、後続の帳票、ERP連携、集計・分析すべてに影響します。画面上は同じでも、裏側のバインド設計が違えば、使い勝手と寿命は別物になります。

フライクでは、画面設計の段階で「このデータがどう使われ、どこに連携されるのか」までを見据えて設計します。

デザインは「入力され続けるための設計」

デザインは装飾ではありません。画面設計において重要なのは、以下のような視点です。

• 入力項目が多すぎないか
• 業務の流れに沿った並びか
• 判断に必要な情報が同じ画面で見えるか

これができていないと、次のような問題が発生します。

• 入力が後回しになる
• 入力漏れが発生する
• データが信用されなくなる

結果として、システムは使われなくなります。

フライクでは、「入力し続けられる画面」を設計することで、データの鮮度と精度を維持し、システムが長期的に活用される基盤を作ります。

帳票設計

帳票設計は、システムに蓄積されたデータを「外部に出力する形」に変換する工程です。単なる見た目の調整ではなく、業務の完了を定義し、データの整合性を保証する設計作業です。

帳票は「業務の完了」を定義する

帳票（見積書・請求書・各種帳票）は単なる出力フォーマットではありません。帳票設計では、以下を決めます。

• どのデータを
• どの状態で
• どのタイミングで
• どの形式で出すのか

これはつまり、「どのデータをもって、業務が完了したとみなすか」を定義することです。

帳票が出力されるということは、そのデータが確定し、業務が次のフェーズに進むことを意味します。したがって、帳票設計は業務プロセス全体の整合性を担保する重要な工程です。

帳票設計を後回しにすると起きること

画面設計だけ先に進めてしまうと、次のような問題が発生します。

• 帳票に必要な項目が足りない
• 計算ロジックが合わない
• 結局Excelで加工する

その結果、システム上のデータと提出する帳票の数字がズレる事態が起きます。

これは現場課題ではなく、設計課題です。帳票設計を後回しにすることで、データの信頼性が失われ、システムが使われなくなる原因となります。

フライクでは、画面設計と帳票設計を並行して進めることで、データと出力の整合性を最初から担保します。

帳票設計は「データと業務を正しく接続する設計」

帳票設計は、見た目を整える作業だけではなく、データと業務を正しく接続する設計です。

• どのオブジェクトから、どの項目を引くのか
• 集計や計算はどのタイミングで行うのか
• 出力条件や権限はどう設定するのか

これらを明確に設計することで、帳票は単なる「印刷物」ではなく、業務の完了を証明し、次工程への橋渡しをする仕組みになります。

ここでズレると、どれだけ業務設計・データ設計を頑張っても、現場では使われないシステムになります。

自動化・承認フロー・処理ロジック

自動化・承認フロー・処理ロジックの設計は、人の判断や記憶に頼っていた業務を、仕組みに置き換えるための設計です。これがないと、システムは「入力ツール」にしかならず、業務効率化の本質的な価値を生み出せません。

フロー定義:「業務の自動運転」を作る設計

フロー定義とは、条件分岐・自動更新・自動通知などを通じて、「人が考えなくても、正しい次の処理に進む」状態を作る設計です。

フロー定義で決めること:

• どの状態になったら、次の処理に進むのか
• 誰に、どのタイミングで通知するのか
• どの項目を、自動で更新するのか
• 例外が発生したとき、どう処理するのか

これを設計しないと、以下のような問題が発生します。

• 次に何をするか分からない
• 誰かが止める
• 誰かが忘れる

結果として、業務は「人依存」のまま残り、システムを導入した意味が失われます。

フロー定義は「属人化をなくす設計」です。人の記憶や判断に頼らず、仕組みで業務を回すための構造を作ります。

承認フロー定義:「判断基準の統一」

承認フローは、誰が・どの条件で・何を承認するのかを明文化する設計です。単に「上長承認」と決めるだけでは不十分で、承認の基準とタイミングを構造化する必要があります。

承認フロー定義で決めること:

• どの条件で、誰の承認が必要になるのか
• 承認者が複数いる場合、並列か直列か
• 承認後、どの項目が確定し、どの処理が走るのか
• 差し戻しや否認時の処理はどうするのか

これを設計しないと、次のような問題が起きます。

• 人によって判断が違う
• 上長によって基準が違う
• 後から責任の所在が曖昧になる

結果として、業務スピードも信頼性も落ちます。

承認フロー定義は「組織の判断基準をシステムに落とし込む設計」です。これにより、誰が承認しても同じ基準で判断される仕組みが作られます。

アルゴリズム定義:「暗黙知の言語化」

アルゴリズム定義とは、計算ロジック・処理順序・例外処理など、これまで説明されていなかった業務の暗黙ルールを明文化する工程です。

アルゴリズム定義で決めること:

• どの項目を、どの順序で計算するのか
• 端数処理や消費税計算のルールは何か
• 例外が発生したとき、どう処理するのか
• 複数の条件が重なったとき、優先順位はどうなるのか

ここを定義しないまま作ると、次のような問題が発生します。

• 「前はこうだった」
• 「人によってやり方が違う」
• 「システムの計算結果が信用できない」

結果として、システムは使われなくなり、Excelでの再計算が常態化します。

アルゴリズム定義は「業務の再現性を担保する設計」です。誰がやっても同じ結果が出る構造を作ることで、システムの信頼性が確保されます。

なぜフロー・承認・アルゴリズムの設計が必要なのか

多くのシステム導入プロジェクトでは、画面設計やデータ設計に注力する一方で、フロー・承認・アルゴリズムの設計が後回しにされます。

その結果、次のような問題が発生します。

• システムは完成したが、業務が回らない
• 人の判断や記憶に頼る部分が残り、属人化が解消されない
• 計算結果が信用できず、結局Excelで再計算する

これは、「システムを作る」ことと「業務が回る仕組みを作る」ことが、別物であることを示しています。

フロー・承認・アルゴリズムの設計は、現場の頑張りを前提にせず、仕組みで業務を回すための設計です。

これがあることで、システムは「導入して終わり」ではなく、運用に耐える業務基盤になります。

まとめ：システム設計は「失敗を防ぐ構造づくり」

• 要件定義 = 「何ができればよいか」
• システム設計 = 「それが当たり前に続く構造」

その構造を、以下の成果物群で担保していきます。

• 自社ブランド定義（定着させる）
• 画面/帳票設計（業務とデータを接続する）
• フロー/承認/アルゴリズム（属人化をなくす）

本記事で解説してきたのは、「どんな設計書を作るか」ではありません。

私たちが本当に伝えたかったのは、
なぜ、それらの設計をやらなければ、あなたの会社のプロジェクトが失敗するのかという真実です。

多くのシステム導入プロジェクトが、

• 要件定義で「何ができるか」を決め
• そのまま開発に進み
• 「ちゃんと作ったのに、なぜか使われない」

という悲劇的な結末を迎えています。

これは、努力不足でもツール選定ミスでもありません。
「当たり前に使われ続ける構造」を設計していないことが原因なのです。

システム設計とは、あなたが経営や業務で考えていることを、「誰がやっても同じ結果が出る仕組み」に翻訳する工程です。

機能を並べる作業でも、画面をきれいにする作業でもなく、
あなたの事業と業務が、システムを通じて回り続ける構造を決める工程
なのです。

要件定義だけでは足りない。開発力だけでも足りない。

その間にある「構造を決める工程」こそが、システム設計であり、3〜5年後もあなたの会社を支え続ける基盤を作ることが、フライクの考える「システム設計」の本質です。

あなたの会社は、どちらを選びますか？

もし今、あなたのシステム導入プロジェクトで

• 「要件は固まったから、あとは開発だけ」と思っている
• 画面設計やデータ設計は進んでいるが、フローや承認の設計が曖昧
• 「使われ続ける仕組み」ではなく「作ること」が目的になっている

という状態であれば、それは間違いなく「失敗の予兆」です。

フライクは、Salesforceをはじめとした複数のSaaSを組み合わせながら、
―「当たり前に使われ続ける構造」をシステム設計の段階で作り込む―
ことを強みとしています。

システム導入で「失敗させない構造を作る」ことに本気で関心があるなら、
今すぐ、私たちに声をかけてください！

あなたの会社の未来を、一緒に守りましょう。

◆まずは60分の無償相談会から

あなたの組織が抱える課題や、これから目指したい姿について、一緒に整理させてください。システム導入は、ゴールではなく、組織が成長するための一つの手段です。

その手段を最大限に活かすために、まずは「準備」から始めませんか？

▼無償相談会はこちらから

▼ホワイトペーパーDLはこちらから