新基幹システムの凄惨な船出(性能編)

判断基準のよく分からない稼働判定を経て、ついに新基幹システムは大海へと漕ぎ出しました。

その船底は穴だらけでしたが、出航前にそれに気付いていたのは現場担当者のみでした。。。

大方の予想通り、まずは性能問題が噴出しました。

画面は大きく分けて、営業系部門が使用するWeb画面と、バックオフィス系部門が使用するクラサバ画面がありますが、どちらの性能も酷いものです。

元々、導入費用をケチったために安いサーバしか買えなかったらしいので、ハード面の原因もあるかと思いますが。

Web画面はTomcatをアプリケーションサーバとし、Java・JSPで組まれています。

ただ・・・何と言っても画面項目が多すぎる。(汗)

これは、当社が属する業界の特性でもあるので一概に画面設計が悪いとは言いませんが、それならばもう少し内部処理方式の面で性能に気を配ってほしかったと思います。

例えば、1画面を表示するのにトランザクションテーブルだけで20個ぐらい使用していたりします。
しかも、同じ内容のデータを、データ出力機能用にも別テーブルとして管理しているため、本来は10個で済むはずなのにです。
なぜ、業務処理用とデータ出力機能用でテーブルを分けているのか、イマイチメリットが理解できません。

また、このパッケージはとにかくビューが大好きです。
なんでもかんでもビューテーブルを作り、ビューの入れ子なんて朝飯前です。(苦笑)
いや別にビューを使うなというわけではないんですが、ちょっと多用しすぎかなという印象です。

そんなこんなで、画面で1つのボタン操作を行うごとに5~10秒はかかります。
ちなみに、1テーブルあたりに入っているデータ件数は多くても5~6万件程度で、かつ一括更新系画面は無いので、1件更新するだけなんですが。。。

スポンサーリンク


さらに輪をかけて困ったちゃんなのが、クラサバ画面です。

ていうか、これからはAI・ロボットだなんて言ってる時代に、未だにクラサバとは。(泣)
私が新卒で就職した12年前ですら、もう古い技術になりつつあったっていうのに・・・

クラサバ画面の方は、締め処理や請求書の一括発行など、オンラインバッチ系の機能がメインになります。
さて、気になるその性能は・・・

数千件処理するのに30分~1時間は当たり前。(苦笑)

酷いものでは、2千件をファイル出力するのにまさかの6時間かかる機能があります。
データを集計しながらファイル出力しているとは言え、集計元データもたかだか1万件程度しかありません。

これならAccessで集計しながらファイル出力した方が良くね?
一応、月次業務でしか使用しないというのが唯一の救いです。

前の会社で卸売業の基幹システムを開発していたときは、「100万件の受注データ取込処理を1時間以内に完了させる」なんていう性能要件はザラにあったものですから、この遅さはちょっと信じられません。
(ハード性能に雲泥の差があるのも主要因だとは思いますけど)

尚、再三再四、ベンダーには性能改善を要求していますが、改善の余地は無いんだそうな。

なるほどなるほど。
ということは、ずっとこの性能のまま運用してけってことなんですね、コレ。(泣)

よく他の導入企業はガマンできてるな・・・

還元率の高いポイントサイトで、ハイペースでポイントが貯まります ポイントサイトのポイントインカム

獲得ポイントの高いアンケートサイトで、効率的にポイントが貯められます infoQ新規会員登録

新基幹システムの凄惨な船出(ログ編)

システムのアクセスログは、今や内部統制に欠かせない重要な資料となっています。

当社においても、各システムのアクセスログを週次で分析し、不正アクセスやアカウントの使い回し等のルールを逸脱した操作を行っていないかについてチェックしています。

さて、この度基幹システムを刷新しましたので、新基幹システムのアクセスログも当然チェック対象に挙がることになりました。
新基幹システムに採用したパッケージでは、アクセスログを画面で検索できたり、CSV形式でファイル出力できたりと、中々ログ分析機能が充実しています。

このため、システム部の誰もログに関しては気にも留めていなかったのですが、まさかあんな地雷があろうとは。(汗)

新基幹システムが稼働して1ヶ月が経過した頃、いよいよそれまで蓄積されてきたログをチェックすることになりました。
早速、パッケージのログ分析画面より、対象期間のログを抽出してみたのですが・・・

