CoE…出来ないなぁ
余り日本のIT業界で聞かない言葉に「CoE（Center of Excellence）」があります。
Wikiでは「日本では、組織横断的専門集団、組織横断的研究拠点などの意で用いられる場合が多い」と説明されていますが、欧米の大企業ではIT部門を中心にITベンダーの専門家が参画した組織形態になっています。
このCoEを通じ、企業内の課題に対してアイデアを持ち寄り改善に繋げていきます。
私の知る範囲では、こう言ったIT部門では自社での開発や管理も行っていることもありCoE自体は、フラットな立場で意見交換や要件集約が行われているようです。
このような「流れ」を考えると、日本では中々根付かない形式に思えます。
まず、お客様とのフラットな意見交換が難しい実態を上げざるを得ません。中小規模の企業ではIT部門がIT企画機能だけを持っている事が従来から少なくなかったと思うのですが、最近では大きな企業でも実態は企画あるいは管理が中心になり、企業内での課題をITに落とし込む（この表現からして…よろしく無いんですが）段階でお客様は行司のような立ち位置で、ベンダー間の話し合いになってしまう事が多いと思うのです。更には、お客様不在でPMOとして雇用された人たちが行司になり、お客様は結果の報告を受けると言う姿すら少なく有りません。
大昔の話で恐縮ですが、それでも「温故知新」として自分の戒めにしていることがあります。それは「お客様以上に業務を理解している人はいない」と言う若かりし頃に出会った上司の言葉です。「お前たちはシステムの専門家にはなれる。けれどもお客様の業務はお客様が一番知っているんだ」と。年を重ねるに従い、この言葉に疑念や同意を繰り返してきました。が、一つ一つの事柄に照らし合わせてみると、哲学として理解しておくべきことだと信じています。
まず、お客様の業務課題が例えば「早期にWebチャネルを立ち上げたい」だとしましょう。Webプログラミングの経験があれば、恐らく「できます」と言えるレベルの案件でしょう。しかし、
・既存のWebサイトなどとの標準化、統一性は？
・ユーザIDやIDに紐付いた行動履歴の活用は？
・Webで表示する過去の取引情報の抽出は？
・エンドユーザの登録は？
・ログイン方式は？
・セキュリティは？
・アクセスコントロールは？
・アウトバウンドや通知の実装方式は？
・レスポンスやキャパシティプランニングは？
・保守のポリシーは？
・OSやDBなど稼動する基盤の要件は？
とザックリと挙げても、これだけの事がお客様の要望を汲み上げつつ決めていかなければなりません。
時々「プロだったら、相性が良さそうなところで見積もってよ」という言葉も聞きます（本当に）。
でも、開発では連携対象のシステムを知っておかなければ、定義すらできません。また、稼動後に「そんなつもりじゃ」と言われるような事態は避けておきたいのですから、適当に見繕って構築することはプロだからこそ避けたいのではないでしょうか？
（当然、目安として提示する事とは違う意味で書いています）
また効率化や調達コストの削減と言うメリットから、どの企業でもマルチベンダーと言われるように、各所各所に色々なベンダーが納入や維持管理に入っている分業体制が出来上がっています。更にはDoAや密結合と言われるようなシステムの内実を把握しなければ連携の方式や対象業務、また実際に連携するデータが理解できないケースも少なくない上に、その定義を文書化した内容と実際に稼動しているシステムの現実とに乖離があるケースも多いのです。
本来、こう言った悲劇的な状況が生まれないように管理を（司る）する事がお客様の肝要だと思いますし、この事が出来てこそ先ほど書いたように「業務はお客様が一番知っている」と言う状況になるのですね。
ところが現実は、そうなっていない事が少なくない。「じゃぁ、どうすんの？」と言う素朴な疑問が一つは「提案時のフィージビリティスタディ」であり、プロジェクトキックオフ後の「要件定義-現状調査」になるのです。上手いIT会社なら、どちらの選択肢をとっても「課金」の対象となります。「おい、提案時の活動だったら無償前提だろ」と言われそうですが、これも大きくは二つのオプションがあり、一つは「有償で調査します」と言う場合、そして「（工数を混ぜ込んで、プロジェクト見積を作成するヨ）」と言う設定があります。
当然、後者はプロジェクト契約ができない場合は『取りっぱぐれ』になるリスクはあるのですが、営業活動などで面倒な提案を一つ減らせるというリスクの代替となるので、意外に多用されるパターンのような多い気がします。逆に言えば、契約前から綿密な提案活動ができる関係性が構築できている事が、このオプションの大前提ですから、リスクが比較的小さいと言えるのでしょう。
ただ、いずれのケースを取ってみても「お客様が業務を一番知っている」場面には行き着いていませんね。IT企業側が本当に為すべきこと「知識保有者を活性化させる」ことにあるのです。
先ほど「Webプログラミングの経験があれば」と書きました。が、あくまでプログラミングです。列挙した要望として汲み上げるべき事柄はプログラミング以前に把握していなければならない事ですね。つまり、Webチャネルに必要な要素を理解しているIT企業が「これだけの事を決めていくんです。そのため、各項目を質問表や打ち合わせで確認したいのですが、御社で知見や決定権のある方に確認をいただけますか？」と伝えなければなりません。
そう、一つの企業でも「お客様」と言う概念や人格は多岐に亘るのです。ですから営業の方などに多いのですが「お客様が判らないと言っているから」を言い訳に使われてしまうのですが、これは「お客様」の中でもカウンターの役割を担っている方が判らないのか？それとも、対象の専門領域の知識を持っている人が判らないのか？あるいは、お客様の法人全体、実働しているITベンダーでも把握していないのか。と、様々な理解ができるのです。この理解が曖昧なまま「判らないなら仕方ない」とすると、プロジェクト工数が（悪い想像に基づいて）膨らんでいきます。
逆にカウンター以外の専門家にも連携が上手く出来始めると「やっぱりお客様が一番良く知っている」と言う状況ができていくのです。
さて、CoEに話を戻します。
CoEのメンバーは、お客さまとITベンダーが構成します。ITベンダーから参加するメンバーは常駐や頻繁な訪問、実装活動などで各々が担当するお客様システムについて理解しています。と言う前提があります。こうなるとお客様からの「こんな要望が業務から出てきている」、あるいはベンダー側から「こういった製品を導入することで、他社では効率改善ができている」と言った意見交換を行うようです。その事で業務の専門家とITの専門家がお客様の状況に会った改善策を練っていくのですね。これはマルチベンダーの中でも行われており、練り上げられたソリューション案に対して、各々が担当する領域を明確化していく訳です。この状況であれば、お客様も常にいる環境で次の一手が決められていき、業務部門や経営部門が納得するIT構築ができるわけです。
この「納得」。「IT戦略」と言い換えると判りやすいでしょうか？
データは保護主義へ向かう
以前も書いたと思うけど、このままで日本のIT業界は成長できるのだろうか？
まず、SESが多すぎる、いや多重請負構造が強すぎる。
多重請負の中での力関係から、待遇・給与・ワークライフバランスまでが決まってしまう。
そんなところに若くて優秀な奴が来ない。
優秀な若手がいないから、どうやっても外人に頼るか、今の状況を維持することに汲々とする。
と言うバッドサイクルは書いてきましたね。
で、もう一つ、以前は「アメリカに10年遅れている」といわれていたソフトウェアの話です。
当時、ハードウェアについてはNECや日立などもメインフレームを出しており、官公庁などを中心に大きなシェアをもっていたため、焦点が当たっていたのはソフトウェアの部分だけでした。しかし、いまやPCすら国産が珍しくなった時代にあってソフトウェアの遅れは取り返しがつかない状況に追い込まれつつあると思っているのです。
ただ、「痒い所に手が届く『PCソフト』」や「日本の習慣や法制度に基づいたシステム」と言った所は、まだ良いのですが…。それ以外はAI分野の開発などで一部、頑張っているだけではないかと思ってしまうのです。
この状況で恐ろしいのはAIを含めたPaaS、そしてSaaSの発展です。
例えばAIのPaaSで考えて見ましょう。AIとビッグデータとは不可分な関係にあります。データ量が多ければ、それだけ学習機会が増やせるので、精度の高い結果を導き出せると言うのが（ごめんなさい、どしろうとな解説です）実情です。また現状、スクラッチの状態からAIを開発するだけの体力がある会社が少なく、特に日本のIT会社が手を出すときにはGoogleなどを使うケースが多いと思うのですね。
確かにGoogleは他のプラットフォームに比べ安価で安定性などを含めた実績もあるので、非常に提案もしやすいのです。が、その一方でビッグデータ、つまり大量のデータをGoogleに提供することになります。BPRCなど新たな個人情報保護への取り組みもあり、本来は安易な提案には載せられない状況にもなってきましたが、更に言えば国内での発生した大量のデータは、国内に蓄積されずGoogleの手の内に収まってしまいます。
SaaSで考えて見ましょう。例えばネットバンキングを使うときにリスクベース認証といって怪しげな場合だけ追加で認証行為をさせるような仕組みができています。この認証はECサイトなどでも広まると思いますが、精度を高くするためもありSaaSでサービス提供されているものが多く有ります。これもGoogleと同様に全てのデータはSaaSベンダーの手の中に入ってしまうのですね。
BPRCについて、最近、またチョコチョコと見る機会がありましたが、そこでフト思ったのは「あ、情報には保護主義が先行していくんだな」と言うことです。BPRCの場合、EU等の居住者の個人情報は一部の認定されたEU域外の国を除いて、使いづらい状況になりました。アメリカでは従来から愛国者法での規制があります。つまり一定の領域や国家の外に、個人情報が持ち出せない方向性が強くなっていると思うのです。
「そんなことを言っても、ECなんかは国境に関係なく買い物ができるよね」
はい、その通りです。ただ、先ほど触れたBPRCは国内のECサイトにも影響を与えます。下手なことをすればサイトの規模に関係なく巨額の賠償請求がくる可能性もあるのです。日本の国内法では守ってもらえない状況なのですね。
このように少なくとも個人情報が国家の域内に閉じ込められた状況になると、もし日本のベンダーが後発で同様のPaaSやSaaSを構築しようとしても、データ件数が明らかに足りず、競争にすらならない可能性があるのです。
「今だってOSはアメリカ製ばっかりだよね」
はい、その通りです。その影響もあって、今、日本のソフトウェア業界は国際的な競争力を失ってしまったと思っているのです。例えて言えば、欧米、特に英語圏を横綱とすれば、日本は十両・幕下かも知れません。それが「今」です。しかし、今後のことを考えると土俵にすら上がれないかもしれないと危機感を抱いているのです。
また、10年ぐらい前のシリコンバレーを思い出すと、白い人は当然として、ハイレベルなポジションにインド系がザクザクとおり、ミドルレベルには中華系がサクサクといる状況でした。そこに日本人は？と言えば、ほんの一握り。ベンダーによっては「日本語化担当」みたいな感じで、ちょこっとだけいるイメージでした。インド人の殆どは理工系の博士号もちが多いのも確かですし、彼らのコミュニティーがシリコンバレーどころかヨーロッパにまで伸びているのも有名な話です。
日米での貿易状況で考えると、全体としては日本が黒字なのでしょう。しかし、ITに限ってみれば完全な赤字だと思います。特にソフトウェアの分野は…悲しい状況ですね。
「インドや中国だって自国に有名なIT企業はないじゃん」
はい、その通りです。ただ、一方で彼らは人脈構成が盛んです。中華系ならオフショアでの参入もあります。インド系はオフショアの他に先ほども書いたようなトップレベルのコミュニケーションが「IIT学閥」で出来上がっています。
下請と言う分野と、経営と言う分野に、この2つの国は差し込めているのですね。
では、日本は？と言うと…。です。
狭窄した視野からは、少なくとも○○T-Dataや○士通などの大手IT企業が元気なうちは、まだ財政力で生きていけると思うのですが、どこまで…かな？と疑問を抱いています。寧ろ若い経営者がチャレンジしている小さな会社が早く世界に打って出ていく状況にしないといけないと思うのです。昔に比べ、クラウドファンドやエンジェルなど銀行以外の資金調達が楽になっていることは良いと思っています。更には、大手企業が支援できる体制を取れれば、信用不足なども解消できるはずですし、ローンチするときに重要な市場の把握すら楽に出来ると思うのです。
この当たりは、社内で新規事業を起こすときと全く同じロジックですね。
IT屋の業界団体
時々不思議に思うことがあります。
日本では様々な業界団体がありますがITの分野では聞いた事がありません。
いや、正確には小規模な団体は有りすぎるくらいにあるのですが、業界の意見を取りまとめるような団体は無いのですね。
先日、働き方改革が国会で討議され、その中で高度プロフェッショナルが話題に上がったときに"SEが高度プロフェッショナルに入れば死んでしまう"（意訳）という発言＋ヤジが野党側からありました。これをニュースで見たときに非常な違和感を覚えたのです。
・これではSEがブラック職種としてレッテルが貼られてしまう
・SEの就業環境を悪化させている要因について、まともな論議が行われてきたのだろうか？
・IT業界の大半が労働集約型の産業に位置している以上、SEと言う従業員側だけではなく、商材として使っている雇用者側の問題改善意識は？
とかとかです。
まじめな話、バブル、ITバブルの頃のSEに比べれば、今はかなり時間制約は減ったように思います。特にSESと言う分野が確立するにつれ、時間外労働＝経費増大の幅増大。と言う図式が成立しやすくなったことも一因かもしれません。
その一方でSES契約を結ぶ場合、一ヶ月の稼動時間を幅で契約する事が多いようです。例えば130h/Month〜180h/Monthという感じです。一見フェアに見えるかもしれないのですが、一ヶ月の平均稼働日数を20日と考えると下限で6.5h/Day、上限なら9h/Day。一日の稼動時間を9:00〜17:30とすれば、7.5h/Dayですから一日1.5hの残業=8時終業でもSESの提供社が被る形になります。
ただ、実際には有給や突発的なこと、またゴールデンウィークや季節休暇など下限を下回る可能性もあるため、給与水準を上げないことでリスクのヘッジが行われているものと思います。
更に"ネゴ"の問題があります。SESを行っている場合、いわゆる二次請・三次請と下請がデフォルト化している会社が少なくありません。この場合、お客様から見ると（形式的には）元請会社と下請の区別はつかないのですね。また先ほど書いたような稼動時間の上下限は関係有りません。いわゆる「請負」と「委任」のギャップが明らかになることがあるのですね。SESは委任契約で最大前提は「稼動時間の遵守」です。これに対して請負は成果物の完成にあります。元請が請負の場合、見積の精度が低いとSESの稼動時間は、あっと言う間にショートしてしまいます。こうなると、上限を超えて"追加料金"が発生することになるのです。最近、更に問題が根深いと思うのは元請にとっても契約上は"委任"のプロジェクトが、実質は"請負"状態になっていることです。本当によく聞く話で、この場合、見積は"委任"として精度が上がっておらず、かつ成果物や品質基準がお客様から提示されてしまい、過少見積のままプロジェクトがキックオフされてしまうのですね。この状況だと恐らく「SEが死ぬ」は、概ねTrueな状況だと思います。
特に品質基準や成果物の規定が後から決まってしまうと、それに応じたスキルセットをもったメンバーが参加していないと
・根性で基準や規定に沿った成果物をつくる（努力をする）
・人を追加して規定に沿った成果物をつくる
・諦める
の3つしか道は残っていません。諦めるという選択肢がない場合（笑）、追加予算を計上させる人の追加か、メンバーに努力を強いる根性の2通り。正論ならば人の追加に走るべきですが、
・お客様とのネゴが必要
・力関係でお客様に負ける
・必要なスキルや経験の文書化（Job Descriptionの明確化）ができない
・JDに見合う人を探す時間が必要
と簡単に考えても4つのハードルがあります。恐らく（私の思うヘッポコ）PMや元請IT会社の方は最初のハードル（お客様とのネゴで負ける）を想像した段階で、SEへの根性論という選択に入るのでしょう。
つまり、SEがSEを殺すのです。
これは、例えば運輸業の場合「荷主勧告制度」としてお客様と取引業者の力関係で「無理が通れば道理引っ込む」という契約や業務実態が起きないよう、法整備なども行われています。しかし、IT業界では犬小屋の発注で、出来上がってみたら高層ビルなんて案件もあるのです。いや、犬小屋と聞いていたのに、作り始めたら2階建てのエレベーターつきと言う状況ぐらいですかね。逆に実態として犬小屋しか作った事がないのに、高層ビルを作ろうとする会社もありますが…。いずれにしても『力関係』が余りにも大きく影響する業界なのではないでしょうか？
その結果、人材を潰す、あるいは逃げられるように印象付けられてしまっている状況を打ち破らなければ、やはりSES主体のIT会社は厳しい状況に日々追い込まれていくと思うのです。業界団体でも作って対抗していく必要があるんじゃないでしょうか？
失敗に（も）学べ
最近、少し聞く機会がへったワードに「ベストプラクティス」や「成功事例」というものがあります。一時期は成功事例に沿っていくことが正義のように言われていましたが、私は余り同意できませんでした。というのも、自分が成功してきた道のりの中には、私の個性や経験、また偶然や幸運が積み重なった結果だと思っていたからです。とはいえ、小さすぎて他の人からは見つけられない成功体験だと思うのですが。
さて、前置きとしては、ここまで。私の中で大切にしていることは失敗体験です。同じような失敗ばかりを繰り返していますが、それでも一つの失敗を忘れずに少しでも改善しようとすることが大切だと思うのですね。
プリセールス活動などは失敗の連続です。時にはデモ終了と共にスタンディングオベーションを受けたこともありますが、そんな心地よさは本当にレアな体験です。毎度毎度、冷や汗が脇をつたい、声がかすれ、自社に戻っる道すがら善後策を考える事ばかりに終われます。
ただ、そんな苦い経験から
・得意・不得意
・出来ること・できないこと
が判りますし、必要な説明と不必要な「オーバートーク」の違い。時には「嘘」への自戒も出てくるのですね。
「お前、嘘つきなんだな」と言われても仕方ないくらい、現場で方便と思って話すことは少なくありません。ただ、その嘘が「つきっぱなし」にならないよう、善後策を考えるのです。ここが言ってみれば「並みの嘘つき」と私の違いだと思っています。
その善後策を考える中から、気づかされることは少なく有りません。例えば、Aと言う課題に対して80％は自社製品でできることは判っている。けれど100％にするために
1. 開発に問い合わせ後、20％が不足するなら機能改善
2. とにかく20％は後の課題として誤魔化す
3. 機能改善に廻る可能性が高く、解決まで時間が掛かる予想が立つので、社外製品を検討する
4. 社内で知っていそうな人間を捕まえて質問する
などなどのオプションを考えたとき、2は兎も角、他については何らかのインタラクションが発生します。そうすると意外な解決策が生まれてきたり、あるいは別会社の製品情報を交えて開発と会話することで機能改善が早まることもあるのですね。いずれにせよ、何らかの解決策はオプションから様々生まれてきますし、以前にも書いた「コードに逃げる」様なことや「技術的には可能だが現実解ではないこと」を除外することができるはずだと思っています。
これは、だいぶ前の話ですが、ある会社の製品をコアとした提案を書いていたときです。当時は今よりもセキュリティやアクセスコントロールが煩くなく、そういった観点で評価をしてみると、どうしても機能が足りなかったのです。そこでベンダーから出てきた提案は外部プログラムを組んで機能補完をして欲しいということでした。確かに論理的には可能なのですが、実装するとなるとデータ量の把握も難しいですし、パフォーマンスの不安もあります。まさに「技術的には可能だが現実解ではない」ですし「コードに逃げる」内容と想い、頂いた提案は却下せざるを得ない局面に立たされました。提案の途中で判明した大失敗です。そこで打った手は、兎にも角にも類似した機能を持つパッケージを探し、実装の可能性をお願いしつつ、当初検討していた製品との競合情報の提供もお願いしたのです。つまり、単に機能不全な状況をリカバリーするだけではなく、より良い提案に昇華…といっていいのでしょうか…させる努力をしてみたのです。
で、その結果を修正提案として提示してみました。失敗の想いを引きずっているだけにビビリ加減はMAXです。が、意外に提案先の反応は良く、提案内容に現実味を感じて頂く事ができました。
と書くと「ほら、成功体験ジャン！」と言われるのでしょうが、実際には今でも、特定の製品に対する優位性を兎に角見つけると言う以前に、何が求められる機能なのかを現実に置き換えて提案に反映すること、その内容をベンダーと共有する事が必要だ（当時、それができていなかった）と言うことに尽きるのです。
それが出来て初めて、改善ができるのだと思うのです。
ただ私の場合、同じような失敗が多いので…（汗）
新事業を立ち上げたいなら
さて、では強みの無い会社が何をすべきなのか、私なりに考えているところを書いてみましょう。
やるべきこと
1. みつける
むかし、むかしの流行語に「選択と集中」というものがありました。パナソニックが大胆な改革に入るときに打ち出したスローガンだったと思います。考え方は似ていますが、集中できる分野を見つける事が必要です。
集中できる分野とは、価格競争など不毛な競争状況に陥っていない、勝てる要素のある分野ということです。時に新規事業を検討するというからリストアップされた多様な分野へ幅広な対応をしてしまう会社がありますが、選択を正しく行い、できるだけ集中していく必要があります。そのためリスクや事業計画などを綿密に検討することも重要ですが、一方で迅速な対応も求められます。
2. 修行
強みがあれば修行は必要ありません。しかし、それが無いのですから、修行の期間が必要です。もし外資などベンダーの代理店や提携先を模索するのであれば、プロフェッショナルサービスや営業として形式はともかく出向のような状況をつくり、できるだけOJTの体験をするべきでしょう。
SESの会社では、しばしば「プロジェクトでの体験」を求めるケースが多いのですが、実際にはプリセールスや営業などフロント業務から修行していくことで、要員育成のオーバーヘッドが減らせますし、フロントエンドに携わることで、案件先や市場の意向を汲み取る事ができます。
ただ難しいことは、こういった人材をSES会社では育成しきれていないことです。以前にも書いたように「技術的には可能だが、現実解ではない」提案をだしてしまう人材しか対象にリストアップできないのであれば、受け入れ先とも話をして、矯正していく必要があるでしょう。ただ、これは受け入れ先のソリューションや体制によって変わる所ですが。
3. 組織
初期の組織は小さいほど良いでしょう。最小構成は携わる人間も一緒に考えるべきですが、逆に一人に全てを押し付けてはいけません。小さいことでリスクも小さくなる一方で、将来の組織作りに柔軟性が与えられます。また小さい組織として一定の独立性を持たせることも重要です。この事で、いわゆる「気づき」に素早い対応が可能になりますし、逆に要員は「気づき」を大切にすることができます。ビジネスの立ち上げは当たり前のように当たり前には動かず、実際、計画段階では気づかなかったことが毎日のように、壁となって立ちはだかりますね。この壁を乗り越えるためにも、小さく強い組織を作り、経営が後押しする体制を作る必要があります。得てして経営の方は立ち上げの後は組織に任せてしまう場面を見てしまいますが、むしろ応援することこそ本義なのではないでしょうか？
やってはいけないこと
1. 余剰人員対策
失敗の原因で一番多いのが、携わる要員です。最悪なのは「今、時間のある人間」です。こうなると前述のような修行にも耐えられませんし、将来の組織像も明確になりません。また、こういう形で開始をしてしまうと次に類似のことをやろうとしたときに「俺、不要な人間なのか」と携わる要員がネガティブなマインドになってしまうので、決してやってはいけません。
2. 公平原則の適用
企業は大なり小なり、幾つかの部門に分かれています。そのため公平原則が意識しなくても出来上がっているのですね。全ての組織が平均的に忙しく、平均的に業績を上げているのであれば正しい原則だと思うのですが、一方で、新規事業の場合は平均以上に忙しく、平均以下の業績にしかなっていないはずです。公平性を担保しようと思えば、当然、新規事業の担当者に対する評価はマイナスになってしまいますし、最小化された組織では予算規模も自ずと小さくなってしまいます。この状況では、いざ展開ができ始めたときに広報も人材登用も後手に廻り始めます。もっと悪いパターンは業績が上がるまでは「欲しがりません、勝つまでは」で無理やり『働かされる』状況に追い込まれることです。こうなると、事業がつぶれるどころか大切な要員までつぶすことになりかねません。
3. 感情的な逃避
新規事業を立ち上げる立場、企業では経営層だと思います。精魂傾けて立ち上げたビジネスが花開くことなく終了してしまうこともあります。あるいは諸般の事情でクローズを求められることも。
そういった中で、最悪の閉じ方があります。それは「思い通りに動かない」「思ったより手間暇かかるな」と感情的に閉じてしまうことです。意外かもしれませんが、対外関係などからグダグダしてしまい、論理性のないところで事業をたたむ例を幾つも見ています。その防止のためにも要員には日ごろからキャリアパスも含めた合意形成をする必要がありますし、事業継続のポイントを客観的に把握、そしてできれば共有すべきだと思うのです。
会社の強み
いわゆる失われた20年と言う期間、リスクとコスト投入を避けることで伸びた企業が多かったのではないでしょうか？
その結果、正直、聞いたことも無かったIT会社が上場を果たしています。一方にはECなどITを活用した小さくて小回りの利く会社、もう一方は労働集約型と言うIT市場の特性に乗った会社に大雑把に分類できると思います。
前者は恐らく淘汰や買収・統合による集約が訪れるのでしょうが、基本的に成長の流れにあると思っています。が、後者は正直、厳しいと思うのです。それが、ここまで書いてきたSESを中心とした収益モデルにあるからです。まず従来から抱えている問題として、収益の源泉が「人頭」に依存している事があります。派遣業と同じ構図です。派遣に比してSESの場合、概ねの相場観があり、特に景気後退期には単月費用を値引きの対象にしていまうなど、オフショアの攻勢もあり厳しい環境で生き残ってきました。この点は素晴らしいことだと思います。
しかし、この構造のために社員の給与を上げることは利益率の低下を招きますよね。
オフショアの信頼性や人件費の上昇、また様々な経費から、価格競争には一定の歯止めが掛かったとは思います。しかし、長年、人件費の抑制で培ってきた業績は一朝一夕で急カーブを描けるものではありません。
また、人材の確保も実態は麻痺を起こしているのではないかと思うくらいに問題です。やはり給与、そして働く目的などから優秀な人材ほど中途退社をしてしまっている状況です。彼らにしてみれば市場価値のある間に、他に移った方が良いというのは自明の判断でしょう。その一方で、残った人材を悪く言うわけではなく、やはりSESと言う文化に同質化していく方向になってしまうのではないでしょうか？
ただ、SESが早晩絶滅するとは思いません。一定の需要は常に存在し続けるはずです。しかし、そのパイは小さくならざるを得ない、いやパイに対して大きすぎたのだと思うのです。
従来は事業会社のIT部門の軽量化に伴ってパイが成長してきました。オフショアなどの進出があっても許容可能なレベルだったのだと思います。しかし、その中で「自社の優位性」について真摯に向かい合っていたのでしょうか？
あるSESの会社さんでは、少ないながらもプライムで保守案件などを持っています。その取締役との会話で「うちの強みを活かした提案ってできない？」と気楽に言われてしまった思い出があります。「強み？具体的に例を挙げられますか？」と質問してみると「それが判ってれば、聞かないよ。何でも良いんだよ」と…。
（いや、それ御社の強みじゃないですよね）…。
異口同音とは言いませんが、似たような話はあちこちで聞いた事があるのですが、やはり回答はないのです。良くて「あるはず」です。
私の視界で言ってしまうと、その状況は「無い」です。
国内で元気だなと思うようなIT企業、特にパッケージやSaaSを持っているような会社では、売り出し中のソリューションが過去何年も会社や経営者の経歴に紐付いています。私自身の卑近な経験で考えても、毛色の新しい製品やサービスを担当する時に「やれそうだ」と思えるかどうかは、自分が過去に経験したソリューションとの類似性の有り無しがポイントになっています。汎用機、DBMS、OS、ERP、CRM、ミドルウェア、金融…。恥ずかしいくらいに沢山の分野や製品を経験してきましたが、重なり合う部分が見つけられれば、すぐに立ち上がることができるのですね。
しかし、これは自分が気づかないと経験を活かすまでには至りません。外から「○○と似たようなもんだから、大丈夫だよ」と言われても、いわゆる「腹落ち」しないと（石頭な）私には大丈夫と言えないのです。
先ほどお話を書いた役員さんたちの会社に転写してみても似たようなものかな？と思うのですね。
例えば、取引先のリストと要員展開しているシステムや分野などでマトリックスを作って見ます。そこから、深堀や新規事業の可能性のリストと紐付けをして提示してみた事があります。件の役員さんにはウケます。しかし、役員さんから現場の部課長に見せると反発とは言いませんが「無理」の同義語が山のように出てくるのです。
・あれは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へ、そして現場へ
以前ほどではないとは思いますが、米国では今でも激しい買収活動が行われています。ただ以前ならIBM・Oracleと言うIT屋なら誰でも知っている会社が買い手になっていましたが、最近は「知る人ぞ知る」ような会社が特殊な技術を持つ会社を盛んに買収している印象が強いのです。そういった買収のニュースを見ていたときに「CIOからCMOへ」的な表題を見つけました。上で書いたように、従来ならCIO＝情報システム担当取締役とのコンタクトを重視していたが、アメリカではCMO＝マーケティング担当取締役をターゲットする方向へとシフトしているようです。
この動きは、恐らく既に日本でも起きています。最近、ウォッチしているとあるソリューション業界では、アメリカでもヨーロッパでも「非IT」だった会社や「ニッチなIT会社」が主役になってきているのです。その分野ではIBMもOracleも、現在の巨人であるAmazonもGoogleも一般市場では活躍できていません。恐らく100人にきいて1人か2人「お、知ってる」と言う感じでは無いでしょうか？
そして、その新たな主役が元々持っていたソリューションが優れていた訳ではなく、彼らが持っていた「知見」に見合う新しい技術ベンダーの買収によって強力な存在になっているようです。市場の規模で言えば、基幹システムやプラットフォームといったソリューションには到底敵うレベルにはなりませんが、確実に存在感を見せつけています。日本にも、同様のサービスを提供している小さなベンダーがあるのですが…とても頑張っているのですが…今のレベルでは市場の大きなパイは外資に、そして残ったところが国内ベンダーにというすみわけができるのでは無いかと見ています。
このようなシフト、実際に聞いてみるとIT部門の関与は製品選定が終わった後、あるいは、ほぼ具体的な選定に入った時点と言う状況のようです。こうなると、従来型のIT会社は、もしIT部門からRFPが出たとしても確実に後手になりますし、勝ち目のあるソリューションは提示できないでしょう。
