内製化の目的は、製品を作ることではなく主導権を持つことである

属人化を減らすために、システムを内製化するべきだという議論があります。外部のベンダーへ依存せず、社員が設計、構築、運用を担当すれば、知識が社内へ蓄積されるという考え方です。

しかし、社員が作業を担当することと、知識が組織へ蓄積されることは同じではありません。個別製品の設計、構築、試験、現地作業、保守まで社員が抱えた結果、限られた担当者だけがシステムを理解することがあります。設計の根拠や障害時の挙動が文書化されず、チャット、口頭説明、個人の作業メモだけで運用されれば、内製したシステムであっても属人化します。

これはベンダー依存を解消したというより、社内に小さな SIer を作り、その内部で個人依存を再生産した状態です。通信キャリアなど、多数の基盤システムを長期間運用する組織では、内製か外注かを一律に決めるべきではありません。どの能力を自社へ残し、どの実装を市場から調達するかを設計する必要があります。

ベンダーへ任せても、属人化はなくならない

個別製品の詳細設計、構築、製品試験、バージョンアップ、障害解析などは、その製品を扱うベンダーへ任せた方が合理的な場合があります。ただし、ベンダーへ委託すれば属人化がなくなるわけではありません。

ベンダー側でも、特定の技術者だけが構成や導入経緯を把握していることがあります。その担当者が異動や退職をすれば、契約が継続していても、回答品質や障害対応能力が低下する可能性があります。したがって、社員個人への依存をベンダー担当者への依存へ移しただけでは、属人化対策にはなりません。

法人へ依存する利点は、法人であれば自動的に知識が継承されることではありません。責任、成果物、要員体制、知識移転、契約終了時の対応を、組織間の合意として要求できる点にあります。英国政府の Sourcing Playbook は、契約終了時に退任する供給者と後継の供給者、または内製体制を接続する退出計画を契約へ組み込むよう求めています。契約の存在だけでは移行は成立せず、切替可能性を具体的に設計する必要があるということです。

この考え方は、NIST Cybersecurity Framework 2.0 の Cybersecurity Supply Chain Risk Management、つまり GV.SC にも具体的に表れています。NIST CSF 2.0 は本来サイバーセキュリティリスクを対象とするフレームワークであり、属人化対策や SI 委託一般の統治基準ではありません。ただし、外部の供給者へ重要な機能を依存し、その依存関係を契約前から終了後まで管理するという問題構造は、一般的なベンダー統治とも共通しています。

ここでは NIST CSF 2.0 を SI 一般へ直接適用するのではなく、供給者依存をライフサイクル全体で管理する構造を参考にします。

サブカテゴリー	求めていること
GV.SC-02	供給者、顧客、パートナーとの役割と責任を内外で調整する
GV.SC-05	サプライチェーン上のリスク要件を契約などへ組み込む
GV.SC-07	供給者とその製品・サービスのリスクを関係期間中継続して管理する
GV.SC-09	供給者管理の実効性を製品・サービスのライフサイクル全体で監視する
GV.SC-10	契約や提携が終了した後の活動も計画へ含める

発注時に要件を書き、納品時に文書を受け取るだけでは不十分です。導入前の評価、契約への反映、運用中の監視、契約終了後の処理までを一つのライフサイクルとして扱う必要があります。ベンダー依存をなくすことは現実的ではありません。必要なのは、依存先、責任、保有情報、切替条件を明確にし、別の体制へ移れる状態を維持することです。

自社に残すべきものは統治能力である

個別製品の SI をベンダーへ任せる場合でも、意思決定まで任せるべきではありません。自社には、サービス要件、非機能要件、全体アーキテクチャ、製品選定、責任分界、受入基準、ライフサイクル方針を決める能力が必要です。

社員が保持すべきなのは、特定製品の全てのコマンドや設定項目ではありません。ベンダーが提案した構成について、要求を満たしているか、技術的な必然性があるか、製品固有の都合ではないか、障害時の挙動を許容できるか、試験によって妥当性を確認できるかを判断できることです。この能力がなければ、SI を委託したのではなく、意思決定そのものを外部へ移したことになります。

英国政府の Digital, Data and Technology Playbook は、市場の製品や能力を利用する一方で、発注側にもソリューションを管理できる知識と受入能力が必要だとしています。特に、社内に知識移転の受け皿を維持し、成果物の所有と再利用を可能にし、供給者を将来の商業判断から分離できる統治を求めています。

