開発基盤部会 Blog

開発基盤部会 Blog >> 記事詳細

2020/03/16

セグメンテーション(マーケティング)のプラクティスをしてみた。

Tweet ThisSend to Facebook | by nishino
 前々回の「KPIの設定ミスってる問題」、前回の「現状ニーズと将来トレンドの不一致問題」の惨状を、もう少し、掘り下げてみようと考えていたら、

 「顧客(顧客事業)/ 事業(自社事業) / 技術は、セグメンテーションされたターゲットを中心に二人三脚してんだな。

 と閃いたので、早速、セグメンテーションのプラクティスをしてみようと思い、以下に色々と書き出してみました。

 この結果、

  • 事業セグメント
  • 技術セグメント
  • 顧客セグメント
※ 私は顧客が良く解っていないので最後に。

 を洗い出して分析するとワリと見えてくる気がしました(TwitterのTLに出てくるエンジニアのTweetの背景を、ほぼ、このセグメンテーションで説明できるレベル)。

 また、本質的に、顧客(顧客事業)/ 事業(自社事業)を問わず、事業に、技術は(、テクノロジに限らず)、必要です。

  • 事業から見た場合、収益性の高い事業は、高度な技術を必要とする。
  • 技術から見た場合、いくら高度でも、技術単体ではマネタイズ困難なので、収益性の高い事業に対して貢献度を増やしていく必要がある。

 ...と思います。

 一方で、「技術(ここでは ≒ テクノロジ)は必要無い。」と言っている事業は、大概、事業としては斜陽ないしは成長する気が無い。...と言うことで、そういう事業ばかりの企業は、

  • 技術そのものをやるのではなく、先ずは、事業企画を頑張った方が良い。
  • ただ、ゲーム業界で、企画と、開発・運営が切り離されているように、アウトソーシングは進むかも知れない。
    • サプライヤーを必要としない "自前主義" (≒ 私のよく言うサプライサイド都合)が、昨今、問題となって来た。
    • 垂直統合は、「購買代理業者 - パッケージャ - 要素提供者」に割れるが、一般的には、「購買代理業者 - パッケージャ」のラインで割れると思われる。
    • 結局、垂直統合を分割する話になるが、今の所、社内に、2つのパーツを上手く同居させることが出来るのか?は、不明ではある。

 ...と言う状態のように思います。



 以下、洗い出した項目と分析の結果。

<事業的セグメンテーション>

  • 派遣、SES
  • 受託開発
    • QCDの面の責任感は有るが、
      従来型では「球数・単価」共に斜陽。
    • 高度なSaaS開発が可能なベンダ
      などが市場から要求される可能性はある。
  • SIテンプレ
    • クォリティ的にオワコン。
    • パッケージ や SaaSに押されて死ぬフェーズ
    • 唯一、ニッチ系に活路を見い出せる。
  • ビッグ・アカウント
    • 古くからあり、収益性も高め。
    • 受託が減るため、上流シフト一択。
    • オーガナイザー的な役割を果たす。
  • 要素技術開発
    • 先行者利益はある。
    • しかし、最終的にコモディティ化の勝者総取り。
  • ソリューション開発
    • 要素系を特定分野に向けるタメ、
      ゴーイング・コンサーンし易い。
    • 例えば、下位スタックを切り替えながら進む、
      ビッグデータ・ソリューションなど。
    • しかし、SaaS登場により安泰ではなくなった感。
  • パッケージ、SaaS
    • 実力(謎)が無いと出来ない。
    • ラストマン戦略なのか、資金調達力なのか。

<技術的セグメンテーション>


<ツール的セグメンテーション>

  • IDE、SDK
    • デファクト・スタンダード
    • ただし、差別化困難
      (事業側の優位性が重要)
  • RAD系
    • 案外、ニーズが無い。
    • IDEとEUCの狭間で中途半端。
    • Visual Studioの方が強力なケースも
  • EUC系
    • ツールを利用した開発自体は
      当然、EUCなので金にならない。
    • RPAは本当にEUCなのか?という話もある。
      (専門部隊中心のソリューションという見方)

<分野的セグメンテーション>

  • 要素技術開発
    • ビッグデータ、AI、IoT。
    • 基本はスタック。営業はコラボレーション。
  • ソリューション開発
    • ビッグデータ、AI、IoTなど要素技術の応用から、
      スマホ、クラウド、認証など様々なスキルが要求される。
    • ツールは、基本的にIDE、SDK。
      RADやEUCとは繋がるように設計・実装。
  • パッケージ、SaaS
    • 業務知識に加えて、
      要素技術からソリューションまで。
    • ツールは、基本的にIDE、SDK。
      RADやEUCツールを自作することも。

<顧客的セグメンテーション>


  • 汎用基幹系
    • SoR / SoE問わず、基本、パッケージ、SaaSに切り替る。
    • パッケージ、SaaSのアドオン開発ツールを使用する。
    • しかし、スクラッチに限らず、アドオンも保守が難しくなっていく。
  • 事業系
    ニッチ系なので基本スクラッチだが、パッケージ、SaaSの
    利用率は、徐々に、上がっていくものと思われる。
    • SoR
      • 従来型のスクラッチが残る部分。
      • 従来型のSIテンプレは、
        ニッチ戦略に活路を見出す。
    • SoE
      • 新型のスクラッチ開発。
      • クラウド、スマホ、SPAなどの重要性が高まる。
        • クラウド、ネイティブの一般的な知識
        • JavaScript、npm系のエコシステム
        • Open PaaS(Docker)系のエコシステム
    • DX系
      • コチラが参考になる。
      • 以下の技術の重要性が増す。
        • クラウド、スマホ、SPAなど
        • IoT、ビッグデータ、AI
        • コンポーザブル、ポータブル



<参考>


09:00 | 投票する | 投票数(0) | コメント(0) | ご報告