後出しクライアントに糊しろのサプライヤ
まず下記YouTubeをご覧ください。「内情…NHKが日本IBMを提訴、システム開発中止で55億円請求も、IBMの反論文が話題」
https://www.youtube.com/watch?v=OMtV6YUW_qA
この類の騒ぎを耳にした巷の人たちがどのように思うのかから始まって、今までシステムを提供してきたサプライヤと今回更新プロジェクトを受注した会社のどっちに問題があるのか？になって、そこからクライアントの責任はという話に展開していく。そもそも開発するシステムの仕様はどのようなものなのか、そして誰がその詳細を検討して決めているのかというシステム開発にまつわる問題について触れている。
プロジェクトを始める時点でクライアントがしっかりしなければ、サプライヤはしっかりしようがない。日本では、このことの道理を曖昧にしたまま「お客様は神様」といった俗な言いぐさからもったいぶった「顧客満足度」なんてお題目を契約書に明記しようとするクライアントがのさばっている。
YouTubeがシステム開発なんかに関係したことのない一般の人たちにも分かり易く解説している。結果として起きていることがなぜ起き続けているのか、その原因について考えてきたことを列記しておく。
オープニングにある「NHKに提訴された日本IBMの反論が生々しい・・・仕様書に記載ない仕様が満載」は仕事で遭遇してきたこと完璧に合致する。アメリカの制御機器メーカの日本支社でマーケティングとして市場開拓から営業やテクニカルサポート業務に携わっていたとき日本企業やお役所の意識のありように何度も泣かされてきた。ことはNHKだけじゃない。クライアント(企業や行政)のシステム担当部署はプロジェクトに応札してきたシステムサプライヤーに開発しなければならないシステムの機能や性能を詳細に明示する責任がある。何をいくらの予算でという要求を曖昧にしたままプロジェクトを丸投げしておいて、後になってあれこれ思いついたかのように追加の開発を要求しだす。それも一度や二度じゃない。しばしこっちを立てればあっちが立たないという仕様変更が担当部所のあっちからこっちから湧き出てくることさえある。クライアントには開発仕様を自分で考える能力もなければ、自分たちが決めなければならないという認識がない。まるで自分で考える能力がないから、考えるのがめんどくさいから、そして責任を負うのをさけるためにもと、お任せ定食を注文しておいて、いざ提供されると、あれこれ言いだして、あれはこうしろ、これはと言ってくるようなもので、振り回されるサプライヤはたまったもんじゃない。開発が終ったかと思っていたら、唐突に無償で追加開発をしいられるからサプライヤは保険をかけるかのようにてんこ盛りの糊代をつけた見積を出さざるを得ない。高いと値切られても大きな糊代で吸収できる。本当の利益は実稼働後のサポートや改善プロジェクトでごっそり頂くビジネスモデルができあがっている。
立ち位置によって様々な意見があるだろうし、考慮しなければならない現実問題も多いが、問題の根源にまで踏み込めば下記のようにまとめられる。
顧客満足度うんうんは、顧客が開発要求仕様を明示できて、サプライヤはその明示された開発要求仕様を満たす責任があるという契約に基づいての話しで、開発仕様をきちんとサプライヤに伝えられなければ、そもそも契約が成立しない。契約とはクライアントとサプライヤが対等の立場で合意した結果を書類にして残すものなのに、日本には「契約」は上位者が下位者に下賜するものとでもいうかのような思想がある。
開発要求仕様を明示できない顧客は、サプライヤが開発し提供してきたシステムにああだのこうだのいう権利はない。 契約に明記されていない機能や性能の開発や改善は別途契約になる。
ことの背景をいくつか列記しておく。
1) 日本企業は業界標準をさけて、ご同業との差別化で市場で優位に立とうとしてきたし、今もその文化が続いている。 上手い例が思いつかないが、分かり易いたとえとして、エクセルで処理していたのでは差別化できないからと、特注の計算機能を開発しようとするようなものだと考えれば想像がつくと思う。
2) 差別化と真逆にいるのがアメリカ企業のありようで、できるだけ標準化を進めて開発コストと開発時間の短縮化をはかっている。その端的な例がシステム開発環境(典型がクラウドインフラ)の開発競争にある。クラウドインフラと呼ばれるプラットフォームとしてはAmazon Web Services(AWS)、Google Cloud Platform(GCP)、マイクロソフトのAzureがある。これらはクラウドインフラの三強と呼ばれている。ASCIIにクラウドインフラの分かり易い説明がある。
「どれがいい？ AWS、Google Cloud、Azure…3大クラウドインフラを比較してみた」
https://ascii.jp/elem/000/001/239/1239970/
3) 日本では世界市場にシステム開発環境を提供するメジャーが育たない。理由は標準化ではなく差別化に市場優位性を求めるクライアントと、システム開発プロジェクトの価格低下を恐れるシステムを開発する側の企業の保身がある。
ソフトウェアに製造コストはない、あったしても誤差の誤差のそのまた誤差でしかない。あるのは開発コストと販売コストにサービスコストだけといってもいい。一つのソフトウェアを開発して一つのソフトウェアしか売れなかったら、全てのコストをその売れた一つのソフトウェアで回収しなければならない。一つのソフトウェアで限りなく多くの客で使ってもらないと、ソフトウェアの価格がとんでもない金額になってしまう。
システム開発環境を導入してシステムソリューションの開発コストを下げられれば、システム開発企業にとってはいいことばかりじゃないかと思われるだろうが、クライアントもバカじゃない。市場全体が低価格ソリューションに移行して下がった分だけシステムソリューションを提供するサプライヤの実入りが減る。
かつては五億円が妥当と思われていたシステムソリューションが三億円になって、何年もしないうちに一億円を切るなんてことも起きる。まして自社(の費用とリスク)で独自の開発環境を開発しても、競合他社はそんな開発環境を使いやしない。自社だけで使うとなれば、莫大な開発環境開発コスト(アップデートコストも含めた)を回収できない。さらに、開発環境を使用することでシステムソリューションの開発コストが下がればソリューションの価格を値切られる。売値が下がるようなことをするより、いままで通りその都度コードをゴリゴリ書いてプログラムをしていた方が間違いないという判断になる。結果としてソフトウェア産業の生産性が上らずに、いつまで経っても実開発作業は下請け孫請け――四畳半産業のままで、IT土方と卑下される業界構造から脱却できない。
更にグローバリゼーションが進むなかで海外でのサポートをも提供しなければならないとなると大手のシステム開発会社といっても体力の限界がある。その結果としてアメリカのIT企業による世界市場の寡占化が進んでいる。
＜参考＞
2019年8月22日にちきゅう座に掲載して頂いた拙稿
「水道民営化に思う」
2025/3/2