裏方として支える喜びを原動力に。SEとして広がった『複数の視点』

学生時代は、数学や情報処理について学ぶ学部に所属していました。プログラミングや機械学習なども学んでおり、もともとPCに触れることが好きだったのが大きかったと思います。実は両親がSEだったこともあって、幼い頃からPCが身近な存在でした。SEという仕事は、ただプログラミングをするだけではなく、「どんなシステムを作るか」という設計の段階からリリースまでシステム全体に携われるところが面白そうだと思って、自然とSE志望になっていましたね。

学業以外では、高校から大学まで運動部のマネージャーを続けていました。もともとはプレイヤーとして競技に取り組んでいたのですが、あるときマネージャーのような役割を担ったところ、自分が試合で活躍するよりも選手をサポートするほうがずっとやりがいがあって楽しいと感じたんです。それ以来、裏方として誰かを支える役割の重要性と魅力を実感するようになりました。アルバイトでも試験の監督や運営業務に携わっていたので、そういった経験がひとつの軸になっていたと思います。

就職活動では、最初からIT業界に絞っていました。ただ、どの分野や領域のシステムに携わりたいかという具体的なこだわりはなくて、「幅広い領域を経験できたほうが自分の向き不向きもわかるんじゃないか」という考えから、様々な業界のシステム開発を手がけるSIer（システムインテグレーター。顧客の要望に合わせてシステムの企画・開発・運用までを一括して請け負う企業）を中心に複数社を検討していました。

その中で現在の会社に興味を持ったのは、金融を中心にしながらも幅広い領域でシステム開発をしており、さらに教育に力を入れているという印象を受けたからです。実際に地方で開催されたインターンシップに参加したのですが、参加者がとても少なくて、正直「内容が簡略化されてしまうんじゃないか」と不安になりました。でも実際はまったく逆で、本来グループワークで実施するようなシステム開発を模したワークをマンツーマンで対応してくださったんです。時間が余っても短縮するのではなく、私の疑問に丁寧に向き合ってくれたり、仕事についてのリアルな話をしてくれたりして、とても充実した時間になりました。

さらに決め手になったのが、面接後のフィードバックです。担当の方が面接後にわざわざ時間を取って、丁寧なフィードバックをしてくださいました。確実に入社するかどうかもわからない学生にここまで向き合ってくれるんだ、と純粋に驚きましたし、「人を大切にする会社なのかもしれない」と感じたことが、入社を決める大きなきっかけになりました。面接の内容自体も、自分のこれまでの人生をプレゼンするような形式で、応募者一人ひとりの歩んできた道をしっかり見ようとする姿勢が伝わってきて、その点も印象的でした。

入社後は、まず3か月間の新人研修からスタートしました。最初の2か月間は、システム開発の基礎知識はもちろん、メールの書き方や議事録の作成、電話対応といったビジネスマナーも丁寧に学びました。学生時代に学んでいたとはいえ、実務レベルのシステム開発知識はほぼゼロからのスタートでしたが、基礎からしっかり教えてもらえる環境があったので、少しずつ自信をつけていくことができました。

残りの1か月は、グループワーク形式でのシステム開発演習でした。グループごとに実際にシステム開発を行うというもので、チームで協力しながら一つのものをつくり上げる経験は、研修の中でも特に印象に残っています。

研修が終わると、社会インフラ系（電力・交通・通信など、社会の基盤を支えるシステム）の保守開発プロジェクトに配属されました。入社1年目は主にテスト実施を担当しました。テストとは、開発したシステムが正しく動作するかを確認する工程のことです。最初は覚えることも多く、がむしゃらにこなしていた記憶があります。

2年目以降になると、小さな保守案件について要件定義（お客様の要望を整理してシステムに必要な機能を定める工程）からリリース（システムの本番稼働）まで、一連の工程を担当するようになりました。任せてもらえる範囲がどんどん広がっていくのを感じながら、少しずつSEとしての仕事の全体像をつかんでいきました。

その後、当時メインで行われていた大規模な開発がひと段落し、プロジェクトが縮小することになったタイミングで、次のプロジェクトへ異動することになりました。

次のプロジェクトでは、要件定義や基本設計といった上流工程（システム開発の初期段階にあたる、仕様を決めるフェーズ）のみを担当することになりました。前のプロジェクトではほぼすべての工程を担当していたので、「プロジェクトによって担当する工程や領域がこんなに違うのか」と正直驚きました。就職活動の中でイメージしていたSEの仕事は、要件定義からリリースまで一気通貫で関わるものだったので、そんなこともあるんだという感覚でした。

ただ、戸惑いながらも先輩に積極的に質問しながら業務を進めるうちに、担当工程が限られる分、その工程に関するノウハウが深く積み重なっていくという側面もあると気づきました。どちらの経験も、今の自分の仕事の土台になっていると感じています。

現在は金融系の保守開発プロジェクトに所属しており、基盤チームのサブリーダーを務めています。基盤チームとは、システムを利用する人が安心して使い続けられるよう、サーバやネットワークの状態を監視し、問題の予防や改善を行うチームです。具体的には、システムのリソース状況の確認や、情報セキュリティに関する脆弱性情報（システムの弱点となりうるセキュリティ上の問題）のチェックといった定常作業のほか、顧客からの問い合わせを受けて調査・報告を行うことも大切な仕事のひとつです。

