コラム - お役立ち情報

2022.06.29

システム開発って高い!

皆さんの会社で、既製品のコンピュータソフトウェアでは実現できない仕事があるのだけれど、やはり人手に頼ったままでは時間がかかりすぎるとか、属人的になってしまって担当が休むことすらできないとか、高額なシステム買っても何年かで元が取れるんじゃないの、とか色々考えた末にカスタムメイドの情報システムを構築しよう、となったとしましょう。
自社で構築することができる情報システム部門が存在する場合は人件費が固定費となってしまっているので、構築にかかる費用が軽視されがちです。しかし社外に構築を委託する場合はガッチリと現金の形で構築費が表面化します。

弊社のようなSIerがカスタム仕様のシステムを受託開発するときには先ず要件をヒアリングし、概要設計して、時には詳細部まで設計し、お見積を作成します。

その見積を見たとき、殆どのお客様が「高い!」と感じるのではないでしょうか。
例えばニュース等で国が主導したシステム(最近だと「新型コロナウイルス接触確認アプリ COCOA」は約4億円)や、大手銀行のシステム構築(UFJ銀行 3,300億円、みずほ銀行 4,000億円)の報道を聞くと途方も無い金額に愕然とします。
こういう巨大な案件では多くの会社が絡んで下請け~孫請け~ と委託するうちにオーバーヘッド費用が嵩むので、純粋な開発にかかる費用はもっと少ないのですが、1社だけで巨大システムを開発しようとしても人員が足りず完成時期が遥か未来になってしまうためシステム開発の費用は規模に比例せず、規模2乗的に上昇することが避けられません。
そんな巨大システムの話ではなくても、システム構築の商談の際には見積もり価格が「機能相応だね」とか「意外と安いね」などと言われることはまずありません。
相見積もりになったときに他社の見積と比べて「安いな」といわれることはあります。でもあくまで比較して相対的に、の話なので絶対評価で安い、と思われることはほぼ無いです。
このようにシステム開発が「高い」と思われがちな理由を開発者の目線から解説したいと思います。

システム開発とは?

システム開発は、よく建築の工程に例えられます。
 • 要件分析/ヒアリング
 • 設計
 • 構築/建築施工
 • 試験/検査
 • 導入/引渡

似ている両者ですが、大きく違う点を挙げると
1.建築は一度設計すると何度も使いまわして建築することができる。

完全注文建築では設計は1回しか使用しないが、その場合は相応に高額になる。
また注文建築であっても家を構成する要素はほぼ決まっており、細部に至るまで全く新規の構成要素のようなものはほぼ発生しない。
一方システム開発では同じ設計が使えるケースではソフトウェアをコピーできるため、構築そのものが発生しない。開発案件となる場合は必ず新設計になる。
ソフトウェアは極めて広範囲の分野に適用されるため、全く新規の解法を編み出さねばならないことが多い。

2.建築は物理的に見える/触れるものを造る。

システム開発はUI部分こそ見えるが、ソフトウェアとして動作している大部分は見えないので開発会社の外からは規模感、複雑さが判り難い。
人は見えない部分のサイズを含めずに全体の規模感を暗黙に想定してしまうのでソフトウェアは実際より小規模で安価だという予断を持ちやすい。

3.建築は物理的な建材を相手にしているので「切ってしまった」「穴を開けてしまった」ものは元に戻せない、との暗黙の認識が共有されやすい。

ソフトウェアはキーボードから打ち直すだけで簡単に変更/修正できると思われがちで、作る前の検討が真剣に実施されにくい。
そのため構築後の修正要求で費用が嵩む。

4.建築では設計変更したとき、どこに影響が波及するかが比較的明らかで、物理的距離が近い、繋がっている箇所に影響することがほとんど。

ソフトウェアでは変更が影響する箇所がコード上の距離の近さだけでは判断できず、確証を持つには動作テストをするしか無い。

5.建築では既に構築済みの物件への増改築は土地の制限や法的な制限、物件に使用されている建材の老朽化等から、限られた条件でしか実施されない。

