新事業を立ち上げたいなら

さて、では強みの無い会社が何をすべきなのか、私なりに考えているところを書いてみましょう。
やるべきこと
1. みつける
 むかし、むかしの流行語に「選択と集中」というものがありました。パナソニックが大胆な改革に入るときに打ち出したスローガンだったと思います。考え方は似ていますが、集中できる分野を見つける事が必要です。
 集中できる分野とは、価格競争など不毛な競争状況に陥っていない、勝てる要素のある分野ということです。時に新規事業を検討するというからリストアップされた多様な分野へ幅広な対応をしてしまう会社がありますが、選択を正しく行い、できるだけ集中していく必要があります。そのためリスクや事業計画などを綿密に検討することも重要ですが、一方で迅速な対応も求められます。
2. 修行
 強みがあれば修行は必要ありません。しかし、それが無いのですから、修行の期間が必要です。もし外資などベンダーの代理店や提携先を模索するのであれば、プロフェッショナルサービスや営業として形式はともかく出向のような状況をつくり、できるだけOJTの体験をするべきでしょう。
 SESの会社では、しばしば「プロジェクトでの体験」を求めるケースが多いのですが、実際にはプリセールスや営業などフロント業務から修行していくことで、要員育成のオーバーヘッドが減らせますし、フロントエンドに携わることで、案件先や市場の意向を汲み取る事ができます。
 ただ難しいことは、こういった人材をSES会社では育成しきれていないことです。以前にも書いたように「技術的には可能だが、現実解ではない」提案をだしてしまう人材しか対象にリストアップできないのであれば、受け入れ先とも話をして、矯正していく必要があるでしょう。ただ、これは受け入れ先のソリューションや体制によって変わる所ですが。
3. 組織
 初期の組織は小さいほど良いでしょう。最小構成は携わる人間も一緒に考えるべきですが、逆に一人に全てを押し付けてはいけません。小さいことでリスクも小さくなる一方で、将来の組織作りに柔軟性が与えられます。また小さい組織として一定の独立性を持たせることも重要です。この事で、いわゆる「気づき」に素早い対応が可能になりますし、逆に要員は「気づき」を大切にすることができます。ビジネスの立ち上げは当たり前のように当たり前には動かず、実際、計画段階では気づかなかったことが毎日のように、壁となって立ちはだかりますね。この壁を乗り越えるためにも、小さく強い組織を作り、経営が後押しする体制を作る必要があります。得てして経営の方は立ち上げの後は組織に任せてしまう場面を見てしまいますが、むしろ応援することこそ本義なのではないでしょうか?

やってはいけないこと
1. 余剰人員対策
 失敗の原因で一番多いのが、携わる要員です。最悪なのは「今、時間のある人間」です。こうなると前述のような修行にも耐えられませんし、将来の組織像も明確になりません。また、こういう形で開始をしてしまうと次に類似のことをやろうとしたときに「俺、不要な人間なのか」と携わる要員がネガティブなマインドになってしまうので、決してやってはいけません。
2. 公平原則の適用
 企業は大なり小なり、幾つかの部門に分かれています。そのため公平原則が意識しなくても出来上がっているのですね。全ての組織が平均的に忙しく、平均的に業績を上げているのであれば正しい原則だと思うのですが、一方で、新規事業の場合は平均以上に忙しく、平均以下の業績にしかなっていないはずです。公平性を担保しようと思えば、当然、新規事業の担当者に対する評価はマイナスになってしまいますし、最小化された組織では予算規模も自ずと小さくなってしまいます。この状況では、いざ展開ができ始めたときに広報も人材登用も後手に廻り始めます。もっと悪いパターンは業績が上がるまでは「欲しがりません、勝つまでは」で無理やり『働かされる』状況に追い込まれることです。こうなると、事業がつぶれるどころか大切な要員までつぶすことになりかねません。
3. 感情的な逃避
新規事業を立ち上げる立場、企業では経営層だと思います。精魂傾けて立ち上げたビジネスが花開くことなく終了してしまうこともあります。あるいは諸般の事情でクローズを求められることも。
そういった中で、最悪の閉じ方があります。それは「思い通りに動かない」「思ったより手間暇かかるな」と感情的に閉じてしまうことです。意外かもしれませんが、対外関係などからグダグダしてしまい、論理性のないところで事業をたたむ例を幾つも見ています。その防止のためにも要員には日ごろからキャリアパスも含めた合意形成をする必要がありますし、事業継続のポイントを客観的に把握、そしてできれば共有すべきだと思うのです。

会社の強み

いわゆる失われた20年と言う期間、リスクとコスト投入を避けることで伸びた企業が多かったのではないでしょうか?
その結果、正直、聞いたことも無かったIT会社が上場を果たしています。一方にはECなどITを活用した小さくて小回りの利く会社、もう一方は労働集約型と言うIT市場の特性に乗った会社に大雑把に分類できると思います。

