あわた

## プロジェクト概要 在宅医療における医療報酬算定業務を行う実務者の作業効率化のためのサービス。 SSOTになる外部カルテサービスからapi経由によるデータ連携から算定ロジック、業務画面に至る一連の機能を横断的に開発し、現場で使える医療サービスを実現した中核エンジニアとして貢献 ## 役割・体制 ### 自身のポジションと役割 - 中核エンジニアとして、外部カルテ情報の取り込みから診療報酬算定ロジックの実装、管理画面の設計・開発、運用改善まで幅広い領域を担当し、機能ごとの設計・仕様整理も推進しました。 - データ連携や算定処理の主要実装を担い、医療業務の複雑な条件をシステムに落とし込み、利用者が操作・判断しやすい業務フローを構築しました。 - ファーストユーザーへの導入推進において、利用者視点を意識したUI設計や深い対話を重ね、業務効率化に繋がる提案と報連相を高頻度で実施しました。 ### チーム規模と構成 - 4名規模の開発チームで、CTOと協働しながら、新規事業の小規模かつアジャイルな開発体制で推進しました。』 ## 背景・課題 - 新規事業として立ち上げた本サービスは、医療業務における外部システムからのデータ連携や複雑な算定ルールの実装が必須であり、これらを一貫して現場で使える形にする必要がありました。 - 超小規模な開発チームであったため、前倒しで進むタイトなスケジュールに追いつくことが課題で、複数領域の業務要件を迅速に理解し実装に反映する必要がありました。 - ファーストユーザーへの導入推進では、現場の抵抗やハレーションが発生しやすく、その受け入れを促進するための工夫と改善が求められました。 ## 実際の取り組み ### 開発環境 - 算定処理を行う基盤と、Airflowを利用した外部カルテデータのデータパイプライン、実務者ユーザーが触る画面及びAPIが開発範囲。 - 外部カルテのapi連携及びデータの取得から正規化→DBへの取込、算定業務に必要なデータモデルの設計・管理画面構築までを担当しました。 - GitHubでのPR管理を中心に、仕様書やテストコードも含めた包括的なコードレビューと品質管理を実施しました。 - 開発は主にSDD,TDDによるAI駆動開発で進め、高スパンでの品質担保及びリリース頻度を担保。 ### 設計・改善内容 - モバカルの認証や患者・カルテ・検査・入退院・医師情報の統合管理を実装し、外部データを算定処理に活用可能な統一フォーマットへ変換しました。 - 診療報酬の算定要件から業務ルールを生成・判定するロジックを設計・実装し、年度別ルールの切り替えや訪問先基準の集計方式変更など仕様変更にも柔軟に対応しました。 - 管理画面では認証基盤から患者一覧、算定確定、病名登録などの業務フローを一貫して設計・実装し、利用者が算定結果を確認・修正・確定できる仕組みを構築しました。 - 算定根拠の日本語化や再算定時の差分確認機能を追加し、業務担当者が自動算定の内容を理解し判断できるように工夫しました。 - 大量データによるメモリ不足への対応や差分同期、リリースの自動化など、運用面の改善も継続的に推進しました。 ### その他アピールポイント - 利用者視点を重視し、UI/UXの動線設計や深いユーザー対話を通じて実務効率化に繋がる提案を高頻度で行い、ファーストユーザーの導入促進に貢献しました。 - 開発と運用の両面で品質と効率を維持するために、細かな報告連絡相談を徹底し、チーム内外のコミュニケーションを円滑化しました。 ## 成果・価値 - 複数リポジトリに跨る約1068件のPRを通じて、外部データ連携から算定処理、管理画面の業務フローまで一貫したシステムを構築し、Cloud Clinicの現場利用を支えました。 - ファーストユーザーへの導入推進期間を数ヶ月単位で短縮し、事業立ち上げのスピードアップに寄与しました。 - 複雑な医療業務の条件をシステムに落とし込み、利用者が理解・判断しやすい機能を実装したことで、業務効率化と運用性向上を実現しました。

- **案件概要** - 「SIer,ITコンサル業界」に特化した求人プラットフォーム開発 - 求職者管理を行う業務システムのフルスクラッチ開発 - **スキルセット** ##### **言語** - Ruby3.4 - TypeScript ##### **FW** - Ruby on Rails7.1 - Rspec ##### **DB** - PostgresSQL ##### **フロントエンド** - React 18 - Next.js 15 - OpenApiによるスキーマ定義 ##### **インフラ** - AWS - Github Actions - Docker ##### **その他** - Github - **開発手法** - アジャイル - Biz,Dev,Designを横断した会話が多め - **コミュニケーションツール** - Slack - Google Meets - Figma - **タスク管理** - Github Project - **担当した開発内容** - 求職者、求人企業、運営サイド画面の開発全般 - スキーマ駆動開発の導入 - 新機能作成からパフォーマンス改善まで幅広く対応 - 求職者登録動線、マイページのレイアウト、登録内容刷新 - 検索パフォーマンスの改善など(クエリチューニング、ElasticSearchの導入など) - 元々全ての画面から同じエンドポイントを読んでおり、model層に権限の考慮が組み込まれていたので、画面ごとにエンドポイントを分けるように設計見直し - フロント、API問わずフルスタックに実装 - レビュアー対応 - 新業務システム技術選定、MVP作成 - ローコードで作成していた業務システム→フルスクラッチにするための交渉 - Next.js、Prisma、All TypeScriptでの開発における技術選定や実装方針の策定 - 上記開発業務に関わるdevOpsや、プロジェクト管理の整備 - bizサイドからの開発依頼、Issue書き起こし、PRレビュー、などをSlackワークフローによる簡略化 - GithubProjectによるタスク管理を、フィルターを用いたり、タブ単位で用途分けして整備 - 関連するリポジトリが4つ(求職者、企業、運営、API)あったので、stagingやproductionリリースをするための一括リリースPR作成をActionsで自動化 - マーケサイドで用いる、LPからの流入の受け皿になるノーコードフォームツールの選定、実装(入力条件に応じたスコアリングの実装も込み) - エンジニア採用に関わる業務 - 採用広報、技術ブログの立ち上げ - 採用広報記事の投稿 - カジュアル面談の対応 - スカウト内容に関する意見提案等 - **意識したこと** - テックリードポジションとして活動していたので、いかにチームがストレス少なく、快適な開発体験を得られるか？という点を意識して開発環境の整備をしてきました。 - 一方的にこれでお願いしますという形ではなく、これでどうでしょうか？というスタンスでチームメンバーとやり方をすり合わせしながら、確実に良い方向には進む技術選定や方針設定をするよう心がけました。 - 採用業務等は、ただ見極めるだけでなく、こちらの魅力づけやいかに「栗田」に対しても好感を持ってもらえるように話を展開させるか？という点も気にしておりました。

オフィス用不動産募集検索システム 元々担当者レベルが紙等で保有しているオフィス物件の募集情報を、当システムにて一元管理できるシステム こちらの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等で記載するようにしたり、レビューで共有することを意識しました。 - 自分の知らない知識に関しては、まずは既存のコードや実装指針を「真似」して、感覚を掴むことから始めるようにしました。 - テストの書き方やバリデーションの設け方等、自分が過去に経験したことを積極的に共有して、チームの指針を決めるための手伝いができるようにすることも意識しました。

- **案件概要** - 「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の設計等を密に会話

- ナイト業界が各店舗で抱えているドライバーが、他の人手が足りてない店舗にマッチング＆配車を行うサービス(スマホアプリ、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マージでリリースが行えるように自動化しています。