企業がシステム開発をSIerへ依頼することは、珍しいことではありません。
むしろ大企業ほど、
- 会計
- 人事
- 在庫
- 営業
- 製造
- 購買
- 顧客管理
といった重要な業務システムを、外部の専門企業と一緒に作っています。
これは合理的です。
高度な専門知識が必要なものを専門家へ依頼する。
建物を建てるときに建設会社へ依頼するのと同じです。
しかし基幹システムの場合、一つ注意しなければならないことがあります。
SIerが作っているのは、単なる「道具」なのでしょうか。
それとも、会社がどう動くかを決める「統治構造」なのでしょうか。
昔の書記官の仕事
昔の国家には書記官がいました。
王が、
「この土地にはこの税を課す」
と決める。
書記官が文書にする。
官僚が配布する。
現場で実行される。
この場合、書記官は重要な専門職ですが、あくまで王の決定を文書にする役割です。
王
↓
意思決定
↓
書記官
↓
文書
↓
行政
書記官は命令を正確に記録する。
しかし、原則として命令の内容そのものを決めるわけではありません。
では、現在のSIerはどうでしょうか。
経営者の一言だけでは、システムは作れない
例えば経営者が、
「営業部長には値引き権限を与えたい」
と言ったとします。
これだけではプログラムにはできません。
システムを作るためには、
- 何円までか
- 何％までか
- 自部署だけか
- 他営業所も対象か
- 担当顧客だけか
- 承認後に変更できるか
- 代理承認を認めるか
- 退職・異動時はどうするか
- 履歴を誰が見られるか
まで決めなければなりません。
つまりSIerは、単純に「経営者の指示を書き写す」ことができません。
必ず、
経営判断をコンピュータが扱える規則へ翻訳する作業
が必要になります。
ここでSIerの役割は、書記官より一段大きくなります。
書記官から宰相へ
宰相とは、王の命令を書き写すだけの人物ではありません。
王へ助言する。
政策の選択肢を作る。
行政機構を整える。
各部門を調整する。
時には、
「その政策は実行できません」
「こちらの方が現実的です」
と王へ進言する。
基幹システムを長期間担当するSIerも、これに近い立場になることがあります。
例えば経営者が、
「承認制度を変えたい」
と言ったとします。
SIerから、
「現在のERPでは難しいです」
「この変更をすると会計システムへ影響します」
「標準機能に合わせた方が安全です」
「次の更改まで待った方がよいです」
と説明される。
もちろん、その助言が技術的に正しいことも多いでしょう。
しかし結果として、経営者は、
SIerが提示した実現可能な選択肢の中から経営判断を選ぶ
ことになります。
ここまで来ると、SIerは単なる書記官ではありません。
選択肢を作る人は、意思決定へ大きな影響を与える
経営者に最終決定権があるからといって、実質的な影響力まで経営者だけにあるとは限りません。
例えば、
選択肢A
改修費1億円
選択肢B
現状維持
選択肢C
ERP標準へ業務変更
と提示されたら、多くの場合CかBを選ぶでしょう。
しかし、
「本当にこの3つしか選択肢がないのか」
を経営側が検証できなければ、選択肢を作った側が非常に大きな力を持ちます。
これはITに限った話ではありません。
政策でも、
「どの案を議論のテーブルへ載せるか」
を決める人は大きな影響力を持ちます。
システム開発でも同じです。
SIerは会社の内部を非常に深く知る
さらに、長期間同じSIerへ依頼すると、企業内部の知識がSIer側へ蓄積されていきます。
例えば、
1年目は営業。
2年目は在庫。
3年目は製造。
4年目は会計。
5年目は人事。
というように部門ごとにシステムを刷新するとします。
5年後、SIerは、
- 誰が何を承認しているか
- どこに例外業務があるか
- どの部門同士が対立しやすいか
- どの商品が利益を生んでいるか
- どの処理が会計へ影響するか
- 誰が実質的なキーパーソンなのか
まで理解しているかもしれません。
場合によっては、新しく就任した役員よりSIerの担当者の方が、
「この会社が実際にはどう動いているか」
を知っていることすらあります。
会社の記憶まで外部化される
さらに危険なのが、設計理由が社内に残っていない場合です。
例えば、
「なぜこの取引だけ別処理なのか」
「なぜこの役職だけ特殊権限があるのか」
「なぜこのデータは5年間保存するのか」
という理由が、設計書ではなくSIer担当者の経験として残っている。
すると担当者が、
「これは昔こういう事情がありまして」
と説明しない限り、会社側では判断できません。
この状態では、SIerは単にシステムを管理しているのではありません。
会社の制度の記憶まで保有している
ことになります。
ベンダーロックインの本当の怖さ
ベンダーロックインというと、
「別会社へ乗り換えると高い」
という話になりがちです。
しかし、本当に怖いのは価格だけではありません。
コードがSIerにある
設計書がSIerにある
業務知識がSIerにある
例外処理の理由もSIerにある
権限構造を理解しているのもSIer
となった場合、
別のSIerへ変更する以前に、
自社が自社の仕組みを説明できない
という状態になります。
これは単なるIT依存ではありません。
経営能力の外部化です。
SIerが悪いわけではない
ここは重要です。
SIerが悪意を持って経営権を奪っている、という話ではありません。
むしろSIer側からすると、
「会社側で要件を決めてもらえないから、こちらで整理するしかない」
ということが多いでしょう。
経営側が、
「いい感じにしてください」
「他社と同じでお願いします」
「ERP標準でやってください」
と依頼すれば、SIerが会社の業務を設計せざるを得ません。
その結果として影響力が増える。
つまり問題は、
SIerへ任せることではなく、何を任せるのかを会社側が区別していないこと
です。
実装は任せても、会社の設計は手放さない
企業側が持つべきものは、必ずしもコードではありません。
最低限、
会社
↓
部署
↓
業務
↓
データ
↓
権限
↓
処理
という構造を、自社で説明できる状態にしておく必要があります。
例えば、
「営業担当者は自分の顧客だけ閲覧できる」
「営業所長は営業所全体を見られる」
「本部は全社集計を見られるが、個人情報は人事だけ」
というルールは、会社側が決めるべきものです。
SIerはそれを、
- データベース
- API
- 権限設定
- プログラム
- テスト
へ落とし込む。
この分担なら、SIerは優秀な書記官であり、優秀な技術参謀です。
「何を決めるか」まで任せると宰相になる
反対に、
「誰に何を見せればよいかも考えてください」
「どの承認フローがよいか決めてください」
「どんな業務構造にするかも提案してください」
「ERPに合わせて業務を変えてください」
とすべて任せる。
するとSIerは、
会社の業務を理解する
↓
会社のルールを決める
↓
ルールをシステム化する
↓
変更可能範囲まで決める
立場になります。
これはかなり宰相に近い。
経営者は最終承認するだけで、実際の統治構造を設計しているのはSIer、ということになり得ます。
生成AI時代は、企業側が設計を取り戻せる可能性がある
生成AIによって、システム開発そのもののコストは下がりつつあります。
これまで企業がSIerへ大きく依存した理由の一つは、
「コードを書ける人が社内にいない」
ことでした。
しかしAIによって、
- モデル作成
- CRUD
- API
- テスト
- 管理画面
などの実装コストが下がれば、企業側がすべてを外部へ丸投げする必要性も下がります。
ただし条件があります。
企業側が、
何を作るべきかを設計できること
です。
AIへコードを書かせられても、
「誰が何をできる会社にするか」
を決められなければ意味がありません。
現代企業に必要なのは「自前の宰相」
SIerは必要です。
専門知識も必要です。
外部の知見を使うことも重要です。
しかし会社の中に、
- 業務構造を理解する人
- データ構造を理解する人
- 権限を設計する人
- システム変更と経営への影響を説明できる人
が必要です。
肩書はCIOでも、CTOでも、経営企画でも構いません。
大切なのは、
会社全体の設計図を自社側で持つこと
です。
そうすればSIerは、強力な専門家として使えます。
しかし、その設計図まで外部へ渡してしまえば、会社は次第に、
「SIerに相談しなければ自分の会社を変更できない」
状態になります。
SIerは書記官なのか、宰相なのか
答えは、企業側の姿勢によって変わります。
経営側が、
「何を実現するか」
を決め、
SIerが、
「どう実装するか」
を担当するなら、SIerは現代の優秀な書記官であり技術参謀です。
しかし、
「何を実現すべきか」
までSIerへ任せれば、SIerは宰相になります。
そして経営者がシステム構造を理解できなくなれば、
宰相が提示した選択肢から王が選ぶ
という経営になっていきます。
コンピュータシステムが会社のルールそのものを実行する時代だからこそ、
企業が外部へ任せてよいものと、
決して手放してはいけないものを、
もう一度区別する必要があるのではないでしょうか。