第84回例会報告
システムリフォーム（ユニチカモデル）で実現した成長する基幹システム
営業システムは独自開発、会計はパッケージという基本方針。言語はJAVAを採用。保守要員の若返りとインターネット活用によるグローバル対応を狙う。
システム構成：真ん中に統合情報データベースを置く。情報を集める基盤を構築。
会計はORACLEのEBSに。SAPと最後まで争ったが諸般の事情でORACLEに（当日話しを聞いた人だけのシークレット）。営業系、人事・物流はソフトロードのシステムリフォームで対応。体制は西安とユニチカ側に構築して双方のブリッジSEが緊密に連携をとって対応。
プロジェクトの歩み
当初のSWINGプロジェクトはSOA基盤の構築を軸に大手Sierのコンサルを入れて実施したが、システムリフォーム（compasssプロジェクト）に舵を切る。方向展開の理由：規模が大きい、仕様書がない、基幹システムの多くは他システムと連携しているというような様々な要因が絡み合っての結果である。
コスト感、システム保守切れのタイムリミットと言った制約をクリアできない。
●システムリフォームとは
平たく言うと既存のシステムを残しながら新しい基盤にお引越しすること。
ブラックボックス化されたシステムをまずはツールで言語変換。そのあとでスリム化、構造変更、見える化を実施。ツールと手作業で実施。手作業がミソ。仮想ホストという手法もあるが、これもブラックボックス化している。手が入るので細かいところまで変えられる。仕様書も見直して作る。作った仕様書を基に手作業でプログラミングしていくという変わったやり方。これが終わった後に新規案件を組み込む。
何がいいか。古いシステムの有識者が若干だが残っていた。彼らに今の仕様を起こせと言っても無理。システムリフォームはソースが全て。ソースが仕様書である。
我々の認識不足・考慮不足があとから絶対出てくるがソースに書いていれば仕様追加にならない。品質担保に関しては現新比較でやる。最初はどうなることかと思った。他社さんでも事例がありヒアリングもさせてもらった結果大丈夫だろうと判断。メリットはコスト軽減、通常のスクラッチに比べて品質が高い、発注側の負荷軽減などが上げられる。
●ユニチカモデルとは
ソースがダメならダメなまま新しいプログラムになってしまう。VSAMモデルでDBを持っていなかった。唯一アダバスを使っていたが使用範囲が限定的で大きな影響はなかった。新基盤ではRDBに持っていかなければならない。VSAMをそのまま持っていってもRDBになるわけがない。ユニチカアーキテクチャーモデルをもとにWebフレームワークを作成。JAVAEE６＋代表的なオープンソースでそれぞれのアーキテクチャーを構成。
いわゆるMVC（Model、Controller、View）の3層モデルになっている。見る側は当時のJSF2を使用。ライブラリーの一つであったプライムフェイスを使ったが開発の容易性など、評価は今一。
ロジック側はEJBでWebサービスへ簡単に変更。ESB的なACMSというツールを使って疎結合的なデータ公開をしている。将来的には本格的なESBに持って行きたい。DIコンテナー（CDI）を使ってそれぞれを管理している。DOA層はオンライン側で使用するさいはJPA、バッチ側はJDBC、共通基盤についてはJPAを用いる。インスタンスをまたがる場合は２フェーズコミットで実現。
●システムの新旧比較
旧システムの曲者はPLUTOマクロだった。昔はやったケースツールのようなものでライブラリの集まり。当時のユニチカはホスト技術者のレベルが高かったのでPL/1とマシン語を駆使して作った。これは売り物でもあった。
密に繋がったシステムをいかにして疎結合にしていくかが課題だった。DIコンテナでロジック層、View層とDAO層を分離して疎結合を担保した。オンラインのビジネスロジックはEJBで、バッチは速度を考慮してPL/SQLで作成。JCLはSHELLで基本機能をラップすることで提供。アクションとビジネスロジックは基盤機能でラップしてログとか認証認可を基盤で提供。EJB側のPLUTOの後継も提供。バッチ側もＰＬ／ＳＱＬ版を提供。アプリ基盤でサンプル画面やテンプレートを多く用意した。疎結合のアーキテクチャのお作法を守ってもらいたいので、例文・サンプルをかなり用意してその通り作ってもらった。西安の技術者に対して提供してきた。開発の実例集も１２０ページくらいのものを用意した。ソフトロードの技術者は話すのは若干難があったが読み書きは勉強してかなりできるようになっていたので日本語で書いていても大丈夫だった。
●データベースデザイン
ＤＢは配列のお化けみたいになっていたのでそのまま持ってこられてもたまったものではなっかたので以下のルールで再設計した。
- ・要素数が4以上のものは子テーブル化した。
- ・複合コードは一番小さい単位で1項目とした。
- ・1項目複数意味項目（同一・タイプレイアウト）は抽象化した。（ex．請求巾/売上巾→巾）
- ・1項目複数意味項目（別項目格納）は項目分割した。
- ・一番ややこしかったマルチレイアウトはテーブル分割した。
- 新テーブルに関しては全レイアウトを関係者集めてレビューした。
●テストについて
システムリフォームのテスト方式は現新一致が原則。
ユニチカの拘りとして高品質を維持する為のテスト方式を紹介する。
単体テストはメニュー単位でソフトロードさんにやってもらうのだが、鍵は紙芝居。操作サンプルを提供した。紙芝居ベースで現新一致を確認。紙芝居ベースで疎通しないところはデバッグツール等を用いて新システム側だけで実施したが、これが結構大変だった。
バッチに関してはJOB単位で実施。テストJOBに投入する為のデータを提供して現新一致を確認。カバレッジを上げる為に1年分のデータを提供したが、それでも足りない場合は両社協業で増量を実施。十分なカバレッジは達成できたと思っている。（ここは大分揉めたところだったそうです。）
結合テストだが業務フローからテストケースを起こして実施した。有識者で業務フロー作成チームを結成。テストケースを起こしてシナリオに基づいて現新一致を実施。
最終的にはユニチカで総合テストを実施した。これが結構大変でした。
ETL変換においてEBISDICとUTL8との違いからソート等で異なる結果が出るがこれが許容範囲かどうかを確認するのが大変だった。
業務に耐えうるレスポンスかどうかは性能規約を作って対応した。
●ユニチカモデルのアプリケーション基盤構築
前段でオラクルとユニチカアーキテクチャモデルを構想した。コンセプトとしては継続性・保守性・開発生産性を基軸にしている。アーキテクチャー原則は疎結合なシステム構成、統一的アーキテクチャー（標準技術）、信頼性で構成されている。
●ユニチカモデルだからこそ容易にできたこと
・DB正規化
原料は旧システムでは４つしか持てなかったが樹脂はこれでは足りなかった。原価計算には必ずECXELを使わねばならなかったがテーブルを正規化して入力項目数の拡張を容易にして対応。
・外部アクセス機能
本番稼働後に拡張した事例になる。FTPで連携しコンパス（基幹システム）の画面からロボットを呼び出し基幹システムに戻すことを実現している。
・Webサービス連携
基幹システムもグループウェアもWebサービス公開している。こちらの連携もRPAとの連携結果のメール送信等も基幹なので何も変更せずに連携できる。
●今回のプロジェクトのブレークスルー
・レスポンスの維持
当初は全部JAVAで開発予定だったが一部のバッチ処理はホストに比して１０倍の時間がかかるようになってしまう為断念。PL/SQLで開発し16～17秒（ホストが11～15秒）に耐えられる範囲に抑えた。
・PLUTOマクロと同等の機能のPL/SQLでの実装
％MATCH（２つのキーを比較して任意の処理を実行）、％CRLBREAK（特定のキーブレイク時に任意の処理を実行）等々を準備。
プロジェクトの結果と評価
●アプリケーション品質
テスト密度は十分に確保できた。単体テスト時のバグ密度が目標を超えてしまったが、これは結合フェーズのテストを前倒しで取り組んだこととユニチカ側が最初に提供したテストデータの網羅性が不十分であったことに起因している。
結合テストでは非常に複雑な処理ではバグが多く発生した部分もあるが単体テストで多く叩いていたので全体的には品質が安定していた。ユニチカ側でやったビジネスサイクルテストでは若干ながら目標品質を上回った。
●納期とコスト
規模としてはステップ数比較すると誤解を招くので本数画面数で表現しています。（詳細は省略）
納期は工期は2016年7月開発完了が10月に延びた。これはユニチカ内でもシステムリフォームに関して賛否両論。なんで中国を使うんだオフショアはもう流行ってないぞと言われた。経営層は説得していたが構造改革等の関係で目利きの方が来られてインドネシアのオフショアとのコンペになった。他社さんは最初は安い見積が出てきたが現新一致・ソースが正で仕様書は確定できないと言ったら3倍の見積もりが出てきた。
その後もいろいろ調整が必要な事項を経由して3か月の遅れが発生。結合テストでも更に2か月の遅れが発生。要因はコードの変更、曖昧ロジックに起因する不具合の原因究明、ロングレンジのテストで許容すべき差異の増幅等々。
コストに関しては若干コストオーバーとなったがこの規模を考えると結構リーズナブルかと思っている。
コスト増はあったが増加額/増加率ともに同業他社のシステム刷新プロジェクトと比較すると断然優位と判断している。
プロジェクト発足時に立てたコンセプトは概ね実現できたと判断している。
今後の構想（さらなる発展に向けて）
●テストの効率化
・テストの自動化
ブラウザのバージョンアップ対応等々を手作業でやっているところは９０％は自動化できると考えている。
・リファクタリングの実施
CDIを活用した現行ビジネスロジックから新たな実装を目指したい。ポリモフィックな構造に変えていきたい。
・保守・改善運用
長期にわたって保守・運用していく為の体制構築。基盤技術（アーキテクチャー）チーム、基盤技術（インフラ）チーム、実装技術チームの三位一体の体制を組み、中心で改善コーディネイター（業務スペシャリスト）が要求コントロールを実施することで各チームの活動をコーディネイトする社内体制を構築。もちろん外部の開発ラボとしてソフトロードさんの支援を受けている。
ソフトロードさんへの謝辞
開発途中でアーキテクチャーの基盤もどんどん途中で追加追加でやってきた。かっこいい言葉で言うと成長してきた。それを比較的受け入れてくれて我々と一緒に成長してくれました。多方面にわたる協力に感謝しています。
■ディスカッションタイム
Ｑ．機能追加改善効果が聞こえてこないが経営者をどうして納得させたのか？
Ａ．当初SWINGではそういう構想はあった。As-IsからTo-Beを作って設計書に落としていた。
コストオーバーであきらめた。言ってみればリライトになった。作った後に機能追加するというやりかたに切り替えた。機能追加に費用は意外にかけずに通常保守の範囲でできている。追加がやりやすくなるアーキテクチャーにこだわった。元々はかなりの高額で、期間も間に合わない。成功する補償もないということでシステムリフォームに切り替えた。
Ｑ．システムを変えたといったときに段階リリースを考えるが、一気に変えたように見えるがそうしたのは何故？
Ａ．会計は会計で半年前にリリースした。今回は営業の部分は一遍にやった。最初は事業部ごとに考えた。事業部ごとにやるのはリフォームには合わない。最初はフィルムからやろうとしたが、共有部分があり新旧混在のコストの方が高い。リフォームならできると思ったが実際はハラハラしていた。立ち上げ当初のトラブルはこちらの凡ミスであったが、今考えるとスムーズだった。現新比較を徹底的にやったのが効いた。
Ｑ．元々のＰＬ/１の人材はどうなったか？新しい保守運営体制はどう構築したか？
Ａ．業務はわかっているので業務スペシャリストとして活動してもらっている。若い連中は実装技術チームを目指している。基盤チームは元情報子会社で体制構築してもらっている。
開発ラボ（大阪）に2名ＢＳＥが残っている。西安に3人開発者がいる。大阪の二人をユニチカに引き込まないのか？そんなことしたらソフトロードさんが怒る。ユニチカ専用か？詳しくはわからないが、ユニチカだけの為にやっているかと言うと絶対そんなことはないと思う。大阪の２人はユニチカ常駐なので先任してもらっている。改善コーディネーターはＰＬ/１はもういいからに納得したか？最初は反対した。かなり議論はした。前段でやりたいことをまとめたのでやりたい気持ちは持っている。業務はわかっているので改善要望を聞くのもスムーズ。改善コーディネーターは後継者を。若い人も半分こっちに足を踏み込んでいる。
Ｑ．競合にあたります会社の者です。データマネジメントで悩んでいる。データがバラバラなところを一か所にまとめた仕組みはどうなっているか？それを使って動ける人達をどう作ったか？
Ａ．データは整理されました、次にどうするかというネタを拡大していく。何のための投資なんだ？という議論になった。うちは数年前に3社統合した。皆考え方がバラバラで、Ｏ３６５につっこむとかいろいろやっている。データをいかに儲けにつなげるかという議論を共通認識でやっていくというフェーズにようやく入ってきた。業務機能を考慮して仕様をまとめた。業務フローを見える化した。これをもとにテストシナリオを作っていった。我々自身も自分らのシステムがどうなっているかを再認識できた。データデザインを作る時も見直しても再認識できた。ある程度知見ができた。ＭＤＭも視野に入れた。お金かかりすぎるからMDMは一旦あきらめたがベースは整った。実装はこれからの課題だが知見としては我々の中に溜まった。
Ｑ．経営者はこれをわかって投資したか？
Ａ．専門的なことは理解されてなかったと思うが、なくさないとだめでしょから、あと何年で使えなくなるという脅しに近いことから始めて経営的な判断をして頂いた。最後は同業他社との比較でそんな値段でできたのかとは言ってくれた。
Ｑ．プロセスを見える化したと言っているがこんなんでプロセスはわかるのか？こんなのただのポンチエに見えるが。
Ａ．これは総合テスト用なんでブレイクダウンした詳細なものはある。
Ｑ．表記法はなにかにのっとっているか？
Ａ．自分らの適当なやり方。ＵＭＬは難しい。ＢＰＭＮでやるべきでは？僕としてはそう思うがそれを勉強してやっている時間はなかった。今後業務を追加していくときにはそういう手法を使いたい。が描画ツールも高い。
Ｑ．ソフトロードさんは表記法というか標準をもっているか？
Ａ．持っていない。ソースからきているので関係ない。設計図が重要・みんなが理解できる表記表があるといいと思う。できればBPMNを標準にしたいという気持ちは持っている。先輩でそういうのを使ってくれる人もなかなかいない。理想を追求するとお金もかかりすぎる。
Ｑ．メンテナンスにかかっていたＩＴ費用がどれだけ下がってきているか？その下がった費用を今後どこに投資していくか。今後どんなシステムに移行して行くか？他社に先駆けてどんなことをやっていくか？
Ａ．先駆けてはいないと思う。コストはメインフレームの時の約半分くらいになった。DBが安ければもっと安くなっていただろう。どこに行くかは専務・社長がインタビューに答えている。BPMでという話もある。監査がガチガチの承認になっている。監査室自体がかわいそう。現場に本業以外のハードワークをやらせているのはかわいそう。今やっている業務をコンバージョンしたが業務自体を見直したい。ホワイトカラーの生産性を上げたい。顧客エンゲージメントとか製品のサービス化は別途ＣＲＭ・ＳＦＡという形で別途企画グループがやっている。それと基幹とつなげることは取り組んでいる。
Ｑ．今後のソフトロードとの付き合い方は？
Ａ．ラボを活用することを考えている。そんなにＪＡＶＡの技術者を抱えられないので。業務をわかっているので他社にやってもらうという選択肢はない。
Ｑ．どうやったらソフトロードの方が品質がいいということを証明できるのか。開発経験のない人をどう説得すればいいのか？
Ａ．ユニチカモデルってうちだけのものにしようと思っていない。ソフトロードさんにも協力しますよと言ってある。せっかく溜めたノウハウを他に展開してもらえれば。ユニチカモデルリフォームを作りましたと言っても許容するつもり。経営はどう言うかわからなかいが。弊社はSIerではないのでそこで儲けようなどとは思ってない。
Ｑ．情報子会社があるのにソフトロードを使った理由は？なぜ３０年間ここまでできたのか？
Ａ．最初は考えたが諸藩事情で外部発注することに。運用技術チームとして今でもインフラ運用はやってもらっている。アーキテクチャーチームも全員元情報子会社である。ミッションクリティカル系はソフトロードさんを中心に、基盤とかちょっと新しい取り組みは元情報子会社を中心にやっていく。
Ｑ．情報子会社がグループ企業でなくなってしまったことは結果としてよかったか？
Ａ．やりにくい。情報システム部が２０人でやってもローテーションもできない。元情報子会社は８０人から９０人くらいの規模の会社。
Ｑ．本体としても増やさないといけないのでは？
Ａ．経営陣も理解してくれているが、人は素材メーカーにはなかなか来てくれない。化学の会社だと思われている。機械とか情報の人は見向きもしてくれない。
なんで３０年間かというと私も今回のPMも情報子会社にいた。2009年に戻ってきた。ずっと外販していた。ドーナツ屋さん、掃除屋さん、薬屋さんとか。ＳＩの称号を持っていた。基幹系とかほとんど関わっていなかった。来てびっくりした。こんな古いのかと。寿命だし何億もかかる21年には変えなければならない。これは逆にチャンスと思った。企画書を書いて提案を出した。当時の上司が常務だった。先進的な目をもっていてGOを出してくれた。
Ｑ．早く情報子会社に戻ろうとは思わなかったか？
Ａ．今まで何やっていたのと思った。先延ばし先延ばし。前の人がしなかった。動いてたらいいじゃないという感じでリスクを取らなかったのだろうか。
でもユニチカはメインフレームの技術は高いものを持っていたと思う。ノアというプラットフォームも作ってＥＵＣもやっていた。コンピュータ化するのも早かった。ホストにプライドを持っていた。成功を捨てきれなかった。ノアは自前で作った。
Ｑ．クラウドへの移行、Ｓａａｓの活用の研究は？
Ａ．運用技術グループでやっている。某社のクラウドを検討したことはある。カスタマイズなんでそれに対応できるのか？という思いがあった。今でこそ基幹連携とか言っているが当時は難しかった。オープンレガシーは課題として残っている。後輩に残しておきます。ある意味人にめぐまれている。最初の上司はシステムのリテラシーが高い方で後半の二人は銀行から来た人だった。なのでシステムに関するアレルギーが少なかった。そんなもんでできるの？大丈夫？と心配はされた。PMは情報子会社がグループ企業を離れる前に引っ張ってきた。そのあたりは人に恵まれていたと思う。
■木内さんコメント
2025年の崖とあちこちで言われている。壁じゃないですよ。レガシーを３０年くらい放置した。１０年くらいたつとレガシーになる。２０２０年までにレガシーを刷新しておけ。そうしないと年間１2兆くらいの損失が出ると言っている。だったらあんたのとこちゃんとやっときなさいよ。
創業100年を超える会社は大体持っている。中身はよくわかんない。スパゲティどころではない。爆弾持っていてどっかで刷新しなければならない。どこかのところでハード・ＯＳ・ミドルウェアの限界。だましだましできているが、ずっと使っているのでロジックは安定している。それを変えたからどうなるの？経営層をシステム部門長がいかにだますかを考える。失敗できない。失敗すると2025年を待たずして崖っぷちに立ってしまう。現行踏襲丸投げは失敗する。中の人間が業務・仕掛け・技術もわかっている人が近藤さんのところにいた。株主になんか説明のしようがない。完全に作り変えるかリフォームするかの選択肢はあるがどこかでやらなければならない。
今日は生々しい話が聞けた。イニシアティブをとってアーキテクチャーから考え設計もやった。コード設計など地道なことをやった上で経営者がいかに決断するか？が第一の山で刷新計画を確実に成功させるかが第２の山で、データある。両方がうまくいかないとちゃんとした成果がでない。そうしないと次のＤＸに行けない。必要なデータはレガシーの中にしかない。自由に使えるようにしていくしかないといけない。苦労を共有して失敗しないようにどうしたらいいかを考えてもらえればいいと思う。ユーザー企業のせいなの？サービス提供側できちんとした仕掛けはないのかと思うが現実はこういうものなので本当にご苦労様でした。
江戸 栄一（リコーITソリューションズ（株）・BSIA運営委員）