前者は恐らく淘汰や買収・統合による集約が訪れるのでしょうが、基本的に成長の流れにあると思っています。が、後者は正直、厳しいと思うのです。それが、ここまで書いてきたSESを中心とした収益モデルにあるからです。まず従来から抱えている問題として、収益の源泉が「人頭」に依存している事があります。派遣業と同じ構図です。派遣に比してSESの場合、概ねの相場観があり、特に景気後退期には単月費用を値引きの対象にしていまうなど、オフショアの攻勢もあり厳しい環境で生き残ってきました。この点は素晴らしいことだと思います。
しかし、この構造のために社員の給与を上げることは利益率の低下を招きますよね。
オフショアの信頼性や人件費の上昇、また様々な経費から、価格競争には一定の歯止めが掛かったとは思います。しかし、長年、人件費の抑制で培ってきた業績は一朝一夕で急カーブを描けるものではありません。
また、人材の確保も実態は麻痺を起こしているのではないかと思うくらいに問題です。やはり給与、そして働く目的などから優秀な人材ほど中途退社をしてしまっている状況です。彼らにしてみれば市場価値のある間に、他に移った方が良いというのは自明の判断でしょう。その一方で、残った人材を悪く言うわけではなく、やはりSESと言う文化に同質化していく方向になってしまうのではないでしょうか?

ただ、SESが早晩絶滅するとは思いません。一定の需要は常に存在し続けるはずです。しかし、そのパイは小さくならざるを得ない、いやパイに対して大きすぎたのだと思うのです。
従来は事業会社のIT部門の軽量化に伴ってパイが成長してきました。オフショアなどの進出があっても許容可能なレベルだったのだと思います。しかし、その中で「自社の優位性」について真摯に向かい合っていたのでしょうか?
あるSESの会社さんでは、少ないながらもプライムで保守案件などを持っています。その取締役との会話で「うちの強みを活かした提案ってできない?」と気楽に言われてしまった思い出があります。「強み?具体的に例を挙げられますか?」と質問してみると「それが判ってれば、聞かないよ。何でも良いんだよ」と…。
(いや、それ御社の強みじゃないですよね)…。
異口同音とは言いませんが、似たような話はあちこちで聞いた事があるのですが、やはり回答はないのです。良くて「あるはず」です。
私の視界で言ってしまうと、その状況は「無い」です。
国内で元気だなと思うようなIT企業、特にパッケージやSaaSを持っているような会社では、売り出し中のソリューションが過去何年も会社や経営者の経歴に紐付いています。私自身の卑近な経験で考えても、毛色の新しい製品やサービスを担当する時に「やれそうだ」と思えるかどうかは、自分が過去に経験したソリューションとの類似性の有り無しがポイントになっています。汎用機、DBMS、OS、ERPCRMミドルウェア、金融…。恥ずかしいくらいに沢山の分野や製品を経験してきましたが、重なり合う部分が見つけられれば、すぐに立ち上がることができるのですね。
しかし、これは自分が気づかないと経験を活かすまでには至りません。外から「○○と似たようなもんだから、大丈夫だよ」と言われても、いわゆる「腹落ち」しないと(石頭な)私には大丈夫と言えないのです。
先ほどお話を書いた役員さんたちの会社に転写してみても似たようなものかな?と思うのですね。
例えば、取引先のリストと要員展開しているシステムや分野などでマトリックスを作って見ます。そこから、深堀や新規事業の可能性のリストと紐付けをして提示してみた事があります。件の役員さんにはウケます。しかし、役員さんから現場の部課長に見せると反発とは言いませんが「無理」の同義語が山のように出てくるのです。
・あれはAさんだからできたので、Aさんに聞いてみないと
・既にZ社では似たような取り組みが始まっているので、いまさら提案はできません
・今、Bさんが暇だから勉強させる意味では良いですけど、時間掛かりますよ。
などなどなどです。
本来、リスト化した意味は「例示」なのですが、あたかも「定食メニュー」のように、リストから展開したような意見は出ずに「無理」「ムリ」「むり」「Muri」の山なのですね。そうなると役員さんからのフィードバックは「うち、力ないんだねぇ」と…。
いや、役員さん、本当はココから時間を掛けて方向性をつくるべきなんですよ。と言っても馬耳東風。というか、傷心モードに入って言葉が風に吸い込まれてしまったように感じました。

いくら会社がAI、FinTech、RPAと叫んでも、自社が培った強みと言う根っこがなければ厳しいと思っております。

IT市場の変化

日本ではIT分野で特殊性を抱えていると思っています。が、実はグローバルレベルの変化に着実に追従している部分があります。とはいえ、追従しているのはお客様企業であってIT企業が追従しているとは思えない現実があります。

