IT 自動化コードも牛のように扱いましょう。
IT 部門は、IT を動かすコードの標準化を受け入れなければ、IT 自動化の経済的メリットと有効性メリットを奪ってしまうシステムを作成するリスクを負うことになります。
私はほぼ10年をソフトウェア開発に費やしました。 組み込みソフトウェア。 Web ソフトウェア。 クライアント サーバー ソフトウェア。 ミドルウェアおよびメインフレーム ソフトウェア。 私は専門的に 9 つの異なる言語でコードを書いてきました。 興味深いことに、同じ組織で 2 つ以上の言語を使用したことは覚えていません。
ほとんどの企業組織では、サーバー、プラットフォーム、フレームワークだけでなく、言語も標準化しています。 数分以上、場合によっては数十年に及ぶ寿命を持つソフトウェアには、保守性という目標があります。 保守性とは、ソフトウェアの寿命がどのように測定されるかに関係なく、ソフトウェアを他の誰かが取り上げて、そのライフサイクル全体にわたってサポートできるようにするソフトウェアの特性です。 これは多くの場合、開発者の離職や言語能力を持つ人材の市場における不足、トレーニングや一般的なメンテナンスのコストが原因です。 原則として、企業はプログラミング言語を標準化します。
これは、非常に多様な（多言語）言語セットをサポートできることを利点として売りにしているマイクロサービスやサーバーレス コンピューティングの現在のトレンドとは相容れないものです。 Bob と彼のチームは Go で開発し、Alice と彼女のチームは C または Java または Lambda で開発できます。 確かに開発者（それぞれにお気に入りの言語を持っている）にとってはメリットですが、長期にわたってそのソフトウェアを維持する必要がある企業組織にとってはあまり良いことではありません。 API により統合と使用が可能になり、アプリケーション開発の観点では実装言語はほとんど無関係になりますが、企業では基礎となるコードを依然として維持する必要があります。
IT 自動化 (ビジネスの生産側で発生する内部デジタル変革) に関しては、組織は、それをサポートするため構築されているスクリプトとシステムの標準化の利点だけでなく、標準化を行わない場合の落とし穴も認識することが重要です。 なぜなら、これらのシステムは来週、来月、あるいは来年に捨てるつもりで構築しているわけではないからです。 これらは、今後何年にもわたって展開のデジタル化をサポートする長期的な投資です。 それは、世界中の企業のアプリ開発者が何十年にもわたって学んだベストプラクティスを基に、柔軟でありながら強固な基盤を築くことを意味し、その第一は標準化です。
1. 保守性
あなたは PERL で書くのが好きですが、他の人は皆 Python を使っているのは知っています。 お気に入りの言語で自動化を開発すると、それが自分のお気に入りになり、将来誰もそれを保守できなくなります。 それはあなたにとって良くないことです。なぜなら、あなたが8歳のときに両親にねだった金魚と同じように、その物と何年も付き合わなければならないからです。 これは組織にとって悪いことです。なぜなら、あなたが退職すると、組織は維持できないコードを抱えることになり、サポートに苦労する可能性があるからです。 SIG と O'Reilly が 2016 年に実施した調査では、「回答者の 70% が、パフォーマンスやセキュリティと比較しても、保守性は測定すべきコードの最も重要な側面であると考えている」ことがわかりました。
それはとても重要なのです。 スクリプトとシステムを、現在および将来にわたって IT 部門の大多数の担当者が簡単に変更およびサポートできる共有リソースとして見てください。
2. 互換性
ますます多くの IT サービスがソフトウェアとして実装されるにつれて、それを最新の状態に保ち、他のシステムとの互換性を維持する作業が増加します。 REST API によって「下位互換性」の問題が解消されると考えているなら、考え直してください。 API は製品であり（またはそうあるべきであり）、したがって常に進化しています。 そして、同じ製品ライン間でも差異があり、バージョンごとに API が異なる「ネットワーク」では、標準化がシシュフォスの苦役となるなど、状況はさらに悪化します。 これは非常に広範囲にわたる問題であり、 Smart Bear の 2016 年 API 状況レポートの回答者の 4 人に 1 人によると、API 標準化は今後数年間で解決する必要がある技術課題のリストで 3 位にランクされています。
また、IT で使用される言語の多くはインタープリタ型であるため、バージョン間の変更によって、慎重に設計された自動化スクリプトやシステムが破壊される可能性があります。 node.js のバージョンを変更すると、スクリプトの破損から予期しない動作まで、大きな悪影響が生じる可能性があります。 スクリプト環境と言語の安定したバージョンを標準化すると、このような変更の影響を最小限に抑えることができます。
また、自動化を支える基盤となるすべてのシステムのパッチとアップグレードを管理する必要があるため、数は少ないほど良いと言えます。
3. トラブルシューティング
標準化を無視すると、トラブルシューティングに問題が生じます。 これは、IT KPI の解決までの時間に基づく指標に移行する場合に特に重要です。 問題の発見に時間がかかるほど、その指標は悪くなります。 標準化は、解決までの時間を短縮するための重要な要素です。 もしボブがスタッフの中で唯一の Python エキスパートであり、彼が休暇中（そして連絡が取れない）で彼のスクリプトが壊れた場合、トラブルシューティングを担当する人は長い一週間を過ごすことになるでしょう。 IT 部門に独自の専門用語の使用を促すと、他の部門が問題をトラブルシューティングして解決する能力が大幅に制限されます。 ボブが休暇中でなく、問題を見つけられなかったとしても、助けてくれる人はほとんどいません。
これは、手を出してはいけない領域です。 InitialStateによると、バグを修正するのにかかる時間は、コードを 1 行書くよりも 30 倍長いそうです。 よく知らないコードのバグを見つけて修正するのに苦労しながら、お金がゆっくりとシュレッダーに流されていく様子を想像してみてください。 あまりいいイメージではありません。 トラブルシューティングのコストをなくすことはできませんが、そもそも言語を知らない人に必要な追加時間を排除することで、コストを抑えることはできます。 生産においては、時間はお金です。そのため、解決までの時間を短縮するためにできることは何でも非常に重要です。
そのため、IT が徐々にスクリプト言語、ツール、システムを採用するにつれて、アプリ開発と同期することは悪い考えではありません。 IT 部門が同じシステムと言語 (または少なくともその一部) を標準化すると、トラブルシューティングやコードレビューなどの開発関連のプロセスを支援できる専門家の軍団が得られます。 問題が発生する前にバグを見つける手段としてコードレビューを実装しているからですよね? 右？
標準化はコスト上昇に対抗する手段として挙げられており、そうした取り組みに大きく貢献していることは間違いありません。 しかし、標準化には、技術的負債の最小化、解決までの時間の短縮、日常的な運用保守の簡素化など、さまざまな利点もあります。 まったく標準化を行わないと、複雑さとボトルネックが生じて自動化のメリットが打ち消され、ビジネスの成長に必要な利益と生産性の実現が妨げられ、予算と時間に逆効果となることは間違いありません。 IT 自動化の取り組みを開始するとき、または継続するときには、スクリプトとシステムを個人のペットではなく、家畜のように扱うことを忘れないでください。 ペットには継続的な個人的な配慮が必要であり、IT 部門では対応できないからです。