ID:60498さん

オンライン診療や医師とのチャットを行うことができるアプリです。 患者用のWebアプリ、医療従事者用のWebアプリ、システム管理者用のWebアプリ、各Webアプリとネイティブアプリに提供するAPIサーバー、インフラ構築を担当しました。 ## 役割 - Webフロントエンド/バックエンドのリードエンジニア - Webフロントエンド/バックエンドのプロジェクトマネジメント(メンバー数最大6名) ## 主な担当業務 - 設計(DB設計、API設計、技術選定) - gqlgen、entを使用したベースコードの構築 - Vite、Chakra UI、Graphql Code Generatorを使用したベースコードの構築 - Graphql Code Generatorを使用したAPI呼び出し処理(hooks)及び型定義の自動生成 - GraphQL Subscription、Redis Pub/Sub、goroutineを使用したリアルタイムチャット機能の検証及び実装 - Twilioを使用したビデオ通話機能の実装(API側のみ) - GMOPaymentを使用した定期課金機能の実装 ## 利用技術や技術選定に関する思考と行動 大きく3つのチャレンジを行いました。 - Goの全面的な導入 - GraphQLによるスキーマ駆動開発の導入 - Project-based monorepoの導入 --- ### Goの全面的な導入 #### 課題 工事現場での無傷事故報告アプリで部分的なGoの導入を行い、Rubyを使用した際の課題が解決され、かつGoを導入することのメリットを確認できました。 今回のプロジェクトは大規模だったこともあり、全面的に導入することでGoのメリットをより享受できると考えました。 ですが、Goを全面的に導入する際の課題として、**プロジェクト参加者に学習コストが発生する**ことが挙げられました。 #### 取り組み、工夫点 課題の対応として、まずは導入の背景や学習コストが発生することをプロジェクト参加予定のメンバーに伝え、合意形成を行いました。 その後、学習コストを最小限にするために、下記を行いました。 - プロジェクト参加時に必要となるスキルセットを明確にする - 上記スキルセットを習得するためのタスク一覧及び教材一覧を作成する - 勉強会を企画し、その勉強会の中で上記タスクや教材を進める - 一定期間内で毎週行いました #### 成果 上記取り組みによって、下記のような成果が得られました。 - プロジェクト参加時に必要となるスキルセットが明確であるため、必要なスキルセットのみを集中して学習することができました - タスク一覧及び教材一覧を作成することで、タスクの洗い出しや教材の選定にかかる時間を省くと共に、案件参画後も一定の前提知識を元にコミュニケーションが取れるようになりました - 勉強会を企画することで、定期的に学習する習慣を作れたことに加えて、それぞれの知識レベルを把握することで案件参画後のチケットの割り振りを効率よく行うことができました なお、全面的に導入することによって、下記のようなメリットをより享受することができました。 - コンパイル時に型関係のエラーを検出できるようになった - 部分的に導入した時よりも、広範囲のコードをチェックできるようになりました - 依存先を比較的少なくできた - 問題が発生していた大手メガネメーカー店舗向けサービスの依存ライブラリ数は66でしたが、本プロジェクト(オンライン診療アプリ)では37に抑えることができました --- ### GraphQLによるスキーマ駆動開発の導入 #### 課題 GraphQLによるスキーマ駆動開発を導入することによって、工事現場での無傷事故報告アプリで発生した**レスポンスを過度に共通化したことによる無駄なプロパティの発生**という課題の解決を試みました。 課題についての補足ですが、工事現場での無傷事故報告アプリでは大きく2つの方針でレスポンスを決めていました。 ``` 1.原則、レスポンスは対象entityの全てのプロパティを返す - セキュリティ上問題がある場合等は除く 2.子のentityが必要な場合は、リクエストで指定する - [Stripeのexpand](https://stripe.com/docs/expand)のような仕組み - 1に従い、子のentityは全てのプロパティを返す ``` 上記の方針は、画面の表示要素を変えるたびにAPI側のコードを修正しなくても良いようにするために決めたものでした。 ですが、モバイルの開発者から、**使用しないプロパティを返さないで欲しい**という要望がありました。 #### 取り組み、工夫点 上記課題を解決するためには、画面の表示要素を変えるたびにAPI側のコードを修正しなくても良いという部分は維持しつつ、特定のプロパティのみを返すようにする必要があると考えました。 そのためには、クライアント側でプロパティを指定できるようにすることが必要だと判断しました。 クライアント側でプロパティを指定できるようにする方法として、2つの方法が考えられました。 - GraphQLを導入する - RESTに[Stripeのexpand](https://stripe.com/docs/expand)と[Google CloudのAPI設計ガイドで紹介されているfields](https://cloud.google.com/apis/design/design_patterns?hl=ja#partial_response)のような仕組みを導入する 下記の理由からGraphQLを導入しました。 - expandやfieldsの仕組みを両方とも実装すると、リクエストパラメータが複雑になる可能性があった - RESTはexpandやfieldsの仕組みを実装する必要があるが、GraphQLはライブラリ側で実装されているため、リクエストパラメータのハンドリングという点においては実装コストが低く抑えられる - GraphQLは採用実績があり(宿泊者管理サービス)、問題が解決されることが明らかであった #### 成果 上記の取り組みによって、クライアント側でプロパティを指定できるようになり、最初にあげた**レスポンスを過度に共通化したことによる無駄なプロパティの発生**の解決に成功しました。 かつ、工事現場での無傷事故報告アプリでgRPCを導入した際と同じく、スキーマ駆動開発によって各クライアントとの意思疎通が容易になり、ドキュメンテーションにかかる時間も削減できました。 --- ### Project-based monorepoの導入 こちらはプロジェクト立ち上げ初期からではなく、途中から導入しました。 #### 課題 初期はAPIサーバー、Webクライアント、GraphQLスキーマの3リポジトリに分け、APIサーバーとWebクライアントでGraphQLスキーマのリポジトリをsubmoduleとして参照していました。 この構成で1ヶ月程度運用してみたところ、下記の問題が発生しました。 - GraphQLスキーマの変更を行うと、APIサーバーとWebクライアントの2つのリポジトリで変更を取り込む必要がある - プロジェクトの新規開発フェーズでは、GraphQLスキーマの変更が頻繁に発生するため、この作業が大きなコストになっていました - entの機能で自動生成しているGraphQLスキーマが最新かどうか担保できない - GraphQLスキーマをマージする際は、毎回entで変更が入っていないかを確認する必要があり、途中で変更が入るとその度にPRを出す必要がありました - 生成コードとスキーマの整合性が取りづらい - gqlgenのgenerateが失敗しているのに気づかず、GraphQLスキーマをマージしてしまうことが何度かありました - ソースコードとPRの管理が煩雑 #### 取り組み、工夫点 上記の問題を解決するためにAPIサーバー、Webクライアント、GraphQLスキーマの3リポジトリを1つのリポジトリに統合しました。 かつ、GitHub Actionsでgenerateのチェックを行うようにし、generateされていなかった場合はマージをブロックするようにしました。 #### 成果 上記の取り組みによって、下記のように問題が解決されました。 - GraphQLスキーマ変更時の作業コストが大幅に削減された - entの機能で自動生成しているGraphQLスキーマが最新かどうか担保できるようになった - 途中でentに変更が入っても、その度にPRを出す必要がなくなった - 生成コードとスキーマの整合性をCIによって自動で担保できるようになった - ソースコードとPRの管理が容易になった

