自己紹介 クラウドエンジニアを目指して

転職活動の結果、2024年3月からクラウドエンジニアの道に進むことが決まりました！

はじめに

新卒で大手SIerに就職し20数年、20代・30代・40代とキャリアを重ね、今はチームのマネジメントをメインに行っています。
来る者拒まずで仕事に取り組んだ結果、汎用機の保守・保守開発や、Webシステムの再構築プロジェクト、またお客様の情報システム部門に派遣として参画し企画・要件定義など、いろいろと経験することができました。
しかし、ふと立ち止まって振り返った時に、「これが得意！」と胸を張って言える技術がない状況や、「もっと技術に近い場所で仕事がしたい！」との思いが芽生えてきたことから、AWSをスクールで学ぶことに。
2023年5月から受講を開始し毎日学習を継続、2023年10月30日時点で継続学習日数184日、累計学習時間334時間を達成。
学習の日報をX（旧Twitter）につぶやいています。

なぜクラウドエンジニアを目指すようになったのか、自己分析も含めこれまでの主な経歴や転職活動に至った経緯、今後やりたいことなどをまとめたいと思います。

思いつくままに書き綴った結果、長文になってしまいましたが、最後までお付き合いいただけると幸いです。

主な経歴

インフラエンジニアのはずが

新卒で大手SIerにインフラエンジニアとして就職が決まりました。
私が配属された部門はシステムのアウトソーシングサービスを提供しており、自社で保有する汎用機、自社のサーバールームにお預かりしているお客様のサーバー、またそれらインフラ上で動いているシステムの運用・保守・監視をしていました。部門には運用課とシステム課があり、インフラエンジニアは運用課で、システム課ではシステムエンジニアがシステム側の保守および保守開発をしていました。

二ヶ月の研修も終わりいよいよ現場に出る着任初日のこと。
「誰か一人システムエンジニアやってみない？」

どうやら採用時と状況が変わったようで、インフラエンジニア採用は3名だったのですが、1名システムエンジニアをして欲しいとのことでした。
当時、就活では自己分析で「仕事では技術を身に付けたいな、コツコツ取り組むのが好きだな、攻めるより守るのが好きだな」と考え、「自分はシステムエンジニアよりインフラエンジニアだ！」と決めた就職でしたが、「まぁ、システムエンジニアも面白そうかな」と、その場でシステムエンジニアにキャリアチェンジすることを決めました。（キャリアチェンジといってもインフラエンジニアとしてのキャリアはゼロですが・・・）

20代　システムエンジニアとしてのキャリアがスタート

いろいろな業務を担当させてもらいましたが、一番長く担当していたのは製造卸業向け基幹システムの保守・保守開発でした。
従業員数が約500名、全国に支店を持つ製造卸業のお客様の基幹システムで、自社で保有する汎用機上でアウトソーシングしていました。
開発環境を簡単に記載します。

分類	名称
OS	z/OS
言語	COBOL
DB	ADABAS
ミドルウェア	CICS

また、このシステムは周辺システムとして汎用機と連携しながら動くシステムがいくつかありましたので、私が担当していた周辺システムについても簡単に記載します。

分類	名称
システム名	展示会注文システム
構成	クライアントサーバーシステム
OS	Windows
言語	Visual Basic 6.0
DB	Oracle8i

分類	名称
システム名	出荷検品データダウンロードシステム
構成	Webシステム
OS	Windows
言語	HTML、VBScript
DB	Oracle8i
ミドルウェア	IIS、ASP

EDI用に汎用機と連携したUNIXのEDIサーバーもあり、受発注データや請求・支払データ、送り状データなどを相手先とデータ交換していました。

保守・保守開発チームに所属するメンバーは8名ほどで、私はそのうちの販売管理を担当していました。主な機能として受発注・在庫管理・入出荷・EDIなど。私はOJT担当の先輩社員とペアで問い合わせ対応や開発・テストから始め、徐々に自分一人で業務を実施するようになっていきました。

大きなシステムだったので、問い合わせや障害があっても機能などについてわからないことはざらで、設計書はありましたが新規開発時からメンテナンスされていないため当てにならず、わからないながらも　「お客様から状況を詳細にヒアリングする」「開発環境で再現させてみる」「とにかくプログラムから読み解く」　などを駆使しながら対応していました。
機能についてわからないこともそうですが、技術要素も多岐にわたっており、ネットに情報もなかったため、周りに聞きまくって進めていました。

