DevOpsツールを闇雲に導入しても、その効果を引き出し切れない。活用する理由をチームに浸透させるなど、導入前の受け入れ体制の整備が肝心だ。ツールを120％使いこなす現場のエンジニアたちがノウハウを明かした。
工夫1
DevOpsツールの導入前に
インフラや運用手順を標準化する
第二システム本部 オープンシステム開発部 上席課長代理
DevOpsツールを本格的に活用したければ、ぜひとも事前にサーバー、ミドルウエアなどのインフラや、システムを運用する手順を標準化しておきたい。DevOpsツールが効果を発揮しやすくなるからだ。
標準化が重要な理由は、環境構築の作業をChefで自動化するケースが分かりやすい。Chefでは環境構築の設定手順であるレシピを記述する。業務アプリケーションごとにインフラがバラバラであれば、それぞれにレシピを用意しなければならず、その工数が意外と大きい。自動化によって環境構築作業を短縮する効果が、レシピを作る作業の手間で相殺されてしまう。
120システムを17パターンに集約
そこで私たちのチームは事前に、運用する120の業務システムのインフラや運用手順を調査して標準化に取り組んだ。アプリケーションサーバーやデータベースサーバー、ネットワークといったインフラの種類と、バックアップを取る頻度や監視の有無といった運用項目の違いによって、17のパターンに絞り込んだ。各システムの更改時期に、いずれかのパターンに当てはまるように移し替える。
既に50近いシステムを標準化し終わり、残りのシステムも今後2年ほどで移行する。標準パターンに切り替えたシステムでは、DevOpsツールの効果を十分に享受できている。
標準化は後々の運用にもメリットが大きい。例えば標準的な環境で構成するあるシステムに問題が発生したとき、同じ構成の他のシステムも影響を受けるかどうかを判断しやすい。問題に対処するためにDevOpsツールの設定を変更する必要になった場合も、その手間が最小限で済む。（談）
工夫2
なぜツールを使うのか、
メンバーが納得する機会を設ける
企画本部 業務管理統括部 情報システム部 部長
新しいツールを導入する際には、「なぜこのツールを活用するのか」という理由を、チームのメンバーがしっかりと理解し、納得するための機会を設けることが大切だ。メンバーが納得して使ってこそ、ツールは十分な効果を発揮する。
私たちのチームでは、ITIL（Information Technology Infrastructure Library）に準拠した保守開発のプロセスを策定し、そのプロセスを回すためにツールを導入した（p.41を参照）。メンバーからすれば、途中経過の情報をその都度ツールに書き込んだり、上司の承認を得たりする手間が増えたことになる。メンバーがツールを使う必要性について理解していなければ「なぜこんな面倒な手続きを踏まないといけないのか」と疑問を抱いてもおかしくはない。しっかりと説明する必要がある。
資格取得を奨励し、勉強会を開催
ただし、ソフトウエアの改修に伴って障害を発生させないためのプロセスであり、そのプロセスを回すためのツールであると説明するだけでは工夫が足りない。それではメンバー全員が確実に理解・納得するとは限らない。
そこで私たちのチームでは、メンバー全員が「ITILファウンデーション」の資格取得を目指すことにした。資格を取得する勉強の過程で、チームが策定したITIL準拠の保守開発プロセスと、ツールを活用する必要性を学び、納得感を得やすくなると考えたのだ。勉強会は既に2回開いた。
これまでにメンバーの27人中、22人が資格を取得した。このようにツール活用の理由を納得する機会を設けたことが功を奏し、現場でのツール活用が円滑に進んだと考えている。（談）