aizawa.r

### 概要 - 社内経理向けのWEBアプリの開発 - 別機能で取り込んだ帳票の表示、編集画面を担当 - 開発後に、追加開発、保守業務を継続して担当 開発:5名 保守:2名（兼用リーダーのため、ほぼ自分のみ） ### 担当業務内容 - 基本設計～総合テストまで - 帳票の表示画面、編集画面各2種類担当（Spring, Doma, Thymeleaf） - フロント エンドからバックエンドまで担当 ### 課題 - 開発が終了し、メンバーが減ったことによる残課題清算 - 顧客の経理部からの要望（画面表示が多い） ### 成果 - 経理部からの明確ではない課題をどのように解決するかを上長と相談し解決 - 帳票をWEB画面に表として出していたが、編集する際に行を増やせるようにしてほしいという要望 - jqueryにて画面上の行を増やすよう対応 - 増えた場合の処理は専用のAPIを作成し、内部的に齟齬がないように更新 - 金額入力に制限が欲しい、マイナス金額には色を付けてほしい - 正規表現にてjsを使い対応 ### 所感 - 初案件のため、技術に追いつくことで手一杯であった - 技術者ではない方からの要望をどのように解決するかを上長と考えたことは、非常に勉強になった

### 概要 - 社内開発の8種類のクロールシステムの監視、調査、改修作業 - 規模としては全国の賃貸情報や、販売物件をクロールしていためそこそこ大きかった認識 - 月次・週次の納品、 Teamsによるお客様への連絡 - 定常業務外はその他本社保守業務のフォロー 保守:2名（兼用リーダーのため、ほぼ自分のみ） ### 担当業務内容 - 8種類のクロールシステムの運用保守 - メール、teamsによる各所への月次納品作業（CSV提出） - Linuxの特定シェルによる出力、Amazon Athenaによる出力、A5M2による出力にて提出 - 調査依頼対応 - クロール取得不可ページのログ、ソース、クロール先調査 - 修正依頼による案件化（Ruby, Java：後述） - teamsによる顧客折衝（少量） - 別案件のヘルプ - Java, AWS, Springによって構成された既存プロジェクトの調査依頼 - ログの調査 - Backlogによる報告 - 修正案提出 - 実装、テスト ### 課題 - 作成した創業メンバー退職による技術負債 - 各種出力ファイルの納品作業 - エラーの監視、解決 - 紛失しかけていた管理情報の収集 - ドキュメント - ソースコード - サーバアクセス情報 ### 成果 - ドキュメント、フロー整理による俗人化の払拭 - 8種類すべて 納品方法～アクセス情報まで - 引き継ぎ資料が散らばっていたため、管理フォルダ再作成 - フォルダ構成を同一にし、足りない情報を見える化（アクセス情報、サービスアカウント、リポジトリなど） - 前任者が理解せず作った手順書を解読、全添削（フォーマットを統一） - 内容理解後の作業の単純化、不要作業工程削除（linux上の不要コマンドなど） - ブラックボックス化したソースコード解析（Java、Ruby） - 過去にGit管理されていたソースとリポジトリを発掘 - 過去のドキュメントを中心に可能な範囲のソースコード解説資料作成 - backlogへ関連項目の作成 - 管理されているサーバの調査 - 関連するサーバのクラウドサービスアカウント、アクセス方法までの表を作成（踏み台サーバや鍵情報、関連するサービス情報などを記載） - サイト変更によるクロール不可の不具合修正 - 0.5人月でRubyのクローラー修正 - リポジトリが見つからないため、winscpによる対象ソースをサーバから取得、vscodeで編集、テストへ - 別件でJavaの修正を1人月の案件化、不具合説明資料、修正提案提案資料～テストまで1人で担当 - 料金計算、工数判断、本番リリースはリーダーに協力を仰ぎ進行 ### 所感 - 創業メンバーの技術力が高く、DockerやMongoDBなど通常業務では触りづらかった様々な技術を体験した - その分、勉強量が多いかつリーダーですら内容がわからないため一からの作業が多かった - Linux操作はこの期間で体得 - 蓄積したDBで落ちることも多々あったため、削除による影響調査なども頻繁に行い勉強になった（数万～十数万レコード規模）

### 概要 - 個人開発のクローラー兼カレンダー自動登録バッチ - 保守と学習で得た知識が本当に書けるかの腕試し - 実際に使えなければ意味がないと思い、自分の中で実用性の高いものを選択 ### 実装機能 - 商品発売日クロール、html解析、csvローカル保存 - S3の登録済み販売日csvと比較、カレンダー登録データ作成、登録済みデータをS3へ保存 - カレンダー登録データをgoogleカレンダーへ登録 ### 課題 - 商品の発売時期をわざわざサイトに確認しに行くのが面倒だと感じていたため発案 - たぶんできるだろうで始めたため、技術の下調べほとんどなし - 現場で触っていたのはPython、AWSのみ ### 成果 - 何とかリリースまで成功 - EventBridgeによる月1の自動実行設定で稼働中 - 関連技術を検索し、どのライブラリを採用するかの検討が行えたこと - pythonであれば解析ライブラリにbeautifulsoupの採用など - エラーの対処をほぼ一人で完結できたこと - 特にlambdaリリースまでの手段がソース完成当初全くわからなかたため、リリースしても動かないことも多々あった - 例：クロールデータは比較のため一時csvにてローカルへ残していたが、lambdaにリリースする場合は専用フォルダの作成が必要 - 3ヶ月の期限を限りなく守れたこと - 時間をかければ解決するわけでもなかったため、作業を捨てることも大事だと学習 - 例：chaliceライブラリでlambdaへ自動デプロイが可能だったが、準備不足のため失敗⇒やむなくzip作成で手動アップロードへ変更 ### 所感 - 具体的にどうすれば便利になるかを考えられたため、実用性のある開発を選んで良かった - 保守で得た知識を少ない開発経験、自己学習を組み合わせて実現できたことは少なからず自信になった - 同時に改善案（chaliceによる自動デプロイ、poetryを使用した開発環境準備）なども出てきたため、次の課題とする

### 概要 - マンション顔認証端末向けの追加機能開発、保守 - アプリにて顔を登録、マンションで専用端末から鍵を使わずにロック解除ができる - WEBアプリ、モバイルアプリ、lambdaの改修を担当 ### 担当業務内容 - 新規連携サービス実装による既存処理修正 - lamdba ⇒ DynamoDBへ登録処理への新規のパラメータ追加、分岐実装（Python） - モバイルアプリの新規連携サービス使用時の登録自動処理、新規画面作成および、既存画面スキップ機能（React Native） - 管理画面の新規連携サービスで登録処理をした際の判定処理および表示修正。（laravel ） ### 課題 - メンバー交代のためマンション現場のテスト兼、案件を引き継ぎ - スタートアップ企業での業務のため、複数業務を同時進行でこなした - 改修作業（lambda、laravel、react native） - マンションの現地テスト ### 成果 - 設計まで終了していたため引き継いで改修作業を実施 - 修正ソースの使用技術 - lamdba（Python） - React Native - laravel ### 所感 - 現場テストは私の目的とするエンジニアの仕事でなかったため、退職 - 朝8時現地集合、開発したwebコンソールで現地の疎通確認などを行っていた - 起床時間が5時前後であったためかなりのハードワークであった