情シスならでは?私が出会った怪しいツール

情シスならでは?私が出会った怪しいツール

情シスならでは?私が出会った怪しいツール

情シス部門のなすべき使命は事業会社によって様々ですが、これらの中で、担当者が毎月苦労して困っているから・・ システム改修が間に合いそうもないのでとりあえず・・などの 様々な理由であやしいツールが誕生するものです。 私が実際に遭遇したものと、その原因を考えていきたいと思います。

はじめに 「やさしさ」や「納期」が巻き起こす事件の数々

情シス部門のなすべき使命は事業会社によって様々ですが、代表的なものは下記ではないでしょうか。

 1.戦略の企画

 2.新規システム導入

 3.開発 既存システムの保守

 4.改修 PCやIT機器の調達・設定保守

 5.ネットワークインフラ整備保守

 6.小規模社内ツールの開発

これらの中で、

〇担当者が毎月苦労して困っているから・・・

〇システム改修が間に合いそうもないのでとりあえず・・

などの 様々な理由であやしいツールが誕生するものです。 私が実際に遭遇したものと、その原因を考えていきたいと思います。

 

遭遇その1.エクセルマクロ「合体君」全国デビュー!悲しみのバケツリレー

まずは私が作成したツールのお話です。

小売業態の情シスに所属していたのですが「管理会計と売上利益計画は店舗単位で立てるべし」という思想の会社でした。「管理会計」はエクセルで管理されており、そのエクセル数値をコピペして数値を合算して全店の「売上利益計画」を集計していたのでした。当時そのコピペ作業を必死で行っていた本部の担当者がいました。「コピペ王子」というあだ名までつけられたその担当者の工数を削減すべく、私が作成したのが 集計マクロの「合体君」でした。

これはたいそう喜ばれ、役にたてて私もうれしかったのですが、「合体君」が彼だけではなく「エリアマネージャー」 にも展開されるという事に及び、悲劇が起きました。店舗の管理に関しては、

〇いくつかの店舗を 管理する「エリアマネージャー」

〇エリアマネージャーを統括する「統括エリアマネージャー」

がいたのですが、この単位の集計にも「合体君」を活用しようとなったのです。 エリアマネージャーは70人位、統括エリアマネージャーは8人位、店舗は400店舗ほどでしたが、 そこに「合体君」がバラまかれる事となったわけです。経験浅かった私はそれを快諾しました。 その直後、「合体君」に不具合が発覚し、修正が必要に。「先ほどの合体君は破棄し、新しい合体君を利用してください」という伝達。 古いバージョンを使う事による店舗からの不具合問い合わせ。 そしてまた見つかる不具合と修正連絡のバケツリレー。 (最終的には合体君のファイル名にバージョン名がつきました) まさにカオスでありました。

遭遇その2.バッチファイルがどこにもない?

拠点毎にある販売管理から出力されたデータを、一つのデータベースに 取り込む処理が社内にある事はしっていました。 しかし、よくある事なのですが、その仕組みに関してのドキュメントはなく、処理の内容に関しては担当者の頭にしかないのでした。そんな時に事故はおこります。 毎日入るはずのデータがデータベースに入っていなかったのです。 こういう時に担当者がいないのもよくある事です。 処理が動いている(はずの)サーバーを確認しました。 が・・プログラムがありません。というよりも、タスクスケジューラに ジョブが何も設定されていないのです。JP1(導入されていた製品)を使ったのか・・? 見てみましたがそこにも処理はありませんでした。 しかし、サーバーのデスクトップは、定期的に黒いコンソール画面が立ち上がっているので、 何らかの処理がされている事は明らかでした。 「こ・・これは・・?」 あるメンバーが気づきました。実は、デスクトップの「壁紙」がHTMLになっており、 そこにPHPが仕込んであるというアクロバティックな実装になっていたのです。 「どうして・・こんな事に・・」 原因を確認したところ、担当者はPHP「しか」扱えなく、知恵を絞りだして定期的に データを登録する仕組みを構築したのでした。

 

遭遇その3.期待の救世主は機能要件を満たさない

上記「バッチファイルがどこにもない」の続きの話。 上記のシステムはデータの収集にも問題がありました。 安定して動かず、よく夜間の処理で動きが止まってしまうのでした。 そんな中、ある担当者がVBでの収集バッチの刷新を試みたのです。 プログラムは完成し、期待を持って試験運用が開始されました。 しかし・・日時でデータを収集しなくてはならないそのツールは、 全データを収集するのに27時間かかるの事がわかったのでした・・ 機能要件を満たせるかの想像が足りていなかった悲しいツールとなりました。 その後私が付け焼き刃的につくったC++のマルチスレッドプログラム 「ピュンピュン」が登場するまでこの課題は続く事となります。

 

遭遇その4.いつの間にか社内のデファクトスタンダードツールに!

その事業会社では、拠点毎にWEBの販売管理システムがあり、 本部側もWEBの機能である程度のデータをダウンロードして 分析する事が可能でした。しかしながら分析の対象や粒度は状況によって 変化しやすく、システム担当者がデータ抽出を行うのはよくある事です。 その担当者は、頻繁にくる抽出依頼にうんざりし、データダウンロード用の簡易サイトを 構築する事にしました。仮にONSと名付けられたその仕組みは 担当者にたいそう喜ばれ、重宝されることになったのです。 担当者は、当初「これは、あくまで参考値を取り出すものです。本当に正しいデータは WEBシステムから取得してください」といっていたのですが・・ 1年もたつと、「データがWEBシステムとズレているじゃないか!」や 「数値がまだ入ってなくて今月のレポートが作れません。いつ入りますか・・?」のような、 本人にしてみれば理不尽極まりない問い合わせが来るようになってしまったのです。 担当者にやさしさはあったのですが、サイトの立ち位置の認識の共有が難しかったようです。 悲劇を生まないように、ツールを作るとき心がける事 まだまだ色々あるのですが、今回はこの辺で・・

 

おわりに 悲劇をうまない為には

見えてくることはいくつかありますが、下記のようなことを心がけるべきではないでしょうか。

〇運用保守まで考えてツールを提供する
運用範囲はあらかじめユーザー側と認識を合わせ、保守しきれる範囲で使ってもらいましょう。

〇一人開発はしても、属人化はしない
定例MTGなどでツール化案件を周知し、仕組みや妥当性をメンバーで検討してもいいと思います。  (依頼をワークフロー化するようなこともよくやられる手法です)

〇ツールの立ち位置は明確に
特に抽出系のデータを提供する際は、決算などの「正」のデータは○○で、このデータは「○○」の  ためのものです。 というやり取りを行い、メールなどに残しておくといいでしょう。

それでは今回はここまで。

pagetop