「情シスならでは？私が出会った怪しいツール ２」からの続きです

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

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

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

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

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

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

　〇運用保守まで考えてツールを提供する
　　運用範囲はあらかじめユーザー側と認識を合わせ、保守しきれる範囲で使ってもらいましょう。
　〇一人開発はしても、属人化はしない
　　定例MTGなどでツール化案件を周知し、仕組みや妥当性をメンバーで検討してもいいと思います。 　　（依頼をワークフロー化するようなこともよくやられる手法です）
　〇ツールの立ち位置は明確に
　　特に抽出系のデータを提供する際は、決算などの「正」のデータは○○で、このデータは「○○」の
　　ためのものです。 というやり取りを行い、メールなどに残しておくといいでしょう。

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

https://sunited.co.jp/