「大企業向けエンタープライズ市場は飽和状態だが、中小企業向けはまだまだ開拓の余地がある。」という台詞は、私がこの業界に入った20年も前からずっと語られてきました。ベンチャー企業である当社はもちろん、中小企業向け市場の開拓に熱い視線を注いでいます。しかし、チャレンジすればするほど、なぜこの市場開拓が難しいのかを実感しています。
はじめに、私がよく耳にする市場戦略の多くが誤解であった、という体験を紹介したいと思います。
大企業向けのERPパッケージの機能を削ったものを中小企業向けに展開する
中小企業向けといって削れる機能の実体は、一部の特殊な機能でしかありません。業務の本質的な機能は削れるわけもなく、またセキュリティを含む多くの非機能要件も企業の規模を問わず必要です。さらに業務機能は変わらないどころか、むしろ中小企業の方が複雑、といったことも珍しくありません。異なるのは扱うデータ量くらいではないでしょうか。
大企業の方が機能や操作性へのこだわりが強く、中小企業はシンプルでよい
企業規模の大小を問わず、こだわりは日本企業の文化であり、大差ありません。こだわる部分ほど自社独自の業務の核心でもあるため、他社類似システムと異なる「一品もの」の設計が求められます。この実現には現場担当者の協力も必要ですし、何度も設計を繰り返し、レビューを重ねていくための時間もかかります。つまり作り手にとってみれば手間をかけるだけ良いものに仕上げられる反面、開発費が増大するのは当然なのですが、「中小企業が求めるものは大企業と変わらないが、予算規模は大きく異なる」というジレンマがあります。
もう一つ注目すべきは、中小企業はシステムを利用するエンドユーザ部門の発言力が突出して強い傾向がある、というものです。社長が調整役になるといった言質をとったとしても、現場の強い声には叶わず、結果として当初予定していた開発工数を大幅に超過するような細かい修正が、それも納期直前に噴出することも珍しくありません。これらの要求は思いつきで出されることも少なくないため、開発サイドがこれらの要求に振り回され、徹夜続きで何とか対応したとしても、運用に入ってみると実は不要であったので使われなかった、というオチがつくこともありました。
ある中小企業向けの基幹システムを構築したので、同規模の会社に横展開で販売する
実際には横展開の案件の都度、多大なカスタマイズが発生します。営業としては「中小企業向け専用に開発したので御社でも（カスタマイズなしで）使えます（使えるはずです）」というアピールをしたいところですが、そう単純ではありません。無理に契約してしまうと、あとからあとから出現するカスタマイズ要件を目の当たりにして、価格交渉という精神戦に突入するか、あるいは当初見積予算を超えた分を赤字として引き取るかという判断を迫られることになるのは自明です。
クラウド型にすれば（価格が安いので）成功する
クラウド型で成功するのは、カスタマイズが発生しないテーマのみ、と考えています。法律によって業務要件が固まっている会計システムや、グループウェアなどがすぐに思いつきますが、これらは元々、クラウド型でなかった時代でも成功する（ノンカスタマイズで横展開がしやすい）テーマでした。つまりこれまで述べた「個々に発生するカスタマイズをどう収束させるか」という課題と、クラウド型ビジネスモデルは無関係です。
矛盾を解消するビジネスモデルを見出せるか
中小企業向け市場というのは確かに広大に存在するのですが、一つ一つの案件だけをみれば赤字になりやすく、かといって一つの「業務テンプレート」を使い回す単純なビジネスモデルは成立しないという矛盾を抱えているのです。
この市場に参入し、成功するためには、この矛盾を解消する新しいビジネスモデルを見出す必要があります。続いて私が現時点で可能性があると考える、二つのアプローチを紹介します。
ITコーディネーターをはじめとするコンサルタントの活躍の場を拡げる
ITコーディネータの役割といえば、業務の要求分析や上流工程に関わることを思い浮かべる人が多いでしょう。しかし私が重視しているのは「開発予算つまりリソースは有限であることを関係者全員に納得してもらい、何を得て、何を諦めてもらうかを中立の立場で真摯に調整する」役割です。これを発注側のIT部門が行ってしまうと、組織内のエンドユーザ部門から「我が社のIT部門はベンダーのいいなりだ」と侮蔑されてしまうことになります。かといって開発側のSIerのプロジェクトマネージャが行うのも難しく、多くの場合は押し切られます。この役割を担えるのは第三者的なコンサルタントをおいて他にありません。
しかし現実には、このような立場で活躍できる方は少ないようです。その理由は、調整役はどこからも不満を受けるので、辛い仕事になるからでしょう。発注側の社長が、そのような立場にたつコンサルタントを支持する立場を表明し、その苦労に見合う報酬で契約することが求められますが、特に中小企業案件ではコンサルタントとは大企業が採用するものであり、上流設計は自分達ができると（発注側も、開発側も）考えている節があります。コンサルタントを上流設計のアドバイザーとしてではなく、プロジェクトを円滑に推進するための調整役（そして理論武装役）として入っていただくというスタイルが普及すれば、プロジェクトの成功率は上がるのではないでしょうか。もちろんコンサルタント側にも、自らが調整役として泥をかぶるという覚悟が求められます。そういう経験のない私がいうのもおこがましいのですが、そのような役回りが存在しないプロジェクトでは調整が難航することもまた、実感しています。
仕様変更を前提とする開発体制を最初から用意する
中小企業向け案件こそ仕様が膨らみやすく、またカットオーバー直前の仕様変更もありうる、という前提に立って、そのような環境下でもデスマーチにせず、かつ品質と納期を遵守して黒字も出すような開発体制を目指す、というのは一見、理想です。しかしこの実現には、これまでの開発スタイルの延長では不可能である、という視点を持つ勇気が求められる、と考えています。
これまでの延長策として私が見聞するのは、「より使い勝手のよい（無理を引き受ける）オフショア、ニアショアを探す」ことや「プロジェクトマネージャを強化する」または「契約方法を変える」などです。しかし私は、この手法では中小企業向け案件に対応するのは難しいと考えています。
当社が実践しているのは、超高速開発ツールの活用です。その基本路線は「できるだけプログラムを書かず、仕様書からプログラムを生成するようにすることで、仕様変更のインパクトをツールに吸収させる」というものです。これによる変更要求への対応スピードは段違いで、顧客先への納品時に変更を要望され、その場で修正して目の前で確認したということも一回や二回ではありません。この瞬間に顧客満足度が一気に高まるということを肌で実感できます。
その代わり、ツールがサポートしていない要求は「原則として、やらない」ことを提案します。その上で、どうしてもやってほしいというテーマのみを厳選してカスタマイズとして実現します。これによって不要不急の機能を削減すると同時に、カスタマイズ開発の工数を圧縮します。これは端的にいえば、手を動かす範囲を狭めることになるため、目先の売上は減少します。もう一点、そこで残ったテーマはおおむね「実装の難易度が高い」ものが多く、高い開発スキルが要求されることになります。
結論
コンサルタントの活躍を場を拡げる案は、従来型開発手法の延長で顧客（発注側）と関係を継続できるものです。しかし、ネックは人件費の負担にあることはいうまでもありません。自治体や政府の補助金活用というスキームもありますが、これも賛否が分かれるでしょう。
超高速開発ツールの活用にもメリットと、デメリットがあります。顧客満足度は高まりますが、これまでのSIerのビジネスモデルの根本である「稼働による売上」が変わってきます。しかし多くのパートナーと一緒にこのビジネスモデルを推進してきた経験から、少数精鋭の開発チームと、ツールの組み合わせによる開発が今後の基本スタイルになる可能性は十分にある、と個人的には考えています。