ソリューションの変化
何度か開発基盤等について触れましたが、この分野やSOA・ESBなどのミドルウェアの分野が華やかだった時期に、ベンダーが訴えたのは「全体効率化」でした。エンタープライズソリューションと言うように企業の全体をコントロールするようにシステム環境を整理していく事が重要だと考えたのですね。特に、この技術が効果を上げたのがシステム連携です。
システム連携は連携の方式やタイミング、目的によって同じシステム同士の接続であっても複数の要素が存在するために非常に複雑な状況になっています。これが「スパゲッティ化」と言う状況です。

これを疎結合化として、できるだけ標準の方式で接続ポイントを簡略化しようとしたのがESBやSOAの考え方の基本でした。また、疎結合により例えば、一方のDB構成が変更されても、直接影響を受けないようサービスとして連携しようとしていました。
この考え方は、今でも活きています。が、過去形で書いている理由があります。それは、従来、実現のためESBツールなどと呼ばれた製品で実現しようとしていたのですが、Webサービスの一般化、普及やAPIの提供によるパッケージやSaaS疎結合化を可能とした接続方式の提供で、Javaでスクラッチの開発を行っても比較的簡単に実装できるようになったからです。

でも、これだけでは「全体最適はできないじゃないか」と言う問いかけには「その通り!」といわざるを得ません。いや、接続が簡素化=疎結合化されることで一定の全体最適が行われたと考えてよいのだとは思います。が、本来であれば、ここから接続内容の管理(利用頻度や方式管理)に発展させようとしたベンダーも多かったのですが、現実にはそれ以前の段階でお客様(市場)が満足されてしまったと考える状況ですね。
で満足したお客様が考えたのは「部分最適化」と言うべき改善です。ここで言う部分とは、単一あるいは比較的小規模の業務集合に対する課題解決として書いています。例えば、セキュリティというと企業全体の試みになりますが、ログインだけを完全にするためワンタイムパスワードを構成してみたり、工程の管理を行うためにプロジェクト管理ツールを導入するなど、業務や課題に特化した解決策の導入が増えたと思うのです。

特に、この流れを加速させている要素が「SaaS」です。内容にもよりますが、SaaSなら小難しい設定も構築もなく、すぐに使えるものが多く有ります。ユーザー登録が終わったらすぐに書き始められるフリーのBlogツールなどは典型的なSaaSでしょう。そして、各業務や部門にありそうな様々な課題に合わせて、痒いところに手が届くようなSaaSが沢山出てきているのですね。

部分最適が歓迎される訳
部分最適全体最適は神学論争のような関係がありました。部分最適は、業務に特化した解決策だから費用対効果も可視化しやすいと主張し、全体最適部分最適の積み重ねで複雑化したシステム環境を改善しなければ適時のシステム更新すらできな現実を打破する必要があると主張したのです。で、現在は部分最適に大きくシフトしています。それは接続の標準化・疎結合化の普及もありますし、もう一方で、やはり経営層や財務の視点で部分最適による効果の可視化にこそ重点が置かれやすい現実があると思います。

セールス対象の変化
このように部分最適が進んでくると、従来の「商流」にも変化が起きています。例えばシステム連携も必要ないSaaSなどは、業務部門が勝手に契約することも可能です。まぁ現実にはセキュリティチェックや法務チェックなど一般的な調達に必要な手間が掛かりますが、特にIT部門を経由する必要も手を煩わせる必要もありません。
また自前のシステムと連携するようなSaaSでも、IT部門の選定よりも業務部門が効率化や課題への対策となり得るかを判断することが優先されます。となると、売り込む先は業務部門です。が、IT企業の多くは、お客様企業のIT部門とはコネクションはあっても、中々業務部門にはコンタクトができません。ERPを扱っているところでも、本当に人事・在庫・経理などの個別業務部門とコンタクトを取れていれば未だしも、業務向けSaaSを最適な人に提案することは難しいようです。
そしてIT会社には、もう一つの問題があります。
それはSaaSが自前の製品なら、利用料の殆ど全てが自社の収入にできるのですが、例えばSFDCやNET SUITEような他社製品の販売代理店としてアクションする場合、収益率は決して高くありません。営業の評価として考えると恐らく、ERPなら年間で一件でも成約すれば充分に3-10人のチームが構成できるのに、SaaSの場合、年間で10件以上とらないとシステム連携やコンサルテーションなどの付帯的なサービスを構成することが難しいのではないかと思います。
となるとSaaSを初めとした部分最適のソリューションは「薄利多売」と言うよりも「小利多売」(小さな利益を多量に販売する)が求められてくるのですね。そして数をこなすように売りに行く先は、誰も知らない事業部門だったりします。とてつもないチャレンジだと思います。

