「見える化」って本当に必要？見えた先のこと考えてますか？導入前に意識したい３つのこと

■この記事のターゲット
・データの見える化を社内SEに開発依頼している
・社内のIT技術者リソースを有効に使いたい
・ムダにならない見える化ツールを導入したい

「よし、見える化しよう！」

「いろんなデータをつないでスマートファクトリーを目指そう！」

製造業の工場ではDX（デジタルトランスフォーメーション）、スマートファクトリーの旗印のもと、ITを駆使した様々な「可視化」を進めようとしているところが多いでしょう。

データ可視化ソリューションを提供しているレッドフォックス株式会社が2020年に調査した「企業のDXに関するアンケート」によると、

業務改善・効率化を目的としたデジタルツールを新たに導入し、利用しているユーザーの多くは不満を感じているようです。

上のアンケート結果からは、「業務量、業務負担が増えた（43%）」、「業務がさらに煩雑になった、残業が増えた（31.4%）」といった、当初の目的から相反する結果が現場で起きている…。

僕が勤める企業でも同じようことが起きています。

従来から変化しようとすると、いろいろな問題や課題が出てくるのは仕方ないこと。

ある程度許容しなければいけない部分はあると思います。

しかし、

できるだけ「見える化」、「デジタル化」を効果的に進め、将来予見される問題を回避するために依頼側がしっかりとした導入後の活用イメージをしておくことが大切です。

そうでないと、冒頭のアンケート結果のような事態が起こってしまうことになりますよ・・・。

見える化・デジタル化を進めるうえで意識しておきたいことは多く存在しますが、今回の記事では以下の３つについて述べたいと思います。
注：今回は社内に情報技術部門を持ち、社内SEを活用するケースを想定しています。

ここでは詳しく述べませんが、ツールの要件定義が最も重要であることが前提です。

そもそもの必要な仕様が盛り込まれていないと、「ツールが正しく機能しない」、「改修の繰り返しでプログラムが複雑化して汎用性が無くなる」という致命的な問題を抱えます。

要件定義は、IT技術者と開発依頼側とでしっかりと詳細まで詰めましょう。

導入後の活用によって得られる現実的な成果・効果を試算する

見える化ツールを開発するにあたっては、当然ニーズがあって開発依頼することになるでしょう。

そのニーズを満たすツールが、開発依頼主にどのような利益を産むのかを事前に試算すると思います。

当然考えますよね。

・今まで○○に○○時間かかっていた工数が〇％削減される
・○○する時のヒューマンエラーが排除でき、手戻りコストが〇円削減される

などの効果を。

そこで、今一度考えてみてください。

見える化したら本当に試算通りの効果が出ますか？
エクセルマクロなどで自部門内で簡単にできませんか？

言いたいことは、

そもそもその「見える化」必要ですか？

ということです。

見える化を、単純に「既知の情報を自動で表示するもの」と考えていてはいけません。

設備の情報やラインの稼働状況が自動でパッと数値で分かるような表示などは「単なるモニター」でしかなく、人がマニュアルで集計する時間を効率化するものにすぎません。

自動でパッと情報が見えるようになったあとに、見えた情報から次のアクションを起こすのに有効かどうかを考えてください。

従来のマニュアル集計でモニター化していた時に、得られた結果から次へのアクションを正しく行ってきた場合、集計→アクションが短時間で行えるため効果的な開発となるでしょう。

一方で、

集計した結果が次のアクションに必ずしも繋がらない場合、わざわざIT投資する必要などないケース往々にしてあります。

見えただけで満足するようなデータなら、わざわざ見えるようにしなくてもいいんじゃないでしょうか。

社内SEは、社内の多くの組織から様々な開発案件を持ち込まれています。

DXや見える化といった耳障りの良い言葉が先行して、効果に繋がらない開発案件を社内情報技術部門に押し込むことは避けるべきです。

情報技術部門の人的リソースが十分でない場合、会社全体の重要なシステム開発納期にも影響しますし、そもそもの開発費（人件費）がムダに終わる可能性もあります。

・そもそも今やっている集計自体が必要なのか？
・ExcelマクロやRPAなどを駆使して、自前でできないか？

をまず考えてみてはどうでしょうか。

「見える化」とは、今まで見えなかったモノ、可視化できなかったようなモノを数値や図表に変換するものと僕は考えます。

既存の情報を「単なるモニター」するのではなく、

・既知の情報を組み合わせて、新たな指標に変換する
・いままで見えなかったアナログ量をセンサーなどでデジタル変換する

といったような「見えなかったものを見えるようにする」変換作業です。

今まで「経験や勘でしか対処できなかったこと」に対して、

数値的な根拠をもって課題解決、問題解決への新たなアクションへの動機付け・裏付けとする数値や図表を生成・補助するツール

であるべきです。

見える化しようとしているものが、この先の組織の発展にどのように寄与するのか、長期間効果的に運用されるものなのかをしっかり考えてみましょう。

多くの場合、見えたものに対して判断し、行動するのは人間です。

人間がある程度の根拠をもって行動を起こすための判断材料を提供できるかどうか大切です。

ちなみに、

「可視化」と「見える化」は以下のように意味が違うという意見もありますが、正直細かい意味はどうでもよいと思います。

「可視化」：見たいときにだけ見るもの
「見える化」：見たいときだけでなく、否応なく情報が目に入るもの