ソフトウェアではそのような制限がないので何回もバージョンアップと称した増改築が実施される。
法改正などがあっても建築物は急に適法改修などできないので新規建築から適用、とされることがほとんどだが、
ソフトウェアは既存システムであっても期限までの適法改修が求められる(法令の改定等)。
ソフトウェアの増改築は既存部分への影響を鑑み、追加されるソフトウェアの規模だけでなく元になるシステムの規模にも影響されて手間が増える。

これらソフトウェア/システム開発ならでは、の事情は開発を行う仕事に従事していないと中々感覚的に分からないものです。
ですので「中の人」からシステム開発、特に受託開発でのコスト構造を解説したいと思います。

コンピュータには「当たり前」「当然」が無い


人間が仕事を新人さんに手ほどきしているとしましょう。
ベテランさんは相手の前提知識、例えば前職職歴や学校で専攻していたことを鑑み、彼/彼女が知らないはず、という部分だけを教えると思います。
例えば「このプログラムは毎日9時に経理の人が使うから・・・」と教えているとき、両者の間で暗黙に「午前9時」と了解しています。
何故なら「経理の人」が使うと言っているので午後9時ではないだろう、と常識を自然と当てはめるからです。
しかしコンピュータシステムに「09:00」と指示したらどうなるでしょうか。24時間制の指定なら運良く午前9時に実行されるでしょう。
12時間制の指定なら1日に2回動作するという意味になってしまうかも知れません。
この「当たり前」が要求仕様に書かれていなくてもプログラム上にはきっちり実装しなければお客様が期待したシステム挙動にならないので、仕様を「補完する」技術が求められ、当然その部分を実装するコストが発生するのです。

テストに非常に多くのコストがかかる

ここが「中の人」とそれ以外の人で認識が大きく違ってくる部分です。システム開発では全コストのうち、非常に大きな部分をテストが占めます。
この部分について言えば建築よりも医薬品の開発のほうが構造的に近いかも知れません。
テストというものはかなり恣意的に増減されます。テストは「これだけやれば充分」という限界がありません。金融系、医療系のシステムは極めて厳格に、大量のテストが行われます。また個人情報を扱う機能、お金の出入りを扱う機能も重量級のテストが行われる分野です。
ソフトウェア開発には「自動テスト」というツールが有り、言葉の響きからすると救世主になってくれそうな感じがします。ですが自動テストというのはテスト実施シナリオ、テストに供するデータを厳格に用意する必要があり、この準備にまたかなりのコストがかかるのです。1回実施するだけなら自動テストは全くコスパに見合いません。同じテストを何度も実施する(再帰テストといいます)ためのツールです。自動テストツールを導入しても全テストを任せることはできません。日時に依存したテストケースは予め用意して再利用できないことが殆どですし、システムがバージョンアップを重ねるにつれ過去に用意したテストデータが使えなくなることも起こるからです。

対象のソフトウェア(アプリケーション)そのものだけを作れば終わり、ではない

ソフトウェアを動作させるためにコンピュータ/サーバの構成を変更したり、サーバ上でアプリケーションを動作させるための他のソフトウェア、所謂ミドルウェアやデータベース、Webサービス、メールサービスといった諸々のコンポーネントが揃って初めてアプリケーションの動作が可能になります。これらの構成はプログラムを書く人たち(プログラマ)とは別の知識と経験を持ったエンジニアが必要です。
家を建てる時に、家そのものの建築だけでなく整地や、水道ガス電気電話等のインフラの引き込み、関係役所への許認可申請、ご近所への挨拶、といったようなタスクも必要になるのと似たものでしょうか。
このような裏方さんの仕事ができるエンジニアは比較的人口が少なく、単価が高めになる傾向があることも記しておきます。

システムには「非機能要件」が実装される

システムでも建築でも、「こうして欲しい」と明示的にリストされるのが「機能要件」、と名付けておいて、その逆に明示的に要求されないけれども家を建てるなら満たしていないといけない要件や、機能要件に連動して同時に満たさないといけない要件をプロの目線で、指定されなくてもリストアップする。
そのようなものを「非機能要件」と言います。
システム開発での典型的な非機能要件の例を上げると、
1. セキュリティ:ログイン等の仕組みを実装し、正規利用者以外がシステムを使用できないようにする。