サブリーダーという立場では、基盤チームの管理や顧客への報告対応に加えて、他チームとの情報連携や調整も担っています。私が所属するプロジェクトは、2種類のアプリチームと基盤チーム、PMO（プロジェクト全体の管理・調整を担うチーム）の大きく4チームで構成されているのですが、基盤チームはどちらのアプリチームの作業にも関わることが多いため、複数のチームにまたがるやりとりが日常的に発生します。

そのなかで特に苦労するのが、他チームから漠然とした依頼がきたときです。まず依頼内容をタスクとして明確に洗い出し、それぞれの担当チームを整理した上で、「いつまでに実施したいか」「いつなら実施できるか」をチーム間で調整していきます。関係者全員の希望通りに作業を進められるとは限らないので、折衷案を見つけるのはなかなか大変です。それでも、複数の立場の意見をまとめてプロジェクトを前に進められたときには、サブリーダーとしての手応えを感じます。

この仕事でやりがいを感じる瞬間は、システム運用の効率化や改善に貢献できたときです。複数の会社が利用する共用環境で問題が発生した際、その場の対処にとどまらず、「再発しないためにはどうすべきか」まで考えて運用の仕組みに落とし込む。Webサービスのように成果が直接目に見えるわけではないですが、そうした取り組みが実際に運用として根づいたとき、「自分の仕事には確かに意味があるんだ」と実感できます。

失敗から学んだこともあります。夜間に実施されるシステム処理で問題が発生し、翌日の日中に対応が必要になった際、フォローの考慮漏れが起きてしまったことがありました。本番環境での問い合わせ対応はスピードが求められる場面が多く、素早く、かつ正確に影響を調査することが不可欠です。この経験をきっかけに、同じような場面で誰でも迅速に対応できるよう、調査手順や過去事例を整理し、プロジェクト内で共有する仕組みづくりに取り組みました。

それまでは経験豊富なメンバーに頼りがちだった部分も、ノウハウを参照することで経験の浅いメンバーでも一定程度の切り分けや状況理解ができるようになり、チーム全体の対応スピードが上がったと感じています。

こうした経験を通じて、学生時代と比べて大きく成長したと感じるのが、多角的に考える力です。学生のころは、自分に関することは自分の視点で考えれば十分なことが多かったと思います。でも今は、同じシステムでも、エンドユーザー・ベンダー・開発者それぞれの立場によって見え方や課題感がまったく異なります。顧客の要望に対して複数の対応案を検討する際にも、開発工数や難易度だけでなく、保守運用上のメリット・デメリット、ユーザーの使い勝手まで複数の視点で整理して提案できるようになりました。この「複数の視点で考える習慣」こそ、この仕事が自分に与えてくれた大きな変化だと思っています。

直近で取り組んでいきたいのが、AIを活用した業務効率化です。私が担当しているシステム運用の仕事では、ログ（システムが動作した際に自動的に記録される履歴データ）をもとにリソース情報を確認・分析する作業が日常的に発生します。こうした定常作業の中には、手作業で行っているものもまだ多く、AIを使って自動化できる部分を少しずつ増やしていきたいと考えています。

所属している部署では、AIの活用に向けて難易度別に研修が開催されており、会社全体でもシステムに関する知識からビジネススキルまで、幅広い分野のオンライン研修に参加することができます。今のプロジェクトだけでなく、将来ほかのプロジェクトに異動した場合にも活かせるスキルを身につけられる環境が整っているので、この機会を積極的に活用しながら、まずは自分の目の前の業務から効率化に挑戦していきたいと思っています。

中長期的には、誰もが入りやすいプロジェクト運営に携わることが目標です。現在の仕事は、何かを新しく作るシステム開発というよりも、日々発生する問い合わせや障害への対応が中心です。「こんな問題が起きたらこう対処する」と手順をあらかじめ決めておくことが難しい性質の業務が多く、どうしても過去の経験や暗黙知（文書化されていない、個人の経験や勘に基づく知識）に頼る場面が出てきてしまいます。これが属人化（特定の人しか対応できない状態）を生む大きな壁だと感じています。

私自身、わからないことが多い状況は「難しそう」という心理的な抵抗感につながると実感してきました。だからこそ、手順の内容やシステムの知識など、これまで明文化されていなかったことを一つひとつ言葉にして残していくことが大切だと思っています。新しくプロジェクトに参加したメンバーや、技術的な知識がまだ少ないメンバーでも、「難しそう」と感じることなく業務に向き合える環境を作っていきたいのです。

最後に、この仕事に興味を持ってくださっている方に伝えたいことがあります。大切なのは、積極的にコミュニケーションを取れること、わからないことを一人で抱え込まず周りに相談できることだと思います。そのとき「ある程度は自分でも調べたけれど、どうしてもわからなくて」というひと言があると、相談された側もアドバイスがしやすくなります。ITの知識や経験ももちろん大切ですが、それ以上に周囲と積極的にコミュニケーションを取りながら学ぼうとする姿勢が活躍につながると感じています。研修制度も充実しているので、技術的な知識は入ってから着実に身につけていくことができます。ぜひ一緒に働きましょう。