すべてを自社でつくらなくても、ITの主導権は自社に持てる。
システム内製化というと、エンジニアを採用し、自社でシステムを開発することをイメージしがちです。
しかし、すべてを自社で抱える必要はありません。
大切なのは、
何を自社で判断するのか。
何をベンダーに任せるのか。
その境界を、自社で決められること。
オーシャン・アンド・パートナーズは、ベンダーの力を活かしながら、自社でITを判断し、動かせる体制づくりを支援します。
こんな状況ではありませんか？
- ベンダー任せになっていて、システムの中身がよく分からない
- ベンダーからの提案や見積が妥当なのか判断できない
- 情報システム部門が少人数で、日々の対応だけで手いっぱい
- 担当者が異動・退職すると、システムのことが分からなくなる
- 内製化したいが、エンジニアを何人も採用するのは現実的ではない
- ベンダーを変更したいわけではないが、依存状態からは抜け出したい
こうした問題に対して、「自社で全部開発できるようになること」が答えとは限りません。
必要なのは、ITに関する知識と判断が、自社に残る仕組みをつくることです。
内製化するのは、「開発」だけではありません
開発を誰が行うか。
これは、内製化を考えるうえで一つの論点にすぎません。
たとえば、
- 何にIT投資するのか
- どんな業務に変えるのか
- 何をシステム化するのか
- どの製品を選ぶのか
- ベンダーへ何を任せるのか
- 提案や見積をどう評価するのか
- 何を変更し、何を変更しないのか
これらをすべて外部に任せたまま、開発だけ自社で行っても、本当の意味で主導権を持ったとは言えません。
逆に、開発をベンダーへ任せていても、
自社で方向を決め、選択肢を比較し、意思決定できる。
それなら、ITの主導権は自社にあります。
私たちは、これを「現実的な内製化」と考えています。
「自社で持つもの」と「外に任せるもの」を決める
すべてを内製化する必要はありません。
むしろ重要なのは、自社に残すべき能力と、外部の専門家を活用すべき領域を切り分けることです。
自社に残したいもの
- IT戦略と投資判断
- 業務・要求の整理
- システム全体像の把握
- 優先順位の判断
- ベンダー・製品の評価
- プロジェクトの意思決定
- システムや業務に関する知識
外部を活用できるもの
- 専門技術
- システム開発
- インフラ構築
- 製品固有の知識
- 一時的に必要となる専門人材
- 保守・運用の一部
「何でも自社」でも、「何でもベンダー」でもない。
会社の規模、体制、事業特性に合わせて、適切な境界を設計します。
内製化支援でつくる4つの力
01｜分かる
まず、現在のシステムと運営状況を把握できる状態にします。
システム構成、ドキュメント、契約、ベンダーの役割、運用方法などを整理し、「誰かに聞かなければ分からない」状態を減らします。
02｜決められる
要件、投資、製品、ベンダー、変更内容などについて、自社で判断するための基準をつくります。
ベンダーからの提案を「受ける」だけではなく、その妥当性を評価できる状態を目指します。
03｜動かせる
社内とベンダーの役割を明確にし、課題管理、会議、意思決定など、プロジェクトやシステム運営を自社主導で進める仕組みをつくります。
04｜残せる
判断の経緯、業務知識、システム構成、運営ルールなどを、特定の担当者やベンダーだけに閉じない形で残します。
担当者が変わっても、会社としてITを運営できる状態を目指します。
ベンダーを変えることが目的ではありません
長年システムを支えてきたベンダーには、技術や業務について蓄積された知識があります。
それを捨てて、すべて自社でやり直すことが内製化ではありません。
むしろ、
企業は、事業と業務を知っている。
ベンダーは、技術と実装を知っている。
それぞれの強みを活かす方が合理的です。
問題なのは、企業側が判断できないほど依存してしまうことです。
ベンダーを管理するのではなく、自社が方向を決め、ベンダーの専門性を活かす。
その関係をつくります。
支援の進め方
STEP 1｜現状を見えるようにする
システム構成、ドキュメント、運営体制、契約、ベンダーとの役割分担などを確認します。
「誰が何を知り、誰が何を決めているのか」まで整理します。
↓
STEP 2｜自社に残すものを決める
すべてを内製化するのではなく、どの判断・知識・業務を自社に持つべきかを整理します。
逆に、外部へ任せた方がよい領域も明確にします。
↓
STEP 3｜運営の仕組みをつくる
ドキュメント、会議、課題管理、要求整理、ベンダーとの役割分担など、日常的にITを動かす仕組みを整えます。
↓
STEP 4｜実際のプロジェクトで一緒に動かす
必要に応じて、構想策定、RFP、ベンダー選定、要件定義、PMOなど、実際のプロジェクトに一緒に入りながら進めます。
↓
STEP 5｜自社で回せる範囲を広げる
最初からすべてを自社で行う必要はありません。
自社で判断・推進できる領域を段階的に増やし、外部支援への依存を減らしていきます。
ゴールは、「私たちがいなくても回ること」
内製化支援で、私たちがずっと企業の代わりに判断し続けるのであれば、それは依存先が変わっただけです。
目指すのは、
- システムの全体像を自社で把握できる
- ベンダーの提案を評価できる
- 要求と優先順位を自社で決められる
- 必要な情報や判断の経緯が社内に残る
- ベンダーと適切に役割分担できる
- ITプロジェクトを自社主導で進められる
という状態です。
外部の専門家を使いながら、自分たちで判断できる。
そこまでを内製化と考えます。
必要なところから支援できます
内製化は、大きなプロジェクトとして始める必要はありません。
IT運営を見えるようにしたい
システム構成、ドキュメント、契約、役割分担などを整理します。
ベンダーとの関係を見直したい
要求整理、見積・提案の評価、役割分担、会議体などを整理します。
情報システム部門を強化したい
日常的な相談、課題整理、意思決定支援を通じて、少人数の情報システム部門を支援します。
実際のプロジェクトを通じて力をつけたい
構想策定、RFP、ベンダー選定、要件定義、PMOなどに一緒に入り、実務を通じて自社で担える領域を広げます。
他の支援と組み合わせることもできます
内製化は、単独で進めるだけではありません。
システム構想策定支援
システム刷新などの機会を利用して、「何を自社で判断するのか」から体制をつくります。
RFP作成・ベンダー選定支援
RFPやベンダー選定を一緒に進めながら、要求整理やベンダー評価の方法を自社に残します。
基幹システム再構築支援
大規模な刷新プロジェクトを通じて、構想からプロジェクト推進まで発注側の能力を強化します。
よくあるご質問
できます。開発そのものではなく、まず要求整理や意思決定、ベンダーマネジメントなどを自社で担える状態からつくります。
ありません。現在のベンダーとの関係を活かしながら、企業側の役割を強化する進め方が可能です。
少人数だからこそ、何を自社で持ち、何を外部へ任せるかを明確にすることが重要です。現在の体制に合わせて支援範囲を設計します。
必須ではありません。開発まで内製化することが合理的な場合もあれば、専門の開発会社を活用した方がよい場合もあります。
可能です。現在のシステム運営やベンダーとの役割分担を整理するところから始められます。
ITを全部つくれる会社ではなく、ITを自分たちで動かせる会社へ。
必要な技術は、外部から借りることができます。
必要な開発も、専門会社へ任せることができます。
しかし、
何を変えるのか。
何に投資するのか。
誰に何を任せるのか。
その判断まで外に出してしまうと、ITの主導権は自社に残りません。
すべてを自社でつくらなくてもいい。
自分たちで決め、自分たちで動かせる。
そんなIT運営への移行を支援します。