情報を共有する仕組み

本ブログのテーマとしているSalesTechは、主には営業、マーケティング部門における情報共有がベースです。

 

部門内だけでなく、関係する全ての部門で情報を共有することが重要であることは言うまでもないものの、HubSpotさんの調査によれば、日本国内に於いて、

CRMを導入している営業組織の割合は36.1%と、微増しながらも依然として低い数字

となっています。

 

これには理由があるのですが、それは別の機会に書くこととして、今日は、敢えて元々のテーマを外れ、昨今話題のマイナンバーカードの障害における、

情報を共有する仕組み

について考えてみます。

 

2023年8月3付けの日本経済新聞の電子版において、

混乱マイナンバー3
まさにスパゲッティコード

と題する記事が掲載されていました。

 

気になったのは、

富士通は高負荷環境下で起きる不良など一部のプログラムミスだけを改修していた。現場が把握する不良は複数あったが、富士通全体で共有する仕組みがなかった。

の内の、い部分です。

 

正に「情報を共有する仕組み」に問題があったとのことですが、これだけ読むと、

ならば、全国の現場で起こっている不良箇所の情報を
一か所に集めて一つ一つ潰して行けばよいのではないか?

と思われるでしょう。

 

でも、その通リにはならないのです。

 

今から相当前のことです。

 

某ユーザーのシステム更新に伴って、私が所属する部門の製品と国産X社が開発したシステムを相互運用することとなりました。

 

それぞれのインストールが終わり連携のテストが上手く行きません。

 

夜遅くまで現場で調べたところ、どうもX社のシステムの仕様の不備が原因であることが分かりました。

 

そこで、当面は手入力を併用して両システムを稼働させ、X社のシステムの改修後に再テストということになりました。

 

ところが、その後、X社からは何も言って来ません。

 

結局、そのままの状態が続き、加えてユーザー側の担当者が転勤になって、再テストも有耶無耶になりました。

 

それから、暫くしてのことです。

 

或る会合で同席したの元X社の友人に、事の次第を話したところ、こんな返事が返ってきました。

 

X社では、開発作業が社内で行われること自体が少なく、開発部門の担当者は仕様を書くのが仕事で、開発作業そのものは大抵は子会社、或いはその下請けが担っている。

 

その友人は、たまたまX社内でも近い部門にいたから事情を知っていたようなのだが、先のシステムは、業務そのものが子会社に丸投げだった。

 

そして、その子会社の担当者もユーザーの業務内容の理解に乏しくて、頻繁に仕様変更を繰り返したようだ。

 

一方で、実開発作業は、更なる下請け会社に派遣されてきた技術者チームが担当したが、派遣会社の都合で技術者メンバーが何回か変わったし、挙句の果てに、その派遣会社自身が潰れて技術者の行き先も分からなくなった、という経緯があったようだ。

 

そんな製品の納品立ち合いにユーザー先に出向くフィールドSEも別の子会社の社員だが、現場で何かを指摘されても「本社に伝えます。」と言うのが生一杯だ。

 

というのも、システムトラブルが発生した場合には、利用環境や再現性を確認した上で詳細な報告書を上げなければならない。

 

ただ、仮に報告書を上げても必ずしも改修されるわけでもなく、再調査依頼がかかったり、或いは大抵の場合、「運用で逃げる方法を提案して来るように」とか「現場でなんとかしてこい」と指示されたり、場合によっては理由もなく怒られることもあるらしい。

 

このような場合、

  • 開発担当:全体~詳細迄把握している担当者が不在だし現場を気にしない
  • 現場担当:面倒になることが分かっている場合は報告書を上げない

となり、「情報を共有する仕組み」を作ってトラブルの解決にあたることもありません。

 

勿論、今回のマイナンバーにおいても同様だとは言いません。

 

ただ、必ずしも

全体で共有する仕組みがなかった。

だけの問題ではないことを指摘しておきます。

 

冒頭に書いた「営業、マーケティング部門における情報共有」が進まない理由が同じだとは言いませんが、何某かの根本的な理由が別にある場合が多いのです。

 

それと余談ですが、「マイナンバー」というネーミングも良くありません。

 

何時の時代も管理されることを嫌がる人たちがいます。

 

マイナンバーと聞いて、かつての「国民総背番号制」への抵抗感、拒否感を持つ人が少なくないのです。

 

ですから、例えばアメリカのような「社会保障番号」に名称変更して、個人を守るイメージに転換さえればよいのだと思います。