― システム開発の費用は、なぜこれほど違うのか？ ―

1．「７公３民」という言葉をご存じですか？

日本史の教科書で「７公３民（しちこうさんみん）」という言葉を聞いたことはありませんか？
収穫した農作物の７割を年貢として納め、農民の手元には３割しか残らないという、かつての厳しい年貢負担を表す言葉です。

実は、日本のシステム開発業界にも、これに似た構造があります。
大手SIer（エスアイアー／システムインテグレーター）が顧客からシステム開発を受注し、そのプログラム開発をKnetのような中小開発会社へ外注するケースです。案件によって異なりますが、仮に顧客が支払う開発費用のうち、大手SIerが７割、下請けの開発会社が３割という配分だったとしましょう。

これが、「７公３民」です。

ただし、これは大手SIerが不当に利益を搾取しているという意味ではありません。実際、大手SIerには、下請けの開発会社にはない重要な役割があります。そして、その役割には相応の人件費と責任が伴います。では、なぜこれほど費用に差が生じるのでしょうか。
その理由を理解するためには、まずシステム開発の仕組みを知る必要があります。

用語解説：SIer
SIer（エスアイアー）とは、「システムインテグレーター（System Integrator）」の略称で、企業のシステム作りを企画・設計から開発、運用・保守まで一貫して請け負うIT企業のことです。

2．システム開発には、大きく4つの工程がある

システム開発というと、プログラマーがパソコンに向かってプログラムを書いている姿を想像されるかもしれません。しかし、実際にプログラムを書く作業は、システム開発全体の一部分にすぎません。
大まかに分類すると、次の４つの工程があります。

  1. 要件定義書の作成 ― 何を実現するシステムなのかを明確にする
  2. プログラム開発 ― 要件定義に基づいて実際にシステムを構築する
  3. デザイン ― 画面構成や操作性などを設計する
  4. 仕様書・操作マニュアルの作成 ― システムの内部構造や操作方法を文書化する

実際には、設計、テスト、導入、運用支援、プロジェクト管理などの工程もありますが、ここでは説明を分かりやすくするため、上記の４つに整理します。大手SIerは、これらの業務を一括して請け負うことが多く、顧客に対してシステム全体の品質、納期、予算などの責任を負います。
一方、Knetのような中小開発会社は、そのうちの一部、特にプログラム開発を担当することが多いのです。

3．最も重要で、最も費用がかかるかもしれない「要件定義」

私の経験では、システム開発で最も重要な工程は「要件定義」だと考えています。場合によっては、プログラムを作ること以上に、多くの費用（時間と人件費）が必要になります。

要件定義とは、簡単にいえば「顧客がどのような仕事をしていて、その仕事をシステムでどのように実現するのか」を明らかにする作業です。

例えば、ある会社の販売管理システムを開発するとしましょう。
まず、その会社では注文をどのように受け付け、在庫をどのように管理し、請求書をどのように発行しているのかを調べなければなりません。担当者にヒアリングするだけでなく、実際に業務の現場を訪問し、仕事の流れを確認することもあります。 こうした調査や実現可能性の検証には、フィージビリティスタディ（実現可能性調査）の考え方も関わってきます。

短ければ１週間程度で終わることもありますが、大規模なシステムでは半年から１年、場合によってはそれ以上の期間を費やすこともあります。 その結果を整理したものが、要件定義書です。大規模な案件では、関連する設計資料まで含めると、印刷した書類の厚さが数十cm、時にはメートル単位にも達することもあります。


良い要件定義書とは何か？

私は、優れた要件定義書について、次のように考えています。

「誰がプログラムを開発しても、画面のデザインなどを除けば、基本的に同じ動作をするシステムが完成する」

それほど具体的で、解釈に迷う余地が少ない書類が理想です。 例えば「売上を集計する」という一文だけでは、プログラマーは何を作ればよいのか判断できません。日別なのか月別なのか、税込金額なのか税抜金額なのか、返品をどう扱うのか、締め日はいつなのか。 こうした条件が明確になって、初めて正確なプログラムを作ることができます。