また、それらの機能について保守開発もしますので、COBOLでプログラムを作ったり、VBのプログラムを修正したり、OracleにDDLでテーブルを追加したり、こちらもわからないながらも進めていました。

なかなか大変ではありましたが、汎用機からUNIX、Windows、クラサバやWebシステムと一通り触れることができたのは経験としてとても大きく、今では「どんな技術でもなんとかなるでしょ」の思いがあるのですが、この時の経験がベースになっていると思います。
後、わからないながらも調べながら周りに聞きながら進める自走力が付いたのもこの時の経験が大きいです。

また、障害時は運用・監視を担当しているオペーレーターとやり取りしながら対応に当たりました。オペレーターとやり取りし、部門に報告しながらお客様にも定期的に状況を報告しながらの対応は目が回りそうでしたが、実践の中で関係者と調整しながら進めるスキルが身に付いたと思います。
ですが、夜間にオペレーターからの電話で起こされ、障害対応のために車で駆け付けるのはなかなかハードでした。。

最後に、問い合わせや障害対応、開発などをする中で気をつけていた事について書きたいのですが、それは　「全体を俯瞰してみること」　です。
わからないことだらけの状況だったのですが、問い合わせの回答が見当違いだったり、障害対応で二次障害を引き起こしたり、開発で不具合を生み出してしまっては元も子もありません。また、開発であれば実は既に機能があり、新たに作る必要がないかもしれません。
「全体を俯瞰する」にはシステムの全体を見るということもありますが、問い合わせであれば、今問い合わせてきている内容だけでなく、「この問い合わせをすることで最終的にお客様が何をしたいのか」のやりたいことの全体を意識するということも含まれます。お客様もわからない中で問い合わせていることもありますので、うまく表現できていないかもしれないからです。

このように心掛けながらやっていた結果、ある日お客様から「じゃあ、Takaさんが言うなら間違いないね」と言っていただき、その時の嬉しさは今でも覚えています。
また、システムの設計をする際も全体を意識しながら無駄がなく最適な設計ができるようになったと感じています。

30代　マネジメントを経験する

30代では大規模な再構築プロジェクトを二つ経験しました。

一つは、20代で保守・保守開発していた製造卸業向け基幹システムをWebシステムに再構築するオープン化のプロジェクト。要件定義からリリースまで約4年間、ピーク時の体制は100名を超える大規模なものでした。
私は基本設計からリリースまでの約3年間、EDIに絡んだ量販店向け受注機能とメーカー向け発注機能を担当するチーム（ピーク時、約6名）のリーダーを務め、主にレビューと、進捗・品質・課題管理を担当しました。
また、保守・保守開発を担当していた知見がありましたので、他のチームのオブザーバーとして打ち合わせに参加したり、仕様に関する問い合わせ対応も行っていました。

開発環境を簡単に記載します。

分類	名称
OS	AIX
言語	Java
DB	DB2
ミドルウェア	IHS、WAS
フレームワーク	Struts

もう一つは、別のお客様になりますが同様に汎用機で動いている用地管理システムをWebシステムに再構築するオープン化のプロジェクト。こちらも先ほどのプロジェクトと同程度の規模でした。
私は基本設計からリリースまでの約3年間、用地取得機能を担当するチーム（ピーク時、約10名）のリーダーを務め、主にレビューと、進捗・品質・課題管理、およびお客様の進捗会議で担当機能の進捗報告を担当していました。
また、プロパーが少なかったため、自身のチームだけではなく、自社メンバーの他チーム含め開発が円滑に進むように、標準化・共通化の検討、生産性向上ツールの検討なども行っていました。

こちらの開発環境を簡単に記載します。

分類	名称
OS	Windows、z/OS
言語	Java、COBOL
DB	DB2（z/OS）、Oracle
ミドルウェア	IHS、WAS、Nexaweb
フレームワーク	Struts

プロジェクトの方針として、「バッチ処理は最小限の変更のみを実施し再構築前のCOBOL資産を流用し汎用機上で動かす」となっていました。そのため、オンラインはJava、バッチはCOBOLで開発を実施することになり、汎用機でCOBOLを使っていた経験を活かすことができました。

