あわた

- **案件概要** - 「SaaS管理」と「ID管理（IDaaS）」の２つの機能を備えた日本初のSaaS一元管理ツール(サービス名: メタップスクラウド) - アカウント管理、コスト削減、業務の自動化などSaaS管理で行うべき事を一元管理するクラウドサービス - シングルサインオンやシャドーIT対策も網羅したセキュリティー対策も同時に行う日本初のSaaS一元管理可能なサービス - 2023年10月にSmartHRに事業譲渡 - **スキルセット** ##### **言語** - Ruby3.1 - Python - TypeScript - golang ##### **FW** - Ruby on Rails7.0 - Rspec ##### **DB** - MySQL 8 ##### **フロントエンド** - React ##### **インフラ** - AWS - CircleCi - Docker ##### **その他** - Github - **開発手法** - アジャイル - Dev,Designを横断した会話が多め - **コミュニケーションツール** - Slack - Google Meets - **タスク管理** - Clickup - **担当した開発内容** - 企業内で利用するSaaSをまとめて設定できるグループ機能 - ex. 営業グループにSlackとSalesForceを設定し、そこにユーザーが所属すると、そのユーザーがSlackとSalesForceを利用可能になる - サービス利用企業の組織管理機能 - 企業内の組織のCRUD機能 - 組織構造をn階層(可変的)に作成できるように対応 - 組織に所属するユーザーのCRUD操作機能 - 組織内で利用するSaaSデータの管理等 - ユーザーの利用するSaaSを取得する際、個別で利用しているものと組織で利用しているものの両方を重複なく取得できるように取得処理を構築 - SaaSを利用しているユーザーの閲覧及びCRUDの実装 - レビュアー対応 - 端末・ブラウザ制御機能 - 利用端末・ブラウザごとに利用可否を判定する機能 - 管理者が設定した端末台数以内は自動承認し、以上はアクセスを制限 - 利用端末申請機能 - 管理者が設定した端末台数以上のアクセスの場合は申請画面に遷移 - 利用端末の申請・承認・否認フローの作成 - 申請中のログイン制御機能 - あらゆるユースケースを想定し、考慮漏れがないか、脆弱性が発生するような仕様になっていないか等を責任者と密にコミュニケーションを取って行った - ユーザー単位での連携SaaS登録・解除機能 - SaaS単位での、利用ユーザー登録・解除機能 - 組織単位での、連携SaaS登録・解除機能 - SaaSごとの利用コスト取得 - SaaSごとの自動ログイン機能 - **出したバリュー** - プロジェクトのコアになる機能の開発を行い、実装スピード面において評価いただく - 導入する企業の組織構造を管理する機能や、企業のセキュリティ対策として重要な役割を担う端末のアクセス制御機能の追加等 - スピードの改善方法 - ドラフト実装を行い、要件を固める上で、動かせるものを見ながらデザイナー、責任者と同時で実装の方向性、認識を合わせるような動き方をした。 - 新しく取り入れる技術・スキルに関して積極的に取り入れ、0→1に限らず、1→xのフェーズの開発も難なく行う - **意識したこと** - キャッシュを用いたり、ネストをさせない等、パフォーマンスを意識した実装 - 例：データ取得の際、n+1が発生しないようpreloadやeager_loadを使用したり(極力includesは使用しない)、eachではなくmapを使用/ネットに転がっているパフォーマンスの記事を参考にリファクタを定期的に行うなど - 組織管理で利用した、階層構造に関するスケーラビリティを意識した設計 - 組織階層の深さを柔軟に設定(取得)できるよう閉包モデルを用いたデータ構造を採用(gem等は不使用) - リクエストはシンプルな形を担保するために可能な限りRestfulな実装を意識して実装 - できる限り、controllerは細かく細分し、controllerに定義するメソッドはrestで対応できるようにした - 複数オブジェクトの作成、更新処理を含むロジックに関しては、formオブジェクトを作成し、そこでビジネスロジックを定義するようにした - gem選定や実装方針等、設計面に関しての相談は密に行う - フルリモートのテキストコミュニケーションは結論を完結に、理由は詳細に記載すること - 使用したことのない言語でも躊躇なく手を出していくようにしていくこと(ここで初めてpythonとgoを触りました) 　- レビュアーのチェック速度向上のために、出来るだけPRの対象スコープは小さく、細かく行うようにした 　- 元々、共有不足等でレビューのやりとり回数が多くなり、レビュー速度を出せないことが多くあった。そのためPR内に適宜コメントを追加し、実装意図や仕様等の補足をなるべく記載する事でレビュアーの負担を減らす努力をしている