要件定義が曖昧だと、開発会社の負担が増える

ここからは少し、開発現場の本音になります。

下請けとしてプログラム開発を受注すると、元請けから要件定義書を受け取ります。ところが、書かれている内容が曖昧で、どのようにでも解釈できる場合があります。 そうなると、開発側は作業を進めるたびに、元請けや顧客へ確認しなければなりません。

  • 「このボタンを押した場合、どの画面へ移動するのですか？」
  • 「この条件に該当しないデータは、どう処理するのですか？」
  • 「この数値は四捨五入ですか、それとも切り捨てですか？」

こうした確認が何十回、何百回と発生すると、プログラムを書く時間より、確認と回答待ちに費やす時間のほうが長くなることさえあります。

もちろん、完璧な要件定義書に出会うことは、ほとんどありません。実際に開発を進めて初めて判明する問題もあるためです。しかし、あまりにも曖昧な内容が多い場合には、開発会社が実質的に要件定義の一部まで引き受けていることになります。

そんなときは、思わず考えてしまいます。
「７公３民ではなく、せめて６公４民。できれば５公５民にしてもらえないだろうか」と。 冗談めかした表現ですが、開発現場の負担を考えると、決して笑い話だけではありません。

4．プログラム開発は、必ずしも大手SIerが行うわけではない

要件定義が完成すると、それをもとにプログラム開発が始まります。
大手SIerが受注した案件を、自社の開発チームが請け負う場合と、Knetのような外部の開発会社へ発注する場合があります。私見ですが、案件の規模や内容が大手SIerでは負担となる場合、協力会社が開発の実務を担当しているのではないでしょうか？

大手SIerは、顧客との調整、プロジェクト全体の進捗管理、品質管理、予算管理などを担当し、実際の開発作業を協力会社へ委託するわけです。 このような分業は、日本のシステム開発業界では珍しいことではありません。 つまり、大手SIerへ依頼したからといって、必ずしも大手SIerの社員がすべてのプログラムを作っているわけではないのです。

元請けと同等の技術力を持つ開発会社が、同じ要件と品質基準に基づいて開発するのであれば、基本的な機能について同等の成果を期待できます。 ただし、大手SIerには、大規模プロジェクトを管理する体制、専門技術者の確保、品質保証、セキュリティ管理、障害発生時の対応など、中小開発会社では十分に提供できない強みがあります。

そのため、単純に「大手SIerに依頼するのは割高だ」とは言えません。 重要なのは、顧客が必要としているシステムの規模や難易度に対して、どこまでの管理体制と保証が必要なのかという点です。

5．デザインは、案件によって自由度が異なる

システムのデザインも重要な工程です。
ここでいうデザインとは、単に画面を美しくすることだけではありません。ボタンの配置、入力項目の並び方、画面の切り替わり方など、利用者が迷わず操作できる仕組みを考えることも含まれます。

大手SIerから受注する案件では、画面デザインまで細かく指定される場合があります。 ボタンの色、大きさ、配置場所、文字の表示方法などが、要件定義書やデザイン定義書などの設計資料に明記されていることもあります。

一方、基本的な動作だけが決められていて、画面の構成や見た目は開発会社に任される場合もあります。Knetのような中小開発会社でも、一般的な業務システムであれば、使いやすい画面を設計することは十分に可能です。

初めてシステムに触れる人でも、迷わず操作できる。

それが理想的なデザインだと考えています。
特に、大規模なサービスでは、UI・UX設計は設計資料にしっかりと書かれていないと大変なことになります。例えば、下請けが複数存在する場合、UI・UX設計についての指示がなく、ページによって配置や色がバラバラのサービスを想像してみてください。きっと、その大切さをご理解いただけるのではないでしょうか？

6．仕様書は、数年後の自分を助ける大切な書類

プログラムが完成したら、それで終わりではありません。システムは納品後も長期間使われ、機能の追加や修正が必要になることがあります。

