何の記事か

先月末、2016年8月から従事していたプロジェクトを離任した。
新人で初めて配属されたプロジェクトだったので、一つの区切りとしてこの記事を書く。

うちの会社はプロジェクトの変わり目で休暇を取得することを奨励している（年休だが）ので、実は期初にもかかわらず5連休である。（土日入れて9連休）
本当は先週末の土日に書きたかったのだが、「来週連休だからそこで書けばよいか」と思っていたら、いつの間にか結構日にちが過ぎてしまった（ YouTube を見ていた）。

個人的な振り返りが主である。誰かに何かを伝えることは目的に一切含まれていない。
公開する理由は、自分だけが読むものでななく誰かがもしかしたら見るかもしれないという形で残したかったからである。途中から何が書きたいのかが雲散霧消になってしまった感があるが、それは今の自分の文章能力だと受け止めたい。

何をやっていたか

守秘義務等々あるので、細かいことは省いて大雑把に書く。
参画から離任まで時系列を追って振り返ってみた。

全体情報

担当していたのは金融システム（割と大きめ）。
金融機関のシステム会社（以下、A社）の協力会社として、うちの会社が入っていた（作業請負契約だったはず）。

請け負っていたシステムの具体的な領域や業務内容はここでは記さないが、その領域を担当していた会社はうち以外にも複数あった。後述するが参画したときはいわゆる「炎上案件」だったので、一部製造部隊という詳細設計書をひたすら java に落とすグループがあった。また、設計でもうちの会社以外にあと2社いて、A社から見ればこの領域はうちの会社、あの領域はあの会社というように担当範囲が分けられていた。

本番リリースは2018年夏。参画時は本番リリースまでのスケジュールは未定だったが、いつの間にか決まっていた（いつ決まったかは忘れた）。

参画当初

自分が現場に参画したのが、2016年8月。
ちょうどその時はうちの会社がそのプロジェクトに人をバンバンつぎ込んでいた時期だった（全体で250人くらい）。
人がたくさんいたこともあり、うちの会社だけでも多くのチームが編成されていた。

一番最初に所属したのはテストチーム。
参画時のプロジェクトのフェーズは（確か）システムテストだったが、うちが担当していた領域の品質が極めて低かったので、「詳細設計から全部作り直そう」と大きく舵を切ったところだった。
テストチームのタスクは、作り直しの優先度が最も高い機能から、結合テストをひたすら消化することだった。
本来のフェーズとは一も二も巻き戻ってやり直しとなったので、キツキツのスケジュールを強いられていた。
また設計やり直しも開発やり直しも同じくキツキツのスケジュールなので、資材はまともに単体テストが行われずに結合テスト環境へリリースされていた。
テストチームの僕は、テスト対象にUTレベルのバグが残存している中で、「どのケースが正常終了するだろうか」と試行錯誤しながら、機能が持つ入力値のバリエーションのほんの一部を通す作業に追われていた。

テストチームが実施するテストは、大雑把に言うと以下の流れで実施するものだった。

画面の各項目にケースで定められた値を入力する
入力した画面のスクリーンショットを印刷する
「入力値を確認する」というボタンを押下する
遷移した画面のスクリーンショットを印刷する
「処理を進める」というボタンを押下する
処理後の完了画面のスクリーンショットを印刷する
印刷した画面をスキャンし、PDFで所定の場所に保存する
その他DBの断面ややり取りされる電文を取得し、PDF同様に所定の場所に保存する

まず大前提として、テストチームが上記のテストを実施するのは、担当の金融システムが乗っている実機（not 開発機）である。
そして実機は、A社から借用するICカードが無いと入れないところに設置してある。
わざわざICカードを借りるという手順を踏んで、実機でテスト過程の画面を印刷し、それをスキャナーでPDF化するという作業を行っていた。

