これまで余り浮き彫りにされることはありませんでしたが、IT業界において、ここ数年で運用業務が大々的にクローズアップされ始めています。一人前のエンジニアでも「システム運用」について理解している人は多くありません。
ITシステム≒プログラマ・エンジニアと置き換えられることが多かったこれまでと違い、これからのITシステムには運用方面でのスペシャリスト「運用・保守エンジニア」が注目されています。
運用・保守エンジニアとは
システム運用は、サービスが終了するその時までシステムリプレースや機能追加などの体制を維持し、管理し続けなければなりません。そのような長期的な視野に立ってシステム運用を設計し、管理する人材を「運用・保守エンジニア」と呼びます。
本来「運用・保守エンジニア」の業務は「PM（プロジェクトマネージャ）」や「SE（システムエンジニア)」が担う作業とされてきましたが、システムの多様化に伴い、とても「PM」や「SE」では手が回らないのが実情です。
残念ながら、この「運用・保守エンジニア」と言う名称はこれまであまり認知されてきませんでした。近年まで「システム開発≒SE・プログラマ・エンジニア」の領分と捉えられ、「システム運用」を軽視してきたプロジェクトは少なくありません。大きな理由として、発注者がシステム導入に求めているものと、システム運用に求めているものの乖離があるためです。
発注者側がシステム導入に求めているものは「新しいサービスの提供」であり「新たなサービスを得る」ために費用を払っているのに対し、システム運用に求められているものは安定稼働と効率的なサービス提供です。直接的に目で見えるメリットが薄い為、「運用はシステム導入後に残った人材で考えればよい！」となりがちだからです。
そのため、システム導入プロジェクトにおいて運用設計は後回しにされることが多く、結果的にノウハウが溜まりづらく専門家がいない状況が出来上がってしまうことになります。
当然の如く、一流ITベンダーと言われる名だたる企業が出掛けたプロジェクトでさえも、この「システム運用」の属人化が原因で崩壊する事案が次々と表沙汰になってきています。
運用・保守エンジニアの必須スキル
システム運用は大きく分けて「業務運用」「基盤運用」「運用管理」の3分類に分けることが出来ます。「業務運用」は、発注者側の業務色が強く出る為（知識があるに越したことはありませんが）、現場に入ってから知識を習得することになります。
「運用・保守エンジニア」へ課せられる大きな目的の一つは「基盤運用」「運用管理」を仕組化することになります。この２業務に関しては「プログラミングスキル」や「システム構築スキル」は必須スキルとして求められることはありません。
「運用・保守エンジニア」へ求められるスキルは「プロジェクトマネージャ」や「管理者」等、プロジェクトにおける「責任者」と同じ目線で業務を見ることが出来る視野が求められます。
つまり「運用・保守エンジニア」に求められるスキルとして、重要なことは「システムの統一化」及び、「重要度」と「緊急度」を理解している事です。
下記イメージは、コンサル業界では有名な「時間管理のマトリックス」です。
参考例）
あなたは、あるプロジェクトに携わることになりました。そのプロジェクトは常にシステム障害に見舞わられ、殆どのエンジニアは業務時間の大半を障害対応に費やしています。
上記のような状況のプロジェクトに携わった場合、参画したばかりのエンジニアの取る道は、概ね2つに分かれることが経験的に分かっています。
-
- 現在発生している障害対応を支援する。
- なぜこの問題が発生したのか原因を追究する。
１．を選択した場合、今後起こりえる障害に対して、永遠に対応を迫られることになり、あなたが生産性の高い業務につくことは難しくなります。
２．を選択した場合、今後起こりえる同様の障害に対して対策を見つけることになり、時間とともに同種の障害は減ることになります。全体的に時間的余裕が生まれ、プロジェクト全体を「質の高い領域」へシフトさせることが可能になります。
つまり、「運用・保守エンジニア」を目指すあなたの立ち位置は、常に「第二領域」になくてはなりません。
このように「運用・保守エンジニア」に求められるスキルとは、技術的なスキル以前に大きな枠で事象捉え、最適解を導き出せる「コンサルタント」的な視点が必要となります。
運用・保守エンジニアの業務内容
余程、潤沢な予算を持つプロジェクトでない限り、運用設計を行うプロジェクトは多くありません。最近ではその傾向がさらに顕著になりつつあります。
経験的に「運用・保守エンジニア」が求められる状況は、下記のいずれかに該当します。
運用・保守エンジニアが必要とされる状況
- 何をやればこのシステムが維持管理されていくのかわからない。
- 障害や故障が発生した場合、誰に連絡したら良いか分からず、影響が大きくなる。
- スキルの高い担当者への属人化が進み、後任への引継ぎが困難。
- 手順書が存在しない、もしくはメモレベルでしか存在しない為、作業を実施する運用担当者によって結果にバラつきが出る。
- ドキュメントが整理されていないので、改善しようにも何をどうしたらよいかわからない。
最悪な場合、上記のすべてが当てはまるプロジェクトも少なくありません。大抵の場合、運用設計を行わずにシステムをリリースしてしまったことが原因です。実際にリリースしてみたは良いが、うまく運用が回らず膨大な工数を費やし続けていることがほとんどです。
このような状況で求められる「運用・保守エンジニア」は、呼び名こそ違えど、やることは「コンサルタント」とたいして変わりません。まずはどこに問題があるのか、下記のカテゴリ毎に状況を整理し、運用・作業項目の分析から始めることになります。
問題解決の業務分析カテゴリ
- 運用範囲の未整理
- サービスレベルの低下
- 属人化
- サービス品質のばらつき
- ドキュメントが未整理
「プロジェクトマネージャ」は一刻も早く状況の打開を求めてきますが、「運用・保守エンジニア」は決して「第一領域」に組み込まれてはならないことが重要です。常に「第二領域」を意識し、大局的な視野を持って作業することを最優先します。それゆえ「プロジェクトマネージャ」と衝突することも厭わない信念を必要とします。
非常に厳しい職種ですが、最終的にシステム運用の成否は「運用・保守エンジニア」の腕にかかっていると言っても過言ではありません。
運用・保守エンジニアのアサイン契機
大抵の場合、デススパイラルの発生が原因で「運用・保」設計の見直し、もしくは改善を行うことになり、運用・保守のスペシャリスト、「運用・保守エンジニア」がアサインされることになります。
予めシステム運用設計に予算を組み入れるプロジェクトは、余程潤沢な予算を与えられた大企業以外無いと思っていいでしょう。
注意ポイント
残念なことに「運用・保守エンジニア」の業務内容を誤って認識している人を多く見かけます。
- 決まった手順に従って単純な作業をするだけ。
- 関係者間の調整ばかりで、実戦で通用する技術・スキルが身に付かない。
「運用・保守エンジニア」の守備範囲は膨大です。上記は、スキルの見合わない「運用オペレータ」へ、差しさわりのない作業を振り分けているだけの話です。プログラマを例にとれば、プラグラミングスキルの拙い「新米プログラマ」へソースのインデントが乱れてないかチェックを依頼している事と同じです。
「運用・保守エンジニア」の立ち位置を具体的に表現するとすれば、当該プロジェクトにとって「プロパー」or 「パートナ」の場合は「運用・保守エンジニア」と呼ばれることが多く、完全に社外からアサインする外注の場合「コンサルタント」と呼ばれることになります。
「決まった手順に従って・・・」は単なる「運用オペレータ」と呼ばれる職種になります。
IT未経験でも運用・保守エンジニアに転職可能か？
これまで説明してきたように「運用・保守エンジニア」に必要な知識は「業務運用」「基盤運用」「運用管理」の三つです。中でも「業務運用」は現場で覚えることが一般的です。「基盤運用」「運用管理」については、先人たちの努力の甲斐あって既に固定化された方程式が存在します。
「プログラミングスキル」や「システム構築スキル」は、あるに越したことはありませんが必須ではありません。前職で管理職やマネージャの経験があれば十分可能な範囲です。特に相手を理詰めで説得する能力があれば、その後の経験次第でコンサルタントへのキャリアアップも望むことが可能です。
幸いなことに「運用・保守エンジニア」のスキルは、他で培ってきたそれまでのキャリアを引き継ぎやすいのが特徴といえます。IT未経験だからと言って諦める必要はありません。
業務内容を深堀すると、それだけで一冊の本が出来上がってしまうほど「運用・保守エンジニア」の業務内容は膨大ですのでここでは割愛します。
※ 追々運用業務も記事にしていくつもりです。
まとめ
システム開発では、兎角「システム運用」は後回しにされがちです。それが原因で運用がうまく機能せず、毎晩終電まで働くエンジニアが後を絶ちません。市場の人材不足は思ったよりも深刻です。
「プログラマ」や「インフラエンジニア」とは異なり、運用面でのスペシャリストはまだまだ足りない状態です。運用・保守エンジニアにとって「プログラミングスキル」は特に必須な知識ではありません。
作業項目の整理方法や対人交渉能力等、むしろ、これまで他業種で養ってきたキャリアがモノを言うことになるでしょう。
「システム運用」は今後、間違いなく「プログラミングスキル」「インフラ・サーバ構築スキル」と同様にシステム開発には必須のスキルになると思われます。