新聞販売システム（マイグレーション） 導入事例 株式会社日刊工業新聞社様

—　はじめに、新聞販売システムのマイグレーションに取り組まれた背景や経緯を教えてください。

まず、当社におけるホストコンピューターのオープン化について説明します。
1970年の電子計算室発足当初に導入されたホストコンピューターは代を重ねるごとに高機能化し、オープン化の取り組みが始まる2006年時点でシステム数は32、プログラム数は約3,500に達していました。

その後、人事・給与・勤怠といった汎用的なパッケージシステムを適用しやすい業務から徐々にオープン化を進めました。電子帳票・広告・出版などのシステムが続き、最後に残ったのが今回ニッセイコムに依頼した「新聞販売システム」でした。

新聞販売システムが最後に残った理由はその独自性にあります。
日刊工業新聞は全国の約6,000の販売店を通して購読者に届けられています。当社は専売店を持っておりませんので、各区域で全国紙や地方紙の販売店と契約をしています。手数料や業務処理の流れなど、様々な要素が契約ごとに異なっており、これを全てシステムで管理していました。

この複雑さを吸収できるような、既製のパッケージシステムはありませんでした。一度、同業の新聞社の販売システムを買おうかと検討したこともありましたが、同業であっても必要な機能には乖離があり断念しました。

スクラッチで再開発すると方向性を固めた上でいくつかのベンダーに声をかけ、提案を依頼しました。比較検討の結果、ニッセイコムに開発をお願いすることを決めました。

—　ニッセイコムを選んだ理由を教えてください。

ニッセイコムからの提案はWeb Performerというツールを用いた開発でした。このツールを使うことでノンプログラミング開発（コーディングの自動化と品質の均一化が図れる）が可能になり、開発期間とコストを抑えられるというものでした。確かに、全てスクラッチ開発する前提で提案をされた他社に比べてニッセイコムの見積費用は安価でした。ただしツールを用いることによって、旧システムで出来ていたことをきちんと再現できるのかを心配していました。どうしても細かい部分で抜け穴ができた時に、きちんと埋められるかどうか。

その点で、ニッセイコムには実績があったことが決断を後押ししました。
当社のホストコンピューターは日立製作所製だったのですが、かつてメンテナンスや追加開発を日立にお願いした際に、実作業を担当したメンバーの中にニッセイコムのエンジニアがいたということを知りました。ホストをよく理解しているエンジニアであれば安心できると思いました。

加えて、当社の健康保険組合では、すでにニッセイコム製の健保システムを導入しており、開発がスピーディーに進んだという話を聞いていました。それも技術力を信頼できる要因の1つでした。

— マイグレーションを円滑に進めるためのポイントについて、実際の経験を通じてわかったことがあれば教えていただけますか。

先述の通り開発にはWeb Performerが使われましたが、ツールを使えば開発工程の全てが短縮化できるわけではありません。特に以下のような、ツールを使う “前後”の部分がマイグレーションをやり遂げるために重要だと感じました。それぞれのポイントについて、ニッセイコムにどのように支援していただいたかと合わせて紹介します。

＜最初の「現状把握」が肝心＞

マイグレーションの前提となるホストコンピューターの仕様書は、初期の古いものしか残っておらず、数十年の間に行われた多数の追加開発やメンテナンスについてはドキュメントもほとんど残されていませんでした。したがって、どのような設計をするかという基準が無いままマイグレーションを行わなければいけないという状態でした。詳しくは後述しますが、基準がなければ新しいシステムのテストもできません。

ニッセイコムのエンジニアに協力をいただきながら「現在の仕様」を明らかにする作業から始めました。当社側からシステムを用いた業務プロセスを説明するだけではなく、ホストプログラムのコードの解析をしていただいたり、実際の現場業務を見ていただいたりしながら現状を可視化しました。ホストプログラムの中には、かつて現場の要望で作られたものの今は全く使われていないものもありました。マイグレーションの対象となるプログラムかどうか、仕分け作業も支援していただきました。

＜他システムとの「繋ぎ」の問題解決＞

新聞販売システムは、会計や帳票などいくつかの他のシステムと繋がっています。データの出力の仕方や、他システムから出されたデータの取り込み方の部分で、連携に不具合が起きてしまうことがあります。この繋ぎの部分で、開発を進めていく中でいくつか問題を解決しなくてはいけませんでした。

＜仕様書が無い状態での並行テスト＞

先述の通り、正しく移行できたかどうかを判断する基準となる「現在の仕様」が不明確だったために、新システムのテストの仕方も工夫していただきました。

稼働しているホストコンピューターからデータを抜き出し、加工して新システムに入れて、同じ結果が出てくるかを確認しました。請求書などはデータを抜き出すタイミングを逃すと次のチャンスは1ヶ月後になってしまいます。どのデータをどのタイミングで抜き出し、どう検証していくか、プロセスや必要なツールを整えていただき、約2ヶ月テストを行いました。

— 現在、新システムは順調に稼働していますか？

稼働当初は、細かな不具合修正や「これができなくなった」といった現場の声への対応をしていました。完全な仕様が無い状態でのマイグレーションでしたのである程度は覚悟していましたが、それも3〜4ヶ月くらいで収束しました。半年が過ぎた現在は、ホストコンピューターでやっていた事のほぼ全てが新システムでもできる状態になっています。

システムが変わることがわかると、新聞販売部門の現場スタッフは色々な期待を抱きます。
「今までと同じ画面で同じように仕事ができないと嫌だ」
「せっかくならこんな機能もつけ加えてほしい」
開発期間やコストを考えると、全ての要望を取り込むことはできません。そこで開発のかなり早い段階から、現場に向けて新システムの開発状況についてはこまめにアナウンスをすることで過度な期待をコントロールしていました。それも新システムが現場にスムーズに受け入れられた要因の1つだったと思います。

— 最後に、今後の展望について教えてください。

今回の新聞販売システムのマイグレーションによって、長年に渡るオープン化の取り組みは一段落しました。ただし、システム投資による業務改革という視点からみると、ゴールではなくスタート地点に立ったに過ぎません。今後は既存業務の継続ではなく、より付加価値を高めていけるようなシステムの在り方を考え、今の土台の上に築き上げていかなければいけないと考えています。

しっかりとした土台を作っていただいたニッセイコムに引き続きご支援いただきながら、進めていきたいと思います。これからもよろしくお願いします。

お忙しい中、ありがとうございました。