ALPHA BRANDING Corp.

CaseScenario

Column

受託開発SIの上流提案|保守接点はあるのに企画段階に入れない理由

サーバールームで保守点検を行うシステムエンジニアの画像。
宮崎祥一の顔写真

執筆者:宮崎 祥一

Honeywell、Experian、Teradata、Avanade、SAS Instituteなどで、アナリティクス領域の事業開発に従事。製造業を中心に、医薬や金融など多様な業界において、導入事例が乏しい新領域の提案も含め、案件創出から受注までを主導してきました。2023年にHoneywellのAccount Management Directorを退任。現在は株式会社アルファブランディングを通じて、DXや新領域のソリューションにおける初期提案の設計支援を行っています。

はじめに|保守接点はあるのに、企画段階には呼ばれない理由

長年取引のある顧客なのに、大きな刷新プロジェクトの話は、気づけば別の会社が進めていた……そのような経験はないでしょうか。

保守や運用を通じて、顧客とは日常的に接点があります。障害対応や追加開発の相談を通じて、社内の誰よりも顧客の業務を理解している自負もあるはずです。それでも、DXやERP刷新といった変革案件の話になると、声がかかるのは企画が固まった後、RFPが出てから、というケースが続いていないでしょうか。

この状況は、営業やSEの働きかけが足りないという話ではありません。長年の実績が、企画段階の意思決定者に届く形で伝わっていないという、伝え方の構造に起因しています。

本稿では、受託開発を主軸とするSI企業が変革案件の企画段階に入れない理由を整理したうえで、蓄積した実績を上流提案の論点に変える視点を解説します。

1. 課題と背景|受託領域の縮小と、押さえられていく企画段階

1-1. クラウド化・SaaS化で縮む受託領域

受託開発と運用保守を主軸としてきたSI企業を取り巻く環境は、ここ数年で大きく変わっています。クラウドの普及、業務システムのSaaS化、生成AIの実用化が重なり合い、これまで受託開発企業が担ってきたオンプレミスのシステム構築やカスタム開発の需要は縮小傾向にあります。顧客企業がパッケージやSaaSを直接調達する動きが広がり、「作って渡す」受託の領域は相対的に痩せてきました。

運用保守についても同様の変化が起きています。SaaS化が進むにつれて従来型の保守の形が変わりつつあり、長期契約による安定収益という前提が崩れ始めています。加えて、人材不足と労務費の上昇、人月単価の頭打ちが受託モデルの収益構造を圧迫しています。単価の低い受託案件を積み上げるビジネスモデルは持続性を問われ、多重下請け構造の中で、元請・上流工程へどう移行するかが、各社の収益性を左右するテーマになっています。

保守・運用の実績が豊富にあっても、それだけでは収益構造の転換には直結しない状況です。

1-2. 拡大する変革投資と、企画段階を握れない構造

受託領域が縮む一方で、顧客側の変革投資自体は拡大しています。DX、人的資本経営、ERP刷新、データ統合といったテーマへの投資は、業種を問わず増え続けています。ただし、これらの案件は従来のシステム開発とは性質が異なります。何を求めるかが明確でないまま検討が始まることが多く、要件が固まる前の企画段階は、外部コンサルや上流志向のSIが押さえやすい領域になっています。

企画段階で顧客と伴走する立場にいるのは、多くの場合、保守・運用を担ってきたSI企業ではなく、経営課題の言語を持つコンサルや上流SIです。受託を主軸とする企業は、企画が固まった後のRFPに応札する受け手の位置に回りやすくなります。「作る力」があっても、企画段階に関与する力が伴わなければ、変革投資の拡大は自社の受注機会として現れません。

保守・運用で顧客と日常的に接していること自体は、企画段階への入り口を保証しないのです。

2. 課題の構造|実績はあるのに、経営論点に翻訳されていない

2-1. 実績はあるのに「技術タグ」でしか語られていない

企画段階に届かない一因は、保有する実績の整理の仕方にあります。長年の構築・保守を通じて、SI企業は顧客の業務実態に関する深い知見を蓄積しています。しかしその実績は、「特定のパッケージに詳しい」「〇〇システムを構築した」という製品・技術の看板でしか語られず、顧客の経営テーマに翻訳されないまま管理されているケースが少なくありません。実績を製品単位・案件単位で整理する限り、これは特定の企業や担当者に限った問題ではなく、構造として起きます。

以前、外資系アナリティクスベンダーに勤めていた頃、米国本社のトップ営業から提案書を共有してもらったことがあります。私は製品の機能や導入事例をまとめた資料を想像していました。しかし、送られてきたのは、顧客のIR情報をもとに経営課題を整理し、その課題に対して自社の解決策をどう位置付けるかを一つのストーリーとしてまとめたWord文書でした。そこでは製品は主役ではなく、経営課題を実現するための手段として位置付けられていました。私はそのとき初めて、「実績や機能を説明すること」と「経営課題から逆算して提案を組み立てること」は、まったく別の発想なのだと気づきました。

実績や機能をどれだけ持っていても、経営課題に変換する型がなければ、企画段階の意思決定者には届きません。

2-2. 企画段階の意思決定者と、保守接点の担当者のズレ

実績が経営論点に翻訳されていない状態は、もう一つのズレとも重なります。受託開発SI企業の顧客接点は、保守・運用を担当するIT部門に集中していることがほとんどです。対して、DXや人的資本経営、ERP刷新といった変革テーマの意思決定は、業務側の部門や経営企画、経営層が担っています。