あれ?今日の分しかログが表示されないんだけど、コレ。(焦)

試しに対象期間を絞り込むのを止め、全件表示してみたりもしましたが、やはり結果は変わらず。
また、CSVファイルに出力してみても、やはり当日分しか出力されません。

んだよコレ、パッケージの標準機能のクセにバグってんのかよ。(呆)
しょうがない、ログを蓄積しているテーブルからObject Browserで直接抽出するか。

そして、ログ蓄積テーブルを参照したとき、血の気が引きました。

そうです。
元々ログが1日分しか入ってなかったんです。

※正確に言うと、1日分どころか過去10分間ぐらいしか入っていませんでした・・・
スポンサーリンク


この事実を課長に報告し、すぐにベンダーに問い合わせることになりました。
以下、ベンダーと私のやり取りです。

私: 「アクセスログをログ分析画面で表示しても、ログが今日の分しか表示されないんですが。」
ベンダー: 「御社の場合、各機能の性能を考慮して、一昨年にアクセスログ保持を最大1,000件に制限しました。」
私: 「たったの1,000件ですか?!そもそもなぜログの出力件数が業務機能の性能に影響があるんですか?
ベンダー: 「ログを蓄積しているテーブルの総件数が増えるからです。」
私: 「いや、総件数が増えてもレコードの書き込み性能はそれほど低下しませんよね?
    もちろん、ログ分析画面の表示は遅くなるでしょうけど、そこは別に表示が遅くなっても全然いいんですけど。」
ベンダー: 「いえ、総件数が増えると業務機能の性能が低下するんです。」
私: 「それはなぜなんですか?」
ベンダー: 「ログ書き込み毎に最大件数を超えていないかを毎回チェックし、超えていたら古いレコードを削除しているからです。」
私: 「ええ?!ログ書き込み毎にそんなことをやっているんですか?
    ログの削除なんて日次でやればいいだけの話なのに、性能のことを何も考慮してないじゃないですか!」
ベンダー: 「そう言われても、それが仕様ですので・・・」

まさかのログ書き込み方式に、ここでもカルチャーショックを受けました。
そりゃこんなやり方してれば、ログの保持件数が増えると性能はどんどん落ちていっちゃいますよね。
普通、ログの出力件数を減らす理由としては使用ディスク容量の節約が主なんですが、まさか性能を確保するためとは。。。
(しかも、大して速くないし)

んで、一昨年にその頃のシステム部の人達と相談し、ログの最大件数を1,000件に限定したという次第です。
困ったことに、誰も経緯を覚えていませんでしたが・・・

しかし、1,000件しか保持できないなら、むしろそんなログなんていらないんじゃないかと思います。
だって、たった過去10分間のアクセスしか分からないんだもん。(泣)

仕方が無いので、ログが消えていく前に別テーブルに退避するバッチを自前で作ることにしました。
あ~、めんどくさ。。。

※関連記事はコチラ。
  新基幹システムの凄惨な船出(稼働判定編)
  新基幹システムの凄惨な船出(性能編)

還元率の高いポイントサイトで、ハイペースでポイントが貯まります ポイントサイトのポイントインカム

獲得ポイントの高いアンケートサイトで、効率的にポイントが貯められます infoQ新規会員登録

新基幹システムの凄惨な船出(データ出力編)

システムに蓄積されているデータの出力機能の位置付けは、日々の業務を効率化する上で重要です。

例えば、データ出力後にExcelなどを使って人手で加工しなければならない工程が多いほど、業務は非効率になり、加工ミスも発生し易くなります。
逆に、殆ど加工が必要無い状態でデータが出力されてくれば、それだけで業務効率化に繋がるというわけです。

この観点でいくと、旧基幹システムを使用した業務というのは、酷いものでした。
もちろん、旧基幹システム自体が約10年ほど前に導入された古いシステムであるという点も原因ではあると思いますが。

旧基幹システムは拠点ごとにサーバが分かれていたため、全社横断的な資料を作成するためには、各サーバからそれぞれデータ出力する必要がありました。
また、トランザクションデータとマスタデータを別々に出力しなければならなかったため、出力ファイル数は膨大に上っていました。
なので、それらのデータをExcelでマージしたり手で修正を加えたりしなければならず、多大な工数をかけてようやく1つの資料が出来上がるといった具合でした。

