基幹システムを外注しようとすると、非常に高額な見積もりが提示されることがあります。
高額な開発費用
その金額を見て、「大手SIerがぼったくっているのではないか」と感じる人もいるでしょう。しかし、当社は単純にそう考えているわけではありません。
基幹システムの外注化が高額になる最大の理由は、プログラムを書くことが難しいからではありません。
依頼企業の中で不文律となっている業務ルールを、外部の人間が理解できる要件へ変換することが、果てしなく難しいからです。
社員は説明されなくても仕事ができる
社内では、社員同士が共通の経験や企業文化を持っています。
「この場合は先に部長へ確認する」
「この取引先だけは通常と処理が違う」
「作業完了と請求可能は別である」
「金額が一定以上なら社長の承認が必要になる」
こうしたルールは、必ずしも社内規程や業務マニュアルに書かれているとは限りません。長年働いている社員同士であれば、あえて説明しなくても仕事が進みます。
ところが、外部のSIerはその不文律を知りません。
そのため、何度もミーティングを行い、社員の言葉から業務ルールを引き出し、例外を確認し、外部の技術者にも理解できる要件へ変換する必要があります。
社員もすべてを外部へ話せるわけではない
要件定義を難しくするもう一つの理由が、情報開示の問題です。
基幹システムの設計には、単なる作業手順だけでなく、取引上の事情、社内の権限関係、価格の決め方、顧客ごとの対応、会計処理、企業文化なども関係します。
当然、その中には企業機密も含まれます。
社員は、外部企業であるSIerに対して、
「この情報まで話してよいのだろうか」
「他部署の事情を自分が説明してよいのだろうか」
「正式なルールではないことを話して問題にならないだろうか」
と考えながら、恐る恐る受け答えをすることになります。
しかも、同じ業務について複数の社員へ質問すると、説明が食い違うこともあります。
SIerは、その断片的な情報から会社の実態を推測し、矛盾を整理し、要件定義書へまとめ、関係者全員の合意を得なければなりません。
高額な開発費用には「翻訳と合意形成」の費用が含まれている
外部のSIerが行っているのは、単なるプログラミングではありません。
- 現場から業務ルールを聞き出す
- 部署ごとの認識の違いを整理する
- 曖昧な言葉の意味を定義する
- 例外処理を洗い出す
- 要件定義書へ変換する
- 関係者から合意を得る
- 将来の変更による影響を予測する
- 障害や情報漏えいに対する責任を負う
こうした工程に、多くの時間と人員が必要になります。
個々の見積もりが妥当かどうかは別として、開発費用が高額だからという理由だけで、SIerが不当に利益を得ているとは断定できません。
発注企業から見える契約総額と、現場で働く技術者が受け取る報酬も同じではありません。現場の技術者は、限られた情報と納期の中で、非常に高い成果と責任を求められています。
外注では、気づきが「仕様変更」になる
基幹システムでは、実際に動かしてから初めて分かることが数多くあります。
内製化であれば、現場の担当者が社内掲示板などに、
「もしかして、この処理は違うのではないか」
「この場合は、こちらを先に確認するべきではないか」
と書き込めます。
社長やCIO、業務責任者がその内容を確認し、正しいと判断すれば、その時点で仕様を修正できます。
一方、外注の場合は、一つの認識違いを修正するためにも、
仕様変更 → 影響調査 → 再見積もり → 承認 → 契約変更 → 開発 → テスト
という工程が必要になります。
外注先から見れば、当然の手続きです。口頭で依頼された変更を無条件に反映すれば、責任の所在が分からなくなるからです。
しかし発注企業から見ると、「少し直すだけなのに、なぜ時間と費用がかかるのか」という不満につながります。
内製化では、要件定義を育て続けられる
当社が考える内製化とは、すべてのプログラムを社員だけで書くことではありません。
自社の業務を自社の言葉で整理し、何を既存のSaaSに任せ、何をAPIで接続し、何を独自に作り、どの情報を会計へつなぐのかを、自社で判断できる状態をつくることです。
外部の技術者へプログラミングを依頼することはできます。しかし、会社の業務構造や設計意図まで外部へ丸投げしてはいけません。
内製化であれば、要件定義を最初から完全なものにする必要はありません。小さな業務から始め、現場で発見された事実を取り込みながら、少しずつ正しい構造へ育てていけます。
もちろん、会計・請求・在庫・権限など、会社の資産を変化させる処理を、その場の判断だけで本番環境へ反映してよいわけではありません。仕様をすぐに修正できることと、テストをせずに公開することは別です。
重要なのは、修正の意思決定を社内で行い、契約上の摩擦なく、検証と改善を続けられることです。
外注してはいけないのは、経営判断である
基幹システムは、会社の仕事を会社自身の言葉で表現したものです。
その設計の大本を理解していなければ、経営者は、どの業務を内製化するのか、どのSaaSを利用するのか、どの技術者へ依頼するのかを判断できません。
外注してよいのは、専門的な実装作業です。
外注してはいけないのは、自社に必要なシステムを決める経営判断です。
外注では、要件定義を完成させてから作らなければならない。
内製では、要件定義そのものを日常の経営活動として育て続けられる。
基幹システムの外注化が難しい理由は、システムが高度だからではありません。
会社の中にある言葉、文化、判断、例外、責任関係を、外部の人間へ完全に伝えることが難しいからなのです。
コメントを残す