CIOからCMOへ、そして現場へ
以前ほどではないとは思いますが、米国では今でも激しい買収活動が行われています。ただ以前ならIBMOracleと言うIT屋なら誰でも知っている会社が買い手になっていましたが、最近は「知る人ぞ知る」ような会社が特殊な技術を持つ会社を盛んに買収している印象が強いのです。そういった買収のニュースを見ていたときに「CIOからCMOへ」的な表題を見つけました。上で書いたように、従来ならCIO=情報システム担当取締役とのコンタクトを重視していたが、アメリカではCMOマーケティング担当取締役をターゲットする方向へとシフトしているようです。
この動きは、恐らく既に日本でも起きています。最近、ウォッチしているとあるソリューション業界では、アメリカでもヨーロッパでも「非IT」だった会社や「ニッチなIT会社」が主役になってきているのです。その分野ではIBMOracleも、現在の巨人であるAmazonGoogleも一般市場では活躍できていません。恐らく100人にきいて1人か2人「お、知ってる」と言う感じでは無いでしょうか?
そして、その新たな主役が元々持っていたソリューションが優れていた訳ではなく、彼らが持っていた「知見」に見合う新しい技術ベンダーの買収によって強力な存在になっているようです。市場の規模で言えば、基幹システムやプラットフォームといったソリューションには到底敵うレベルにはなりませんが、確実に存在感を見せつけています。日本にも、同様のサービスを提供している小さなベンダーがあるのですが…とても頑張っているのですが…今のレベルでは市場の大きなパイは外資に、そして残ったところが国内ベンダーにというすみわけができるのでは無いかと見ています。
このようなシフト、実際に聞いてみるとIT部門の関与は製品選定が終わった後、あるいは、ほぼ具体的な選定に入った時点と言う状況のようです。こうなると、従来型のIT会社は、もしIT部門からRFPが出たとしても確実に後手になりますし、勝ち目のあるソリューションは提示できないでしょう。

 

 

プリセールスって楽しいのだ

さてプリセールスとしての愚痴を沢山書いてきましたので、今回は重要性などアピールすべきところに話を移します。

私の中では
プリセールス=セールスサポート=ソリューションコンサルタント
です。他にいろいろな定義やご経験上の区別もあるのは存じていますが、上の定義で書いていきます。

役割は以前にも書いていますが、実際、案件が無い状況ができると、いつの間にかマーケティング的な活動に入っていたりします。
「おい、外資だったら優秀なマーケティングを雇っているだろ」と言われるのも存じておりますし、本当に優秀な方と一緒に仕事をしていました。ただITベンダーの場合、新製品や新サービスなど特に技術的な新要素について、最初の国内コンタクトポイントになるのがプリセールスなんですね。ほぼ同じタイミングでマーケティングにも情報は行きますが、優位性や特長の他、経験も踏まえて競合になりそうな他社製品などの動向までを抑えているのはプリセールスです。また、私の場合は多少なり英語が使えるので、気になったら本社のキーパーソンに連絡を入れまくります。「A社の製品にバッティングするけど、どこで勝てる?」「B社の製品とは上の価格帯で勝負することになるけど、何か想定している?」とかですね。そしてほんの時々ですが「日本のC社の製品が、ものすごい強い分野に勝負掛けるんだけどね。○○とか××が相手の弱点なんだけど、こっちは?」みたいな事を書いたりします(逆に、何も調べずに聞いてもスルーされる事が多いのです)。ではマーケティングは?といえば、この時点で動き出すのが「フェア実施の予算は?」⇒「プライベートセミナー実施の予算は?」⇒「投げ込みやっちゃう?」的なところで動いています。彼らの多くは、あまり製品競合力には無いようです(笑)。
こうして、プリセールスは時には自分から、時には営業から「意見を聞いてみたいお客様」へ連絡を入れます。そうして市場の価値を探り、同時にそのお客様への取っ掛かりができるかも狙っているわけです。

では、マーケティングは?といえば
 Web: 本社作成のページを日本語化
 ブローシャー:本社作成のPDFを日本語化+印刷発注
が主務です。ここら辺の段取りが上手く動くと現場もやりやすいんですね。逆に、段取りが悪いと、現場がお客様を一周して「あ、こりゃダメだ」となったころにドサ〜っとブローシャーが入荷するのを見せ付けられてしまうのです。
マーケティングのプロ以上に、マーケットの状況を把握するのがプリセールスの役割なんですね。