見える化、可視化は英語ではVisualizationです。

どちらも「見えないものを見えるようにする」ということには変わりなく、結局は見えた後にどう行動するかが本質なので、細かい意味の議論には価値がないと思います。

あわせて読みたい

【FMEAする意味とは…】社内に多くのメリットをもたらすリスク数値化手法

FMEA（故障モード解析）…よく聞くけど実際どんなメリットがあるのか？時間かかるだけでしょ？そうです。時間はかかります！しかし、もたらすメリットはいろんな組織にも波及するのです。後手に回って疲弊することから脱却したいなら、じっくりやってみることを強くおススメします。どんなビジネスでも活用できますよ！

life-notenki.com

2020.05.28

実運用上で想定されるデータメンテナンスの方法

大規模な情報システムになればなるほど、データベースのメンテナンスが重要になってきます。

見える化システムをリリースしても、それだけで終わりではありません。

ヒト、モノ、カネなどのビジネス上の新しいデータは絶えず社内に発生しており、マスタとなるデータベースを更新することはよくあることです。

また多くのデータを蓄積する場合、サーバーへのデータ保存容量を確保するための費用が発生し、さらにデータ保存頻度によっては社内ネットワークのトラフィック（データの送受信）が混雑するため、回線増強なども必要になってきます。

開発を依頼する側は、メンテナンスの運用、データ保存容量・通信頻度も考慮しておかなければ、

・データメンテナンス不備により誤った情報を与える
・トラフィック混雑による社内通信環境のダウン
・サーバー増強による費用増

といったプログラムの仕様以外の問題が運用後に顕在化してきます。

①データメンテナンスについて

たとえば、従業員情報や新商品名などの新しいマスタデータはいつ・誰が・どのようにデータベースに登録するのかを事前に明確にしましょう。

都度、情報処理部門にデータ登録依頼するのか、自分たちで登録するのか、自動で登録できるようにするのかによって費用はもちろん、運用での不具合リスク度合いが変わってきます。

開発予算、データ更新頻度、運用上の問題が与える影響の大きさ、社内で扱うデータ形式を考慮して最適なメンテナンスの仕組を事前に考慮しましょう。

全社的に重要でない開発案件（特定業務や限定的な業務効率化）の場合は、開発コスト（開発工数）を抑えるために、大掛かりなものにならない仕様が良いと思います。

②データ保存容量、更新について

センサーなどから得た新たなデータを、どのくらいの期間保管する必要があるのか、更新の頻度はどれくらいか妥当かを事前に考えましょう。

データ量が多くなれば、それに見合ったストレージの容量が必要になります。

また、データ更新の頻度が多くなれば社内通信ネットワークの通信速度に影響します。

データは必要最小限の保存量に留め、更新頻度も最小限に留めることを意識しておくと良いでしょう。

陳腐化しないような拡張性・汎用性をもたせること

見える化ツールをリリースしても、変わっていくビジネス環境によって使えないものになってしまうこともしばしば。

複数の既存情報システムとデータ連携したツールであればあるほど、他のシステムに変更が入った場合に見える化ツールの信頼性が落ちるリスクが高まります。

特によくあるケースが「データ形式」です。

既存の社内データを収集して加工する場合、扱うデータ形式（文字列、数字の桁など）に基づいて、フィルタリングや分岐処理などを行うようにプログラミングされていきます。

当初想定していたデータ形式が、何らかの理由で拡張（桁数が増えるなど）された場合、見える化ツールが動かなくなることもあります。

動かなくなるだけならいいですが、間違った数字を出し続けてそれに気づけないことが最も恐ろしい状態です。

これを防ぐためには、扱えるデータの桁数をあらかじめ多めに確保しておくことが必要です。

必要になった時にプログラム変更すればいいじゃん！

と思われる方もいるかもしれませんが、プログラム改造すると二次災害がよく発生します。

特に、リリース当時から開発担当者が変わっていると修正すべきポイントが引き継がれていないケースが多く、ツールがうまく動かないことがあります。

それを無理やり修正しようとして新たな処理を加え始めると、つぎはぎだらけの将来誰も触れないプログラムが完成していくのです。

・変わることが少ないデータ形式で一貫したデータベースを用いる
・将来継続して活用するなら扱えるデータ形式に余裕を確保しておく
・なるべく独立したデータベースと直接連携する

などを考慮すると拡張性、汎用性がアップします。

見える化導入で意識すべきこと　まとめ

今回の記事で述べたことは、IT技術者であれば普通に意識していることです。

依頼元が情報技術に長けているわけではないので、開発依頼元からの不十分な要求仕様を基に気を利かせて仕様を詰めていくことが常態化しています。

しかし、情報技術者は依頼元の業務やデータの使われ方を完全に把握しているわけではないので、リリース後の運用で問題が発生するケースが散見されるのです。

依頼する側は、少なくともこの記事で述べた内容を情報技術者に相談するようにしてあげると、技術者も喜んでくれると思います。

そして、最も大切なのは

そもそも「その見える化、必要ですか？」

ということ。

社内のデジタル化に伴い、社内SEは積みあがった開発案件で疲弊しています。
本当に必要なツールとして、会社に貢献できるモノを依頼してあげないと彼らも浮かばれません。

依頼する側は、見える化を行った先のこともイメージすることが大切です。

おわり