そこで重要になるのが「仕様書」です。
仕様書とは、プログラムの内部構造や動作の仕組みを記録した書類です。 例えば、PHPとデータベースを使ったシステムであれば、次のような内容を記載します。

  • 各PHPファイルがどのような処理を行っているか
  • どのデータベーステーブルを参照しているか
  • どのテーブルにデータを登録・更新しているか
  • 各画面がどのようにつながっているか
  • データの計算方法や処理条件はどうなっているか

こうした情報を残しておくことで、数年後に修正が必要になった場合でも、システム全体の仕組みを把握しやすくなります。

プログラムを作った本人でも、数年後には分からなくなる

これは、プログラマーなら誰でも経験があるのではないでしょうか。
過去に自分が作成したプログラムを開いて、
「あれ？ この処理はどういう仕組みだったかな？」
「なぜ、ここでこのテーブルを参照しているのだろう？」
と首をかしげることがあります。

人間の記憶は、意外なほど曖昧です。 ましてや、他人が作成したプログラムを引き継ぐ場合には、内部構造を理解するだけで相当な時間が必要になります。 それを補ってくれるのが仕様書なのです。

近年は生成AIの発達によって、既存のプログラムを解析し、処理内容を説明させることも可能になりました。 これは開発現場にとって大きな進歩です。 しかし、生成AIがあれば仕様書が不要になるわけではありません。

プログラムのコードだけでは、なぜその仕様になったのか、顧客とどのような取り決めがあったのか、といった背景までは分からないことがあります。 そのため、現在でも仕様書は重要な役割を持っています。

7．操作マニュアルは、顧客の立場で作るもの

仕様書が開発者や保守担当者のための書類であるのに対して、操作マニュアルはシステムを利用する顧客のための書類です。

操作マニュアルには、画面の開き方、データの入力方法、検索方法、帳票の印刷方法などを記載します。 ただし、単に操作手順を書けばよいというものではありません。 開発者にとって当たり前の操作でも、初めてそのシステムを使う人には分からないことがあります。

例えば「登録ボタンを押してください」と書かれていても、画面に類似のボタンが複数あったら、利用者は迷ってしまいます。 そのため、画面の画像を掲載したり、操作する場所を矢印で示したり、実際の業務の流れに沿って説明したりする工夫が必要です。

初めてシステムに触れる人でも、迷わず操作できる。

それが理想的な操作マニュアルだと考えています。
分かりやすい操作マニュアルを作るためには、プログラムの知識だけでなく、顧客の業務や利用者の立場を理解することが必要です。 これもまた、時間と経験を要する仕事なのです。

8．大手SIerの開発費用が高額になる理由

ここまで説明してきたように、システム開発には、単にプログラムを書くこと以外にも多くの仕事があります。 大手SIerは、要件定義、設計、開発、テスト、デザイン、仕様書や操作マニュアルの作成、さらにはプロジェクト管理や品質保証などをまとめて提供することができます。

加えて、大規模なシステムでは、複数の開発会社や多数の技術者を統括する必要があります。 開発途中で問題が発生すれば、その調整や解決も元請けの重要な仕事です。 こうした費用がすべて開発予算に含まれるため、大手SIerへ依頼すると、数千万円、場合によっては数億円規模になることも珍しくありません。 つまり、顧客が支払っているのは、プログラムそのものの代金だけではないのです。

「システムを完成する作業代」ではなく、「システムを完成させるための責任」に対し費用を支払っていると考えると、理解しやすいのではないでしょうか。

9．では、Knetに依頼すると何が違うのか？

ここまで大手SIerの役割を説明してきましたが、では、Knetのような中小開発会社へ直接依頼する場合は、どうなるのでしょうか。

結論からいえば、大規模なシステム開発は難しいものの、比較的小規模な業務システムであれば、必要な機能を絞り込み、開発費用を抑えて提供できる自信と自負があります。

ただし、大手SIerと同じ内容のサービスを、単純に安く提供できるというわけではありません。
Knetの場合、各工程について次のような対応になります。

