事業開発/事業再生の大鉄則:SI受託開発だけは絶対に避けろ

事業開発/事業再生の大鉄則:SI受託開発だけは絶対に避けろ

あるいは、この記事は、当サイトの中でも最も大切な記事になるかもしれません。 結論を先に書きます。

SI下請けの事業をやっていると、自社サービスを開発する「筋力」が著しく衰える

私にとってもごく最近まで、この教訓は他人事ではなかったのです。

セブンペイの大失敗から学ぶべきこと

イトーヨーカドーグループが、セキュリティの問題でランチしたばかりの 7pay サービスをたちまちひっこめたのは2019年のことですから、読者の皆様の記憶に新しいと思います。

7pay のことを語ったウェブページ今回ひとしきり跋渉したのですが、事業開発の視点から問題を解説した記事は、私が探した限り、一つも見当たりませんでした。

 

7pay の事業開発からの問題点 その2 SIの委託→再委託

この話のもう一つはらんでいる、大げさに言うと日本経済全体にとって非常に巨きな問題は、この事業自体が大失敗だったにもかかわらず、下請けの中には、間違いなく、

システム開発の売上を立てられ(てしまっ)た

業者が存在した、ということです。なぜなら、一次受けのSIerはともかく、その下請け/孫請けの再委託先は、

PO/Purchase Order/注文書が発行されていれば支払いを受けられる

からです。

この一文、!マークのボックスで囲われている理由、すぐにお分かりですか?

かつての私は、正直言って、こう思ったはずなのです。

支払いを受けられて何が悪いのだ?

日本経済が抱える、構造的な問題:受託のSI

管理人の受託のシステム開発時代の意識

私が大学を出て初めて勤務した会社は、ソフトウェアハウスという当時の言い方が当てはまるような、移動体通信を得意とするシステム開発会社でした。

日本の大手通信機器メーカーが内蔵するシステムを開発する、といった受託の会社でした。

つまりは、

SIの下請け

です。

大手メーカーの工場で連日深夜まで Unix C で営々開発していて、ある朝、通勤時にその工場周辺の河原でゴルフクラブを振っている人を目撃して、強烈な違和感を感じたら、よく考えたら土曜日だった、などということをまざまざと覚えています。

三六協定に引っかかるペースで働いていたため、曜日と時間の感覚がなっくなっていたのです。

当時はこの

いったんPOをいただいてしまい、納品し契約違反になることさえさければ、必ずお金が入ってくる

というビジネスモデルに、何の違和感も感じませんでした。

そのときは、ちょうど世間が2000年問題で沸いていたときで、2000年の正月三が日にも、私は当然のように出社してコーディングしていました。

発注書をもらって契約を締結してしまったのだから、残業して多少健康を壊しても、設計してコーディングしてテストして………と死に物狂いで納品(検収といいますね)まで作業を遂行すべきで、それが開発者の生活だと思っていました。

そして、裏でうすうす思っていたのは、

これだけ苦労したのだから、我々ベンダーは金銭的に報われて当然だ

ということでした。

私は、自社サービスを開発するようになってから、この洞察の異常さに気づかされることになります。

お客様のプロジェクトが大失敗

そんな中、携帯電話端末のシミュレーターの開発プロジェクトにテスターとして参加しました。

人手が足りないので、テスターとして参加したプロジェクトでしたので、私はさほどの残業をせずに済んだのですが、PMの技術主任はときどき徹夜をしていました。

しかし、そのプロジェクトはとん挫しました。

我々シミュレーターの開発が期限通り納品されたので問題はなかったのですが、ある事情で、その携帯電話端末自体が世に出ないことになったのです。

チームの間では、

大失敗をしでかしたお客様の担当者が、責任をとって閑職に飛ばされる

といううわさが流れました。

にもかかわらず、契約書に謳われた期限通り耳をそろえて、すべての機能を納品した我々下請けには、きちんと支払いが行われました。

