このブログを読んでいるあなたは、システムエンジニアがどのような仕事をしているのか調べている最中でしょうか。「IT業界は人手不足で引く手あまた」とか「フリーランスで気軽に働ける」とか、巷には聞こえの良い情報ばかり溢れています。でも、聞こえの良い情報ばかりだからこそ、ネガティブな側面を見てほしいと私は考えます。なぜなら、せっかく努力してスキルを身に着けて転職しても、理想と現実とのギャップに苦しんでしまうからです。
この記事ではシステムエンジニアの運営業務の実情から、システムエンジニアがモチベーションを下げてしまう”トリガ”について書いてみました。これは、システムエンジニアの仕事について調べている方だけではなく、最近になって運営担当の元気がないことに気がついた管理者の方や、現在運営を担当していて、将来に不安を抱えているシステムエンジニアにもお役に立てる情報だと考えています。
私の認識だと、運営担当がモチベーションを下げてしまう”最凶”のトリガは、
「開発業務と運営業務の比較」
です。これから詳しく解説していきます。
運営業務の特徴
管理職の方は、運営業務の大切さを身にしみて分かっているのではないでしょうか。システムにトラブルが発生したら昼夜問わず駆けつけ、できる限り早く復旧させてユーザの満足度を高めるという非常に重要なミッションを持っているからです。運営業務の特徴として以下の3点が挙げられます；
- オンのときの過剰な業務負担
- トラブル対応中の過剰な言葉遣い
- トラブルを早期復旧できて当たり前という考え方
1点めに、運営担当の業務負担についてです。ユーザがシステムを使うことができないという状況が、ユーザの満足度を低下させてしまう一番の原因なので、運営担当は、昼夜問わず現場に駆けつけたり、リモートで対応したりします。また、トラブルの内容によって数十分で対応終了できる事象もあれば、月単位で対応するインシデントもあります。オンのときは本当に大変な業務です。その代わりオフのときは、監視ログにも何も上がってこないので、電話も鳴らず定時退社できます。
2点目は、コミュニケーションについてです。トラブルが発生したときは、複数人で対応することもあります。問題になるのはその時の言葉遣いです。対応中はどうしてもスイッチが入ってしまうので、「なんで言ったことがわからないんだ！」とか「ちげーだろ！」のようにあたりが強くなってしまいがちです。また、お客さまからも「こんなんじゃ使い物にならない。」とか「早く直して。」のように、きつい言い方をされることもあります。お互い冷静にコミュニケーションを取ることができればよいのですが、人間いっぱいいっぱいになるとなかなか難しいようです。
3点目は、エンジニアの評価方法です。オンのときはとんでもなくきつい思いをするのですが、それらがどこまで考慮されて評価されているのか全くわからないのです。システムは動いてなんぼとお客さまからは思われているので、復旧して当然という扱いを受けてしまいます。私達は、評価とはプラスアルファを指しているとなんとなく思っておりますが、運営業務はマイナスをゼロに持っていく業務になりますのでプラスではありません。
隣の芝生は青く見える
さて、こういった状況に対して、経験年数数年の若いシステムエンジニアはどう思っているしょうか。もしかしたら、オンオフの差が激しくて、昼夜問わず電話が来て、トラブルが発生しているから周りの気が立っていて・・・でも日が当たらないというようなネガティブな部分ばかりが気になっているかもしれません。そのような状態の中、隣の開発部を見てみればどうでしょうか。お客さまと名刺を交換して打合せして設計書を作成して・・・よく見るビジネスシーンで仕事を頑張っていて、まるで輝いて見えるかもしれません。お客さまに納品して間近で喜んでもらっているところを見るとプラスアルファにも今後のモチベーションにも繋がりますよね。また、運営側でトラブルが発生しておらず定時で帰宅している横で、一生懸命設計書を作成したり議論し合っている開発担当を見たらどうでしょうか。やっぱり気になりますよね。
そうなんです、運営担当がモチベーションを下げてしまうトリガは、「開発業務との比較」なんです。
トリガを引かせないようにするために、どうするべきか
それでは、そのトリガを引かせないようにするためにはどうしたらいいのか。私は以下のようにするべきだと考えています。
「開発業務と運営業務の兼務」と「運営業務の評価方法の明確化」
開発業務と運営業務を兼務するなんて体がいくつあっても足りないと思われるかもしれません。しかし、常時兼務ではなく例えば開発メンバーの中から当番制で運営を行ったり、運営と開発を開発の目処で交代するなど、各会社の風土や特性により様々なやり方があると思います。
そもそも運営業務とは、ハードウェア、ソフトウェア問わず、周りと連携して、何が原因なのかを探っていき、そこから復旧手段を考える。そして振返りを行い、自分に不足していた経験を補うというITと社会人としての総合力が試される業務です。そのため、開発、運営のどちらも経験したほうが、エンジニアや社会人としての成長につながるのです。
評価方法の明確化については、どのようにプロセスに焦点を当てられるかが大切だと考えています。単純に復旧までの時間が早かったではなく、どのような経緯で事象の発生と判断できたのか、どのような視点で原因の特定に至ったのか、どのような手順で復旧させたのか、これらを職場としての再現性のある成功体験として共有し、担当者を労うことができる風土づくりを行うべきなのではないかと考えています。
まだまだ私も経験年数が浅いですが、運営業務をこなせるエンジニアのことは、素直にすごいと思っています。そんなエンジニアがモチベーションを下げないように、この記事で少しでも協力ができたら幸いです。
コメント