ベンダー活用と技術力の保持は対立しません。実装を外部へ任せながら、要求、判断基準、評価能力を自社へ残すことは可能です。

簡単だから内製する、という判断も雑である

難しいものはベンダーへ任せ、簡単なものは内製する、という切り分けも一見すると合理的に見えます。しかし、これもかなり雑な判断です。簡単に構築できることと、組織として継続的に維持できることは別だからです。

簡単な仕組みほど、導入直後は誰でも分かるように見えます。そのため、設計判断、設定理由、障害時の確認手順、更新方法、責任分界が軽く扱われやすくなります。時間が経つと、担当者は別の仕事へ移り、周囲も関心を失い、誰も深く覚えていないが止めることもできない小さな基盤だけが残ります。

この種の領域では、むしろベンダーの組織力を使う意味があります。作業が高度だから任せるのではなく、簡単で退屈に見える作業を、手順、体制、保守契約、定期点検、問い合わせ窓口、変更履歴として維持させるために任せるという考え方です。法人として継続的に扱わせることで、個人の興味や記憶に依存しない状態を作れます。

もちろん、簡単なものをすべて外部へ出せばよいわけではありません。自社が保持すべき判断基準、受入条件、停止時の影響、契約終了時の移行条件を持たないまま委託すれば、依存先を変えるだけです。重要なのは、難易度ではなく、継続責任、知識の残り方、切替可能性、組織として関心を維持できるかで判断することです。

統治能力も属人化する

「実装はベンダーへ任せ、統治は社員が担う」と整理しただけでは、問題は解決しません。要件を定義できる社員、ベンダーの設計を評価できる社員、受入可否を判断できる社員が一人しかいなければ、属人化を製品実装の層から統治の層へ移しただけです。

NIST CSF 2.0 では、GV.RR-02 がリスク管理に関する役割、責任、権限を明確にし、理解され、実行されることを求めています。GV.RR-03 は、その役割と戦略に見合う資源を配分することを求めています。これらも本来はサイバーセキュリティリスク管理に関する要求ですが、統治を個人の力量だけに依存させず、役割、権限、資源を組織として定義するという構造は、技術統治にも援用できます。

統治能力を組織へ定着させるには、重要な設計判断を複数人でレビューし、採用理由、却下した代替案、前提条件、リスクを意思決定記録として残す必要があります。要求仕様、評価基準、試験基準、例外承認の方法も共通化します。正担当と副担当を置くだけではなく、実際のレビュー、ベンダーとの協議、障害対応へ複数人が参加しなければ、知識は移転しません。

文書を残す目的も、情報量を増やすことではありません。別の人が同じ前提に立ち、判断の過程を追跡し、必要であれば異なる結論を出せるようにすることです。

技術研究と商用 SI は分けて考える

個別製品の商用 SI を外部へ任せる場合でも、社員による技術研究は必要です。新しい技術や製品を実際に触り、構成を試し、性能、障害、復旧、運用上の制約を確認しなければ、ベンダーの提案を評価できません。

ただし、技術研究の目的は、社員だけで商用システムを構築し、恒常的に保守できるようになることではありません。研究で確認した技術的成立性は製品選定基準へ、性能傾向は性能要件と試験条件へ、障害時の挙動は可用性要件と障害試験へ変換します。製品や方式の制約は、リスク、責任分界、契約条件へ反映します。

研究環境では社員が手を動かし、商用導入では得られた知見を要求と受入基準へ変換する。この境界が必要です。技術研究を行った社員が、商用環境の構築、現地作業、定常運用、障害対応まで恒常的に抱えると、研究者は保守要員になります。新しい技術を検証する時間が失われ、組織が保持しようとした技術力そのものが低下します。

内製対象は統合層だけとは限らない

多くの企業では、個別製品そのものより、複数の製品や業務を結び付ける部分に内製価値があります。既存製品が提供する専門機能を利用しながら、自社固有の顧客、契約、サービス、リソース、監視、課金、運用などを一つのライフサイクルとして管理する部分です。

製品の API を利用し、上位に自社の情報モデルやオーケストレーションを置けば、個別製品の違いを一定範囲で吸収できます。上位の業務システムへ製品固有の仕様を直接広げなければ、製品更改時の影響も抑えられます。

