IT運用管理をめぐる状況は激変、これをチャンスとするには：IT運用担当者が着目すべき「トイル」というキーワード
DXの波により、IT運用管理をめぐる状況は激変している。既存システムの運用はますます効率化が求められ、新たなシステムでは短いリリースサイクルに運用も追随していかなければならない。これらにどう対処するか。「アシスト運用フォーラム」では具体的な解決策が提示された。
IT運用管理を取り巻く状況は、この数年で大きく変化している。クラウドやコンテナ、APIなど新しい管理対象が加わり、DevOpsなどの新しいやり方での運用が求められている。そもそもITがビジネスに直結するようになり、そのためのエンドユーザー向けのITが増えていることから、IT運用管理に求められること自体が、従来とは大きく変わってきた。
IT運用担当者が、この大きな変化を危機ではなく、チャンスと捉えるにはどうしたらいいか。日本企業のITを長年支えてきたアシストは、「トイル」がキーワードになると訴える。同社は2022年6月8日に「アシスト運用フォーラムオンライン2022」を開催、DX（デジタルトランスフォーメーション）推進における運用現場、開発現場での新たな課題と、具体的な解決策を提示した。なお、同イベントは2022年6月30日までオンデマンド配信中だ。
DXが進むと運用現場が疲弊する？
近年、DXやITモダナイズが多くの企業のテーマとなっているが、「従来のIT部門と新しいシステム、サービスを提供する現場の間にひずみが生じている」と、アシスト システム基盤技術本部 事業推進部 部長の坂田真也氏は言う。
DXは、部門横断で新規に設置されたDX推進チームが主導したり、事業部門からの発案で進んだりすることが多い。IT部門の運用担当は、従来のシステムを守りながら、新たにDX関連システムを運用しなければならなくなる。この2つはライフサイクルも運用基盤も異なっているので、運用がサイロ化されやすい。
一方、システム開発の場面では、求められるサービスリリースのスピードが速くなっている。しかし、開発プロセスを変えずに開発スピードを上げると品質は低下する。スピードと品質をどう両立させればいいのか。
アシストでは、「IT部門のDX」実現をゴールとした、「4つの変革アプローチ」を提唱している。変革の阻害要因となるボトルネックを「トイル（どうしても必要だが、自動化や効率化が可能な作業）」と捉えているという。
どこから自動化すれば運用が効率化できるのか
既存システムの運用については、属人化と肥大化が業務改革推進の足かせになっていると感じている企業が多い。運用業務の自動化を進めてきたところでも、個別最適化が進んでしまい、全体として効率化されていないという状況もある。
「各システムの運用は自動化されているが、横のつながりがなく、自動化しきれない部分が残ってしまったり、新たな運用対象の受け入れによって自動化しなければならない項目が増えてしまったりといった課題を挙げる企業が多い」（坂田氏）
課題をまとめると、主に以下のようになる。
- 自動化にかかる工数と、自動化によって減らすことができた運用工数が見合わない
- サイロ化されたシステムごとに運用を自動化していて、全体としてはあまり工数削減になっていない
- 自動化の対象が増え続け、いつまでも効率化できた実感が得られない
このような課題を解決するには、サイロ化したシステム運用を共通基盤上に統合することが必要だ。現場では、「システムの重要度によって、認証の違いや監査内容の違いがあるので、個別に自動化するしかない」という意見もある。とはいえ、共通化した基盤上での自動化ができれば、効率を上げられることは明らかだ。
アシストでは、運用業務効率化について、各企業の段階に合わせたソリューションを提供している。例えば、以下のようなものだ。
何から自動化すれば効果が出るか分からない段階
まず、自社の運用のどこにボトルネックがあるかを洗い出す必要がある。その上で、「課題、目指す姿、改善策」を整理し、効果が高い業務を抽出する。それを実施するのが、「ENISHI運用改善ワークショップ」だ。
STEP1では、運用業務を棚卸しする現状診断サービスを提供する。STEP2〜3では、課題やゴールを明確にするための個別ヒアリングや関係者ワークショップを開催する。ワークショップの結果から「あるべき姿」に向けて効果の高い業務を抽出し、優先度に応じてSTEP4でクイックウィンを意識したシナリオを実施。自動化にトライしてみて、それを横展開する。
「個々に課題をヒアリングし、レポートとして示すと共に、これを題材にワークショップを行い、優先事項の抽出や解決方法の提案などを行う。また、上層部に対しては現場の考えを組み入れたレポートを提出し、トップダウンで進める契機にしていただく」（坂田氏）という。
個別の自動化は進めているが、効果が実感できない段階
個別の自動化は進めているが、効果が実感できないという企業に向けては、日立製作所の「JP1 Cloud Service/Operations Integration（Ops I：オプス・アイ）」を提案する。これは、さまざまな運用業務をコード化して統合管理できる基盤ツールだ。サイロ化したシステム運用を統合するために必要な、運用の標準化、運用要員の共有化、運用の統制が実現する。
1．運用の標準化
システムごとに異なっている手順書を、各システム共通で利用できる運用シナリオの形に標準化しコード化する。これにより、あいまいさがなくなり、変更箇所の視認性も高くなる。コードのバージョン管理を行うため、今後の機能追加などに備えた効率化が可能。また、よく使われる標準的な自動化ツールのシナリオなどはそのまま取り込めるので、これまでの自動化が無駄にならない。
2．運用要員の共有化
要員のスキルを管理し、共有化することで、システム横断で作業を割り当てることが可能になる。これにより、作業を平準化して負担の偏りを減らす。
3．運用の統制
システムごとに散在している作業証跡を集約することで、規格準拠状況の可視化や全体の統制が可能になる。
「運用の効率化にとって、アクセス制御や監査のための証跡管理などは、やらなければいけないことだが、本質的ではない。考えなくてもいいならやりたくない、いわゆるトイルで、Ops Iのような仕組みを入れることで手が離れ、自動化や効率化に注力できるようになる」（坂田氏）
運用効率化のためには開発プロセスの改革も必要
DXやITモダナイズの加速によるスピード感とIT運用現場のひずみは、運用部門の努力だけで解消することはできない。開発の段階から運用の視点が入っていないと、しわ寄せが運用部門にきてしまうからだ。
アシストでは、ボトルネックを解消するための道具立てやサービスをソリューションとして提供している。提供イメージは以下の通りだ。
計画フェーズ
例えば、既存アプリケーションの改修に着目すると、その改修がどこにどのような影響を及ぼすかを調査する。中には「特定のベテランエンジニアの経験と勘で判断しているため、その人のレビュー待ちで時間がかかる」といったボトルネックがある。こうしたボトルネックを解消するための影響調査ツールを提供する。
実装フェーズ
コーディングは、個々のエンジニアのスキルによって品質にばらつきが生じる。少なくとも、コーディングのミスや既知の脆弱（ぜいじゃく）性が混入していないかをあらかじめチェックしておけば、後のフェーズで不具合が判明して差し戻されることが減る。そのためのコード解析ツールを提供する。
テストフェーズ
省力化しつつ確実にテストを実施するには、テスト全体を自動化するツールや、開発チームがボタンを押すだけでテスト環境が自動構築できるような仕組みが必要だ。
展開フェーズ
本番環境へのデプロイを自動化し、作業を軽減するとともに確実に実施するツールを提供する。
例えば、受け入れテストや負荷テストは、システムごとに環境を作り直すのが普通だ。開発者にとっては、残業してやっとコードを修正し、テスト環境構築を依頼しても、「明日の午後まで待って」と言われるかもしれない。運用チームとしては、対象システムがたくさんあるので、言われてもすぐに作業に入れるとは限らないからだ。このような待ち時間は、開発プロセスの至る所に存在する。半日のタイムロスが10カ所で発生すれば、5日間の遅延となる。
しかしこれは、運用チームでテスト環境構築をコード化しておき、開発チームがボタンを押しさえすればテスト環境が自動構築できるような仕組みがあれば、解消できる。すなわち、自動化すれば「開発チームが運用チームに手動での環境構築を依頼する」というトイルが解消できるということだ。
ただし、ソリューションのコンセプトや意義が納得できたとしても、「自分たちの開発プロセスで、どこにボトルネックがあるのか分からない」というケースもある。それを解消するために提供しているのが、「開発プロセス可視化サービス」だ。「VSM（バリューストリームマッピング）」と呼ばれる手法を使っている。
VSMでは、関係者が集まって開発プロセスで実際にやっていることを付箋紙に書き出し、時系列に並べてホワイトボードに貼っていく。さらに、明確でない部分は関係者間で話し合って明確にしていく。これによって、どこにボトルネックがあるのかをあぶり出す。外資系企業やマーケティング部門などでおなじみの風景だが、製造業でもよく利用されている。
アシストがファシリテーターとなってVSMを実施することで、個々のメンバーの頭の中にはあるが共有できていないことや、「何となく感じていたけれど、このプロセスは無駄だな」といったことがチーム全体の課題感となり、どのように解決すべきか検討するステップに進めるようになる。
その後の各フェーズについては、次の図の通り。テストツールとしては、日本市場でも実績のあるマイクロフォーカスの機能テストツール「Micro Focus UFT One」と負荷テストツール「Micro Focus LoadRunner Professional」を提供している。また、テスト環境準備の効率が悪いなら、レッドハットの「Red Hat Ansible Automation Platform」で環境構築を自動化する。
ここで、マイクロフォーカスのソースコードの静的解析ツール「Micro Focus Fortify Static Code Analyzer」（以下、Fortify）について、少し解説する。
実は、書き上げたコードを後から見直しても、何千行（場合によっては何万行）ものテキストからミスを見つけるのは難しい。このため、機能テストや、複数アプリケーションを連携して実際にユーザーが使えるかというテストの段階以降のフェーズで不具合が見つかることがほとんどだ。
それを防ぐのがFortifyだ。書いたコードをFortifyに取り込むと、自動的にチェックし、不具合を修正。脆弱性の混入を指摘し、どう直すべきかも提案してくれる。書きながら随時Fortifyでチェックすれば、コーディング全体にかかる時間が短縮できる。
「開発プロセス全体を見渡して、スピードと品質を両立できる道具立てを用意している。それら全部を使っていただく必要はなく、お客さまの開発プロセスの中で、ここはボトルネックで、自動化すれば効果があるというポイントに当て込めるよう、フェーズに分けて商材をそろえている。個々のツールを提供するだけでなく、お客さまの課題に沿って最も効果的な組み合わせで使いこなしていただけるように、伴走型でお手伝いする」（技術1部 部長 若月恵介氏）
アシストでは、このようなソリューションを積み上げていくことで、運用そのものをトランスフォーメーションすることをゴールとして見据えている。
アシストは、IT部門の現場をよく知っている。そして、今のDXブームでニーズや環境が変化し、現場がどのように困っているかも理解している。その現場の気持ちに寄り添いながらも、時代の流れにうまく乗るための道具立てやサービスを取りそろえ、各企業の事情に合わせて提案している。どこを自動化すればいいか分かっていて、あとはいいツールと信頼できる代理店を探しているという企業はもちろんだが、どこがボトルネックか分からないと暗中模索の企業も、アシストのドアをたたいてみると光明が見えるかもしれない。
販売元：株式会社アシスト
サービス
・ENISHI運用改善ワークショップ
・開発プロセス可視化サービス
プロダクト
開発元：株式会社日立製作所
・JP1 Cloud Service/Operations Integration
開発元：マイクロフォーカスエンタープライズ株式会社
・Micro Focus Fortify Static Code Analyzer、Micro Focus LoadRunner Professional、Micro Focus UFT One
開発元：ジーティーワン株式会社
・ChangeMiner
開発元：株式会社ジェニファーソフト
・JENNIFER
開発元：レッドハット株式会社
・Red Hat Ansible Automation Platform
Copyright © ITmedia, Inc. All Rights Reserved.
提供：株式会社アシスト
アイティメディア営業企画／制作：＠IT 編集部／掲載内容有効期限：2022年7月13日
