ID:64567さん

# 概要 - チケット検索/購入/動画閲覧/投げ銭等ができる動画配信サービスとその管理システムを新規開発しました。フロントエンド・バックエンド・チーム管理を担当しました。 # 開発チーム PM × 2名 PL × 1名 エンジニア × 10名　-> このエンジニアチームの管理を実施 テストエンジニア　 × 10名 デザイナー × 1名 # 使用技術 - Docker, Jenkins, AWS, PHP8.0, MySQL8.0, Redis, Apache、独自FW - HTML, CSS, Javascript - Slack, Redmine, Backlog, Discord # 担当範囲 エンジニアチームや顧客との課題整理、進捗などをPLとして管理、およびバックエンドエンジニアのメンバーとして基本設計〜実装/単体テストまでを担当しました。 - 管理：顧客との仕様のすり合わせや課題管理をBacklog上で行い。確定事項はRedmineに起票してエンジニアに共有していました。WBSを作成して進捗管理を行い、タスクの遅れ等は人員へのRedmineタスクの付け替えや顧客との調整をしていました。また設計書やソースレビューを担当しました。 - 設計：PlantUMLによるシーケンス図の作成、draw.ioで画面設計書の作成を行い、Markdownで機能設計書として顧客に見せていました。APIのインターフェースはSwaggerを使って作成し、バッチ設計も行いました。 - 実装：ログイン/会員登録、チケット購入(SBPS/PayPal)/払戻、在庫管理、購入履歴、お気に入り登録、チケット検索/一覧/詳細等、視聴ページ、外部システムデータ連携バッチ、会員管理、売上管理、コンテンツ管理、CSV出力、ライセンス管理など # 取り組み - 数に限りのある限定チケットの在庫管理を検討・実装しました。購入フローに入った瞬間に仮の在庫を確保しますが、大量のアクセスが想定されたため、仮在庫はDynamoDBで管理しました。購入が成立したタイミングでDBに格納することにしましたが、購入しない場合もあるため、仮在庫の有効期限を設け、定期的なバッチ処理で在庫の整合性を担保するようにしました。 - 決済処理の際に、SBPSへのAPI連携・基盤システムへの連携、メール送信など複数の処理が必要でした。基盤システムへの連携はやり直しができないため、トランザクションに苦労しました。ステータスを設け、SBPSの連携のみ失敗した場合は、ユーザーには失敗と出して、次の決済では基盤システムへの連携をスキップするようにしました。 - 動画を検索する全文検索がLIKEになっており、検索に5分程度かかるパフォーマンスになっていました。Elasticsearch等外部サービスは使えなかったため、フルテキストインデックスで解決を試みました。半角スペース区切りでも検索したかったので、パーサーはngramを採用し、漢字１文字もあったため、1文字区切りとして設定しました。結果的に検索は30秒未満に抑えられました。 - チケット管理など業務システム側は使う人数が限られるため、基本は楽観ロックを採用しました。 - コーディング規約(PSR2)やeditorconfig、Docsを書いてもらうなどを行い、最低限のコード品質を保ちました。 # 課題 - 仕様の未確定やコード品質の低下 仕様がなかなか確定しなかったり、確定しない状況で作り始めたため、コード品質の低下が発生しました。また、コロナだったため、リモートの中で若手のメンバーをサポートしたり、仕様をエンジニア間で整理する必要がありました。 # 工夫した点・成果 - Discordの導入やチケット管理の共有 Discordを導入し、常に話せる状態を作ったことで仕様の勘違いや漏れをできるだけ抑えるようにしました。 またペアプロを実施し、最低限のコードの品質を揃えることにしました。 顧客との仕様策定が会議・チケット・個別Slackなどでバラバラになってしまっていたため、Backlogに統一し、内容はRedmineに起票して情報やタスクの整理を行いました。 # 解決できなかった課題 - デグレーションの多発（ユニットテストの導入） メンバーの追加や入れ替え、また仕様の細かい変更が多く、デグレーションが多発しました。請負のため、ユニットテストコードの必要性を理解してもらえず、書くことができませんでしたが、必要性を痛感しました。

