新人MSPエンジニア奮闘記とこれから

この記事は KINTOテクノロジーズアドベントカレンダー2024 の12日目の記事です🎅🎄
 はじめにみなさんこんにちは！KTC（KINTOテクノロジーズ）にてプラットフォームグループMSPチームに所属しているマツノです（入社時エントリーはこちら）。

前職ではSES事業会社に在籍し、インフラエンジニアとしてオンプレやAWSに構築されているシステムの保守・運用を担当していました。もう少しシステムやそこに関わる人達と深く関わりたいなと考えていたところ、縁あってKTCにジョインし本日に至ります。
 この記事を書こうと思ったきっかけ突然ですが、みなさんはMSPと聞いてどんなものをイメージしますか？なんの略称かご存じですか？

恥ずかしながら、自分はリクルーターの方に求人票を見せてもらうまでMSPという単語を知りませんでした…。

そこで、この記事では自分がKTCにMSPチームとして入社してから学んだことや苦労したことを紹介しながら、KTCでのMSPチームの取り組みを紹介したいと思います！
 MSPとは？まずはMSPについて一般的な説明をさせてください。MSPとは「Managed Service Provider」の略称でGartner社の公開している用語集では以下のように紹介されています。（原文をDeepLにて翻訳）
マネージド・サービス・プロバイダー（MSP）は、ネットワーク、アプリケーション、インフラ、セキュリティなどのサービスを、顧客の構内、MSPのデータセンター（ホスティング）、またはサードパーティのデータセンターで、継続的かつ定期的なサポートと能動的な管理を通じて提供する。  
MSPは、自社固有のサービスを他のプロバイダーのサービスと組み合わせて提供することもある（例えば、セキュリティMSPがサードパーティのクラウドIaaSの上でシステム管理を提供するなど）。ピュアプレイMSPは、1つのベンダーやテクノロジーに特化し、通常は自社のコア・サービスを提供する。多くのMSPは、他のタイプのプロバイダーのサービスを含んでいる。  
MSPという用語は、従来はインフラやデバイスを中心としたタイプのサービスに適用されていたが、現在では継続的、定期的な管理、メンテナンス、サポートを含むようになった。
Gartner Glossary: Managed Service Provider (MSP)より引用
「継続的かつ定期的なサポートと能動的な管理を通じて提供する。」 ここら辺がMSPの根幹となる考え方になってきます。

MSPという用語を調べてみると事業所によって若干の違いはあるようですが、多くは稼働中のシステムの保守・運用・監視を専門に担当するサービスのことを指すようです。
 KTCでのMSPチームの取り組み MSPチームの成り立ちここからはKTC社内でのMSPチームの取り組みなどを紹介させていただきます！

まず、KTCでのMSPチームのミッションですが、
「アプリケーション運用サポートにより間接的な開発スピードと品質向上に貢献する」
となっています。

なぜそのようなミッションになったのかを理解するために、MSPチーム発足当時のことを調べてみました。

MSPチームの構想が立ち上がった当初、KTCでは以下のような課題がありました。
開発中のシステムにおいて開発者と運用者が同一のため、運用作業に追われて開発スピードが上がらない。
障害対応において、システム稼働時間と同等の時間でサポート体制が取れていない。
こういった課題を解決するために、KTCにおけるMSPチームは以下の2チームで構成されています。
MSPサービスデスク（アウトソーシング）
MSP内製チーム
MSPサービスデスクはアウトソーシングしており、いわゆる24h365d対応の部隊になります。

一方でMSP内勤チームは2023年5月に発足した比較的新しいチームで、平日の日中帯にKTC社内の各開発チームより引き継いだ業務を対応しています。
 MSPチームの具体的な業務内容KTCでは日々様々な内製プロダクトが開発されており、MSPチームでは主に以下のような業務対応をしています。
アカウント管理
アカウント登録・削除
パスワードリセット
アカウント棚卸
離職者対応

セキュリティレポート集計・周知対応
データ連携バッチ失敗時のリラン対応
システム監視アラート1次対応
各種問い合わせ対応
上記のリストからイメージ出来る方もいらっしゃるかもしれませんが、

現在のMSPチームではシステム管理・運用において定型的に対応できるもの、

複数のチームで対応する必要があるが対応方法が統一されていなかったもの、

もしくは対応できていなかったものを中心に対応しています。
 実際にどんなことをやっているの？いまいちイメージが湧かないと思うので、MSPチームで取り組んでいるとある業務の詳細を紹介していきます。

現在、MSPチームでは毎月社内向けに公開される人事情報を元に、離職者対応というものを実施しています。

業務内容としては退職や育児休暇等で離職される社員の情報をとりまとめ、対象システム（内製・SaaS含む）のアカウント有無の確認から削除までを一括対応するというものです。2024年11月時点では2つのグループが開発・管理している、合計7つのシステムに関して離職者対応を実施しています。

この業務をMSPチームが一括で対応することのメリットは、例えば以下のようなことが挙げられると思います。
業務の標準化
グループ間やシステム間でのアカウント管理の差異をなくせる。

運用コスト削減と開発への注力
システム開発・管理を担当しているチームの運用コストを減らせる。

業務の属人化防止
MSP内製チームにて手順書を作成し、チームメンバー全員が対応できる状態を維持する。

運用コスト削減については、ここで例に挙げている離職者対応について具体的な計算をしてみます。

7つのシステムについて担当者が月次で離職者アカウントの削除対応しているとしましょう。そしてそれぞれの作業が大体2時間程度掛かると仮定します。

そうすると全体で必要な月次・年次運用コストは
2（月次の工数） × 7（対象システム数） = 14（時間/月）
14（時間/月） × 12 = 168（時間/年）
となります。あくまで概算ですが、年間で約150時間程度の工数を開発チームの代わりにMSPチームが担当しているということがわかりますね。