保守・運用の定例や追加開発の相談は、障害対応や機能追加の見積もりに終始しやすく、経営テーマの話には発展しません。原因は担当者の意欲ではなく、経営テーマとして持ち込める論点素材が手元にないことにあります。IT部門の担当者との関係が良好であっても、その関係の延長線上に、業務側や経営層との接点が自動的に生まれるわけではありません。

企画段階の意思決定者と、日常的に接しているIT部門の担当者は、そもそも見ている評価軸が異なります。IT部門は運用の安定や機能の過不足を見ますが、企画段階の意思決定者は、投資額に見合う経営上の効果を見ています。この評価軸の違いを踏まえずに実績を持ち込んでも、企画段階の検討材料としては受け取られにくいのです。

3. 解決策|実績の棚卸しと、経営ゴールからの逆算

3-1. 実績を経営論点の単位で棚卸しする

実績を企画段階の論点に変えるための最初の作業は、実績の棚卸しの単位を変えることです。「製品」や「案件」の単位で実績を並べるのではなく、その実績が顧客のどのような経営課題に接続できるかという単位で整理し直します。

同じく以前、外資系品質管理ベンダーで製造業向けの提案を担当していたときの経験です。金融・医薬向けの事例は豊富にあった一方、製造業向けの事例はほとんどありませんでした。他業界の事例をそのまま紹介しても、業種が異なるというだけで顧客の反応は鈍いものでした。

転機になったのは、IR情報をもとに「製造業が導入する場合のシナリオ」として事例を作り直したことです。医薬業界特有の規制要件や、過剰スペックにあたる機能の記述を削り、バリデーションや監査証跡といった業界用語を、検証や変更履歴といった製造業の言葉に置き換えました。企業名を伏せた事例をそのまま横流しするのではなく、業界・経営論点に合わせて実績そのものを組み替えたことで、顧客は自分たちの話として提案を検討し始めました。実績の中身を変えるのではなく、経営論点の単位で編み直すという作業です。

3-2. 経営ゴールから逆算して、実績の使いどころを定める

棚卸しした実績のどれを、どの顧客のどのタイミングで差し出すかは、業務課題からではなく、顧客の経営ゴールから逆算して定めます。IR・中期経営計画・統合報告書といった情報から、顧客が到達しようとしている方向性を読み取り、そこから逆算して、自社のどの実績が経営論点として使えるかを絞り込みます。

業務課題を起点に実績を選ぶと、競合他社も同じ保守・運用の接点から同じ業務課題を把握しているため、提案の論点は似通いやすくなります。経営ゴールを起点にすることで、他社が容易には把握できない切り口から、実績を企画段階の論点として差し出せるようになります。たとえば同じ「基幹システムの保守実績」であっても、顧客が人的資本経営の情報開示を経営ゴールに掲げているのか、グローバル展開の効率化を掲げているのかによって、経営論点としての使いどころは変わります。

棚卸しと逆算は、どちらか一方では機能しません。実績を経営論点の単位で整理することと、経営ゴールから逆算してその使いどころを定めることを、あわせて行って初めて、企画段階で差し出せる論点になります。

【次に読むべきコラム】
👉️ PoCが本番導入につながらない理由|営業が初期提案で変えるべき設計とは
👉️ DX提案が承認されない本当の理由|経営と現場の断絶をどう設計で埋めるか
👉️ 業務課題と経営課題の違い|DX提案が承認されない「翻訳ミス」3つの構造

まとめ|実績の語り方を変えることから

保守・運用の接点は、これまでの実績の証です。それ自体は失われていません。変わるべきは、その実績をどう語るかという部分だけです。

まずは、直近で担当した案件の実績を一つ選び、それが顧客のどのような経営課題に接続できそうか、書き出すところから始めてみてください。すべての実績を一度に整理し直す必要はありません。一件ずつ経営論点の言葉に置き換えていくところから、企画段階に届く提案は少しずつ形になっていきます。

【参考】CaseScenario™なら

ここまで述べてきた実績の棚卸しと経営ゴールからの逆算は、担当者一人が継続的に行うには負荷の大きい作業です。CaseScenario™は、顧客のIR・中期経営計画から経営ゴールを逆算し、現場の実績を経営層が判断できる経営課題へ翻訳することで、案件化・検討開始・承認前進に必要な判断材料を初期提案の設計図として整えるサービスです。

受託開発型のSI企業は、案件の多くが守秘義務の対象となり、企業名を出せる事例が乏しいという制約も抱えています。CaseScenario™が設計するのは企業名を伴う事例ではなく、業務実態を翻訳した経営論点です。「同業界で、このような経営課題に接続された実績がある」という形に変換できれば、事例を公開できないことは、上流提案の入口を閉じる理由にはなりません。

👉 CaseScenario™の紹介ページはこちら

ライブラリ

BtoB提案シリーズ

導入事例の制作を依頼する前に知っておくべきことを解説するコラムのバナー。営業が使わない事例になる理由と、担当者止まりを防ぐ設計の考え方を紹介。導入事例の制作を依頼する前に知っておくべきことを解説するコラムのバナー。営業が使わない事例になる理由と、担当者止まりを防ぐ設計の考え方を紹介。
「提案停滞」の文字と、足跡のシルエット図「承認停滞」の文字と、ビジネスパーソン3人のシルエット図「伝達不全」の文字と、4人の人物がネットワークで繋がっているシルエット図「PoC停滞」の文字と、進入禁止のテープのシルエット図「事例依存」の文字と、3つのバインダーのシルエット図「営業実務」の文字と、ジグソーパズルの3つのピースのシルエット図