# 業務一覧
| No. | 期間 | 概要 |
| --- | --- | --- |
| 1 | 2024年1月~現在 | 求人検索サイトの改善・運用保守 |
| 2 | 2024年1月~現在 | 社内運用システムの改善・運用保守 |
# 1. 求人検索システムの改善・運用保守
## 概要
障害者向け求人検索サイトの運用保守と要望対応、改善
## 担当
フロントエンド,バックエンド問わず基本設計から〜リリースまで一貫して1人で担当
## 使用技術
PHP, MySQL, HTML, CSS, jQuery, AWS
## 参画経緯
1人の方が社内の他業務と兼務して運用保守されており、追加開発はほぼ行わず不具合には対応する程度だった。
フロントエンド / バックエンドの開発経験があり指示がなくても自ら効率化・改善を提案実施できると
弊社社長からの推薦によって参画が決定し、開発を一手に担うこととなった。
## 課題
1. 外部システムから求職者情報は連携できているが、求人情報の連携が実装できておらず手動登録をしている状態だった。
外部システムの求人情報を当システムの求人情報として取り込みたい。
### 取り組み
当システムの求職者登録API呼び出し処理と外部システムのAPIドキュメントをもとに、求人情報取得APIの呼び出しからデータ登録までを実装した。
### 工夫点
まず必須パラメータのみで実データを数件取得してレスポンス形式を把握し、当システムのどのテーブル・どのカラムに当てはめるべきかマッピング表を作成した。
足りない要素についてはカスタマイズ項目があるかなどを外部システム運用者に確認、当システムでの表示フォーマットの要望なども合わせてヒアリングした。
外部システムのユニークIDを保持するカラムを新設し、照合して新規登録 / 更新 / 削除の処理を分岐した。
SQL負荷軽減のため1件ずつSQLを発行するのではなく、それぞれの対象リストを形成し一括SQLを作成した。
新規登録 / 更新 / 削除の一括操作について、テーブルや対象カラムを変更し他処理でも利用できる共通メソッドとして実装した。
SQLの最大文字数超過を防止するため、各カラムの最大文字数をもとに一括操作可能件数を定義、制御を追加した。
取り込み実行完了後、取り込み総数、新規登録 / 更新 / 削除それぞれの実行件数を画面に表示した。
### 成果
約1500件の求人情報について、1分弱で取り込みが完了できるようになった。
2. GitHubへのマージ後に自動デプロイを構築していたが、現在エラーが発生してしまいデプロイが実行されない。
エラー原因の特定・解消 または 新規の自動デプロイを構築して欲しい。
### 取り組み
将来を考えた上で専門外が安易に構築するのは危ういと考えインフラエンジニアを参画させたいという提案し、自社の技術に信頼がおけるインフラエンジニアを斡旋、参画につなげた。
### 工夫点
依頼があった際、まずはEC2など調べながら自分で対応できるかを確認した。
今後企業として拡大の計画がありシステムもより本格的に運用されていること・私自身がインフラ経験が浅く現状では調べながらの構築しかできないことから、将来的にトラブルが発生しインフラ再構築になるリスクなどを考えると、本格的に専門知識のあるインフラエンジニアに構築を依頼した方が良いと判断した。
単にインフラエンジニアの参画を提案するだけでなく、自社内で技術力・コミュニケーション力などを考慮して対応ができるインフラエンジニアを抜粋し、自社営業などに該当エンジニアの稼働を確保できるかなどを確認した。
### 成果
インフラエンジニアにより、デプロイエラーが解消がされ自動デプロイが動くようになった。
インフラエンジニアが参画したことにより、インスタンスの最適化、各種環境の構築など本格的なインフラ整備も始動することになった。
自社からの増員を斡旋し、自社営業にも貢献したと社内で大きく評価された。
# 2. 社内運用システムの改善・運用保守
## 概要
オフィス利用者の勤怠や健康状態の管理をするシステムの運用保守と要望対応、改善
## 担当
フロントエンド,バックエンド問わず基本設計から〜リリースまで一貫して1人で担当
## 使用技術
Laravel(Blade, JetStream), PostgreSQL, AWS
## 参画経緯
社外チームに外注して実装されたシステムだがその開発チームは解散。
1人の方が社内の他業務と兼務して運用保守されており、追加開発はほぼ行わず不具合には対応する程度だった。
フロントエンド / バックエンドの開発経験があり指示がなくても自ら効率化・改善を提案実施できると
弊社社長からの推薦によって参画が決定し、開発を一手に担うこととなった。
## 課題
1. 管理スタッフ用画面の利用者一覧において、利用オフィスを列として示したい。
### 取り組み
利用者を所属会社ごとにグループ化して表示していたため、利用オフィスでの並び替えもしくはグループ化をした方が業務がしやすいのではないかと提案した。
その結果、利用オフィスでタブ表示をしたいと要望をもらい、列追加ではなくタブで実装をした。
### 工夫点
利用オフィスを表示したい理由を考えた際、オフィスごとに利用者に対するアクションをしたいのではないかと思い、並び替え・グループ化を提案した。
提案をする際はより業務や実運用を想定しやすいように、文章だけではなく簡単なモックを作成してそのイメージを提出した。
改修対象画面を表示する際のSQLを確認したところN+1が発生していたため、納期に余裕があることを確認した上で合わせて課題を解消し、SQLの発行数を必要最小限に抑えた。
### 成果
普段直接交流をすることのないスタッフから、画面がサクサク動く・業務がしやすくなったなどの複数の感謝のメッセージをいただいた。
スタッフ情報に普段管理しているオフィスを紐づけたい、企業とオフィスを関連づけたいなど追加の要望につながった。
2. 管理スタッフを都度SQL操作で追加しているため、登録画面を実装したい。
### 取り組み
既存である利用者登録画面などを参考にしつつ、Livewireを初めて利用して実装した。
登録画面のみの依頼ではあったが、されている管理スタッフを確認する画面もなかったため一覧画面も実装した。
入力項目の必須表記を提案し採用され、新設画面だけでなく既存の登録画面にも反映した。
### 工夫点
テーブル情報にて電話番号カラムがNOT NULLになっているが利用されている様子がなかったため仕様を確認したところ、必須である必要はないとのことだったのでNOT NULLを解除した。
参考にした利用者登録画面において入力項目が必須か任意か表記がなく登録ボタン押下時にバリデーションエラーが表示されて初めて分かる状態だったため、必須の表記をしたいと提案し採用された。
必須表記について、できるだけ多くの人が直感的に理解ができるようアスタリスクなどの記号ではなく必須と文字で表示するようにした。
### 成果
管理スタッフ登録画面が実装されたことにより、管理スタッフからの依頼での開発者によるSQL操作ではなく管理スタッフ自身が任意のタイミングで登録できるようになり、開発者・管理スタッフ双方の作業軽減に貢献した。
必須項目が明確になったことにより、新規スタッフもバリデーションエラーを発生させることなく登録作業が行えるようになった。