当時初めてこの作業をしたときはショックだった。
まず、画面ごとに印刷する過程が無駄に思えたし、印刷したのをまたPDF化するという手順も非常に煩わしかった。
時にはPDF化の作業のせいで時間外労働を強いられ、「何故テスト実施時にキャプチャーした電子データをPDFとしてエビデンスとして保存できないのか」と常に思っていた。
ちょうど「画面キャプチャーをExcelに貼ってそれをレビューする日本のSI企業はゴミ」というような記事を読み漁っていたこともあり、同じような仕事をしていた自分はモチベーションも日を追うごとに低下していた。

テストチームの仕事へのモチベーションが下がり、設計や開発がしたいという思いが日に日に強くなっていった。決められた内容通りに画面に入力し、印刷し、印刷した紙をスキャナーにかけてPDF化するという作業は誰でもできるものであり、自分がやるべき仕事は他にもあるのではないかと考えるようになった。しかし、いかんせん規模の大きいプロジェクトで、あまり個々人に裁量が与えられない環境だったこともあり、希望はあるけど今は我慢という気持ちで自分を無理やり納得させていた。テスト以外で自分のスキルアップにつながることができたらよかったのだが、プロジェクトの環境がインターネットに接続できないものであり、テスト以外のことはできないという状況を強いられていた。

2017年

テストチームの作業にも慣れてきて、チームの中でもそれなりに一日あたりの消化ケースが多くなった。
単純作業の繰り返しは割と得意な方なので、画面にひたすら値を入力するという行為は人より速くできるようになった。

テストチームの主な作業はケースの消化である。策定したテストケースを如何に速く、如何に正確に実施するかということが仕事だ。
ただ、たまに開発側やA社から「こういった入力値のテストをやってほしい」とお願いされる時がある。
実機でのテストには当然テストチームが一番精通しているので、ユーザに「この画面でこの入力したらどうなるの？」といったQAが来た場合など、ケース消化以外で実機のテストが必要な場合はテストチームが繰り出される。

こういった開発側やA社からの依頼を、スピーディに正確に実施するという点で、自分は少しずつ開発側やA社の人から認知されるようになった。
それまではテストチームのタスク消化が仕事の99.9%だったので、あまり開発側やA社との接点が少なかった。
また、テストチームのメンバー（特に協力会社さん）とはそれまでもずっと一緒に仕事してきたこともあり、「こいつそれなりに要領良いし、仕事も速い」と思われて、良好な関係を築けた。
特に仲良くできたメンバーは人当たりが良く、A社の人とも仲が良かったので、その人経由でA社の人に認知してもらった面も多分にある。

ただ、テストチームでの仕事は上手くできていたが、単純作業であるということと、配属当初からテストよりも設計や開発をやりたいと思っていたこともあり、リーダーとの面談時は常に「テストチームから外してくれ」と話していた。
作業内容自体は前述から変わらず、画面の印刷とPDF化が主だったので、一刻も早くその作業から開放されてより創造的な作業をしたいと考えていた。

その頃は、参画時よりも作り直しが進んだ機能がそれなりにあり、設計や開発も新しい人を追加する必要が無い程度には落ち着きを見せていた。むしろ、作り直したことにより、システムテストが全くできていなかったので、多量のテストケースをスケジュール内に消化するためのマンパワーの方が需要があった。
それでも常に「テストとは別のことをやらせてくれ」とお願いしていたこともあり、2017年の初頭にはテストチームの所属を離れることになった。（スケジュールとテストケース消化状況に応じて、テストも担当するということにもなったが）
新しく属することになったチームは「全体推進」というチームだった。

全体推進チーム

担当領域の機能はそれなりに形になっていたので、個別の機能は個別のチームの既存メンバーで十分対応できる状態となった。
一方、個々の機能がそこそこの品質まで来た（だがまだ低品質）ので、担当領域全体を俯瞰して全体としての品質を向上させることが、プロジェクトの次の大きなタスクとなっていた。