工事現場で無傷事故(ヒヤリハット)が発生した際に報告を行うアプリです。 報告された内容を確認する管理者用のWeb画面、ネイティブアプリと管理者用Web画面に提供するAPI開発を担当しました。 ## 役割 - Webフロントエンド/バックエンドのリードエンジニア - Webフロントエンド/バックエンドのプロジェクトマネジメント(メンバー数最大7名) ## 主な担当業務 - 設計(DB設計、API設計、技術選定) - grpc-gateway、grpc_tools_ruby_protocを使用したgRPCサーバーのベースコード構築(Ruby、Go) - Next.js、TailwindCSS、Recoilを使用したベースコードの構築 - Amazon ECS、AWS Fargateを使用したインフラの構築 - GitHub Actionsを使用した自動デプロイフローの構築 - guardを使用したRubyサーバーのオートリロード - APIのページネーションとフィルタリング機能の共通モジュールの実装 ## 利用技術や技術選定に関する思考と行動 大きく3つのチャレンジを行いました。 - Goの部分的な導入 - gRPCを使用したスキーマ駆動開発の導入 - Amazon ECSとAWS Fargateの導入 --- ### Goの部分的な導入 今まで会社がメインで使用していたサーバーサイドの言語はRubyでしたが、この案件で初めてGoを導入しました。 #### 課題 この意思決定には、Rubyを使用した際の課題が関係しています。 私が考えている、Rubyを使用した際の課題は下記になります。 - 動的型付け言語であるため、型関係の問題が実行時に発生する - 実行速度が遅い - 大手ハウスメーカー顧客管理サービスで問題になっていました - コミュニティが衰退してきていると感じる - [TIOBE index](https://www.tiobe.com/tiobe-index/ruby)や[State of the Octoverse](https://octoverse.github.com)等の情報から衰退していると判断しました - 技術的な部分ではなく、多くの人が使っているから良いという訳ではないものの、OSSにおいてコミュニティは重要だと考えています - 特にRuby/Ruby on Railsは日本のコミュニティが盛んで、そこに大きな価値があると考えているため、コミュニティの衰退は痛手だと判断しました #### 取り組み、工夫点 上記課題から、採用する言語は静的型付け言語で、実行速度が早く、コミュニティが盛んである必要があり、いくつか候補がある中からGoを選択しました。(Goの他にKotlinとTypeScriptを検討しました) Goを選択した理由としては下記になります。 - 静的型付け言語であり、コンパイル時に型関係のエラーを検出できる - 実行速度が比較的速い - コミュニティが盛んであると感じる - [TIOBE index](https://www.tiobe.com/tiobe-index/go)や[State of the Octoverse](https://octoverse.github.com)等の情報から盛んであると判断しました - 言語仕様がシンプルであり、動的型付け言語を扱っていた人でも比較的容易に習得できる - Rubyを使っている人が多いのと、大規模なアプリになる可能性が高くプロジェクトに参加する人数が多くなることを考えると、習得難易度は重要でした - 外部ライブラリの依存先を比較的少なくできる - 大手メガネメーカー店舗向けサービスで依存関係の更新を行う際に、依存先の数が多く更新にコストがかかっており、かつ一部は更新の際にエラーが発生し古いバージョンで固定した経験がありました - そのため、依存先を少なくできることは魅力的でした ただ、社内でGoを書ける人が少なかったので、アプリケーションレイヤをマイクロサービス化し、部分的かつ段階的にGoを導入しました。 具体的にはgatewayサーバーはGo、他のサーバーは書けるメンバーが多く社内に知見がたまっているという点でRubyを採用しました。 サーバー間の通信はgRPCを使用しました。 #### 成果 上記取り組みによって、下記のような成果を得ることができました。 - コンパイル時に型関係のエラーを検出できるようになった - コミュニティが盛んであるため、さまざまな会社での利用事例を参考にすることができ、かつパッケージの更新頻度も高いことが多かった - 言語仕様がシンプルであるため、動的型付け言語を扱っていた人でも比較的容易に習得できた - 他の静的型付け言語を導入していないため比較はできませんが、言語仕様の把握や習得に大きく困ることはなかったため、この判断としています 「実行速度が遅い」という課題は、問題となっていた大手ハウスメーカー顧客管理サービスを改善した形ではないため、課題が改善されたか計測することはできませんでした。 ですが、一般的にGoはRubyよりも実行速度が速いため、本プロジェクト(工事現場での無傷事故報告アプリ)で実行速度に関係する課題が発生した際に、取り得る選択肢が増えたと考えています。 なお、「外部ライブラリの依存先を比較的少なくできる」というメリットは、Goを全面的に導入した際により実感できると考えています。 そのため、Goを全面的に導入したオンライン診療アプリの方に実際の成果を記載しています。 --- ### Protocol BuffersとOpenAPIを使用したスキーマ駆動開発の導入 #### 課題 APIのインターフェースはフロントエンドとバックエンドの間で共通の認識を持つ必要があります。 今までのプロジェクトでは、APIのインターフェースはドキュメントか口頭によって共有されており、下記のような課題がありました。 - 必要な情報が足りない等の不備が発生する可能性がある - APIの数が多くなると管理が難しくなり、実装とドキュメントの内容が乖離してしまう - 口頭も上記と同様に、伝えたタイミングから変更があった場合は、内容が乖離してしまう - 人によって書き方や伝え方にばらつきがあり、認識を合わせるのに時間がかかる #### 取り組み、工夫点 上記課題を解決するために、Protocol BuffersでAPIインターフェースを定義し、Protocol BuffersからOpenAPIを自動生成するようなフローでスキーマ駆動開発を実現しました。 なぜそのような構成にしたのかを書いていきます。 まず最初に、スキーマ駆動開発を導入する際の選択肢として一般的かつ実績が豊富なのは下記2つであると考えました。 - OpenAPI - Protocol Buffers 最初はgRPCで十分にサポートされていない言語やクライアントを考慮しOpenAPIのみを使用することも考えましたが、下記のような理由からProtocol Buffersを書き、OpenAPIを自動生成する形を採用しました。 - エンジニアが書くIDLを統一したかったため - gatewayサーバーと他のサーバー間の通信はgRPCを使用していたため、既にProtocol BuffersをIDLとして使用していました - なぜサーバー間通信にgRPCを使用しているかは下記2つが理由になります - プライベートなAPIなので、標準的なHTTP技術のみで叩ける必要がないため - URLパスやHTTPメソッド等を決める必要がなく、より必要なことのみに集中できるため(メソッドライクに書けるため) - grpc-gatewayを使用することで、Protocol Buffersでインターフェースを書きつつ、各クライアントにRESTful APIを提供することが容易に可能だったため - このことによって、記述するIDLをProtocol Buffersに統一しながらも、gRPCで十分にサポートされていない言語やクライアント向けにRESTful APIを提供することができました - grpc-gatewayを使用することで、提供しているRESTful APIに従ったOpenAPIを自動生成することも可能です #### 成果 上記取り組みによって、下記のような成果が得られました。 - スキーマからソースコードを自動生成できるようになりました - リクエストやレスポンスの型など、最低限必要な情報が揃っていることが保証されるようになりました - スキーマ(ドキュメント)と実装が乖離しないようになりました - IDLは人による記述のばらつきが少なくなるため、認識を合わせやすくなりました - 各クライアントとの意思疎通が容易になりました - ドキュメンテーションにかかる時間を削減できました --- ### Amazon ECSとAWS Fargateの導入 Amazon ECSとAWS Fargateは、サーバーレスかつコンテナ化を実現するために導入しましたので、ここでは最初になぜサーバーレスかつコンテナ化を実現したかったのかについて書きます。 #### 課題 今まではAWS EC2にAnsibleでプロビジョニングする形でしたが、下記のような課題がありました。 - 開発環境、STG環境、PRD環境でそれぞれ動作環境が違う - 動作環境が異なるため、他環境で再現しない不具合が発生しやすい - Ansible自体はVagrantで仮想環境を立てて動作確認をしていたが、Ansibleの動作確認のために仮想環境を立てるのはコストに見合わないと考えていました - 実際にその上でアプリを動かすと同じ動作環境で実行できますが、計算リソース的に無駄が多いと考えていました - EC2関連の管理作業が後回しにされていた - OSのバージョンアップなど #### 取り組み、工夫点 上記の問題を、サーバーレスかつコンテナ化をすることで解決したいと考えました。 パブリッククラウドはAWSを使用していたため、AWSで提供されているサービスであるAmazon ECSとAWS Fargateを採用しました。 コントロールプレーンはEKSでも可能でしたが、EKSはECSに比べて学習コストおよび運用コストが高いと考えており、今後何かしらの課題が発生した際はEKSにする可能性はあるが、問題が発生するまではECSで良いと判断しました。 #### 成果 サーバーレスかつコンテナ化することで、下記のような成果が得られました。 - コンテナ化することで、開発環境、STG環境、PRD環境で動作環境を統一することができました - サーバーレス化することで、EC2関連の管理作業が不要になりました - インフラ構築時のコストが削減できました - AutoScalingの容易化及び高速化が可能になりました