実際のプロジェクトを通して、プロジェクトやチームのマネジメントについて多くを学ぶことができました。
初めは「マネジメントって何からやればいいの？」と戸惑うことばかりでしたが、手探りながらも進めた中から学び、私がマネジメントの心得としていることを書きたいのですが、それは　「マネジメントは地道で特別なスキルなどなくやるべきことを確実に一つずつやること」「関係者とのコミュニケーションを大事にすること」　の二つです。
初めの頃は「マネジメントに関する学習をしスキルを身に付けよう」と考えていました。もちろんプロジェクトであればPMBOKなどプロジェクトマネジメントに関するナレッジがあります。しかし、それらを知ったからすぐにプロジェクトがうまくいくわけではなく、内容も当たり前のことが書いているなという印象でした。
大事なのは、ナレッジを知っているというよりも、地道にやるべきことを確実に一つずつやるということだと気付きました。
また、コミュニケーションについては私はどちらかというと苦手意識があり、今までは避けてきたところがありました。しかし、リーダーという立場になってからはそうも言ってられず、苦手ながらも少しずつでもコミュニケーションを取ることを心掛けていました。
コミュニケーションにおいて私が心掛けていることは 「感情的にならない」「相手には相手なりの考えがあるため、しっかりと相手の話を聞く」「聞いた話は適当に扱わず、結果を必ず相手に伝える」 です。
こちらもマネジメントに近いのですが、地道にやるべきコミュニケーションと対応を確実に一つずつやることが大事だと気付きました。
そこに気づけたからこそ、自分なりのコミュニケーションの取り方がわかり、リーダーとしても成長できたと考えています。
そのおかげでは今では自分なりのコミュニケーションの取り方もわかり、コミュニケーション能力を買われメンバー間の壁が問題になっていたプロジェクトの立て直しを依頼されました。そのプロジェクトは無事に立て直すことができ、予定通り完了させることができました。

最後に、リリース後は保守・保守開発のリーダーになり、部門のラインマネジメントも担当するようになったことで、チームの予算管理や原価管理、要員管理、BPとの要員調整などチーム運営に必要な経験も積むことができました。

40代　顧客からの視点を学ぶ

保守・保守開発のリーダーとして経験を積んだ頃、事業部内のプロジェクトでリーダーが足りておらず、部門内で参画可能な要員がいないか問い合わせがありました。
私のチームはお客様の予算の都合で体制が縮小傾向にあったことから、私のチームから要員を出すことを検討し、最終的に自分が出ることにしました。自分は残り他のメンバーを出す選択肢もあったのですが以下の理由から自分が出ることに決めました。

• 他のメンバーはまだリーダー経験がなかったこと
• 自分が出ることでそのメンバーにリーダーを経験させることができること
• リーダーが育つことはリーダーが不足している部門にとってもよいと考えたこと
• 該当のプロジェクトは勤務地が異なり部門異動を伴い単身赴任になることから新しい経験ができ自身にとっても成長ができるのではないかと考えたこと

また、この単身赴任のタイミングでグループ会社間の事業移管が行われ、親会社への転籍も併せて経験しました。
単身赴任で新しい環境での生活が始まり、会社も変わり、さらには部門も変わり、まさに体一つで飛び込んだ気持ちでしたが、いざ飛び込んでみると不安よりも新しい環境での経験が楽しかった記憶が強くあります。もちろん、新しい部門のメンバーやお客様に恵まれたことも大きいと思います。
考え過ぎずに新しい環境に飛び込んで見れば「まぁなんとかなるもんだな」と感じさせてくれた経験でした。

単身赴任先では当初参画したプロジェクトが落ち着いたタイミングで、お客様の情報システム部門に派遣として参画する機会を得ることができました。
主な業務内容はお客様のプロジェクトマネジメントの支援だったのですが、お客様も人が足りていない状況で支援というより、お客様と手分けして複数のプロジェクトを管理し、お客様内での報告やベンダーコントロールも行っていました。
システムを作るためのプロジェクトという意味では同じなのですが、お客様先では上流工程に携わることも多く、今までは決まっている仕様に基づいてシステムを作ることが主な仕事でしたが、上流工程では何も決まっていないところから仕様を決めていくことが仕事になり、立場が変わると仕事の内容も変わり、頭を切り替えることに苦労したことを覚えています。

