ソーマ

# プロジェクト概要 顧客からの電話を外注業者にコールセンターとして委託するにあたり、社内基幹システム内の、顧客登録機能等の一部機能を外部業者でも使う必要があった。 # 開発背景 既存の基幹システムはインフラ構成が複雑だったこともあり、権限を追加して操作制限するよりは、APIを作成し、そこにを作る方が工数的に早かったので新しいアプリを作った。 # 実装内容 - 最低限の情報のみ返すAPI設計・実装 - ユーザー認証機能、顧客検索・登録機能、買取時第三者チェック機能 - Laravel のサーバーレスライブラリ(bref) を使いデプロイ - Vue3 (Composition API), Vuetify, Typescript を導入 # 技術的な詳細 ## バックエンド PHP (Laravel)選定理由： - 既存のシステム内にAPIを作成するため ## フロントエンド Javascript(Vue3)選定理由： - Typescriptとの相性が良いため - 既存の社内基幹システムではVue2 を利用し、Options APIを採用しているがコード管理においてわかりにくさがあるため。 Typescript選定理由： - まだ規模の小さいアプリであるが、将来的に現状の社内基幹システムのフロントのアルファ版にする構想があり、将来的に規模が大きくなることを想定したため。 ## インフラ AWS Lamda & ServerleFramework選定理由： - サーバーベースの運用のように、常にサーバーを稼働させておく必要がなく、リクエスト等の関数を呼び出すアクション時のみサーバーが可動するので費用の削減になるから。 - マイクロサービス化させることにより、アプリケーション全体の可用性を上げるため。 # 工夫したこと - 既存の複雑にカスタマイズされた認証とは別の、シンプルな認証機能を作成したためその共存とミドルウェアによる責務分け - 認証情報のセッション保持 - Typescriptのinterface, type構成 - 顧客の買取依頼ごとの一意のパスコードを生成するためのロジック作成

# プロジェクト概要 従来はスプレッドシートで管理していた、自社の運営する全国の小売店の現金管理帳を、既存社内CRMとデータを連携させたものにした。(既存のCRM に新機能として追加) # 開発背景 従来までの手作業でのデータの挿入を廃止し、CRM入力時にレコードが自動生成されるようにすることにより、誤入力をなくす。のちの会計作業で金額の突合作業工数を減らすため。 # 実装内容 - Laravel のサーバーレスライブラリ(bref) を使いデプロイ - 月ごと、支店ごと、買取・販売・入出金等々、種類ごとに表示方法や操作範囲を合わせた実装 - 毎日の現金カウント作業と、現金合計と管理帳の合計残高に差異が見られたときのアラートとして slack incoming webhook を使用。 - 既存CRM で使用されている買取・販売のIDを取得、表示し現金の出入と商品の種類が一目でわかるようにする。 # 技術的な詳細 ## バックエンド PHP (Laravel)選定理由： - 社内の既存根幹システムがLaravelで構築されているから。 - 一般的に学習コストが低いとされており、アジャイル開発を進めていく上で開発から本番運用までのスピード感が重要だから。 - AWS Lambda へサーバーレスデプロイを実現するにあたり、サポート言語が制限されることに加え、日本語の資料が豊富で一般的に学習コストが低いとされている laravel を選定することにより、長期的な運用や保守改修の面で利点があったから。 ## フロントエンド Javascript(Vue.js)選定理由： - 上記と被る部分であるが、開発開始から本番運用までのスピード感や臨機応変な改修にも対応する必要があったため。 ## インフラ AWS Lamda & ServerleFramework選定理由： - サーバーベースの運用のように、常にサーバーを稼働させておく必要がなく、リクエスト等の関数を呼び出すアクション時のみサーバーが可動するので費用の削減になるから。 - マイクロサービス化させることにより、アプリケーション全体の可用性を上げるため。 # 工夫したこと - 使用PCやブラウザの設定日時が実時間と違っていても必ず実時間を表示させるようなUI設計（不正な入出金操作を防ぐため。ex. 前日の入出金記録の書き換えを防ぐ） - 現金出納帳として実用的に活用するために、スプレッドシート作成APIの作成（パラメータに既定の配列をセットしてリクエストすれば自動でその月の現金帳簿が作成される） - slack web hook を利用した個別へのアラート（毎日のレジ閉め忘れ防止アラートetc.）

