システムの設計書を県庁の職員が自ら作成し，小さな単位に分割して入札にかけ，さらにオープンソース・ソフトウエアを採用することでコストを削減，同時に地元のIT企業を育成――「長崎ITモデル」とも呼ばれるこの方式により，システムのコストは半減したという。また従来はほとんど中央の大手企業が受注していたが，現在は地元企業が半数を占める。
2003年6月から，MySQLやPHPを使い文書管理システム，電子決裁システム，年次休暇システム，電子申請システムなどを稼働させ，サーバー全体の6割以上，40台近くがLinuxになっている。
この改革を推進したのが，日本総合研究所から長崎県のCIO（Chief Information Officer)として出向した島村秀世氏である。自治体システムの改革は，当然のように当初様々な抵抗に迎えられた。島村氏は「土日もなく」自ら仕事を進めて実績を積み上げ，業務と職員の意識を変えていった。（聞き手はIT Pro編集 高橋信頼）
――なぜオープンソース・ソフトウエアを使うのですか。
 |
| 島村秀世氏 |
商用ソフトは資金がない地元企業に不利
オープンソースは，システムのコスト削減策としてよく用いられますが，地元企業が仕事を受注するためにも必要なんです。商用ソフトウエアは，講習を受けて，自ら購入し試用して初めて使えるようになります。ITゼネコンとも呼ばれる大手は資金が豊富なので，技術者を講習会に行かせることができます。一方，地場のIT企業は資金に余裕がないので，そんなことはできません。結局大手の下請けに入って仕事をすることが多くなります。ソフト産業といっても，資金がなければ駄目だと言われているようなものです。それなら，無料で手に入るオープンソースを使えば地元企業も仕事に参加できるのではと考えました。しかし，味方と思っていた県職員から思いもよらない不満が寄せられました。「そんなものを使っていいんですか？」，「誰が責任を取るんですか？」という声です。しかしそれは「メーカーに丸投げすれば楽なのに，なんでそんな苦労を背負い込むんですか」ということを暗にほのめかした声でもあったと思います。
県職員にしてみれば当然の話です。各省庁から上司としてキャリアがやって来ても，数年たてば帰る。そのうちいなくなる人のためにリスクは冒せない。適当にあしらいつつ，指示に従っているふりをしながらも無難な方向に向けた方が合理的だしはるかに楽です。信頼関係がないのに無理を言うなってことなのかも知れません。
この関係を正すには，自分が汗をかくしかないと考えました。
最初に，プロトタイプ的な小さなシステムをオープンソース・ソフトウエアを用いて作成し，問題なく動くことを証明することから始めました。もちろん設計書を自ら書きました。やらせるんじゃなくて，やって見せるしかなかったんです。この当時，私に土日はありませんでした。自分でも「なんて馬鹿なことをやってるんだろう。大人になれば楽なのに」なんて考えたこともあります。
でも，発注のあり方を丸投げから，主体的な開発へと変えるにはこれしかないと，のめり込むように設計書を書いてました。
――ユニークな設計書の作成方法は，どのようにしてできあがったのですか。
私は28歳くらいに，SEとしてのキャリアを始めました。建設会社からシステム会社へ転職したんです。
建設では許されない設計書が当たり前のIT業界
その当時感じていたのが「システム屋なのに，設計書がいいかげん」ということです。なにしろ，プログラムと一致していない。不具合があってプログラムを直すが，それが設計書に反映されない。必ずと言っていいほど，ずれているわけです。特に詳細設計書は書き直すの大変だから放置したままで，ウソの設計書になっていることが多かったように思います。建設会社の時はそんなこと許されませんでした。
システム開発の教科書には「要件定義はしっかり書け」とあります。しかし，要件定義書が文字だけなんてこと多くありませんか。文字だけのようなあいまいな方法で要件が正確に伝えられるわけがない。
発注する側はシステムの素人です。受注する側は業務の素人です。システムの素人が，業務の素人にシステムの要件を伝えるわけです。文字だけなんて変ですよね。マイホームを建てるときは，間取り図を前に打ち合わせします。情報システムを作るときも，画面イメージくらいは必要ですよね。
そこで，そもそもシステムに必要なのは，「画面イメージ」と「データベース・フォーマット」と「システム間連携」ではないかと考え，次のような手順で仕事をするように変えました。
まず，仕事を任せた担当職員に，簡単な画面イメージを書いてもらい，仕事がどのように流れるのか自分なりに考えてもらいます。そしてできあがった画面イメージをWebデザイナのような方にお願いしてきれいな画面イメージにしてもらいます。そして改めて担当職員に推敲してもらいます。
推敲に際しては，関連する職員や部門などと相談しながら行ってもらいます。きれいな画面イメージなら，相談される人に親切だし理解も早い，工夫すべき点も見つけ易くなります。そして推敲した結果を踏まえデザイナに画面イメージを仕上げてもらいます。
次に，画面イメージを基に必要な項目を考えデータベース・フォーマットを設計します。馴れてきたら担当職員が設計しますが，基本的にはSEの方にお願いします。画面がしっかりしていますからデータベース設計はそれほど難しくありません。ベテランのSEでなくてもできる軽易な作業です。
最後に，画面イメージとデータベース設計を踏まえ，システム間連携までがきちんと書かれた設計書の作成をベテランのSEにお願いします。
今までのやり方は，最初から全部SEに委託してしまいますが，私のやり方では3人のプロにそれぞれの専門性を活かした仕事をしてもらっています。また，それぞれのプロには事前の整理が済んだ段階で仕事してもらってるので，段取りや質疑に時間をとられないというメリットもあります。
画面イメージを基にシステムを自然に理解可能に
もうお気づきですよね。この手順で仕事を進めれば，今まで「設計書なんてとても理解できない」と言っていた職員が，自然と設計書全体を理解するようになります。わからないと思っていたものが，だいたいこんな感じだと分かるようになります。先の話で言えばマイホームのイメージがばっちり頭の中にできあがるんです。やればできるんです。やればできるのに，なぜこれまでやってこなかったのかというと，「丸投げ意識」があったからだと思います。「責任を取りたくない」「誰かに押し付けたい」という意識です。
そういう「丸投げ意識」を変えるには，業務を分割することです。担当者が1人で無理なく携われるサイズに業務を分割して，何をすればいいのか悩まないようにしてあげる。そうすれば，先に示した手法で自然と本人が関与するようになります。また，例え失敗して，やり直すようなことになってもサイズか小さければ費用は大してかかりませんから，思い切ってやれる。
「分割するとかえって非効率になる」という意見もありますが，分割数が中途半端だからだと思います。私の経験では，一つの業務システムのサイズは，大きくても1000万円以下にした方が確実でいい仕事となっています。
――ベンダー側からの抵抗はありませんでしたか。
もちろんありましたよ。