- **案件概要** - 学校の職員が以下の管理を行うために利用する社内システム(機能としてはもっと多岐にわたるが、一旦自分が関わった機能は以下の通り) - 在籍中の生徒や、クラスの管理 - 生徒の保護者の管理 - 生徒の成績表管理 - 保護者が参加する - サポート業務(行事の手伝いや登下校の旗振り当番等) - 保護者総会等のイベント管理 - **スキルセット** ##### **言語** - Ruby2.7 - Python - TypeScript ##### **FW** - Ruby on Rails6 - Rspec ##### **DB** - MySQL 5.7 ##### **フロントエンド** - HTML, SCSS, Jquery ##### **インフラ** - AWS(k8s) - CircleCi - Docker ##### **その他** - Github - **開発手法** - issueベースでタスク作成し、2週間のスプリントでのアジャイル - **コミュニケーションツール** - Slack - zoom - **タスク管理** - GitHub issue - **担当した開発内容** - 生徒の通知表管理 - 生徒の通知表をデータだけでなく、s3にPDFでアップロードし、管理するよう対応 - 保護者が参加するサポート業務の管理 - slack APIを用いた指定チャンネルへの一括投稿機能 - 年度切りかえ、クラス発表日付の動的管理機能 - 印刷物(保護者や職員の学校への入退館証や、生徒の個人情報フォーム等)の一括PDF出力管理 - **出したバリュー** - 生徒の通知表管理は、学年ごとに通知表のレイアウトが異なる点や登録項目が違ったり、保護者のサポート業務管理は、保護者の応募制かつ「サポート参加した業務に応じてポイント付与し、もし応募が足りない場合はそのポイントの大小で抽選処理を行う」といった、複雑な仕様の多いシステムですが、Rubyの専任が私だけというのもあり、基本的には全て使用把握から設計実装まで自走しておりました。 - また、海外とのコミュニケーション(やり取りするのは日本人ですが)で、時差等もあったのですが、不具合や要望等あったら、レスポンスは遅くても出来るだけ半日以内に返すことを心がけていました。 - **意識したこと** - 教育委員会の方針によって、毎年仕様が変わったり、保護者や職員の要望で仕様変更する事が多いため、なるべくそこを改善しやすい形で設計するにはどうしたらいいのか？という事を意識していました。 - 基本的にRubyの担当は私1人、つまり自分の思想のコード＝プロジェクトの実装方針という形になるため、どうしたら負債にならないよう適切なコーディングができるか考えていました。

- **案件概要** - 不動産仲介の接客業務をweb上、チャットアプリ上で完結できるサービス(サービス名: ietty) - 人工知能やクラウドソーシングを活用した賃貸住宅の接客型コミュニケーションプラットフォーム - 不動産管理会社向け、不動産査定システム開発支援業務 - 既存アプリで収集した物件データをもとに、AIが該当不動産の市場価格査定を算出、査定を行うシステム - **スキルセット** ##### **言語** - Ruby2.4 - node.js ##### **FW** - Ruby on Rails5.1 - Rspec ##### **DB** - MySQL 5.7 ##### **フロントエンド** - HTML, SCSS, Jquery - React, Typescript - Swift - Android Kotlin ##### **インフラ** - AWS - CircleCi - Docker ##### **その他** - aws serveless - lambda - dynamoDB - Cognito - Github - Redash - GoogleAppScript - **開発手法** - アジャイル(週一のスプリント) - Dev,Design内での会話が多い - **コミュニケーションツール** - Slack - Snake - **タスク管理** - esa - Redmine - **担当した開発内容** - チャットサービス - 登録ユーザーへの物件提案ロジックの改修 - 非同期実行処理のツール移行(Delayedjob → Sidekiq) - チャットオペレーターが、アプリユーザーに物件の内見情報(日付/場所等)を伝達するためのメモ画面の開発 - 及び付随する操作画面の改修やチャットボットの改修を担当 - レビュアー対応 - 不動産査定システム - APIGateWay lambdaを使用したバックエンドの開発業務 - Redashによる既存DBから物件/AI(Python)による査定情報データの取得処理開発 - サインイン後、DBに保管したユーザー情報の取得処理開発 - ログイン/ヘッダー画面の画面開発（React） - **意識したこと** - 初のRubyの現場だったので、とにかく実務に際した書き方をコードリーディングをたくさんした - ABテストをよくやっていたので、ABテストの手法を学んだ - 数万件のデータを扱う非同期処理において、処理が詰まらないようにfind_batchesやbulk_insert等のパフォーマンスを考慮した実装 - reactを触るのも初めてだったので、フロントエンドの実装のお作法を書きながら学んだ - サーバレス開発も始めてだったので、Cognitoやlambda,NoSQLの設計等を密に会話

