ID:59795さん

### 使用技術 - React(typescript) - ReactKonva(ReactでCanvasを簡単に編集できるようにするためのライブラリ) - opencv-ts(OpenCVをtypescriptで使用できるようにラップしたライブラリ) ### 開発背景 とある通信制高校では、 紙に書いたレポートの回答を郵送によって提出をしている運用をしていました。 しかし郵送となると運用が手間であるため、 DX化の一環として、スマホで撮影したレポート画像をWeb上で提出し、採点までできる機能が求められました。 しかし、現在提供しているe-Learningサービスでは、 Web上での回答しか考慮されておらず、紙での回答には対応していませんでした。 そのため、既存のe-Learningのレポートの種類に手書きレポートを追加し、 手書きで書いたレポートを写真から読み取り、Web上で採点するシステムを開発しました。 ### アピールポイント #### お客様要望に対する柔軟な対応 本開発は前例となる取り組みも見つからず、手探りでの開発となりました。 その中で、最初に設計した内容からの変更や追加要望が多数発生しましたが こちらからのプッシュ提案も含め、お客様である先生の使い勝手を第一に考え 度重なる仕様変更にも柔軟に対応しました。 会社では、この新しい取り組みに対するチャレンジと柔軟な対応の姿勢が評価され - プロダクト賞 (今期で最も優れたプロダクトを作成した賞) - 部門長推薦社長賞 の2つの賞をいただきました。 #### 射影変換による採点アシスト スマホで撮影した写真はスキャナーと違い、 歪んでいたり傾いたりすることが多いため、 画像を射影変換して提出したレポートが見やすくなるように工夫しました。 紙の位置は自動検出機能による自動調整に加え、 万が一検出の誤りがある場合は手作業による調整ができるようにし、 作業効率化と柔軟性をできるだけ向上できるようにしました。 #### 手書き採点の仕組みを1から作成 もともとのe-Learningサービスでは、レポートの採点は一般的なWebの入力ボックスのみでしたが、 今回のシステムで提出された画像上に、落書きアプリのように自由に書き込める機能を、 1から追加しました。 落書きアプリでは線を引ける「ペン」 文字が書ける「テキスト」 任意の画像を追加できる「スタンプ」 の3種類を実装しています。 ### 振り返り 本プロジェクトで最も達成できたと感じていることは、 お客様の「要望」に寄り添う開発を行うことです。 特に射影変換の提案を行った際は、 もともとのヒアリング結果が「画像を回転させたい」 であったことに対し、画像をきれいに見やすくしたいという お客様の言語化できていない隠れたニーズを汲み取れたと感じています。 V字モデルに沿って開発したとき、どうしても「要件」から入ってしまい その前提となる「要求・要望」が曖昧にされるケース発生しがちです。 しかし、今回はヒアリングの内容をそのまま実装するのではなく 要求・要望を深く考えて要件や設計に落とし込んだ結果 お客様に寄り添ったといえる開発ができたと感じています。

### 使用技術 - AWS - S3 - CloudFront - Lambda (Lambda Edge) - DynamoDB - API Gateway - MediaConvert - EventBridge - terraform ### 開発背景 現在提供しているe-Learningサービスで、使用しているストリーミングサーバの 提供会社が倒産し、サービス停止することになりました。 そこで、全社的にAWSへの移行が行われましたが、移行に伴い、全社方針ではHLS配信機能が廃止となりました。 しかし、どうしてもHLS配信が行いたいという要望があり HLS配信の仕組みを個社用に構築しました ### アピールポイント #### Lambda Edgeを用いた認証付き動画 e-Learningにおける動画教材は、企業研修で使用している企業秘密の内容であったり、コンテンツサービス事業における商材になるため、不正アクセスによる情報流出を避けたいという要望が多いです。 しかし、基本的なCloudFront-S3による動画ストリーミングサーバであれば、URLを知っているすべての人がアクセス可能なため、脆弱性が問題になります。 そこで、Lambda Edgeを用いてDynamoDBにアクセスし、DynamoDBに保存されているトークンと動画URLのクエリパラメータのトークンが一致しているときのみ動画が再生可能な仕様としています。 また、Tokenを作成して保存する処理をAPI Gateway、Lambda、DynamoDBの3つを使用して行っています。API Gatewayはx-api-keyを設定しており、キーが流出しない限り不正アクセスができない仕様となっています。さらに、APIをブラウザではなくサーバ内で実行しているため、APIを実行することでキーを不正に取得されることを防いでいます。 HLS配信ではチャンクファイルが大量に生成されるため CloudFrontのビヘイビアでチャンクファイルtsのみ認証処理の対象外とし lambdaへのアクセス回数を減らしつつセキュリティを一定基準担保しました。 #### Terraformを用いたIaCでの作業効率化 現状、会社では手作業でのサーバ構築が基本になっていました。 そのため、サーバ構築に比較的時間がかかり、またミスが多発していました。 そこでTerraformを使用してIaCを実現することで、今回の複数のAWSサービスを用いた複雑なシステムであっても、安定して素早く構築できるようにしました。 ### 振り返り terraformを用いた開発は私にとって、そして会社でも初めてであり 新しい技術への挑戦になりました。 terraformを使う上でポイントに感じたことは 「terraformを使うのであれば、最初から使う」 ということです。 terraformを既存のシステムで使うことも 可能ではありますが、技術難易度があがり、工数も倍近くになると感じています。 そのため、新規作成のときから保守性を考え terraformを最初から使用することはかなり価値が高いことに感じました。 また、本件ではストリーミングサーバではterraformを用いましたが システムの基幹部分のサーバ構成は一切変更しませんでした。 現職のようにある程度歴史のあるシステムだと EC2のようなIaaS上に構築された規模の大きなシステムも多いです。 そのシステム全体をterraformのような いわゆるモダンなサーバ構成に変更することは かなり開発コストがかかります。 それに対し一部機能を切り離し、追加要件などに応じて モダン環境に切り離して基幹システムと連携することは 既存システムの継続とシステムのモダン化を両立されるうえで 有効な手段になると感じています。

# 開発概要 既存のe-Learningシステムに対し、リアルタイムのチャット機能を追加実装しました。 # 使用技術 ## e-Learning(既存機能)で使用されている技術 - C# - .NET Framework - ASP.NET - SQL Server - Windows Server(自社クラウドサーバ) - boot strap, 生js ## チャット(追加機能)で使用した技術 - React - AWS Chime (Slackのバックエンドで使用されている技術) - AWS S3 # アピールポイント ## AWS のサービスを活用したサーバレスの機能拡張 現状のe-Learningでは、自社クラウドサーバを利用していたため、一時的な高負荷に耐えられなかったり、Windowsサーバの価格高騰によりサーバ費用が負担になる問題がありました。 そのため、サーバ費用を抑えるために、AWSを用いてサーバレスの設計を行いました。主な使用技術としては、Slackでも用いられているAWS Chimeというリアルタイムのチャットを行うためのサービスになります。また、チャット上でファイルの送受信も行いたいという要望があり、AWS S3も活用しています。 ## Reactを用いたモダンなUXの実現 フロントエンドにはReactを選定しました。社内でのReactの導入実績はありませんでしたが、フリーのライブラリの導入の行いやすさを考慮し、既存の生jsを用いるよりも効率的で高品質なものが作れると判断したことが、選考の理由となります。 フロントエンドの中で特に注力した点としては、以下のような内容になります。 - 無限スクロールによる高速でスムーズなチャット一覧画面の作成 - Viteによる複数画面の処理の共通化 - SPAかつチャット機能で必要な処理をReactとAWSにまとめることにより、Windows Serverの負荷軽減