# プロジェクト概要 基幹システム内の既存のCS管理機能のリニューアル # 開発背景 既存のシステムの下記の問題のために、運用や登録実態が形骸化していたため、リニューアルにより解消することになった。 - CSに対する対応の流れや結果、今後の改善策などを確認できない（事象の登録のみでそのあとはスプレッドシート等での管理になっていた。） 　→一元管理できるように途中経過と結果も残せるようにする - 画像やファイルの保存、共有ができていない。 　→画像アップロード・ダウンロード機能の追加 - CSに登録された際の通知、連絡が手動とマンパワーによるものになっている。 　→Slackと連携して自動化 # 実装内容 - Serverless Framework を利用したデプロイ - Laravel と Vue.js での実装 - 基本的なCRUD - 商品・顧客情報との連携（他のDBからのデータ抽出） - S3を利用したファイルアップロード・ダウンロード - Slack API を使用したチャンネル、DMへの投稿・通知 - リスク管理委員会へ提出用のCSVの自動作成 - CSだけでなく、社内で起こった買取ミスや事故報告も記載できるように汎用的なUI設計 # 工夫したこと - Lambda を利用してs3にファイルアップロードするには容量の上限があったため、Lambda を使わずにフロントからaxiosを利用して直接アップロードした。 - CSのみを取り扱うわけではないため、UIは汎用的にし、DB設計は key, value カラムを持つ補助テーブルを作成して後の変更に柔軟に対応できる設計にした。 - リスク管理委員会へ提出用のcsvは記載方法にある程度決まりがあったので、データ取得から配列操作が複雑になり時間をかけた。 - 基幹システムのDBと、その他社内システムのDBと、DBを横断してデータを取得してくる必要があったため、DBへの接続回数やDBへの負荷が低いSQL文の作成に努めた。 - データ登録時に、記入項目がどうしても多くなってしまう設計であったため、文字はなるべく少なくして、アイコンで見た目がうるさくならないように心がけた。

# プロジェクト概要 外注ベンダーが作成したAPI(AIによる画像認識と画像マッチングAPI)と社内基幹システムの連携 # 開発背景 AIによる画像認識やマッチング機能を基幹システムに導入することにより、従業員の業務効率を改善するため。 # 実装内容 外注のAIシステムの連携やコーディングを行ったのは業務委託のエンジニア 基幹システム内から、画像をAIシステムにREST API形式でPOSTして、返ってくるマッチング度合いの高い画像を表示、その中からユーザーが選択した画像が自動で基幹システム上のフォームに入力される。 また、外注のAIシステムのサーバー上のDBへのCRUD機能の実装も行った。 # 工夫したこと 外注のAIシステム自体が開発されたのが、私の入社していない時期であったため、Slack や残った資料から開発の流れや意図を汲み取った。またその外注ベンダーにもミーティングを組んで当時の開発要件や仕様の確認、機械学習とディープラーニングについての理解、近傍方式による画像マッチングに関してもヒアリングを行なって開発に臨んだ。 実際に手を動かしたのは業務委託のエンジニアの方だったので、そのかたにそもそもの基幹システムの構成とAPIの説明を丁寧に行った。また、本番環境のバックエンドは、Lambda で動くシステムとECSで動くシステムの両方があったため、その構成によって画像の処理方法が違うことに気づき伝えることを工夫した。 そして実際に従業員が使う基幹システムでのユースケースを詳細に伝え、UI上設計の認識がお互い大きくずれないようにこまめに画面共有等を利用して確認した。

# プロジェクト概要 顧客アンケートの回答を1時間ごとにスプレッドシートに更新させるとともに、slack 社内workspace に全体に見える形で共有する。 # 開発背景 各店舗の顧客満足度のアンケート調査による把握や可視化、リアルタイムな顧客からのフィードバックを社員全体で共有する仕組みを作りたい。 # 実装内容 - Serverless Framework を利用したデプロイ - slack incoming webhook, Lambda, Event Bridge を使用してアンケート情報を毎時取得するスクリプトを自動化。お客様のアンケート内容をリアルタイムでSlackに反映させた。 # 工夫したこと - 格納されている文字列データの数値・点数化 - お客様情報と、該当の買取・販売依頼との紐付けと表示 - Slackメッセージ上の表示のさせ方

# プロジェクト概要 社内基幹システムと外部の勤怠管理システムのAPIを使用して勤怠を自動化させる。社員全員が1日の業務の終わりに基幹システム内で書く日報機能の投稿と同時に退勤処理もさせる。 # 開発背景 正確な勤務実態を把握するため。 # 実装内容 - 既存の日報提出機能との連携 - 日報提出後に退勤時間を表示させる - 各ユーザーのAPIトークンDB保存 # 工夫したこと - 正しいAPIトークンがDB内に登録されていないと日報を記入するページに訪れられなくした。（退勤せずに日報だけ提出され、ステルス残業を防ぐ）

# プロジェクト概要 社員情報が入ったDBテーブルを利用して、新入社員の登録・退職処理、管理・経理権限の付与などの処理を自動化させるアプリの開発 # 開発背景 これまでは、全て手作業でDB 登録や権限変更を行っていたので、自動化させることによる生産性の向上を図りたい。 # 実装内容 - Laravel のサーバーレスライブラリ(bref) を使いデプロイ - ビューファイルをS3 で管理、temporaryurl を使って一時的なURLの作成 - slack incoming webhook を使用して、エラーログをslack に送信されるようにする。 - python で 定期的にパスワードのリセット自動化(serverless)とslack メッセージ送信 - ELB を利用 - Google Spread Sheet に社員情報を支店ごとにシート化

# 情報システム分野の業務経験 - ルータの設定、静的IPマスカレードの設定によるポートフォワーディング - IP電話の配線 - IP電話業者とのやりとり（番号変更、移転、音声設定、一部Amazon Connect使用） - IT資産（社用PC・スマートフォン）の管理システムの外注と運用管理 - google smtp のプリンタ複合機の連携