オフィス用不動産募集検索システム 元々担当者レベルが紙等で保有しているオフィス物件の募集情報を、当システムにて一元管理できるシステム こちらのRails→Rustのバックエンドリプレイスを3ヶ月のプロジェクトとして担当 住居用不動産賃料推定システム 住居用不動産の業者が、物件購入の際に対象物件の周辺物件の特徴や賃料、坪単価を検索、分析し仕入れるかの判断材料を集めるための分析システム **スキルセット** ##### **言語** - Ruby3.0 - TypeScript - Rust ##### **FW** - Ruby - Ruby on Rails7.0 - Rspec - Rust - SeaORM - sqlx - Tokio ##### **DB** - MySQL 8 ##### **フロントエンド** - React(Next.js) ##### **インフラ** - AWS - ECS - GithubActions - Docker ##### **その他** - Github **開発で意識したこと** - Rust未経験というところから、キャッチアップ及びレビューを出す速度を意識 - 早く戦力になれるようにコードの読み込みや実装 - RustやReactにおいて、誰もやったことないツール(Excel出力, PDF出力等)の選定や、実装方法の調査を積極的に、知見を持ってる人に確認しつつ自分も担うようにしました。 - Next.jsで新しく知った実装や知見を、意識的に社内Slack等で記載するようにしたり、レビューで共有することを意識しました。 - 自分の知らない知識に関しては、まずは既存のコードや実装指針を「真似」して、感覚を掴むことから始めるようにしました。 - テストの書き方やバリデーションの設け方等、自分が過去に経験したことを積極的に共有して、チームの指針を決めるための手伝いができるようにすることも意識しました。

- ナイト業界が各店舗で抱えているドライバーが、他の人手が足りてない店舗にマッチング＆配車を行うサービス(スマホアプリ、web) - キャストの業務予約を追加するための予約管理及びキャストやスタッフの管理が行えるシステム(web) - 現在α版のリリースに向けた開発及びテスト実装中 - web、スマホ、apiをすべて1人で実装しています。 **スキルセット** ##### 言語 - Ruby3.2 - TypeScript - Dart ##### **FW** - Ruby on Rails7.0 - Rspec ##### **DB** - MySQL 8 ##### **フロントエンド** - React(Next.js) - Flutter ##### **インフラ** - GCP - Firebase Authenticate - Cloud Functions - Firebase storage - Cloud Run - Cloud SQL - GithubActions - Docker ##### **その他** - Github **開発で意識したこと** - 前任者がいたのですが、α版60％程度でバグだらけで離任したとこから引き継ぎ(引継は一切なし) - Flutter, Flutter Web, GCP(firestore: NoSQL)という技術要件から完全フルスクラッチで再開発 - (0.2~3人月のキャパを用いて)6ヶ月でweb,ios,androidの3媒体で一部デモ運用開始できるような速度感で開発 - 業界特有のユーザーの背景を考慮した要件や設計の定義を密に行うように努めいています。 - イチ実装者ではなく、pdm的な視点を持って要件定義 - この機能は今必要？使うユーザーはどっちのほうが使いやすい？という議論を細かく行い、できる限り精査して進められるように意識しております。 - リリースに関しては、GithubActionsでタグを切ったり、PRマージでリリースが行えるように自動化しています。