この問題については、新基幹システム導入によりデータ出力・加工業務の大幅な効率化が図れると期待されています。
なにせ、全サーバの情報が一元化されますから、データ出力作業とマージ作業は楽になるはずです。

ところが・・・

パッケージの標準機能として付いているデータ出力機能ですが、これの使えなさといったら・・・
何が使えないかというと、テーブルで縦持ちしているようなデータが、そのまま縦で出てきます。

流通業に例えて言うと、1行の受注明細に対して、定番単価と特売単価の2つが設定されているとします。
このデータを出力した場合、定番単価と特売単価がそれぞれ1行で横につながって出力されるのが一般的かと思います。
しかし、当社の基幹システムを使うと、定番単価で1行・特売単価で1行の計2行が出力されてしまい、1行の受注明細が増幅したように見えてしまうのです。

当然、これには現場からクレームが殺到しました。
重複行を省いて1行にしなければならず、余計に加工するのがめんどくさくなった、と。
これに対してベンダーのSEの反応はこんな感じ。

「そうなんですよね~。実は、他社さんからもあまり評判は良くないんです。。。」(苦笑)

ああそう・・・
やっぱり評判悪いのね。
だって、使いにくいもん。

システム屋から見れば、単純にメインテーブルと縦持ちテーブルをJOINしているだけだから、そのまま増幅して出てくるんですってのは分かります。
しかし、増幅して出てくるよりは1行でそのまま横にくっついて出てきてくれた方が使い易いっていうことは、業務的な使い方を考えれば普通気付きそうなもんですが・・・

スポンサーリンク


この増幅して出てきちゃう問題を受けて、ずっと塩漬けになっていたBIツールを活用することにしました。

つまり、BIツールを使用して新基幹システムからデータ出力できるようにしよう、ということです。
ただ、上記の記事でも書いたとおり、BIツールは所詮SQLを日本語にしただけですので、業務部門の担当者が定義を作れるような代物ではありません。

ということで、業務部門が欲しいデータを予めビューとして新基幹システムのOracleに作成し、そのビューをBIツールから参照させてデータ出力してもらうという、単純な方式にしました。
これだと、ビューの作成は当然こちらでやるので、元のテーブルが縦持ちだろうが、JOINするときに横持ちに変換してやればいいだけのことです。

この方式がすこぶる好評で、喜ばしい限りです。

問題は、パッケージのテーブル構造を解析してノウハウを持っているのが現状私だけなので、データ出力用のビュー作成やBIツールの定義作成を一身に受けてやるハメになっちゃったことでしょうか。
このあたりは、ノウハウをドキュメント化して、少しずつ他のメンバーにも引き継いでいこうと思います。

そんなこんなで、どうやらデータ出力問題は解決しそうです。
ただ、パッケージ標準のデータ出力機能が逆に塩漬け状態になってしまったのはさすがに哀れみを感じますが。(笑)
(もはや、誰も使いたがらない機能になってしまった・・・)

※関連記事はコチラ。
  新基幹システムの凄惨な船出(稼働判定編)
  新基幹システムの凄惨な船出(性能編)
  新基幹システムの凄惨な船出(ログ編)

還元率の高いポイントサイトで、ハイペースでポイントが貯まります ポイントサイトのポイントインカム

獲得ポイントの高いアンケートサイトで、効率的にポイントが貯められます infoQ新規会員登録
プロフィール

Author:たみおと
36歳にして社内SEに転職しました。
ベンダーSE・社内SEどちらの方が記事を読んでも、ご参考になる体験談をUPしていきたいと思っていますので、宜しくお願い致します。

検索フォーム
ブログランキング
よろしければ、ポチっと一押しお願いします。m(__)m

ブログランキング・にほんブログ村へ
カテゴリ
よく読まれている記事
最新記事
おすすめ書籍
[商品価格に関しましては、リンクが作成された時点と現時点で情報が変更されている場合がございます。]

なぜ、システム開発は必ずモメるのか? [ 細川義洋 ]
価格:2160円(税込、送料無料) (2016/11/7時点)



[商品価格に関しましては、リンクが作成された時点と現時点で情報が変更されている場合がございます。]

絵で見てわかる RPAの仕組み (絵で見てわかる) [ 西村 泰洋 ]
価格:2786円(税込、送料無料) (2018/7/30時点)



月別アーカイブ
リンク