① 要件定義書の作成
Knetでも、顧客へのヒアリングや実際の訪問を通じて、必要な機能や業務の流れを整理します。 また、顧客自身に「どのような動作をするシステムが欲しいのか」を大まかに書面へまとめていただき、それをもとに具体的な仕様を決めていく方法もあります。 大手SIerのように、多数の専門スタッフを投入して半年から１年かけるような大規模な要件定義は困難です。

その代わり、顧客と開発担当者が直接話し合いながら、必要な機能を一つずつ明確にしていく方法を取ります。 この方法は、小規模なシステムでは効率的な場合があります。 一方で、顧客にも一定の協力をお願いすることになります。 業務の流れを説明していただいたり、画面の動作を確認していただいたりすることが必要です。

② プログラム開発
ここは、Knetのような開発会社が最も力を発揮できる部分です。
前述したように、大手SIerが受注したシステムでも、実際のプログラム開発は外部の開発会社が担当することがあります。 つまり、一般的な業務システムであれば、大手SIerを経由せず、Knetへ直接ご依頼いただくことで、必要な機能を実現しながら、開発費用を抑えられます。

もちろん、開発会社によって技術力や得意分野は異なりますので、すべてのシステムについて同じ品質を保証できるという意味ではありません。 また、Knetにも対応できない分野があります。

例えば、最先端の生成AI技術を独自に組み込んだ大規模システムや、高度な専門知識、大人数の開発体制が必要な案件などです。 こうした開発には、専門技術者、研究開発環境、設備投資などが必要であり、現時点のKnetの体制では対応が難しいものがあります。 無理に受注するのではなく、対応できる範囲を明確にすることが重要だと考えています。

③ デザイン
一般的な業務システムの画面デザインについては、Knetでも対応できます。
顧客の希望を聞きながら、ボタンの配置や画面構成を決め、日常業務で使いやすいシステムを目指します。 特に、毎日使用する社内向けシステムでは、見た目の華やかさよりも、操作の分かりやすさや作業効率のほうが重要になることがあります。 ただし、高度なデザイン性や専門的なUI・UX設計が必要な案件については、対応範囲に限界があります。

④ 仕様書・操作マニュアル
ここは、大手SIerとKnetの違いが比較的はっきり表れる部分です。
大手SIerでは、契約内容に応じて、詳細な設計書、仕様書、テスト資料、操作マニュアルなどを体系的に整備することがあります。 一方、Knetでは開発費用を抑えるため、これらの書類は必要最低限の内容とすることを基本にしています。

書類の作成も、立派な開発業務の一部だからです。

もちろん、何も残さないという意味ではありません。 システムの保守や修正に必要な情報、顧客が日常業務で操作するために必要な説明などは、案件に応じて整理します。 ただし、大手SIerと同じ水準の詳細なドキュメントを作成する場合には、そのための時間と費用が別途必要になります。

10．大手SIerとKnet、どちらに依頼すべきか？

大手SIerとKnetの違いを、簡単に整理すると次のようになります。

比較項目大手SIerKnet
大規模システム対応可能な体制を整えやすい対応が難しい
要件定義専門スタッフによる詳細な調査・分析が可能顧客との直接相談を中心に対応
プログラム開発自社開発と外部委託を組み合わせる自社の対応可能な範囲で開発
デザイン専門チームによる対応も可能一般的な業務画面を中心に対応
仕様書詳細な文書整備に対応可能原則として必要最低限
操作マニュアル詳細な文書整備に対応可能原則として必要最低限
プロジェクト管理大規模・複数社の管理に強み小規模案件を中心に対応
開発費用管理・保証体制を含め高額になりやすい範囲を絞ることで抑えやすい

※実際のサービス内容や費用は、各社の契約条件や案件の規模によって異なります。
例えば、全国に数百店舗を展開する企業の基幹システムを全面的に刷新するのであれば、大手SIerのような組織的な開発体制が必要になるでしょう。

