DBのテーブル設計は「収納問題」である闘うマネジャー(2/2 ページ)

» 2008年07月03日 09時26分 公開
[島村秀世,ITmedia]
前のページへ 1|2       

データ入力作業の考え方の違い

 画面はできあがっているので入力情報は明確だが、職員だけでテーブル設計を進めるのは経験不足もあり、つらい。そこで、職員が画面を見せながら業務の流れをSEに伝え、SEがそれに基づいて提案・協議しながら一緒に設計する協同作業で進めている。職員情報や組織情報など基本となるテーブルはすでに作成されているので、当該システムに必要なテーブルを追加するだけだ。大した作業ではない。テーブル数で6〜7個、A3で3〜4枚程度であることがほとんどだ。大手ベンダー系SEに任せずとも、地元SEで十分対応可能な分量である。なお、SEには最適化し過ぎないようにお願いしている。多少の項目重複より、見やすさ・分かりやすさを優先した方が職員にははるかに理解しやすいからだ。

 テーブル設計の過程で、職員はシステムの利用方法をさらに詰めることになる。例えば業績評価システムでは、評価される本人に対し、誰が第一評価者で、誰が最終評価者か決めておかなければならない。本人の役職によって評価者は大きく変わるし、本庁か地方機関かによっても評価者は異なる。SEに言わせれば「評価者テーブルを用意し、事前にデータ登録してもらはなくては困る」だが、職員に言わせれば「人事課が5000人分のデータを正確に登録するなんてあり得ない。それに、毎年4分の1は確実に人事異動するから、修正作業も膨大だ」となる。

開発時のストレスを軽減したい

 どちらも立場が違うだけで、正論である。そこで、解決策の検討を職員とSEが一緒になって進める。画面デザインの時は、評価者登録画面をとりあえず作っておいただけだが、テーブル設計に入ってみると「これじゃ無理がある。現実的ではない」ということになり、「評価者の初期化ボタンを用意して、事前登録し、必要分だけ手作業で直すスタイルに変えよう」となる。さらに、「評価者の初期化だが、電子決裁の回議データを使ってはどうだろう。回議データと役職コードを使えば、第一評価者と最終価者がほぼ決定されるはずだ」となる。

 さらにテーブル設計書に、「初期情報の入手の仕方」の注記を検討の経緯とともに残しておけば、設計書作成作業に移った時、改めて思い悩む必要がないだけでなく、制御やシステム間フローに注力できるので、設計書作成負荷も軽減される。

 テーブル設計が終わったら、職員は筆者のところに来ることになっている。筆者のところで、項目名をコントロールし、どのシステムでも同じ意味になるようにしているからだ。また、新規にテーブルを作るのではなく、既存テーブルに追加した方が便利な事もあるので、そのような調整も行っている。CIOの仕事とは思えないというのが自然だろうが、あえてやらせてもらっている。調整が手早く済むし、職員も「CIOがOKを出したんだから」と安心できるからだ。

 従来型の開発では、システムができあがってから「評価者を1人1人入れるなんて無理だ。使い物にならない。人事課にルールを提示してもらって、評価者の初期値を入れるように直せ!!」となる。微修正ならSEもアフターケアとして対処可能かもしれないが、このような話は受注側にとってみれば追加開発だ。「営業を通して見積書を出しますので、納得いただければ修正に入ります」と言わざるをえない。ところが、発注側にしてみれば、「システムを人質にとって追い銭の要求か!!」となるわけで、「こんな会社二度と使わん!!」とエスカレートすることさえある。

 先に書いたように、画面設計が済んでいれば、テーブル設計は大した作業ではない。しかも、できあがってから、開発側に「追い銭か!!」と喧嘩を売る事もない。それに、地元SEとの協同作業であるから高価となることもない。発注者として、実施してみてはどうだろう。

関連キーワード

CIO | 人事 | 地方自治体 | オープンソース | スキル


プロフィール

しまむら・ひでよ 1963年3月生まれ。長崎県総務部理事(情報政策担当)。大手建設会社、民間シンクタンクSE職を経て2001年より現職。県CIOとして「県庁IT調達コストの低減」「地元SI企業の活性化」「県職員のITスキル向上」を知事から命じられ、日々奮闘中。オープンソースを活用した電子決裁システムなどを開発。これを無償公開し、他県からの引き合いも増えている。「やって見せて、納得させる」をマネジメントの基本と考える。


前のページへ 1|2       

Copyright © ITmedia, Inc. All Rights Reserved.

注目のテーマ