最近の大企業の営業の方は、自社既存顧客の窓口紹介で口銭稼ぐパタンが多いですねぇ（以前からそうでしたが、拍車がかかっていますね）。
話を聞いてみると、減点主義で、新規開拓などはとてもやりにくい環境だそうです。
そんなので大丈夫でしょうか・・・（シュリンクする一方なので、ダメですよね、普通）。
うーむ。
違和感
敗退したチームに、去年のメンバがどのくらい残っているのかはさておき、原則として高校野球メンバは毎年入れ替わるので、このような表現には以前より違和感があります（プチ・ジャイアントキリング的な表現をしたいのはわからなくもないですが）。
個人商店からの脱皮（２）
取ってきた、或いは取れそうな案件にアサインするリソースは、社内にアサイン担当者をおき、オーナー判断だけで決めてはいけません。
人間はだれしも自分の案件を重視するものですが、オーナーがそれをやってしまうと、他の人間の士気が落ちます。
まさに悪循環への第一歩です。
個人商店からの脱皮（１）
まずはRate Card（価格表）の整備は必須ですね。
当たり前のように聞こえますが、まだ未整備のケースが結構あるのです。
正直、オーナーが案件の予算等の状況で、その都度決めるなんて、会社の体を成していません。そもそも、オーナーの体調が不調だったらどうするのでしょうか？
あと、例えばオーナーが、提案先で（ある意味意図的に）金額を眼前でガクッと下げたら、提案相手先のみならず、見積もり作成者はどう思うでしょうか？
マイクロサービス
言葉自体は以前からありますが、最近適用可能性を感じるケースが増えてきました。従来のSOAとの違いにも軽く触れています。
------------------------------------------------------------------------------------------------------
まずSOAでは、サービスの切り口としてXMLで定義された「Webサービス」（SOAPやWSDLなど）が有力視されていました。現在の主流であるRESTful Web APIよりはるかに複雑な仕様群です。そして、Webサービスによりシステムコンポーネント間を結ぶためには、ESB（エンタープライズサービスバス）と呼ぶ複雑な（つまり高価な）ミドルウェアが必要だと言われていました。非同期メッセージへの対応、高負荷への対応、障害発生への対応、サービスレベルの保証、セキュリティなど、利用条件をエンタープライズシステムの伝統的な基準に合わせて厳しく設定すると、こうしたミドルウェアの必要性はもっともなように思われました。SOAは「難しく考え過ぎていた」ためにうまくいかなかったのです。
一方の「マイクロサービス」では、Webの文化から生まれたシンプルなRESTful Web APIをサービスの切り口にすればいいじゃないか、という考え方です。ESBのような重量級のメッセージングミドルウェアは使いません。
------------------------------------------------------------------------------------------------------
そうなのですよね。
