外字やマクロ、フラグが問題
ユーザーに責任の一端が
情報システムのリプレースには、データとアプリケーションのコンバージョンが付いて回る。地方公共団体は部門ごとにデータフォーマットが異なり、特殊文字を使い、そのうえ隠しコマンドが埋め込まれていることもある。そうした事情から、リプレースで成約したSIerが“想定外”の事態に陥ることも少なくない。脱レガシー／電子自治体のかけ声は勇ましいが、自治体にユーザーとしての責任が問われている。（佃均（ジャーナリスト）●取材／文）
■続出する想定外の損失
電子自治体市場で不採算プロジェクトを抱えたのは、前回登場の日立情報システムズに限らない。NTTコミュニケーション、インテック、アイネス、オーイーシー、日本電子計算……。
表立って取りざたされない企業にも、多かれ少なかれ不採算案件は発生している。背景にあるのは、自治体の数が減る危機感に刺激された激烈な受注競争だ。なおかつ契約書では、トラブル発生時の対応や責任の所在について、「両者協議のうえ取り決める」と曖昧な表現にとどめることが少なくないこともトラブルの種になっている。
不採算プロジェクトを抱えた当事者から、「身の丈以上の無理がたたった」「フタを開けたら想定外の労力がかかってしまった」等々、繰り言に近い言葉が飛び出す。しかし発注者と受注者の力関係から、「ユーザーにも責任がある」とは口に出せない。
NTTコミュニケーションズは岐阜県の電子県庁システムで大失態を演じたが、同時期に同様のプロジェクトを進めていた静岡、愛知、三重の3県では予定通り運用フェーズに移行することができた。岐阜県のケースについては、「コンサルタントとして入ったアクセンチュアの不手際」を指摘する声がある。
オーイーシーが撤退せざるを得なかった青森市の場合も、発注窓口となった第三セクターのソフトアカデミー青森、コンサルタントを務めたタタ・コンサルタンシーの不定見さが第一の原因だった。「受託」という立場、また「言われた通りにやっていればいい」という意識が、アラームを鳴らそうとする情報サービス会社の発言を抑え込んでしまう。
プロジェクト推進体制の不備だけではない。もつれにもつれたスパゲッティのようなプログラムとデータ構造だ。加えて、いつ、誰が、どのような改良を加えたのか、どのようなプログラムを組み込んだのか、ドキュメントが残っていない。地方公共団体は「職務機会の均等」という原則があるため、“生き字引”的なベテランがいないのだ。
■データ構造すら不統一 SIerのアイネスは2年前、通期の当期利益見通しを黒字から赤字に修正した。その証券アナリスト向けの会見で、「いくつかの自治体のシステム開発で、想定外の労力がかかってしまった」と林代治社長は弁明した。質問がなかったこともあって、林社長もその詳細な理由をあえて語ろうとしなかった。
当時、同社は横須賀市、町田市、立川市、八潮市といった首都圏の中堅都市から相次いで電子自治体システムを受注していた。その切り札だったのはWeb対応の統合システム「WebRings」だ。同社はその後も約70件の新規受注を獲得しているので、WebRingsに問題があったとは考えにくい。
同社の関係者に聞くと、「民間企業では考えられないことが、自治体ではごく普通に行われている」という答えが返ってきた。地方公共団体は部門ごとに、組織ばかりでなく予算執行も縦割り。情報システムも部門ごとに発注され、相互運用性が保たれていないのだ。
端的にいうと、委託先が異なるので帳票用紙や周辺機器の購入価格もまちまち、OSやデータベースシステムの統一も図られず、データの構造もバラバラ。保守運営を委託先に丸投げしているため、その場しのぎのパッチやマクロ、フラグが付け加えられていることも、当の自治体が知らない。
特に、専用に作った外字と例外処理のためのマクロとフラグがクセモノだ。リプレース後、日常業務は円滑に運用できても、課税額通知書など年に1回か2回のバッチ処理のときトラブルが表面化する。深く静かに潜行していて突然姿を現わし、収拾がつかない。佐賀市で発生した国民健康保険料・税徴収額通知書処理のトラブルもそれだった。
栃木県の芳賀町は利用システムを地元TKCから群馬県のジーシーシーから切り替えた。ともに窓口業務系はWindowsベース、センターはメインフレーム系だったが、住民の氏名、住所にかかわるデータ移行に当たっては、住民課のベテラン職員が数回にわたってすべてを確認しなければならなかった。
情報化推進計画に基づいて着実なプロジェクトを進めていることで知られる埼玉県のある町は昨年、電子化の第三フェーズとしていよいよ行政手続きの電子化に着手しようとした。そのためには各部門が使っているデータの構造を標準化しなければならない。コンピュータ処理にかかる氏名や住所の順番やカラム数、フラグの立て方などを共通化しようとしたのだ。ところが──。
「原課にいくら尋ねても、データ構造を知っている人がいない。IT担当部門で解析しようとすると、原課は強く抵抗する。職権や職務を侵害されるというような意識があるんです」
結局、その町ではデータ構造の標準化を断念した。部門間に無用な軋轢を生むことを懸念したためだ。もし、この状態でアーキテクチャが異なるシステムにリプレースしようとすれば、受託した情報サービス会社に大きな負荷がかかるのは目に見えている。
■スパゲッティ・システム 東京・用賀に本社を置くアトリス。従業員70人ほどのソフトウェア会社だが、この会社が大手コンピュータメーカーの上位に立って、システム設計とプロジェクト管理を担当していることはほとんど知られていない。つい最近も大型リプレース案件を年10億円規模で受注している。
「かつてはプログラムのスパゲッティ状態が大きな問題とされた。ところが、この10年のサーバー乱立で、システムがスパゲッティ状態に。データとアプリケーションが同期しておらず、システムリソースに無駄が発生している」
と安光正則社長は指摘する。
長年の運用過程で、プログラムを改造し、パッチを当てることは日常茶飯事だが、ドキュメントを残さず、システムをスパゲッティ状態にした責任はユーザーにある。電子自治体プロジェクトで発生した不採算案件の何割かは、本来ならユーザーが負うべき責任を受託会社が背負ったケースだった。
電子自治体のシステム構築は今後も続く。自治体に特有な縦割り組織と予算執行、情報システムの丸投げといった体制が改まらなければ、情報サービス会社の不採算プロジェクトは根本的には解決しない。