担当領域だけで250人もいるような状況だったので、個々の機能がそれぞれ独自に作り込んだ部分が多い。それだけ共通化できている部分が少ないということでもある。
かつ、チームをまたいだコミュニケーションや情報共有は、ピークを過ぎた時期こそ積極的にやっていこうという空気が生まれていたが、自分が参画した頃なんかはそれぞれが自分の機能を作り直すことで精一杯といった感じだった。

機能を跨いで共通化するという作業は、既に機能がそれなりに動くようになっていたこともあり、本来は実施すべきだったのだが見送られた。
一方、機能を跨いで存在する品質上の懸念点は「課題」（not 不良）という枠組みでまとめられ、別途「課題検討」チームというものが立ち上がった。そのチームが対応策の検討や対応状況の管理を担当していた。この「課題検討」チームに、「全体推進」チームの一部メンバーがあてられた。

また、システムテストもドギツいスケジュールで消化していたが、ケース数消化が目的となってしまい、本来果たすべき品質の確認ができないテストとなってしまった。ケース策定の間も機能は修正・変更が施されていたので、機械的にケースを設定しても後々「このケースが足りない」というのがどうしても出てきていたのだ。

うちの会社の管理層や、引いてはプロジェクト全体の管理層（A社の凄いえらいひと）テストにおける上記の問題点は把握していたようで、システムテストとは別のテストフェーズが設けられることとなった。
その中で、システムテストでは確認できない品質の担保を目指し、観点やケースをまとめる役割として「課題検討」と同様に、「全体推進」チームの一部メンバーがあてられた。

僕はテストチームにいたからなのか、この追加テストフェーズの観点整理やシナリオ・ケース策定の役割を担った。
7、8年先輩と一緒に観点や検証方法を整理し、ケースを設定してテスト仕様書を作ったり、ケース消化のスケジュール策定などしていた。
システムテスト同様に追加テストもかなりのスケジュールでやり切らなければならないものであり、時にテスト実施も担当した。

前はテストチームで実施者の立場だったので、毎日自分が消化しなければならないケースや細かいタスクを確認して、それを黙々とやっていくというのが仕事だった。全体推進チームでは、ケース消化のスケジュールやケース策定からやることになったので、プロジェクトの状況を見るようになった。「この日はテスト実施にあてられるのは何人で、次の日は何人だから、ケース消化のスケジュールはバッファを持たせてこんな感じにしよう」とか、「この機能はここまでできているから何日までにこのシナリオは終わらせて、あの機能はこの日から実施しよう」とか、「この機能だとこの観点も後々突っ込まれそうだから入れておこう」とか。
自分でたてたスケジュールが厳しいとなったり、急なトラブルで予定よりテスト要員が少なくなってしまったときは、自分でテストを実施してスケジュールを死守した。テストチームにいたとき、ケース消化のスケジュールを遅延するとチームリーダーがA社から厳しい追求にあっていたのを見てきたので、スケジュールはできる限り遅延しないようスケジュール設定から意識した。

先輩と一緒に仕事していたこともあり、目立ったトラブルもなく観点整理やケース策定、スケジュール設定やケース消化ができていたので、僕はそれなりに評価された。テストチームにいたときに良い関係を築けたA社の人とも引き続き信頼を得ることができた。一方で僕の中では、「単にテスト工程の一部の仕事しかしていないし、システムを実際に作るという役割を担えていない」というのが頭の中で常にあった。設計や開発をせずテストしかしていないということが不安で、管理者との面談では正直に想いを伝えた。

2017年の春を迎えると、担当領域のそれなりの品質を見て徐々に人員削減が進められていったのだ。ポツポツと離任者が増えていき、ひと月で30〜40人くらい離任する月もあった。
そういう状況もあり、面談時は「別の現場に早めに移って、設計や開発を担当したい」ということを、先の不安とともに伝えていたわけだ。

うちの会社の僕がいた部門（金融部門）は、若手社員のローテーション制度というものが存在する。若手は入社3年目のタイミングで新人配属された本部ではない別の本部へ異動し、様々な業種を若いうちから経験させるというものだ。
僕は2017年度は2年目社員だったので、本来は2018年4月から別の本部で働くこととなっていた。（今となってはそれが結局伸びて伸びてとなっているのだが）