大きく黒字になったそのプロジェクトは、私の勤務していた社内ではなんと、

成功扱いされました。

すなわち、プロダクトが一度として使用されなかったにもかかわらず、そのプロダクトを製造した側は、当然の報酬を受け取れたのです。

そして何より怖いのは、そのことに、やはり、我々下請けは、寸毫も違和感を感じなかったことです。むしろ、

面倒な保守をしなくて得をした(契約で守られていたため、保守費も所定の額が支払われた!)

と小躍りすらしたのです。

受託先SIは「上流工程」には、本来的に一切かかわれない

思わず赤字で書いてしまいましたが、これが事実です。

SIに関わっている皆さん、直面しましょう。

よく、PMやアーキテクトのロールを担うベテランのSEが

お客様が考えている要件定義はしっかりしていないからこちらが設計視点でお客様の足りないところを補う必要がある

という言い方をします。この「上流工程」(?)に関われるのがSEの本懐とされます。

私が言わんとしているのは、「これはウォーターフォールの考え方だから、今どきはアジャイルでやりましょう」とかなんとかいう、つまらない話ではありません。

よく考えて下さい、たとえば 7payの話で言うなら、

真の上流工程は、セブンペイ社の事業企画に閉じている

のです。

彼らがリーンスタートアップメソッド的に、お客様とかかわったかどうかは外からはわかりませんが、いずれにせよ、7pay の委託先/再委託先/再々委託先が事業企画そのものをひっくり返せる立場になかったのは明らかです。

一次受けのSIですら、7pay のピボット、受託側のサービス企画変更は、契約上、絶対にできないのです。

今回セキュリティの問題で大失敗したコスト上の責任をセブンペイと一次受けのSIのどちらがとったのかは世間に公表されていませんが、世間に対して陳謝したのは、当然、セブンペイです。

しかし、再委託先/再々委託先は、満額出ないかもしれませんが、売上はたっているものと思われます。

でないと、法律違反になるからです。そこがどう考えても、事業開発の視点からは、異常そのものに移るのです。

なぜなら、Lean Startup Methods/リーンスタートアップメソッドをフレームワーク化したエリック・リース氏はが指摘している通り、

顧客(エンドユーザ)に価値をもたらさないべての努力は無駄

のはずだからです。

線形プロダクト開発で世に出した自社プロダクトを誰も使わなければ、間違いなく腹切りもののはずだからです。

ところが、セブンペイから開発を再委託された会社も、かつて私が勤めていたソフトウェアハウスも、

無駄な努力をして報酬をもらった

のです!

受託先SIがかかる業病:事業開発力の衰退

ここで、

無駄な努力をしても報酬をもらえるならそれに越したことはないではないか

とかつての私なら思った、と先ほど書きましたが、万が一私の勤めていた企業が自社サービスを開発しようとしたら、ものすごい苦労をしたはずです。

私自身も、役立たずだったはずなのです。

(その証拠、という訳でもないのですが、かつて私が働いていたそのSI事業会社は、私が辞めた後、退職者を募るまでに一時期困窮しています。)

かつては自社製品を広く世に出して収益を立てていたが、いまはSI事業を収益の柱にしている「メーカー」の方々に

御社の強みは何ですか?

と伺うと、

  • お客様にSI力/カスタマイズ力
  • お客様に最後までよりそう、営業と現場のSEの、システムを完成させる力

とか、まじめな顔しておっしゃいます。

技術的には私とは比較にならないほど優秀な方で、普段から大変な苦労をなさっているのでしょう。

そして、お客様に大いに感謝していただいているのだと思います。

大いにリスペクトしつつも、そこで私が、

システムをカスタマイズして、AWSなみに、何千社に売れるようになったということですか?
かつて皆様方が世に出して大ヒットした○○○とか×××も、そうやって完成させたから、そうして構築なさったシステムも、何もしないで飛ぶように売れているということですよね?