社員が使うアプリの認証が各アプリのサーバーで実装しており、情報が散在しているという課題がありました。 その情報を集約することを目的に、認証認可基盤を作成しました。 管理者が使用するWebアプリとAPI開発を担当しました。 ## 役割 - Webフロントエンド/バックエンドのリードエンジニア - Webフロントエンド/バックエンドのプロジェクトマネジメント(メンバー数最大2名) ## 主な担当業務 - 技術選定 - Serverless Frameworkを使用したベースコードの構築 - Next.js、Recoil、TailwindCSSを使用したベースコードの構築 - LDAP認証の実装 - ディレクトリサービスはActive Directoryを使用 - Sambaサーバーへのファイルアップロード実装 - Lambda上でAmazonLinux2のネイティブバイナリパッケージ(samba-client)を使用することで実現 - CSVをstreamにして読み込みつつDBにインサートするバッチ処理の実装 - ldapjsを使用したパスワード変更機能の実装 ## 利用技術や技術選定に関する思考と行動 インフラ構成や言語については、お客さんの方から要望があったため、要望に答える形で実装しました。 APIはAPI Gateway + Lambdaの構成になっています。 DBはMySQL互換のRDSを使用しています。(コネクション管理はRDS Proxyを使用しています。) 管理画面は「アクセスをプライベートネットワークに閉じたい」という要望があったため、会社でよく使っていたS3の静的Webサイトホスティング上でプライベートIPのみを設定できないか調査を行いました。 最初は静的Webサイトホスティングの設定のみで設定できないか調査を行いましたが、設定できないことがわかりました。 上記を調査しているタイミングでAWS PrivateLink for Amazon S3の一般提供が開始され、これで可能になると考えていたのですが、静的WebサイトホスティングはPrivateLinkに対応していないことがわかりました。 最終的にはEC2でホスティング(Nginxを使用しています)を行いました。 そういった中でも、大きく2つのチャレンジを行うことができました。 - Serverless Frameworkの導入 - Recoilの導入 --- ### Serverless Frameworkの導入 こちらはプロジェクト立ち上げ初期からではなく、途中から導入しました。 #### 課題 プロジェクト立ち上げ初期はお客さんの方でもAWS Web コンソールでインフラを変更する可能性があるということだったので、API全体の管理ライブラリは導入せず、シェルスクリプトを独自に組んでデプロイや環境変数の切り替えを行っていました。 Serverless FrameworkやAWS SAMはインフラの設定に意図しない変更が出てしまうことを懸念して導入しないという判断をしました。 しかし運用を続けていく中で、下記のような課題が出てきました。 - 基盤全体の見通しが悪くなっていた - 手動でタイムアウトの設定やメモリの設定を行っていたため、どのLambdaがどの設定をしているか把握しづらくなっていた - 属人化していた - シェルスクリプトを独自に組んでいたが、複雑になるにつれて理解できる人が限られてしまっていた - インフラ設定が共通化されていなかった - AWS Web コンソールで設定を行っていたため、設定が共通化されず微妙な差異が出ていた #### 取り組み、工夫点 解決策として、下記の3つを候補として考えました。 - Serverless Frameworkの導入 - AWS SAMの導入 - シェルスクリプトの充実 シェルスクリプトの充実は上手く作成することで多くの課題ををカバーできると考えましたが、属人化が進んでしまう可能性があると考え、候補から外しました。 Serverless Frameworkの導入とAWS SAMの導入はどちらでも解決可能でしたが、プラグインの豊富さからServerless Frameworkを導入することにしました。 お客さんの方で変更する部分が大体分かってきたというのもあり、導入にあたって大きく問題が発生しないことは想定できました。 そこで取引会社さんと交渉し、大きな機能追加開発が入るタイミングでServerless Frameworkを導入することができました。 #### 成果 導入によって下記のような成果が得られました。 - タイムアウトの設定やメモリの設定をコードで管理できるようになり、基盤全体の見通しが良くなりました - シェルスクリプトを独自に組んでいたが、Serverless Frameworkのコマンドを使用することで属人化を排除することができました - Serverless Frameworkの設定ファイルを使用することで、インフラ設定を共通化できました - プラグインを使用することでテスト環境と開発環境での実行が容易に出来るようになりました なお、上記のタイミングでJavaScriptからTypeScriptへの移行も行い、より安全に開発を行えるようになりました。 --- #### Recoilの導入 TODO: 詳細を書く

