こんにちは。 デバイスソフトウエア開発部の伊與です。 私は異業種転職でエコモットに入社し、はや半年以上過ぎました。 今回は、私が実際に異業種転職してみて感じた現状や、前職とのギャップについてお伝えします。 特に、以下のような方々のちょっとした一歩や助けになれば幸いです。
- 異業種への転職に悩んでいる方
- エコモットでの仕事に興味がある方
- 医療職(看護師)から新しいキャリアを目指したい方
簡単なプロフィール
- 前職：看護師(主に病棟勤務)
- プログラミング経験：オンラインスクール(約半年) + 職業訓練校(半年)
前職との違い
重ねてになりますが、私の前職は看護師だったため、これからお伝えする内容は少し医療職ならではの感想になっているかもしれません。 医療職からIT企業や一般企業に転職したい方には、参考にしていただける内容かなと思います。仕事の管理の仕方が「タスク単位」から「時間・成果単位」へ
個人的な意見ですが、看護師の仕事は「業務単位・その日のタスク」で管理されていたなと思います。 『今日は〇〇さんの採血、○○さんは点滴……』というように、決められた業務を確実にこなしていくスタイルです。 極端な話、目の前の業務さえすべて実施できれば、いつか仕事は終わります。 一方、現在のエコモットでの働き方は、1日単位のルーティンではなく、プロジェクトで計画された予定工数を元に、課題に対する「時間を管理」します。 プロジェクトはあらかじめ決められた予定工数(スケジュール)に沿って進むため、「何の課題に、何時間使ったか」を管理し、予定を超過しないよう、工数管理が必要になります。 最初は、この時間の管理が苦手で、『時間メモするの忘れた！』『時間の計算が合わない！』とスムーズにいかないことばかりでした。(今でも苦戦していますが……(´・ω・`)) また、看護師の業務は目の前のタスクを順番にこなしていけばよかったですが、現在は「決められたスケジュールまでに、求められる成果物や結果報告を出すこと」が求められます。 スケジュールに収まるのであれば、タスクを始める順番などは自分の裁量で調整できますが、看護師の業務とは違い、時間をかけたからといって必ずしも成果が出る確証はありません。 いかにスケジュール内に成果を出すか、日々試行錯誤しています。スケジュールが自由にコントロールできる
病棟勤務の時は、他のスタッフと休み希望が重なると休みが取りづらい……ということがあると思います。 しかも、『いつの間にか有給が使われていた』というのも医療職あるあるですよね……(シフト制なので仕方ない部分もあるのでしょうが……！) しかし、現在はいつ有給を取るかは、自分で決められます。 自由に休める分、「自分の仕事(課題)の管理は自分で責任を持つ」という自律は必要ですが、前職と比べると直前の予定が立てやすくなりました。 また、病棟勤務の時と大きく変わったのは、「平日に連休を作る時の仕組み」です。 シフト制の頃は、「土日に出勤する分、ここの平日に休みをください！」という調整が可能でしたが、現在は土日祝休みがベースです。 そのため、平日に連休を取りたい場合は、休みをずらすのではなく、自分の有給休暇を組み合わせてスケジュールを組む形になります。 「じゃあ平日の用事は有給を使わないと済ませられないの？」というと、そんなことはありませんでした。 なぜかというと、エコモットは「フレックス制度」があるからです。 出退勤の時間は自分でコントロールできるので、『17時過ぎに用事があるから、今日は17時に退勤しよう！』という調整ができます。 そのため、カレンダー通りの土日祝休みの生活になりましたが、平日の動きにくさで困ることは意外とありません。憧れのリモート勤務と働く環境の変化
エコモットではリモート勤務も導入されているため、医療職ではなかなか実現できないリモート勤務ができるようになります！ 私は普段は出社して勤務していますが、例えば大雪で出勤するのが大変な日などは、無理せずリモート勤務に切り替えることができるので、大変助かっています。 医療職だと、ほぼ出勤しないと勤務できないので、どんなに雪が降っても、絶対に病院に行かなければなりませんよね……。 医療職からすると、家で仕事ができるリモート勤務は憧れでした。 ただし、1日中座りっぱなしになるデスクワークならではの大変さはあります。(肩こりとか腰痛とか……)異業種転職を支えてくれたAIの存在
エコモットに入社して半年以上経ち、異業種からの転職でありながら、日々の業務ができているのは、AIの存在が大きいです。 私が入社した頃には、生成AIを使った開発(コード生成等)が当たり前に行われていた環境でした。 そのため、新しいコードを書くときはもちろん、既存のコードを読み解くという場面でも助けられました。 もしAIがなければ、未経験の私が現状の課題をこなすのは、何倍も難しかったのではないかなと思います。 ただし、AIは万能ではないため、「AIに丸投げする」「理解しないまま進める」と、後から自分が困ることになります。 だからこそ、出来上がったコードを自分の目で確認したり、どんなロジックで動いているのかを理解することが大切だと感じています。 たまに難しすぎて理解しきれないこともありますが、後日「そういうことか！」と閃いたりもするので、深みにははまらないようにしています。 今の環境は未経験から異業種転職する方には、とてもありがたい環境だと実感するばかりです。実務紹介：証明書自動更新スクリプト作成
ここからは、現在私が担当しているサービスで作成した、証明書自動更新のスクリプトをご紹介します。 今後、SSL証明書の有効期間を短縮する動きが進んでおり、これにより手動の証明書の更新作業の頻度が多くなってしまうことから、自動更新を導入する流れとなりました。 (※SSL証明書は、Webサイトが安全であることを証明するものです) 今回は、Let’s Encrypt(レッツ・エンクリプト)という機関が発行する無料のSSL/TLS証明書を自動で取得・更新してくれるツール「Certbot(サートボット)」を使用し、Linuxサーバー上で一発で設定が完了する自動化スクリプトを作成しました。事前準備
CertbotがSSL証明書を発行・更新する時は、「本当にドメインの所有者なのか」確認が必要になります。 今回証明書自動更新スクリプトを導入したサービスは、AWSを利用しているため、DNS認証（DNS-01 チャレンジ）で確認を行いました。 DNS認証では、本当にドメインの所有者かを確認するために、ドメインのDNS設定（AWSだとRoute 53）に、TXTレコードを書き込めるかを確認します。 そのため、Route 53の書き換えの許可、つまりIAMポリシーの作成が必要になります。 AWSコンソール＞ポリシー＞ポリシーの作成 で、Certbot用のIAMポリシーを作成します。 一つずつ手動で設定していくこともできますが、ポリシーエディタをJSONに切り替えると、JSONデータを貼り付けて作成することができます。 今回は、書き換えられるレコードやレコードの種別を限定し、他のレコードに影響がないよう、次の内容で設定しました。- ChangeResourceRecordSets：Route 53 のレコードを追加・更新・削除する権限を付与
- hostedzone/ホストゾーンID：変更対象を対象のドメイン名のホストゾーンに限定
※ホストゾーンは、AWSコンソール＞Route 53＞対象のドメイン名から確認できます。 - route53:ChangeResourceRecordSetsNormalizedRecordNames：変更対象のレコード名をDNS認証用の専用レコード（_acme-challenge.ドメイン名）に限定
- route53:ChangeResourceRecordSetsRecordTypes：レコード種別をTXTに限定
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 |
{ "Version": "2012-10-17", "Statement": [ { "Sid": "ListAndGetChange", "Effect": "Allow", "Action": [ "route53:ListHostedZones", "route53:ListResourceRecordSets", "route53:GetChange" ], "Resource": [ "*" ] }, { "Sid": "AllowOnlyAcmeChallengeTxt", "Effect": "Allow", "Action": [ "route53:ChangeResourceRecordSets" ], "Resource": [ "arn:aws:route53:::hostedzone/ホストゾーンID" ], "Condition": { "ForAllValues:StringLike": { "route53:ChangeResourceRecordSetsNormalizedRecordNames": [ "_acme-challenge.ドメイン名" ] }, "ForAllValues:StringEquals": { "route53:ChangeResourceRecordSetsRecordTypes": [ "TXT" ] } } } ] } |
スクリプトの実行
このスクリプトを実行すると、以下のステップを自動で行います。- 環境固有の設定
ドメインや登録するメールアドレス、毎日確認する時間を指定します(ここは自分で値を入力します) - インストール
新しいPython環境を作り、certbotをインストールします - 事前通信テスト
AWSのRoute53と正しく通信できるかをテストします - 初回証明書発行
初回の証明書を発行します(既に有効な証明書の残り日数が30日以上ある場合はスキップされます) - systemd 設定（自動更新のスケジュール設定）
1で指定した時間に毎日自動で証明書の確認を行うよう、サーバーにスケジュールを登録します - 最終診断
今後の自動更新がうまく動くかをシミュレーションし、次回の確認の実行予定日を表示します
setup.sh)がこちら↓です。
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 |
#!/bin/bash set -euo pipefail # ========================================== # 1. 環境固有の設定 # ========================================== DOMAIN="ドメインを入力" EMAIL="登録するメールアドレスを入力" RENEW_TIME="確認する時間を入力（hh:mm:ss）" echo "--- Certbot (Python 3.12) Fully Automated Setup Start ---" # ========================================== # 2. インストール # ========================================== echo "[1/5] Installing Python 3.12 and Certbot..." # AL2023のリポジトリから Python 3.12 をインストール sudo dnf install -y python3.12 # 既存の古い仮想環境がある場合は削除してクリーンにする if [ -d "/opt/certbot" ]; then echo "Old virtual environment found. Removing..." sudo rm -rf /opt/certbot fi # Python 3.12 を使用して仮想環境を作成 sudo python3.12 -m venv /opt/certbot # 仮想環境内の pip をアップグレードし、Certbot 関連をインストール sudo /opt/certbot/bin/python3 -m pip install --upgrade pip sudo /opt/certbot/bin/python3 -m pip install certbot certbot-dns-route53 # シンボリックリンクの作成 sudo ln -sf /opt/certbot/bin/certbot /usr/local/bin/certbot # ========================================== # 3. 事前通信テスト (certonly --dry-run) # ========================================== echo "[2/5] Testing Route 53 permissions..." if ! sudo certbot certonly \ --dns-route53 \ -d "${DOMAIN}" \ --dry-run \ --agree-tos \ --non-interactive; then echo "ERROR: Route 53 communication failed. Check IAM Policy." exit 1 fi # ロック解放待ちのための待機 echo "Waiting for process to release locks..." sleep 5 # ========================================== # 4. 初回証明書発行 # ========================================== echo "[3/5] Issuing real certificate..." sudo certbot certonly \ --dns-route53 \ --agree-tos \ --email "${EMAIL}" \ --no-eff-email \ -d "${DOMAIN}" \ --deploy-hook "systemctl reload nginx" \ --non-interactive # ========================================== # 5. systemd 設定（自動更新の仕込み） # ========================================== echo "[4/5] Setting up systemd timer..." # サービスファイル作成 sudo tee /etc/systemd/system/certbot.service >/dev/null <<'EOF' [Unit] Description=Certbot After=network-online.target [Service] Type=oneshot ExecStart=/usr/local/bin/certbot --quiet renew --no-random-sleep-on-renew --deploy-hook "systemctl reload nginx" PrivateTmp=true [Install] WantedBy=multi-user.target EOF # タイマーファイル作成 sudo tee /etc/systemd/system/certbot.timer >/dev/null <<EOF [Unit] Description=Certbot Schedule [Timer] OnCalendar=*-*-* ${RENEW_TIME} RandomizedDelaySec=3600 Persistent=true [Install] WantedBy=timers.target EOF sudo systemctl daemon-reload sudo systemctl enable --now certbot.timer # ========================================== # 6. 最終診断 (renew --dry-run) # ========================================== echo "[5/5] Running final renewal simulation..." if sudo certbot renew --dry-run; then echo "--------------------------------------------------" echo "✅ SUCCESS: Certificate issued and auto-renewal tested!" echo "Next Run: $(sudo systemctl list-timers --all --no-pager certbot.timer | awk 'NR==2 {print $1, $2}')" echo "--------------------------------------------------" else echo "❌ WARNING: Renewal simulation failed. Please check logs." exit 1 fi |
|
1 2 3 4 5 |
#実行権限を与える chmod +x setup.sh #スクリプトを実行する sudo ./setup.sh |