そんな中で、お客様立場で仕事を進めることはもちろんなのですが、派遣として外部から参画しているという立場を活かし、ユーザー部門やベンダーなどのステークホルダーに対して、対情報システム部門には言いにくいことも、懐に入り込み聞き出すことでプロジェクトが円滑に進むように心掛けていました。

お客様の立場で業務を行った経験から、お客様がどのようなことを気にしながら業務を行っているのか、そのためどのような報告を聞きたいのかなどを知ることができ、今後の仕事に活かせる貴重な経験ができたと思います。
また、立場が変わってもコミュニケーションの重要性は変わらず、対ベンダーなどであっても「感情的にならない」「相手には相手なりの考えがあるため、しっかりと相手の話を聞く」「聞いた話は適当に扱わず、結果を必ず相手に伝える」が良い結果につながることが身をもってわかったことは大きな収穫でした。
また、異なる立場で今まで接点がなかった人たちとコミュニケーションを取り業務を進めたことは自身のコミュニケーションにおける自身にもなりました。

この頃に新型コロナが流行り、リモートでの業務も経験し出社とリモートを半々ぐらいで業務を進めていました。

改めて経歴を振り返り

20代、30代、40代と、来る者拒まずで仕事に取り組んできた結果、本当に多くの多岐にわたる経験をする事ができました。
また、コミュニケーションについては苦手意識があった状況から自分なりの取り組み方がわかったことは大きな成長であり、まずはやってみることの大切さを知るきっかけの一つになったと思います。

クラウドエンジニアを目指すようになった経緯

単身赴任終了後、この先のキャリアを考える

2017年4月から2022年9月の約5年半が単身赴任。
一区切りついた2022年10月のタイミングで、ふとこの先のキャリアについて考えることがありました。
今の延長だと、複数プロジェクトのマネジメントや部門運営などのキャリアパスが考えられましたが、「マネジメントだけでなくもっと技術に携わっていたい！」という気持ちがどんどん大きくなっていきました。
また、今のまま会社の看板が外れた時に「果たして自分は通用するのか？」という疑問が浮かび上がり、「これが得意！」を胸を張って言えない状況に焦りを感じました。

G検定の受験

考えているだけでは何も始まらないと、2022年11月にAI・ディープラーニングに関するG検定を受験しました。
無事に合格することはできましたが、この先のキャリアについて見えてくるものはありませんでした。

AWSとの出会い

その後、仕事が忙しく何も動けない日が続きます。
そんな中、2023年4月にふとしたきっかけでエンジニアリングスクールRaiseTechの説明会に参加し、そこでAWSに出会いました。
もちろん以前からAWSについて聞いたことはありましたが仕事で使ったことはなく、学んでみたいと考えたこともありませんでした。
そんなAWSでしたが、説明会から1週間後には申し込みを終えスクールの受講を開始していました。
決して受講費用は安くありません。また、私は慎重に物事を進めるタイプなのですぐに決めることはほとんどありません。
ですが、この時は1週間も経たないうちに一歩を踏み出すことができました。今でも不思議ですが、 「ここで一歩を踏み出さないと、この先何も変わらない」 気がしていました。
また、スクールの説明会で話をしてくださった代表の熱量に背中を押していただいたことも大きいと思います。
感謝。

スクールでの刺激

20数年IT業界にいる中で、最新のトレンドや技術について自分なりに情報収集はしていました。AWSやDevOps、コンテナなどのワードはもちろん知っていましたし、導入事例なども記事で見てはいましたが、「どこか別の世界の話」というか身近に感じられていませんでした。
そんな中、現役エンジニアであるスクールの講師から聞く話はそれらの技術を実際にバリバリ使っている話、それだけでなく聞いたこともない技術やサービスも当たり前のように使っていました。
ちょうど世間でChatGPTが話題になり始めたタイミング。私の周りには業務はもちろん個人で使っている人もいませんでしたが、「使うのが当たり前。使っていかに生産性を向上させるかを考えていく必要がある」なんて話も。
ベタな表現ですが、頭に雷が落ちたような衝撃を受けました。
私がまったく知らなかった世界がすぐそこにあり、それに気付かなかったのは私がそれを見ていなかったからだと思い知らされました。 「どこか別の世界」と感じていた世界がすぐそこにあると知った時、ただ単純に「私もやりたい！」 と思っていました。

AWSの可能性

