コロナ禍で新卒一年目を乗り越えた話

皆さん、こんにちは。入社2年目のAsuka.Kです。

ブログというものを初めて書きます。この記事では、入社してから銀行システムの上流工程(保守・運用)のプロジェクトに配属されるまでの話を書きたいと思います。

現在2年目、まだまだ知識は浅いので間違っているところがあるかもしれませんがご容赦ください。

１．配属される前⋯

文字通り、ITに関して大学卒業まで何一つ触れてこず、授業で情報系の授業やプログラムを書く授業なども一切取っていませんでした。強いて言えば大学1年生のころ必修科目だったITパスポートの内容を解説している授業を受けていたくらいで、もちろんその内容は忘れてしまったので、本当になにも知らないまま入社式を迎えました。

研修も始まり、Javaでの開発をメインで学び、なるほどこういうことかと思いながらコードを書いたり、インフラについて学んだりしました。

残りは配属されたらやっていく中で学んでいこうと思っていました。

２．配属が決まり、いざプロジェクトへ参画したものの⋯

私が配属されたのはインターネット銀行のシステムを保守・運用をするプロジェクトでした。仕事内容としては銀行アプリの修正に伴う影響調査や設計書のレビュー、テストのレビュー、障害調査、諸々のレビュー⋯。

いや、研修内容どこ行った？という心情です。

コードを書くどころか見ることもわずか。みんなが何を言っているのかひとつも理解できません。どんなことをしているのかも全く掴めず、ジョブってなに？バッチってなに？という状態です。そもそも設計書などを見ても情報が目ではじかれて脳までいかないという状況です。どういう観点でみればいいかも謎です。

何一つ分かるものがない⋯という状態でした。

３．時代の波

時代は新型コロナウイルスによりてんやわんやしていたため、なにも状況が分からないまま配属され、即時テレワークとなりました。何が分からないのかも分からないという状態のため、当然、やることがありません。いつまでたっても仕事どころかプロジェクトメンバーのことも分からないですし、みんなが何をやっているのかも分からない状況でした。

出社していれば他の人が何をやっているのか、少なからず状況を掴めるはずです。障害調査に立ち会えるので現場でどんなことをしているのか学べると思いますが、それもできません。

これではまずいと感じました。

元々の知識もない、研修でやったことは全く違うフェーズであまり役に立たない、日々何も出来ないうえに、物事の前提が分からないので成長することもできない。他の同世代は今頃メキメキ学び成長しているのではないかと思うと、今のこの身動きの取れない状況にかなり焦ります。

どうにかしなきゃ、どうしようかと考えました。

４．とりあえず勉強

手っ取り早く、勉強をしました。そもそも知識がなさすぎることが問題の1つとしてあったので、基礎的な、話の前提知識を身に着けようと思い、資格試験を通じて知識を習得しようと考えました。

資格というのは大変便利です。やみくもにいろんな分野に手を出してもしかたないですから、ある程度範囲を絞り込んで知識を身に着けられるというところが強みです。そしてわかりやすい参考書もある、ついでに資格も取れて一石二鳥です。資格があればどの程度の知識を保有しているのかも客観的に分かりやすくなります。

ただ、資格取得を目標にしてはいけない、という点は念頭に置いておかなければならないです。資格を取るために勉強をしているわけではなく、知識を得るために資格を取るという手段を取っているということを忘れてはいけません。

そんなことは誰でも分かることかとは思いますが、勉強をしていると目標がぶれがちになってしまうので、目標はあくまでも知識を取得して業務と結びつけていくというところに落とし込んでいかなければいけません。

５．様々な知識を身に着け⋯

勉強を重ね、みんなが話している内容も、自分がどれだけ何もわかってなかったかも段々わかってきます。分からないところも分からない状態からの脱却です。いやはや、ようやく一歩前進だなぁといった感じです。

少しは理解できることが増えたなというところで、やらせてもらえる仕事も増えてきました。

