株式会社長野県協同電算

再構築の狙い

JA長野県グループは、2001年から6カ年の「第5次電算構想」を推進。それに基づき、信用系事業をJASTEM(農林中央金庫の勘定系システム)へ移管するとともに、日本ユニシスの汎用機上で30年にわたり運用してきた基幹業務システムの再構築に取り組むこととなった。利用者は、JA全農長野とそれを構成する25(当時)の農業協同組合、システム構築の主管はJA農協中央会の総合情報システム室、そして開発を中心的に担ったのは、グループ内のシステム構築を主要業務とする長野県協同電算である。

導入したシステム

同グループの基幹システムは、購買系・販売系・管理系・共済系・全業務共通などの各システム。旧システムの業務要件を踏襲するのに加え、各種の新機能群を付加するので、実際には移行ではなく、新規開発するシステムといってよい。JA農協中央会の総合情報システム室では、販売系の「園芸・花き販売システム」だけでもCOBOLで70万ステップ以上あり、こうした大規模開発には、生産性を高める何らかの開発ツールが不可欠と判断。早くからツール製品の選定を始め、1999年に「SapienseMerge」(以下Sapiens)の存在を知り、導入を決めた。そしてSapiensが利用できるプラットフォームという理由で、iSeriesの導入が決まった。全体では28システムがiSeries上で、8システムが富士通系のクライアント/サーバー上で動いている。またSapiensが不得手とする印刷処理は「SVF」(ウイングアークテクノロジーズ)、バッチ処理はRPGで開発した。

導入スケジュールとプロジェクト規模

iSeries上で最初に稼働したのは、2000年の宅配購売システム。販売系の「園芸・花き販売システム」は図表1のとおり。プロジェクトは長野県協同電算から開発要員が約20名、協力会社から約50名。要件定義などの上流工程でJA農協中央会から約8名が参加。

システム選定の理由

同グループが着目したのは、Sapiensの開発生産性である。ある県のJAグループが一部のシステム開発に利用しているという話を聞き、1999年10月に実際にデモを見て機能性をチェック。翌年2月に導入を決定した。モデルシステムとして、まず購売系の宅配システムの開発に着手。5月の連休明けからコーディングを開始し、約2カ月で開発を終了、7月に本稼働という高い生産性を実感し、Sapiensの全面採用を決定したという。同グループがファンクションポイント法(FP、注1)を使って導入から5年間の加重平均で比較したところ、「COBOLが10FPであるのに対し、Sapiensは平均100FP。システム内容によって、40~200FPという結果を得ており、COBOLと比べて最高20倍の生産性があると評価しています」(長野県協同電算営業部原退介審議役)

プロジェクトの難所

同プロジェクトが最初に直面したのは「意識改革の壁」である。「長野県協同電算では開発者のほとんどがCOBOLを使ってきました。そのため利用経験のない、その時点では本当に生産性が高いのか分からないSapiensの導入には、強い抵抗がありました。この意識を変革していくことが、プロジェクトの最初の仕事でしたね」(長野県協同電算佐々木賢筆頭常務取締役)

まず、管理者を中心にサピエンス・ジャパンで2週間の講習を受け、彼らが講師になって社内で1週間の講習を開催。実開発が始まり、販売系の畜産システムが2002年に2カ月程度の工数で本稼働した頃には、Sapiensの生産性が理解され、抵抗なく利用が定着した。また同グループでは、ラショナル・ソフトウェア(当時)のモデリングツール「RationalRose」(現IBM)を導入し、上流工程における設計のクラス図やシーケンス図作成に利用した。取引の流れをグラフィカルに図示することで、ウォーターフォール型の開発から意識を切り換え、オブジェクト指向型の発想を学習するのに役立ったという。一方、広域で複雑な組織構造を持つJAグループの全ユーザーから要望を吸い上げ、農協ごとに手法の異なる業務要件をすべてサポートしたシステムを構築するのは、意思疎通や合意を得るうえで大きな苦労があったようだ。例えば「園芸・花き販売システム」では要件定義に1年、開発に1年を要している。各地の農協の担当者が要件定義に参加し、意見をまとめ、慎重にシステムへ反映するが、県内のあちこちの組合からさまざまな要望が出され、なかなか仕様が決定できないという状況は想像に難くない。開発段階に入ってからも、仕様変更と手戻りが頻繁に発生した。

しかしSapiensではプロトタイピング型の開発が基本。例えば、ある担当者が画面を操作し、機能の変更を長野県協同電算に要請すると、翌朝には修正プログラムをロードして、担当者は新しい画面を確認できる。早ければ午前中の仕様変更が、その日の昼食後に確認できることも。「COBOLであれば、1週間は必要な修正作業も、Sapiensでは1日で済む。COBOLで修正作業が4つ続けば、たちまち工数が1カ月遅れます。でも、Sapiensであったため、あれだけ仕様変更と手戻りが発生しても、iSeries上のシステムはすべて予定どおり本稼働しました」と、長野県協同電算営業部の高梨勝緒部長(当時の開発部長)は指摘する。

プロジェクトを振り返って、今池上良一次長(長野県協同電算開発企画部)は、「導入前は漠然と、Sapiensは大規模システムの開発には不向きではないかというイメージを抱いていました。実際に使ってみると、大規模システムでも何ら問題はなかったですが、できればすべての要件定義を終了してから開発に入った方が開発工数は短縮できたように思います」と語る。

確かに途中段階での修正変更を素早く反映して、システムを作り込めるのがプロトタイピングのメリットだが、大規模システムの場合は、プロトタイピングのスパイラルに入る前に、すべての要件を決定しておく方が、さらに高い生産性を得られるとの実感だ。また今回のプロジェクトでは、上流工程の基本設計・詳細設計はJA農協中央会の総合情報システム室で、Sapiensを利用した開発の実作業は長野県協同電算で実施した。両社は組織も違い、総合情報システム室の中でもシステムごとに担当部署が分かれ、拠点も離れているので、コミュニケーション効率は必ずしも高くない。そのため設計と開発部隊が同じであれば、つまり設計の担当者が開発業務を兼務した場合は、Sapiensの生産性はさらに高かったのではないかという指摘も出ている。

今、長野県協同電算を見学に訪れるシステム担当者の多くが「本当に開発生産性は高いのか」「我々のスキルレベルで受け入れられるのか」と質問する。同社では上記を踏まえて自らの開発経験を語り、その成功事例を受けて全国のJAグループでSapiens導入の機運が高まっているようだ。

注1 ソフトウェアの規模を測定する手法。ソフトウェアの“機 能”を基本に、その処理内容の複雑さなどからファンクショ ンポイントという点数を付け、ソフトウェアの全機能のポイ ントを合計して規模や工数を導き出す