ただ、当時同じ現場にいた同期が12月にローテーション制度で他本部へ異動となったので、希望すれば早めにローテーションさせてもらえるものだと思っていた。先輩からも「他のところに行きたいとか、他のことをやりたいってことは、管理者に主張し続けないと叶えてもらえないよ」というアドバイスをもらっていたので、積極的に「今のところは抜けて、設計や開発を担当できるところに行きたい」と面談で主張した。ただ、管理者から返ってくる反応はいつも同じで、「今のところで経験できることは、他のところでは経験できないこと（超ざっくり）」というものだった。

移行チーム

全体推進とは別に、「移行」チームというのにも所属していた。
担当のシステムが抜本的な更改案件だったので、現行から新システムにうまく移行できるかをテストするという、主にテストチームと同じ作業を実施するチームだ。移行システム自体は現行が作るもので、新システムの立場だったうちは移行後に移行されたデータで新システムがうまく動かせるかというのが主な仕事である。

ここでも僕はまた「結局やることはテストか…」という気持ちになったのを覚えている。移行チームに所属することになった時に、移行システムや移行作業の実内容について確認したのだが、テストより移行の実作業を担当したいと強く思った。辛く厳しい作業ではあるけど、その分それこそ「そこでしか経験できないこと」が経験できるはずだったからだ。ただ、移行システムを担当するのは現行側、というのは決まっていることなので、その気持ちはすんなり割り切ることができた。

テスト以外の仕事は一つだけある。「移行後に新システムが想定していないようなデータが来ていないか確認する」というSQLを作ったことだ。これは本来、移行作業後の検証の中で実施されるべきものであり、個々に作成するものではないのではないかとも思ったが、当時移行チームにいた先輩（40代50代の社員って先輩という呼称が正しいのかな？）が「作るべきでしょ！」といって作り始めたものだ。観点は業務の有識者が洗い出して、僕はSQLの作成とテストを担当した。

ここでは、自社以外の他領域の人と接する機会が多かった。現行システムの人と相談したり、他業務の人と会話することができた。今までは自社（協力会社さん含む）とA社の人としか接することがなかったので、コミュニケーションの面で勉強になった。

2018年

基本的には2017年にやっていた作業や所属していたチームに変更は無かった。ただ毎月毎月人が離任していて、ピーク時は250人程度いた要員が2018年に入ったときは3、40人になっていた。

全体情報でも書いたが、そもそも担当の領域はうち以外の会社もいるという体制だった。ここまで来るとA社としても、複数の協力会社を擁する必要もなくなってきていて、どの会社に集約させるかを検討する時期になっていた。2018年に入るとその話は具体的になり、2月にはうち以外の会社の一つが領域から離れることとなった（このプロジェクトの他の領域にもこの会社は要員がいた）。

構成管理

他の会社が作ってきた部分を巻き取る中で、僕は設計や製造を引き継ぐのではなく、資材管理の部分を担当することとなった。
2018年1月に、今までうちの会社の資材を管理していた担当者が離任することとなったこともあり、「構成管理」の引継先として僕がアサインされたわけである。

構成管理というと、全体的な資材管理から修正後のリリース、デプロイまで担当するかと思ったが、僕が担った役割は資材管理の部分のみだった。より大きい範囲で、プロジェクトを横断する形で構成管理チームというのが別にあり、リリースやデプロイの具体的な作業はそのチームが担当していた。各領域の構成管理チームは自分たちが担当する領域の資材の管理と、横断の構成管理チームへのリリースを依頼する作業というのが主な仕事だった。

