オブジェクト指向型開発ツ−ルを利用したパッケ−ジシステムの構築
(PDF文書,622KB)


【要旨】

1.はじめに
地方自治体における福祉関連業務は高齢化、少子化問題が叫ばれる昨今において介護保健制度の創設にみられる通り、激変の時を向かえている。
また、地方財政の悪化によるコストの削減や行政の住民に対するサービスも量、質共に今まで以上に強く求められているところである。今回対象としている生活保護業務は福祉行政の中核をなし、"健康で文化的な最低限度の生活"を営む権利を保証する為、都道府県及び市の福祉事務所が中心となってその運用を行っている業務である。今回の開発はこの生活保護業務を支援するクライアント・サーバ型のパッケージシステムを新規で構築するものである。

2.背景
当社はこれまで各自治体に対してオフコンでのサポートを永年行ってきた。生活保護業務のサポートもこのオフコン上で動作するパッケージを提供することによって行ってきた。
しかしながら事務処理のコンピュータ化が進むにつれ、ユーザーのニーズも定型処理から非定型処理へときめ細かなものへと推移してきた。また、近年パソコンの普及によりオープンシステムが求められるようになり、様々な問題点が指摘されるようになった。

指摘された問題点をまとめた。
(1)1画面に表示できる情報量が少ない。
(2)マウスを使った直感的な操作ができない。
(3)業務システムをパソコンで動作させたい。
(4)クローズされたシステムである為、非定型の資料作成は手作業で行わなければならない。
(5)法改正など各ユーザー共通のシステム変更であっても、同じ変更内容を全てのユーザーに施さなければならず、保守に時間と費用を費やしている。
(6)長期にわたるカスタマイズによりパッケージとしての整合性が失われ、潜在的なバグが危惧される。

これまでもオープン化された他社パッケージシステムはあったが、カスタマイズするために使用する開発ツールの生産性や現行システムと比較したパッケージの機能面で当社ユーザーに対しては難点があり、パッケージの利用を見送っていた。そこでこのような問題を解決するために社内で検討を重ねた結果、オープンシステムのパッケージを自社開発する案が有力となり、開発に向けて具体的な検討に入った。

3.システム化構想
本パッケージ開発は、最新の技術を駆使して永年に渡って陳腐化しない、「長期間使用出来るパッケージ」を目指した。

3.1 開発条件
パッケージ開発に先だって次の事を前提とした。
(1)ハードウェア、OS、データベースのバージョンに対する依存度が低く、長期間使用出来る安定性、信頼性の高いシステムであること。
(2)開発に際して、業務知識はあるが、クライアント・サーバ型での開発経験が少ないSEにも短期間で問題無く設計ができ、かつ技術的にも習得できること。
(3)頻繁な制度改正に対して短期間に改造が出来、コストダウンが計れるシステムであること。
(4)自治体の規模によりデータの管理形態、運用形態など、若干の違いがあることがあらかじめ考慮され、全ての導入自治体で利用可能なこと。
(5)プレビュー機能等、パッケージシステムとして多くの機能を標準で装備させ、競争力のあるものとすること。
(6)プロジェクトメンバーは8名、開発工数を60人月とすること。

3.2ツール・プラットホームの選定
当初、開発ツールとして社内でも技術者の多いVisualBasicを考えたが、大規模なパッケージ開発ではモジュール管理や生産性が大きな問題となり短期間での構築は不可能と判断した。また、データベースについてもRDB(リレーショナルデータベース)の開発技術者不足からVisualBasicでの開発は困難であった。そのため、上記開発条件を満たすツールを調査した結果、「COOL:Plex」という上流工程をもカバーしたオブジェクト指向型の開発ツールを選択した。理由として、「COOL:Plex」での開発は、上記開発条件を満たしていることはもちろんのこと、生産性や保守性についても見込めるのではないかと判断したためである。