自分がKTCにジョインしたタイミングで、すでに離職者対応はMSPチームにて対応していたのですが、月半ばであっても離職者の方が離職された翌稼働日にアカウント削除しており、かなりきっちり対応しているなという印象を受けたのを覚えています。
こういったメリットがある一方で、当然デメリットもあります。

以下のようなものが考えられるでしょう。
コミュニケーションコストの肥大化
業務によっては引継ぎ元チームとのやりとりが増え、業務を手放した恩恵を感じにくい。

引継ぎリスク
MSPチームの作業ミスによって、リカバリー対応等を求められる。

これらメリット・デメリットを踏まえ、業務を引き継ぐタイミングで如何にデメリットを最小限に抑え、メリットを増やしていくのかが腕の見せ所になります。
ここまではKTCでのMSPチームの成り立ちや、具体的な業務の紹介をさせて頂きました。

かっこいいことも書きましたが、自分はまだまだ未熟者なので日々勉強中です…。
 MSPチームのこれから 求められたことここからは自分自身がKTCに入社してから求められたことや取り組んだことをお話ししつつ、これからのMSPチームについて紹介させていただいてこの記事を締めようと思います！

まず、KTCに入社する際に自分に求められたことは大きく以下の2点でした。
MSP内製チーム現場リーダーとして成長し、内製チームをリードすること。
今まで経験したシステム保守・運用の実務経験を活かし、MSP内製チームの業務拡大に貢献すること。
これらは自分にとってとてもチャレンジングな内容でした。なぜなら、今までの働き方は日次・週次・月次といった各スパンで一定の決められた業務があり、それらをミスなく同じクオリティでアウトプットすることが求められるようなものだったからです。組織としてもシステムとしても安定期にある環境がほとんどでした。

一方でKTCは組織としてもビジネスとしても拡大を狙う組織であり、当然それに伴い新規システムの開発も進んでいます。開発チームの開発スピードと品質向上をミッションに掲げるMSPチームとしては、対応業務の拡大を進めたいということになってきます。
 現場リーダーとして意識したこと前述したように自分に求められたことは理解していたつもりなのですが、1人のエンジニアとして目の前の業務をこなすのと現場リーダーとして立ち回るのとでは全く違いました。

今までは自分自身のアウトプットにのみ気を配ればよかったのですが、現場リーダーとして成長するためには、チームメンバー全員のアウトプットにまで気を配る必要があります。

もちろん自分一人が責任を負う必要はないのですが、どこまで把握する必要があって、どこまでを委ねて良いのかのさじ加減が難しいと感じています。

周りのサポートもありだいぶ慣れてきましたが、日々勉強だなぁと感じています。
 MSP内製チームの業務拡大に向けて最後に自分のシステム保守・運用の実務経験を活かし、MSP内製チームの業務拡大に貢献するという部分ですが、こちらは絶賛悪戦苦闘中です。

過去に組織として縮小傾向にある開発現場にいたことがあるのですが、そこでは業務の属人化が進んでしまっていました。担当者の高齢化や過負荷な状況が続いていたこともあり、属人化を解消するのがかなり難しい状況になっていると感じたのを覚えています。自分なりに出来ることはやったつもりですが、工数も限られているため、出来ることには限界がありました。

そういった経験を踏まえても、今のMSPチームが取り組んでいることはKTCにとって有用性があると感じています。

チームとしてやろうとしていることやその必要性はとても良く理解できる、しかしノウハウが自分の中にないという状況です。
MSPチームの取り組みを拡大するためには、自分自身が以下のようなことが出来るようになる・実践する必要があると考えています。
適切な業務設計・フローとするために、システム観点だけでなく業務観点で考える。
新たな業務を引き継ぐ際には、MSPチームとしてのアウトプットが揃う手順とする。
KTC社内でのMSPチームの取り組みを知ってもらう。
もともと手順書などのドキュメント類を作ることは嫌いではなく、定型作業のようなルーチンワークにも抵抗がないため、それなりに適正はあると自負しているのですが、業務を作る部分が本当に難しいと感じます…。今まで自分自身がシステム開発寄りの働き方をしていたため、思考の癖としてシステムの仕様や内部で利用しているAWSサービスが気になってしまいます。ですが良い業務を作るためにはそれではいけません。「業務観点ってなんだ？」と自問自答しながらドキュメントと向き合う毎日です。
アウトプットを揃えるという観点についても、業務フローを整えチケット起票したうえで、そこに必要な情報を集めてから対応する手順が基本だと理解しています。ですが業務フローを整えるのに四苦八苦しています。ちゃんと考えるべき部分と、あまり考えなくて良い部分の判断が難しいです。
上記のことが自分のスタイルを確立したうえで実践できれば、業務引継ぎのリスクを最小限に抑えメリットを最大化することができると思うのですが、これがなかなか難しい…。一朝一夕で身に付かないものだと感じているので、今は上長やマネージャーに助けてもらいながら日々の業務に取り組んでいます。ただ、自分の働きによって良い業務を作ることが出来れば、それがMSPチーム拡大に繋がるので頑張ろうと思います。
 さいごにこの記事では一般的なMSPの話から始まり、2024年4月にKTCに入社した筆者の目線から見たMSPチームの取り組みや、有用性、これからやりたいことを紹介させていただきました。

普段の業務で技術的に高度なことに取り組んでいるようなことがないため、他のテックブログと違い技術系の話や、技術的に困ったことを紹介するものではなく、自身の主観を交えながらKTCでのMSPチームを紹介させて頂きました。少しでもMSPチームでの取り組みに興味を持ってもらえたら嬉しいです。