プロジェクトのバージョン管理は svn だったので、僕のやることは担当領域の開発リポジトリの管理や資材引継、修正時のリリース申請書の作成が大部分を占めた。
品質的にはそれなりのレベルに達成したとはいえ、毎週毎週細々としたインシデントが発生しており、リリース申請書の作成や申請準備が1日の主な仕事となった。人員削減の流れで管理系タスクにあてる要員が少なくなり、構成管理の作業はほぼ僕一人でやっていた。

移行

いつ決まったのか忘れてしまったが、担当領域の本番リリースは2018年夏と決まった。本番リリースの直前（具体的にどれくらい前までかは覚えていない）には資材が凍結され、一切の資材リリースが許されないということがわかっていたので、それまでに判明しているインシデントのうち重要性の高いものを対応する必要があった。
その頃になると人が少なくなってきて、体制上僕も一部の機能の設計を担当することになっていたが、インシデント対応で設計を修正したのは片手に収まるくらいしか無い。僕は構成管理のタスクに従事し、設計や開発で修正対応するメンバーはあの人たちというように、メンバーの役割がほぼ固定となっていた。
僕は、うちの会社で構成管理がわかっているのが自分だけという状況を早めに解消したかったので、インシデントの対応スケジュールにはある程度のバッファをもたせ、メンバーが担っている役割を都度都度流動的に変更していったほうが良いと考えていた。しかしインシデントの対応も、厳しいスケジュールを設定するのが文化なのかわからないが、不必要と感じられるほどキツキツなスケジュールで毎度毎度対応させられていた。なので僕はほぼ毎回リリース申請を出す人となっていた。

移行チームとしては移行本番に向けたプロジェクト全体でのリハーサルに向けた準備や作業が仕事だった。2017年に作成したSQLを移行時に稼働するジョブネットに組み込み、リハーサルでそれがうまく動くかどうかを検証した。組み込んだジョブは「SQLで引っかかったデータがあるかないかにかかわらず、常にファイルを出力する（データが有る場合はファイルに書き込まれる）」というものだったので、毎回毎回ジョブが正常終了したら環境に入ってファイルの中身を cat した。リハーサルの移行作業は土日に実施されていたので、ジョブが稼働するときは土曜日に出勤し、環境に入ってファイルの中身を確認し、0件だったらすぐ帰宅する、という無駄としか思えない仕事をしていた。

2018年は「構成管理」「移行」が仕事だった。2017年と変わらず、設計や開発をやりたいといことや別の案件に関わりたいという考えは上長に伝えていたが、2018年も叶うことはなかった。
本来であれば2018年の4月にローテーションのはずだったが、2018年の初頭に「君のローテーションは一年伸ばした」と上長から伝えられ、2019年3月まで残るということが決まった。
個人的には複雑な気持ちだった。チームメンバーや顧客であるA社の人から信頼されているということは評価されていたが、裏を返せば他で通用しない（ポジティブな理由で他に行かせようと上長が思わない）と評価されていたということでもあるからだ。評価されたことは嬉しかったが、それは口頭だけで実際の評定は普通だったということも複雑な気持ちの要員の一つである。先にプロジェクトを離任して新しいことをやっていた同年代の人は、2018年はその働きが評価され評定がSだったそうだ。
僕は周りの話を聞いたりして、またモチベーションが下がってしまった。2016、2017年ほど忙しくもなかったし、この間に転職活動なり環境を強制的に変えることを試みるべきだったと、後から振り返れば思う。

2019年

3ヶ月だけだったが、同じような作業（主に構成管理）を担当した。2019年2月には最終的に8人体制となり、ピーク時からは考えられないくらいの人員ダイエットの結果となった。

自分の離任タイミングは1年前からわかっていたので、引継でミスしないように準備を進めていた。しかし結局、2019年夏をもってうちの会社はこのプロジェクトから撤退し、他社に引き継ぐということが決まった。当然、他社にも構成管理を担当している人はいるし、他領域であっても構成管理の中身の仕事はそこまで変わらないので、構成管理の会社間引継は僕がいる間にやろうといって実施はしたが、トータル1時間ほどで終わってしまった。