次に出てくるのが、社内キーマンとの連携です。外資に勤めていたときに本当に力を使ったのが、これです。
例えば日本語化の重要性や、機能改善事項の取り扱い、質問などへのエスカレーションなどなど、全て海外にいる開発チームや担当開発マネージャーと通じておかないと蚊帳の外に置かれてしまいます。
実は、この動きをする外資の人は少ないかも知れません。一つは語学の問題、もう一つはチャネルを作る事が大変だと言うことです。外資に勤めていても、そうしょっちゅう本社へいけるわけではありません。会社によっては本社とは別の拠点・別の国に開発チームがいたりもします。便利なメールで知り合いだと思っていても、やはり対面もしたことがないと、他人行儀な部分は除去しきれません。
私自身、けっして上手な英語を話すことも、書くことも出来ません。でも、重要なポイントがあれば、社内のツテを手繰ったりして、キーパーソンを見つけ出しておき、会えそうな機会があれば「来月、本社へ行くんだよね。会えるかな?」とメールでアポ取りをしておきます。そうすると、予め自分の中には質問リストを用意しておくことができますし、確認事項の漏れがありません。こういう海外出張の機会があると、日ごろの忙しさからエスケープして本社でのんびり過ごす想像をしてしまうのですが、実際には時差ボケと戦いながら昼は開発と、そして夜は日本で待っているお客様とのコンタクトで寝る間が無いんです。

ただ、ここまでやっていると報われることもあります。当初は無理だと門前払いに近かった機能改善をロードマップに盛りこんでもらう約束を取り付けたり、何かと相談にのってくれるなどは、プリセールスならではの喜びだと思いますし、そういう関係性もなく「いや本社の方針ですから」としか答えないプリセールスを心から…以下、省略です(笑)。

それがお前らの「提案」かぁ〜!?

今回もSESの会社さんとのお付き合いで感じたことです。
当時、開発基盤と言って良いような製品に携わっており、そのチャネル(販売代理店)開発で沢山のIT会社に伺っていました。パッケージなどを扱うところは、中々、話が前に進まないのですが、SESの会社さんは話が早いところが多く「じゃ、今度、お客さんのアポとりますね」と言われたり「社内説明会をお願いします」と前向きな反応をしてもらえました。が、大抵はすぐに話が止まるんですね。と言うのも彼らが求めてくるのは「適用事例」なのです。正直、これ外資の多くは「掴み」に使うものだと思っています。だって、導入にベンダーが深く入り込む事が少ないですし、導入過程の話はお客様の機微情報ですからね。その前提をつけて資料の提示や説明をしても「実際の工数は?」「工数の削減率は?」と聞いてくるんですね。正直(シラネェよ)とも思いますが、こちらからの回答は「通常、御社で類似の案件見積をすると、どれくらい掛かりますか?もし必要なら評価版を提示しますから、それを使って工数比較されては如何でしょうか?」となります。まぁ、これ質問への「すかし」みたいに見られるかもしれませんが、本当にこのくらいしか彼らが求める定量評価の試算ができないのです。場合によっては「NYのお客様にチャネルを作って頂きますから、必要ならお申し付けください。現地担当者が案内いたします」と言うこともあります(英語の壁で99.999%「い、いや、そこまでは…ねぇ(汗)」と言う反応でFinです)。
で「すかし」では無い理由ですが、まず、評価版の手配が必要です。私の勤め先ですとライセンス発行のための契約が必要です、その前提でNDAの締結から始まることもあります。で、ライセンスが発行されたらインストール。で、インストールの最中に、予めお願いしていたDBやミドルウェアの調達ができていないことや、時にはサーバーがないことが判明します(マジです)。
そして、次にトレーニングや説明会で使い方などを簡単に(一週間かけて習ったことを、「掻い摘み*100」の勢いで脳内編集して一日)レクチャーして、使い方が判らないとか、なんかコケたとかって質問にお答えする。なんて事を、時には一人でやらないとならんのです。ね「すかし」てる訳ではないんです。IT会社さんが求める数値を求めるために、かなり真摯な提案をしているんですよ(笑)。

で、この手順の通りに進んでいけば、まだ良いのです。が、大抵はインストールが完了する前に止まりますね。準備ができないんです。時に「動くPCサーバ貸してよ」とか言われることもありますが、今どき、他社のサーバーを滞りなく社内に持ち込んで、ネットワーク接続や普段使っているPCとつなぐなんて事ができるはずがありません。「貴社のセキュリティ管理者とご相談いただいて、必要書類を頂いてからの調整で良いですか?」で話が止まります。

更に、先に進んだとします。99%、定量評価は出せていませんが、お客様に持って行くんだとかって話しができていたりします。あ、逆ですね。事のおこりは、大抵「○○社へ提案したい」というのが多いパターンです。でIT会社さんは自社紹介資料だけを携え、こちらは印刷した説明資料とデモ機に説明資料を抱えて訪問します。が、99.9%討ち死にします。そのキーワードは「で、製品は判ったけど、これをどう使えと?」です。大抵のお客様は課題に対するソリューションがほしいのですね。そこに嵌れば、遅いDBでも高価なサーバーでも売れると思います。が、形のない開発基盤で何をしろと言われても、日本のIT文化では先の無い話しか出来ません。IT部門に持っていったとこで、彼らのスタッフがプログラミングをしているケースは少なく、多数はSIerが担っているのですから、そちらが使えるかどうかがポイントになるのです。以前にも書いたとおり、開発効率化が決してIT会社に歓迎されるソリューションにはならいのですから…。