宿泊者の入退室を管理したり、スタッフとチャットやビデオ通話を行うことが出来るアプリです。 システム管理者が使用するWebアプリとAPI開発を担当しました。 ## 役割 - Webフロントエンド/バックエンドのリードエンジニア ## 主な担当業務 - graphql-rubyを使用したベースコードの構築 - Next.js、Apollo Client、Redux、Redux Toolkitを使用したベースコードの構築 - Terraformを使用したインフラ構築 ## 利用技術や技術選定に関する思考と行動 大きく3つのチャレンジを行いました。 - GraphQLの導入 - Next.jsの導入 - Terraformを使用したIaCの導入 --- ### GraphQLの導入 #### 課題 大手ハウスメーカー顧客管理サービスで発生していた問題を解決することを試みました。 主に問題となっていたのは下記です。 - 画面の表示要素を変えるたびに、API側のコードを修正する必要がある - 1画面で複数のAPIを叩いており、画面とAPIの関係が複雑になっている - APIが様々な画面で叩かれているため、どのレスポンスのプロパティがどこで使われているか把握しづらく、レスポンスのプロパティ管理が難しい(削除がしにくい) #### 取り組み、工夫点 解決策として、下記の2つを候補として考えました。 - RESTに[Stripeのexpand](https://stripe.com/docs/expand)や[Google CloudのAPI設計ガイドで紹介されているfields](https://cloud.google.com/apis/design/design_patterns?hl=ja#partial_response)というリクエストパラメータを追加し、レスポンスをリクエストパラメータに応じて変更するようにする - GraphQLを使用する どちらでも課題は解決可能でしたが、下記の理由によりGraphQLを採用しました。 - 本プロジェクト(宿泊者管理サービス)は比較的小規模であり、挑戦的な技術選定が可能であるため - 今後社内でGraphQLを導入する可能性を考慮し、小規模なプロジェクトで使用することで影響範囲を最小限にしつつ社内にGraphQLの知見をためることができるため - コアロジックを分離しておけば低コストでRESTへの切り替えが可能であると判断したため #### 成果 GraphQLの導入によって、下記のような成果が得られました。 - リクエストパラメータを変更することで、API側のコードを修正することなく画面の表示要素変更に対応することができるようになりました - 今までは複数APIを叩いていたような画面でも1回のAPIコールで済むようになり、画面とAPIの関係がシンプルになりました - 基本的には各画面用にクエリパラメータを定義するため、レスポンスのプロパティがどこで使われているかが明確になり、管理が容易になりました - 知見がたまったため、今後の開発においてGraphQLという選択肢を取ることが以前より容易になり、会社全体として問題解決の幅が広がりました --- ### Next.jsの導入 TODO: 詳細を書く --- ### Terraformを使用したIaCの導入 TODO: 詳細を書く

