カテゴリー: システム開発内製化

基幹システムを外注しようとすると、非常に高額な見積もりが提示されることがあります。

高額な開発費用

その金額を見て、「大手SIerがぼったくっているのではないか」と感じる人もいるでしょう。しかし、当社は単純にそう考えているわけではありません。

基幹システムの外注化が高額になる最大の理由は、プログラムを書くことが難しいからではありません。

依頼企業の中で不文律となっている業務ルールを、外部の人間が理解できる要件へ変換することが、果てしなく難しいからです。

社員は説明されなくても仕事ができる

社内では、社員同士が共通の経験や企業文化を持っています。

「この場合は先に部長へ確認する」

「この取引先だけは通常と処理が違う」

「作業完了と請求可能は別である」

「金額が一定以上なら社長の承認が必要になる」

こうしたルールは、必ずしも社内規程や業務マニュアルに書かれているとは限りません。長年働いている社員同士であれば、あえて説明しなくても仕事が進みます。

ところが、外部のSIerはその不文律を知りません。

そのため、何度もミーティングを行い、社員の言葉から業務ルールを引き出し、例外を確認し、外部の技術者にも理解できる要件へ変換する必要があります。

社員もすべてを外部へ話せるわけではない

要件定義を難しくするもう一つの理由が、情報開示の問題です。

基幹システムの設計には、単なる作業手順だけでなく、取引上の事情、社内の権限関係、価格の決め方、顧客ごとの対応、会計処理、企業文化なども関係します。

当然、その中には企業機密も含まれます。

社員は、外部企業であるSIerに対して、

「この情報まで話してよいのだろうか」

「他部署の事情を自分が説明してよいのだろうか」

「正式なルールではないことを話して問題にならないだろうか」

と考えながら、恐る恐る受け答えをすることになります。

しかも、同じ業務について複数の社員へ質問すると、説明が食い違うこともあります。

SIerは、その断片的な情報から会社の実態を推測し、矛盾を整理し、要件定義書へまとめ、関係者全員の合意を得なければなりません。

高額な開発費用には「翻訳と合意形成」の費用が含まれている

外部のSIerが行っているのは、単なるプログラミングではありません。

• 現場から業務ルールを聞き出す
• 部署ごとの認識の違いを整理する
• 曖昧な言葉の意味を定義する
• 例外処理を洗い出す
• 要件定義書へ変換する
• 関係者から合意を得る
• 将来の変更による影響を予測する
• 障害や情報漏えいに対する責任を負う

こうした工程に、多くの時間と人員が必要になります。

個々の見積もりが妥当かどうかは別として、開発費用が高額だからという理由だけで、SIerが不当に利益を得ているとは断定できません。

発注企業から見える契約総額と、現場で働く技術者が受け取る報酬も同じではありません。現場の技術者は、限られた情報と納期の中で、非常に高い成果と責任を求められています。

外注では、気づきが「仕様変更」になる

基幹システムでは、実際に動かしてから初めて分かることが数多くあります。

内製化であれば、現場の担当者が社内掲示板などに、

「もしかして、この処理は違うのではないか」

「この場合は、こちらを先に確認するべきではないか」

と書き込めます。

社長やCIO、業務責任者がその内容を確認し、正しいと判断すれば、その時点で仕様を修正できます。

一方、外注の場合は、一つの認識違いを修正するためにも、

仕様変更 → 影響調査 → 再見積もり → 承認 → 契約変更 → 開発 → テスト

という工程が必要になります。

外注先から見れば、当然の手続きです。口頭で依頼された変更を無条件に反映すれば、責任の所在が分からなくなるからです。

しかし発注企業から見ると、「少し直すだけなのに、なぜ時間と費用がかかるのか」という不満につながります。

内製化では、要件定義を育て続けられる

当社が考える内製化とは、すべてのプログラムを社員だけで書くことではありません。

自社の業務を自社の言葉で整理し、何を既存のSaaSに任せ、何をAPIで接続し、何を独自に作り、どの情報を会計へつなぐのかを、自社で判断できる状態をつくることです。

