hal_18

## 概要 ■開発、その他業務 ①講師/スタッフ向け管理システム(授業管理・学生管理)の開発/保守 ②予備校生向けシステム(授業カレンダー等)の開発/保守 　・クライアントの要望を基に仕様確認、要件定義、設計 　・部署ごとの要望をヒアリングし、工数見積もりから実装まで担当 　・テストケース作成、テスト実施 　・ステージング/本番環境デプロイ - 期間：2020年4月〜10月 ## 使用技術・言語 　- OS: Mac 　- DB: Mysql 5.9 　　本番/テスト環境にてDB調査・作成・修正など 　- SCM: Git (CodeCommit) 　　共同開発 　- IDE: Cloud9 　- 言語: Ruby 　- FW: Ruby on Rails 　- UI-FW: Bootstrap 　- インフラ:AWS ## 取組内容 - エンジニアとしての初業務 当初は分からないことばかりでしたが、Sentryによるエラー通知があれば率先して対応し、システムの全容把握、キャッチアップに努め、開発量を上げていきました。 PJ終盤では新規アサインされたメンバーに対し、システムの概要や、定例で行う作業について説明し、PJの教育面でも貢献することができました。 - 学生管理機能の充実化 講師/スタッフ向け管理システムについては、前年度にメイン機能である授業管理部分はリリースしており、運用開始しているフェーズでした。 先方から「今後学生管理も充実化させたい」というニーズをヒアリングし、私は主に学生管理機能の追加実装を担当しました。具体的には、学生との個人面談管理機能、経歴機能、志望校・入試結果情報管理機能を開発しました。 - 学生の志望校、入試情報の登録機能作成 上述しましたが、志望校・入試結果情報の追加実装は講師/スタッフ向け管理システム及び学生向けシステム、いずれも私が担当しました。 先方へのヒアリングをもとに要件定義を行い、設計・開発までを一貫して行いました。 その上で、苦労したこと・意識したことを下記に記載します。 - 要件定義／DB設計 どういったテーブルが必要かを考え、先方から取得した大学一覧データ（スプレッドシート）を整形し、MySQLでDBにインサートしました。 さらに、大学に紐づく学部・学科テーブルを子テーブルとして作成し、それらのデータもインサートしました。 - 入力フォームの実装 学生向けシステムに関しては、それまで授業予定やコースの残時間等のDBデータを出力するのみであったため、本機能の追加にあたり、入力フォームの整備・導入自体を一から行いました。 UIに関しては、slim, jQuery, CSS, Bootstrapを用いました。学生から予期せぬ入力を防ぐため、autocompleteを活用したセレクトボックスをベースに実装しました。 また、autocompleteで学校情報を表示する必要があったので、GrapeAPIを導入し、APIによるデータ取得も実装しました。 - カスタムバリデーションの作成 学生からの入力、ということを踏まえ、データの整合性意識しバリデーションはしっかり作成しました。 具体的には ・学生は複数校に合格した場合も、「入学」ステータスを選択できる学校は一つ ・「不合格」を選択した場合は「入学」を選べない などです。 また、セキュリティの観点から、別生徒の志望校・入試情報のページにアクセスした際はホーム画面へリダイレクトする仕様にしました。 - 月初の定例作業をWheneverでバッチ化 毎月月初に、前月分の授業データを一括更新する作業がありました。それまで毎月手動でActiveRecordコマンドを実行し、updateする運用だったのですが、非効率だと感じたため、Wheneverを用いた定期バッチ化を提案、実現しました。 また、バッチ実行後、その結果をSlack通知するようにし、結果もすぐに確認できるようにしました。これにより毎月の無駄な工数を削減することができました。

## 概要 ■開発、運用・保守 - BPO事業会社向け社内の販売管理システムの開発・運用・保守 　・主に2021年4月の会計基準変更に対応するための追加開発 　・クライアントの要望を基に仕様確認、要件定義、設計 　・定期バッチの作成、改修 - 期間：2020年10月〜現在 ## 技術・言語 　- OS: Mac 　- DB: Mysql 5.9 　　本番/テスト環境にてDB調査・作成・修正など 　- SCM: Git (GitHub) 　- 言語: PHP, TypeScript 　- FW: Laravel 　- UI-FW: React 　- IDE: VScode 　- インフラ:AWS, Docker ## 取組内容 - 売上会計基準の変更に伴う追加開発 2021年4月の会計基準変更にシステム上で対応すべく、追加開発の必要がありました。 これまでは納品日ベースで売上計上していたものを、新たに「検収日」ベースに変更する追加実装を行いました。 エンジニアは私一人であったため、先方のPMに要件をヒアリングし、設計から実装、検証まで行いました。 具体的には下記に関わる実装を行いました。 - 納品テーブルに、新たに検収完了日ログテーブルを紐付け(検収完了日を記録するため) - 検収完了日は、顧客に発送したメールをクリックするとその日付が入力される - 金額が100万以内であれば、バッチによる自動検収可 - 検収完了確認メールの送付先は、複数人を選択可能(納品ページで指定する) - メール送信先テーブルを新たに作成、納品書と紐付け - 検収日が入力後でないと、請求書は申請できない - 検収未完了案件、メール送付先一覧、自動検収対象案件等は日時バッチを作成し、毎日実行 これらの追加機能は無事に4月頭にリリースは完了し、現在運用開始しております。 - 使用技術について - バックエンドはLaravel、フロントはReact(TypeScript) - API周りではSwaggerを導入しており、Laravel側のコードを基にswagger-generatorで自動でクライアント側の型定義を行い、TypeScriptによる型安全な実装 - Reactではクラスコンポーネントで記述、状態管理はMobxを使用、ページ遷移はReact Routerを使用 - UIフレームワークはant-designを使用 - バッチに関してはLaravelで実装。バッチによっては、内容をSpreadSheetに出力し、結果のSlack通知まで実装した - 新規バッチ追加の際、AWS Lambdaを使用 バッチは全てLaravel側で実行していましたが、日時バッチが増えてRDSのメモリ使用率が上昇するケース多々発生するようになりました。そこで、新規バッチを追加するAWS Lambdaの導入を提案、実装まで行ないました。 今後は既存バッチもLambda以降を検討中です。 - Lambda関数を新たに作成し、RDSへ接続 - RDSから必要情報取得し、その内容をSlack通知する - Lambda関数はCloudWatch Eventsをトリガーにし、Cron式により毎日定期実行する ## 今後の課題、個人的にやりたいこと - システム自体は3年前に大枠が作られたものであり、Reactのバージョンが古く、記法もクラスコンポーネントであるため、関数コンポーネント・Hooksへのリプレースを行なっていきたい