スクールに通うまでAWSについて、単に「インフラのクラウド化」ぐらいにしか考えていませんでした。しかし、いざ学び始めてみると驚きの連続でした。

• ネットワークやサーバーなどのインフラ環境が画面から簡単に構築できる（わずか数分で！）
• インフラ環境をコード化でき、コードを実行することですぐにインフラ環境が構築できる
• GitHubやCircleCIなどの他のサービスと組み合わせることで、自動でインフラ環境の構築、プロビジョニング、テストが行える

などなど、挙げればキリがありません。
また、監視のサービスがあったり、サーバーレスのサービスがあったり、 「AWSがあれば何でもできるのではないか？！」 と思わせてくれる内容でした。

今の自分が通用するか

スクールに通ったもう一つの目的は 「果たして今の自分がどの程度通用するのか？」を確認するためでもありました。
IT業界に20数年いるとはいえ、最近はマネジメントがメインとなり、自分で手を動かしてモノを作ることがほぼゼロでした。とはいえ心の中には「なんとかなるでしょ」という思いを持ちながら、いきなり何も策がないまま飛び込んで、結果ダメでしたで家族を路頭に迷わすわけにもいきません。
スクールの課題は自走力を鍛えるために丁寧な解説などはなく、自分で調べたり講師・メンターに質問しながら進めるスタイル。頭が痛くなり気分が悪くなるぐらい考えることもたびたびありましたが、予定通り課題を終え無事に完走することができました。

以下のGitHubのリポジトリにはスクールの課題で作成した成果物や最終課題で作成した構成図などを記載しています。

AWS、それってインフラエンジニアじゃない？

新卒で大手SIerに就職した時、着任早々インフラエンジニアからシステムエンジニアにキャリアチェンジしました。
システムエンジニアとしてキャリアを重ねながら、ふと「あの時、インフラエンジニのままだったらどんなキャリアパスを歩んでいたのかな？」と思うことは何度かありました。
また、就活の時に実施した自己分析「仕事では技術を身に付けたいな、コツコツ取り組むのが好きだな、攻めるより守るのが好きだな」という結果は、システムエンジニアを経験した後も変わリませんでした。
まさかのここにきて インフラエンジニア ＝ クラウドエンジニア のキャリアが叶えられるかも？と、一人で何か運命的なモノを感じていました。

改めて、この先のキャリアを考える

今のまま会社の看板が外れた時に「果たして自分は通用するか？」という疑問と、「これが得意！」と胸を張って言えない状況に焦りを感じたことから、模索を始めたこの先のキャリア。
AWSでクラウドエンジニアを目指すことに運命的なモノを感じながらも、じゃあそれをどう実現していくのか？

まず、自社でAWSを使っている部門に異動してクラウドエンジニアを目指す方法が考えられます。
早速、上司に「AWSを勉強していること」「AWSを使っている部門に異動したいこと」を伝えました。予想はしていたのですが、上司や部門の反応は良いものではありませんでした。
それではと、会社が実施している社内公募に応募し異動する方法も検討しましたが、「年一回しかないこと」「次の公募は来年の夏頃になること」「応募したからと異動できるわけではなく、落ちたらまた一年待たないといけないこと」など、今からキャリアを歩もうと考えている世界のスピードからは遅く感じました。

そんな考えと並行して、今の会社ではないところでチャレンジしてみたいという気持ちも芽生えてきていました。

• 今まで歩んできたのはどちらかといえばトラディショナル畑で、どうせAWSをやるなら最新畑を歩いてみたい、ベンチャー気質を感じてみたい
• 転籍と単身赴任を経験したことで、環境が変わると大きく成長できることを実感していた
• スクールで感じたように新しい刺激に触れ、より多くの実践を経験できる環境で仕事がしたい

また、今ならリスクがあったとしてもリカバリーできるが、定年間近になって今のまま社会に放り出されてもリカバリーできないしそれこそリスクが高く、更に今からスキルを磨いておけば定年後にも活躍でき老後のリスクも軽減できるのでは？
と、途中からは半ば強引にも感じますが（笑）

クラウドエンジニアを目指して

「クラウドエンジニアを目指すようになった経緯」ということでいろいろと記載してきました。
ざっくりまとめると、以下の通り（短っ！！）

• 「これが得意！」と胸を張って言える技術が欲しい！！
• AWSすごい！！
• 刺激のある世界で自分を成長させたい！まだまだできる！！

