昨今、「オファリング・ビジネス」 という言葉が、SI事業者界隈で、聞かれるようになりました。これは、お客様個別の要望に応える「受託開発」ではなく、自社のサービスをお客様に提案（オファリング）することでビジネスを生みだすことを意味する言葉です。
クラウド・サービスの充実や生成AIの機能向上で、工数需要に伸び代はなくなりつつあります。また、これらツールの充実は、ユーザー企業の内製化を拡大させていくでしょう。また、変化が速く予測できない社会に対処するには、システムの開発や改修のスピードを加速しなければなりません。外注に依存する従来のやり方では、これに対処できないことは明白で、これが内製拡大の機運を高めています。
また、慢性的な「エンジニア不足」は、工数の確保を難しくしており、これまでと同じやり方で収益の拡大を目指すことは、できません。このような、事業環境の変化に対処するために、「オファリング・ビジネス」へと舵を切らざるを得ない状況が、生まれているわけです。
日経コンピューターの2024年2月8日で、「オファリング・ビジネスの正体」という特集が掲載されました。この中で、各社のオファリング・ビジネスの共通点を3つあげています。
ひとつは、「システム化領域の拡大」です。顧客が解決したい課題が、自社個別の課題から、
脱炭素や高齢化への対応など、企業の枠を越えた社会課題へと拡がってきたことです。そのため、「課題はあるが、対処の仕方が分からない」、つまり、「ユーザー企業の要求が定義できず、仕様が決められない」事態となっているわけです。この状況では、従来の「受託開発」では対処できません。
ふたつ目は、「開発の変革」です。お客様の要望に応えての個別開発では、お客様が望む工数の確保、コストの低減、短納期での開発が困難な状況にあります。そこで、SI事業者が持つ既存のアセットを使ってこの問題を解決しようというわけです。
3つ目は、「ビジネスの変革」です。上記「開発の変革」に伴い、一時的な売上計上から、継続課金へと変えることも必要になります。
このような取り組みについての詳細や事例は、本記事をご覧頂ければと思いますが、私なりの視点で、その死角と課題を捉え直してみたいと思います。
そもそも、「オファリング・ビジネス」という言葉が、使われる以前から、同様の課題は指摘されていましたし、このブログでも再三にわたって述べてきました。それでも、このような取り組みが、なかなか成果をあげられなかったのは、「本気になれなかったから」ということに尽きるでしょう。
受託開発の需要はコンスタントにあり、収益を確保できていました。もちろん、それだけではダメだからということで、独自サービスを開発し、提供する試みが行われては来ましたが、なかなか成果に結びつきません。その理由として、受託開発の要になっているようなエースを引き抜き投入することはなく、投資も逐次的でした。「新しいサービスで受託開発を置き換える！」という確固たる覚悟を待たないままに、だらだらと取り組み、需要がないからと自然消滅するケースもいくつも目にしています。需要がないのではなく、需要を生みだす努力をしてこなかったのです。
特に、この「需要を生みだす」ことについては、SI事業者の多くは、大変に消極的でした。
「セールスには熱心に取り組むけれど、マーケティングには不熱心」
そんな常識が染みついていたように思います。
そもそもセールスやマーケティングの役割が未分化な企業も多く、セールスもまた、オポチュニティの開拓とカスタマーサクセスが未分化であり、極めて効率の悪いやり方が続いてきました。
このような状況が続いてきたのは、「必要がなかったから」です。ユーザー企業の情報システム部門を窓口に、継続的な受託案件を確保できたからで、新しい市場を生みだし、それを拡げるマーケティングは必要とされませんでした。
また、限られたお客様の窓口と人間的関係をしっかり作っておくことが、案件確保の絶対条件であり、システマティックなセールスの機能分化の必要はありませんでした。効率は良くないけれど確実に数字が取れることが優先されたわけです。
しかし、システム需要の窓口は、もはや情報システム部門だけではなくなりました。事業部門が主導する内製チームの拡大、開発せずに使えるクラウドサービスの充実、社会課題への対応の要請などにより、既存のセールス・チャネルに頼ったやり方の限界が露わになってきました。
結果として、マーケティング機能を拡充し、セールスの効率を上げなければならない状況に直面したわけです。オファリング・ビジネスもまた、このような事業環境の変化と揆を一にした動きであるといえます。
先の「日経コンピューター」の示したオファリング・ビジネスの3つの共通点に加え、マーケティングやセールスのあり方も含めて、従来のSIビジネスを再定義するか、あるいは、それとは異なるビジネス・プロセスを新しく作る覚悟なくして、オファリング・ビジネスを成功に導くことは難しいでしょう。
また、先の3つの共通点についても、既存のSI文化の常識を上書きすることが必要です。
「システム化領域の拡大」では、「ユーザー企業の要求が定義できず、仕様が決められない」という現実に対処しなければなりません。そのためには、「提言」を起点とする営業スタイルへの転換です。
お客様の課題を聞き出し、その解決策を提案する「ソリューション営業」は通用しません。営業が、お客様のビジネス環境や課題をお客様以上に深く考察し、お客様の課題や取り組むべくテーマを教えてあげる必要があります。これを「コンサルティング営業」と呼ぶ場合もあるようですが、課題解決の筋道を提供するコンサルティング以前の段階です。何を解決すべきかを教える役割から始めなくてはなりません。私は、これを「提言営業」と呼んでいます。
わかりやすく言えば、お客様の先生あるいは教師になることです。営業は、そのための教養とコミュニケーション能力を磨く必要があるでしょう。
ふたつ目の「開発の変革」は、既存アセットを再利用して組み合わせるビジネスの必要性が語られています。このやり方を否定するつもりはありませんが、このやり方を活かすためにもアジャイル開発やDevOpsへのシフトを進めなくてはなりません。
アジャイル開発とは、「高品質で、無駄なく変更要求に即応できるソフトウェアの実現」です。「高品質」とは、リリースしたコードにバクがないこと、「無駄なく」とは、売上や利益に貢献するコードだけを開発し、できるだけ作らないようにすること。「変更要求に即応できる」とは、仕様凍結せずに、ビジネス環境の変化に迅速柔軟に仕様を変え、開発プロセスの優先順位を変更することで、ビジネス環境の変化に同期してシステムを開発することです。
また、そもそも、初期段階で「要件が定義できない」ことも多く、ならば、要件定義無しでシステムを開発することもできなくてはなりません。
アジャイル開発というのは、このような要件を見たす開発の考え方と手法です。
DevOpsはアジャイル開発のスピードとシステム運用のスピードを同期させるための取り組みです。簡単に述べれば、「開発したら即本番、それでも安定稼働を保証する開発や運用の仕組み作り」と言うことになるでしょう。
つまり、「開発の変革」において、既存のアセットを使うことは有効な手段のひとつですが、それが唯一ではありません。テーマを確定すれば、それを直ちに開発し、ユーザーの検証をうけ、現場のフィードバックをうけながら、高速な改善で正解を探すことが必要なわけです。そのためにアジャイル開発やDevOpsがあり、その手段として、既存アセット、マイクロサービス、オープンソース、クラウド・サービスなどを組み合わせ、活用していくことが必要なります。
既存のアセットだけでは限界があります。また、既存アセットありきでの発想に陥ってしまうと、きめ細かなユーザーニーズへの対応や変化への俊敏性を失います。ただ、既存アセットを前提にすれば、開発原価の削減やスピードを上げられることはわかります。ならば、新たな開発も、低い原価（できるだけ作らない）と圧倒的なスピードを生みだす他の手段を積極的に組み合わせていくことで、柔軟迅速に変化を受け止める能力を確保する必要があるでしょう。
3つめの「ビジネスの変革」で大切な点は、営業や事業部門の業績評価の方法を変えることです。かつてSI事業者の業績評価は、「売上が増えれば利益がついてくる」という前提に立ち、業績評価の基準をわかりやすい「売上」のみにしている企業が大半でした。しかし、売上は上がるが利益が出ない案件が増えてきたことから、「売上と利益」あるいは「利益のみ」を業績評価基準にする会社も増えてきました。
しかし、リカレントが増えれば、一時的な売上や利益の金額は、大きく減少します。そうなると、旧来のままでの業績評価基準では、現場のモチベーションは上がりません。富士通は、この問題を解決する手段として、営業担当者に自社サービスUvanceの売上計上に金銭的インセンティブを与えることで、このビジネスを促進しようとしています。また、あるSI事業者では、リカレントなビジネスは、解約リスクが少ないので、売上と利益を3年分一括して受注時に業績として計上するところもあります。また、経常利益を業績評価基準にしている企業では、サービスの初期投資分を本社勘定として計上し、営業は原価無しで利益を計上できるようにしているところもあります。
どのようなやり方がいいかについては、企業の文化に関わることでもあり、一概に言い切れません。ただ、受託開発が当たり前の時代に作られた業績評価基準を前提にせず、オファリング・ビジネスの現実に即したやり方を新しく創ってゆかなければならないことだけは、はっきりしているように思います。
既存の受託開発の延長線上に、事業の未来がないことが明らかとなったいま、新しいビジネスの仕組みを作っていく必要があることは、言うまでもありません。また、そのひとつのカタチが、「オファリング・ビジネス」なるものかも知れません。
しかし、「オファリング・ビジネス」が、唯一の解決策ではありません。個人的な感想を申し上げれば、「いまさら感」を拭えません。こんな時代になることは、かなり前から十分に想定できていたわけで、この期に及んで大騒ぎしているようにも見えます。
お客様のDXの支援を叫ぶのもいいのですが、まずは、自分たちの変革の道筋を描いてはどうでしょう。その手段としての「オファリング・ビジネス」を否定するものではありませんが、もっと本質的な変革に目を向けるべきでしょう。
自社のパーパスを問い直し、自社の使命とあるべき姿を再定義して、既存の延長ではないビジネスのあり方を模索すべきでしょう。そこに踏み込まずして、お客様の変革を支援しようなどとは、都合が良すぎるように聞こえてしまうのは、私のへそが曲がっているからだと思います。
神社の杜のワーキング・プレイス 8MATO
