ID:9976さん

# ECサイト開発プロジェクト ## 目的 繁忙期の負荷に耐えられなくなっていた自社ECシステムを、 3,000件/日の受注に耐えられるよう新たに構築すること ## 規模 参画パートナーのスタイルにあわせ、ウォーターフォール形式で プロジェクトを進行しました。 - 自社 - 5名 - パートナー(EC/会員機能) - 5名 - LAPP+独自フレームワーク(PHP) - パートナー(インフラ構築) - 2名 - パートナー(オーダーメイド商材作成アプリケーション) - 5名 - IIS+VB.Net+Flex ## 役割 各システムを開発・構築するための、要件定義・設計を主に担い、 受け入れテストを行った後、2016年まで保守運用に携わりました。 ## 補足 - 東北の震災で一時はプロジェクト中止まで検討されたものの、最終的に期日どおりリリースできました - リリース直前に、Flexアプリケーションがモダンブラウザに対応してないことが発覚するなど、WF形式で開発することの難しさ・リスクを学びました - 2012年に改修を実施し、各ブラウザに対応

# オーダーメイド商材作成アプリケーション開発プロジェクト ## 目的 スマートフォン流行の情勢を踏まえ、PCのみで可能だったオーダーメイド商材作成を、 スマートフォンからも可能にすること ## 規模 - 自社 - 4名 - パートナー(バックエンド) - 1名 - パートナー(技術支援) - 2名 - パートナー(フロントエンド) - 3名 ## 役割 PCの仕組みを構築したベンダーに技術支援を受けつつ、 要件定義・設計を行いました。 また、フロントエンドを担うパートナーの技術力不足が プロジェクト途中で発覚し、急遽フロントエンドの開発に あたりました。 ## 補足 - ユニットテストを初めて本格的に導入し、結果、ほぼ不具合の無い品質で現在の運用まで至っています - パートナーのコードベースを捨ててフルスクラッチの再開発で非常にタイトでしたが、必須要件であった繁忙期のリリースに間に合わせることができました

# ECサイト開発プロジェクト ## 目的 販促の一環として展開する期間限定のECサイトを、フルスクラッチで構築すること ## 規模 - 自社 - 2名 ## 役割 開発の役割をフロントエンド・バックエンドで分担し、 主にバックエンド(Web API)の開発を行いました。 ## 補足 - AWSを初めて本格的に利用し、実質2ヶ月弱の開発期間と非常にタイトだったものの、期日どおりにリリースできました - 短期間で大量のビジネスロジックを作り込む必要があったので、インフラの整備コストを圧縮できるようElasticBeanstalkを選定しました - ビジネスロジックが安定するよう、常にコードとテストを1:1で設計しました - AWSのebコマンドにバグを発見しましたが、修正対応を待つ時間も無かったため独自にパッチをあてて回避しました - ARのN+1問題で、数量の多い注文を処理しきれない課題を解決するのに苦労しました。 - バルクINSERTへのスイッチで解決しました

# 画像スキャンサービス連携システム開発 ## 目的 「画像→文字列抽出」のサービスを提供する外部パートナーのシステムと連携した 自社サービスを構築すること ## 規模 - 自社 - 2名 - パートナー(サービス提供) - 2名 ## 役割 開発の役割をアプリ・バックエンドで分担し、 バックエンドの開発(データ送受信)を行いました。 ## 補足 - AWS lambdaを初めて本格導入し、トリガーとスケジューリング起動による徹底した効率化を実現しました - FaaSで責務を小さくまとめたことで、リリース以降バグ0で運用できており、現在では自社の複数プロジェクトで利用されています

# バックヤードシステム移植プロジェクト ## 目的 クラウド運用のコストを削減するため、EC2で稼動するバックヤードシステムを サーバーレス化すること ## 規模 - 自社 - 1名 ## 役割 既存のシステム(Ruby on Rails製のWeb API)を分析し、サーバーレスアーキテクチャ で再設計・開発を行いました。 サービスの特性上、単日で数万回コールされるAPIを安定稼動させる必要がありましたが、 既存のrailsでは高負荷を処理し切れずシステムダウンが頻発していた点、スケールアウト させる為のコストを削減したいという運用の要求から、サーバーレスアーキテクチャを 採用しました。 また、設計の過程で既存データの大規模な洗い替え(約800万件)が避けられないことが 判明したため、急遽AWS Step Functionsを利用したバッチ処理を開発し、洗い替えを行いました。 ## 補足 - DynamoDBを想定したORMの良いライブラリが見当たらなかったため、自作するところで苦労しました - 実施したデータの洗い替えは、失敗率0.01%で着地させることができました

# 業務支援システムリプレースプロジェクト ## 目的 開発以降、10年弱の運用で機能追加やメンテナンスが困難になっていた 社内業務支援システム(Webアプリケーション)をリプレースし、 社内メンバーの要望実現や保守容易性を担保すること ## 規模 - 自社 - 1名 ## 役割 運用部署起案ではなく、システム部門発案の案件であったため、 企画・折衝・推進から始まり、すべての工程を担当しました。 既存のシステムがSSRのWebアプリケーションで、当時既に パフォーマンスの問題が顕在化していたため、Web API + SPAの アーキテクチャで構築しました。 また、JavaScriptを駆使していたがゆえのランタイムエラーも課題であったため、 堅牢性とパフォーマンスを重視してフロントエンドにはElmを採用しました。 リプレース対象システムの機能は100を超えていたため、リプレースのスコープを区切り、 運用部署が最も多忙となる時期までに、基本機能の開発を終えて運用に乗せることができました。 ## 補足 - SPAでの認証における最適解を見出すところで苦労しました - 最終的にはCORS+Cookieを利用した認証方式で着地させました

# 業務基幹システムブラッシュアッププロジェクト ## 目的 前任者から引き継いだ自社の業務基幹システムを、 現在の運用実態に合わせて再設計・リファクタリングし、 安定性と保守容易性を担保し、運用部門の業務効率化に寄与すること ## 規模 - 自社 - 2名 ## 役割 引き継ぎ後の運用保守を行う過程で、システムの老朽化による業務への影響が 看過できないレベルになっていると判断し、ブラッシュアップの企画から始めました。 運用業務というインターフェースへの影響は最低限にとどめるため、 システム部門内の関連メンバーを巻きこみながら再設計とブラッシュアップの リファクタリングを進めている最中です。 2023年年末をゴールとしたロードマップベースで、8つ存在するシステムのうち、 2つのシステムを2022年前半に再設計完了させる予定です。 ## 補足 システムの老朽化というと、「作り直した方が早い」というケースはままありますが、 現行システムの設計思想が一貫していた点と、静的型付けであるC#の利点を活かし、 「既存の設計思想を残しつつ、コードを全体的に入れ替えていく」アプローチとしました。 引き継ぎ前には存在しなかったユニットテストを数年がかりで充実させてきたので、 大きな変更に対して躊躇なく取り組める下地ができており、新人メンバーの教育の場にも なっています。 また、.NETのオープンソース戦略も取り入れ、インフラをWindows Serverから Linux ServerやAWSのServerlessに切り替えていくPoCも進めています。