６．仕事内容

私の仕事内容としては、以下がメインです。

①銀行からの問い合わせ対応

大概はシステム仕様がどうなっているかの確認です

②障害発生時の対応

システムを稼働させているとどうしてもエラーが出ます。なぜそのエラーが出ているのかをログ等をみて突き止めます。もちろん一人でやるのではなく、複数人で確認し、調査に不足がないか、間違っていないかを議論しつつ、障害の原因を探ります。

③機能修正の対応

例えば、ATMの無料利用回数を変更したり、文言の変更をしたりと多岐にわたります。銀行側から「こういう要件があるから対応してほしい」という要望を受けて対応します。また6-２の障害調査の結果、改修が必要となった場合もこれにあたります。

７．開発案件の進めかた(機能修正の対応)

仕事内容の中で最も対応することが多いのは「6-3.機能修正の対応」です。そこで、機能修正の対応の内容について、詳しく説明していきたいと思います。

修正をするにあたり、作業は主に以下のような流れでやっていきます。　

①修正箇所の特定

どこを修正すれば要件を実現できるかを考えながら、設計書やプログラムを見ていきます。

ざっくりとこの辺、ではなくこのプログラムの中のここの部分、という粒度まで見ます。

②影響調査

修正により他機能への影響があるかどうかの確認をします。修正により今まで正常に動いていた機能が正常稼働しないといったことを防ぐためです。

ここが一番重要だと私は考えています。影響調査をしっかり行うことで、「考えていた修正箇所だけでは不足しているな」とか、「違うエラーがでてしまうな」、などさらに発展して気付くことが出来ます。影響調査を行うことで新たな障害の発生を未然に防ぐことができます。

③設計〜テスト

私のプロジェクトでは設計書やプログラムの修正、稼働テストは中国の会社に依頼しています。修正箇所や影響調査をまとめ、「こういうことをしたいのでここをこんな風に修正してください」、といった依頼をします。また、テストは中国の方にも行ってもらいますが、二次的なテストを国内でも行ったり、案件によっては銀行の方にもテストを行っていただくことがあります。

ここで②の影響調査が効いてきます。影響調査をしっかりと行うと、テスト観点等もおのずと見えてきます。確認しなければならない箇所をしっかり確認することが大切です。

④レビュー(修正したものを確認すること)

案件もいよいよ大詰めです。③で修正した設計書やテスト結果をレビューします。修正が合っているか、テスト観点が不足していないか等を主な観点としてみます。レビューについてはもちろん私だけでやるのではなく、システムに詳しいメンバーにも参加してもらいます。まだシステムについての知識も浅いので、どういった観点で見ているか質問しつつレビューします。

⑤リリース

レビューもテストも終わり、ちゃんと修正できているかが確認出来たらいよいよリリースです。修正した機能を実際に動いているシステムに反映させます。リリース後、修正箇所が正常稼働していることが確認できたら一安心です。

ここで障害が発生するかどうかはすべて②の影響調査にかかっています。影響調査で考慮漏れがあるとテストでもその観点が抜け、障害が起きてやっと漏れが発覚、なんてことにもなります。ひやひやですね。

８．終わりに

そんなこんなで長々と書いてしまいましたがいかがだったでしょうか。仕事内容はわかりやすく書いている(つもり)ので、厳密には少し違う部分もありますが、概ねイメージはできたかなと思います。難しいこともありますが、毎日頭を働かせ、刺激もあるのでなかなか楽しいです。

大変なことも多いですが、まだまだ頑張っていきたいです。

プロフィール

氏名:Asuka.K

株式会社リライフジャパン 証券ソリューション本部所属

2020年4月親会社である株式会社シーエスエスに入社〜同年7月グループ会社であるリライフジャパンに転籍-

取得資格:応用情報技術者(202106)、基本情報技術者(202103)、証券外務員1種(202011)、OracleJavaProgrammerSiler(202008)、日商簿記2級(201906)、他