でも、これはまだ良いほうかも知れません。一度、開発基盤をお客様に紹介したいといわれた事がありました。この頃、既にその会社を離れた身としては、正直「どうでも良い話」ですし、話を振られても手の出しようが無いのです。が、現状の会社にコンタクトを上手く取れないからと、紹介されたのです。そこで信じられない言葉を聞いてSES会社の病理みたいなものを感じてしまいました。それは「開発基盤を提案したいんですよ」です。想定は事業会社で、規模はそれほど大きくない。頭の中で簡単に想定図を書きましたが、そこに開発基盤で喜ばれるストーリーを置く場所はありませんし、簡単な想定回答を用意しておきながら、簡単な質問をしてみました。「で、どう提案したいんですか?と言うか、どういうペインがあるんですか?」と。で回答は想定外の低レベル「いや、それを聞きたいんですよね」。つまりドアノッカーにしたいと…。それも、開発基盤でと…。ありえないのです。先ほど書いた「で、どう使えと?」と言われるんです(笑)。その時の顔を見たいなぁと思いつつ、自分の趣味の悪さをポケットにしまっておくことにしました。

提案という言葉が多重下請で下位に回るほど軽くなっているようです。本来、これで「ご購入を検討していいただけませんか?」が提案だと思うのです。ところがGoogleがネット購買で「提案」するようなレベルにも達していない。そんなもので提案を受け止めるようなお客様に私は会ったことがありません。

PMとプリセールス

PMとプリセールスは国内のITで比較的「軽く見られる」カテゴリーだと思っています。
「PMとは?」と考えると、本来はプロジェクトでお客様との最大の接触点です。接触にはコミュニケーションとネゴシエーションの二つがあり、これを裏で支えるため要員の管理、スケジュール管理やコスト管理の他、リスク管理など多岐にわたる管理と、その為の経験や知識が求められます。言ってみれば、期間限定の(かなりシビアな意味で)経営を行わなくてはなりません。

しかし、実態で言えば例えば
スケジュール遅延が起きている←ネゴシエーションが機能しない←プロジェクトの実態を把握していない
と言う図式が成立している事が少なくないよう思うのですね。
プロジェクト内でPMは厳然たるトップですから、それでもリーダを初めとしたメンバーは付き従う必要がありますが、概ね破綻している状況といって過言ではないでしょう。
では、なぜ、こんな事が起きるのでしょうか?
まず、考えるべき点としてPMの職責が曖昧になっている事が上げられると思います。あるプロジェクトを請け負ったとき、その組織のマネージメント階層がそのままPMとなっていることが少なく有りません。ところがマネージャーが提案段階で仕切っていたとは限らず、またPMとしての経験や知見を持ち合わせているとは限らないのですね。つまり組織マネージャーとプロジェクトマネージャーが同一視されてしまっていることに問題の起因があると思っています。ただ、別の問題もあります。

もう一つは特に中小規模のプロジェクトの場合、PMをテキトーに選んでいると思うケースがあるのですね。どういう事かと言えば、PMがPMとして自己認識をしないまま組織のマネージャーから委託されて「言われるがまま」に着任してしまうケースです。この場合、お客様との接点も含めて機能しない人が少なからずいるのです。SESを主体としたIT会社のマネージャーさんと会話したときの記憶ですが「PMって何のためにいるんですかね?まぁガントチャートとか作る人はいりますけどね」と…。(いや、それPMOにやらせなさい!)特にシニア階層になるまでお客様とメインで折衝する必要がなかったのですから、言われるがままに動く事が正義になっているかと思いますが…。
逆に同様にSES主体の会社で人事、特にキャリアマネージメントを中心に考えてる担当者の方からは「うち、シニアになるほどSE志向が強いんですよ。PMとかコンサルタントって…」と嘆かれていたのです。で、少し突っ込んで聞いてみたところ、会社認定のPMになるためには100人月程度のプロジェクトでのリーダー経験が5回以上、コンサルタントは同規模のプロジェクトをマネージした経験が2回以上と言うのです。察するに100人月のプロジェクトマネージメントの機会は、その会社では殆ど無いはずです。が、数名の認定コンサルタントがいると言う『矛盾』を尋ねたら、「基準はあるのですが、結局は上司の方や担当の役員からの推薦で決まるんですよ」と…。「基準、意味ねぇじゃん!」と言う叫びは胸の中にしまっておきました。
が、結局、PMもコンサルタントも言わば評価の延長線上にしかなく、PMとしてのスペシャリティや役割について明確なものはないと言うことです。であれば、普通に過ごしてマネージャー→部長と無難な昇進を狙うか、昇進などというストレスもなく言われたことを素直に(悩みながら)作っている方がローリスクなサラリーマンライフをエンジョイできるでしょう。
つまり、会社の経営層も社員自身も「PM」と言う立場に現実感もなければ憧れもないのですね。