ただし、内製対象は常に統合層であるとは限りません。製品機能そのものが競争力、サービス品質、規制対応、知的財産の中核になる場合は、その機能を内製する合理性があります。市場に適切な製品が存在しない場合や、既製品では重要な要求を満たせない場合も同様です。

内製範囲は、次の観点で判断する必要があります。

判断観点	内製へ寄る条件	外部調達へ寄る条件
競争優位	サービスの差別化や収益の中核になる	他社でも共通して必要となる
市場成熟度	適切な製品や供給者が存在しない	成熟した製品と供給市場がある
固有性	自社固有の業務や制御が多い	標準機能で要求を満たせる
変更速度と制御	自社判断で頻繁に変更する必要がある	製品の更新周期へ追随できる
継続可能性	複数人の開発・保守体制を維持でき、外部依存が事業上の重大リスクになる	社内での維持が困難で、専門ベンダーへ任せた方が安定する

Digital, Data and Technology Playbook も、内製、外注、混合型のいずれかを最初から正解とはしていません。市場の能力、社内能力、戦略的重要性、所有と制御の必要性、ロックイン、コストなどを比較し、構成要素ごとに提供方式を判断するモデルを示しています。重要なのは、内製を理念として掲げることではありません。何を、なぜ自社へ保持するのかを説明できることです。

横串の要求がガバナンスを実体化する

個別の基盤システムは、それぞれ異なる機能や技術的特性を持っています。しかし、企業システムとして求める要求には共通部分があります。可用性、性能、セキュリティ、監視、バックアップ、復旧、外部連携、監査、ライフサイクル、文書、保守体制などです。

これらをシステムごとに一から定義すると、担当組織ごとに品質基準や運用文化が分かれます。そこで、要求を全社共通、技術領域共通、製品・案件固有の三層に分けます。共通部分を横串で定義し、固有部分だけを差分として管理すれば、異なるシステムを同じ観点から評価できます。目的は全ての構成を統一することではなく、最低基準を適用し、基準から外れる理由を説明可能にすることです。

API も同じです。「API がある」という製品説明だけでは、統合可能性は判断できません。主要操作を実行できるか、状態とエラーを機械的に取得できるか、認証と権限を管理できるか、監査情報が残るか、互換性方針があるか、データを移行可能な形式で取得できるかを共通基準として評価する必要があります。

統合システムを内製する場合も、各製品の API を業務システムから直接呼び出すだけでは、製品依存が上位へ広がります。製品固有のデータ構造や状態表現はアダプターへ閉じ込め、上位では自社のサービスモデルとして扱うべきです。

文書は成果物ではなく統治手段である

内製システムでは、作った本人が内容を理解しているため、文書化が後回しになりがちです。一方、ベンダーへ設計書を納品させても、製品マニュアルの要約、設定値の羅列、テンプレートを埋めただけの文書では、知識継承には役立ちません。

重要なのは、文書の冊数やページ数ではなく、第三者が設計と判断を追跡できることです。社員側が残すべきものは、サービス要件、全体構成、設計原則、製品選定理由、責任分界、受入基準、例外判断、ライフサイクル方針です。

ベンダー側には、製品詳細設計、設定情報、試験仕様と結果、製品固有の運用・復旧手順、既知の制約を作成させます。両者を要求と試験によって結び付け、変更時に更新させます。Digital, Data and Technology Playbook も、供給者への固定化を避けるため、設計文書、システムアーキテクチャ、移行計画、リスク管理、評価結果などを最新の状態で維持し、引継ぎに利用するよう求めています。

文書化をベンダーへ任せることと、文書が満たすべき品質をベンダーへ決めさせることは別です。何を説明可能にするかは、自社が統治基準として定義する必要があります。

まとめ

内製か外注かという二分論ではありません。個別製品の実装をベンダーへ任せる場合でも、要求、判断基準、受入能力は自社へ残す必要があります。反対に、個別機能そのものが競争力の中核であり、継続的に維持できる体制があるなら、製品層を内製する選択もあります。

統治能力についても、優秀な担当者の経験へ依存させてはいけません。共通要求、複数人レビュー、意思決定記録、試験との対応付けによって、個人の能力を組織の能力へ変換する必要があります。

内製化の目的は、社員が全てを作ることではありません。市場の製品や能力を利用しながらも、会社がシステムとサービスの主導権を失わないことです。

参考情報

• The Sourcing Playbook
• The Digital, Data and Technology Playbook
• The NIST Cybersecurity Framework 2.0

関連する記事