BT

最新技術を追い求めるデベロッパのための情報コミュニティ

寄稿

Topics

地域を選ぶ

InfoQ ホームページ ニュース 古いシステムと現代的な技術のギャップを埋める

古いシステムと現代的な技術のギャップを埋める

ブックマーク

原文(投稿日:2017/05/25)へのリンク

手動で時間のかかるやり方で管理されている、長年動かし続けているプラットフォームはコストがかかる。チームは経営陣に対してビジネスケースを作ることで、繰り返し作業やヒューマンエラーで失われた時間に基づいて、自動化ツールやコンテナのような現代的な技術を導入して改善ができる。結果として、配置作業は予測可能で反復的なプロセスになり、配置も頻繁かつ安全に行えるようになり、人間の介在も最小限になる。

Walt Disney CompanyのシニアシステムエンジニアであるMichael Jenkins氏はCraft 2017でレガシなプロセスに現代的なコンセプトを注入することについて話した。InfoQでは、このカンファレンスの模様を記事やインタビューで取り上げている。

レガシなプロセスを変えるにはまずビジネスケースを構築する必要がある。Injecting Modern Concepts into Legacy Processesと題した記事でMichael Jenkins氏はこれを実現する方法について書いている。

新しいツールの魅惑をかわして、正しいツールを見つける方法の一つは辛い点について考えることです。開発者、あるいはシステム管理者としてのあなたを遅くしているのは何でしょうか。何度も問題を起こし、その度に復旧させるという辛い反復を生み出しているものは何でしょうか。新しいツールや手法はこれらの問題を解決しますか。するとしたらどのようにしますか。

辛い点にフォーカスすると同時に、改善の度合いを示すメトリクスを集めます。例えば、手動での配置が数時間かかり、自動化ツールで数時んに短縮されうるのであれば、とても説得力があります。また、メトリクスによって発言を支える事実という武器を手にすることができ、質問に答えられます。

そして、なぜ変える必要があるのは、どのくらい生産性が改善するのか、というビジネスケースが作りたくなるでしょう。

InfoQはMichael Jenkins氏にインタビューしてレガシなプロセスに現代的なやり方を導入することについて話を聞いた。

InfoQ: レガシなプロセスの主要な問題とは何でしょうか。

Michael Jenkins: レガシなプロセスには二つの大きな問題があります。技術的負債と手動の作業です。多くの場合、レガシなプロセスはソフトウェアやオペレーティングシステムの特定のバージョン、さらには特定のハードウェアに結びついています。この技術的負債がプロセスの改善を難しくします。また、レガシなプロセスに多くの手動の操作が含まれているのもよくあることです。この場合、ヒューマンエラーが発生します。また、自動化していたら避けられたかもしれない問題も発生します。開発者や管理者を手動のタスクの管理から自由にすれば、彼らはイノベーティブなことにより多くの時間を使えるようになります。

InfoQ: プロセスを変えるためのビジネスケースはどのように作成しますか。

Jenkins: ビジネスケースを作る最良の方法は時間や利益の観点で一番コストがかかっているプロセスの一部分に着目することです。この方法を採用するのが難しい開発者や管理者もいます。というのは、企業のボトムラインだと、自分たちが管理しているアプリケーションやシステムの価値の全体を把握できない場合があるからです。把握できるのは繰り返し作業やヒューマンエラーによって発生する再作業で失われる時間です。もし、経営陣に対して問題の再発生で失われる時間の観点から意見が述べられるのであれば、これはビジネスケースの基礎になります。経営陣は失われた時間を企業のコストとして解釈するでしょう。一方、開発者や管理者がアプリケーションや製品の利益についてある程度詳しいなら、アプリケーションがオフラインになってしまったときに会社にどのくらいの損失を生み出しているのかを言うことができるでしょう。

InfoQ: 周囲を巻き込むために変化を味方にするにはどうしたらいいでしょうか。

Jenkins: 変化の主導者が告発者のように感じられるなら巻き込むのは難しいでしょう。しかし、そのようにする必要はありません。すでにあるコミュニケーションチャンネル、例えば、チームミーティングやリーダーや経営陣とのワンオンワンミーティングを使うのがお薦めです。開発と運用は対処する必要がある問題についての経験を共有できます。実際、このような問題がビジネスケースの元になりえます。例えば、繰り返し発生する問題を解決するのに費やした時間について説明し、この時間が他の作業からどのように奪われてしまったかを示します。変化を提案する人が望めば、ビジネスケースを共有することもできます。作業がチームの環境の中で行われているなら、チームメイトや同僚からインプットをもらうのもいいでしょう。レガシなプロセスが日々の業務の背後にある複数のビジネス領域に影響している場合もあります。その場合は、主導者を助けてくれ、複数の領域に価値を示す人やチームがいるかもしれません。どのようなケースであれ、経験を共有し、味方を見つけるのが一番良いやり方です。

氏はブログに、運用と開発がどのように協力するか、そして、アプリケーションパフォーマンス管理(APM)のデータを使ってどこに改善が必要なのかを調べることについて書いている。

APMを導入することでアプリケーションの実行とアプリケーションを実行しているサーバに対するより深い洞察が得られます。問題が発生しダウンタイムが発生した場合、開発者も運用担当者もAPMのデータを使って何がおかしくなったかを調べ、同じことが再度発生しないように対策を打つことができます。

問題を特定し解決する視点から、開発者と運用担当者は共通の関心事を共有します。

InfoQ: あなたは講演で手動の配置から自動化された配置に移行した企業について話しました。最大のハードルは何でしたか、そして彼らはどのように対処しましたか。

Jenkins: 現在のビルドプロセスを壊さない、と言うことが最大のハードルでした。これを"走っている自動車のタイヤを交換する"というように表現する人もいます。実際、私たちはどの部分が自動化できるのかを特定し、何も壊さずに徐々に大きな図に近づいていくような作業の仕方を見つける必要がありました。小さく始めて、その他の部分が同じままで変えられる部分を特定することで、対処しました。そして、プロセス全体の再作成されるまで部分から別の部分へと動きます。例えば、3つの異なるアプリケーションが3つの異なるプロダクション環境に全く同じ配置プロセスで配置されているとします。サーバ名の読み取りミスなどのエラーのため、管理者が間違ったサーバに配置してしまうということがたびたび発生していました。これに対処するため、私たちはリポジトリのURLを配置のインプットとして使い、サーバの選択を自動化しました。これで問題が解決しました。正しいサーバが選択されるようになったら、後続の配置プロセスが自動化できます。そして、このようなことを繰り返して可能な限りプロセス全体を自動化しました。

InfoQ: レガシなプロセスを変えることからどのような利点が得られましたか。

Jenkins: 配置が予測可能であり反復可能になったことが最大の利点です。前述の通り、配置に必要な唯一のインプットがリポジトリのURLです。後続のすべてのプロセスは自動化されているので、ヒューマンエラーは根本的に取り除かれています。人間の介在を最小限にしているので、ヒューマンエラーで配置プロセスが脱線するポイントが取り除かれています。問題解決に時間がかからないこと、間違った配置のロールバックに時間がかからないこと、頻繁にかつ安全に配置できることが得られた利点です。これによって管理者は革新的なことに時間を使ったり、他の領域に貢献したりできるようになりました。

 
 

Rate this Article

Adoption Stage
Style
 
 

この記事に星をつける

おすすめ度
スタイル

BT