今後やりたいこと

AWS

この先、縁がありAWSに携われる仕事ができるようになったとして、1年ほどはAWSの案件を数多く経験しスキルを身に付けていきたいと考えています。また、AWSをより広く知り「どんなことができるのか」「自分はどんなことがやりたいのか」、いろいろなサービスを使うことができる中で探求していきたいです。

お客様に価値を提供する

高校時代、勉強でわからないところをクラスメイトに聞かれ喜んでくれた経験から、「人にわかりやすく伝え、それで相手が喜んでくれること」に自分も喜びを感じ、「また聞いてもらった時にちゃんと答えられるようにしておこう」と常に誰かに説明することを想定して理解することを心掛けていました。そのおかげで自身の理解が深まる、とてもよい好循環が生まれていました。
この好循環を仕事でも生み出すために、身に付けたスキルはどんどんお客様に価値として提供していきたいと考えています。

DevOps

新卒で配属されたアウトソーシングセンターは、「開発」と「運用」がシステム課・運用課として同じ部門に属し協力しながら業務を進めており、システム課・運用課が一緒にお客様の進捗会議にも出席するなどしてお客様に提供する価値の向上に努めていました。
しかし、組織再編の中でシステム課が切り出されシステム部として別部門になりました。その後も今まで通りお客様の進捗会議には出席し、協力しながら業務を進めていたのですが、やはり別部門となったことで壁ができてしまい、昔のようにはいかない場面も出てきました。
システム部門は「お客様のためにより良い開発を行う」、運用部門は「お客様のために安定的な稼働を提供する」、どちらもお客様のためですが、組織として向いている方向性が違ってきていました。

組織の壁によって「開発」と「運用」が一緒になってお客様に価値を提供できないもどかしさを感じている中で、DevOpsという考え方に出会いました。
開発と運用が一緒になり、同じ目的を持ち、開発と運用を含め全体の業務を最適化し、さらにはCI/CDなどの技術も取り入れながら、お客様に提供する価値を向上させていく。
「私がやりたい事がここに凝縮されている！」　と思いました。

また、今まで経験してきた保守・保守開発のノウハウも活かせると考えました。

最後に

スクールで得たこと

スクールでは技術以外でもとても大きな刺激を受けました。スクールに通われている方は、みなさん仕事や子育てなどをしながらスクールに入ってまで学びたいという方達なので、とても意識が高く取り組んでおられました。また、壁にぶつかり挫けそうになり弱音を吐き、それでも前に進む姿勢は「自分も負けてられない」という気持ちにさせてくれました。
これからも大事にしたいコミュニティに出会えたことは、とても大きな財産です。

家族への思い

我が家には、小学5年生の男の子と、小学3年生の女の子がいます。
2人とも新しい興味を見つけてはどんどんチャレンジしていきます。

小学5年生の男の子は、つい先日英検4級に合格し、次は英検3級に合格すると早速勉強を開始しています。
また、塾に通いたいということで11月からはスクールバスに乗って塾に通い始めます。

小学3年生の女の子は、体を動かすことが大好きで体育スクールに通いながらダンススクールにも通っています。
体育スクールでは「バク転がしたい！」と練習に励み、家では時間があれば踊っています（笑）
ダンススクールに通い始めて3ヶ月ほどで発表会のステージで踊っていた時は、その行動力に驚かされました。

また、妻は住宅会の役員をしており、日々忙しくしています。
のんびりしている私と違い、「ずっとやらないといけないと思いながら過ごすのがしんどいから！」と自ら飛び込んでいきます。子どもたちが幼稚園の時は、幼稚園の役員をやり、夏祭りやバザーなど「やるからにはみんなが喜んでくれるように」とこちらも忙しくしていました。
そんな忙しくしている中、のんびりしている私の尻をたたき家から送り出してくれます。

そんな家族には私が活き活きと仕事をしている姿を見せていきたいと思っています。

また、単身赴任では家族に大きな負担をかけましたが、単身赴任後は家族のための時間を多く取りたいと考えています。
仕事にも打ち込み、家族との時間を確保する、そんな理想の働き方を目指していきたいです。

締め

最後までお付き合いいただきありがとうございました。
長文かつ読みにくい文章だったかと思いますが、少しでもみなさんの参考になればと思います。