具体的には、
(1)ツールの特性として設計情報を登録することでC++のソースコードが自動生成される為、プログラム言語に対する知識がなくても業務に精通したSEのノウハウが短期間にシステムとして具現化出来ると同時に開発コストの削減が可能になる。
(2)データベースの設計は図形を組み合わせていくことで設計情報として登録でき、特定のデータベースについての知識を必要としない。
(3)マルチプラットホーム対応でありOS、データベース等の依存度が低い。
(4)属性が継承関係を持つオブジェクト指向で有り、修正作業もデータ属性の変更、追加により、多くのプログラムを自動的に再生成する事が出来るため、制度改正によるプログラムの追加、変更が多い生活保護業務には最適である。
ということから「COOL:Plex」は今回の開発の目的に合致すると判断した。

「COOL:Plex」で機能的に弱いとされる帳票系を補う為に、市販の帳票作成ツールである「Crystal Reports」を採用した。「COOL:Plex」はActiveXに準拠したコンポーネントを利用できるため市販のコントロール類を実装することができた。また、システム構成は、マルチプラットホーム対応の「COOL:Plex」としては幾つかのプラットホームを選択可能だが、最も実績があり標準的な構成として、OSはWindowsNT4.0、データベースはOracle8を採用することにした。(図1参照)

3.3システム化する業務範囲
大規模な自治体での業務分担を意識して、システムでは業務を大きく、「相談」「現業」「決裁」「介護」「医療」「経理」「統計」と7つに分け、これにシステム情報を管理する「共通管理」を加えた。
「相談」は住民からの問合せ、福祉に関する相談などに対処、記録し、統計・分析の支援を行う。「現業」は生活保護の申請を受け付け、法律に基づいた資産や扶養親族の調査、保護を受ける人の家族状況、生活状況から生活保護費の計算などを支援する。現業の保護費計算では、コンピュータの最も不得意とする希少な処理パターンが多種多用に考えられシステムの中枢とも言うべきところである。「決裁」は電子承認のことであるが、現状の行政事務手続きでは、法律や条例の関係から実現出来ていない。システム上、決裁したものを決裁データとして入力することで、入力された情報が決裁されたかどうかを判別することにより、誤支給や不正使用を防止する。「医療」「介護」は現金の代わりに「医療券・介護券」の発行を支援する。毎月、定期的に大量発行が発生し、最も印刷機能を酷使する。通常は卓上の小型ページプリンタで十分だが、この時は印刷速度を要求されプリンタの選定を悩ませるところである。今回は、発行時に範囲指定で、複数の小型のプリンタで同時印刷することにより速度をカバーすることを想定した。「経理」は毎月または随時での支給を支援する。運用や管理がユーザー毎に異なり、必ずカスタマイズが発生する業務である。如何にして共通点を見いだし、相違点を明確にしてユーザー毎のカスタマイズを行い易くしておくかがカギとなった。「統計」は毎月、及び年1回の規定の報告物を作成支援する。コンピュータが最も得意とする業務である。しかし従来のオフコン版システムでは、集計結果のみが印刷され、誰がどの集計項目に含まれているのかが不明なままで、手作業による調査が必要なこともあった。統計では、この点に重点を置き、対象者が誰か簡単にわかる仕組みを作り上げることを目標とした。(図2参照)

4.システム開発
生活保護システムの開発はツールの特性に合わせて次の手順で行った。
(1)共通化作業
(2)システム設計
(3)プログラム作成
(4)テスト

(1)共通化作業は概要設計フェーズ、(2)システム設計は詳細設計フェーズ、(3)プログラム作成は製造・単体フェーズで行った。
「COOL:Plex」によるシステム開発にあたって最大の特徴は、共通化作業とベースファンクションの作成であった。また、この作業を進めるために開発体制としてモデルマネージャを配置した。(モデルマネージャについては後述する。)(図3参照)

ここでは、(1)共通化作業、(2)システム設計について具体的に説明する。((3)プログラム作成、(4)テストについては一般的なオープン系開発と同等な手順で作業を進めていった。)

