ユーザーがＡＳＰサービス
Ｆ社（建設会社）は、工事現場の協力会社にＡＳＰサービスを提供しています。工事現場はたくさんあって、そのときそのときで変化します。そのたびに出向いたのではプロジェクト管理がままならない。無線ブロードバンドが実用化されたのと、携帯電話の中継局が細かくメッシュを作っているので、それを利用して建設現場の進捗管理を行っているのです。
さきほどお話ししたＤ社（化学メーカー）の指揮を取った方は、ＩＴの専門家ではありません。元は工場の現場のリーダーで労働組合の書記長でもありました。叩き上げの方です。その方がいまは執行役員とおして情報システムを統括しています。
Ｆ社、Ｄ社、九州の某県の事例は、これまで情報サービス産業にシステムを発注する、つまりＩＴ調達に徹していた企業や自治体が、同業他社や取引先に自社開発のシステムを共通基盤として提供し始めているということです。情報サービス産業が本来やるべきことをユーザーがやり始めている。ユーザーとＩＴサービス業の境目がグンと日聞きなっています。
その背景をもうちょっと細かく見ると、先ほど申し上げたように、基幹系システムはずっとメンテナンスフェーズでいい。コストを固定化する。その仕事は外注にまかせておく。その代わりフロント系を戦略化する。そこは自分たちでキッチリやる。
フロント系というと、わかりやすいのは窓口業務や現場のOA系ですが、この部分にＣＲＭとかサプライチェーンマネジメントを追加するとかいう話ではなくて、現場の一人ひとりが自分たちがいま何をやっているのかきちっと整理することからスタートさせています。
フロント系の戦略化 実はＩＴの話ではない
フロント系の整理、戦略化というのは、実はシステムの話ではなくて、現場に立つ一人ひとりが自分たちはどういうことを、何のために、どういう手順でやっているのかということを整理して、それをシステムに取り込んできている。その作業に３年ぐらいかけています。その間にＩＴ部門はでータの整理を進めました。あちこちにサーバーが乱立していて、データ構造がバラバラだったので、それをちゃんと一元化しましょう、と。
並行して実施したのが組織と業務の見直しです。
ＢＰＲ（Business Process Reengineering）というやつです。われわれが記事で「これからはＢＰＲだ」と書いていたのは１０年ちょっと前ですが、ユーザーが実施するには５年ぐらいかかります。２０００年問題との絡みということもあるでしょう。同じようにＩＴ調達の一元化というものも、このころに体制作りをやっています。
■現場参加型で要求仕様を作る
要求仕様の作成は、それまでは情報子会社に外出しするか、要求だけ言って定義は専門会社にやらせる丸投げでしたが、要求仕様そのものを現業部門参加型でやる。現場の方に来てもらって、ないしは現場に自分たちが出向いてヒアリングして、ないしは現場で議論させる。
先ほど言った団塊世代からのノウハウの継承ということもあって、これから引退していくであろう５０代後半の方々と３０代の若手がチームになって、こういうときはどうしていたのか聞く。そういうことに現業部門が参加していく。
そのときに、情報システム部門がやっているのは社内の共通基盤作りです。われわれはすぐに開発標準から行きます。開発標準から始めて、最後に来るのが運用ですが、ある化学メーカーが最初に手がけたのは運用標準でした。社内共通基盤を運用からスタートしています。
運用でトラブったらアウト、という発想です。だから運用標準から作って、その運用標準に対応できる開発標準まで落とし込んでいます。その開発標準を実現するための設計方法論を自分たちで作るかどこかから持ってくる。
ＳＩだのソリューションだのは信用しない
契約の見直しというのは当然起こってきます。先ほどのお話の中にもありましたが、私どもが取材した範囲では、いわゆる設計フェーズと開発フェーズというものを分ける傾向が見えました。設計フェーズについて、「そんなもの外部にやらせられるか」という声を聞きました。
「システムインテグレーションだのソリューションだのと言う企業ほど当てにならない」という非常に手厳しい声を聞いたこともあります。意見が合ったので、取材そっちのけで盛り上がることもありました。自分で要求仕様を作らないで、どうして新しいビジネスモデルを作れるんだということです。
それこそ自分たちの命ではないか。なのにそれを外に出すなんてできるわけがないだろう。だから、少なくとも要求仕様を固めるところまでは自分たちでやる。要求仕様のもう一つ下の詳細設計のレベルで初めて情報子会社を参加させる。ものづくりについては外に出す。
それは構わない。ただし、プロジェクト管理は全部自分たちでやる。なぜかというと、システムトラブルが起こったら全部終わってしまうからだ、と。その責任を取れないようでは、ガバナンスもコンプライアンスもない、ということです。それが経営トップからの要求になってきている。
■次に起こるとは外注の見直し
そうなると当然ですが、外注の見直しということも起こります。特に多重下請けと多重派遣の問題です。１人親方、偽装請負、二重派遣については共通して、原則も例外もなくダメ。
下請けへの再委託について共通していたのは２次請けまでです。情報子会社は身内なので、そこから先の１次、２次まで。たとえば情報子会社がコンピュータメーカーに発注して、パートナーの情報サービス会社に再発注されたら、そこから先はダメ。それについてはかなり厳しかったです。
どうやってそれをチェックするんですかと尋ねたら、「面接します」という答えでした。ＣＩＯが「一人ひとり、私が面接します」と。それをやると派遣法で問題になりませんかと言ったら、「自分がやるのは面接するだけで、決めるのは情報子会社。それに自社のシステムに責任を持つのが自分の仕事」とも言っていました。業界に対するかなり厳しい見方だなと思います。
なぜその方が１人ひとりのエンジニアを面談するかというと、以前、すごい腕のエンジニアが来て素晴らしく効率のいいプログラムを作った。ところが普通のエンジニアではメンテナンスができない。発注先にそのエンジニアを出してくれと頼んだら、４次請けの会社から多重派遣できていた人で、行方が分からなかった。「それに懲りたんだ」ということでした。
立ち位置次第で「ＩＴ」の意味が違う
それからＩＴの意味合いが変わってきたな、と感じました。
われわれはＩＴを「Information Technology」と思っています。あえて同じ「ＩＴ」に置き換えると、ユーザーの現業部門からすると、単なる「Information Tool」です。ＩＴ部門にとっては「Intelectual Technique」であって、課題解決の手法、手段にすぎません。課題を解決できるのなら、コンピューターでなくても構わない。
たとえば化学工場のプラント制御です。有機化合物が流れるパイプを制御するのは、コンピュータだけではない。ネジの締め方とかパイプの振動や熱とか、それは人間の感覚が大事なんだと。そのためにパイプの振動や熱さを体験させるダミーの小さなプラントを作っている。情報システムの中にヒューマンなファクターを入れてきています。それは現場の方がシステムを作って運用するからです。
経営部門にとってのＩＴは「Innovation Transfer」、事業の改革を具体化する道具、方法論でしかありません。われわれが言っているコンピュータ、ネットワーク、ソフトウエアというものを意識してＩＴと言っているのではないんですね。
いまやInformation Technologyは二の次です。企業のあり方、企業のコンプライアンス、企業の事業継続性を実現する方法は何か。それがテーマになっている。