外部の技術者へプログラミングを依頼することはできます。しかし、会社の業務構造や設計意図まで外部へ丸投げしてはいけません。

内製化であれば、要件定義を最初から完全なものにする必要はありません。小さな業務から始め、現場で発見された事実を取り込みながら、少しずつ正しい構造へ育てていけます。

もちろん、会計・請求・在庫・権限など、会社の資産を変化させる処理を、その場の判断だけで本番環境へ反映してよいわけではありません。仕様をすぐに修正できることと、テストをせずに公開することは別です。

重要なのは、修正の意思決定を社内で行い、契約上の摩擦なく、検証と改善を続けられることです。

外注してはいけないのは、経営判断である

基幹システムは、会社の仕事を会社自身の言葉で表現したものです。

その設計の大本を理解していなければ、経営者は、どの業務を内製化するのか、どのSaaSを利用するのか、どの技術者へ依頼するのかを判断できません。

外注してよいのは、専門的な実装作業です。

外注してはいけないのは、自社に必要なシステムを決める経営判断です。

外注では、要件定義を完成させてから作らなければならない。
内製では、要件定義そのものを日常の経営活動として育て続けられる。

基幹システムの外注化が難しい理由は、システムが高度だからではありません。

会社の中にある言葉、文化、判断、例外、責任関係を、外部の人間へ完全に伝えることが難しいからなのです。

システム内製化の強み

システム開発では、最初に要件定義書を作り、次に設計書を作り、それをエンジニアがコードへ変換する方法が一般的です。

しかし、この方法では同じシステムを異なる形式で何度も表現することになります。

経営者や現場担当者の言葉
↓
要件定義書
↓
設計書
↓
プログラムコード
↓
非コーダー向けの操作説明書

工程が増えるたびに、翻訳作業と確認作業が発生します。

さらに、仕様を変更した場合には、要件定義書・設計書・コード・説明資料をそれぞれ修正しなければなりません。

この二重、三重の管理が、システム開発費用を押し上げる大きな原因になっています。

当社は、AI時代には要件定義そのものをコードで表現し、コードを唯一の原本として管理する方法が広がっていくと考えています。

「コードを原本にする」とはどういうことか

コードを原本にするとは、要件を整理せず、いきなりプログラムを書き始めることではありません。

会社の業務構造と判断ルールを、コード上で直接表現するという意味です。

• ディレクトリの配置で、会社・部署・業務の境界を表現する
• クラスで、人・物・取引・出来事を表現する
• プロパティで、記録すべき情報や状態を表現する
• メソッドで、実行可能な業務処理を表現する
• ドックストリングで、設計目的・判断理由・制約・例外を説明する
• テストコードで、具体的な処理例と期待結果を表現する

例えば、請求書を発行する条件が、

「検収が完了していること」

「金額が100万円以上の場合は代表者の承認を得ていること」

であれば、次のように表現できます。

from decimal import Decimal


class 請求:
    """
    検収が完了した取引だけを請求対象とする。

    金額が100万円以上の場合は、
    代表者の承認を必要とする。
    """

    検収済み: bool
    金額: Decimal
    代表者承認済み: bool

    def 発行できる(self) -> bool:
        if not self.検収済み:
            return False

        if self.金額 >= Decimal("1000000"):
            return self.代表者承認済み

        return True

このコードには、請求に必要な情報、判断条件、例外、処理結果が表現されています。

ドックストリングを読めば、人間もその設計意図を確認できます。AIに読ませれば、経営者や現場担当者向けの説明文へ変換することもできます。

さらにテストコードを用意すれば、

• 未検収なら発行できない
• 50万円なら代表者承認なしでも発行できる
• 120万円なら代表者承認が必要になる

という具体例まで、実行可能な要件として残せます。

要件定義書からコードへの翻訳が不要になる

従来の開発では、要件定義を行う人とコードを書く人が別になっていることがあります。

要件定義書を書いた人の意図をエンジニアが読み取り、コードへ翻訳します。認識に違いがあれば、質問、回答、文書修正、再確認が必要になります。

コード自体を要件定義の原本にすれば、この翻訳工程を大幅に減らせます。