4.1共通化作業
直接、住民の行政サービスに携わる自治体職員が当システムの利用者となることから、若い人から中高年層の方まで幅広い年齢層の人が利用することになる。そのため、画面や文字は大きく配置するようにした。また、自治体職員は3〜4年で別の部署に異動することが多いので新任の職員でも直感的に理解出来るよう色分けして視覚的にも操作の手助けになるよう配慮した。更に、小規模の自治体では、一人の担当が複数の業務で使うことが考えられるため、画面のイメージや振る舞い(動作)を全ての画面について統一した。このような共通化を進める中で、特に重要であったのがこの「画面の振る舞い」の統一と「ビジネスルール」の抽出であった。今回のシステム開発では、この「画面の振る舞い」と「ビジネスルール」にどれだけの共通性を施せるかが工数削減のポイントとなった。

共通化作業は、次のようなことを行った。
(1)画面の体裁の統一
(2)画面の振る舞いの統一とベースファンクションの作成
(3)ビジネスルール(業務ルール)の抽出とビジネスファンクションの作成
(4)ネーミングルールの設定
(5)コーディングルールの設定

4.1.1「画面の振る舞い」の統一
「COOL:Plex」の大きな特徴は「パターンベースによる開発ツールである。」ということである。ここでいう「パターン」は一連の画面遷移をグループ化したもので例えば1画面のみのマスターメンテナンスのプログラムを作成するときの手順を考えてみると、

(1)マスターに格納するフィールドを持つデータベースを作成する。
(2)追加、変更、削除の機能を実現するためマスターに対応する項目を持つ画面を作成する。
(3)画面の制御とデータベースに対する入出力プログラムを作成する。
(4)このとき、オンラインでの処理を考慮して多重アクセスへの対応をしておく。
この(1)〜(4)の抽象的な工程をマスターメンテナンスアプリケーションの1つの「パターン」として「COOL:Plex」に登録することによりマスターをメンテナンスしたいデータ(例えば職員データ、地区データ等)と置き換えるだけで様々なマスターメンテナンスアプリケーションが完成する。さらにこのような簡単なパターンを色々組み合わせることで複雑な画面遷移をもつパターンも登録することができる。このようにして各業務の機能を「画面の振る舞い」で分類し「パターン」を特定していった。「画面の振る舞い」を共通化する具体的な作業内容としては、必要となる入力画面を全て洗い出し、一つずつパターン部品の動きと照らし合わせてどのパターンと一致するか、または近いかを検討していった。結果、いろいろな処理パターンがあると思い込んでいたものが、6パターンで構成されることがわかった。これに多少のアレンジを加え、合計7パターンでシステムの基礎を構成した。

4.1. ベースファンクションの作成
「画面の振る舞い」でパターン化された機能は基本パターンとしてツールに登録する必要がある。これがベースファンクションの作成である。ベースファンクションはプログラム作成に先立って事前に用意しておく必要があるため設計と並行して作業を進めていった。この作業はモデルマネージャが担当する。また、作成したベースファンクションの管理も行う。しかし、開発当初にツールを使ってベースファンクションを作成していくには、スキルがまだ開発メンバーに身についていなかった。結局、早期に開発を立ち上げて進めていくには「COOL:Plex」を熟知した外注を技術支援として起用せざる得なかった。また、ある程度パターン化された市販のパターン部品を用いて、高度な作業を必要としないかたちで進めていくことにした。この市販のパターン部品に生活保護システムの画面遷移を合わせることで共通化作業を進めていった。生活保護システムでは7パターンのベースファンクションを作成して、すべての機能はこのベースファンクションを継承して作成した。

4.1.3「ビジネスルール」の抽出
「ビジネスルール」とは業務処理で考慮しなければならない、業務要件や業務規約のことだがここでの「ビジネスルール」の抽出作業は同じ業務要件や業務規約を別の機能として記述することを排除する目的で行った。「ビジネスルール」を明確にすることにより、そのルールがファンクション化され、一機能を形成する。これがビジネスファンクションである。実際に製造する時にはその機能をファンクションとして実装すれば良い。また、実装する側からすると利用するファンクションは完成されたテスト済みのファンクションであり、この部分のテストは不要となり、コーディング工数、テスト工数の削減につなげることが出来る。このため共通化作業の中で出来るだけ多くのビジネスルールを抽出する必要がある。

