BLOG

Garbage In, Garbage Out(GIGO、無意味なデータを入力しても無意味な結果しか得られない):壊れたプロセスを自動化してはならない

  • Share to Facebook
  • Share to Twitter
  • Share to Linkedin
  • Share via AddThis
nintex-broken-processes

若い頃に在籍していた会社で同社初のインターネット対応アプリケーションをリリースしたことがありますが、私はその準備作業から貴重な教訓を学びました。重要なのはテクノロジーではなく、インターネットでもありません。重要なのはプロセスであり、どれほどそのプロセスがその人にとって、ストレスを与えるものになり得るかが重要なのです。

ここで必要なのは、トラフィックがアプリケーションに到達する際にファイアウォールの役割を果たすシンプルなルールです。ただひとつのルールです。

ネットワークエンジニアが変更自体に費やした時間は、ログイン、コマンド入力、およびコンフィグレーション保存を含めて5分程度と思われます。しかし、そのためのプロセスには数週間を要しました。

これはプロセスが、(1)文書化されておらず、(2)ハードコピーの承認申請書には少なくとも3名の署名が求められたためです。そしてこのような署名は誰かが休暇から戻るまで放置されたり、誰かのデスク上で埋もれていたりしたあげく、「再発見」されることもあります。

とはいえ最終的には承認が得られ、変更が行われ、担当者は表彰されることもあります。

それから何年も経った現在、プロセスは依然として従業員にとっての苦労の大きな原因です。このような状況を把握するためにNintex社が最近行った調査では、プロセスが確かに不満の原因であり、多くの組織では従業員が退職する原因にもなっていることがわかりました。

実際に転職を考えている従業員のうちITプロセスに問題があると回答したのは72%に達しましたが、調査対象となった従業員全体では58%に留まりました。問題があると指摘されたその他のプロセスには、印刷や(印刷すら問題になります)、昇級や昇進などの人事管理関連のものがありました。

この調査全体からNintex社は、米国企業において最も問題のあるプロセスは「テクノロジー関連のトラブルシューティング」と、「優れた業務達成を可能にするツールと文書へのアクセス」であると結論づけました。このレポートはさらに、「ITサービスをすぐに得られない場合、従業員はシャドーITに頼り、このような業務慣行は本質的に企業にリスクをもたらす」と述べています。

F5が行った同様の調査からも、生産パイプラインに関わるプロセスに対してDevOpsが同様の不満を抱いていることが明らかになっています。調査では、DevOpsの4人に1人(27%)は、生産パイプラインへのアクセスを自動化によるセルフサービスで行えない場合、そのことがクラウドベースのソリューションを使用するという判断に「非常に」影響すると回答し、また38%は「ある程度」影響すると回答しています。

プロセスはビジネスと業務運営の両方にとって非常に重要です。

またこの重要性は、生産性や効率改善のためプロセスのコード化(自動化)を進めようとするデジタルトランスフォーメーションにおいてさらに高まります。

このNintex社の調査は、企業や組織がデジタルトランスフォーメーションに期待する(求める)メリットを検証した、F5の『2018年版 アプリケーションデリバリの状況』調査からの結果の解釈に役立ちます。

このメリットとして最上位に挙げられたのは「ITの最適化」でした。3番目には「ビジネスプロセスの最適化」がランクされました。

何が重視されているかもうおわかりですね?

企業や組織は効率改善を期待してデジタルトランスフォーメーションへの投資を行っています。つまるところ、「状況やリソースを最も効率的に活用すること」が求められているためです。

ちなみにこの定義は辞書から取ったもので、私が作ったものではありません。

最適化においてはまずプロセスを理解する必要があります。新しい仮想マシンやコンテナ環境の要請、文書の印刷、あるいは休暇の申請など、あらゆるプロセスを目に見える形で示さなければなりません。

どのプロセスを最適化すべきかの判断は、これを行って初めて可能になります。またこれは、ビジネスプロセスマネジメント(BPM)システムに、あるいはプロセスを実際に実行するスクリプトやテンプレートにそれをコードとして入力する以前に行わなければなりません。

なぜなら、Garbage In, Garbage Out(GIGO)とは、単にデータやコードに対するデベロッパーの感想ではないからです。これはすべてのプロセスに当てはまります。出来の悪いプロセスを自動化しても出来の悪い結果しか得られません。その出来の悪い結果が、手作業で行う場合よりもより速く得られるようになるだけです。

ITであれビジネスプロセスであれ、最適化を求める場合にはまず何を最適化しようとしているかを理解する必要があります。ビジネスプロセスを構成する個々のタスクからなるバリューストリームを正確に把握し、「これまでそうしてきた」ということ以外にビジネスや業務運営にとって意味のないものを排除しなければなりません。

また、このような不要なステップはITプロセスにも存在します。必要のない承認も存在します。依存関係が存在しないため、待つ必要のないタスクの完了を待っていることもあります。社内のデジタルトランスフォーメーションにおいて、要請を満たすため必要な技術的ステップが自動化によって劇的に変革されることもありません。しかし、非効率なことや不要な待ち時間などを明らかにすることにより、業務プロセスを劇的に変革することは可能です。

最適化とはITとビジネスを高速化することです。ただし、これはITとビジネスをよりスマートにすることから始まります。

orgs expect dx benefits soad18

Connect with F5

F5 Labs

The latest in application threat intelligence.

DevCentral

The F5 community for discussion forums and expert articles.

F5 Newsroom

News, F5 blogs, and more.