またシステム内のデータに正規手順を踏まずにアクセスできないように構成する。
パスワードの複雑さ(8文字以上、英数混ぜて、とか)やパスワード忘れのときの手段の設計実装。
誰がどのような操作をしたのか後から確認できる記録(監査機能)。
世間や業界で一般に知られるシステム攻撃手段の対策を一通り施す。

2. 耐障害性:ハードウェアの故障によるシステム停止を防ぐ、最小限にする構成上の工夫を施す。(冗長化等)

故障してしまってもデータが失われることが無いように、若しくは最小限になるよう設計する。(冗長化、バックアップ計画)
故障ではなくても、人的ミスで消してしまったデータを復元する手段の確保。
法令で保存期間が定められているデータの保存方法設計。(アーカイブ)

3. パフォーマンス:どの画面も10秒以内に応答する。09:00~10:00は100人がログインして使用する、等。
4. 容量:保存できるデータは10,000人のユーザがそれぞれ100件のデータ登録することができる、等。

このような非機能要件はお客様側では想定していないか、していてもかなり小さく考えていることが殆どで、開発見積を提示すると内訳から「頼んでもいない」部分に高額が費やされることに驚き、そしてどうにかして削れないか、と言われますが非機能要件は得てして「保険」的な意味合いが強く、悪意ある攻撃者に侵入されてしまったり事故でデータが壊れてしまってからではどうにもなりません。

ノウハウの継続


これは新規開発ではなく、開発終了してからの保守のお話です。開発したら殆どの場合「保守契約」を締結して頂き、おそらく「高い!」と言われる費用を負担していただくことになります。保守は何ら新しい機能が増えるわけでもないのにお金を払う、一見不合理な仕組みです。システムではなく機械などであれば「保証期間」に該当し、経年劣化や消耗品を除く故障に対して無償修理してもらえます。保証に入らなければ、故障したときに有償修理となるので、こちらを選択することもあるでしょう。
しかしながらシステム開発の保守は、保守契約せずに不具合生じたときに有償対応してね、というわけには行かないのです。
受託開発したシステムは世界に一つのカスタムメイドです。もし機械でも完全カスタムな造りであれば「不具合出たらその時有償修理」を受けてくれる会社はそうそういないでしょう。何故なら、保守契約しなければそのカスタム品に関する知識、ノウハウを維持継承しないからです。
ソフトウェアの受託開発は全ての製品がカスタム品ですから、保守契約しなければ開発終わって納品したら終わり。暫くは設計書などを保管しているでしょうが、そのシステムの「中身が解る人」を引き継いで維持するコストを正当化できないため、「お金払うから対応して」と言われても分かる人がいなくなっていれば無理なのです。つまり保守契約の最大の役割は、カスタムメイドのシステムのノウハウを維持することなのです。

まとめ

如何でしょうか。
システム開発を委託しようとしたとき、その費用総額の内、正味要件の実現のためのソフトウェア開発費はほんの一部分だけ、ということがお分かりいただけましたでしょうか。
例えるなら高級レストランでディナーを戴く、そうしたらコース3万円です!とメニューに載っていました。その時、
「いくら上質な材料使っていると言っても原価10%くらいだろうな」「雰囲気に金払っているようなものだな」「ボッタクリだ!」
と考えますか?

高級レストランでしっかりとしたメニューを提供できるようになるには恐らく、
・相応のシェフ、スタッフの修行年数
・調理技術の継続的な向上、維持
・器具、設備の投資と維持
・高級にふさわしい立地と建物、インテリアへの投資と維持
・高級にふさわしいスタッフの雇用と教育
これらのコストが高級の名に足る信用を支えているのです。
情報システムも本要件本体だけの実現ではなく、社会的に「きちんとしている」ものであるためにこれだけのコストがかかっているのです。