|
必聴講座ご紹介 Cloud Days Tokyo 2012 エムオーテックス Cloud Days Tokyo 2012 ヴイエムウェア Cloud Days Osaka 2012 アマゾン データ サービス ジャパン |
|
![]() |
| 島村秀世氏 |
それなら,無料で手に入るオープンソースを使えば地元企業も仕事に参加できるのではと考えました。しかし,味方と思っていた県職員から思いもよらない不満が寄せられました。「そんなものを使っていいんですか?」,「誰が責任を取るんですか?」という声です。しかしそれは「メーカーに丸投げすれば楽なのに,なんでそんな苦労を背負い込むんですか」ということを暗にほのめかした声でもあったと思います。
県職員にしてみれば当然の話です。各省庁から上司としてキャリアがやって来ても,数年たてば帰る。そのうちいなくなる人のためにリスクは冒せない。適当にあしらいつつ,指示に従っているふりをしながらも無難な方向に向けた方が合理的だしはるかに楽です。信頼関係がないのに無理を言うなってことなのかも知れません。
この関係を正すには,自分が汗をかくしかないと考えました。
最初に,プロトタイプ的な小さなシステムをオープンソース・ソフトウエアを用いて作成し,問題なく動くことを証明することから始めました。もちろん設計書を自ら書きました。やらせるんじゃなくて,やって見せるしかなかったんです。この当時,私に土日はありませんでした。自分でも「なんて馬鹿なことをやってるんだろう。大人になれば楽なのに」なんて考えたこともあります。
でも,発注のあり方を丸投げから,主体的な開発へと変えるにはこれしかないと,のめり込むように設計書を書いてました。
――ユニークな設計書の作成方法は,どのようにしてできあがったのですか。
私は28歳くらいに,SEとしてのキャリアを始めました。建設会社からシステム会社へ転職したんです。
その当時感じていたのが「システム屋なのに,設計書がいいかげん」ということです。なにしろ,プログラムと一致していない。不具合があってプログラムを直すが,それが設計書に反映されない。必ずと言っていいほど,ずれているわけです。特に詳細設計書は書き直すの大変だから放置したままで,ウソの設計書になっていることが多かったように思います。建設会社の時はそんなこと許されませんでした。
システム開発の教科書には「要件定義はしっかり書け」とあります。しかし,要件定義書が文字だけなんてこと多くありませんか。文字だけのようなあいまいな方法で要件が正確に伝えられるわけがない。
発注する側はシステムの素人です。受注する側は業務の素人です。システムの素人が,業務の素人にシステムの要件を伝えるわけです。文字だけなんて変ですよね。マイホームを建てるときは,間取り図を前に打ち合わせします。情報システムを作るときも,画面イメージくらいは必要ですよね。
そこで,そもそもシステムに必要なのは,「画面イメージ」と「データベース・フォーマット」と「システム間連携」ではないかと考え,次のような手順で仕事をするように変えました。
まず,仕事を任せた担当職員に,簡単な画面イメージを書いてもらい,仕事がどのように流れるのか自分なりに考えてもらいます。そしてできあがった画面イメージをWebデザイナのような方にお願いしてきれいな画面イメージにしてもらいます。そして改めて担当職員に推敲してもらいます。
推敲に際しては,関連する職員や部門などと相談しながら行ってもらいます。きれいな画面イメージなら,相談される人に親切だし理解も早い,工夫すべき点も見つけ易くなります。そして推敲した結果を踏まえデザイナに画面イメージを仕上げてもらいます。
次に,画面イメージを基に必要な項目を考えデータベース・フォーマットを設計します。馴れてきたら担当職員が設計しますが,基本的にはSEの方にお願いします。画面がしっかりしていますからデータベース設計はそれほど難しくありません。ベテランのSEでなくてもできる軽易な作業です。
最後に,画面イメージとデータベース設計を踏まえ,システム間連携までがきちんと書かれた設計書の作成をベテランのSEにお願いします。
今までのやり方は,最初から全部SEに委託してしまいますが,私のやり方では3人のプロにそれぞれの専門性を活かした仕事をしてもらっています。また,それぞれのプロには事前の整理が済んだ段階で仕事してもらってるので,段取りや質疑に時間をとられないというメリットもあります。
やればできるんです。やればできるのに,なぜこれまでやってこなかったのかというと,「丸投げ意識」があったからだと思います。「責任を取りたくない」「誰かに押し付けたい」という意識です。
そういう「丸投げ意識」を変えるには,業務を分割することです。担当者が1人で無理なく携われるサイズに業務を分割して,何をすればいいのか悩まないようにしてあげる。そうすれば,先に示した手法で自然と本人が関与するようになります。また,例え失敗して,やり直すようなことになってもサイズか小さければ費用は大してかかりませんから,思い切ってやれる。
「分割するとかえって非効率になる」という意見もありますが,分割数が中途半端だからだと思います。私の経験では,一つの業務システムのサイズは,大きくても1000万円以下にした方が確実でいい仕事となっています。
――ベンダー側からの抵抗はありませんでしたか。
もちろんありましたよ。