ハウスメーカーと住宅を購入した顧客がコミュニケーションを取るアプリです。 顧客が使用するWebアプリと大手ハウスメーカーが使用するWebアプリ、それぞれのWeb画面に提供するAPIの開発を担当しました。 ## 役割 - Webフロントエンド/バックエンドエンジニア ## 主な担当業務 - 複数画面のAPI繋ぎ込み - react-pdfを使用したWebフロントでのPDF生成 - 複数画像アップロード機能の作成 - react-tableを使用した週次カレンダー機能の作成 - 各区分ごとにソートを行う処理の作成 - 上記ソート処理のパフォーマンス最適化

ユーザーがメガネ購入後に、保険証などの情報を管理できるアプリです。 他にもユーザーの投稿、タイムライン、販売中のメガネ一覧、友達招待などの機能があります。 実際にメガネを購入するユーザーが使用するAndroidアプリと、ネイティブアプリに提供するAPIの開発を担当しました。 ## 役割 - バックエンドエンジニア - Androidエンジニア ## 主な担当業務 - バックエンド - 友達招待機能 - Railsアップグレード(4.2->5.2) - GMOPaymentを使用した決済機能のベース実装 - Android - 楽天Pay、LINEPayの決済機能 - クレジットカードのカメラ読み取り機能