# 概要 請求書管理システムにて、請求書の承認/発行/メール送信ができる機能を追加開発しました。バックエンド開発と途中からプロジェクトリーダーを担いました。 # 開発チーム PL × 1名 エンジニア × 3名 # 使用技術 - PHP7系、MySQL5.7、Apache、Vagrant、VirtualBox - Smarty（テンプレートエンジン）、JavaScript(jQuery) # 担当業務 - 実装、テスト: 帳票のExcel出力、PDF変換バッチ、帳票の検索/詳細表示/登録/削除機能、帳票のメール送信機能、画面上でのPDF表示/ダウンロード機能を担当しました。 # 取り組み - 画面上で請求書情報を入力し、入力された情報をExcelとして出力する機能を作りました。PHPSpreadsheetを導入して実現しました。 - 顧客や内部でのメール送付とするため、ExcelからPDFへのデータ変換が必要でした。PDF変換にはTCPDFを用いて行いました。また、メール送付のためにはPDFの結合が必要だったため、大元のExcelの出力情報やPDF変換状況のステータスを管理する親テーブルと結合前の各帳票Excelの出力情報を管理する子テーブルの2テーブルでバッチ管理を行いました。 - 帳票の発行状態を管理する画面を作り、失敗した情報を見えるようにしました。 - 帳票の出力・送付状態を検索・確認できる検索画面を作りCRUD処理を作りました。 - PDFを表示する画面を作りiframeで埋め込みました。ダウンロードしたかどうかをステータス管理し、操作者も特定できるようにしました。 # 課題 - 帳票が100ページあるものもあり、バッチ処理が遅くなったり、メモリが足りずに落ちる現象が起きました。 - 仕様のすり合わせがうまくいかず、元々のリーダーが途中で飛んでしまい、代わりにリーダーとして調整を行いました。 - 元のソースがコントローラーに全ての処理を記載しており、保守性が低いソースとなっていました。またマイグレーションでの管理も行っておらずテーブル管理も適当になっていました。 # 工夫した点・成果 - PhoSpreadsheetの公式ドキュメントを参照し、APCuを用いてキャッシュすることでメモリの削減を行いました。結果としてかなりのスピード改善ができ、メモリ枯渇で落ちることがなくなりました。 - 上記対策でも要望に応えるスピードを担保できなかったため、バッチ処理は常時起動とし、PHPのexec関数で同時並行的に動作させることで、スピードを担保できました。エラーの際はバッチ管理テーブルにステータスを持たせ、次のバッチで再実行することとしました。 - フォントや画像指定、エクセルの線出力など、Execel出力の負荷が高くなっていたため、Excelフォーマットにできるだけ静的な情報を持たせるように顧客調整を行いました。 - 既存同様に手動追加だと、変更等が追いづらくなるため、phpmigというマイグレーションツールを使ってDB管理を行いました。またデータベースへのアクセス等がコントローラーにベタがきだったため、Modelを作りデータベースアクセスを分離しました。 - 顧客との仕様擦り合わせがもめていたかつエビデンスが残っていなかったため、何度も打ち合わせをして妥協点を見つけました。課題管理や仕様の棚卸しができていなかったため、Backlogで管理し、なんとか納品日までにご納得いただき、リリースすることができました。

# 概要 CM情報の登録・更新・削除/動画データアップロードができ、CM情報を閲覧可能なサービスを請負で新規開発。 CMの動画、CM情報のテキストファイルを読み込んでアップロード、管理できる機能を開発しました。 # 開発チーム エンジニア × 2名　 # 使用技術 - PHP7系、Laravel5.8、MySQL、Vagrant、VirtualBox、nginx、AWS - HTML、CSS、BootStrap、JavaScript(jQuery) # 担当業務 顧客との仕様の擦り合わせやAWSインフラ設定〜リリースまで新規開発の全ての工程を担当しました。 - BootStrapでのモック作成 顧客と画面の仕様を摺り合わせるために、Bootstrapでモックを作りました。 - AWSインフラ設定 Route53、EC2、RDS、ELB、S3、CloudWatch、AWS Elemental MediaConvert、CloudFrontなど、開発/本番環境でのAWS構築を行いました。 - 実装 データベース設計、ログイン認証(外部ユーザー基盤とのAPI連携による認証)、ユーザー連携バッチ作成(外部ユーザー基盤とのデータ同期)、ユーザー一覧/登録/編集/削除、S3への動画データアップロード機能(単体/一括)、AWS Elemental MediaConvertによる動画形式変換(ts - > mp4)など # 取り組み - 開発環境はVagrantとVirtualBoxでCentOSやPHP、nginx、MySQLなどをインストールしてコマンドをシェル化、誰でも環境構築できるように設定しました。 - まずは作ってみたいということだったので、AWSはEC2を2台でロードバランサー設定とし、RDSは１台でリードレプリカを設定。動画データのアップロード用にS3を設定し、CloudFront経由のみでしかアクセスできないようにしました。 - AWSはIAMを設定して、必要になったら権限を付与する形にしました。また、管理画面は特定のIPからのみアクセス可能としました（ホワイトリスト）。 - 画面側としては、動画とCM情報のテキストファイルを読み込ませ、Javascriptで動画名とテキストファイル記載の名前がマッチしたものだけをアップロード可能としました。動画はS3にアップロードし、画面上ではカーソルを合わせたら自動再生するようにしました。 - ログインは顧客のユーザー基盤を利用したいということだったので、JWTを付与したAPI認証としました。 - サービス内のユーザ権限管理も行いたいということで、日次の夜間バッチを作成してユーザー情報を同期しました。 # 課題 - 結合テスト時に、MacのSafariで検証を行ったところ、カーソル合わせでの動画自動再生ができませんでした。 理由としてはCM動画の動画形式が.ts形式であり、対応していないためでした。 常時バッチを作り、裏側でmp4形式に変換してS3にアップロードすることも考えましたが、変換時間がかかりすぎるため断念しました。 # 工夫した点・成果 - S3にアップロード後に変換する仕組みはないか探したところ、AWS Elemental MediaConvertを見つけ導入を提案しました。調査したところ料金も安く、問題なく変換できたため、導入したところ、変換時間も早く、サービスに問題ありませんでした。運用後も料金はほとんどかからなかったため(1ドル前後）、成果を出せたと思います。

