社内SEからのコンサル転職〜⑥システム知識0がインフラ担当になったら〜

前回までのあらすじ

古株社員がやっている業務端末管理業務を一緒にやることになり、属人化された業務の進め方に納得できず対立を繰り返した結果、転職を考えたりメンタルに不調が起きたりしました。それを課長が見かねたのか、別の業務を担当することになりました。

前回のお話はこちら↓

知識ゼロからのインフラ担当

私は古株さんと行っていた業務端末管理の担当からは外れ、ヘルパーさん業務と兼任の形で新しくインフラ案件の管理を行う担当になりました。
ハード・ソフトのEOS（保守切れ）に伴うシステム更改や、現行システムの導入製品のバージョンアップやセキュリティパッチの適用等、システム基盤維持のための案件の発注手続き、ベンダー管理が主な業務となります。
会社のほぼ全システムのインフラ案件管理を、前職エンジニアでIT知識が豊富なチームリーダーと、以前はアプリの開発案件を担当していた先輩（以降Aさん）と、私の3人体制で見ることになりました。
インフラ案件の管理は2年間担当することになりますが、自分が最も役に立たなかった期間でした。当時面倒を見てくれたチームリーダーには今でも申し訳ないと思っています。私がどのように2年間を過ごしてきたか、ここから書いていこうと思います。

1日中理解できない会議に出る毎日

先ほど業務内容は案件の発注手続きやベンダー管理と書きましたが、具体的にはベンダーとの会議が大半を占めました。打ち合わせのラインナップはこんな感じです。

・システム更改案件の進捗会議
・これから始まるシステム更改案件の見積もり説明
・システムメンテナンス作業計画の説明
・本番作業の判定会議
・過去発生した障害の恒久対応、再発防止の説明...etc

どこの会社の情シスでもあるような会議だと思いますが、会社のシステムほぼすべてのインフラを担当していたので、会議の数が膨大になっていました。基本的に1日の半分は打ち合わせ、始業〜定時まで会議という日も頻繁にありました。この仕事の大半を占める会議で、私は何の役割も果たすことができていませんでした。
資料の作成や説明はベンダー側の担当なので、情シス側は説明された内容に対する質問、指摘や、意思決定をすることになるのですが、これまで業務端末の管理とヘルパーさん業務しかしてこなかった私は会議の内容を全く理解できませんでした。
例えば「WASのバグフィックス適用作業計画」の説明をする会議があったとします。まずWASが何かわからない。バグフィックスの適用ってどんなことするのかわからない。WASってどのシステムのものかもわからない。
こんな状態で作業としてどんなリスクがあるかとか、問題があったときにどこに影響するかとかわかるわけもなく、ただ会議を聞くことしかできませんでした。
会議にはチームリーダーも先輩もいつも一緒に出席しており、承認などの意思決定はチームリーダーがすることになっていました。チームリーダーは前職の知識が豊富で、説明された内容を正確に理解し、いつも的確な判断をしていましたので、ベンダーからはほど良い緊張感を持たれつつも信頼されており良好な関係を築かれていたと思います。
なので私が会議にいなくとも、理解できていなくても会議は進むし、チームリーダーにもベンダーにも支障はなかったと思います。
Aさんもはじめは私と同じく会議の内容が理解できず戸惑っていましたが、アプリ領域の経験が長いことから、チームリーダーが不足していたアプリや業務観点での知見が豊富で、「この作業はアプリにも影響あるから連携しておいた方が良い」など、ありがちなアプリーインフラ間の連携漏れによるトラブルを未然に防ぐことに貢献されていました。
チームリーダーは毎日相当数の意思決定をされていたうえ、障害で週に1.2回はベンダーから夜中に連絡を受けていたのでかなりハードな日々だったにも関わらず、ほぼいる意味のない私の成長を待っていてくれました。力になれないことが本当に申し訳なかったです。

わからないなら質問、資料を読み漁れ

どうすればよかったか振り返ると、自分が何が理解できないのかチームリーダーに共有して内容を説明してもらったり、設計書等の資料を読み込んで理解を深めるべきだったと思います。（もちろん、これが絶対の正解ではないと思います）
ほとんど会議の内容がわかっていないクセに私は会議後に質問をほとんどしていませんでした。チームリーダーの時間を取ってはいけない、というのは建前で、何も理解していないことを知られて失望されたくなかっただけだと思います。また、チームリーダーの手を煩わせたくないのであれば、過去の会議資料や設計書などを読めむことで理解できるようになる部分も多く出てくると思います。それに資料なんて探さずとも、まず「WASってなに？」と思えばググればいいのです。そこでヒットしたら何かわかりますし、ヒットしなければ社内システムです。（社内システムのこともほとんど知らなかったので、当時は社内システム名と製品名の区別もつかなかった）

現在はコンサルティングファームにいますので、「打ち合わせ出てるけど意味わかんないし」では話になりません。ファーストジョブではすでに進行中のPJに途中からアサインされ、やっぱり最初にでた進捗会議では「意味わかんない」でしたが、過去の会議資料や成果物を見ることで理解できることは格段に増えます。事前にある程度お客様とも会話できるレベルの理解をしておかないとお客様からの信頼を損ねてしまうので、暇があれば過去の資料を探すことは常にやるようになりました。
どういった資料を見れば知りたい情報に辿り着くのかや、設計書の味方に関しては前職の経験で身についていたので、こういった経験が詰めたことはありがたく思います。

ある程度私が会議の内容を理解し、チームリーダーに説明することができるようになれば、チームリーダーがすべての会議に出席する必要がなく、負荷分散ができますし、私の役割も確立できたと思います。
将来的にはAさんと私で担当するシステムを分けた上で、それぞれ会議に出席し、チームリーダーへの説明、判断を仰ぐ、といった形をチームリーダーも考えていました。チームリーダーは「早い段階で担当分けせずに、まずは担当するシステム全体のことを知って欲しい」として担当分けはしませんでしたが、私に任せても大丈夫と思えなかったからではないかと思っています。結果的に私に任せても大丈夫な状態になる前に私が異動することになりましたので、担当分けは実現せず、ずっとチームリーダーの負荷は高いままでした。ここは今でも後悔しています。。。

書いてて嫌になるくらい自分のダメさと後悔を書きましたが、流石に私も2年間ただ会議に出るだけだったわけではありません。
次回は役立たずの現状を受け止めた私の（残念な）努力について書こうと思います。
ここまで読んでいただきありがとうございました。