共通化と個別要望のバランスを取りながら
運用センター業務の自動化、高度化を推進

学生時代は、高専の情報系学科に属していました。情報系学科を志望した理由は「なんとなく」です。子供のころから家にはパソコンがあり、インターネットに触れる機会が多かったこと、よくゲームで遊んでいたことなどが影響しているのかもしれません。
高専では主にプログラミングについて学びました。一般科目よりもプログラミングなどの専門科目の方が得意でしたし、以前からコンテンツを消費することよりも作ることに興味があったので、結果的に楽しく学ぶことができました。プログラミング系の授業では、マイコンで物理的にモーターを動かしたり、パソコンやスマホで動作するソフトウェアを作ったりしました。
入社のきっかけは、母校に求人が来ていたことです。最初は「あっ、会社名にNTTって付いてる！」くらいの安直な理由で興味を持ちました。しかし、その後、採用面談の前に会社見学の機会を設けていただき、実際に先輩社員の方々と話す中で、良さそうな会社だなと思いました。
入社後、まずは運用センターに配属され、SEとしてお客さまのサーバー、ネットワーク機器、アプリケーションの監視運用を行う業務に従事しました。高専出身者は即戦力になりやすいといわれますが、実際に即戦力になれたかというと、そうではなかったと思います。Linux環境は学生時代にもプログラミングの際に使っていたので、サーバー操作の簡単なコマンドであれば辛うじて分かるものの、その他は初見のものが大半でした。実際の運用業務では日々、お客さまの要望に沿って機器の設定変更や情報取得の操作をしたりします。また、物理機器の故障によって通信が止まったり、アプリケーションが動かなくなったりした場合は、さまざまな部署や社外の方と連携しての早期復旧を求められます。もともと「プログラムだけではこの先やっていけないだろう」と思っていたので、早いうちにこういった経験ができて、良い部署に配属されたなと思いました。毎日さまざまなお客さま対応に追われながらも、先輩方にはいつも気にかけていただき、結構な頻度で職場の近くで夕食を摂っていたことは思い出に残っています。

入社から3年ほど経ったころ、上司の方から声をかけていただき、VR動画配信サービスの検証に参画しました。各部署から有志を募ったプロジェクトで少人数の体制だったこともあり、配信サービス側は別の方が1人で立ち上げを担当し、私はAndroid版とiOS版のスマホ向け視聴アプリ開発を1人で担当しました。運用業務を経験し、物理機器やデータベースの仕組み、各システム間をどのように連携できるのかを何となくは理解した上で、再度プログラムに触れたため、非常に多くの学びがあったと思います。
一方で、技術的な検証はある程度うまくいったものの、引き継ぎ先が見つからないという技術面の問題と、不適切なコンテンツやコメント書き込みへの対処体制維持など、サービス運営上の問題が生じ、サービス化は断念することとなりました。実際に、大学のイベントや地域の花火大会を配信する段階まで進んでいたこともあり、PoC（Proof of Concept、概念実証）にとどまってしまったことは、現在も少し心残りです。同時に「作りっぱなしではダメだ」ということを痛感しました。
その後は、運用センター業務の自動化、高度化を進める「ServiceNow^®」の開発チームの立ち上げに携わりました。ServiceNow^®は、一言でいうとデータベースとWebサービスを一体化させたようなSaaS製品で、各所にプログラムを仕込むことができるため、極端な話、何でもできてしまいます。しかし、せっかく新たな取り組みとして運用を自動化、高度化しようとしているのに、これまで100通りの業務があったからと言って、そのまま100通りの自動化の仕組みを実装するのでは意味がありません。未来を見据えて数ある業務のパターンを、ある程度共通化しながら自動化を進め、全体で5通りくらいに抑えられるよう、業務の見直しをすることには苦労しました。
私がこの立場に抜擢されたのは、運用センターのための自動化の仕組みを作ろう、というところから始まったプロジェクトなので、運用業務とアプリ開発の両方に知見がある人間を入れたいという想いがあったのだと思います。この仕組みを実際に使うことになる現場の方に「この対応は、普段どんなふうに進めていたのでしたっけ？」とヒアリングをすることも何度もありましたが、運用業務への理解に加えて、現場の方と元々知り合いであるということがかなり強みになったなと思います。
当初の開発チームは私を含めて4人で、私以外は全員がアプリケーション開発の経験がないメンバーだったため、すべてが手探りでした。一歩進むごとにさまざまなトラップに引っ掛かる状況を繰り返していたことを、懐かしく思います。