3月になっても、「やっぱりこのプロジェクトに残ってくれ」と言われるんじゃないかと不安もあったが、無事3月末にプロジェクトを離任した。

何を得たか

技術的なことはほとんどなにも得られなかった。
開発をバリバリやりたかったのだが、そういった仕事はほぼやっていない。たまに人が足りないとかで、修正された詳細設計書を見ながらソースを修正し、テストドライバとデータを作り直して単体テストを実施するくらいは実施した経験があるが、それで技術的な何かが得られたとは言えない。
「開発チームに所属できなかったから、技術的なことは何も学べなかった」という言い訳はしたくなかったので、隙間時間で積極的にソースコードを読んだりドライバを自分のローカル環境で作って動かしたり、プロジェクトで定められていたミドルウェアのドキュメントを読んだりした。が、ドキュメントを読むだけではなく実際に作ってテストしてリリースしてという一連の流れを踏まないと技術は身につかないと痛感した。

では何が得られたのか。自分でもこのプロジェクトで何が得られたのかを自信満々に答えることは難しい。こう書いていると、2016年からの3年弱が完全に無駄だったのかという気持ちになるが、100%そういう意味ではない。言語化するのが難しいという意味である。
プロジェクトの規模はそれなりに大きかったので、小規模の案件の要件定義、設計、製造、テスト、リリースを一人でやるという場では体験できないようなものも多分ある（比較対象である小規模案件を経験したことがないので、自分の言うことに説得力はまったくないというのは置いておく）。規模が大きく自分ではコントロールできない範囲がとても広い中で、自分の仕事をスケジュール通りに達成するためにはどうすればよいのかを考え、関係各所と早め早めに調整できるようになった。プロジェクトの担当領域全体を推進するために必要な施策や、それを無理なく達成できるスケジュールを作成する能力などは身についたと思う。そういった能力よりも技術を身に着けたかったという思いは未だにあるが、技術だけ身につければ良いものでもないと思うので、ここでしかできない経験やここでしか得られないものがあったのだと思っている。おそらく、この考えが正しかったかどうかがわかるのは、もっともっと他の経験を積んだときだと思うので、それまで忘れないようにしたい。

何を反省しているか

この3年間で達成できなかったことなどを反省する。

業務内でもっと実施できたと思うことは、技術的・業務的・管理的な面で様々ある。技術的な面では、もっと java の習熟度を上げることができたと感じている。担当領域は java で書かれていて、プロジェクトの開発チームには開発経験が豊富なメンバーがいたり、担当領域外でも java で書かれていたりしたので、 java を習得しようと思えばもっとできた感は否めない。テストドライバやデータを整備して試したりはしていたが、それを開発経験が豊富なメンバーに見せてレビューしてもらったり、もしくは他領域の資材と自領域の資材を比較して、複数の観点で開発上の問題点や改善点を洗い出したりすることができなかった。何がよいソースなのかというのは、経験豊富な他人にレビューしてもらったり、「これがよい」と評価されている別のソースを読むことで判断できるものと思う。
データベースについてももっと勉強できた。本番リリース後なにかインシデントが起こり、データパッチが必要だとなった際、毎回毎回データパッチの手順やSQLを作る要員として一番にアサインされていたので、SQLの基本的な構文については習得できた。ただRDBMSのメンテナンスなどデータベースのより踏み込んだ知識を習得することはできなかった。インフラけいについても、リリース申請や最後の方はリリース実作業を担当していたとはいえ、既存の手順書の通りに実施すれば問題なかったので、デプロイ周りの知識を習得できたとは言えない。よりAPサーバの製品のマニュアルを精読して、サーバ構成などから知識を取得できたと反省している。