4.1.4ビジネスファンクションの作成
抽出された業務処理で必要とされるビジネスルールに加え、現在サポートしているユーザーからの「指摘事項」や「運用効率を高めると思われる要望」、及び運用サポートのSEから「保守を行う上での問題点」などを改めて洗い出した。結果、全てではないが個別で捉えてきた指摘事項や要望は、幾つかのユーザーで重なることが明確になった。ここで上がった問題点や要望事項を整理して、システム化する機能を確定させていった。その中でも一連の業務手順に添った処理で、汎用性があればこれも「ビジネスルール」としてファンクション化し、ビジネスファンクションとして作成していった。

4.2 システム設計
このように機能を統一し、かつ整理していったにも関わらず結果は、ファンクション数は5,147、機能数も390という大規模なシステムとなった。(表1参照)
システム設計は、これら一度分解された機能を整理し共通化することによって作成されたベースファンクションやビジネスファンクションを組み合わせ、一つの機能として再構築していく作業となった。実際には共通化作業中に抽出できなかったファンクションがこの段階で新たに抽出されることもあり多くの手戻り作業が発生した。
オブジェクト指向型の開発では、共通化がカギとなるがこれをいかに前段階で抽出できるかは開発メンバーの習熟度に依存するものであると感じた。

4.3システムの特徴
この生活保護システムはパッケージ化を前提として開発した。法改正に柔軟に対応し、かつ各自治体向けに対して容易にカスタマイズできることが必要であり、これを実現する機能が「モデルの継承」であった。

4.3.1 モデルの継承
「COOL:Plex」では業務ノウハウを設計情報として登録し、出来上がったアプリケーションをひとつのモデルとして扱うことが出来るが、この設計情報を実装するのに「COOL:Plex」の特性を最大限生かせるように開発体制、モデルの構成や継承関係などを検討した。開発体制の特色としてモデルを管理する「モデルマネージャ」を1名配置した。今回の生活保護システムはモデル構成を3階層モデルとした。このモデルの中に生活保護の業務モデルを設計情報として登録していった。ここで「COOL:Plex」で扱う「継承」の概念を説明しよう。
何かを計算する関数F(z)があったとするとその関数を少し変更して目的のF'(z)を完成させる場合、従来ならF(z)をコピーしてF'(z)をつくりロジックを追加して完成となる。 「COOL:Plex」では、F'(z)を新たに作り「F'(z)はF(z)である」と定義づけ、差分のみを記述して完成となる。これが「継承」である。この「継承」のメリットは、F'(z)のようにF(z)を元に作成されるものがいくつも出来てくると「Z=Z+A」の部分が「Z=Z+T」とかわった場合、従来であればコピーして作ったすべての関数に対し、修正を加える必要があるが「継承」された関数なら、F(z)のみの変更で完成する。
これだけだと作業量が同じなので特にメリットはないが、F'(z)のようにF(z)を元に作成されるものがいくつも出来てくると「Z=Z+A」の部分が「Z=Z+T」に変更になった場合、従来であればコピーして作ったすべての関数に対し、修正を加える必要があるが「継承」では、F(z)のみの変更でよい。(図4参照)

