前回、「価値を創出するプロセス」中でプロモーションについて少々書かせて頂きましたが、昨今のプロモーションでは、「企業」と言えども「個」との共生（CSRやコミュニケーション）が重要になって来ている気がします。

　...と言う事で、私は、入社当時から、開発基盤の提案（エンジニアとのコミュニケーション）というモノを延々とやって来ておりますので、あまり「？（疑問符）」は無いのですが、そもそも、（業務）アプリケーション側の開発規模が100K Stepを超えてきて、やっと、その必要性が朧気（おぼろげ）に見えてくる「開発基盤」の世界を知らない方も多く、導入（プレ）の際にどういう提案（コミュニケーション）をしているのか？などを少々、書き出してみたいと思います。

＜訴求ポイント＞

　そもそも、訴求ポイントを明確にしておかなくてはいけないですが、「知る人ぞ知る。」的なニッチな界隈への提案が多いので、あまり、訴求ポイントが明確にされていないと言う問題もあります。

　...が、某弊部会、「開発基盤部会」と言うダケあって、一応、この辺に情報を纏めてあります。また、以下のWikiにも情報を纏めています。

• 開発基盤とは - Open 棟梁 Wiki

＜ベンダ側＞

　開発基盤の導入のステークホルダーになるベンダ側となると、これはもう、所謂一つの「SI」事業者（SIer）が推進者になって来ると思います。「SES」事業者の場合は、イニシアティブに対するコミットが希薄なのでユーザと言うレベルに留まります。

• 小規模SI常連組
  　開発基盤推進を行うような「SI」事業者から見ると、20K Step以下のレンジのプロジェクトが小規模プロジェクトに該当するでしょうか？小規模SI常連組は、確かに小規模だったら素書きしてしまってもイイので、そもそも開発基盤の必要性を理解していないケースが多いです。
  
  　そのため、仮にこの手の組織が中～大規模SIにチャレンジするケースに合わせて開発基盤の必要性の説明する場合、苦労することになるんじゃないか？と思います（実際に、こう言うプレを行ったことは無いのですが、OSS化の際に開催したイベントで、そう言うクラスタ違いを感じたことがあります）。
  
  
• パッケージSI組
  　相性が悪いです。
  
  　理由は、単一の業務パッケージって、アーキテクチャの多様性が低いので、担当者が業務にフォーカスしていて、基盤（技術）にフォーカスしていないという点と、リプレースの機会も少ないので、日々の業務で必要性を感じていない。と言う辺りではないかと。
  
  　恐らく、リプレースの際も、説明が難しいモノと思われますが、リプレースの際にスクラッチ経験者がアサインされれば、状況は少々異なってくるように思います。
  
  
• 中規模SI常連組
  　中規模（100K Step前後）に差し掛かって来ると、基盤の必要性を体感しているSEが殆どになるので、細かな説明は不要なケースが多いです。このレンジが、最もスムーズに基盤の導入が可能なレンジと思います。
  
  
• 大規模SI常連組
  　大規模（500K Step以上）に差し掛かって来ると、中規模とは異なる問題が現れてきます。具体的には、大規模な顧客資産の土台になるものなので、顧客向けに必要性を説明したりする必要があります。
  
  

＜ユーザ側＞

　大規模案件における開発基盤は、大規模な顧客資産の土台になるものなので、顧客向けに（中小規模では求められない）開発基盤の必要性を説明したりする必要があります。昨今、クローズドだと絶望的なケースが多いので、オープンソースが前提になる気がします。

• 提案先
　提案先としても様々なポジションの人たちがいるので、其々に対して提案方法を変える必要があるかもしれません。


• トップ
　メリットを適切に説明できれば、トップダウンが楽だと思います。過去に、コチラの資料を使用してCIOに向けて説明したことがありますが、その際も、問題はありませんでした。ただ、事例は重視されるケースが多い気がします。


• 現場（内製）
  　開発に対する理解はあると思いますが、既存システムの保守・改修が中心となっているケースでは、大規模スクラッチ開発時のマネジメントに対する理解があまりないので、例えば、「カスタムHTMLヘルパ＋Dapper」などの軽量な基盤を求める等、選定技術についての見解にも差が出てくるケースが多い気がします。そのようなケースで、コチラの資料を作成したりしました。
  
  
• 現場（運用）
  　基本的に関心度の高いステークホルダーではありませんが、運用面に対するメリットや、影響（変更点）については、説明しておく必要があると思います。

• 抵抗勢力
　抵抗がある場合、発生源は主に、直接、声をかけて貰っていない「現場」からだと思います。主な理由としては、手持ちの基盤がある場合、以下のような変更が生じるためと思います。
1. 開発手順が変わる。
2. システム運用が変わる。
3. 基盤の開発者が抵抗する。

　...とは言え、的確にメリット・デメリットの説明を行い選定して頂ければイイのですが、「3.」に関しては、IT子会社だったりするケースがあるので、そういうケースでは争うだけ無駄と言う感もありますので、オープン化でオーナーに直接、選定して貰うのが良いと思います。