一方、年商で数十億円規模の会社が、これまで使用していた業務システムをリニューアルしたい、たとえばオンプレミスをクラウド化したいという場合には、Knetのような中小規模の事業者に依頼する方がコストパフォーマンスは良いと思います。必ずしも大手SIerのような体制が必要とは思いません。

必要な機能を整理し、顧客と開発会社が直接相談しながら進めることで、費用を抑えられる可能性があります。 大切なのは、会社の規模や知名度ではなく、開発したいシステムの内容に合った依頼先を選ぶことです。

11．システム開発の価格には理由がある

システム開発の見積金額を見て、「なぜ、こんなに高いのだろう？」と思われる方も多いでしょう。 しかし、システム開発の費用は、プログラムを書く作業だけで決まるものではありません。 顧客の業務を理解し、必要な機能を整理し、設計し、開発し、テストを行い、完成後も維持できる状態にする。 その一つひとつに、人の時間と技術が必要です。

大手SIerは、これらを組織として一括提供できることに価値があります。 一方、Knetのような中小開発会社は、提供するサービスの範囲を絞り、顧客と直接やり取りすることで、比較的小規模なシステムを低コストで開発できることに強みがあります。 もちろん、安ければよいというものではありません。

要件定義を簡略化すれば、開発途中で認識の違いが生じる可能性もあります。仕様書を簡略化すれば、将来の改修時に負担が増える可能性があります。 そのため、費用を抑える場合には、何を省略し、何を残すのかを顧客と十分に相談する必要があります。

それぞれがどのような仕事を担当し、どこまでの責任を負い、その対価として適正な費用を受け取っているか。

これこそが重要なのだと思います。 そしてKnetとしては、大手SIerと同じことを目指すのではなく、自分たちにできる範囲を正直に伝え、その範囲で顧客にとって使いやすく、費用に見合ったシステムを提供していきたいと考えています。

― 最後にもうひとつ ―

12．システム開発には、お客様の協力も必要です

最後に、開発現場で感じていることを、もうひとつお伝えしたいと思います。
Knetに寄せられるご相談の中には、20年以上前から使用しているシステムを、新しく作り直してほしいというご依頼もあります。 ところが、仕様書の内容が更新されておらず現状とかけ離れていたり、開発当時の担当者がすでに退職しており、システムの内部構造はもちろん、現在どのような仕組みで動作しているのかさえ、十分に把握できないケースがあります。

お客様自身も「現在のシステムと同じように動けばよい」とお考えで、今回の作り直しに際し、現在は使用していない機能、新規事業で追加したい機能などを具体的に説明できない場合があります。 しかし、プログラム開発会社は、何もないところからお客様の業務をすべて推測できるわけではありません。 どれほど経験豊富なプログラマーであっても、お客様の会社独自の業務ルールや、長年の運用で積み重ねられた例外処理まで、最初から理解することは不可能です。

もちろん、既存システムを調査し、動作を解析することはできます。しかし、それにも相応の時間と費用がかかります。 また、現在のシステムがそのように動作しているからといって、それが本当に正しい業務処理であるとは限りません。 長年使い続けるうちに、当初の仕様と実際の業務が食い違っていることもあります。そのため、システムを新しく作り直す際には、開発会社だけでなく、お客様にも積極的にご協力いただく必要があります。

「何を実現したいのか」を決めるのはお客様であり、「それをどのように実現するのか」を考えるのが開発会社の仕事です。

お金を支払えば、開発会社がすべてを理解し、理想のシステムを自動的に完成させてくれるわけではありません。 良いシステムを作るためには、お客様と開発会社が互いの役割を理解し、協力しながら進めることが不可欠です。 Knetでは、そのような関係を大切にしながら、無理のない予算と開発体制で、実際の業務に役立つシステムを作っていきたいと考えています。

業務システムの開発・改修をご検討のお客様へ Knetでは、小規模な業務システムの新規開発や、既存システムの改修についてご相談を承っています。ご希望の内容を伺い、対応できること、難しいことを率直にお伝えいたします。