と、しれっと指摘すると、みなさん、「いったいこの男は何が言いたいのだ?」と怪訝な顔をされて黙ってしまわれます。

この記事末尾の「あわせて読みたい」にとりあげた記事の中で指摘した、

弊社のアマゾンにもない強みは、SI力と販路だ。
その証拠に、一緒に動いているアマゾンの営業は、AWSをどこに提案すればいいか知らないで弊社を頼ってくるし、AWSをそのままでは顧客に使わせるようにすることもできない

という、とんちんかんな発言も、このようなやり取りで出てきたものです。

彼らに共通して言えるのは、

事業開発力、ビジネスを組み立てる力が圧倒的に鈍っている

ということです。そして、これは彼らが頭の悪い人間だからでは全くありません。

かつての私がそうであった通り、

真の上流工程である事業開発を全部お客様にぶん投げ、本当の意味での事業の責任をとらないSI受託というスキームがビジネスを考える機会を奪い、能力を衰退させているのです。

彼らは、会社全体がいわば「事業開発ED/勃起不全」にかかっている、その証拠であり、被害者なのです。

事業のことを何も考えないでも勝手に売上がたつスキームでずっと仕事し続けていれば、誰だってそうなります。

自分たちの開発したプロダクトが生み出すはずの価値に責任をとらなくてもいいSI事業は、ワンショットで何百億と儲かろうが、自社プロダクトの開発力を長期では確実に弱める麻薬なのです。

 

イーロン・マスク氏に叩きのめされた”SIerたち”

SpaceXが登場する前は、どんなロケットも、必ず一台一台、個別に開発製造していました。

大手航空産業のメーカーは、ベンダから供与された部品をインテグレーションして、毎回毎回、オリジナルなロケットを新造していました。

スペースシャトルを打ち上げるために使われたロケットですら、そうでした。

そして原理的に、ロケットは文字通りの打ち上げ花火で、一度きりの使い捨てです。

ロケットメーカーは、したがって、利益の構造を不透明にしたまま、NASAなどから巨額の収益を上げることができました。

国民の血税を、ビジネスセンスが毛ほどもなくても、自社の莫大な収益にできるSIです。

マスク氏は一瞬で、これはどう考えても金と資源の無駄そのものだと思いました。

①軌道まで撃ちあがったら、そのあと降りてきて、地上の所定位置に戻ってくるロケットを
②部品から自社で設計製造して、完成品まで一貫して
③量産すれば
コストは圧倒的に安くなるはずだ

このとんでもない発想で、衛星でも何でも宇宙へ運び上げる

宇宙への宅急便

を事業として行っているのが SpaceX です。

SpaceX は料金を公表することで、既存のロケットメーカたちが暴利をむさぼれないようにしてしまいました。

NASAがSpaceX 以外のところに発注しようものなら、たちまち税金の無駄遣いだと後ろ指さされるからです。

かつて Amazon.com がインフラの世界をAWSで「規格化」してサーバの構築を不要にしてしまったのと同じことを、マスク氏はこの単純だが大胆な発想で大規模にやって見せたわけです。

その結果、既存のロケットメーカーの事業は危殆に瀕しています。

日本のSIに関わる皆さん、これと同じ破壊的イノベーションが、皆様方の業界では起こりえないと断言しきれますか?

むしろ、このようなイノベーションを自ら興してやる側になぜ回ろうと考えないのですか?

あわせて読みたい

あなたが興味を持ったトピック あわせて読みたいほかの記事
ピボットとは何か? ピボットとは何か?
Lean Startup Methods/リーンスタートアップメソッドをフレームワーク化したエリック・リース氏 Lean Startup Methods/リーンスタートアップメソッドをフレームワーク化したエリック・リース氏
企業の強みとビジネスモデル 企業の強みとビジネスモデル
弊社のアマゾンにもない強みは、SI力と販路だ 弊社のアマゾンにもない強みは、SI力と販路だ

コメントを書く

送信いただいたコメントは承認後、表示されます。

CAPTCHA