現在はServiceNow^®の開発チームのリーダーとして18名を率い、全体統制やインスタンス管理（ServiceNow自体の維持運用）などの業務にあたっています。具体的には、開発要件の検討からリリース判定までの全工程のハンドリングと、利用しているインスタンスに関する問い合わせやトラブル対応などを行います。
ServiceNow^®は使い手あっての仕組み、機能ですから、現場の要望は可能な範囲で受け入れていくべきだと考えています。しかしその一方で、すべての要望を受け入れると個別のチューニングが増加することになります。ServiceNow^®を運用業務の基盤として長く使っていくためには、できる限り標準機能を利用してカスタムをしない方が良いため、開発チームのリーダーとして要望の取捨選択も必要になります。そのため開発にあたっては、現場への理解度を上げ、要望を上げた裏にある意図を汲み取ることを大事にしています。PoCで終わってしまったVR動画配信サービスの件もあり、ServiceNow^®を用いた運用サービスを軌道に乗せるというところを一種のゴールとして捉え、目指しています。作って終わりではなく、社内の利用者、その先で実際に監視運用のサービスを受けているお客さまが使ってよかったと思えるシステムを作り、維持し続けることを今後も大事にしていきたいです。
私自身としてはこのプロジェクトを通じて、チームで業務にあたれるようになったことが、自身の成長だと思っています。これまで、プログラムの開発は基本的に1人で行っていましたし、運用業務で作業をする際は多くても2、3人程度です。しかし、この規模のServiceNow^®開発を1人でする場合、開発速度を向上させるのは難しいでしょう。開発速度を最大にしようとすれば、常に100％の速度で走り続けることになり、まったく休めなくなってしまいます。開発規模の拡大に伴いチームメンバーも増員となり、ある時点で個人プレイには限界があると気づき、自分ですべてのタスクをこなすスタイルから、チームメンバーに仕事を進めてもらうスタイルへと移行しました。もともと何でも自分でやってしまいたいタイプだったことを考えると、これは成長だと捉えています。
チーム運営の観点では、リーダーとしてチームメンバーの手元に何かしらの知見が残るようなタスクを割り振るよう意識しています。全員のすべての要望に応えられるわけではありませんが、「この領域を担当したい」という意思表示があれば、優先的にその領域のタスクを割り振るように心がけています。
また、過去に私自身が先輩にいわれた「作業者ではなくSEとして仕事をする」という意識も大事にしています。「この機能を使ってこういう仕組みを実装してください」まで言ってしまうと、割り振られた方は完全に作業者になってしまいます。1年目や2年目の新人の方向けであれば、むしろ技術的な知見を増やしてもらうためという意味で良いかもしれませんが、これから中堅社員になっていくメンバーにも同じスタンスを取ってしまうと、「作業者としてこき使われただけ」という印象が残ってしまうかもしれません。そこで、まずは要件だけを伝えて自分で考えながらタスクを進めてもらい、行き詰まった場合はサポートしながら再度進めてもらうというスタンスを取っています。メンバーが将来異動になってしまうこともあると思いますが、異動先でも活躍してほしいですからね。

OFF TIME
休日は家でゲームをしたり、YouTubeで動画を見て過ごしたりすることが多いです。車も所有しているので、ドライブがてらで近くのショッピングモールに買い物に行くこともあります。