業務上の概念をクラスとして配置し、必要な情報をプロパティとして定義し、許可された操作をメソッドとして記述します。判断理由や例外は、そのコードに最も近いドックストリングへ残します。

要件と実装が同じ場所に存在するため、「設計書には書いてあるがコードには反映されていない」という状態も起きにくくなります。

修正費用も圧縮できる

業務ルールは、システムを実際に使う中で少しずつ明らかになります。

現場から、

「この場合は承認者が違うのではないか」

「作業完了と請求可能は別の状態ではないか」

「この取引先だけ例外処理が必要ではないか」

という気づきが出ることがあります。

文書とコードを別々に管理している場合は、影響する要件定義書と設計書を探し、文書を修正し、合意を取り直し、その後でコードを変更します。

コードを原本にしていれば、該当するクラス、プロパティ、メソッド、ドックストリング、テストを確認し、同じ場所で設計と実装を修正できます。

もちろん、会計・請求・在庫・権限など、会社の資産を変化させる処理は、テストや承認を経てから本番環境へ反映しなければなりません。

しかし、仕様を修正するたびに複数の原本を更新する必要はなくなります。

非コーダーにコードを読ませる必要はない

コードを原本にすると聞くと、「経営者や現場担当者はコードを読めない」という疑問が出てきます。

しかし、非コーダーが原本を直接読む必要はありません。

AIを利用すれば、コードから次のような資料を作成できます。

• 経営者向けのシステム全体説明
• 現場担当者向けの業務手順
• 会計専門家向けの処理条件
• 部署間の業務フロー
• 権限と承認経路の一覧
• システム構成図
• 操作マニュアル

これらの資料は、それぞれが独立した原本ではありません。コードという一つの原本を、利用者に合わせて見やすく変換したものです。

コードを変更した場合は、変更後のコードから資料を作り直します。

これにより、古い設計書や操作マニュアルだけが残り、実際のシステムと内容が食い違う問題を減らせます。

AI時代には要件定義とプログラミングの境界が薄くなる

従来は、人間が要件定義書を書き、それを読んだエンジニアがプログラムを書く必要がありました。

生成AIは、人間が説明した業務ルールから、クラス、プロパティ、メソッド、ドックストリング、テストコードの案を作れます。

反対に、既存コードを読み取り、非コーダー向けの説明資料を作ることもできます。

つまり、AIが人間の言葉とコードの間を往復できるようになったことで、要件定義書を独立した原本として維持する必要性が小さくなります。

今後は、

人間が業務上の判断を行う
AIとともにコード上へ構造化する
動く状態で確認する
必要な資料をコードから生成する

という開発方法が日常化していくと当社は考えています。

有力候補となるプログラミング言語がPythonである

当社は、コードを要件定義の原本とする時代において、Pythonが有力候補になると考えています。

Pythonは、クラス、プロパティ、メソッドなどを比較的簡潔な構文で表現できます。

ドックストリングをコードの近くへ記述できるため、何を処理するのかだけでなく、「なぜその構造にしたのか」という設計意図も残せます。

Pythonを使う目的は、単に少ない文字数でプログラムを書くことではありません。

自社の業務を、人間とAIの双方が理解しやすい構造で表現することです。

会社、部署、業務、担当者、承認者、取引、会計上の出来事をコード上へ配置し、その関係を人間が確認できる状態にします。

圧縮されるのは、プログラミング費用だけではない

コードを原本にすることで圧縮できるのは、コードを書く費用だけではありません。

• 要件定義書を作成する費用
• 設計書へ変換する費用
• 要件定義書とコードを照合する費用
• 仕様変更時に複数の文書を修正する費用
• 非コーダー向け資料を一から作る費用
• 古い文書と現在のコードの違いを調査する費用
• 関係者間の認識違いを修正する費用

こうした翻訳・確認・二重管理にかかる費用を圧縮できます。

要件定義そのものをコードで表現するとは、要件定義を省略することではありません。

要件定義と設計と実装を、同じ原本の上で行うことです。

AI時代のシステム開発では、コードは完成品だけではありません。

会社の業務構造、判断基準、設計意図を保存する、最も正確な原本になっていくのです。