業務的な面では、顧客の業務内容が全然知識として取得できなかったことが挙げられる。具体的な業務についてはここでは記さないが、プロジェクトに従事した2年半の間担当業務は変わらなかったので、「今業務を詳細に説明してください」と言われて説明できるかどうかが怪しいのは悲しいことである。
併せて挙げるなら会計知識も全然習得できなかった。隙間時間で簿記の資格試験の勉強をすべきと今になって思うところもある。勘定系システムを担当していたのに勘定の移動や会計的な仕訳知識が全く習得できなかった。技術的なことがやりたいとはいえ、ドメインの知識が身に付けないという姿勢は今後是正したい。SIer という職業はドメインの知識で強みを持っている部分もあるので、先輩を見習っていきたい。

管理的な内容では、ルールの制定や体制の構築に対してもっと意見を述べることができたと思う。特に2017年以降要員が少なくなったときから、自他含んだチームのリーダーと接する機会は増えていっていたので、その場でプロジェクトのルールや体制の問題点を指摘したり改善案を提案できたはず。個々人の裁量はほぼ与えられていない中で、細かいどうでもいいルールの改正や流動的な体制の構築を進言すべきだった。

業務外でもっと実施できたと思うことは、端的に述べると自主学習だ。
高度資格の取得については、データベースとネットワークを申し込んだが、いずれも全く勉強できなかった。応用情報を取得して次の高度資格試験は午前Iが免除だったので、そこで少なくとも一つは取得すべきだった。
個人プロジェクトをもっともっと立ち上げればよかったという思いもある。忙しいときは23時退勤とか帰れないときもあったので、そのシーズンは厳しかったと思うが、早めに帰れる時に全然個人プロジェクトを立ち上げられなかった。勉強はしていたが何かを作って公開できなかったので、新卒入社後数年間の間になにか成し遂げましたというのが無かったのが後悔である。

今後どうするか

ローテーションなのでプロジェクトから離任したのかと思いきや、ローテーションが半年延びたそうだ。ローテーションまでは会社に戻ってRPAについての企画、提案を担当するらしい。
昨年度から所属する部署でRPAの推進が始まっているのは知っていたが、RPAは調べてみれば見るほどつまらなさそうだったので、上長にはあまりやりたくないということは伝えていた。だがうちの部署としてはよくわからんがRPAをグイグイ推しているようで、かつローテーションまでの半年という微妙な期間何をやらせればよいのかを検討した結果、RPAにアサインされてしまった。しかも、ローテーション後もRPAをやるらしい。ローテーションとは、担当する業務内容が変わる（金融業務であることは変わらない）のだが、RPAという扱うシステムはローテーション前と変わらないらしい。個人的にはRPAにはあまり興味がなく、今後ずっと携わりたいとは思ってないので、早い間に社内で別のところに移動させてもらうか、もしくは転職する必要がある。

会社外では、前述の反省点から、「高度資格の取得」「会計知識の取得」「個人プロジェクト」を進めていきたい。
高度資格は、2019年4月の試験は申込みを失念してしまったので、10月の試験に向けて今から勉強しようと思う。まずは取得を第一目標に、取得する内容はひとつ取得してから考えるとして、セキュリティも視野に入れたい。
会計知識の取得については、簿記の資格試験の受験も視野に入れる。RPA業務がどれほど忙しいかによるが、せっかく金融システムに携わる身として、また最近企業決算についての本を読んで会計に興味が出てきたので、積極的に勉強していきたい。
個人プロジェクトはバンバン立ち上げたい。Github の草もどんどん生やしていきたい。少しそれるが、競技プログラミングも時々参加しているので、レーティングを上げるためにDP（動的計画法）等のアルゴリズムを学ぶ。AtCoder によく参加しているのだが、少なくとも ABC のC問題は問題なく解くことができるというレベルまで行く。

長々と書いたが、話があっち行ったりこっち行ったりしたのでここらへんでやめておく。
多分経験したことや得たこと、反省点などはここに書いた以上にたくさんあるだろうが、これを書いている時点で思い浮かんでいないのでスルーする。思いついたら加筆修正するかもしれないが、ブログを加筆修正するくらいなら別の記事を書いたほうが良いのでは？と思う派なので、この文章がここから変わる可能性はあまりないかも。

sier