生活保護システムは3階層モデルとした。第1階層目は、データ構造と共通仕様(画面の振る舞い)や共通のフィールド(データベースの項目)属性などを定義したデータモデル、第2階層目は、業務特有のロジックを記述し、実装レベルのアプリケーション機能を作成するアプリモデル、第3階層目は各ユーザー独自の差分を記述し独自の機能を作成するユーザーモデルと位置付けた。第1階層目のデータモデルはデータ構造や基本となる画面の振る舞い、基本となるフィールド属性を誰もが勝手に変更できないよう更新権限を持つ人を限定した。このようにすることで、開発中知らない間に基本情報が変わり、完成した機能や作成中の機能に影響を及ぼす事はなかった。データモデルに変更がある場合には、必ず変更内容が周知された。第2階層目のアプリモデルは第1階層目を参照ライブラリとして定義する。第1階層目のデータ構造と振る舞いをフレームワークとして「継承」し、データに実体を持たせ、業務特有のロジックを記述する。パッケージとしては、この第1階層目及び第2階層目を完成させることであった。第3階層目のユーザーモデルは各自治体に適用する際、独自の差分を定義するものとしてその都度作成する。このように3階層構想は、パッケージの横展開構想とうまく重なったものだった。
生活保護システムに「継承」の概念が忠実に実現できたのも開発ツールとして「COOL:Plex」を採用したからである。(図5参照)

4.3.2その他の特徴
開発した生活保護システムのその他の特徴や工夫した点を上げる。
(1)業務の特性として、入退院、出生、転出など生活環境や家族構成が変わる度に生活費の再計算を行わなければならない。また、季節や年齢、身体の状態(障害や傷病、妊娠...)でも生活費が異なる。その様な異動の度に生活費の日割り計算を行う。多用で複雑な生活費の計算を利用者が業務になれていなくても計算できるよう家族構成や状態を入力するだけで計算できるようにした。またユーザーインターフェースも直感的に解かるよう配慮した。
(2)日々の不定期な異動とは別に定期的に異動が発生するものがある。例としては、1歳到達時、70歳到達時、小中学校入学時、夏休み開始終了時..などがある。このように事前に異動がわかっているものは、自動的に異動データを作り入力する作業を軽減するものとした。
(3)年1回、生活費の基準額が変更されるが、この時、基準の階層が変更されることも考えられるため、これによるプログラム変更が発生しないよう基準データの階層を変更することで対応可能な仕様とした。
(4)運用に着目すると、従来は経理担当者が支給の処理を行うと、入力した内容が未決済であっても支給データとして処理されるなど、運用ミスを引き起こす問題を含んでいた。その為、入力する側と支給処理をする側でスケジュールの確認を行いながら運用しなければならず、場合によっては入力データを破棄するなどの処置を行わなければならなかった。この問題を解消する為、入力と支給の間に、本来行う決裁処理を取り入れた。支給側では未決済データは対象外とする仕組みとし、更に支給する人を支給側で選択出来るようにした。これによりシステムの運用スケジュールに束縛されず、ユーザーの実態にあった運用が可能となった。
(5)医療・介護の運用で最も問題となっていたのが、医療券・介護券の発行であった。小規模の福祉事務所では、一括発行も意識した高速プリンタ1台で運用するところも珍しくなく、プリンタの故障は即システムの停止を意味していた。そこで今回は、速度を要求せず比較的小型のプリンタを数台接続することを想定した。大量発行時には、範囲指定で分散して印刷することにし、速度をカバーした。その他、問題ではなかったが、昨今ペーパーレス化が叫ばれるなか、社会のニーズに多少とも応えるべく、印刷の機能にはプレビュー機能をもたせた。