では、プリセールスです。こちらは、もっと悲惨だと思っています。
先に米国ベンダーでの経験で考えて見ます。
新製品や新機能の提供が発表される→特性や改善点を把握⇒説明資料の作成⇒既存の顧客やプロスペクトでの適合性をシミュレーション(妄想)⇒営業への説明や提案→営業から説明先へコンタクト⇒説明実施⇒反応などから適正や有為性の見直し⇒説明資料の修正
と言うサイクルを形成します。
言わば製品の現実的な市場投入にプリセールスが指導的な立場をとらなければならないのですね。
ところが、こんな事は日本のSEさんにはあまり求められません。
逆に言えば「無駄」と思う部分が多いのではないでしょうか?例えば、外部の製品やサービスを提案憎みこむ場合、その部分は製品のベンダーに任せてしまう。場合によってはプレゼンや説明会でも製品ベンダーが語る場面を作るそうですが…。お客様がIT会社に相談や提案を求める場面で自社・他社の敷居のないソリューションを望んでいるはずです。明らかに有名なSAPなどの製品を組み込んでいても、その周辺を含めた知見がIT会社にあるかどうかがキーポイントになると考えています。その前提で言えば、特に初めてソリューションに組み込む場合、ベンダーのプリセールスと同様、あるいは別の視点から特性や適合性を調べなければならないはずです。が…。お忙しい中では無理難題なのでしょうか?
あ、ただダメだしについては時間を使われるケースが多いかも知れません。
これもリスクを嫌う一環なのでしょうが、外資ベンダーに勤めていた当時、時々ですが、焦点の定まらない質問の羅列に悩まされた事があります。時に同行した営業が「それが判ると何か前に進むんですか?」と言うレベルといえば良いでしょうか?そうですね。例えば「その製品の内部でtomcatを使うようだけど、他に使っている外部製品を全て提示してください」とかですね。こうなると…まぁ海外の開発部門なんかにエスカレーションするんですね。すると「それリエンジニアリグじゃね?」と判断されて、良くて「内部機密に抵触するので回答は差し控えます」、通常ならエスカレーションもスルーされて終了です(こちらで「内部機密に…」を書き起こすことになるんです)。

正直、この手合いで商談が先に進んだ経験は自分だけではなく、同僚たちの案件を見ていても「皆無」でしたね。

ただ逆にお客様やIT会社から見るとベンダーのプリセールスは「ただで使える」と言う利点があります。そう評価が低いと言う点や、日本のIT会社がプリセールスの育成に不熱心な理由は、もしかしたらここにあるのかも知れません。
私などは若いころから修羅場や針の筵のような状況を過ごしていると、お客様とのネゴはキーポイントですし、楽しくもあったりします(時に「ストレス不感症」と言われることもあります)。が、そんな経験がなく闇雲に知見もない製品のセールス活動の手伝いに借り出されたとしたら、相当なストレスを感じるでしょう。それは当事者だけではなく、組織としても共有しやすい感覚だと思います。その裏返しの感情も手伝って「プリセールス活動はコストばかりかかる無駄」としてしまうのかもしれません。

PMもプリセールスも、ある種の人からは「生産に直接関与していない」と思われる、いや、実際に言われたこともあります。が、生産が資材も機材もなしにできると思っているとしか考えられない「非現実」ではないでしょうか?

忙しすぎるSE

結構、長い間、外資系のベンダーに勤めていました。そして国内の会社で働いていても、結構、外資ベンダーとのお付き合いが発生していました。そこで比べると、日本のSEは働きすぎです。

「お前、働き者を馬鹿にするのか?」と言われそうですが、馬鹿にしている部分があります。
以前にも書きましたが、日本のIT会社の場合、多くはプリセールス要員がいません。そのため、提案が「ビビリ」になっているのです。以前も書いたと思いますが、私がプリセールスとして誇れるところは(胸は張りません)、お客様の要求の引き出しにあります。引き出したら出来る出来ないは兎も角、出来るように考えます。が、ビビリの提案になると要求を抑え込んでしまうのです。一つの理由は、日本のIT会社の場合、どうしても提案活動の期間が限られます。RFPが来て初めてコンタクトが取れるような事も珍しくないようです。こうなると、活動期間は数週間から1ヶ月。一気呵成に見積作成にまで持っていかなくてはなりません。RFPから読み取れないことは想定で書き込みます。そんな中で要求の引き出しなんてやっていては、いつまでたってもプロジェクトのキックオフどころか見積が作れません。
私のような「はしくれエンジニア」から見ていると、優秀なSEさんほどビビリになる傾向が強いように思うのです。
ビビリの提案になれた人ほど、定型化された作業には強いんですね。私が100人いても出来ないことをスラスラと実現してしまいます。言葉も教科書に載っていそうな専門用語が出てきます。格好いいですね。ところが、こういった方ほどRFPから競合を勝ち抜いたプロジェクトでコケル気がします。
理由は簡単です。RFP以後、一気呵成に定型化した見積で契約していますから、お客様の中の「想い」が充分に汲み取れていません。一方でプロジェクト期間は、とても長いのです。ですから「秘められた要件」=「想い」がプロジェクトの中で出てくるのです。ところが精緻に作られた見積・スケジュールに、そんなものを汲み取る時間は全く有りません。そうなるとお客様は「あいつら融通が利かない」「選定が間違っていた」と散々な評価が出まくります。それに対して美しい提案と精緻な見積で武装したビビリには抗弁する材料がないのですね。これが「提案が固定化する」最大の危険です。

