TOP
＞
システム開発
＞ 手当システム 〜 分割発注のプロジェクト
ながさきITモデルへの参画 〜 地場SIerの官公庁システム開発奮戦記
第３回：上流工程に携わることによる、本当の意味での下請けからの脱却
著者：
ドゥアイネット 穴井 春奈
2006/5/10
前のページ
1
2
3
次のページ
手当システム 〜 分割発注のプロジェクト
そんなある日、長崎県庁から当社に仕様書作成の業務依頼がされ、筆者にも上流工程に参加できるチャンスがやってきた。筆者が担当するシステムは手当システムといい、県庁職員の手当届の要・不要をシステム側で判断して申請するというシステムだった。
手当システムでは開発はもちろん、仕様書作成段階から分割発注するということだった。早速県庁の担当者である今冨氏と打ち合わせを行い、データベース設計から取り掛かったが、当社の前田がかつての休暇システムで感じたように、筆者も自分の業務知識の低さに気づかされた。手当に関する業務用語が多くあり、その用語の意味自体を理解していかなければ設計することができない。ただ、ひたすら勉強していくしかなかった。
仕様書作成段階から分割発注するということなので、仕様書作成は一般ユーザ入力機能のみを対象とする。「（1）基本情報の入力部分」「（2）各詳細情報の入力部分」の大きく2つに分け、当社ともう1社で書き上げていくことになった。当然、（1）と（2）の連携処理の仕様も検討する必要があり、仕様書を作成する2社同士の意思疎通が大切になってくる。今冨氏、他社SE、筆者の3人で打ち合わせを情報政策課内で頻繁に行った。
本来システム設計はシステム全体のことを常に考えながら、一部分への影響や連携について検証していかなければならない。設計は1人の人間、もしくは同じ会社で完結して作成するのが望ましいだろう。だが今回はシステムのボリュームと納期との関係もあり、分割してシステム設計をしていくことになったのだ。
開発を分割するデメリットとして、システムの全体像が見えにくいことを冒頭にあげたが、これは開発だけに限ったことではなく、設計にもいえることだろう。筆者はデータベース設計から携わったが、もう1社のSEは入力部分のみの設計だったので、なかなか見えない全体を捉えながらの設計だったはずである。
機能分割数が多い大規模システムでの注意点
図2のようにこれだけの大きなシステムになるということは、機能分割する数も多くなる。つまり、開発に携わる企業の数も増えるということだ。当然、基本設計の段階から、数社が開発する上で問題となる点などを洗い出す必要があった。
図2：手当システム概要
（画像をクリックすると別ウィンドウに拡大図を表示します）
そこで各社で作成する機能をパッケージ化し、パッケージをロードすることでアプレットが動く仕組みを考えた。また、すべての画面に共通となる部品は必ず発生するので、共通で使用するための部品を作る必要があった。
図3：手当システム概要
前のページ
1
2
3
次のページ
「長崎県スケジューラー紹介」
ドゥアイネットでは、リッチクライアント言語を使ったスケジューラーを開発致しました。直感的な操作性とストレスを感じさせない処理スピードで、事務の効率化とコストダウンを実現しています。デモサイトが公開されていますので、ぜひ一度お試しください。
機能詳細はコチラ（実際に体験できるデモサイトをご用意しています！）
http://www.doinet.co.jp/activity/scheduler/
著者プロフィール
株式会社ドゥアイネット 穴井 春奈
システム技術部2課 チーフ。
前職は一般事務。もっと自分にしかできない仕事をしたいという思いから転職を決め、ドゥアイネットに入社して4年。現在は長崎県電子自治体プロジェクトに携わり、設計から開発までをこなす。
INDEX
第3回：上流工程に携わることによる、本当の意味での下請けからの脱却
ITモデルのデメリット
手当システム 〜 分割発注のプロジェクト
できあがった完成品の使い回しのメリット
