管理職の仕事とSE35才定年説

前回の投稿に書いた通り、インフラ担当の社員が他部署に移動した事に伴って、自分は開発担当のマネージャの下に配属となり、実質的に自分を含む出向元のチームが、出向先のインフラ業務やインフラに関わるベンダーコントロールを一括して担当する事になりました。こう書くと形態として「アウトソース」のように聞こえますが、実態としては準委任契約の元、形態・実態共に出向先の社員と何ら変わりなく、まるでプロパー社員がインフラを担当しているかのごとくタスクをこなしていました。

そんな中自分は管理職となったわけですが、それまでインフラ構築・運用担当としてタスクをこなしているところに、以下のタスクが順繰りに積み上がっていきました。

1.担当者の業務アサインの明確化とタスク管理
それまではインフラ担当社員の指示に従い、インフラに関わる業務を分け隔てなく自分を含む出向社員でこなしていたのですが、都度仕事の連続でそのままだとノウハウ蓄積が難しいと感じた為、一人はデータセンターの設備とCTIを含む社内インフラ、もう一人はネットワークとフロントエンドサーバー、自分はアプリケーションサーバとデータベース周りをを主担当業務として握り、それぞれ一人では廻らないときには助け合う体制としました。

本当は一番重たいデータベース関連の業務を他の担当者に振りたかったのですが、振り先の担当者のスキルが低く、また自分自身も以前の投稿でも書いたようにデータベースが大好きだったという事もあり、そのまま自分が担当する事にしました。
また今までは、インフラ担当社員の意向で「仕事は終わりさえすればイイ!過程は知らん」というスタンスで、仕事の進み具合は聞かれる都度口頭で説明していたのですが、それだと進行中のプロジェクトがあるところに別の仕事を積み上げられてしまい、瀕死の状態になる事がままあったため、週次で自分を含む担当者の業務報告をまとめ、開発担当のマネージャに提出し、そのときそのときの業務状況や担当者の負担を関係者に説明し易くなるよう改めました。


2.予算とプロジェクトの管理
新しい体制になってからしばらくは、上記のチーム内の管理で仕事がとどまっており、自分が直接担当するアプリケーションサーバとデータベース周りの現場仕事と、バランスを取りながら仕事をこなして行けていました。

しかし登録顧客が10万件を超えたあたりからは、それまで1台サーバーやストレージを買い足せば済んでいたところが、ある程度纏まった台数を計画的に導入しないとヤバい状態となり、都度の増強依頼に対し即答をしてもらえるような費用感では無くなってきてしまいました。

前々回投稿の「ネットベンチャーブームとシステム負荷との戦い」あたりの頃は、計画立てててもヤバい状態でした。

また設備面でもラックや電源、ネットワーク周りも同様に計画的に拡張しないと、いざというときに「サーバーは買ったけど設置するラックがない」だとか、「電源やUPSのキャパシティが足りず、通電した瞬間に同じラックにマウントされたサーバーが全部落ちるかも」だとか、「空調のキャパシティが足りず、監視システムから「このままだとCPU融けるで」みたいなアラートがあがる」なんていう悪夢も起きかねない状態に近づきつつあり、またこれらの拡張にはサーバ以上に莫大な時間と費用が必要となりました。

全部実際に発生しました。ラックの手配が済むまでサーバーを床に置き、電源はデータセンター業者に無理を承知でお願いして空きラックから無理矢理コードを引っぱり、空調のキャパ不足はサーキュレーターを多量に買い占めて、ラックの前に並べまくって凌ぎました。

これらの初期導入や保守を含む年間の投資額は余裕で億のオーダーを超え、これが出向先会社の経営会議で大問題になり、それまでは開発コストとどんぶり勘定でやっていたところを「システムインフラだけでかっちり予実管理せいやこら」との指示が下り、開発担当のマネージャから「すまんインフラのコスト感分からんから頼むわ」と依頼され、結果として自分がシステムインフラ分を全て作る事となってしまいました・・・

以降、「増強するから金をくれ!」では話が通らず、常に要望に対する根拠・説明責任が求められるようになり、これに対する年次計画や、実際に稟議を起す際の情報収集・添付資料の作成に大きく時間を割かれるようになりました。


3.法改正をきっかけとしたシステム管理体制の強化に伴う管理・報告
そして、某メガバンクがシステム統合でやらかした時から、徐々に当局の金融システムの障害に対する目が厳しくなり、出向先の会社にもその影響がじわじわと及んで行きました。

お客様向けサービスの処理遅延から、プログラムバグ等が原因となる誤表示、ログイン不可まで、何らかの形でお客様へ影響が及んだ障害について、当初は比較的影響の大きい障害にしぼって報告をしていれば良かった(ホントは良くなかったのかもしれませんが、少なくとも自分は把握せずに仕事していた)ところが、最終的には例外なく当局へ報告をしなければならないようになりました。更に金商法が施行されてからは、障害のみならず日々のシステム開発、および構築・運用業務について、必要とされたときに直ぐに状況報告が出来るよう、日々の管理体制を整える※※※必要が生じました。
具体的にどんな管理体制が求められるか興味がある方は、是非こちらの資料(PDF)をご覧下さい。ISO27001(情報セキュリティマネジメントシステム)の要求事項との類似点が多いです。

上記の「日々の管理体制を整える」為に、いわゆるPDCAサイクルで業務を定期点検してウミを絞りだし、一連の活動を出向先会社の経営陣に報告するタスクが12.の業務にドカンと上積みされたのでした。

え、これも自分がやらんといかんのですか?と思いつつ、開発担当のマネージャから「すまんインフラの業務状況分からんから頼むわ」といわれるのは目に見えており、甘んじて仕事を請け負わざる得ない状況でした。

上記の1.から3.に至るまでの間、インフラ部門には更に4名の増員がされましたが、残念ながらデータベース周りの仕事をすぐに引き継げるような人材には恵まれず、かといって増員されたメンバーをがっつり教育する余裕もなく、仕事の難易度で行くとOracle Silver程度のスキルレベルでこなせる業務を割り振るまでが精一杯でした。
その結果自分は、
  • 日々のシステム稼働状況のモニタリングや部下のタスクや進捗フォローをこなしつつ
  • システム開発案件や処理劣化に伴うデータベースのサイジングやチューニングに対応し
  • 障害が起きれば、昼夜問わず火消し(現場対応と対外的な報告の取り纏め)に追われ
  • 月次でこれらの活動を総括して経営陣に報告し
  • 半期毎に予算取りの戦いで何度も計画書のさし戻しを喰らい
というマルチスレッド状態で仕事をこなさなければ廻らない状態となりました。

ちょうど自分はもうすぐ35才を迎える頃で、頭の中に「SE35才定年説」という言葉がよぎりました。
SE35才定年説は、一般的には「スキルの限界」や「体力の限界」を根拠とする事が多いように感じますが、自分にとっては現場タスクと管理タスクの両立を期待されるものの、自分のキャパシティでは質の維持が困難で、かつどちらか一方の仕事だけを選べる状況になく、どんどん消耗して行く様もこの言葉に当てはまるよな・・・などとぼんやり考えていたのでした。


ここまでご覧頂き、有り難うございます。
当エントリを含む、就職からアラフォーの現在に至るまでの8回に渡る転職履歴について、「転職履歴」のページにまとめました。
また、これまでの転職履歴で得た経験から、仕事に向かい合う為に必要なテクニックや、メンタリティ・思いを抽出し、「お仕事サバイバル」のページにまとめ直しました。 
それぞれ、あわせてご覧頂けますと幸いです。