# 概要 駅検索のスマホアプリからAPI要求を受けるAPIインターフェース機能の改修/保守/新規機能開発をバックエンドエンジニアとして担当しています。 # 開発チーム PL × 1名 エンジニア × 5名 # 使用技術 - VisualStudio、IIS、Windows Server、C#、.NET Core6、SQL Server # 担当業務 - API設計書の修正、実装、単体テスト/管理システムのURL設計、DB設計、機能設計書作成を担当 # 取り組み - C#と.NETは未経験だったため、MicroSoftのチュートリアルを実施して、最低限の知識を持ってプロジェクトに入りました。 - 駅検索時に検索オプションを設定することによる、API項目の追加に伴うAPI設計書の修正/実装/開発環境へのリリースを担当。 - 既存のソースはControllerが肥大化しすぎていたため、新しく作る機能は1メソッド1機能を心がけてユニットテストしやすいようにしました。また、ユニットテストがメンテされていなかったため、新しい機能については作成し、ユニットテストの作成方法をwikiに残しました。 - 本番環境のエラーログを毎週取得し、大きな問題がないかソース調査。 - 駅員用の管理システムを新たに作ることになったため、DB設計、URL設計、画面設計、シーケンス図の作成を実施。テーブルとしては6テーブルほどで、ユーザ/権限/所属/エリアなどを管理するものでした。また、AzureADを用いたユーザ認証を行うために、XamarinにてMSALで認証がうまく機能するか検証を行いました。

# 概要 社内データ基盤から直接SaaSに繋ぐことができなかったため、中間サーバーを配置し、データの加工や確認を行うシステムを構築しました。PL/バックエンド開発エンジニアとして参画しました。 # 開発チーム PL × 1名 エンジニア × 3名 # 使用技術 Python3.6、Flask、Jinja2、SQLAlchemy、CentOS8、VirtualBox、Vagrant、Apache、PostgreSQL12 # 担当業務 - 管理/設計 プロジェクト管理 、基本設計書作成 - 開発/テスト CSVアップロード/ダウンロード、データ基盤からのデータ取得/加工バッチ、SaaSにデータを送信するバッチ # 取り組み - 機能としてはほとんどAPIのみだったため、Djangoなどと比較して、軽量のFlaskを選択しました。ORMとしてはFlaskの拡張機能として利用できるFlask-SQLAlchemyを使うことにしました。 - VirtualBoxとVagrantで開発環境を整えました。pipenvを用いてパッケージ管理を行いました。バッチはcron、ログはlogrotate、メールはpostfixで設定しました。 - ソースの構成としてはgithubで参考になりそうなFlaskのプロジェクトを探し、MVC風に構築しました。 - CSVをアップロードし、内容を確認する画面があったので、Jinjaで実装しました。 - SaaSの要件に合わせたcsvを連携する必要があったため、バッチで基盤からcsvを取得、データ加工をしてDBに保存。そのDBからCSVを作成してSaaSに連携するようにしました。 - データ加工のため繰返し処理が多くなりましたが、負荷を抑えるため、できるだけ繰返し処理の中でSQLを実行しないように心がけました(bulk insertを使うなど)。 - ファイルが貯まっていくため、不要データ削除のバッチも作成しました。