ID:72708さん

## プロジェクト概要 ### 背景・目的 - 利用ユーザーと健康指導を担当する自社の医療従事者が面談を行う際、日程の調整において日程管理が手動になっており、50人以上と面談を行う医療従事者にとって大きな負担となっており、そこの業務負担を下げたいという話があった。 - 利用ユーザーには50代後半以降の高齢な方が多く、ITリテラシーが低いことが予想されるため、既存の日程調整ツールやSaaSで必要となるメールアドレスや名前の入力の際に離脱や打ち間違いが予想され、その調整で医療従事者の業務負荷がさらに増えてしまう懸念があったため、**自社のユーザーデータをうまく使うことで認証が必要のない日程調整アプリを自作する**という話が浮上した。 ### 規模感・チーム構成・担当した役割 - PdM1名、フロントエンド1名、バックエンド1名、デザイナー1名の4名で開発を行い、適宜医療従事者1名にステークホルダとして参加してもらっていた。 - 私はバックエンドエンジニアとして、要件の定義とバックエンドAPI開発およびインフラ構築に関わった ### 使用技術・開発環境 - バックエンドではGoを使用し、echoとgqlgenを使ってGraphQL APIを構築した。(※それぞれの役割については課題へのアプローチの項目で後述) - インフラはAWSを使用して、ALB+ECS+RDSの構成で作成した。 - また、既存プロダクトとの連携を行うためにVPC Lambda+APIGatewayを用いたREST APIの作成も行った。 - 構成は全てTerraformを用いて行った。 ## 取り組んだ課題とそれに対するアプローチ ### 課題 ビジネス課題としては以下のようなものがあった - 医療従事者はGoogleカレンダーで日程管理しているため、**Googleカレンダーと連携**したい - ユーザーのリテラシーを考慮し、**ユーザーが日程を提出する際の認証は不要としつつセキュリティは担保しなければならない** 開発課題としては以下のようなものがあった - 既存のAPIのインフラ環境はコンソールで作成されているか、その環境でしか使えないようなterraformコードになっており、参考にするにしてもAWSコンソールを毎回見に行く、terraformコードを都度新環境に読み替えるなどの手間がかかっていた - プロダクト間の連携が定期実行のバッチ処理依存となっており、開発当初の工数がなかったことのみがそうなった事情であるという話を社内でヒアリングできていたことから、**APIでのプロダクト間連携ができるように環境を整える必要があった。** ### アプローチ - Googleカレンダーを使用する際に必要なアクセストークンが取得でき、かつ認証周りの実装もカットできるGoogleログインを採用した。これにより、Google認証レイヤとGraphQL APIレイヤが分断されてしまったので、echoを使用しmiddlewareでこれら２つの橋渡しをすることでGoogleログインとGraphQL APIの両立を実現した。 - 認証については自社にユーザーのデータがあることを活かし、期限付きのトークンを発行しユーザーと関連づけることでセキュリティを担保しながら認証を不要とした。 - terraformコードを今後の新規開発の際の参考にできるように作ることを意識した。既存のterraformコードではECSとRDSなど大まかな構成のみコードかされていたが、このPJにおいてはVPCやサブネット、セキュリティグループなどのネットワーク周りやCodePipelineなどのCD環境も全て含めてterraform apply一回で構築できるように作成した。 - API GatewayとLambdaを用いて、プロダクトのデータをCRUDするAPIを作成して既存プロダクトとの連携にはそれを用いた。RDSアクセスのためにVPC Lambdaとし、コネクションが枯渇しないようRDS Proxyを用いた。またこれらをあらゆる環境で使えるように意識したterraformコードを作成した。 ## 成果 新規ツールを使って業務を改善するところまでいけないほどに医療従事者の業務負荷が高く、運用開始に至ることができていない。 しかしながら、アプリについては、トライアル段階で「面白いくらいに自動化できる」と高評価を得ることができている。

## プロジェクト概要 ### 背景・目的 - 医療従事者の業務負荷が高いことが課題となっており、中でも健康保険組合に提出する報告書の校閲業務に大幅に時間を取られているという背景があり、医療従事者の業務効率改善のためPJが立ち上がった ### 規模感・チーム構成・担当した役割 - PdM1名、PM1名、フロントエンド1名、バックエンド1名、の4名で開発を行い、医療従事者4名にステークホルダとして参加してもらっていた。 - 私はPMとして、課題のヒアリングからプロジェクトの立ち上げ、要件の定義と一部のバックエンド実装に関わった ### 使用技術・開発環境 - Go, Typescript, Vue.js, GraphQL ## 取り組んだ課題とそれに対するアプローチ ### 課題 - 校閲プロジェクトとして大きく一つのプロジェクトが立ち上がったが、状況をヒアリングしたところ、課題は大きく2つに分けられることが判明した。 - 社内システムで報告書作成 -> Dropbox共有ファイルで共有 -> 社内システムに戻って修正というフローが手間であること - そもそもの校閲業務に対し、かかる時間と質に個人差があること これら2つの大きな課題に対し、それぞれ社内システムの機能追加とGPT4の導入によって解決する方向で進めることになった。 ### アプローチ - 校閲機能の追加では、GithubのコードレビューとMiroというホワイトボードアプリをイメージしながら、報告書のプレビューに対しコメントを残せるような機能を検討。業務の実情に合わせて必要な機能のみに絞って実装をしていくよう意識した。 - 特定のメンバーに校閲業務が偏ることがないよう、校閲実績を可視化できる画面を追加するなど、管理者視点での機能作成も行った。 - AIによる校閲では、医療従事者が使いやすいものにできるかトライアルを行った。私の方でtypescriptを用いてGUIで文章を校閲できる簡易アプリをトライアル参加者に共有しフィードバックを集め、報告書のような厳格な文章が必要なシーンではGPT4でないと精度が足りないことがわかったためGPT4を導入する運びとなった。 - のちにこのAI校閲の企画はペンディングとなったのだが、トライアルで試し続けたことをサンクコストとしてしまいAI校閲を無理に実現しようとするというようなバイアスに陥ることなく事業インパクトを考えて別のPJ優先のためにペンディングを選択できたのは良かった点と言える。また、今後AIを導入する際のノウハウを社内に残せたことも大きかった。