前例踏襲で済むくらい「カスタマイズはしません」「こちらがやることはここ迄です」と言い切れる商材、製品なら良いのですが、大抵は逃げ場がなくなります。で想いを実現するにもオーバーワーク、拒絶するにも文書など書かされてオーバーワーク。これが働きすぎになる第一弾ですね。
次がプロジェクト管理です。プロジェクト管理のためのドキュメントが多すぎると思うのです。ガントチャートだけをとっても、社内用とお客さま用の2つを作る。少しでも遅延があれば社内の説明を資料を作って行い、またお客様にも別途作成の上、説明。いやいや、忘れていました。提案でも見られますね。提案書自体はチャチャっと作っているのに、その裏にあるソフトウェアやハード、サービスなど外部からの仕入見積、それを社内の原価管理に落とし込んで、更に利益率やリスクレートを掛け合わせて…で、検算をして見ると辻褄が合わない。で、もう一度計算してみて…。とExcelとの格闘が行われます。中間、見積の変更などが入るといけないので、バージョンをガンガン上げながら共同作業をしていると、今度は先祖がえりしてしまって、再計算。ギャグのような状況が簡単に起こるのです。
確かに、こんなことをやっていれば、お客様と会話する勇気なんて持てない訳です。ビビッて当たり前、私だってビビリます。こうなると「社会が悪い!」とか言いたくもなりますが…。仕事のやり方を変えないとね。で、これが働きすぎになる第2弾です。

そして、もう一つ。これがプログラマー信仰に根ざしているところで…。本来、技術の発達と共にGUIベースで開発する事が一般化してくるだろうと思っていました。そして、そう提唱もされていました。が、結果として、未だに「.netで開発が」とかって感じなのです。前にも書きましたが、様々な開発ツール(有償版)を使うと、製品価格はアドオンになりますが、一方で開発の人件費が下がるので全体の見積費用はトントンになることが多いのです。そして、手組みでプログラムを組むよりも一般的にバグ発生率が低くなります。バグは一定数発生するのがプログラム開発の要諦ですが、一方で一定数を越えてしまうとスケジュール遅延になります。更にテスト仕様などに漏れがあれば、そのまま本番稼働中にトラブルが起きてしまうのですね。それだけ、プロジェクトの潜在的なリスクが低くなるのです。ところが、特に日本では、こういったツールの導入が進んでいないように思います。その理由がIT会社のせいだとしたら、怒られますか?(笑)。
その責任論は兎も角、IT会社がブレーキをかけていると思う理由があります。それは「開発生産性」です。
開発生産性が良くなれば、SEさんの稼動時間は短くなります。が、IT会社の生命線はSEの稼動時間なのです。当たり前の事ですが過剰な残業は誰も望んでいません。特にIT会社自身は望んでいません。が、開発生産性の良いツールを使ったプロジェクトで見積を行えば、当然、見積に出てくる数字は小さくなります。すなわち!売上予測が小さくなるのです。過去には某製品を使った開発を高らかに宣言したプレスリリースをしたがために「○○を使うんだったら、もっと安く出来るはず」とお客様に鴨のようにされてしまったIT会社もあったそうです。
「ん?でも売上は変わらないって言ってたジャン」と言われるのでしたら…。その通りです。ところが、全体の利益率は小さくなります。SEさんが稼ぎ出す100万円と外部から仕入れた製品を販売する利益率が違うのです。当たり前ですがSEさんの方が高い利益率を設定されているのですね(あ、ピンはね?)。
それに、保守なども考えればシステムが何かやるよりも人手が掛かる方が、将来的な売上にも関わるのです。効率化が中々進まない、これが第三弾です。

 

忙しいことが美しく扱われるのは、勘違いだと思います。その人、あるいは組織・会社として仕事の進め方がおかしいのです。忙しすぎて勉強ができないというのも、勉強しすぎて仕事ができないのと同じくらいに変な話だと思うのですよ。