5.評価
以下、開発当初に立てた目的と比較しての評価を行ってみたい。
(1)ハードウェア、OS、データベースのバージョンに対する依存度が低く、長期間使用出来る安定性、信頼性を持ったシステムとなったか?
開発ツールに「COOL:Plex」を採用したことにより、ハードウェア、OS、データベースは全て開発ツールの配下で管理されておりツールの整合性が保たれることによって開発したシステムの安定性、信頼性が確保されている。また、OSやデータベースがバージョンアップしても開発ツールがバージョンの違いを吸収してくれるため生活保護システムに変更は発生しない。
(2)クライアント・サーバ型での開発経験が少ないSEにも短期間で問題無く設計が出来たか?また技術的な習得が可能であったか?
従来システムでは「手続き依存型の設計手法」であったが今回は「DOA(データ中心アプローチ)」での設計を行った。DOAでの設計は、RDBでの開発経験があるメンバーを中心に行ったため特に問題なかった。加えて「COOL:Plex」自体がこのDOAに適したツールであり、設計思想とツールが合致し特性を生かせたことは大きな収穫であった。現在はまだ特定の開発メンバーだけが習得している状況であり今後も引き続き技術習得に努める必要がある。
(3)短期間で改造が出来、コストダウンが計れるシステムであるか?
生活保護システムは、共通化作業によりわずか7パターンのベースファンクションで構成されている。また、高品質なベースファンクションが完成しており、後のプログラム作成では、多種多様な機能を構築することが出来た。今後発生する改造も大半はこの7パターンでシステム化する予定である。それによって短期間での改造、コストダウンが可能なシステムになっている。
(4)自治体毎の管理形態、運用形態の違いをカバーしたシステムであるか?
 自治体規模の大小に関わらずシステムを利用できるように既存の大小自治体サポートで得たノウハウを反映させた。また、開発ツールが持つ「モデルの継承」機能により法改正など全自治体に必要な改造は、第2階層目の「アプリモデル」に、また各自治体固有の改造に対しては第3階層目の「ユーザーモデル」に対して実施することにより提供全自治体のシステムを一元管理することが出来た。
(5)パッケージとして標準の機能を多く装備し、競争力のあるものとなったか?
業務システムとして多機能で操作性の良いものが出来たと思う。システム導入に際して短期間での改造が容易にでき、導入システムがオブジェクト指向によって開発されているため将来に渡って使用できる環境を提供でき、競争力のあるシステムが出来たと考えている。
(6)プロジェクトメンバー8名、開発工数は60人月という予定に対する実績?
プロジェクトメンバーについては開発ツールのライセンス数に依存するため8名に変わりはない。開発工数については予定60人月に対して外注分工数を含め実績76.5人月であった。原因として「COOL:Plex」の習得に思いのほか時間を要したこと、業務に精通したSEが既存システムの保守に手をとられ設計に十分な工数をとれなかったことが上げられる。結果として後工程での設計の見直しが頻発し予定した工期、工数をオーバーしてしまうこととなった。(表2参照)
これまで多種多様な開発ツールを経験してきたがこれほどオブジェクト指向が明確に反映された開発ツールはかつてなかったと思う。この「COOL:Plex」が持つアーキテクチャを駆使することにより、これまでに開発したファンクションを業務部品として再販するなど、今後大きな可能性が開けることを確信している。

6.今後の課題
今後取り組むべき課題として最初に挙げられるものは、先ずメンバーのオブジェクト指向開発の概念の理解とツールに対する習熟度の向上である。
開発の初期段階での共通化作業と、プログラム製造段階でのモデル管理に、今回は外注を技術支援として起用し開発を進めることが出来たが、この工程は特に習熟を要する。この二点をマスターし、習熟度を増すことにより、更なる生産性の向上が望めるものと考えている。
次に挙げられるものは、3階層で構成されるモデルのメンテナンス作業についての方法論の確立である。今後、法改正等のメンテナンス作業においては、パッケージの基となる第2階層目のメンテナンス、ユーザー毎の差異(差分)に対する第3階層目のメンテナンスを安全で効率的に実施できる方法を手順として確立する必要がある。

平成年10月から平成12年10月末まで、予定を3ヶ月オーバーした形で完了した。未経験の事が多く、思った様には進まなかったというのが感想ではあるが、オブジェクト指向型のツールを利用しての開発で学習出来た事も数多くあったのも事実である。  現在、開発されたシステムは実際のユーザーの元へ納入され、本稼動を開始した所である。
したがって、機能面や、操作性等に関する真の評価は今後ユーザーによって下される事になるが、開発者としては十分満足頂けるものが出来たと思っている。また、開発の目的がそうであった様に、多くのユーザーに長期間システムを利用して頂き、安定性、信頼性の高いシステムである事も検証していきたい。